Arthur T Knackerbracket has processed the following story:
Python's been around in one form or another for over 30 years. Over that time, it has accumulated a wide and powerful set of modules in its standard library. These modules help developers get started with many common tasks. Fans of Python call this the "batteries included" part of the language.
But over the years, some of those batteries have died—meaning they've gone out of maintenance, or been used for technologies that are now obsolete. Some of these "dead batteries" were deprecated in Python 3.12, and will be removed entirely in Python 3.13.
So, here's a rundown—in roughly descending order of importance—of the standard library modules being removed in Python 3.13, including what each one does and what new module (if any) has replaced it.
Here are the most important deprecated standard library modules. These are the ones you are most likely still using in existing applications.
Listed as the most important modules being deprecated are cgi, cgitb, smtpd, telnetlib, nntplib, msilib, and pipes. Other deprecated modules listed in the article are: asynchat/asyncore, imghdr/sndhdr, uu, mailcap, crypt, nis, spwd, xdrlib, chunk, sunau, and ossaudiodev. Click through to the fine article if you want to see a brief description of each module and a suggested possible replacement for it.
(Score: 5, Insightful) by Anonymous Coward on Thursday December 28, @03:31PM (18 children)
3.12 -> 3.13 is not a major version number change right?
More evidence of Python's poor commitment to backward compatibility.
It's OK to use Python if you're writing trivial code or code that doesn't need to be in use for more than a few years. But if you're planning to have something with more than a few thousands of lines of code to be in use for more than five years, I recommend you use something else with a better track record for backward compatibility.
Perl maybe? Java? Cobol?
(Score: 1, Insightful) by Anonymous Coward on Thursday December 28, @03:50PM
> Perl maybe? Java? Cobol?
Are you mental? Perl? The Write-Once-Read-Never language? COBOL, the language for which you cannot find people who can still wield it (at reasonable prices) outside of government?
Java? Have you used that monstrosity? Quickly now, explain the versioning scheme of java to a non-java developer?
I agree that there are better languages than Python - and which ones those are depends very heavily on what you're going to be doing, which environment (physical, business, technological) you're operating in, and a whole slew of other factors - but the ones you suggest are even worse than Python.
> More evidence of Python's poor commitment to backward compatibility.
I don't think you fully understand the rationale, implications, or meaning of the removal of those 'batteries' (horrible term). They won't be removed from pre-3.13 Pythons, so you can still use them if you really want to, you just have to use an older/not the latest version of Python. Those older versions don't go away/poof.
The reason they are removing them is because they can no longer be supported or they deal with technology that is obsolete. If they left those unsupported, and probably insecure packages in, you'd be moaning about how they have a "poor commitment to forward compatibility". What they're doing is limiting their attack surface by removing things that are either not used anymore to the extent that the resources needed to continue to support them in the main branch exceed the number of people/resources that actually use them or because there have been better replacements available for years already and you shouldn't use the older versions anymore. (Have you actually looked at the actual list?)
Python is open source, you can always take the deprecated/removed code, and roll your own package from it to continue using it... if you were to really really
be an idiotwant to.(Score: 3, Interesting) by Anonymous Coward on Thursday December 28, @03:55PM (2 children)
Uh huh. Tell that to the Python web app I wrote 15 years ago that brings in ~$40k/mo across several hundred customers.
I've occasionally had to adjust a few things due to a deprecation here and there over the last 15 years, and I've updated the web interface to make it more user-friendly over time...but it's still running well and passes a security audit every year.
(Score: 4, Interesting) by darkfeline on Friday December 29, @03:46AM (1 child)
> I've occasionally had to adjust a few things due to a deprecation here and there over the last 15 years
Exactly, poor commitment to backward compatibility. If you haven't changed the code, it should continue to work, period.
Join the SDF Public Access UNIX System today!
(Score: 1, Troll) by Ox0000 on Friday December 29, @05:27PM
And it will. Not changing the code also means not changing the Python version you run on. And if you do that, it will keep working.
(Score: 5, Insightful) by Mojibake Tengu on Thursday December 28, @03:59PM (5 children)
Still it is possible to hide runtime eval sploits in obfuscated docstrings though.
Well, I like Python, it's cosy comfort and I recommend it for children learning programming, but using it for production code or even for certified applications is like a Sisyphos' damnation, definitely not commendable.
Respect Authorities. Know your social status. Woke responsibly.
(Score: 2) by HiThere on Thursday December 28, @04:17PM
It depends on what you're doing. For some things, Python is my first choice. For others I prefer something else. (Currently I've bee trying to get std::chrono to do something it doesn't want to...so I'm going to need to write my own module. My class won't handle time zones, because I don't need that, but it will support easy creation of a known date at runtime...at low resolution...and packing it into a uint32.) Were I using Python I'd never try to do that, but I also wouldn't need to. (I.e., if an application that needed that I wouldn't choose Python.)
Javascript is what you use to allow unknown third parties to run software you have no idea about on your computer.
(Score: 3, Interesting) by anubi on Thursday December 28, @10:04PM (3 children)
What is the consensus on C++ / Assembler ?
Those are the only ones I use. I only mess with embedded microcontroller stuff where I am trying to interface big things to talk to real world physical things: sensors, actuators, usually through TCP/IP or RS485.
So far, all of my stuff has been Arduino compatible. I keep wanting to branch into Raspberries, but my plate is full with just the "toy" microcontroller. I rarely design with fast stuff, but I have been known to use several microcontrollers to process threads simultaneously, as for me, it takes the undivided attention of a microcontroller just to handle ONE stepper motor, mostly due to acceleration/deceleration sequence timing.
A lot of my stuff is energy critical. Battery/Solar.
I will do weird stuff like phase locking a processor clock to the process that it is controlling to avoid sampling artifacts and the chaotic operation that sometimes result from the coupling of systems running at two different speeds...and the thing I am trying to control is bound by some natural phenomena that varies slightly from unit to unit from manufacturing tolerances.
I haven't found anything out there that even comes close to C++/Assembler. But then I am still using 20 year old technologies.
I am interested in maintainable, efficient, and inexpensive. Anything else I should be looking at?
"Prove all things; hold fast that which is good." [KJV: I Thessalonians 5:21]
(Score: 4, Interesting) by Unixnut on Thursday December 28, @11:29PM
Personally, I would just stick with C++/Assembler if you know it well. So what if it is 20 year old technology? It does the job, it does it well, and C++ in particular seems to really care about backwards compatibility, to the point that (at least on non embedded systems) you can instruct your compiler which C++ standard you want to target, from the new/experimental standards to C++98 AFAIR.
I've only recently started learning C++20 (as part of my move away from Python) and am impressed both with C++'s capability, flexibility and backwards compatibility.
For uC's I moved away from Assembler around about the PIC, 8051 and ATMEL AVR days (Keil C compiler comes to mind). When I started playing around with Arduino's in my spare time I admit I basically just wrote C, and only "dabbled" in C++ when the libraries I interfaced with required me to. However I am putting an effort into doing more Arduino C++ in future projects :-)
Raspberry pi's are just SBCs, you get a full fat OS on them (I've made and used lightweight embedded Linux systems for them using Gentoo and cross compiling) so when you are in a Linux environment you can program in any language Linux supports. I've written Perl and Python code on raspberry pi's, and if your task does not eat up all the RAM and/or is not timing critical you are generally fine. For anything else C/C++ works just fine. I mean the Raspberry pi 2 is more powerful than my desktop in the 90s was, so from my point of view there is no real "embedded" type thinking required for Raspberry pi's.
At least there isn't unless you need/want to use a RTOS of course :-) But then you need to learn more about the OS environment and its abstractions/libraries then about the raw HW of the pi.
(Score: 4, Interesting) by Mojibake Tengu on Friday December 29, @07:14AM
There is a MicroPython out there now for all spectrum of microcontrollers, from Arduino through ARM/32 up to RISC-V/64, but it has its own issues.
One typical limitation of it is memory: a programmer in MicroPython needs to adopt different (from standard Python) thinking about automatic allocation of Python objects and garbage collection. Redefinitions and local constructions are no good and may lead to memory exhaustion.
Another one is threading: an RV64 which has two cores can run exactly two hardware threads on its MicroPython implementation.
On microcontrollers, stick to your C++/Assembly skills on and cultivate them. Understanding all hardware details of a platform is critical.
Respect Authorities. Know your social status. Woke responsibly.
(Score: 3, Informative) by Thexalon on Friday December 29, @01:17PM
It sounds good for what you're doing, although I'm certain there would also be some advocates for plain old C instead of C++ due to the faster compiling and simpler code structures that can result. Assembler is of course really your go-to for low-level tweak-the-processor-in-a-precise-way sort of work. C or C++ makes the larger structures a lot more readable than assembler modules, no question, so that makes a lot of sense too.
Some Python-related tools you might be interested in include Cython which can compile Python into C, and the Python-C interface which would allow you to write Python code that talks to C code which can wrap asm blocks. If you find Python readable and maintainable (and I do - if it's written well it looks a lot like pseudocode), you might find this useful.
But when in doubt, Do What Works.
The only thing that stops a bad guy with a compiler is a good guy with a compiler.
(Score: 5, Funny) by tekk on Thursday December 28, @04:16PM
> Java?
Unfortunately Java solved the problem of its enormous breaking changes in the move from 1.8 to 1.9 by just declaring that they were dropping the 1., taking it from java 1.8 straight to java 9 ;)
(Score: 3, Informative) by DannyB on Thursday December 28, @06:21PM (2 children)
Java has a pretty good story of backward compatibility. It also is used for big programs, and programs that must be maintained for long periods of time.
Once, decades ago, I worked on a program in Visual FoxPro while I was learning Java. I worked on that program for several years. Before that I had also done a lot of personal exploration and fun projects in Common Lisp. One lesson I learned about dynamic languages: code of any significant size written in dynamic languages is not maintainable in the long run. (Also JavaScript has these problems.) Java was fantastic by comparison. The IDE and editor understood all of the code the same way the compiler understands it. There isn't any question about what a particular identifier means and exactly what it refers to. There is no mechanism to use a string as a way to access an identifier in the source code that happens to match; for example, calling one of several functions via the function name in a string variable. In Java you would have to use a SWITCH statement for that meaning everything is settled at compile time. And a "switch" uses exactly the same amount of time to reach any of the switch CASEs, unlike stacked if-then-elseif.
This dynamic nature is one of the reasons Python is difficult at best to compile efficiently. There is no way to know what many statements actually mean until runtime in context. A statement may look like a method call on an object, but the method could be dynamically replaced at runtime by some code far away in a million line codebase. And there is no way for an IDE to prove that.
People may claim that Pascal and Java (and others) are "Bondage and Discipline" languages. But that is the very thing that makes them easy to work with. The compiler knows the exact meaning of everything, and it will happily complain about the least little tiddle or dot that is wrong.
Now people can and have written dynamic evaluation things on top of Java. Including the stupid idea of being able to interpret certain URLs in a way that can lead to executing code. But that isn't the language's fault. You can write bad code or have bad ideas in any language. And I would point out that there are introspection mechanisms in Java where if you really, seriously want to, you can introspect the code at runtime and manipulate things in bad ways, such as dynamically compile classes and add them to the runtime, at runtime. And some dynamic languages on the JVM, which are efficiently implemented, depend upon that very machinery in order to be efficient.
Now that said, I will point out that any mainstream language that is popular is popular for a reason. Obviously a significant community of developers find that language is well suited to some particular use case. That applies to Java and Python equally. Python wouldn't be popular if it didn't do something right for someone. Python is great for quickly creating small programs that don't need to be maintained for decades across generations of programmers. In Java, you can look at code your grandfather wrote, and your IDE can tell you exactly everything about any identifier.
When trying to solve a problem don't ask who suffers from the problem, ask who profits from the problem.
(Score: 3, Interesting) by DeathMonkey on Thursday December 28, @06:45PM (1 child)
On the other hand, the Python program I wrote to replace a Visual FoxPro program that got EOL'ed after 10 years is still running 20 years later.
(Score: 2) by DannyB on Thursday December 28, @09:50PM
The Visual FoxPro program I worked on also outlasted official EOL support of VFP from Microsoft in 2015. But I had long moved on. Other people stepped up to continue developing and supporting it, but I did not see that as a good career move.
I could see a well written Python (or Lisp, or JavaScript) program lasting a long time. But it would have to be put together by someone who is writing it with an eye toward long term maintenance. I've seen plenty of dynamic language hacks that are great for short term use but that I would not consider good examples of "engineering" in any sense. :-)
Nonetheless, I recognized in both Common Lisp and VFP that "refactoring" was a big problem. I could intelligently rename and refactor some things in the frameworks I had written. But that was because it was all in my head. Now you could say "documentation", and I believe in that, but there are limits to what a company spends on an older product.
When trying to solve a problem don't ask who suffers from the problem, ask who profits from the problem.
(Score: 3, Interesting) by Unixnut on Thursday December 28, @11:12PM (2 children)
Funnily enough, after almost 20 years of Python dev work, I have started replacing more and more of it with Perl (while of course learning Perl along the way), primarily because Perl seems to be not only stable over time, but is keeping true to its goal as being a general purpose glue/prototyping/automation/scripting language.
That is not to say Python is useless, it is really showing its strength in replacing R/Matlab as a research language, and its widespread use means that you have a lot of libraries that interact with it (hence why it is the main glue language of "AI").
As for backwards compatibility, apart from the switchover to Python3 I have not seen any major compatibility issues between core Python versions (pandas is a whole different kettle of fish, I almost feel like they enjoy breaking compatibility whenever they can for shits and giggles, which is why I moved away from them for numerical work). Generally when there has been a compatibility change the Python devs provided ample warning time, advice and sometimes helper scripts to deal with the transition. I can see here they did the same, as the "phase out" transition is 2 years according to TFA.
Saying that I am surprised at some of these modules they are removing. Quite a few of my old programs make use of them. I find it very surprising that not only are they removing cgi/cgib, they have no replacements listed, which means they are giving up on CGI web programming. There are websites I wrote recently that are in heavy production use that use cgi/cgib, and there are plenty older ones still in production that use them, and I am sure I am not the only one in this position.
It is not the end of the world, 2 years is long enough to migrate your software away from those modules, and if the Python devs are not planning on compatible replacements, to plan the move to a different language. I myself will probably port the affected software over to Perl over the next couple of years, simply because it seems in future those tasks will be a better fit in the Perl ecosystem, given the direction Python is taking.
(Score: 1, Interesting) by Anonymous Coward on Friday December 29, @03:18AM (1 child)
Not always. The more affected code you have the longer you might need. So moral of the story is you shouldn't have too much code written in python, the max is something like "12-18 months of rewrite+debug+test+document+migrate+etc" worth of python code.
I'm also surprised with them removing libraries with no replacements.
For example, in addition to cgi that you mentioned:
How do they know few real world users use it? Has Microsoft deprecated MSI? Is creating MSI packages no longer a conceivable thing that python developers would ever want to do? I can imagine more than a few organizations in the world need to create MSI installers. Maybe they were like me and wisely avoided python and used something else.
(Score: 2) by Unixnut on Friday December 29, @10:11AM
Well, TFA says they will support the modules in the latest Python releases for two years. Most production environments run stable / LTS versions of Linux which provide support and security patching for 5 years after the latest Python release. This means you should be able to run your current code for another 7 years without worrying about running unpatched binaries on production.
At my last job you could also request special dispensation to run older (for example my company will provide an extra 3 years for critical services as long as the security team sign off on it). Meaning that you could be able to run that code for 10 years before porting needs to be completed (but ideally you want porting to complete within the 7 year window).
To put it in perspective, Python 3 was released in 2008 yet we still have Python 2 code running in production. Only recently (2020) did the Python devs end-of-life python2, but our LTS release still supports it. Indeed a lot of my "Learning Perl" and re-writing Python code over the last years has precisely been the python2 code, primarily because python3 made some things that were easy difficult, and it was faster to port it to Perl then beat python3 into doing what you wanted it to.
Not that I disagree with you, I personally hate having to do things twice, and re-writing perfectly good production code (and going through the re-test/debug/QA procedure) because upstream broke compatibility is an annoyance. This is the first time in my knowledge of Python history that they are deprecating standard modules without drop-in replacements, which will require a re-write (hence an opportunity to carry on the migration of logic to better suited language ecosystems).
(Score: 3, Touché) by The Vocal Minority on Friday December 29, @04:10AM
Doing anything AI related that is reasonably complex seems to required Python code these days...unfortunately.
(Score: 4, Insightful) by crafoo on Thursday December 28, @04:07PM
Python is the new Visual Basic, and there is nothing wrong with that. It's probably more productive to just install something like SciPy or similar, tailored to the type of tasks you will be working on. Or just use a full environment such as Anaconda or whatever.
(Score: 4, Insightful) by Opportunist on Thursday December 28, @05:43PM (8 children)
I mean, python is a great language to whip up a quick POC without having to go through the song and dance routine of setting up an environment and write convoluted classes to get something up and going quickly, but there are actually people writing "real" programs with it? Programs that someone still gives a fuck about a month after it was created?
(Score: 4, Funny) by DeathMonkey on Thursday December 28, @06:40PM (5 children)
Have you heard of this tiny little website called Google?
Or perhaps this little video streaming site called Netflix?
There's also a little chat website called Reddit.
They're probably all so obscure you've never heard of them though....
there's a few more tiny companies on here [jaydevs.com]
(Score: 4, Funny) by DeathMonkey on Thursday December 28, @06:42PM
And I came in here to bitch about my latest Python woes!
But people say the stupidest shit about it I end up defending it!
(Score: 4, Touché) by Opportunist on Thursday December 28, @08:10PM (3 children)
Yeah, I know them all, and I have used them all. And pretty much all their interfaces suck.
Just imagine what they could've done if they used a programming language that was built for maintainability!
(Score: 4, Funny) by DeathMonkey on Thursday December 28, @11:17PM
It is true that Guido van Rossum has a personal veto power over every graphic designer hired by any firm that uses Python. But hey...all languages have their flaws!
(Score: 0) by Anonymous Coward on Friday December 29, @12:17AM
This is the stupidest fucking thing I've read all day, and not only is the day almost all behind us, I've spent a considerable amount of time on Truth Social today.
(Score: 2) by Tork on Saturday December 30, @02:11AM
🏳️🌈 Proud Ally 🏳️🌈
(Score: 3, Interesting) by Rich on Thursday December 28, @06:42PM
I've done such a thing. Requirement was a rather simple logged-data -> some processing -> nice-graph thing. I think it had grown out of its Excel heritage and needed a makeover. We quickly whipped up some proof of concept, using Matplotlib, and iirc wxPython. Everyone was happy and it got bundled with one of these make-a-standalone-EXE tools. Horrible bloat, but apparently good enough for them to pay the bill. I then didn't hear from that for ages and always thought "well, I guess it wasn't tidy enough and fizzled out.". But then, years later, someone at the customer site casually mentioned it. I asked if someone actually still uses that stuff, and they replied. "Oh, yes, it's in widespread use, it works without any flaws, and everyone is happy with it."
From ad RAD-stance, Delphi or even a quick C#/WPF project would have been neater, but for one, I'm not a Windows shop (Windows alone would have been good enough, but we delivered cross-platform) and neither of the "big" RAD environments would let us drop-in the plot functionality with such little effort. So Python indeed was the least-effort route to customer happiness.
When you deal with vertical market customers, they care about 1.) a certain, limited functionality and 2.) the price. If you can kludge together 1 so everyone is happy, and offer 2 a good percentage below what would be expected of "usual" application development, you'll have the equivalent of rather royal hourly rates.
When I was younger, I undercut a competitor's FoxPro development offer for a specific warehouse-keeping task by two thirds, mostly just to make a point. I offered GUI operation, the competition was ugly text masks. They thought I was a con, and to prove I'm not, I clicked it together in FileMaker Pro in three hours and let them test it. They were totally satisfied, and paid - in terms of time spent, that was my highest hourly rate ever.
(Score: 3, Insightful) by Thexalon on Friday December 29, @01:32PM
I spent almost 5 years working for a division of a fairly large company with about 40 people wrangling Python. It wasn't too terrible, but felt more like maintaining a large chunk of Java than anything else, and certainly was not a silver bullet solution to everything but had the language not making anything needlessly complicated.
So it's at the very least not massively worse than any other alternatives out there.
One of the longest-maintained bits of Python out there, though, has to be Red Hat's RPM.
The only thing that stops a bad guy with a compiler is a good guy with a compiler.
(Score: 5, Insightful) by turgid on Thursday December 28, @07:34PM (11 children)
I hate to sound like an old git but some things need to be said.
These days, we seem to judge a programming language by its libraries. "Can language ${foo} do ${bar}?" Those of us of a certain mental disposition, and knowing what we know about Turing Machines might give a different answer to the average hipster.
It's not surprising that certain libraries go stale, if they become less relevant to the modern world.
Python is not a "bad language." It's actually quite a good language and I wish I had more time to spend learning it. The problem I see, and this is from real-world experience, is that the next generation coming up don't understand the issues. They expect to have things provided to them by a language's library,
They don't know what to do about "new stuff." They don't know how to roll their own. To use a cringe worthy cliche, they can't think outside the box. As a result, they don't know what it takes to keep the old stuff going on their own. Do they ever think to ask themselves how anything works?
We have FOSS these days. People need to maintain the skills to use it to its full potential.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 4, Insightful) by Opportunist on Thursday December 28, @08:14PM (5 children)
That's hardly a new thing, I already noticed the same with languages like C# and Java. For every fart you might want to pass, there is almost certainly a library that abstracts away anything you could possible need to know or understand. And while that certainly aids people who don't want to understand that intricate differences between bubble and merge sort, it also means that we have more and more programmers who don't even know their own language anymore. They only know how to plug parameters into functions and run that function. With zero idea what's going on behind the curtain.
And that eventually leads to severe security problems, especially when they copy/paste program off some "ask your programming questions" board, where more often than not by now the blind leads the blind because those that answer also only know how to plug parameters into functions and spin the wheel.
(Score: 3, Insightful) by VLM on Thursday December 28, @08:50PM (1 child)
Even worse, now you have AI generated answers using other AI generated answers as their authority.
(Score: 2) by turgid on Thursday December 28, @09:08PM
....is the correct answer to the universe.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 4, Insightful) by Ox0000 on Friday December 29, @12:29AM (2 children)
And then there's left-pad [wikipedia.org]: a "framework" (everything is a framework in the javascript world) to left-pad a string. The full source code [github.com] of said "framework" was a mere 14 lines of code. A bunch of people decided that taking a dependency on some other code-base to left-pad a string was a better idea than to write that code themselves...
On the bright side, that's job-security for me...
(Score: 2) by Opportunist on Friday December 29, @01:58PM (1 child)
Hell, those cargo-cult programmers mean total job security for me.
Working in security as well?
(Score: 3, Funny) by Ox0000 on Friday December 29, @05:24PM
How did you know?
(Score: 0) by Anonymous Coward on Friday December 29, @01:59AM (4 children)
If the libraries are well written, designed, documented, supported and aren't burnt down every few years or even centuries; it makes more sense to use them.
You say roll your own. I say why reinvent the wheel? Why build your own CPU, RAM, capacitors and motherboard from scratch?
It's an inefficient waste of resources to have millions of people reinventing their own libraries to do mostly the same thing but in hundreds of thousands of different ways, that work differently and mostly poorly documented.
For example, instead of everyone rolling their own database library and drivers for different databases, they can just use the standard database library.
The more standard stuff in libraries, the less code I have to write, test, document and support. And the more time I have to spend on writing "new" code to solve the "actual problem" (OK it's usually not a truly novel problem too but whatever 😉 ).
And when I am troubleshooting someone else's code. If it uses lots of standard libraries (database etc), I don't need to investigate the details of how the libraries work - I can just focus on the much smaller problem of that person code (unless of course there's a bug in the library in which case if it's well supported I can report it and someone else will fix it and document it).
Having everyone roll their own libraries is as stupid as everyone building their own computer and OS from scratch, just to run their own app.
Yes there are advantages to knowing how to do it and how stuff works. But it's still stupid and inefficient to have most people doing that or to expect most of them to know how to do it. Doesn't help civilization to scale and achieve more things.
This is why good libraries that "work forever" are important. If you are going to build something that works for decades you need a foundation and concrete that lasts for decades.
If you use an "LTS" concrete that barely lasts 3 years and a foundation that also doesn't last 3 years, then the malls, factories and skyscrapers that you build on such stuff will have to keep on being migrated, or they might never be in good working condition or even be completed.
Yes it's job security and more jobs for us if stuff has to keep on being built and migrated. But it's still a huge waste from a "big picture" perspective.
Like being paid to keep building sand castles on a beach. Sand castles that will be destroyed by the next hipster wave.
(Score: 2, Redundant) by turgid on Friday December 29, @10:50AM (2 children)
You say roll your own. I say why reinvent the wheel?
No, I say try to learn enough about things over time that you can do meaningful maintenance on the wheel. Optimise the wheel and extend it for the new challenges of the day. If it's too old and crufty, burn it and start again with the benefit of hindsight.
As for reinventing wheels, for the jobs I do I write new code. There usually isn't a library, or there might be one I wrote myself. To be honest, there isn't really a lot of stuff out there that's good enough. Sometimes I have to go looking for solutions to problems and I end up on stack overflow. Some people proudly tell me that they "just copy-and-paste from stack overflow." Not in my codebase they don't.
There is a tendency these days for all sorts of random garbage to get hoovered up into a project and most of it's unnecessary broken bloat.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 3, Informative) by pTamok on Saturday December 30, @09:18PM (1 child)
There are times when standard libraries are rather useful.
A case in point are libraries that implement IEEE 754 [wikipedia.org]. Rolling your own is not a good idea. In general, some clever people have assured predictable, stable, and portable behaviour.
The same can be said for some standard cryptographic functions, where implementing your own is a fool's game.
So it can be argued that use of standardised libraries can be regarded as good practice. But throwing together a mish-mash of frameworks and libraries without understanding is, most likely, bad practice. Telling the difference between the two requires at least some insight.
(Score: 2) by turgid on Saturday December 30, @10:46PM
Quite. I once saw an independent implementation of "AES-256." Oh dear...
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 2) by sjames on Friday December 29, @11:46PM
A natural cutoff point is where the complexity of maintaining the dependency exceeds the complexity of maintaining the code itself. Include in that estimate that bringing in a dependency also means adding more attack surface than just adding a few lines of code.
I wish more cargo cultists would realize that if you have to bend over backwards to contort things just so you can use a library function, perhaps the function you want is not the library function and you should roll your own.
Arguably, small one function dependencies are the riskiest of all. The odds are just too high that the publisher simply doesn't give it enough thought to keep it from being hijacked.
(Score: 3, Interesting) by VLM on Thursday December 28, @08:47PM (4 children)
The next step beyond the dead batteries is modules with strange functionality.
For a good time look at the file formats supported in tarfile. I had a run-in with that last week (long story) and IIRC it supports original AT&T unix 7th edition format from a pdp11, sunos stuff (pre Solaris), the USTAR format from the 80s, just tons of code to do stuff that was probably cutting edge back in 2002, but is kind of crufty now.
For those not interested in esoteric tarfile trivia, if you made a tar file after the turn of the century its probably in PAX format supporting enormous files and unicode filenames and all that good stuff. However, Python tarfile module supports some strange old stuff that has a filename ending in .tar
And the meta point is what to do about it? Create a new 'tarfile2' module that only supports PAX files made after 2001? It's almost 23 years now, nobody "IRL" uses anything but PAX formatted files. Ripping unused features out of 'tarfile' will result in screeching.
Another novelty is people "know" how "avi" and "mp4" are container formats but I bet less than 1% of sysadmins know tar files are essentially a container format, probably because for a human generation or so they've mostly all only contained PAX format archives. There was, however, a day when tar files didn't support unicode filenames or petabyte length files and those were different container forms inside ".tar" files.
(Score: 2) by turgid on Thursday December 28, @09:10PM (1 child)
Maybe we need to go back to cpio?
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 3, Insightful) by VLM on Thursday December 28, @11:48PM
Funny you should mention that because there's no standard library support out of the box in Python for CPIO, AFAIK, tars and zips and lzma formats and stuff like that, but no CPIO.
There's yet another friction in the world of Python where what's the point of Python including a standard library that includes a tarfile module that includes support for 7th edition AT&T Unix(TM) genuine tar files when there's the perfectly good, maybe better, 3rd party "python-libarchive" which AFAIK is 'supported' by the SmartFile dotcom which is a super-wrapper for pretty much every format that ever existed including your CPIO format.
The standard library you get with every Python install has stuff too old and crufty to really be 'standard library' material in 2024, but its not as feature filled as the 3rd party modules of 2024. Or rephrased its got "junk" that's big enough to be annoying and possibly a security hole or security "surface", yet small enough to not have enough features to be useful so you'll need to install 3rd party stuff anyway... its like the perfect optimum of being not useful.
(Score: 1, Interesting) by Anonymous Coward on Friday December 29, @01:24PM (1 child)
Just for the sheer horror of it, have a look at the awesome mess that is the "tiff" file. IIRC it's Turing complete, with disk and network access.
(Score: 3, Interesting) by Tork on Saturday December 30, @02:33AM
I seem to recall an Amiga format... .iff maybe? It was flexible enough to serve as the template file for storing layered 3d models, including multiple UV coords per-vertex and even detailed material instructions. I never really got into using scripting to write binary data but if my curiosity piques on it again I wouldn't mind digging up details on why it's that flexible. It's still in use today!
* Actually it might not be ZIP, could be a predecessor but my old man brain is being grouchy about long-term-retrieval requests.
🏳️🌈 Proud Ally 🏳️🌈