181–190 of 257 posts
This is a reminder that the excellent pyenv [0] project can help you manage all your Python versions. - Set global and per-project python versions - Not written in Python. - Shims your PATH - Linux, Mac, Windows [0]: https://github.com/pyenv/pyenv
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…
I've dealt with a lot of sideways yak-shaving work in my career and still frequently today and Python has been the absolute least of it.
Earlier quoted context omitted.
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…
Meh, the print change was fairly trivial. You could backport the print function in Python 2 codebases, and updating existing print statements to use the function was easy to automate. String changing from bytes to Unicode was a lot more painful, in my experience.
Back when Python 3 was first released, the error message was not so clear, either...
I hope we don't end up with the same things as the java world. JDK9 removed and moved to a library a few things like JAXB. Since JDK11, every new version is harsher for programs that use reflection to mess with non-published internals. Both are good changes, BTW. In theory, you add a few libs and you're ready to upgrade. In practice, adding libs at scale is hard, and quite a few dependencies of dependencies of ... ar…
> Both are good changes, BTW. I disagree. The entire point of setAccessible is to say I want to access nonpublic things. I shouldn't have to also say "Simon says, pretty please" for each such access on the command line to be able to do so.
But you can't expect from your API vendor that they won't ever again change the internals of the implementation just because you forced your way in and monkeyed with the internals. Writing your code this way is a surefire way to need rework at some unpredictable time in the future.
If you're lucky, it just crashes. A worse possibility is subtly corrupting and destabilizing your program. That was what happened in some of these cases: hashcodes were stored/cached in collections after an upgrade, and people using reflection to 'restore' a collection didn't update these caches correctly or dropped them in the wrong hash bucket. Then the hashmap had elements that were both there and not there, depending on how you queried it.
One of differences of a senior engineer is that you not only say it works today, you can guarantee how it stays working long term, even when the environment changes. Things like tests and comments are part of that. API contracts are a big part of that, both in being explicit about them as an API provider, and not touching non-guaranteed parts as an API consumer. Using setAccessible like this is a grave violation of an API contract, and it takes away your ability to upgrade to later version.
Earlier quoted context omitted.
For a different perspective, I started using python about 5 years ago, and I never experienced a single breakage due to a new python release. Instead, I'm always excited to read new version releases notes and it's the only thing that may make me move away from debian stable someday. But waiting a few months, using containers, or compiling a newer python is usually fine when I can't wait. Removing deprecated stuff is……
You should also look into pyenv if you'd like to install newer versions sooner, outside a container.
> smtpd has been removed according to the schedule in PEP 594 Damn! I guess it's time to cross out my snippet of running a debug smtp server in almost any Linux distro & Mac: python -m smtpd -n -c DebuggingServer localhost:25 > Remove the distutils package. It was deprecated in Python 3.10 by PEP 632 So apparently we need to replace from distutils.version import StrictVersion with from pkg_resources import parse_vers…
I thought having smtpd was useful but I guess people must be using better maintained alternatives. Anyone care to comment on what they are using for receiving emails in Python? Update: smtplib is still on, so that makes sense.
In most cases, you use an existing MTA (like Postfix or whatnot) and set it up to deliver mail to a Python script. Or, even less directly, you use an IMAP library to access mail after it's delivered to a mailbox, or use a mail provider which can call a webhook over HTTP when an email is received.
For the rare situations where you do really want to write your own mail server, aiosmtpd exists, and the migration process doesn't look terribly complicated: https://aiosmtpd.readthedocs.io/en/latest/migrating.html
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…
I literally have 20+ years old perl scripts, usually doing one single thing (many of them) still working on new machines without issues.
I've rewritten some stuff from python(2) to perl (instead of python3) because i was unsure when a new rewrite for whatever reasons...
Now, more python stuff needs fixing, while perl still works.
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…
If you type `print "arg"`, the syntax error is a bit more informative, but I wouldn't say that the compiler "understands" what you mean. It's just making a guess based on the fact that the previous token was "print".
On the other hand, supporting a special call syntax just for print, which includes more than just parentheses, would be substantially more complex. And then Python code in the wild would be more inconsistent and there will be endless debates about `print ` versus `print()`.
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.
Except for when it comes to packaging and distribution. That is still a nightmare for newbies.