Python Complaining About Python

  • Thread starter Thread starter Hornbein
  • Start date Start date
AI Thread Summary
The discussion centers on the challenges and frustrations associated with Python's weak typing and indentation rules. Key points include the difficulty of accidentally redefining functions without warnings, which can lead to significant errors, especially when transitioning from Python 2.7 to 3.10 due to changes in division behavior. The conversation highlights the importance of explicit variable types and the need for better IDE support to catch potential mistakes. Participants express concerns about Python's reliance on whitespace for structure, arguing that it complicates coding. The discussion also touches on the trade-offs of using Python versus more strongly typed languages like Go, particularly in production environments where performance and standardization are critical. Additionally, there are reflections on personal experiences with various programming languages, emphasizing the hazards of loose typing and the evolution of coding practices over time. The conversation concludes with anecdotes about past programming experiences and the evolution of coding tools, underscoring the ongoing debate about language design and usability.
Hornbein
Gold Member
Messages
3,394
Reaction score
2,756
The weak typing of Python has its ups and downs. The thing that really bothers me is when I accidentally have two copies of a routine. It doesn't tell me! It just blithely redefines it. That's going too far with weak typing.
 
Technology news on Phys.org
What can you expect from a language named after a team of comedians ?
 
  • Like
  • Haha
Likes harborsparrow, nsaspook, PeterDonis and 1 other person
What bothered me when I first used it years ago was the indentations. I recall having some lines indented by tabbing vs lines spaced in the same amount causing trouble.

More recently when porting a script from Python 2.7 to 3.10 I encountered the division (/) feature change that corrupted my logic. Basically Python 2.7 treated / as integer division when the operands were integers 5/2 was 2 vs the new interpretation of 5/2 as 2.5

The solution was to review all / operations and decide if the operands were both integers and if so switch to using //. The script I had was computing indices into a database table to retrieve some environmental data and got messed up big time switching to Python 3.10.
 
  • Wow
Likes FactChecker
jedishrfu said:
I recall having some lines indented by tabbing vs lines spaced in the same amount causing trouble.
White space should not have structure implications.
Variable type should be explicit.
 
Hornbein said:
The weak typing of Python has its ups and downs. The thing that really bothers me is when I accidentally have two copies of a routine. It doesn't tell me! It just blithely redefines it.

Detecting possible coding mistakes is not the job of a language implementation, it is the job of an IDE.

The following is valid syntax and is correctly processed by the compiler:

Python:
""" Spot the deliberate mistake. """

def get_half(num: float | int) -> float:
    """ Get half of a number. """
    return num / 2

def get_half(num: int) -> int:
    """ Get half of an integer. """
    return num // 2

But any sensible IDE (this is VS Code) will highlight your error:

1745835695744.png


Proper use of namespacing and type hints should help avoid making this mistake in the first place.
 
Baluncore said:
Variable type should be explicit.
It is true that one of the items in the Zen of Python is "Explicit is better than implicit", and yet the types of variables are implicit.

However, "variables" in Python are not like variables in other languages. Variables in, for example, C are labels for blocks of memory. Since blocks of memory, in and of themselves, don't have any type, you have to tell the compiler how it should interpret the bits that get stored in those blocks of memory--i.e., the type of the variable.

But "variables" in Python are namespace bindings: you're binding a name in some namespace to an object. And the object already has a type. Every object in Python has a type. So there's no need to tell the compiler about any "variable type" for the object, because it's already there.

What a "variable type" in Python actually means is: only allow this particular name in this particular namespace to be bound to an object with this type. That's already more complicated than "interpret the bits in this block of memory this way". And the tradeoffs involved are not the same.
 
I mainly hand translate Python to C for 8-bit controllers. I need to see the state logic in the code, not program in it. One of the, IMO, strange choices in Python is the reverse notation for 'if' .
 
One thing to consider is that python is often used for small coding tasks, proof of concept or data analysis tasks.

However, when we get to production code then a more rigorous approach is taken.

As an example, Go is preferred for docker/podman microservices development. Python orojects slated for microservices production often get converted to Go code.

One reason for that is a go executable contains all code needed to run vs python which needs all referenced modules to run. Go executables have a smaller memory footprint.
 
  • #10
Hornbein said:
The weak typing of Python has its ups and downs. The thing that really bothers me is when I accidentally have two copies of a routine. It doesn't tell me! It just blithely redefines it. That's going too far with weak typing.
I'm not sure how many languages you've used. It sounds to me that you basically like Python. But if you really want to code in something appalling, try Forth or Cobol. Those should completely recalibrate your tolerance for language quirks.

jedishrfu said:
I recall having some lines indented by tabbing vs lines spaced in the same amount ...
As if there was such a thing as a tab being the same as some invariant amount of spacing.
Since 4 spaces/tab seems to be common in Python circles, I would guess you had your editor set up for that. Here's what Google says:
Python 3 raises an error if tabs and spaces are mixed for indentation, and while Python 2 might not, it can lead to unexpected behavior.
It went on to describe what I expected, that when you mix spaces and tabs (and Python accepts it) it counts each tab as a space.

I do not use tabs. And when editing someone else's code, I make the whitespace visible so I can check it.
 
  • #11
Tabs only are nice when you do code mashups as things will be consistent.

I set my editor to convert tabs and use only spaces. One issue i saw when doing code mashups where spacing varied and you had to manually adjust them.

Languages using braces were more explicit with the programmers intent.
 
  • #12
.Scott said:
I'm not sure how many languages you've used. It sounds to me that you basically like Python. But if you really want to code in something appalling, try Forth or Cobol. Those should completely recalibrate your tolerance for language quirks.

In 1979 I got my first prog job in a Forth/Basic house that was converting to C. Memorable quotation : "The man who brought Forth into this place ought to be shot." It did have the advantage of being very light weight, but by 1979 that wasn't necessary any more. For them I wrote a Forth compactor that crammed as much as you could into those disc sectors. The name of the place was Zehntel, which is German for one tenth. I was told the founders had mistakenly believed it meant a power of ten. If so the company name was literally inverted. It was always pronounced Zentel. Zen is Japanese for zero. Their product included a vacuum pump. A coworker suggested that communication with that be done through a Succubus, while the printer would use the Incubus.

One of my co-workers said "I tried COBOL. When I tried to compile my first little program I got a hundred error messages. That was it for COBOL."

For some mysterious reason I have trouble installing software on this computer so at first I was using Python with a bare bones editor. This was highly impractical.
 
Last edited:
  • #13
.Scott said:
I do not use tabs.
The blog post I linked to in post #6 has a link to a hilarious newsgroup post by Tim Peters about the tabs vs. spaces issue in Python, as it was back around the turn of the millennium.
 
  • #14
PeterDonis said:
The blog post I linked to in post #6 has a link to a hilarious newsgroup post by Tim Peters about the tabs vs. spaces issue in Python, as it was back around the turn of the millennium.

I also used to think that way but in the last few years the increased prominence of the a11y argument resolves the debate in favour of tabs: https://www.brycewray.com/posts/2022/06/accessibility-argument-tabs-spaces/
 
  • #15
Hornbein said:
Their product included a vacuum pump. A coworker suggested that communication with that be done through a Succubus, while the printer would use the Incubus.
Most people don't know the difference, but my preference was the Concubus.
 
  • #16
pbuk said:
I also used to think that way but in the last few years the increased prominence of the a11y argument resolves the debate in favour of tabs: https://www.brycewray.com/posts/2022/06/accessibility-argument-tabs-spaces/
To me the answer to issues like accessibility is to uncouple the visual display formatting (or the other cues that are used by, for example, Braille) from the specific characters that are used to show indentation in the source code. This seems like an issue that IDEs could be solving.
 
  • #17
Neat I learned a new numeronym:

a11y

to go along with i18n, g11n, and l10n.

And I learned the word numeronym.
 
  • Like
Likes harborsparrow
  • #18
Baluncore said:
Most people don't know the difference, but my preference was the Concubus.
Heavily used by the Sultan, I'd wager.
 
  • #19
jedishrfu said:
Neat I learned a new numeronym:

a11y

to go along with i18n, g11n, and l10n.

And I learned the word numeronym.
"Numeronyms are commonly used in technical contexts, like in the localization industry. " Localization is an industry? Why not. Though I am puzzled as to what use n8s would be to them.
 
Last edited:
  • #21
Hornbein said:
A coworker suggested that communication with that be done through a Succubus, while the printer would use the Incubus.
:biggrin:
jedishrfu said:
to go along with i18n, g11n, and l10n
My favorite is ICU812
 
  • #23
By the time you get old, you learn things. "New" (mostly young) programmers have always seemed to prefer to use loosely typed languages. First it was Visual Basic. Now it's Python. They hate and avoid the strongly typed languages such as Java and C#. However, speaking for both my spouse and myself who both wrote code for most of our lives, we were both burned more than once by loose typing and its hazards. This usually happens once you already have a large, complex wad of code; then a name gets redefined, and the effects can be subtle and weird and take a long time to track down.

So, at some point, I pretty much stopped messing about with the loosely typed languages except for small bits of quick code. And I developed a lot of discipline about naming conventions to help avoid duplicate names.

There are 2 other reasons I never endorsed Python, despite its popularity. And those are its lack of standardization (I've been bitten several times in various unstandardized scripting languages) and also its lack of performance tuning internally (because I worked on large, complex systems with huge database backends).

It kind of thrills me to find someone admitting out loud that the loose typing in Python is hazardous.
 
  • #24
My favorite language for a time was Awk. I felt kind of burned out with C and the amount of work I had to do to code a one-time program to process some text files.

I discovered awk by accident when I ordered some Unix software tools from Thompson Automation. I wanted my PC DOS to resemble Unix in a time before I could acquire an IBM RS/6000 at work. Awk came as an extra.

I read the Kernighan AWK book and was hooked on the paradigm, doing all sorts of crazy things with it. It was a welcome diversion from the usual IBM C/C++ with STL nonsense I had to contend with.

AWK in other OS contexts was just not as cool as the Thompson DOS one. Often, I had trouble finding the compile error in my code.

My favorite AWK script was when I made a mini IDE. It was basically a frontend to Vim called vm, where I could be in the base directory of a project and type in a partial filename, which would display a numbered list of matching files, usually Java code. Entering the number would pull up the file in Vim.

Under the covers, it also created a copy of the original file with a different file type. If I made changes to it, then it kept the copy as a baseline. At the end of a session, I could pull up a list of changed files, and it would either launch Vim in file compare mode or just diff the original copy to the changed copy, so I could record the changes in my notebook for later use at my desk.

This was a closed lab environment where you could bring code on CD media in but couldn’t take anything back out. Available IDE tools may or may not be present, and you had to adapt to the environment.

My script significantly enhanced my productivity and reduced my anxiety levels because I knew it recorded my changes and enabled me to hack my code freely to achieve a working version.

Later on, I converted it to Python because it started to get a bit unwieldy, and Python brought some order to it again as I added features to facilitate network deployment and other things.
 
  • Like
Likes harborsparrow

Similar threads

Back
Top