Good for him! I hope he has a long vacation and enjoyment without the responsibility.
As he says, the bus is around the corner, and the reaper comes for us all - so governance is a key component of an institution.
“I'm basically giving myself a permanent vacation from being BDFL”
261–270 of 764 posts
Re: “I'm basically giving myself a permanent vacation from being BDFL”
#262Earlier quoted context omitted.
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.
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 dat…
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.
Re: “I'm basically giving myself a permanent vacation from being BDFL”
#263Earlier quoted context omitted.
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.
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 dat…
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.
Re: “I'm basically giving myself a permanent vacation from being BDFL”
#264Earlier quoted context omitted.
I'm sure 'endosquid.com' is currently being by hammered by people wanting to find out who was so rude and unreasonable.
Looks like it has been dead for a bit now.
Since 2010, it seems: https://web.archive.org/web/*/endosquid.com
Guess they went out of business before they could typecast all these nasty empty strings.
Re: “I'm basically giving myself a permanent vacation from being BDFL”
#265Earlier quoted context omitted.
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.
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 dat…
> 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.
Re: “I'm basically giving myself a permanent vacation from being BDFL”
#266Earlier quoted context omitted.
(a := b) rather than a = b Naturally people went to the barricades for it, in a classic example of bikeshedding and Wadler's Law (programmers will fight to the death over trivial syntax disagreements and just shrug at profound changes to semantics and architecture)
Damn dude... I'm sick and tired of writing stuff like m = f( ) if m: # do stuff with m Trivial as it may be, I for one welcome this.
That's pretty much the main use of the new syntax. When you have a cascade of regexes, it is even better:
if m := re.match(...):
...
elif m := re.match(...):
...
Re: “I'm basically giving myself a permanent vacation from being BDFL”
#267I've begged GitHub to institute forms of government for repos. For X action to happen, Y percent of the pool of people in the Z list need to approve it. Membership of the Z list is granted when W percent of the T pool approve it. Modifying the rules of government of this repo can only happen when L percent of the R pool approve it. And on and on... I could imagine a city or state government actually having its laws e…
Why Github? It's like begging your electrical company to institute rules for how multi-tenant building is governed. Github is just a (admittedly major) infrastructure provider, they are not and should not be in business of enforcing governance in open-source communities, which have very diverse governance models and it's great.
Because I don't want an individual (or small group of individuals) to have authoritarian power (BDFL) over a repo.
It's the governance of the repo that I want encoded. I make a pull request, and it's decided upon by the government system.
That needs to be encoded into Github.
And yes, "the very diverse governance models" is a challenge. One I think needs to be taken up, eventually.
I don't want one jerk to have the ability to ruin a repo. I don't want to have to fork a repo when the one owner dies. When I disagree with the owner of a repo, I'd like a process to resolve it.
Re: “I'm basically giving myself a permanent vacation from being BDFL”
#268Earlier quoted context omitted.
Guido is only human. And one day, he will die. (Hopefully a long, long time from now.) Guido is not asking Python to live without a dictator. Guido is asking Python to learn how to live without Guido, so that Python may outlive him. This is a tale as old as time. Apple lives on with only memories of Steve Jobs. The United States lives on with only memories George Washington. For some inspiration I'd recommend listeni…
"Apple lives on with only memories of Steve Jobs." I think that remains to be seen.
> I think that remains to be seen.
I'm sure there's more you could have written, why hold back?
Re: “I'm basically giving myself a permanent vacation from being BDFL”
#269Earlier quoted context omitted.
> 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.
Name one.
I think it's true, but also a red herring.
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.
Re: “I'm basically giving myself a permanent vacation from being BDFL”
#270Earlier quoted context omitted.
> I think that having strong opinions on how others should be developing software is how communities become toxic like this. Depends on what you think the answer to "is programming an art or a science" is. People who build bridges are absolutely subject to "strong opinions" on how to build bridges. I am of the opinion that shipping software to others when under a contract without using all the facilities available to…
Thinking that linting and static typing will stop all errors is foolish (although I prefer both, myself). Cargo culting "best practices" is often useless, and is sometimes used as a crutch by developers who are bad at the much more important and much less quantifiable things, like code readability and architectural simplicity. Wanting your pet coding preferences to be enforced by criminal law is a sadomasochistic fan…
> Thinking that linting and static typing will stop all errors is foolish (although I prefer both, myself).
Thinking that putting a seatbelt will prevent death in a crash is foolish, and yet they are still mandatory