171–180 of 257 posts
It’s a great time to be a Python developer. Python seems to be settling in to a really nice sweet spot of accessibility and power, and with the upcoming performance improvements it’s got an even brighter future.
Earlier quoted context omitted.
Not forever, eg very old versions of Python cannot install dependencies from PyPI anymore because SSL is stricter nowadays.
I mean that level of breakage is good. You can’t keep running outdated stuff while expecting to interact with the wider world.
Don't think I was using any of these removed things, and it all sounds sensible looking at the fuller list at https://docs.python.org/dev/whatsnew/3.12.html#removed > Remove the filename attribute of gzip.GzipFile, deprecated since Python 2.6, use the name attribute instead. 2.6 wow, that's some compatibility right there. About time that got removed then! Either that or undeprecate it, if it's fine to use. Any decisi…
Perhaps after the big mess of the backwards incompatibilty of 3.x vs 2.x, they are erring on the side of caution now.
Earlier quoted context omitted.
I mean that level of breakage is good. You can’t keep running outdated stuff while expecting to interact with the wider world.
Okay, then practically you can't pin versions and have it work forever.
Anyone care to comment on what they are using for receiving emails in Python?
Update: smtplib is still on, so that makes sense.
Earlier quoted context omitted.
I disagree strongly with this take and it seems basically to be saying "better error messages are bad." What if clang says "did you forget a ';'"? It would have been better to just compile the code as if there was a semicolon?
No need to disagree, that's just two different design patterns among programming languages. If stuff like that matters, you can always choose Ruby or something similar. It has its own shortcomings though and neither approach is ideal in every situation. That being said, the transition from Python 2 to 3 was the most horrible thing that ever happened to a popular language. Print for example was fine as a keyword and f…
I'm normally joyful when a modern language (say, julia) decides to break backward compatibility to improve the language on a fundamental level. This is mostly because I'm not too vested in it. For languages where I have 10+ years of work behind, it's the exact opposite, and where I see the c/c++ model of not breaking backward compatibility a much saner choice. Python in particular is an extremely bittersweet pill to…
Ah, but that's because the Perl community rejected the one major attempt at such a change (Perl 6) so hard that it became its own separate language.
Earlier quoted context omitted.
I disagree strongly with this take and it seems basically to be saying "better error messages are bad." What if clang says "did you forget a ';'"? It would have been better to just compile the code as if there was a semicolon?
This is why I appreciate languages with a strict and non-strict mode. Let me make that choice. In particular, if the parser is intelligent enough to understand what I meant and is just throwing a syntax error to be pedantic, then let me control that. Needlessly taking choices away will always be a frustration.
- It is a maintenance burden on the compiler/interpreter writers to allow both modes
- There may be unexpected behavior when you use code from two different sources; one that expects strict mode and the other expects non-strict mode
- There may be interpersonal conflict when developers working together prefer one mode over another
I'm normally joyful when a modern language (say, julia) decides to break backward compatibility to improve the language on a fundamental level. This is mostly because I'm not too vested in it. For languages where I have 10+ years of work behind, it's the exact opposite, and where I see the c/c++ model of not breaking backward compatibility a much saner choice. Python in particular is an extremely bittersweet pill to…
Agree. This is perfectly exemplified by Python 3's insistence that you call print with parenthesis: >>> print "hello" SyntaxError: Missing parentheses in call to 'print'. Did you mean print(...)? I empathize with the lang devs in that having two forms of print is nonoptimal, but the fact it tells you to do something different while fully understanding what you said (as it were) is what really irritates me. It comes o…
While the Python3 lexer is specifically hacked up to recognize 'print' as a distinct lexeme — and to thereby emit an additional parser meta-instruction lexeme that triggers a special error-handling path in the parser if you then go on to make a syntax error per the newer uniform syntax — it doesn't actually know what you were trying to print. (That'd require a successful parse!) If the Python3 parser tried to do the compatible thing, that'd require ditching the uniform syntax altogether, and going back to the ambiguous parser.
It's a bit like Error Correcting Codes — the uniform Python3 parser knows enough to know that you did something wrong, and is provided by the lexer enough context to guess what kind of failure it was; but it doesn't have enough information to "Do What I Mean", because that's a strictly-greater amount of information.
I'm curious if there's anything preventing them from switching to semver.
Their own decisions. They want to spread little breakages over many realeases instead of collecting them into big breakages, due to the 2 to 3 fiasco. Feels like an over-correction imho.