21 ms·

Python 3.12.0 is to remove long-deprecated items

264 points by BerislavLopac 4y ago

voakbasda 4y ago
This is enough for me to swear off python for any long-lived or production system. I am tired of this kind of endless incompatibility. It has fractured the ecosystem sufficiently that things break all the time when trying to use any non-trivial set of dependencies. Maybe the developers will stop this crap with Python 4. It’s the next Perl 6!
DougBTX 4y ago
Breaking changes in Python releases are nothing new, that’s why none of my Python projects are using the latest version :shrug:
- OJFord 4y ago
  The title is referencing this line (not TFA's actual title): > In the unittest module, a number of long deprecated methods and classes were removed. (They had been deprecated since Python 3.1 or 3.2). I doubt your projects are using 3.1 or 3.2 (or older, except perhaps 2.7, but then you wouldn't care that 3.12 was removing something deprecated vs 3.11 which has it)?
  - janzer 4y ago
    There's quite a bit more than just the unittest removals https://docs.python.org/dev/whatsnew/3.12.html#removed https://docs.python.org/dev/whatsnew/3.12.html#removed An example of a more recent deprecation is the 'distutils' module which was deprecated in 3.10.
    - duskwuff 4y ago
      > An example of a more recent deprecation is the 'distutils' module which was deprecated in 3.10. distutils was functionally deprecated long before that. Even the Python 2.7 documentation (released in 2010!) recommended that users avoid distutils and use setuptools instead: https://docs.python.org/2.7/library/distutils.html https://docs.python.org/2.7/library/distutils.html
      - d1l 4y ago
        Isn't setuptools deprecated now too or on the chopping block?
        eesmith 4y ago
        I believe setuptools is more frowned upon - in favor of PEP 517/PEP 518 tools - than deprecated. Last I checked, there was no good way to package hand-written Python/C extensions than setuptools, but that was a couple of years ago. In any case, there's a large installed-based of setuptools-based projects making it hard to get rid of.
  - PurpleRamen 4y ago
    Deprecated does not mean removed. They are still there, working fine, having no big reason to change them. I know it, as I just checked my and my workplaces code, and there are several usages of deprecated code. And we are on 3.9/3.10.
    - samus 4y ago
      Merriam Webster lists the following relevant meanings for "deprecated": > to express disapproval of > to withdraw official support for or discourage the use of (something, such as a software product) in favor of a newer or better alternative In other words, deprecated is a strong signal that one should strive to migrate from items marked as such.
      - PurpleRamen 4y ago
        So what? As long as it works, don't change it. This parts are deprecated since up to nearly a decade (Python 3.2 was released February 20th, 2011). And they will work for some more years. Some have not even a working replacement yet. Investing now in changing old code just to be compatible to a not even released version, is a bit pointless if you have more important work on the list.
        samus 4y ago
        Python 2 was supported for way longer than initially announced. Distutils as well. Maybe deprecated is not a strong enough signal because many projects hesitate to cut stuff loose that they deprecated because of the community backslash. Sometimes things have to be deprecated, but the community will never get around to adapt to that if they stick around forever. Compared to that, Java still carries some deprecated items around. But with Java 9, deprecation for removal was introduced, which is a strong signal that stuff will be gone in two releases. Kubernetes has a strict deprecation policy as well, such that skipping more than two releases is asking for trouble.
    - sigzero 4y ago
      Except the notice is about "removing deprecated modules"? Deprecation usually means "These are going away at some point. Be aware.".
  - adrian_b 4y ago
    I do not know what is wrong with Python, because I use it only occasionally, for short programs that do not use obscure features. Nevertheless, there is no doubt that it is the worst software project that I have ever seen, during several decades, from the point of view of keeping compatibility between versions. For other programs, I may happen to need to have installed 2 versions, or maybe 3 versions, at most, in order to be able to use other programs that are compatible only with certain versions. On the other hand, for Python, during many, many years, I have been forced to keep installed all the time around 7 or 8 versions, to keep happy many other programs that claim to be compatible only with certain Python versions (and not also with any newer versions; some programs are even compatible only with a list of non-consecutive versions). Building from source any program that depends on Python may frequently require various temporary configuration modifications, to ensure that the program is built only for the Python versions with which it is compatible.
    - drunkpotato 4y ago
      I will say this, I love python, and I hate python the way only someone who loves it can. I think everything you said is accurate. I love writing Python code. I love its standard library and many third party libraries. But I loathe Python’s dependency management, and Python version upgrades are sometimes a huge pain. There are tools to help with this (pyenv or I am fond of asdf for python versions; poetry or pipenv for isolating package dependencies), but they only partially solve the problems and introduce new ones.
- rightbyte 4y ago
  The move to web based apps or connected in general was a genius move by the programming community. Now there will be an endless churn to keep programs up to date for "security reasons" and that cost money. We can even pull the plug on programs nowadays to the give the users the very best experience! Otherwise the lusers might have felt satisfied with what they have.
  - nicoburns 4y ago
    You say that, but the web platform rarely if ever removes features in this way. My web code from 15 years ago works the same as it always did.
    - rightbyte 4y ago
      Obviously you chose the wrong framework or even worse - none at all. Ye I am whining but only half joking. Breaking backwards compatibility ruins my mood. And Python are getting way to much slack for what they have been doing to the users. People wanting to stick to 2.7 are ridiculed and soon the software security police will start arresting offenders.
      - samus 4y ago
        If people that want to stick to 2.7 can find a vendor that supplies them security patches, then there is no problem.
      - senko 4y ago
        I recently upgraded a Python 2 + Django 1.x project with no tests to Python 3 and latest Django. Using 2to3, the most trouble I had were db migrations, which I just squashed. The rest were ferreting out str() problems that 2to3 didn't find (eg. redis package happily taking strings but returning bytes by default), Django regexp url changes, and trivial stuff like that. It took a couple of days work. I also wanted to upgrade the frontend part (webpack build of Vue). I stopped after a few hours od going nowhere and am still apprehensive of approaching that particular thing.
  - 4y ago
wirrbel 4y ago
https://docs.python.org/dev/whatsnew/3.12.html https://docs.python.org/dev/whatsnew/3.12.html For a lot more info on removals
- eesmith 4y ago
  > Removed many old deprecated unittest features ... > You can use https://github.com/isidentical/teyit https://github.com/isidentical/teyit to automatically modernise your unit tests. I tried out teyit when it was a "Show HN" 10 months ago (at https://news.ycombinator.com/item?id=29948813 https://news.ycombinator.com/item?id=29948813 ). It not only pointed out places where I was using a deprecated alias, but also fixed a few places where I was using the API poorly (using "assertTrue(a binop b)" instead of "assertBinOp(a, b)". I recommend it.
  - toyg 4y ago
    I can't comment on the quality of the tool, I just don't like this attitude of "just use this tool we don't support, hosted on some platform we don't control, which might disappear tomorrow". Back in the day, this tool would have been shipped (and supported) with stdlib, or at least be frozen somewhere "official".
    - samus 4y ago
      That tool is not a permanent addition to the list of dependencies, but for a single migration effort. As such, it is unnecessary to include it in the standard library.
      - toyg 4y ago
        It should still be hosted somewhere that won't disappear tomorrow if GH goes bust or starts packing malware.
        eesmith 4y ago
        It's also on PyPI. https://pypi.org/project/teyit/ https://pypi.org/project/teyit/ .
JonathanBeuys 4y ago
The changes seem to be in modules. What is the relation between a new Python version and changes in modules? Are some modules considered to be part of the language?
- BiteCode_dev 4y ago
  The stdlib is linked to the version of the language, yes.
  - dividedbyzero 4y ago
    I wonder if there are languages (that have a stdlib) where that isn't the case
    - ZiiS 4y ago
      The c stdlib is more tightly coupled to the OS then any particular Compiler; and is not changed when you select a particular dialect (though the language standard dose specify what stdlib must support).
- OJFord 4y ago
  They're in the standard library, like `std` or (ish) Node API, etc.
- qsort 4y ago
  Those modules are parts of the standard library. As far as CPython is concerned, most of those modules are implemented in C, and therefore for practical purposes part of the interpreter itself. > How can a language be released? If we really want to be pedantic, a new version of the language spec can be released. Translated to C++ terms, this is like if the ISO committee approved a change to the stl in the new standard.
imurray 4y ago
While it's been coming for a long time, it's still frustrating to see the cgi module go. It's going to create a load of busy work to rewrite some low-traffic scripts. Modules being removed [edit: in 3.13]: https://docs.python.org/dev/whatsnew/3.12.html#pending-removal-in-python-3-13 https://docs.python.org/dev/whatsnew/3.12.html#pending-remov... Updating CGI scripts will be a bit fiddly: https://peps.python.org/pep-0594/#cgi https://peps.python.org/pep-0594/#cgi
- jwilk 4y ago
  You linked to Python 3.13 removals. Python 3.12 removals are here: https://docs.python.org/dev/whatsnew/3.12.html#removed https://docs.python.org/dev/whatsnew/3.12.html#removed
  - imurray 4y ago
    Thanks. I did ctrl-f cgi as I knew its removal was coming and missed the heading. So one more point release of grace, but it's still coming soon.
- tyingq 4y ago
  There is CGIHandler that ships with python. Not many examples that are simple, so... #!/usr/bin/env python from wsgiref.handlers import CGIHandler def app(environ, start_response): start_response('200 OK', [('Content-Type', 'text/html')]) return [ b"<html><head><title>foo</title></head><body>bar</body></html>" ] if __name__ == '__main__': CGIHandler().run(app)
  - imurray 4y ago
    Thank you!
- sigzero 4y ago
  Just copy out cgi.py and use it as a module. https://github.com/python/cpython/blob/3.11/Lib/cgi.py https://github.com/python/cpython/blob/3.11/Lib/cgi.py
jeffrallen 4y ago
Great, so now not only Python will be incompatible with itself, but also incompatible with itself even if you use Python 3. Sigh.
- anakaine 4y ago
  Or, the glass half full view of the world suggests that low usage high barrier to maintenance module deprecation increases overall long term improvements and compatibility at the cost of small, planned, notified, short term inconvenience.
  - dbsmith83 4y ago
    I think you're missing the point. Nothing is wrong with deprecation, but it should be done properly. Ideally, breaking changes should correspond to a major version increase
- drexlspivey 4y ago
  You should sign up to maintain those ancient modules
  - xigoi 4y ago
    Why do they need to be maintained? Just leave them as is.
    - ciupicri 4y ago
      Because supposedly people will report bugs for them and someone will need to fix them.
      - xigoi 4y ago
        “Sorry, we don't fix bugs in deprecated code. Closed.”
        4y ago
Aachen 4y ago
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 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 decision at this point is a good one.
- martopix 4y ago
  Perhaps after the big mess of the backwards incompatibilty of 3.x vs 2.x, they are erring on the side of caution now.
  - leadingthenet 4y ago
    Can't blame them looking at some of the responses in this very comment section.
tbran 4y ago
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 https://github.com/pyenv/pyenv
- Already__Taken 4y ago
  Not really windows, WSL. There's windows fork recommended. Classic python splitting the ecosystem up. Why something like this isn't in go or rust that's actually cross platform capable just seems like excess effort.
  - Spivak 4y ago
    Because thanks to WSL the lingua franca of scripting languages is bash and that’s how pyenv started. Rewriting when it works fine on Windows and every dev I know uses WSL anyway is excess effort. Hell, the fork could have used Go or whatever too but it went with a bunch of .bat scripts.
    - 0cf8612b2e1e 4y ago
      Hello from corporate America where WSL is most certainly not standard and will require a virgin sacrifice if you want to get it approved by IT. Which is to say, no pyenv is not an option for everyone.
      - ihaveajob 4y ago
        Indeed, I recently worked on a fairly simple deployment for a state government agency. When I described the process to their IT staff and mentioned that we prefer using WSL, they looked at me like I had grown 2 heads.
      - int_19h 4y ago
        Even aside from that, WSL is only useful if you are writing code that will run on Linux at the end of the day. This is usually true for web apps, but that's not the only thing people write in Python. Libraries, in particular, need to be able to target Windows directly.
mikewarot 4y ago
Is there a standard way a Python script can ask for an older version of the environment? If I could insert a few lines of code into the top of the WikidPad source, to specify an OLDER version of wxPython, for example... I'd be able to switch to Linux from Windows. As it is now, there were breaking changes in wxPython (likely due to the culture of breaking working code extant in Python) which result in WikidPad being broken. It seems to me that if the Python community continues in this direction, nothing will work more than 3 months after it's last github commit. [edit/append] No, I'm not sure it's wxPython and not wxWindows that is the issue. I'll have to stuff my Linux boot SSD in, and then try to build WikidPad again to know for sure (it's been too long) I didn't write WikidPad, it seems to have been last maintained about 2012, but I use it for my notes, etc. I really like it, but the breakage on the Linux side is a show stopper. It's really unfortunate that Linux doesn't have a stable API like Win32, and forces dependence on source code. I'd consider installing an older version of Linux to force older python, wxPython, wxWindows, etc... and try to figure it from there... the last time I looked at it I got a wall of confusing errors, and couldn't patch it enough to get any functionality out of it.
- duskwuff 4y ago
  wxPython is a Python module. It isn't the same as Python itself. Don't blame the language for issues you're having with libraries written in it. On top of that, wxPython is a Python module which interfaces with an external library (wxWindows). Are you sure your problems are even with the Python module, and not the result of breaking changes in wxWindows itself?
- idealmedtech 4y ago
  pipenv or anaconda are the way to get reproducible python environments
- rerx 4y ago
  Sure, just put something like `wxPython < 4.2.0` into your `requirements.txt`. https://pip.pypa.io/en/stable/reference/requirements-file-format/ https://pip.pypa.io/en/stable/reference/requirements-file-fo...
TheAdamist 4y ago
This should have been called Python 4 if they are removing this many things in a breaking fashion. Is the disaster of the python 2->3 rollout preventing them from doing so? Either way, doesnt effect me, python 2.7 forever.
- deleted 4y ago
  [deleted]
mkoubaa 4y ago
Kudos to the python core devs. The core library is getting cleaner and more maintainable and the language is getting more performant and powerful for users. Long live the snake
- ngcc_hk 4y ago
  Ys especially if one read their update on the macro one knows maintainability is in their mind.
nyanpasu64 4y ago
The largely-unmaintained Python 3 port of syncthing-gtk already failed to start on Python 3.11 since it removed obsolete methods like bind_textdomain_codeset(): https://github.com/void-linux/void-packages/issues/40430 https://github.com/void-linux/void-packages/issues/40430 Though this project isn't exactly in the best shape, having prior bugs: https://salsa.debian.org/debian/syncthing-gtk/-/issues/2 https://salsa.debian.org/debian/syncthing-gtk/-/issues/2
khrtag 4y ago
longlivebooks 4y ago
Sad to see distutils going away. I have very old projects which use distutils for distribution. Wrote them in Python 2 days and they were ported easily to Python 3. But distutils going away is going to break them. I know setuptools is advanced and recommended but distutils worked fine for me and my users for so many years. It is going to be overhead for me to comb through all my projects and replace distutils with setuptools, test them and testing out packaging and distribution is quite a lot of work. I am growing unhappy with Python due to these breakages. Is there some other programming language whose maintainers don't break the "user space" like Python has been doing time and again?
- ketzu 4y ago
  Good news for you: > For projects still using distutils and cannot be updated to something else, the setuptools project can be installed: it still provides distutils. From: https://docs.python.org/dev/whatsnew/3.12.html#removed https://docs.python.org/dev/whatsnew/3.12.html#removed
- guggle 4y ago
  > other programming language whose maintainers don't break the "user space" I think Go qualifies here. (but it's still much younger than Python).
- rwmj 4y ago
  A warning that while there's something called sysconfig that replaces distutils.sysconfig, it is not compatible: https://github.com/libguestfs/libguestfs/commit/26940f64a740676103b0ee49bf0ca5ac4e297841 https://github.com/libguestfs/libguestfs/commit/26940f64a740...
- freedomben 4y ago
  I've been pretty happy with Ruby. I don't ever recall changing my ruby scripts for a new release (whereas with Python it's been many times). Rails is a different story although rails is not ruby. Ruby is similar enough to python that most pythonistas can already read it, so learning effort is mainly just the API differences.
mindwok 4y ago
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.
- rochak 4y ago
  Except for when it comes to packaging and distribution. That is still a nightmare for newbies.
  - davidktr 4y ago
    Agreed, but Poetry works wonderfully if the features are sufficient for your use case.
    - nomel 4y ago
      Sure, but wait until you see what next year brings us!
      - rochak 4y ago
        Umm, I didn’t have a great experience with Poetry. For starters, I wanted to create a separate virtual env to install Poetry in and have Poetry install the project’s dependencies in a separate virtual env. There was simply no way to do that and I didn’t wanna install Poetry globally on my machine. I also didn’t wanna use docker just for this, so I realized that Poetry could just not be for me.
        mindwok 4y ago
        This isn’t a poetry problem. Use pipenv for this. It’s pip but uses separate venvs to install packages. Pipenv install poetry will do exactly what you want I think.
Kinrany 4y ago
I'm curious if there's anything preventing them from switching to semver.
- mixmastamyk 4y ago
  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.
  - leadingthenet 4y ago
    Have you been reading the same comments as I have in this thread? It's all a bit nuts if you ask me.
Macha 4y ago
If we're going to be making backwards incompatible changes to unittest, it'd be nice to introduce PEP8-compatible names, deprecate the old ones, and remove then in 3.20 or something. (I know there's pytest and nosetests, but especially when teaching people, it's nice to use what's in the standard library and unittest sticks out for having things named differently)
- miohtama 4y ago
  Logging is another module that is non PEP8. Would be nice to clean there up in some point to increase consistency.
  - Redoubts 4y ago
    or even just getting rid of sprintf formatting.
- masklinn 4y ago
  > I know there's pytest and nosetests, but especially when teaching people, it's nice to use what's in the standard library and unittest sticks out for having things named differently You’re just crippling them for no reason.
- jonpalmisc 4y ago
  yes, please! Very minor issue indeed, but this kind of cruft adds up and I'd love to see it fixed.
hopfenspergerj 4y ago
Their suggested replacement for smtpd is a package that hasn’t been updated in almost two years.
- LudwigNagasena 4y ago
  smtpd barely had a meaningful commit since 2014.
nibbleshifter 4y ago
I see telnetlib is on the way out in 3.13 or so, which means a lot of pointless busywork in my future. Its a super useful module for a lot of tasks. The suggested replacements either are asyncio based (which means whole ass rewrites as asyncio is really fucking opinionated), or are excessively restrictive in some stupid way. "Infosec" at work tend to raise a ruckus when their scans detect "older" versions of Python on machines too, so virtualenv'ing to pin versions or similar is often not the most practical in prod without getting an exception.
- deleted 4y ago
  [deleted]
- Someone 4y ago
  I would expect them to move telnetlib to a separate, unsupported repo that you can then import. Even if they don’t, from a cursory view, it seems it’s a pure python library (https://github.com/python/cpython/blob/main/Lib/telnetlib.py https://github.com/python/cpython/blob/main/Lib/telnetlib.py). If so, can’t you copy the current code into your project? You would take on the burden of supporting it, but looking at https://github.com/python/cpython/commits/main/Lib/telnetlib.py https://github.com/python/cpython/commits/main/Lib/telnetlib..., that doesn’t seem to be much of a burden.
  - manfre 4y ago
    PEP-0594 lists the deprecated packages and any potential replacements. https://peps.python.org/pep-0594/#telnetlib https://peps.python.org/pep-0594/#telnetlib
- jacob019 4y ago
  You should be able to repackage it as a module.
  - noobermin 4y ago
    That's what I'm thinking, someone could always throw it up on pypi
brodouevencode 4y ago
> Support for the Linux perf profiler to report Python function names in traces. hidden gem
wodenokoto 4y ago
Speaking of standard lib, today I was looking to do a sliding window over an iterator and ended up on the pairwise function in itertools that was added in 3.10. Seems like such a wasted opportunity, to add a sliding window for n=2, and then in the documentation add a recipe for a sliding window function for any n.
- talideon 4y ago
  There are a lot of things like this in the boltons library: https://boltons.readthedocs.io/en/latest/iterutils.html#boltons.iterutils.windowed_iter https://boltons.readthedocs.io/en/latest/iterutils.html#bolt... It's nice to not have to depend on anything external, but boltons is something I just treat as an expanded part of the standard library.
est 4y ago
wait, since when python.org has a discuss subdomain? And it's running Discourse which is built on RoR? What the...
- duckmysick 4y ago
  Not sure how the Not Invented Here syndrome would help in this case. Besides, a few years ago they moved from Mercurial to Git(Hub).
- jwilk 4y ago
  Since September 2018 at least: https://discuss.python.org/t/welcome-to-discourse-say-hi/8 https://discuss.python.org/t/welcome-to-discourse-say-hi/8
- int_19h 4y ago
  The Python community tends to favor pragmaticism over purity.
- Alifatisk 4y ago
  Why does it matter?
est 4y ago
> 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_version A bit labor for my code but OK.
- masklinn 4y ago
  Darn the smtpd thing is going to be annoying next time I try to debug a mail sender. It was super convenient. Shame they didn’t leave just that.
  - Luyt 4y ago
    I use that one too. An alternative might be https://aiosmtpd.readthedocs.io/en/latest/cli.html https://aiosmtpd.readthedocs.io/en/latest/cli.html
- remram 4y ago
  packaging.version.parse() might be the canonical replacement?
hyperman1 4y ago
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 ... are using reflection to mess with internals. As a result, there are still a lot of enterprise applications on JDK8 and JDK11, even if the security impact of this is bad and the fix should be easy. For a typical example: see https://github.com/x-stream/xstream/issues/101 https://github.com/x-stream/xstream/issues/101
- josephcsible 4y ago
  > 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.
  - hyperman1 4y ago
    Marking random hidden internals accessible doesn't mean a private API becomes public. setAccessible is a useful tool for debug access, or for when an annotation gives extra guarantees, or you can use it on code you have access to. 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.
wakeupcall 4y ago
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 swallow. The amount of small and large breakage I had ever since I started to use it for production work (v2.6 and onward) has been relentless. Small and large breakages requiring constant retooling and reworking. Minor release? Yeah, still breaks just as much as a major one. pyenv doesn't help when you dependencies need to be updated, and the updates do not support the lower versions you wanted to use anyway. Containerizing everything is a not a solution for a project is expected to be supported for years so the real way forward is to fix it, again, and again, and again. My experience is that every 6 months there _will_ be work just to fix bitrotting. A one year old python project will hardly even run unless it's using the stdlib only. By comparison, I never experienced such churn with perl.
- forgotmypw17 4y ago
  This is the top reason I chose Perl for my project. Literally every time I try to use someone else's Python code from GitHub I run into this crap. I wanted my project to be easy to install and run, so I chose Perl.
  - jjgreen 4y ago
    I have had Perl scripts which I've not used for 15 years, run them expecting to need to fix something, but nothing needed ...
    - somat 4y ago
      The really nice part of sticking with python2 is that it is now a a stable interface. just like perl 5. only half joking.
      - forgotmypw17 4y ago
yoyohello13 4y ago
Cue the bevy of devs complaining their mission critical script, using features deprecated a decade ago, will no longer work.
c7b 4y ago
Is there any model or rationale behind introducing breaking changes in a minor release? What are the version numbers good for if not to indicate how important the changes are?
- kurante 4y ago
  Python has never followed semver. It's saner to treat minor releases as semver-major, and patches as semver-minor.
vkaku 4y ago
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.
- duskwuff 4y ago
  > Anyone care to comment on what they are using for receiving emails in Python? 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 https://aiosmtpd.readthedocs.io/en/latest/migrating.html
  - BurnGpuBurn 4y ago
    Aiosmtpd is great. A simple script to send all received mails to something like slack is demonstrated here: https://github.com/ont/slacker https://github.com/ont/slacker
ngcc_hk 4y ago
Talking about depreciated item. There are a lot of pyenv in the discussion. And even suggest it is to augment venv. But is that depreciated is since 3.6? “Deprecated since version 3.6: pyvenv was the recommended tool for creating virtual environments for Python 3.3 and 3.4, and is deprecated in Python 3.6.” Version is a nightmare btw. I have Conda just installed but sometimes the python is not the same as python3, one to 3.9 and one to 3.10. And unless you know the difference of pip3, pip and python -m pip (and not pip3…). Using venv then somehow the script Kivy switch it out and fall to python 3.9. Where is it? And then it fail as there is no python in my macOS but just python3. Struggle whole night on how to fix the bash alias and fail then use symbolic link. Just a “user” guys. Do not confuse me please. “ There should be one-- and preferably only one --obvious way to do it.” sigh.
- int_19h 4y ago
  venv is not deprecated - it's still the standard way to create new environments in Python. pyvenv, which was removed in Python 3.8, was a wrapper script around venv. The same functionality today is invoked via `python3 -m venv`.
pyuser583 4y ago
One thing that’s ticked me off is Python has been expanding the standard library. That’s a pain when you already are using libs that imitate the “new” behavior. Either the new tools are less good, or they destroy development in the existing tools. Twisted was, and is, a really cool framework. Unfortunately, it’s doomed. There were a ton of really good datetime utilities before … datetime. Oh well. Complain complain.
- mixmastamyk 4y ago
  I don’t think datetime is a good example, been around for a long time. Dataclasses might be one.

264 points by BerislavLopac 4y ago

This is enough for me to swear off python for any long-lived or production system. I am tired of this kind of endless incompatibility. It has fractured the ecosystem sufficiently that things break all the time when trying to use any non-trivial set of dependencies. Maybe the developers will stop this crap with Python 4. It’s the next Perl 6!

DougBTX 4y ago

Breaking changes in Python releases are nothing new, that’s why none of my Python projects are using the latest version :shrug:

OJFord 4y ago
The title is referencing this line (not TFA's actual title): > In the unittest module, a number of long deprecated methods and classes were removed. (They had been deprecated since Python 3.1 or 3.2). I doubt your projects are using 3.1 or 3.2 (or older, except perhaps 2.7, but then you wouldn't care that 3.12 was removing something deprecated vs 3.11 which has it)?
- janzer 4y ago
  There's quite a bit more than just the unittest removals https://docs.python.org/dev/whatsnew/3.12.html#removed https://docs.python.org/dev/whatsnew/3.12.html#removed An example of a more recent deprecation is the 'distutils' module which was deprecated in 3.10.
  - duskwuff 4y ago
    > An example of a more recent deprecation is the 'distutils' module which was deprecated in 3.10. distutils was functionally deprecated long before that. Even the Python 2.7 documentation (released in 2010!) recommended that users avoid distutils and use setuptools instead: https://docs.python.org/2.7/library/distutils.html https://docs.python.org/2.7/library/distutils.html
    - d1l 4y ago
      Isn't setuptools deprecated now too or on the chopping block?
      - eesmith 4y ago
        I believe setuptools is more frowned upon - in favor of PEP 517/PEP 518 tools - than deprecated. Last I checked, there was no good way to package hand-written Python/C extensions than setuptools, but that was a couple of years ago. In any case, there's a large installed-based of setuptools-based projects making it hard to get rid of.
- PurpleRamen 4y ago
  Deprecated does not mean removed. They are still there, working fine, having no big reason to change them. I know it, as I just checked my and my workplaces code, and there are several usages of deprecated code. And we are on 3.9/3.10.
  - samus 4y ago
    Merriam Webster lists the following relevant meanings for "deprecated": > to express disapproval of > to withdraw official support for or discourage the use of (something, such as a software product) in favor of a newer or better alternative In other words, deprecated is a strong signal that one should strive to migrate from items marked as such.
    - PurpleRamen 4y ago
      So what? As long as it works, don't change it. This parts are deprecated since up to nearly a decade (Python 3.2 was released February 20th, 2011). And they will work for some more years. Some have not even a working replacement yet. Investing now in changing old code just to be compatible to a not even released version, is a bit pointless if you have more important work on the list.
      - samus 4y ago
        Python 2 was supported for way longer than initially announced. Distutils as well. Maybe deprecated is not a strong enough signal because many projects hesitate to cut stuff loose that they deprecated because of the community backslash. Sometimes things have to be deprecated, but the community will never get around to adapt to that if they stick around forever. Compared to that, Java still carries some deprecated items around. But with Java 9, deprecation for removal was introduced, which is a strong signal that stuff will be gone in two releases. Kubernetes has a strict deprecation policy as well, such that skipping more than two releases is asking for trouble.
  - sigzero 4y ago
    Except the notice is about "removing deprecated modules"? Deprecation usually means "These are going away at some point. Be aware.".
- adrian_b 4y ago
  I do not know what is wrong with Python, because I use it only occasionally, for short programs that do not use obscure features. Nevertheless, there is no doubt that it is the worst software project that I have ever seen, during several decades, from the point of view of keeping compatibility between versions. For other programs, I may happen to need to have installed 2 versions, or maybe 3 versions, at most, in order to be able to use other programs that are compatible only with certain versions. On the other hand, for Python, during many, many years, I have been forced to keep installed all the time around 7 or 8 versions, to keep happy many other programs that claim to be compatible only with certain Python versions (and not also with any newer versions; some programs are even compatible only with a list of non-consecutive versions). Building from source any program that depends on Python may frequently require various temporary configuration modifications, to ensure that the program is built only for the Python versions with which it is compatible.
  - drunkpotato 4y ago
    I will say this, I love python, and I hate python the way only someone who loves it can. I think everything you said is accurate. I love writing Python code. I love its standard library and many third party libraries. But I loathe Python’s dependency management, and Python version upgrades are sometimes a huge pain. There are tools to help with this (pyenv or I am fond of asdf for python versions; poetry or pipenv for isolating package dependencies), but they only partially solve the problems and introduce new ones.
rightbyte 4y ago
The move to web based apps or connected in general was a genius move by the programming community. Now there will be an endless churn to keep programs up to date for "security reasons" and that cost money. We can even pull the plug on programs nowadays to the give the users the very best experience! Otherwise the lusers might have felt satisfied with what they have.
- nicoburns 4y ago
  You say that, but the web platform rarely if ever removes features in this way. My web code from 15 years ago works the same as it always did.
  - rightbyte 4y ago
    Obviously you chose the wrong framework or even worse - none at all. Ye I am whining but only half joking. Breaking backwards compatibility ruins my mood. And Python are getting way to much slack for what they have been doing to the users. People wanting to stick to 2.7 are ridiculed and soon the software security police will start arresting offenders.
    - samus 4y ago
      If people that want to stick to 2.7 can find a vendor that supplies them security patches, then there is no problem.
    - senko 4y ago
      I recently upgraded a Python 2 + Django 1.x project with no tests to Python 3 and latest Django. Using 2to3, the most trouble I had were db migrations, which I just squashed. The rest were ferreting out str() problems that 2to3 didn't find (eg. redis package happily taking strings but returning bytes by default), Django regexp url changes, and trivial stuff like that. It took a couple of days work. I also wanted to upgrade the frontend part (webpack build of Vue). I stopped after a few hours od going nowhere and am still apprehensive of approaching that particular thing.
- 4y ago

wirrbel 4y ago

https://docs.python.org/dev/whatsnew/3.12.html https://docs.python.org/dev/whatsnew/3.12.html For a lot more info on removals

eesmith 4y ago
> Removed many old deprecated unittest features ... > You can use https://github.com/isidentical/teyit https://github.com/isidentical/teyit to automatically modernise your unit tests. I tried out teyit when it was a "Show HN" 10 months ago (at https://news.ycombinator.com/item?id=29948813 https://news.ycombinator.com/item?id=29948813 ). It not only pointed out places where I was using a deprecated alias, but also fixed a few places where I was using the API poorly (using "assertTrue(a binop b)" instead of "assertBinOp(a, b)". I recommend it.
- toyg 4y ago
  I can't comment on the quality of the tool, I just don't like this attitude of "just use this tool we don't support, hosted on some platform we don't control, which might disappear tomorrow". Back in the day, this tool would have been shipped (and supported) with stdlib, or at least be frozen somewhere "official".
  - samus 4y ago
    That tool is not a permanent addition to the list of dependencies, but for a single migration effort. As such, it is unnecessary to include it in the standard library.
    - toyg 4y ago
      It should still be hosted somewhere that won't disappear tomorrow if GH goes bust or starts packing malware.
      - eesmith 4y ago
        It's also on PyPI. https://pypi.org/project/teyit/ https://pypi.org/project/teyit/ .

JonathanBeuys 4y ago

The changes seem to be in modules. What is the relation between a new Python version and changes in modules? Are some modules considered to be part of the language?

BiteCode_dev 4y ago
The stdlib is linked to the version of the language, yes.
- dividedbyzero 4y ago
  I wonder if there are languages (that have a stdlib) where that isn't the case
  - ZiiS 4y ago
    The c stdlib is more tightly coupled to the OS then any particular Compiler; and is not changed when you select a particular dialect (though the language standard dose specify what stdlib must support).
OJFord 4y ago
They're in the standard library, like `std` or (ish) Node API, etc.
qsort 4y ago
Those modules are parts of the standard library. As far as CPython is concerned, most of those modules are implemented in C, and therefore for practical purposes part of the interpreter itself. > How can a language be released? If we really want to be pedantic, a new version of the language spec can be released. Translated to C++ terms, this is like if the ISO committee approved a change to the stl in the new standard.

imurray 4y ago

While it's been coming for a long time, it's still frustrating to see the cgi module go. It's going to create a load of busy work to rewrite some low-traffic scripts. Modules being removed [edit: in 3.13]: https://docs.python.org/dev/whatsnew/3.12.html#pending-removal-in-python-3-13 https://docs.python.org/dev/whatsnew/3.12.html#pending-remov... Updating CGI scripts will be a bit fiddly: https://peps.python.org/pep-0594/#cgi https://peps.python.org/pep-0594/#cgi

jwilk 4y ago
You linked to Python 3.13 removals. Python 3.12 removals are here: https://docs.python.org/dev/whatsnew/3.12.html#removed https://docs.python.org/dev/whatsnew/3.12.html#removed
- imurray 4y ago
  Thanks. I did ctrl-f cgi as I knew its removal was coming and missed the heading. So one more point release of grace, but it's still coming soon.
tyingq 4y ago
There is CGIHandler that ships with python. Not many examples that are simple, so... #!/usr/bin/env python from wsgiref.handlers import CGIHandler def app(environ, start_response): start_response('200 OK', [('Content-Type', 'text/html')]) return [ b"<html><head><title>foo</title></head><body>bar</body></html>" ] if __name__ == '__main__': CGIHandler().run(app)
- imurray 4y ago
  Thank you!
sigzero 4y ago
Just copy out cgi.py and use it as a module. https://github.com/python/cpython/blob/3.11/Lib/cgi.py https://github.com/python/cpython/blob/3.11/Lib/cgi.py

jeffrallen 4y ago

Great, so now not only Python will be incompatible with itself, but also incompatible with itself even if you use Python 3. Sigh.

anakaine 4y ago
Or, the glass half full view of the world suggests that low usage high barrier to maintenance module deprecation increases overall long term improvements and compatibility at the cost of small, planned, notified, short term inconvenience.
- dbsmith83 4y ago
  I think you're missing the point. Nothing is wrong with deprecation, but it should be done properly. Ideally, breaking changes should correspond to a major version increase
drexlspivey 4y ago
You should sign up to maintain those ancient modules
- xigoi 4y ago
  Why do they need to be maintained? Just leave them as is.
  - ciupicri 4y ago
    Because supposedly people will report bugs for them and someone will need to fix them.
    - xigoi 4y ago
      “Sorry, we don't fix bugs in deprecated code. Closed.”
      - 4y ago

Aachen 4y ago

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 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 decision at this point is a good one.

martopix 4y ago
Perhaps after the big mess of the backwards incompatibilty of 3.x vs 2.x, they are erring on the side of caution now.
- leadingthenet 4y ago
  Can't blame them looking at some of the responses in this very comment section.

tbran 4y ago

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 https://github.com/pyenv/pyenv

Already__Taken 4y ago
Not really windows, WSL. There's windows fork recommended. Classic python splitting the ecosystem up. Why something like this isn't in go or rust that's actually cross platform capable just seems like excess effort.
- Spivak 4y ago
  Because thanks to WSL the lingua franca of scripting languages is bash and that’s how pyenv started. Rewriting when it works fine on Windows and every dev I know uses WSL anyway is excess effort. Hell, the fork could have used Go or whatever too but it went with a bunch of .bat scripts.
  - 0cf8612b2e1e 4y ago
    Hello from corporate America where WSL is most certainly not standard and will require a virgin sacrifice if you want to get it approved by IT. Which is to say, no pyenv is not an option for everyone.
    - ihaveajob 4y ago
      Indeed, I recently worked on a fairly simple deployment for a state government agency. When I described the process to their IT staff and mentioned that we prefer using WSL, they looked at me like I had grown 2 heads.
    - int_19h 4y ago
      Even aside from that, WSL is only useful if you are writing code that will run on Linux at the end of the day. This is usually true for web apps, but that's not the only thing people write in Python. Libraries, in particular, need to be able to target Windows directly.

mikewarot 4y ago

Is there a standard way a Python script can ask for an older version of the environment? If I could insert a few lines of code into the top of the WikidPad source, to specify an OLDER version of wxPython, for example... I'd be able to switch to Linux from Windows. As it is now, there were breaking changes in wxPython (likely due to the culture of breaking working code extant in Python) which result in WikidPad being broken. It seems to me that if the Python community continues in this direction, nothing will work more than 3 months after it's last github commit. [edit/append] No, I'm not sure it's wxPython and not wxWindows that is the issue. I'll have to stuff my Linux boot SSD in, and then try to build WikidPad again to know for sure (it's been too long) I didn't write WikidPad, it seems to have been last maintained about 2012, but I use it for my notes, etc. I really like it, but the breakage on the Linux side is a show stopper. It's really unfortunate that Linux doesn't have a stable API like Win32, and forces dependence on source code. I'd consider installing an older version of Linux to force older python, wxPython, wxWindows, etc... and try to figure it from there... the last time I looked at it I got a wall of confusing errors, and couldn't patch it enough to get any functionality out of it.

duskwuff 4y ago
wxPython is a Python module. It isn't the same as Python itself. Don't blame the language for issues you're having with libraries written in it. On top of that, wxPython is a Python module which interfaces with an external library (wxWindows). Are you sure your problems are even with the Python module, and not the result of breaking changes in wxWindows itself?
idealmedtech 4y ago
pipenv or anaconda are the way to get reproducible python environments
rerx 4y ago
Sure, just put something like `wxPython < 4.2.0` into your `requirements.txt`. https://pip.pypa.io/en/stable/reference/requirements-file-format/ https://pip.pypa.io/en/stable/reference/requirements-file-fo...

TheAdamist 4y ago

This should have been called Python 4 if they are removing this many things in a breaking fashion. Is the disaster of the python 2->3 rollout preventing them from doing so? Either way, doesnt effect me, python 2.7 forever.

deleted 4y ago
[deleted]

mkoubaa 4y ago

Kudos to the python core devs. The core library is getting cleaner and more maintainable and the language is getting more performant and powerful for users. Long live the snake

ngcc_hk 4y ago
Ys especially if one read their update on the macro one knows maintainability is in their mind.

nyanpasu64 4y ago

The largely-unmaintained Python 3 port of syncthing-gtk already failed to start on Python 3.11 since it removed obsolete methods like bind_textdomain_codeset(): https://github.com/void-linux/void-packages/issues/40430 https://github.com/void-linux/void-packages/issues/40430 Though this project isn't exactly in the best shape, having prior bugs: https://salsa.debian.org/debian/syncthing-gtk/-/issues/2 https://salsa.debian.org/debian/syncthing-gtk/-/issues/2

khrtag 4y ago

longlivebooks 4y ago

Sad to see distutils going away. I have very old projects which use distutils for distribution. Wrote them in Python 2 days and they were ported easily to Python 3. But distutils going away is going to break them. I know setuptools is advanced and recommended but distutils worked fine for me and my users for so many years. It is going to be overhead for me to comb through all my projects and replace distutils with setuptools, test them and testing out packaging and distribution is quite a lot of work. I am growing unhappy with Python due to these breakages. Is there some other programming language whose maintainers don't break the "user space" like Python has been doing time and again?

ketzu 4y ago
Good news for you: > For projects still using distutils and cannot be updated to something else, the setuptools project can be installed: it still provides distutils. From: https://docs.python.org/dev/whatsnew/3.12.html#removed https://docs.python.org/dev/whatsnew/3.12.html#removed
guggle 4y ago
> other programming language whose maintainers don't break the "user space" I think Go qualifies here. (but it's still much younger than Python).
rwmj 4y ago
A warning that while there's something called sysconfig that replaces distutils.sysconfig, it is not compatible: https://github.com/libguestfs/libguestfs/commit/26940f64a740676103b0ee49bf0ca5ac4e297841 https://github.com/libguestfs/libguestfs/commit/26940f64a740...
freedomben 4y ago
I've been pretty happy with Ruby. I don't ever recall changing my ruby scripts for a new release (whereas with Python it's been many times). Rails is a different story although rails is not ruby. Ruby is similar enough to python that most pythonistas can already read it, so learning effort is mainly just the API differences.

mindwok 4y ago

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.

rochak 4y ago
Except for when it comes to packaging and distribution. That is still a nightmare for newbies.
- davidktr 4y ago
  Agreed, but Poetry works wonderfully if the features are sufficient for your use case.
  - nomel 4y ago
    Sure, but wait until you see what next year brings us!
    - rochak 4y ago
      Umm, I didn’t have a great experience with Poetry. For starters, I wanted to create a separate virtual env to install Poetry in and have Poetry install the project’s dependencies in a separate virtual env. There was simply no way to do that and I didn’t wanna install Poetry globally on my machine. I also didn’t wanna use docker just for this, so I realized that Poetry could just not be for me.
      - mindwok 4y ago
        This isn’t a poetry problem. Use pipenv for this. It’s pip but uses separate venvs to install packages. Pipenv install poetry will do exactly what you want I think.

Kinrany 4y ago

I'm curious if there's anything preventing them from switching to semver.

mixmastamyk 4y ago
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.
- leadingthenet 4y ago
  Have you been reading the same comments as I have in this thread? It's all a bit nuts if you ask me.

Macha 4y ago

If we're going to be making backwards incompatible changes to unittest, it'd be nice to introduce PEP8-compatible names, deprecate the old ones, and remove then in 3.20 or something. (I know there's pytest and nosetests, but especially when teaching people, it's nice to use what's in the standard library and unittest sticks out for having things named differently)

miohtama 4y ago
Logging is another module that is non PEP8. Would be nice to clean there up in some point to increase consistency.
- Redoubts 4y ago
  or even just getting rid of sprintf formatting.
masklinn 4y ago
> I know there's pytest and nosetests, but especially when teaching people, it's nice to use what's in the standard library and unittest sticks out for having things named differently You’re just crippling them for no reason.
jonpalmisc 4y ago
yes, please! Very minor issue indeed, but this kind of cruft adds up and I'd love to see it fixed.

hopfenspergerj 4y ago

Their suggested replacement for smtpd is a package that hasn’t been updated in almost two years.

LudwigNagasena 4y ago
smtpd barely had a meaningful commit since 2014.

nibbleshifter 4y ago

I see telnetlib is on the way out in 3.13 or so, which means a lot of pointless busywork in my future. Its a super useful module for a lot of tasks. The suggested replacements either are asyncio based (which means whole ass rewrites as asyncio is really fucking opinionated), or are excessively restrictive in some stupid way. "Infosec" at work tend to raise a ruckus when their scans detect "older" versions of Python on machines too, so virtualenv'ing to pin versions or similar is often not the most practical in prod without getting an exception.

deleted 4y ago
[deleted]
Someone 4y ago
I would expect them to move telnetlib to a separate, unsupported repo that you can then import. Even if they don’t, from a cursory view, it seems it’s a pure python library (https://github.com/python/cpython/blob/main/Lib/telnetlib.py https://github.com/python/cpython/blob/main/Lib/telnetlib.py). If so, can’t you copy the current code into your project? You would take on the burden of supporting it, but looking at https://github.com/python/cpython/commits/main/Lib/telnetlib.py https://github.com/python/cpython/commits/main/Lib/telnetlib..., that doesn’t seem to be much of a burden.
- manfre 4y ago
  PEP-0594 lists the deprecated packages and any potential replacements. https://peps.python.org/pep-0594/#telnetlib https://peps.python.org/pep-0594/#telnetlib
jacob019 4y ago
You should be able to repackage it as a module.
- noobermin 4y ago
  That's what I'm thinking, someone could always throw it up on pypi

brodouevencode 4y ago

> Support for the Linux perf profiler to report Python function names in traces. hidden gem

wodenokoto 4y ago

Speaking of standard lib, today I was looking to do a sliding window over an iterator and ended up on the pairwise function in itertools that was added in 3.10. Seems like such a wasted opportunity, to add a sliding window for n=2, and then in the documentation add a recipe for a sliding window function for any n.

talideon 4y ago
There are a lot of things like this in the boltons library: https://boltons.readthedocs.io/en/latest/iterutils.html#boltons.iterutils.windowed_iter https://boltons.readthedocs.io/en/latest/iterutils.html#bolt... It's nice to not have to depend on anything external, but boltons is something I just treat as an expanded part of the standard library.

est 4y ago

wait, since when python.org has a discuss subdomain? And it's running Discourse which is built on RoR? What the...

duckmysick 4y ago
Not sure how the Not Invented Here syndrome would help in this case. Besides, a few years ago they moved from Mercurial to Git(Hub).
jwilk 4y ago
Since September 2018 at least: https://discuss.python.org/t/welcome-to-discourse-say-hi/8 https://discuss.python.org/t/welcome-to-discourse-say-hi/8
int_19h 4y ago
The Python community tends to favor pragmaticism over purity.
Alifatisk 4y ago
Why does it matter?

est 4y ago

> 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_version A bit labor for my code but OK.

masklinn 4y ago
Darn the smtpd thing is going to be annoying next time I try to debug a mail sender. It was super convenient. Shame they didn’t leave just that.
- Luyt 4y ago
  I use that one too. An alternative might be https://aiosmtpd.readthedocs.io/en/latest/cli.html https://aiosmtpd.readthedocs.io/en/latest/cli.html
remram 4y ago
packaging.version.parse() might be the canonical replacement?

hyperman1 4y ago

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 ... are using reflection to mess with internals. As a result, there are still a lot of enterprise applications on JDK8 and JDK11, even if the security impact of this is bad and the fix should be easy. For a typical example: see https://github.com/x-stream/xstream/issues/101 https://github.com/x-stream/xstream/issues/101

josephcsible 4y ago
> 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.
- hyperman1 4y ago
  Marking random hidden internals accessible doesn't mean a private API becomes public. setAccessible is a useful tool for debug access, or for when an annotation gives extra guarantees, or you can use it on code you have access to. 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.

wakeupcall 4y ago

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 swallow. The amount of small and large breakage I had ever since I started to use it for production work (v2.6 and onward) has been relentless. Small and large breakages requiring constant retooling and reworking. Minor release? Yeah, still breaks just as much as a major one. pyenv doesn't help when you dependencies need to be updated, and the updates do not support the lower versions you wanted to use anyway. Containerizing everything is a not a solution for a project is expected to be supported for years so the real way forward is to fix it, again, and again, and again. My experience is that every 6 months there _will_ be work just to fix bitrotting. A one year old python project will hardly even run unless it's using the stdlib only. By comparison, I never experienced such churn with perl.

forgotmypw17 4y ago
This is the top reason I chose Perl for my project. Literally every time I try to use someone else's Python code from GitHub I run into this crap. I wanted my project to be easy to install and run, so I chose Perl.
- jjgreen 4y ago
  I have had Perl scripts which I've not used for 15 years, run them expecting to need to fix something, but nothing needed ...
  - somat 4y ago
    The really nice part of sticking with python2 is that it is now a a stable interface. just like perl 5. only half joking.
    - forgotmypw17 4y ago

yoyohello13 4y ago

Cue the bevy of devs complaining their mission critical script, using features deprecated a decade ago, will no longer work.

c7b 4y ago

Is there any model or rationale behind introducing breaking changes in a minor release? What are the version numbers good for if not to indicate how important the changes are?

kurante 4y ago
Python has never followed semver. It's saner to treat minor releases as semver-major, and patches as semver-minor.

vkaku 4y ago

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.

duskwuff 4y ago
> Anyone care to comment on what they are using for receiving emails in Python? 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 https://aiosmtpd.readthedocs.io/en/latest/migrating.html
- BurnGpuBurn 4y ago
  Aiosmtpd is great. A simple script to send all received mails to something like slack is demonstrated here: https://github.com/ont/slacker https://github.com/ont/slacker

ngcc_hk 4y ago

Talking about depreciated item. There are a lot of pyenv in the discussion. And even suggest it is to augment venv. But is that depreciated is since 3.6? “Deprecated since version 3.6: pyvenv was the recommended tool for creating virtual environments for Python 3.3 and 3.4, and is deprecated in Python 3.6.” Version is a nightmare btw. I have Conda just installed but sometimes the python is not the same as python3, one to 3.9 and one to 3.10. And unless you know the difference of pip3, pip and python -m pip (and not pip3…). Using venv then somehow the script Kivy switch it out and fall to python 3.9. Where is it? And then it fail as there is no python in my macOS but just python3. Struggle whole night on how to fix the bash alias and fail then use symbolic link. Just a “user” guys. Do not confuse me please. “ There should be one-- and preferably only one --obvious way to do it.” sigh.

int_19h 4y ago
venv is not deprecated - it's still the standard way to create new environments in Python. pyvenv, which was removed in Python 3.8, was a wrapper script around venv. The same functionality today is invoked via `python3 -m venv`.

pyuser583 4y ago

One thing that’s ticked me off is Python has been expanding the standard library. That’s a pain when you already are using libs that imitate the “new” behavior. Either the new tools are less good, or they destroy development in the existing tools. Twisted was, and is, a really cool framework. Unfortunately, it’s doomed. There were a ton of really good datetime utilities before … datetime. Oh well. Complain complain.

mixmastamyk 4y ago
I don’t think datetime is a good example, been around for a long time. Dataclasses might be one.