It's PHP and not Python, but every time I read something like this from a major open source figure, I always think of this old PHP mailing list thread:
> Escalate? Oh how I wish I had someone to escalate to. - rasmus@php.net
> After carefully reviewing this bug report with our board of directors on 4chan, we have come to the conclusion that your "rusty C skills" should be enough to fix the issue.
I would therefore like to remind you that rasmus@php.net is http://en.wikipedia.org/wiki/Rasmus_lerdorf
It often happens that I wake up at night and begin to think about a serious problem and decide I must tell the Pope about it. Then I wake up completely and remember that I am the Pope.
After carefully reviewing this bug report with our board of directors on 4chan, we have come to the conclusion that your "rusty C skills" should be enough to fix the issue.
I would therefore like to remind you that rasmus@php.net is http://en.wikipedia.org/wiki/Rasmus_lerdorf
That's a good read. I feel like the "customer is always right" mentality does quite a bit of harm to OSS support.
Also reminds me of that dev (who I can't seem to search up) who had their email printed as part of a open-source software license in a car manual and would get ridiculous email from people who had car trouble.
OTOH, way back, when I had a TV receiver card by Hauppage, and a new Linux kernel broke something, I posted a description of my troubles on Usenet, and within 24 hours, the person who had written the Video4Linux subsystem replied asking for more details (which I gladly provided), and a few days later, the bug was fixed.
That, I think, was the most awesome "customer support" experience of my life. I did make a point of being polite about it, however, which I consider a ground rule for dealing with people, especially if I want something from them.
But it was so awesome to post to a random usenet group about a driver problem and have the person who wrote the driver personally approach you for details. You don't get that with Windows, for sure. ;-)
Yep. This attitude isn't dead, assuming you approach the developer via the right/preferred venue, and are polite, and they are still actively maintaining the project. And it really helps if you give a thorough bug report!
I recently submitted a bug report to a fairly niche OSS package that I use, and within a few hours the author replied (on GitHub) something like "oh wow, yeah that's an edge case but I definitely want to fix it, can you send me the test data you used..." and once I gave him the test data, he had it fixed in two hours and now anybody who grabs the source won't have to deal with that bug.
It was great, and even though I didn't do anything except write up a bug ticket properly (the same way I'd expect anyone on my team at work to do it), the software is a little better now.
I had the same experience. Suddenly Emacs Gnus reader stopped working, about 11:00 on a Friday morning. I posted the bug and had a reply from Lars Ingebrigtsen with an explanation and a workaround by 13:00. I think it was fixed by the beginning of the following week.
My experience of trying to get help from Microsoft on the other hand is, well let's just say not quite so impressive; they kept me on hold for 45 minutes once and never did solve my problem.
Back in the days Microsoft would have amazing customer support. And I'm talking about "API customers", many times I've seen them go out of their way to fix third party programs not working correctly by adapting their platform, it was a very efficient process.
I guess that doesn't work as well at their current scale, or they care less because they're not building up market share.
They once shipped my company a custom MSVCRT.DLL to fix a crash bug in a third-party application under heavy load. True, it was a bug in the C runtime itself, but they got us a fix for it about a day after we (along with the third party) got in touch with them.
Just a few years later my team had to contact them for a BSOD that kept happening after one of their patches. We were put off for about a week before throwing our hands up on it.
> go out of their way to fix third party programs not working correctly by adapting their platform, it was a very efficient process
This kind of thing probably doesn't even scale with itself, since there are only so many acrobatics your code can go through before no one can even understand why it's doing something, let alone add new workarounds. So the first K broken programs get special treatment, and the others face a much higher bar to get the same treatment.
Years ago I purchased a motherboard with a built in Raid controller. There were no drivers for it in mainline Linux kernel but there was code for a kernel module on the chipset vendor (Via's) website. The provided code wouldn't compile because there was a bug.
People from Fedora IRC channel helped me live debug the code over irc and we found the bug and were able to get code to compile and my raid controller working. Was an awesome experience.
I used to have similar experience with most of the free source (that, or silence when project got abandoned), until Laravel, where I was yelled at because somebody apparently needed an ego boost that day. I still love the framework, but I don't think I'll be trying to reason there anymore. Still - maintaining projects most of the time is unappreciated job, so kudos if you do it
> "customer is always right" mentality does quite a bit of harm to OSS support.
It goes both ways. All too often people promote their new library on HN and Reddit, wait until a bunch of people are using it as a dependency, and then abandon it without even telling anyone whether or not it’s abandoned.
And why isn't the young developer being mentored by someone more senior before introducing a new dependency into a business critical system?
Why is what amounts to a clear project management failure the problem of some open source developer who has published their personal pet project?
If dependencies aren't reviewed before being used, how does such organization handle software license compliance (whether OSS or proprietary), for example?
A clear cut case of trying to shift blame for own failings onto an unpaid volunteer that has helped to save the commercial developer time and money, IMO.
> And why isn't the young developer being mentored by someone more senior before introducing a new dependency into a business critical system?
Some critical assumptions:
- a more senior dev is available
- has time
- understand the system well enough to judge the impact
- is actually a better developer than the junior (in spite of being older / in the game longer)
> Why is what amounts to a clear project management failure the problem of some open source developer who has published their personal pet project?
It isn't, that was the point.
> If dependencies aren't reviewed before being used, how does such organization handle software license compliance (whether OSS or proprietary), for example?
Some critical assumptions:
- organizations keep a close eye on developers incorporating code under various licenses
- the people keeping an eye on that are qualified to make the calls
- the resources to keep an eye on this are available
> A clear cut case of trying to shift blame for own failings onto an unpaid volunteer that has helped to save the commercial developer time and money, IMO.
Sure. But that doesn't mean these things don't happen just about everywhere, many times per day.
It is rare to find a company where all of the assumptions labelled above are true all the time. And that's where the problem lies.
It's a clear case of there being no difference between theory and practice in theory but in practice there is, and rather a lot of it. Everybody knows in theory how software should be developed, but in practice hardly anybody actually does it that way. They're either out of time, options or qualifications (or all three) and they will do the job anyway.
That doesn't excuse it, but it does help you to understand it.
By definition, they aren't though-- for the truly green, that extensive schooling comes from `npm/pip/gem install`ing random packages with implementations they don't understand or can't account for, then having to deal with the fallout in whatever form it chooses to manifest itself. Could be a maintainability nightmare, or it could be losing your job.
My advice to mentees is that if installing a package to achieve x saves (a significant amount of) time/money that outweighs the risks to self/company or has value added by means of product maturity or domain expertise, then by all means do not roll your own crypto, web framework, db connector or machine learning library. But if one is going to introduce dependencies on things as trivial as leftpad or someone's Show HN single-pass weekend hackathon proof-of-concept, they will soon learn why we don't bring toys to work.
If you put something out there and no one uses it then fine. But once it has hundreds of commits and issues and over 1,000 stars on GitHub, then I think you have some responsibility to people using the thing you’ve created -- if you’ve been actively promoting it as something everyone should use.
It's a free product, not a child support obligation. Even if you do walk away, it's open source and can be maintained by anybody interested in stepping up. This is the price of adoption, not guaranteed updates for life from the creator.
But I get where you're coming from. It's even worse on Steam, where developers will actually collect money during the "early access" phase and then walk away once a (closed-source) tech demo is half-complete.
> This is the price of adoption, not guaranteed updates for life from the creator.
I’m not saying anyone should be obligated to do free work. This issue is that most people don’t feel comfortable publishing a public fork without the blessing of the creator, or at least knowing the creator no longer intends to work on the project in the near future. So you end up with these situations where there are thousands of people running production systems with unmerged security patches because the creator can’t be bothered to spend 30 seconds to write a one sentence reply to an email.
Short of being in a coma, I consider that toxic behavior.
And just to be clear I’m taking about situations where there are lots of open PRs but no signs of life for months or years on end, not situations where the creator just went on vacation for a few weeks.
There is a fundamental difference between the extreme of stuff like GnuPGP, OpenSSL and other extreme of stuff someone created over the weekend and was nice enough to make available
I dont want to know, how much of core infrastructure is resting on the shoulder of overworked and burned out BDFL. This isnt a ego complex in most cases, but the knowledge that without someone with their commitment working at the project it will crumble.
It's more hilarious because his response to that (basically, "this is tax software so there will be a lot of QA when we make that change") is at least sort of legitimate, but only because his accounting software evidently only works due to undefined corner cases in the underlying platform, and that's just ... wow.
I was on the side of the person giving the - I think fairly legit., bug until I came to, "tax software in php" and then I realized there's nothing really black and white in this world.
I caught the part about, "we have unitialized variables being passed everywhere which should be numbers" and that code, well, smells.
I think the PHP team changing the return value of a function without putting anything in a changelog is a Very Bad Idea and a dev. should be pretty upset about that. Saying that the main dev. is doing this work as a charitable thing is fairly misleading as well.
Buuuuut, I also think passing an unitialized value like that is already a bug in this context given the type of software being created. I'd rather see, "NULL" found wherever than know that it was magically changed to 0 (like they would prefer). I know the dev. said that this is just a formatting thing, but I'll wager they're using formatted numbers for some sort of calculation (inadvertently or not).
Whatever is going on, I hope there was a huge code review and a massive QA effort ( which I also doubt happened), because this is a textbook example of tech debt and the loan shark has come a-knockin'.
I agree with this as far as it goes, but I think @zaphar has the better answer: a tax app should never have been written in PHP to begin with.
There's a fundamental quandary in language design: accessibility to novice programmers and suitability for serious work are in opposition. Novices, being novices, are unable to appreciate this problem.
One of the hidden costs when you elect to use a language like PHP in the early 00's is that as they fix the glaring issues in their language and stdlib you will be incurring a continuing maintenance cost.
It's a combination of your choice to pick PHP and their choice to fix the languages warts colliding.
It may even have been a reasonable choice for reasons of time to market, hiring, and other business related factors. But the conflict in this thread highlighted that whoever chose PHP in the beginning did not factor in this hidden cost when he made his choice. The results of that lack of information were predictable.
One of my PHP bug submissions is already in high school. The other is in kindergarten. Thankfully both of them won't see light of day in most applications.
But focusing on PHP is rubbish - you can look at any language and find questionable choices. The moment where we need frameworks to make the warts go away - that's worrying. Same thing with JS really
When I was much younger I started building a ray casting engine. I was having trouble wrapping my brain around how to render the floors so ... I emailed Ken Silverman.
It escapes me now _why_ I emailed him. I certainly had no idea the gravity of who he was (for those also unaware, he is perhaps most famous for creating the Build engine used in games like Duke Nukem 3D). I believe I was under the false assumption at the time that the Build engine was a raycaster (I hadn't played Duke Nukem), and I probably found a personal page of his about the Build engine while trying to solve my problem.
Either way, young me emailed Ken Silverman like it was nothing. He responded! He corrected me about the Build engine, but also proceeded to help describe how to render floors in a raycasting engine.
It still took me awhile more to get the hang of the math, and I believe a few more emails back and forth with him. I feel bad now, knowing now who he was. But I appreciated his help immensely. I think I wrote 3 or 4 more ray casting and tracing engines back then. Some were rudimentary, one was a raycaster but allowed arbitrary 2D level geometry (and even used some tricks to put "holes" in walls to cheat windows and have multiple heights). One was for a code golf competition. And one was _super_ efficient; the math and levels were set up such that 90% of the logic was just binary math rather then having to do the usual multiplications, divisions, and square roots. They're a lot of fun to make and I learned a lot.
Ken, if you ever stumble on this comment, thank you!
I've done nothing worth mentioning here, but I have received a couple emails asking detailed questions about things I'd done and forgotten about years ago or looking for early career advice, and I'm more surprised and honored that someone took the time to appreciate my work than anything.
The best I've gotten are emails asking for permission to fork one of my public Github repos. I was never sure how to respond to those, because... yes? By default?
That’s great. In your naïveté, you were unaware not intimidated by his prominent figure or reputation. I’ve found that some very well-known people and companies are more approachable than one might expect, possibly because people usually assume they will be indifferent to personal communication and don’t try to talk to them.
> Ken, if you ever stumble on this comment, thank you!
His email address takes a very short time to find and he's on Facebook. Just a suggestion: why not send a note and thank him for real? You might make his afternoon a little brighter.
(I'm awful about thank you notes and if you knew me you'd be within your rights to call me a hypocrite, but still!)
When I was 19 I was interning at Google and I got into a mild discussion on a mailing list with Rob Pike. When I went back to school the next semester someone was teaching a class on UTF-8 and I thought the name of the creator sounded familiar.
Thank god I don't have access to those emails anymore so I don't have to endure the cringe.
To make myself feel better, I posit that that kind of youthful arrogance is at the origin of many innovations done by youngsters that didn't know better.
Reminds me of attending a conference and being in a workshop with a member of TC39, the Ecmascript standards committee. I was sitting next to this individual but didn't know who they were. I made the mistake of complaining about modern JS and version splitting. Fortunately, I didn't say anything too harsh but I definitely would have held my tongue if I knew who they were.
I know I've gotten into heated arguments on here or on Reddit with very well-known figures in the tech world without realizing who they are until after the fact. Luckily I don't think I've every argued with a developer about their own product before... that I know of.
I wrote to Ken Thompson when I was an undergrad doing a history of computing essay. And he wrote back with a potted autobiography! It was probably a bit before email became the scourge that it is now.
The sad part is: I lost the email in a transition from one machine/set of floppy disk backups to another.
It's not the outrage, it's the entitlement. People have always been outraged, the major difference I've seen is the rampant sense of entitlement. I'm not sure if it's a result of bad parenting or something else, but it's slowly becoming a major issue for the entirety of the human race.
I noticed this over the years on a forum I’ve run for over 10 years. Since ads are pretty much dead for small publishers like me, the forum costs me money. But I run it out of charity.
Nothing sucks the energy out of me more than lurking in my forum and seeing users complain about how little I’ve done for the forum. I don’t want to know how many weekend I’ve spent building features for the forum or arbitrating problems between users.
The thing is that these posts of entitlement are a relatively knew phenomenon on my forum mostly in crescendo over the last four years.
I’m pretty sensitive to it now and it’s easy to spot eveywhere. From people whining that free shit isn’t perfect on HN to gamers complaining that a modder charges for the mod instead of doing it for fun.
I think part of the explanation might be the explosion of choice [1]. For better or for worse, the more choices there are, the better people expect them to be to stand out. If you make software that solves a critical problem nobody else's does, I doubt people will feel nearly as entitled about it as about a forum or a programming language or whatever.
I'm in an almost identical situation with an online community that I've built and have continued to work on. Back in the day I could hang out there to relax -- these days it's incredibly draining for me to be around.
Completely agree with you. Heck I realized I have the same entitlement issue after running into 2-3 people who were on higher spectrum of entitlement. I was having issue with their behavior but realized I do the same sometimes. I am trying to balance it out. The sad thing is people are not even aware that they have this issue.
I think social media is responsible for breeding this sense of entitlement among people.
I'm not sure it is social media, rather I think it's the price. Free or very cheap opens you up to a group of people you wouldn't normally have to deal with.
I'm a little confused though, by his feelings here. Why did he feel the need to "fight so hard for a PEP" if it was so controversial, and everyone was outraged?
I do understand people's points about "the age of outrage" and "internet 2018" but still: the PEP wasn't generally accepted as being a fantastic improvement, so why did he feel the need to fight so hard for it?
It was controversial syntax, inline assignment-as-expression. There's always a tension between "keep it simple stupid" and "let's make it better", especially when a large user demographic of Python are non-professional-programmers.
Interestingly, C++ is going through the same process, with lots of great ideas being proposed, but the sum total of them being an even more complicated language (on top of what is probably the most complicated language already).
Python has been successful, IMHO, because Guido has made several brave, controversial calls. Python 3 breakage and async turned out to be prescient, fantastic decisions.
> Python 3 breakage and async turned out to be prescient, fantastic decisions.
Python 3 implementation was a step in the right direction, but the decision to allow the old language co co-exist with the new one and to break backwards compatibility between the two (for instance 'print') in places where it didn't need to break makes no sense to me.
> Python 3 breakage and async turned out to be prescient, fantastic decisions.
The jury is still out on the Python 3 decision, to be honest. Heck, Python 2 is still officially supported until 2020.
Python 3 adoption is increasing, but the instability and breakage that it introduced caused a lot of knock-on effects throughout the Python community that held it back and hindered its adoption and mindshare. It'll take a while before we can really say whether the long-term gains will make up for that.
> The jury is still out on the Python 3 decision, to be honest.
It's not. Python 3 has overtaken 2 and there is no stopping migration to it now. Python 3.7 is a lot better than 2.7. Just on memory use alone, 3.7 is massively better. Sure, there will be some hold outs on 2.7 for a long time. That's fine.
Also, this is not the say that migration from 2 to 3 was handled well. It wasn't. Python 3.0 should have had backwards compatible features like allowing the 'u' string prefix. Indexing byte strings should have returned length one byte strings. Byte strings should have supported at least a minimal amount of %-style formats. Etc.
That has all been mostly resolved and is in the past. Mistakes were made because, shock, the Python core developers are not perfect and didn't foresee all the migration issues. However, there is no way that we are going back and reviving the Python 2.x branch.
It was touch and go for a couple of years there but yeah, Python 3 is now well and truly over the hump.
The Python 3 Readiness Project now lists [341](http://py3readiness.org/) of the 360 most common packages as Python 3 compatible.
Even that's underselling it really. For example it lists BeautifulSoup as not converted, but the link goes to BeautifulSoup 3.2.1. However, BeautifulSoup4 works great on Python 3. And for MySQL there's mysqlclient and several others, and since database packages usually follow PEP 249 pretty closely its very easy to switch. So in reality, rather than 341/360, its more like "everything worth converting has been converted." Or just "everything" for short.
How much momentum was lost in the transition though? I know that with the pain of 3 at the time a lot of people started looking at languages like Go or even Scala.
Python currently still 4th at https://www.tiobe.com/tiobe-index/ . As the most popular scripting language on there by some margin, I'd say they're still doing pretty well.
That's not the point of the person you're responding to. They didn't say that the transition didn't happen. They said it's not yet known if it was worth it. All you're saying is that it happened.
I'm saying it happened and Python 3 is the language I want to use. If you don't do Python 3, you either keep the error prone str/unicode string model or you dream up some way to evolve to a better model. Would some mythical version of an evolved Python 2.x be better than what we have? I mean, how to argue against that? I haven't seen anyone propose a workable migration plan. Python 3.7 is better than 2.7.15 and better than 'tauthon'.
Is there even a "production ready" version of Perl 6 yet? It has to be the worst example of production hell for a computer language in history. It's the poster boy for the second system effect.
There has been a production ready version of Rakudo Perl 6 (https://perl6.org) since Christmas 2015. It has been on a monthly release cycle for years, and a 3-monthly release cycle for Rakudo Star, the "user" distribution (with some bells and whistles added).
Cro (https://cro.services) is a set of libraries for building reactive distributed systems. Comma IDE (https://commaide.com) is an IDE for Perl 6, based on the JetBrains IDEA platform, now in (paid) beta.
I'll probably never switch for personal use. The print statement change is intolerable to me. It would have cost them nothing to just leave the old syntax in. It's supposed to be a quick and convenient scripting language and they're actively working to make it more verbose and less convenient. I also still don't like not being able to use "string" objects as dumb byte containers, like I do with an IRC bot that doesn't crash with an encoding exception trying to write IRC control characters into a text file. Yes, I know I can work around that wrapping everything up nice and pretty to tell python "this isn't a real string it's okay you don't need to throw an encoding exception ssh." I just don't think that's good design.
Button regularity on your keyboard is infinitely more important than ergonomics too, right? Anything but a grid of equally-sized squares must be wrong by virtue of aesthetics. Spoken language too: let's eliminate all contractions because they reduce regularity. Let's also make all the speed limits in the country equal at 20mph, because regularity is infinitely more important than convenience.
You should be supporting return being made into a function too, right? That would be much more regular.
Reminder that a guideline of python was supposed to be "practicality beats purity" which is in stark contrast to the changes to print and strings. [1] Reminds me of the gradual shift of the message on the wall in Animal Farm from "four legs good, two legs bad" to "four legs good, two legs better."
That a customer of mine started a web project in Python 2 in 2015 after 7 years since the first release of Python 3 means that the Python BDFL and community managed the process horribly.
Could it be that many vendors still ship Python 2 as default for internal reasons (system-related scripts and what not rely on it)? Macs, for example ...
So you customer, not knowing any better, used whatever was on the machine already. If that's the case, that's really not the Python's community's fault.
They could have used any Python version with one of the many version managers around or docker. I think nobody cares about what comes with the operating system nowadays.
The problem was that after 8 years there were still around libraries and frameworks that worked only with Python 2. That's a huge failure. If developers want to keep using the old stuff it means that the new one is either badly designed or badly managed.
Compare it with Ruby. There were big changes from 1.8 to 1.9 (unicode stuff among the others) and again with the 2.x series. The language mostly maintained backward compatibility and we can still write Ruby on 2.5 with the old 1.8 syntax. Community ported libraries and frameworks, started using the new features and all went well.
> Python has been successful, IMHO, because Guido has made several brave, controversial calls. Python 3 breakage and async turned out to be prescient, fantastic decisions.
A lot of companies are choosing new languages over porting python from 2 to 3.
A lot of corporate dev environments operate on a policy where you're basically allowed to fix things that sales and customer support explicitly ask to fix, but nothing else. Which in turn means an environment where doing maintenance work that indirectly sustains the software is off-limits. Which in turn means they never ever upgrade the underlying platform (that's off-limits maintenance work), and so they end up on an EOL'd platform. At which point they blame the platform, and announce they're going to switch to something better that doesn't impose this problem on them.
Those types of places were never going to upgrade to Python 3 under any circumstances. They probably would not have even upgraded to a completely-backwards-compatible Python 2.8, if that had been released. So blaming Python 3 is a red herring here.
That has little to do with Python 3 and a lot to do with the scale of Google's services where high performance is really important and where refactoring in static languages is easier.
No, the bad decision was treating bytes and strings interchangeably in the first place. 99% of the hardest to fix breakage was due to that, and it was the right call to pay that price all at once.
I think I mostly agree with you, but it can be unclear to programmers (who are after all the people writing Python code) whether they're dealing with a string, or merely with bytes that happen to look like a string, and this causes hassle.
Until way too recently essentially all Python code couldn't handle basic SSL/TLS certificate validation for Internationalized Domain Names. Once you understand what's going on, this situation is a no brainer: In order to connect to a machine named X, we must have turned X into DNS A-labels that we could look up, and we can treat those as bytes. The certificate must have SAN dnsNames matching its names, and those too are written as A-labels. So we can almost just compare the literal bytes (actually DNS A-labels are "case-insensitive" so we need to handle that, and the asterisk "wild card")
But Python, in its wisdom, defined this API to take a string, and strings, as you observe, aren't bytes. So instead of the above unarguable approach they wasted precious months trying to figure out how best to turn the A-labels from a SAN dnsName into Unicode strings, which isn't even the right problem to solve.
The API in 2 is not optimal, but they fixed it the wrong way. As you know, some operations make sense with bytes, and some make sense with character strings. The operations that make sense with character strings would also make sense with bytes when an encoding is specified. Therefore, there should just be a way of annotating bytes with a suggested encoding. Then byte-oriented packages (e.g. those that deal with data sent over an interface like a socket or pipe) could simply ignore the issue of encoding. Whole classes of errors would just disappear for many python coders. Other coders, who do care about encodings and non-ASCII characters, would still get those errors but that would be OK because they would know how to fix those errors.
So yes some breaking change was indicated, but the particular change that was made was the wrong one.
Then byte-oriented packages (e.g. those that deal with data sent over an interface like a socket or pipe) could simply ignore the issue of encoding.
Long and bitter experience has shown that people who think they can "simply ignore" the "issue" of encoding actually can't. That mindset is mostly a more polite way of saying "people who assume everything is ASCII all the time, or at most an encoding that always has one byte == one character". Those assumptions break sooner or later. I prefer having them break sooner, because I've been the person who had to clean up the mess at an unpleasant time when it was kicked to "later".
Which in turn means Python 3 made the right choice: text is text and bytes are bytes, and you should never ever pretend bytes are text no matter how much you think you'll never run into a case where the assumption fails.
For lots of applications it doesn't matter how many bytes are in a character, because characters don't matter. Even within a particular application, it's common for characters to only matter in a few particular locations. It would still have been a win for python, to make such applications easier to write and maintain.
Implicitly converting strings into bytes or vice versa means now all your APIs grow an exception "Invalid encoding" / "Can't encode this" / "Can't decode this" / etcetera that you need to deal with.
Making people actually do the conversion has the advantage that when writing their string conversion code they might actually do something with the exception beyond maybe logging it and then pressing on anyway. It also gives you the opportunity to explicitly offer them alternatives like treating everything we can't encode as some sort of replacement character (works well for Unicode, not so much for ASCII), which is way too much to ask of every single function that takes bytes.
...which is way too much to ask of every single function that takes bytes.
Sorry if I wasn't clear. I meant to suggest that the byte-functions wouldn't know or do anything about encodings. They just work with bytes. It's the other functions, that take the encoding-annotated bytes (or optionally a "pure" unicode type), that would care about encodings.
> The operations that make sense with character strings would also make sense with bytes when an encoding is specified. Therefore, there should just be a way of annotating bytes with a suggested encoding.
That's the ruby solution. I like the ruby API here. When ruby introduced it in 1.9, it did cause similar upgrade pain, since you weren't used to having your strings tagged with an encoding, and suddenly they all kind of need to be if you want to do anything with them as strings-not-bytes.
As someone else noted would be the result, indeed the result was lots of "incompatible encoding" exceptions.
I think ruby actually has a pretty reasonable API here, but several years on, there are still _plenty_ of developers who don't understand it.
Sure, there are growing pains with any breaking change. Do you think the ruby 1.8 -> 1.9 transition went more smoothly than the python 2.7 -> 3.x... transition?
But on the other hand, Python's overall popularity has grown (mostly on the back of 'data science' I think), while rubies has shrunk, and python is definitely more popular than ruby at the moment... so python's lesser success at that transition didn't actually matter much in the end?
Encodings are related to storage and transportation -- not business logic. You should not have to deal with encodings inside your application, so forcing programmers to deal with encodings at the point it matters, when text enters and exits the application, is thus sound.
If yoy truly don't care whether or not the text is decodable (which is sometimes the case), then don't read it as a string, read it as a byte array.
You can still have methods that are generic over byte arrays and text, since that is an orthogonal concern.
Bad decision? UTF was Standarized in 1993, python was first released in 1991. You can't decide to use something that hasn't been invented yet. Back then bytes and string were the same thing. Java did do it right but by 1995 the industry had already seen the problems of differing character sets.
No, they weren't. Impossible as it seems, we had encodings (including multi-byte encodings) for decades before UTF.
Python couldn't use UTF-8 in 1991, but it could very well tag strings with a specific encoding, instead of treating them as a bucket of bytes C-style.
>Java did do it right but by 1995 the industry had already seen the problems of differing character sets.
We had seen the problems of "differing character sets" for decades already (Windows vs DOS version of the same language encodings was a classic example for most users, but the problems go back to EBCDIC and so on).
Java just did a more right thing, but we already have a need for generic string types that can handle multiple encodings and know what they contain and how to convert from one to another.
I wish I could sufficiently express my frustration for this. It's such a common mistake too. If you design a language with a type for text, and your language has a type called "string" oh God please God let those two be the same thing.
There are so many languages in which the type "string" is not the one to use for strings...
"No, the bad decision was treating bytes and strings interchangeably in the first place."
Show me the 1995 software that gets this right, and I'll show you proof that time travel is possible, by simply showing you that software right back again.
Abstractly, yes, it's true. Concretely, though, it's not a particularly valid criticism.
I think there are people on both sides of this fence.
Google is still largely Python 2, but my impression is that Facebook actually managed to make the transition to Python 3 after putting in the right presubmit checks.
Heaven forbid that someone responds to a point made in another post. On a public internet discussion forum. In a discussion about the context and effects of divisive and difficult decisions. /s
To be fair, the person stating that Python 3 breakage was a fantastic decision probably should've avoided referring to that as such, as it almost certainly invites disagreement on a controversial topic.
No, that's giving the flamemongers a flamer's veto. It's a perfectly sensible thing to mention when talking about the difficulties of leading the Python project and offering an opinion on how Guido van Rossum handled them. Picking out that one opinion and yelling little more than 'fite me' back at the person is not a perfectly sensible thing.
Then if someone disagrees & an argument erupts, then that should not be surprising - that post is equally as culpable for igniting a well-discussed issue by posting something clearly so opinionated/leaning towards one side of an issue that at this point one should have known better than to even allow a conversation to digress in that direction if that person wants to avoid that discussion.
To ignore that is to straight up deny what can only be described as flamebait.
It is not flamebait to say 'I think so-and-so handled a difficult problem well', especially as part of larger point. It's flamy to respond 'u wat m8?'. It's not a complicated thing and there's no 'fairness' in treating these things as the same.
>This is a particularly ill-chosen thread to deliberately try to re-flame this flamewar
Apparently it's the right thread to be rude and to assign intentions to people you don't know though?
And all because they dared say their opinion on a subject you're sensitive about?
How about that: people can have any opinion they like on Python 3, including considering it a botched migration process and a ho-hum update. And it's totally legit for them to speak about that. And it's not your place to censor them, or act up any time they express their opinions.
You can either add your arguments, or skip reading their comments. How about that?
> That's the very point of a bdfl : it assumes he knows better than others
I think it's not that he knows better, it's that there can be a single, coherent, consistent design consciousness.
A BFDL can create an effective process of evolution rather than some of the more egregious open-mob process failures that are prevalent in open source.
They are, but they're adults who work in completely different environments and thus have wildly divergent needs.
One contrast:
You have some people who in business and want to do keep an old code base working forever.
You have some people who have no business experience and have no idea what a bottom line is, but might need a feature for a critical open source project that many others will use.
B stands for benevolent even in that case. The target of that benevolence is the project. His call should be in the best interest of the project (benevolent), final (dictator), and (tongue in cheek) eternal (for life)
He fought for it because he thought it was the right call. The role of a BDFL is to make those kinds of calls for the benefit of the language and community. It's really tough to fight the "tyranny of the majority" and go with what you think is right versus what everyone is screaming and yelling at you about.
If 'everyone' was outraged, it wouldn't have been controversial, right? I'd argue that one person against _everyone_ else isn't a controversy, but in any case at the end of the day the PEP was accepted in a democratic poll.
Not to dismiss your point, but outrage on the internet is like a car wreck, its terrible that it happened but everyone on the road still wants to check it out and put their 2 cents in.
What I think would fix this, is better developer metrics and statistics. If every post to the python-dev list was automatically tagged with some sort of metric for that persons contributions to the project, it would go a long way to identifying, and triaging, the most violent vitriol.
Something like code contributions, amount of churn, speed of implementation, level of correctness, etc. Trouble is, I don't really see any quick "just insert batteries" method of adding such metrics to an open-source programming community - perhaps someone knows of a great system of reports for measuring developer productivity through a repo or something? I guess it would also have to accommodate dev-ops and marketing efforts by developers, too. Hmm .. maybe this is a startup idea in the making ..
Leading a large open source project must be terrible in this age of constant outrage :-(