LWN: Comments on "Python discusses deprecations"

Python discusses deprecations

cpitrat — Mon, 03 Jan 2022 10:53:10 +0000

Especially when AoE (both 1 and 2) runs perfectly fine on wine.

Python discusses deprecations

flussence — Fri, 31 Dec 2021 01:31:04 +0000

I'm practising for a hypothetical career shift where I spend more time writing via the computer and less to it. :-)

Python discusses deprecations

bartoc — Fri, 24 Dec 2021 11:01:42 +0000

It also works very well on windows. Much better than perl5 or ruby (did you know mesonbuild has special checks because perl5 and ruby add broken toolchains to PATH on windows?). Python basically "just works", the binary distribution is "official" and almost every package also works, including ones that have C extensions. For people embedding it it's pretty easy to build on windows as well, and with msvc to boot (which historically has been important because mingw links against a C runtime that hasn't been updated since _1998_, recently mingw has grown support for linking against the ucrt, which is the "current" windows C runtime). It also has very good tooling support with the whole type annotations thing.

I'm sure the windows story for ruby and perl5 (and even bash, although that's harder as windows can't do fork() _or_ exec()) could be improved with some dedication and just ... clearing out the cobwebs, but there are a lot of cobwebs.

Despite the general shortcomings of windows as a platform a good percentage of developers need their software to run there

Python discusses deprecations

pebolle — Tue, 21 Dec 2021 00:19:04 +0000

> Perl's decline was more of a long-term cultural rot of slashdotter-style elitism from within than anything to do with Raku (which swung hard into the opposite problem, uncritically platforming awful people in official spaces in the illucid pursuit of SEO).

Sometimes I wish I could construct sentences like that. But most of the times I'm glad I can't.

Python discusses deprecations

flussence — Mon, 20 Dec 2021 21:10:55 +0000

PHP isn't getting this level of attention because everyone who took it seriously already got alert fatigue from it and gave up in the 2000s; those who had to deal with chasing half a dozen different mysql APIs while their recommended/deprecated state flapped every few months are well aware of how “stable” the language truly is.

Coincidentally: I tried running an old internal PHP 5 app on PHP 8.0 this month (not 8.1, because several pecl extensions it relies on are abandonware). It worked for a few page loads and then exploded, because a cache-control function suddenly noticed that the caller had been passing it an iso8601 string instead of an integer timestamp. Doesn't matter that every "best practice" the language had at the time was followed, nor does it matter that the codebase was fuzz-tested several times, this error went silently unnoticed for a decade and a half until PHP added real type checking.

The subject of PHP being an atrocious language where nothing works consistently has been thoroughly flogged to death at this point; nobody's complaining because nobody uses it any more or are too ashamed to admit that they do. It may not break backwards compatibility in the same way Python does, but that's only because it's about as thought out and sight-readable as a DNA sequence - and it's become a *cultural expectation* that things in it are just breaking constantly and inexplicably. At one point the core developers genuinely couldn't understand why they were in the news - for admitting they didn't run the language's test suite before cutting releases because it was too noisy.

I'm not going to write at length for the other examples but they aren't much better:

Shell scripts have entire online wikis and linting programs dedicated to how *not* to write them - none of which seem to get used on the code running on everyone's distros; Javascript has supplanted Old Unix as a de-facto open-in-marketing-only platform that's actually owned by competing predatory corporations; and Perl's decline was more of a long-term cultural rot of slashdotter-style elitism from within than anything to do with Raku (which swung hard into the opposite problem, uncritically platforming awful people in official spaces in the illucid pursuit of SEO).

Everything is in fact awful. You hold up the buildings that aren't on fire as role models while missing the point that they're already burned out.

Python discusses deprecations

geert — Mon, 20 Dec 2021 09:41:37 +0000

Looking at the recent activity on https://github.com/jbruchon/elks, there still is ;-)

Python discusses deprecations

Cyberax — Mon, 20 Dec 2021 06:00:40 +0000

There was ELKS (Embedded Linux Kernel Subset or something) that worked on 8086. It was an interesting project.

Python discusses deprecations

plugwash — Sun, 19 Dec 2021 23:09:17 +0000

Linux was a 32-bit OS from the start, so 16 bit Linux apps were never a thing (I don't know if there were ever any experimental 16 bit ports of Linux, but I'm pretty confident there was nothing that saw widespread use)

16 bit protected mode code (aka win16) can be run on an x86-64 system without emulation, MS simply couldn't be bothered doing the work to get the "WoW" and "WoW64" compatibility layers to work together. Wine on the other hand *does* support 16 bit code while running on a 64-bit system (though the wine process is 32-bit)

16 bit real mode code (aka DOS) on a 64-bit OS on the other hand does require either emulation or use of the virtualization features.

Python discusses deprecations

LyonJE — Thu, 16 Dec 2021 18:22:34 +0000

The danger is in making Python a niche system for the most enthusiastic, up-to-date, engaged, specialist dev community who are always running new versions on their home lab.

The world-at-large has huge volumes of older material that really does not need tweaking and updating and adjusting for the "latest" flavours, even as often as every year or two. I had enough of that pain with PHP breaking compatibility repeatedly for most of its lifetime.

I would be gravely disappointed to see Python shift away from a defensive, conservative, long-term stable approach in favour of a tiny percentage of the world's Python dev community wanting everything to be super clean and shiny.

This isn't critical functionality -- this is nomenclature and aesthetics, but which can break something that would otherwise be perfectly compatible and safe. Not every ".py" file is part of a sophisticated and/or big project -- there are millions of important short scripts, plug-ins, and all sorts.

I'm newish to Python, but not to software engineering, not by far :) So, my tuppence, anyway!

Je.

Python discusses deprecations

xyz — Wed, 15 Dec 2021 19:17:32 +0000

>Still… python popularity never ceases to amaze me: so many were burned by it — yet people still continue to use it… why?

Do you know any other language that has not burnt users one way or another?

> What does it have that other, more stable languages, doesn't have?

Very good modules/packages that you can use without reinventing the wheel.
It is a very nice language and it has a huge ecosystem.

Python discusses deprecations

anton — Wed, 15 Dec 2021 18:03:39 +0000

Linux has been more focused on source-code compatibility than binary compatibility

It seems to me that Linux (the kernel) focusses on binary compatibility for the most part. Given that it does not include a compiler, there is no way for it to provide source-code compatibility.

That said, the Linux developers committed digital vandalism on a.out binaries on the switch to Linux-5.1, based on the excuse that core dumping of running a.out binaries was broken and nobody volunteered to fix it. Given that many systems (mine included) have a core file size limit of 0, core dumping is not an important functionality, certainly much less important than running a binary. Siegfried Pammer heroically implemented a partial user-space solution for this problem, but it's surprisingly hard to actually do that and the result still does not work as well as the kernel did before Linux-5.1.

Python discusses deprecations

tbird20d — Tue, 14 Dec 2021 19:14:23 +0000

I've been doing a lot of Python2 to Python3 conversions lately, and it's news to me that the whole str-to-bytes thing is sorted out. It's the bane of my python experience now, and continues to be. I have to say that I now have a slight preference for Python2 programming (vs. Python3), because, due to it being abandonware, the Python developers will leave it the heck alone, and there's actually more hope my programs will require less maintenance to be able to run in the future than with Python3

Python discusses deprecations

rahulsundaram — Tue, 14 Dec 2021 09:26:04 +0000

> Still… python popularity never ceases to amaze me: so many were burned by it — yet people still continue to use it… why? What does it have that other, more stable languages, doesn't have?
> I guess that would remain mystery for the foreseeable future.

Languages don't thrive in a vacuum. There is a whole host of libraries that work very well and lots of components that you might want to work with provide language bindings and Python is among those that tend to come with good support (docs etc). The incompatibility was a hassle and I do strongly feel that it could have been handled better even if it the outcome after the changes were better code but the popularity itself isn't a mystery at all.

Python discusses deprecations

fenncruz — Tue, 14 Dec 2021 06:46:30 +0000

No scientists don't want constant churn. Your assuming they start from the point of having working code. What's more likely is your handed a piece of code from the last student and told to make it work. So you spend the first few months of a project working out which python version, what version of dependices, and what magic environment variables the previous person used but forgot to tell anyone about. Then you run the last persons project as a test and get different answers and have to go hunting again for that configuration you missed.

You think python itself is a mess? You've not seen python written by scientists, where you luckily if you (as the code author) get the same answer twice. But you would never know if you would because no on teaches about writing unit tests (or code testing in general).

Python discusses deprecations

anselm — Tue, 14 Dec 2021 01:13:09 +0000

And, of course, it's better to use some else than python because if you would make that mistake again then chances that you would be able to run the code which you would write today in year 2033 (exactly 12 years from today — same as the code we are discussing here) is practically zero.

That presumes that Python 12 years from now will be very different from Python today. But even Python today is not that different from Python 12 years ago. There were some important but backwards-incompatible cleanups but otherwise the language is still pretty much the same. Moving reasonably-written code forward really isn't rocket science, and can be at least partly automated. But if you wrote very bad Python code 12 years ago – like it seems the Wikipedia guy did – then you may have a bit of a problem. OTOH, who is to say what today's other fashionable programming languages will look like 12 years from now?

I've been writing Python code professionally for a lot longer than 12 years and I'm reasonably confident that the code I write today will still be working 12 years from now. The str-vs.-bytes thing which was the major new thing in 3.x was a bit of a hassle (albeit important) but that's sorted now. Even the introduction of major new language features like match (in 3.10) doesn't break existing code using match as a variable name, so the Python developers seem to have figured this out. Things are better now than they used to be, and are only likely to improve further as the language keeps maturing.

Python discusses deprecations

khim — Tue, 14 Dec 2021 00:35:52 +0000

> It never ceases to amaze me!

It's because for language developer backward compatibility is a pain, often an embarrassment, but for language users it's a boon… but language is developed by language developers, not by users.

Still… python popularity never ceases to amaze me: so many were burned by it — yet people still continue to use it… why? What does it have that other, more stable languages, doesn't have?

I guess that would remain mystery for the foreseeable future.

Python discusses deprecations

khim — Tue, 14 Dec 2021 00:19:58 +0000

> I suppose you could fix all of the above in refactoring, but IMHO it might be better to just do a ground-up rewrite at this point.

And, of course, it's better to use some else than python because if you would make that mistake again then chances that you would be able to run the code which you would write today in year 2033 (exactly 12 years from today — same as the code we are discussing here) is practically zero.

I sometimes wonder if that planned obsolescence is perceived as good thing in certain circles. E.g. scientists: because python is easily downloadable they can supply code to reviewers and and even safely publish it… but in 5-10 years when your work would become well-known nobody but you would be able to do work on it because your old, published, code wouldn't be compatible with then-current version of python and only you would have properly adjusted version of code.

Python discusses deprecations

khim — Tue, 14 Dec 2021 00:04:51 +0000

That's the most likely reason. Note that even pure 32-bit programs which use NtSetLdtEntries wouldn't work on Windows x64 whileas sys_modify_ldt works just fine on x86-64 Linux kernel.

Python discusses deprecations

nix — Mon, 13 Dec 2021 17:59:11 +0000

I thought it had been decided, but maybe I was hallucinating: I can't find any code for it or any sign of it anywhere.

Python discusses deprecations

pebolle — Mon, 13 Dec 2021 16:52:06 +0000

> Most recent status update I am aware of is https://gist.github.com/Grinnz/be5db6b1d54b22d8e21c975d68...

Thanks.

I stumbled on that too when looking into this this (Northern Hemisphere) summer. My impression was and is that Perl 7 petered out. We'll see.

Python discusses deprecations

rahulsundaram — Mon, 13 Dec 2021 16:45:41 +0000

> Has that ever materialized?

Most recent status update I am aware of is https://gist.github.com/Grinnz/be5db6b1d54b22d8e21c975d68...

Python discusses deprecations

pebolle — Mon, 13 Dec 2021 16:42:08 +0000

> Perl 7

Has that ever materialized?

> IMO, the story with Python was worse as a result.

Of course this is a subject one can debate forever (especially on the web). But I'd say Perl 6 promised more, took forever, split the developer community, and delivered a "sister" language (and a compiler and a VM that are only used for Perl 6). They even had to rename it to Raku because having Perl 5 en 6 simultaneously hurt both languages. So I'd say Perl took a pretty bad hit.

Anyhow, both Perl 5 and 6 and Python 2 and 3 ended up incompatible. It never ceases to amaze me!

Python discusses deprecations

pebolle — Mon, 13 Dec 2021 16:15:29 +0000

> After the usual pile of weird and impractical suggestions

I seem to remember that at one point some people suggested yet another split (i.e., a third version of Perl).

> it's converged on something reasonable: you get Perl 5 unless you say 'use 7'. i.e., the backward compatibility policy is unchanged,

I remember that too, and I also found it reasonable. But did anything actually happen? Has a decision been made to do a v7.0.0 instead of, say, v5.40.0? Nothing like that was mentioned on lwn.net.

Python discusses deprecations

rahulsundaram — Mon, 13 Dec 2021 15:06:30 +0000

> The python2 to python3 process was pretty embarrassing but perl5 to perl6 is a lesson of how not to do such things of a purity to behold. Did anything similar ever turned out worse?

Perl 6 and PHP 6 (https://lwn.net/Articles/379909/) didn't impact users as much because they stepped past that into Perl 7 and PHP 7. Python 3 however did have a major impact for users who had to do a difficult transition. IMO, the story with Python was worse as a result.

Python discusses deprecations

nix — Mon, 13 Dec 2021 14:50:55 +0000

> any hope of a future for perl5 is best described by the perl7 farce. (Did lwn.net ever cover that? It's hilarious.)

I dunno. After the usual pile of weird and impractical suggestions (because that's how development of almost anything *works*, it's just that this is in the open), it's converged on something reasonable: you get Perl 5 unless you say 'use 7'. i.e., the backward compatibility policy is unchanged, which means that you can expect everyone to upgrade to Perl 7 sooner or later, replacing Perl 5 completely, without worrying about things breaking or having to do massive audits of code nobody's looked at in twenty years and whose sole maintainer died of oxygen abuse ten years ago.

Python discusses deprecations

eru — Mon, 13 Dec 2021 13:06:32 +0000

I don't think anyone said it is. In my hacks, I used DOSBOX for the Windows version of the "compiler wrappers". One advantage of it is that it comes with its own MS-DOS emulation, no need to install a copy of MS-DOS or FreeDOS. Unfortunately I had to work around some bugs in it. Another problem is that DOSBOX is a GUI program, but I just wanted the outputs of the compiler to appear on stdout at the end, so the console window popping up for each compiler run was a nuisance, and hard to get rid off. Finally found a way to immediately move it somewhere off-screen before it opened.

Python discusses deprecations

raven667 — Mon, 13 Dec 2021 06:01:43 +0000

Funny enough I recently saw that someone made a new mouse driver for Win3.x supporting the VMWare-Tools mechanism for injecting mouse events, bypassing the emulated PS/2 support and resolving some of the issues with relative vs absolute "tablet" positioning when running in a VM.

https://github.com/NattyNarwhal/vmwmouse

Python discusses deprecations

nybble41 — Mon, 13 Dec 2021 03:42:57 +0000

> you almost may as well just install 16-bit windows in dosbox

I've tried it both ways, and I would say that it's easier to work with 16-bit apps running "rootless" via otvdm (even if the CPU is emulated) than inside a DOSBox frame running Windows 3.11. I never was able to get the emulated mouse working reliably, for example, though that probably had something to do with the fact that DOSBox was running on a remote system accessed via Remote Desktop, so it was turning relative mouse events into absolute "tablet" events and then back to mouse events. In any case, while the app did run in DOSBox it was basically unusable for my purpose. With otvdm all the inputs worked normally, the window size wasn't limited, and I could easily access files on both local and mapped network drives (albeit with truncated names).

Any modern 64-bit CPU should be fully capable of emulating the 16-bit environment the app was originally designed for at better than native speed, even without hardware support, so that isn't much of a handicap.

Python discusses deprecations

pebolle — Sun, 12 Dec 2021 23:42:04 +0000

> You won't see this with Perl, because it takes backwards compatibilty *very* seriously:

And somehow the people subscribing to this policy still managed to set in motion the breathtaking train wreck that perl6 turned out to be. By now no-one uses perl6 and any hope of a future for perl5 is best described by the perl7 farce. (Did lwn.net ever cover that? It's hilarious.)

The python2 to python3 process was pretty embarrassing but perl5 to perl6 is a lesson of how not to do such things of a purity to behold. Did anything similar ever turned out worse?

(For the record, I actually like perl5, but even I can see where it heading...)

Python discusses deprecations

pizza — Sun, 12 Dec 2021 13:34:27 +0000

> Why people still want to use Python? It should be clear at this point that breaking things is in the language DNA.

Python is the new Java. Except for the backwards-compatible part.

> I do not remember similar articles about JavaScript, PHP, Perl, Node, shell scripts.

You won't see this with Perl, because it takes backwards compatibilty *very* seriously:

'Requiring end-user programmers to change just a few language constructs, even language constructs which no well-educated developer would ever intentionally use is tantamount to saying "you should not upgrade to a new release of Perl unless you have 100% test coverage and can do a full manual audit of your codebase."'

"Historically, we've held ourselves to a far higher standard than backward-compatibility -- bugward-compatibility. Any accident of implementation or unintentional side-effect of running some bit of code has been considered to be a feature of the language to be defended with the same zeal as any other feature or functionality. No matter how frustrating these unintentional features may be to us as we continue to improve Perl, these unintentional features often deserve our protection. It is very important that existing software written in Perl continue to work correctly. If end-user developers have adopted a bug as a feature, we need to treat it as such."

(see https://perldoc.perl.org/perlpolicy)

Python discusses deprecations

Wol — Sun, 12 Dec 2021 12:58:24 +0000

And, in practice, quite often real loss, as the company gets flushed down the toilet when things go wrong.

Cheers,
Wol

Python discusses deprecations

fman — Sun, 12 Dec 2021 12:00:22 +0000

> Why people still want to use Python? It should be clear at this point that breaking things is in the language DNA.

Indeed! I don't care one bit about perceived advantages in wholesale replacements of stuff like asyncore.
What i *do* care about are (maybe years) old work being flushed down the toilet by some adolescent quest for perfection
and having to re-acquaint myself with the module in question for no apparent gain overall.

Python discusses deprecations

ibukanov — Sat, 11 Dec 2021 22:14:08 +0000

Why people still want to use Python? It should be clear at this point that breaking things is in the language DNA.

I do not remember similar articles about JavaScript, PHP, Perl, Node, shell scripts. Somehow those interpreted languages managed not to annoy users with breaking changes. Surely the first 3 tried some big incompatible changes like ES4, PHP 6, Perl 6. But those were either abandoned or forked into a separated language.

Python discusses deprecations

nix — Sat, 11 Dec 2021 15:49:08 +0000

> It may be possible to run 16-bit protected mode apps on a kernel in long mode, I'm not sure why windows can't do that.

The processor is capable of it (what doesn't work is real mode, "unreal" mode (i.e. real mode with nonstandard selectors), and v8086 mode). But it does take more work to implement this, mostly due to having to mess about with LDTs some more in ways you don't have to do if all you support is 32-bit protected mode programs. I can entirely believe that MS didn't want to do that.

Python discusses deprecations

bartoc — Sat, 11 Dec 2021 04:46:42 +0000

This appears to use a CPU emulator to actually execute the code, and at that point you almost may as well just install 16-bit windows in dosbox (those old versions of windows are available for free I think). WoW32 (and WoW16, on 32bit windows) actually execute the code directly on the processor, but once in long mode I don't think it's possible to use virtual 80386 mode anymore, so WoW16 no longer works on 64-bit windows. It may be possible to run 16-bit protected mode apps on a kernel in long mode, I'm not sure why windows can't do that.

By the time 64-bit windows came out I think straight emulation was sufficient to run 16-bit apps, and that's a much simpler approach as far as the kernel and userland are concerned.

Python discusses deprecations

NYKevin — Fri, 10 Dec 2021 04:35:41 +0000

> So much for even dreams of "the year of Linux on the desktop". So much for dreams of free software taking over.

That's capitalism.

> Such an attitude will even drive away geek users; there's at least one user commenting on this article pointing out this is why they're using Go instead of Python,

Exactly. Vote with your wallet. Don't complain about X failing to meet your needs when you could just use Y instead of X.

> comments on this thread have said that Python 2 was ANSI C and thus should still compile; surely the fact that ANSI C was stable and universal was part of the reason Python 2 was written in it.

Sounds to me like Guido was already practicing this even back then.

> At a more values-based level, this feels like digital vandalism.

Nothing has been destroyed, at least on the FOSS side of things. All of the code still exists, is still publicly accessible, and can still be used, if you can only get it to run. Characterizing that as "vandalism" is ridiculous. If you can't get the code to run, that's your problem. This is the social contract on which all FOSS code has been founded ever since the FSF stuck a "THERE IS NO WARRANTY" disclaimer on the GPL.

> where code has to be rewritten regularly, not because it wasn't good, but because people decided to make some arbitrary changes, where everyone has to learn everything anew on a regular basis.

Unfortunately, we live in a society. If those changes were completely worthless, they would hopefully not be made. In most cases, they at least accomplish *something,* even if you personally think that thing is not worthwhile. You're always free to fork and revert, if you really think it's bad enough.

Python discusses deprecations

dvdeug — Fri, 10 Dec 2021 03:32:02 +0000

> The average user does not know how to operate a compiler, so from their perspective, source compatibility is entirely worthless.

Which is a reason the average user doesn't use Linux. In any case, it's not entirely worthless; learning "./configure; make; make install" isn't that hard, and it makes it much easier to find someone who can make the program work.

> So why should I care if their software stopped working abruptly? More bluntly, what's in it for me?

So much for even dreams of "the year of Linux on the desktop". So much for dreams of free software taking over. Such an attitude will even drive away geek users; there's at least one user commenting on this article pointing out this is why they're using Go instead of Python, and comments on this thread have said that Python 2 was ANSI C and thus should still compile; surely the fact that ANSI C was stable and universal was part of the reason Python 2 was written in it.

At a more values-based level, this feels like digital vandalism. Instead of making a world where things work and someone can use a tool until something better comes along, it's making a world where planned obsolescence is built in, where code has to be rewritten regularly, not because it wasn't good, but because people decided to make some arbitrary changes, where everyone has to learn everything anew on a regular basis.

Python discusses deprecations

NYKevin — Thu, 09 Dec 2021 23:02:59 +0000

> Linux has been more focused on source-code compatibility than binary compatibility,

The average user does not know how to operate a compiler, so from their perspective, source compatibility is entirely worthless.

> More to the point, so what? The fact is that a working program in use stopped working, frustrating the user, and forcing them to find a replacement. Why does whether Debian does the same thing matter?

So what to your so what. The user wanted to keep using the same software indefinitely, but maintaining existing software (fixing security vulnerabilities, supporting new hardware, etc.) is expensive. Somebody has to pay for that work, and right now, it would seem that nobody is willing to do so, including the user in question. So why should I care if their software stopped working abruptly? More bluntly, what's in it for me?

Python discusses deprecations

dvdeug — Thu, 09 Dec 2021 19:48:23 +0000

Linux has been more focused on source-code compatibility than binary compatibility, and has never natively run on 16-bit systems. IBM System/360 computers were sold between 1965 and 1978, and the code written for those systems still runs on the IBM z15 system released in 2019.

More to the point, so what? The fact is that a working program in use stopped working, frustrating the user, and forcing them to find a replacement. Why does whether Debian does the same thing matter?

Python discusses deprecations

NYKevin — Thu, 09 Dec 2021 19:17:18 +0000

A couple of other interesting features of that code:

* The function dts() is exactly equivalent to the builtin function repr()... unless you pass a tuple with len() != 1, in which case it just blows up in your face. Fortunately, it's only used on integers.
* {buc,ovf}_has_{key,value} are supposed to be boolean, but they are initialized with zero instead of False in some places, and in others they are initialized with objects which appear to be mutable (e.g. op.keys, which is a list in Python 2, and a read-only "view" in Python 3). This gives them sometimes-pass-by-reference-sometimes-pass-by-value semantics, which is probably not intentional?
* There's a fair amount of backslash-escaped newlines inside of parentheses. You don't need to escape those newlines at all.
* Assuming this is Python 2, it is using classic classes, which don't exist in Python 3. Fortunately, it generally doesn't matter unless you're doing some sort of inheritance and/or polymorphism, which this code isn't doing.

I suppose you could fix all of the above in refactoring, but IMHO it might be better to just do a ground-up rewrite at this point.

(As far as helping fix it, you should talk to the person whose user page it is under. According to their contributions, they are still an active Wikipedia user, as of November 2021, so you can probably reach out to them via their talk page or by other means.)