back to article Python creator Guido van Rossum sys.exit()s as language overlord

Guido van Rossum – who created the Python programming language in 1989, was jokingly styled as its “benevolent dictator for life”, and ushered it to global ubiquity – has stepped down, and won’t appoint a successor. In a mailing list post on Thursday titled, “Transfer of Power,” he wrote: “Now that PEP 572 is done, I don't …

  1. ST Silver badge
    Devil

    reflecting opinions more than best practice

    From The Article:

    [ ... ] some developers felt PEP 572 was a poor approach that reflected van Rossum’s opinions more than best practice.

    The same can be said about the entire Python Language.

    Actually, this has already been said about Python. Many times over.

  2. Anonymous Coward
    Anonymous Coward

    Re: reflecting opinions more than best practice

    Ah, repeating bilious burps. Annoying, those.

  3. The Man Who Fell To Earth Silver badge
    Mushroom

    Re: reflecting opinions more than best practice

    I'm old enough to know that Python is just the present "flavor of the month" programming language. It is only a matter of time before another comes along.

  4. JDX Gold badge

    Re: reflecting opinions more than best practice

    Flavour of the month for 15 years or so. It's been a widely used niche language for that time, widely espoused by developers as something that "should" take off more widely.

    In the meantime, Ruby came as a competitor... and seemingly went.

  5. MarkB

    Re: reflecting opinions more than best practice

    As ST comments, surely that's always been the case with Python, just as it's the case (as far as I can understand) with Perl - the language enshrines the opinions and prejudices of the single originator. That's part of my issues with both languages, as I'm not keen on some aspect of both Guido's and Larry's opinions and prejudices.

  6. boltar Silver badge

    Re: reflecting opinions more than best practice

    "I'm old enough to know that Python is just the present "flavor of the month" programming language"

    If using a flavour of the month language means that Perl finally crawls away and dies then thats good enough for me. Anyway, after being around this long I think its fair to say Python is part of the dev furniture now, not a newcomer.

  7. phuzz Silver badge
    IT Angle

    Re: reflecting opinions more than best practice

    It's nice to see ST getting a perfectly balanced 17 upvotes and 17 downvotes (at time of writing). That's a fine line to walk.

  8. DropBear Silver badge
    Joke

    Re: reflecting opinions more than best practice

    On the other hand, you seem a bit imbalanced with 1:0 - just say the word, I'd be happy to help...!

  9. Anonymous Coward
    Anonymous Coward

    Re: reflecting opinions more than best practice

    Flavour of the month for 15 years or so.

    In the end it seems Python beat out Ruby, PHP, JavaScript, and Lua as the king of convenience languages, which only exist because C(++) takes forever to compile nitpick your syntax to death. Now that language designers have run out of 'clever' hooks for new languages, it is only a matter of time until a master architect distills this mess into a single proper language. But not in our lifetimes.

    And that's why we can't have nice things, etc, etc. "Learn to program, build anything your heart desires!" they said. But if you want to build real software, you'll mostly be learning and relearning the intricacies of ecosystems/jungles like C++, Python, .NET, and HTML5.

    Y'all see why I'm a cynical troll?

  10. tfb Silver badge
    Alert

    Re: reflecting opinions more than best practice

    I think that's true: there are many, many questionable decisions in Python's design and it seems to gleefully ignore a lot of things that people understood how to do quite well. And that's before the gratuitous 2-3 incompatibility.

    But, it exists, it works everywhere, it has a big library. There's something to be said for that, and it almost certainly would not have happened without Guido van Rossum. It's easy for language snobs like me to snipe from the sidelines, but that's all it is: sniping.

  11. onefang

    Re: reflecting opinions more than best practice

    Phuzz was 2:2 when I read it. I'm now reluctant to upvote.

  12. tfb Silver badge
    Alert

    Re: reflecting opinions more than best practice

    You should not have asked for that. Perl has crawled off, but it's crawled off into the abyssal void beneath the world we know where it waits, surrounded by an uncountable[*] host of chittering things, waiting, waiting for the time to be right to rise again and destroy this transient thing we call the world. Even now, in the machine room late at night I catch glimpses of unspeakable things and see the trails of slime on the racks: I no longer dare look under the false floor as I know what waits there. Very soon now we will die, horribly screaming as we are slowly eaten from within. And then our world will be a memory and shortly not even that: what remains will be darkness, and Perl, as there once was and as there always will be. As there always should have been.

    [*] You understand of course what I mean by 'uncountable': there are more of them than there are rationals. I know this because I have seen them.

  13. asdf Silver badge

    Re: reflecting opinions more than best practice

    Most languages that have been around as long as Python have advantages and disadvantages. Bloat and performance have always been the knock against Python as is to be expected for what Python does, was designed for and what it gives you. As always horses for courses. Still glad its around as choice is always good and hope the community picks up the pieces well.

  14. John Smith 19 Gold badge
    Unhappy

    Actually, this has already been said about Python. Many times over.

    True.

    Think I'll still learn it though.

    It looks good enough to get the job done.

  15. John Smith 19 Gold badge
    Headmaster

    it works everywhere, it has a big library.

    Library(s) (or rather libraries).

    But you're right.

    They are all pretty big.

  16. asdf Silver badge

    Re: Actually, this has already been said about Python. Many times over.

    >It looks good enough to get the job done.

    Probably true for vast majority of use cases out there. You wouldn't want to use it say for embedded systems development though. It does have some JIT capability IIRC but horses for courses.

  17. Anonymous Coward
    Anonymous Coward

    Another language will come along

    Yes, one with curly brackets, hopefully (yes, and proper indentation as well).

    I’m sorry, but I just find code much easier to read (and write) when I can actually see the block delimiters!

  18. tfb Silver badge

    Re: it works everywhere, it has a big library.

    I was treating the collection of all the generally available modules & packages as the Python library, hence singular. Also by 'big' I meant 'large in coverage' rather than 'a lot of bytes': since I turnd off my 11/70 I've stopped worrying about counting bytes.

  19. Tom 7 Silver badge

    Re: Actually, this has already been said about Python. Many times over.

    For a while until someone 'upgrades' something. I'm finding it increasingly difficult to 'get the job done again' as code that used to work no longer does due to different choices of which version of the language/libraries to settle on,

    I'm trying to teach kids this stuff and having to take them through a virtual environment configuration for each flashy example is getting a bit fucking tedious.

  20. The Man Who Fell To Earth Silver badge

    Re JDX: reflecting opinions more than best practice

    "It's been a widely used niche language..."

    You can say the same thing about FORTRAN, COBOL, PL/I, BASIC's various forms, C's various forms, etc. They are all still around and used in their various niches. Flavor of the month does not require they become extinct when the month is over. My definition of "flavor of the month" is what fad language entry level college computer programming courses use. In my high school (in the '70's), it was a form of Assembly. In my college (also in the '70's), it was PL/I.

  21. Anonymous Coward
    Anonymous Coward

    Re: reflecting opinions more than best practice

    perl -- not so much since he went on to try to create perl6. Since then it's been a bunch of curmudgeons that want to make it more obtuse and harder to learn. In addition to a recent backtrack on relaxing explicit prefix-sigils (@%) for references (that always include their type), they even added postfix sigils -- little tails you can play "pin the tail on the var" to indicate type.

    perl's problem has been that most of those in charge know nothing about computer languages or computer science and have no formal training. A few do and that shows, but machine room operators don't make for good language designers.

    This lack of background, but having expertise in perl shows just as it shows for C++ -- the designers

    design for experts -- not new users, with ideas & projects to help and attract new users shot down as too simplistic or too DWIM'y (Do What I Mean) - one of the original design goals of perl that it's continued to drift away from. Anything that *they* wouldn't use or that deobfuscates the language is considered wrong. In addition to holes in the language that generate errors rather than provide a logical feature, they are adding more errors by taking away existing usable and useful features -- what a bonus! They don't want the language to go forward without them, so they are designing in its obsolescence. A shame really, especially since in many applications it ran 5-15 times faster than an equivalent python program -- more so if it involved parallelism.

    But when it came to new designs, they believed in nuking problems rather than applying touch-up fixes. It took about 20 years to get back to a working unicode that works the same as it did 20 years back -- if they'd just fixed binary files (vs console text files). Instead they killed the whole feature and now perl's unicode has a permanently established bug where you can read in files in a local, 8-bit encoding, and they'll be written out in a multi-byte utf-8 encoding. The believed it was better to preserve this bug for posterity for ancient (20yr+) program compatibility. On one hand they'd keep the bad, but on another hand, they have no problem destroying compatibility by adding new behaviors that would be 'non-optional'. In regard to bugs: they regard them as virtues: "Historically, we've held ourselves to a far higher standard than backward-compatibility -- bugward-compatibility. Any accident of implementation or unintentional side-effect of running some bit of code has been considered to be a feature of the language to be defended with the same zeal as any other feature or functionality -- thus bugs have been cemented into the language with the effect of crippling growth.

  22. buttler987

    Re: reflecting opinions more than best practice

    yes you are right

  23. Notas Badoff Silver badge

    Live! from your keyboard - your reputation

    Um, wow. When the BDFL (retired) is minded to point to the code of conduct and also remind everyone that maillists are public information...? It has obviously been rough riding herd on a federation of (some) foul tempers?

    Two things to note here.

    No misogyny, misandry, racism, classism, or other -isms were employed in the making of this debacle. Just people being much much less than ideal. Thus this is a good (?) example to point to, that there are way too many people out there who simply don't know how to play well together. Quit trying to out-Godwin each other, everybody loses.

    From the nature of the interactions, you have the chance to be a much *nicer*, more *intelligent* person in print than in real life. When you forget one person's name in real life you've lost one future friend. When you forget your humanity on the web, you've lost your career.

  24. Dan 55 Silver badge

    Re: Live! from your keyboard - your reputation

    I'm glad this is a site where this post receives more upvotes than downvotes. Seems most Internet commentary is a shocking cesspit.

  25. This post has been deleted by its author

  26. a_yank_lurker Silver badge

    Re: Futuristic progression of Programming Languages?

    I think if you can write the code then visual style development is a great aid because you should be able to hand to tweak the code if needed (though it probably is rarely done). Where I find visual style development a disaster waiting to happen is when the person does not understand the basics of the underlying languages and can not visualize what the code might actually look like.

  27. Anonymous Coward
    Anonymous Coward

    Re: Futuristic progression of Programming Languages?

    All hardware sucks, all software sucks, all languages suck. They all suck the same (but in different ways).

    If your eyes glow brightly when a particular language is mentioned, I'm going to treat you as radioactive!

  28. ST Silver badge
    Devil

    Re: Futuristic progression of Programming Languages?

    > they all seem kind-of C-like

    Python is like C in the same way a goat's ass is like an orchid.

    Just sayin'.

  29. thames

    Re: Futuristic progression of Programming Languages?

    A program written in Python can be a fraction of the number of lines as a program which does the same thing in C.

    Time is money, or whatever other means you want to measure the value of time in. You can get a finished program in fewer man-hours. That matters in a lot of fields where being first to market is what counts, or where you are delivering a bespoke solution to a single customer at the lowest cost, or where you have a scientific problem that needs solving without investing a lot of time in writing the software part of the project.

    Python isn't the best solution to all possible problems, but it is a very good solution to a lot of problems which are fairly prominent at this time. It also interfaces to C very nicely, which allows it to use lots of popular C libraries that already exist outside of Python itself. These are why it is popular right now.

    There is no one size fits all solution to all programming problems. It is in fact considered to be good practice to write bits of your program in C and the rest in Python if that is what makes for a better solution for your problem. There is no necessity to re-write everything in Python in the manner that certain other languages require everything to be re-written in "their" language. The result is that Python has become the language of choice for a lot of fields of endeavour where you can reuse existing industry standard C and Fortran libraries from Python.

    Van Rossum's "retirement" isn't a huge shock and won't make much difference. For quite some time other members of the community have been taking the lead in developing new features and Van Rossum's main role has been to say "no" to adding stuff that was trendy but didn't provide a lot of value. Everything should continue along find with the BDFL further in the background. Overall, it is probably a good idea to get the post-BDFL era started now while the BDFL is still around.

  30. jake Silver badge

    Re: Futuristic progression of Programming Languages?

    "All hardware sucks, all software sucks, all languages suck."

    You forgot OSes, they suck too. And worse, you forgot fanbois, who suck in all kinds of spectacular ways.

  31. jake Silver badge

    Re: Futuristic progression of Programming Languages?

    "A program written in Python can be a fraction of the number of lines as a program which does the same thing in C."

    This is both a blessing and a curse. Unfortunately, the folks who see it as a blessing will probably never fully understand why it's also a curse. Folks who know it's a curse debug code with the compiler's assembly output anyway, and don't care.

  32. The Man Who Fell To Earth Silver badge
    WTF?

    Re: Futuristic progression of Programming Languages?

    "A program written in Python can be a fraction of the number of lines as a program which does the same thing in C.

    This isn't unique to Python. And it's only a "blessing" in limited circumstances when writing pedestrian software were knowing what is really going on is deemed unimportant.

  33. Wilco
    Coat

    Re: Futuristic progression of Programming Languages?

    "All hardware sucks, all software sucks, all languages suck. They all suck the same (but in different ways)."

    ... except Scala, obvs

    Mine's the one with the trefoil on the back ...

  34. AndrueC Silver badge
    Thumb Up

    Re: Futuristic progression of Programming Languages?

    All hardware sucks, all software sucks, all languages suck...

    Yes, and as was already pointed out 'all operating systems suck'. I learnt that one back in the 90s when I briefly became an OS/2 fanboi. Since then I've forced/taught myself to use whatever is most suited to the task. Of course some of that 'suitability' is 'what managers/customers/the market wants' but a good engineer is a pragmatic engineer ;)

    So for now it's Windows and C# for me in the main. With luck that'll see me through another few years until I retire. Beyond that I will endeavour to try and not care.

  35. Vincent Ballard

    Re: Futuristic progression of Programming Languages?

    90%+ of software is pedestrian.

  36. FeRDNYC

    Re: Futuristic progression of Programming Languages?

    You forgot OSes, they suck too. And worse, you forgot fanbois, who suck in all kinds of spectacular ways.

    Yes, well, the value of pointing out that all hardware, software, and OSes suck is to remind us to focus on an individual example's positives, rather than its negatives, because they all have negatives.

    There are no redeeming positives to fanbois, though, so there's less value in noting that they all suck, even though they most certainly do. They suck not only individually but collectively, and they should be dismissed in the same manner: Begone, all ye fanbois!

  37. The Indomitable Gall

    Re: Futuristic progression of Programming Languages?

    I agree that visual programming is very limited.

    I think the future of code is in frame-based programming. Check out the Stride programming language used in the Greenfoot and BlueJ educational IDEs. It's designed to let you develop traditional line-paradigm code more efficiently by reducing the number of keystrokes and making syntax errors impossible and scope errors rare.

    Every type of code statement has a limited range of possible syntaxes, so Stride turns each statement type into a template where you fill in the boxes. As an educational programming language, Stride maps to a subset of Java, and any Java code can be called from Stride.

    It also renders the block delimiters vs meaningful whitespace debate moot, as blocks, scopes and indentation are handled by the editor automatically as the programmer is no longer dealing with plaintext.

    I think this frame-based paradigm has real potential to change coding practices in a way visual coding never really did.

  38. Nick Kew Silver badge

    Reinventing a more limited wheel

    I clicked the PEP 572 link. Seems to me that everything claimed for it has been accomplished by the C comma list since before Python was ever indented.

    (Never Python's greatest fan - can you tell?)

  39. thames

    Re: Reinventing a more limited wheel

    I would be fascinated to hear how you would do the following in one line of idiomatic C using commas.

    results = [(x, y, x/y) for x in input_data if (y := f(x)) > 0]

    The major objective appears to be avoiding duplicating work unnecessarily when doing multiple things in a single expression. The previous way of doing the above would have been:

    results = [(x, f(x), x/f(x)) for x in input_data if f(x) > 0]

    I can think of multiple instances in which I could have used this feature in cases similar to the above.

  40. Flocke Kroes Silver badge

    Re: Reinventing a more limited wheel

    No because this is not about comma lists, which have very context dependent meanings in both languages. It is not about the comma operator, which in C means calculate the left argument for side effects and return the right argument (in python, the , operator creates a tuple of the two or more arguments). This is about expressions, statements and assignments. Both languages have contexts where an expression is permitted but not a statement, for example C: "while(expression) statement or {statement list}" and python: "while expression: statement or indented block". The difference was that in C assignments are expressions but in python assignments had to be statements. (Both languages allow using an expression where a statement is expected).

    The new feature in python is an extra assignment operator (:=) so assignment expressions are now possible. In the past, converting C: "if (a=b) {...}" to python required the assignment to be in a separate statement from the condition making it abundantly clear that the programmer did not intend C: "if (a==b) {...}". Python will now allow: "if (a:=b): ..."

    This has clearly caused a blood feud between different styles of language designers. On one hand, some people think that best practices must be forced down the throat of all programmers because some of them have to create insane code when the language allows it. Other people think that programmers that dumb are going to fuck up no matter what the language enforces, so the language should rely on the sensible programmers' self discipline to follow best practices and not get in the way when a programmer has an outstanding reason to do something odd.

    Before you reply that clearly python has lacked C's assignment operator for years, there are plenty of things that C++ has attempted to copy from python (or whatever language python copied from), and often still struggles to get close to tolerable.

  41. tb7842676

    Re: Reinventing a more limited wheel

    [(x, y, x/y) for x, y in ((x, f(x)) for x in input_data) if y > 0]

    The new syntax is using less characters. This appeals to many programmers but I thought Python was not such a language.

  42. Tom 38 Silver badge

    Re: Reinventing a more limited wheel

    I would be fascinated to hear how you would do the following in one line of idiomatic C using commas.

    Well newlines are optional, and there is no limit on the number of statements per line, so pretty easy.

  43. Tom 38 Silver badge

    Re: Reinventing a more limited wheel

    [(x, y, x/y) for x, y in ((x, f(x)) for x in input_data) if y > 0]

    The new syntax is using less characters. This appeals to many programmers but I thought Python was not such a language.

    At $JOB, that would immediately fail code review. Nested list comprehensions are hard to comprehend, particularly compared to assignment expressions, and disguise their purpose. Lets run through how many PEP-20 violations that is - its ugly, its complex, its nested, its dense and it has poor readability.

  44. rgmiller1974

    Re: Reinventing a more limited wheel

    I'm curious about the example thames posted. Is

    results = [(x, f(x), x/f(x)) for x in input_data if f(x) > 0]

    really any slower than

    results = [(x, y, x/y) for x in input_data if (y := f(x)) > 0] ?

    In the first expression, I can see that f(x) could potentially be evaluated three times, but would that actually happen? The example implicitly assumes that f(x) returns the same value each time it's evaluated. If that's the case, is the interpreter not smart enough to cache the result of f(x) for later use? (And if that's not the case - for example if f(x) returned x+time.time() - then the two expressions above aren't actually equivalent.)

  45. thames

    Re: Reinventing a more limited wheel

    @rgmiller1974 said: "I'm curious about the example thames posted. Is ... really any slower than ..."

    The interpreter doesn't cache the results of f(x), and I doubt it would be feasible to determine if it could do so in all cases. Static analysis couldn't determine that since function "f" could be written in another language (e.g. 'C') for which you might not even have the source code and dynamic analysis would run into similar problems.

    The new syntax achieves the same result under the control of the programmer as well as being useful in other applications. Plus, you can see what is going on without having to analyse the behaviour of f.

  46. Phil Endecott Silver badge

    Re: Reinventing a more limited wheel

    > results = [(x, y, x/y) for x in input_data if (y := f(x)) > 0]

    That would surely be much more understandable in multiple lines:

    vector<T> results;

    for (x: input_data) {

    auto y = f(x);

    if (y > 0) results.append( make_tuple(x,y,x/y) );

    }

    ...if that’s what it actually does....

  47. Claptrap314 Bronze badge
    Facepalm

    Re: Reinventing a more limited wheel

    No, and that is precisely the point. If you think that

    results = [(x, f(x), x/f(x)) for x in input_data if f(x) > 0]

    is in any way equivalent to

    results = [(x, y, x/y) for x in input_data if (y := f(x)) > 0]

    then I don't want you on my team, and may I never be affected by any your code.

    There is absolutely no way to ensure that f(x) is idempotent. If you don't understand that, then step away from the keyboard.

  48. FeRDNYC

    Re: Reinventing a more limited wheel

    The new syntax is not only using fewer characters, it's far clearer about what's actually going on than your example. Yes, you have to wrap your brain around the := operator, but that's just syntax and syntax is trivial. But when you compare your version:

    [(x, y, x/y) for x, y in ((x, f(x)) for x in input_data) if y > 0]

    vs. the PEP 572 version:

    results = [(x, y, x/y) for x in input_data if (y := f(x)) > 0]

    The fact that there will be a result for every item in the input_data list and that y = f(x) in the output are both made far clearer and more obvious in the latter form.

  49. FeRDNYC

    Re: Reinventing a more limited wheel

    Nested list comprehensions are hard to comprehend

    I'm impressed how you seemingly managed to say that without a trace of irony.

  50. Anonymous Coward
    Anonymous Coward

    Re: Reinventing a more limited wheel

    @Tom 38: Glad you mentioned it also. That code line is fucking horrendous. Just because you can do something in one line doesn't mean you should. Likewise I find that line to be a violation of the principles relating to code readability.

Page:

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2018