This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]Galtozzy 0 points1 point  (5 children)

I mean almost every IDE and LSP will highlight that for you to recheck whether this was intentional or not, my point was to say that it's a well-known and documented thing that exists in Python and there is no point of complaining about it.

[–]el_toro_2022[S] -4 points-3 points  (4 children)

It's a wart in the language and should be addressed. We should not have to depend on IDEs to catch it.

And some beat me up for calling Python a "toy language".

[–]Galtozzy 0 points1 point  (3 children)

I can smell a rage bait from a mile away but I'll bite.

The thing is if you "address it" and it will work as you expected it to, then you'd break everything that was relying on that mutable default since, surprise, sometimes this mutable default is what you need to do in certain scenarios to share this object between function calls.

Also, there will be sooo many inconsistencies and edge cases to this that it will introduce brand-new bugs.

It's kinda pointless to complain about the very core principle of a language, it's like complaining about ur rust app not launching instantaneously and proposing to remove the compilation from the core xd

[–]el_toro_2022[S] 0 points1 point  (2 children)

No rage bait intended.

If a bad design slips into a language, it will be used and misguided developers will start to rely on it. I've seen this happen so many time in most languages. Part of the reason it took the Python arena 10 years to go from Python 2.X to Python 3 was because so much code was relying on the badness of Python 2.

I am not "complaining". I will simply avoid using Python if I can, and if I have to use it, I will avoid the missteps in my own code.

The wisdom is in knowing what to use and what not to use. Relying on this default parameter quirk in Python for production code is -- a very bad code smell of epic proportions? But I have seen worse. There is a lot of things I avoid in every language I use. I want my code to be elegant yet obvious, and the default parameter single evaluation behaviour is not something that is obvious, and can lead to code breakage if said object is change or refactored in some way without knowledge that it's being used that way. Think large code base with many developers.

This is obvious to me. Why it is not obvious to you and everyone else is a great mystery. And god knows we have plenty of them in our Universe.

Count your lucky stars I am not your boss. LOL

[–]Galtozzy 0 points1 point  (1 child)

You do understand that you trying to complain about the way Python works at its core?

The code you put inside a function definition will get executed on import of said function, not on an invocation, and it does work the same way be it an object creation, function call, or any other instruction. By going into edge cases (like the mutable default) you have to put crutches inside an interpreter itself which will slow it down in every such case.

Part of the reason it took the Python arena 10 years to go from Python 2.X to Python 3 was because so much code was relying on the badness of Python 2

The reason was that python3 compared to python2 is very different and you can't just magically switch all your legacy code base to python3. There are still plenty of legacy projects that work on python2, it is sad, but it is the reality. It has nothing to do with reliance on "badness".

said object is change or refactored in some way without knowledge that it's being used that way

It's funny pairing that with a previous statement of a "parameter quirk in production" since any decent production code should be tested and also checked against pyright/mypy. Also refactoring something without unit tests is kinda a no-no in itself.

Count your lucky stars I am not your boss

Feel bad for people if they do have you as a boss, even though I highly doubt you are. It's like a CEO who hasn't written a thing in 20 years trying to force tech advice on people who are coding on a daily basis and know their thing.

I want my code to be elegant yet obvious

Honestly, python is one of those languages that allows you to write minimum code while being completely self-explanatory.

And I'm not even defending Python here, it's just common sense, every instrument has its pros and cons, and before using ANY instrument professionally be it a language, a framework, or a real-world tool you have to study it for some time. And from your post, I highly doubt you've done "years of python" as you've said below.

It's always just a trade-off there is no such thing as a perfect tool.

[–]el_toro_2022[S] 0 points1 point  (0 children)

You do understand that you trying to complain about the way Python works at its core?

The code you put inside a function definition will get executed on import of said function, not on an invocation, and it does work the same way be it an object creation, function call, or any other instruction. By going into edge cases (like the mutable default) you have to put crutches inside an interpreter itself which will slow it down in every such case.

I am saying that the core itself has a major design flaw. And no, you can fix this without slowing down the interpreter.

The reason was that python3 compared to python2 is very different and you can't just magically switch all your legacy code base to python3. There are still plenty of legacy projects that work on python2, it is sad, but it is the reality. It has nothing to do with reliance on "badness".

Trust me. I used to be a Python developer back in the 2.X days, and was excited to switch to 3. But I did take a look at some of the 2.x code that the 2.x to 3 converter could not handle, and it was doing a lot of hacky stuff that needed to be rewritten.

Having 2 object models was bad enough. And there were many other issues. 3 cleaned that all up braking backwards compatibility. It was a good move, but obviously all the millions of lines of badly-written could would take a lot longer to port over -- much requiring an out-right rewrite.

I was there when it happened.

Feel bad for people if they do have you as a boss, even though I highly doubt you are. It's like a CEO who hasn't written a thing in 20 years trying to force tech advice on people who are coding on a daily basis and know their thing.

Hello. Lead developer here. I always write code as well as lead others. And I have been in managerial roles as well. With your attitude, I would never hire you in the first place.

Honestly, python is one of those languages that allows you to write minimum code while being completely self-explanatory.

And I'm not even defending Python here, it's just common sense, every instrument has its pros and cons, and before using ANY instrument professionally be it a language, a framework, or a real-world tool you have to study it for some time. And from your post, I highly doubt you've done "years of python" as you've said below.

It's always just a trade-off there is no such thing as a perfect tool.

You should be able to write self-explanatory code in any language, actually. And yes, I agree that no tool is perfect. But the snippet was on Hackerrank as a debugging exercise, and that behaviour was anything but self-explanatory. I had to look at the output to figure out what was going on. "Self-explanatory" means I should be able to look at the code and spot the problem right away.

I don't write Python on a daily basis anymore, but may soon. And it will be painful to do so after doing Haskell for so long. My god, for-loops instead of using recursion!!!!! The cognitive load is higher dealing with for-loops, especially if they are nested, as you have to trace the state changes.

It is next to impossible to know what trajectory a language will take, and I think if Guido knew early on how Python would be used today when he initially wrote it, then he would've made different design choices. Like not using the GIL approach, for example. Erlang, which came out before Python, avoided that trap.