> I don't ever want to have to fight so hard for a
PEP and find that so many people despise my decisions.
Leading a large open source project must be terrible in this age of constant outrage :-(
replies(9):
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?
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.
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.
Ultimately, it's up to certain stakeholders to hear arguments and make calls.
> 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
https://daniel.haxx.se/blog/2016/11/14/i-have-toyota-corola/
Yeah, tough. Fix your code
That's the attitude some maintainers need in cutting unreasonable requests.
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.
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. ;-)
It seems Python 3 is now dominant but not total, according to TFA.
You can do something that people disagree with, even something that you think is the best for them, and still be benevolent.
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.
A lot of companies are choosing new languages over porting python from 2 to 3.
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.
“A word aptly spoken is like apples of gold in settings of silver.” —Proverbs
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.
So yes some breaking change was indicated, but the particular change that was made was the wrong one.
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!
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.
To ignore that is to straight up deny what can only be described as flamebait.
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?
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.
A lot of goodwill got burned with that.
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 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.
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.
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.
I think social media is responsible for breeding this sense of entitlement among people.
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.
Eventually sanity prevailed: https://bugs.python.org/issue28414
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."
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.
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.
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.
Guess they went out of business before they could typecast all these nasty empty strings.
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.
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.
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.
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
[1] https://www.ted.com/talks/barry_schwartz_on_the_paradox_of_c...
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'm really sorry you ran into this issue. To make things better,
I've given you a full refund.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.
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.
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 ..
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.
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.
ahahaha
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.
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'.
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.
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.
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.
this shows a superficial, almost entertainment-industry sort of view of a software development lifecycle..
in the latest Ubuntu Bionic with apps, building right now on a local machine, I see 143 python-xx packages installed and 43 python3-xxx ..
saavy package authors use import future and six to side-step the whole issue, while core maintainers struggle, and outsiders invoke a mob voice
Python 2.7 for LTS
Because they're already the senior. CEO said it shouldn't be that hard, and besides, they only wanted to pay $40K/yr.
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.
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.
If you want to keep up-to-date on Perl 6 development, check out the Perl 6 Weekly (https://p6weekly.wordpress.com).
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'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.
Fail fast. It's better to break right away than having false senses of security. There is always __future__ too.
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.
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.
There are so many languages in which the type "string" is not the one to use for strings...
The sad part is: I lost the email in a transition from one machine/set of floppy disk backups to another.
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.
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.
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!)
Python preceded unicode, though.
Since Google couldn't convince folks to let them make Python faster, they created a NEW language instead.