Python post-Guido(lwn.net)
lwn.net
Python post-Guido
https://lwn.net/SubscriberLink/759756/931b0f4617723184/
106 comments
> Just another BDFL, that's it.
I think a lesson to take from this is that the concept of a "BDFL" doesn't really stand up. Putting an individual in charge dramatically increases the chances that they will suffer some kind of burn out compared to a situation where there are more people to share the burden with. That means the "For Life" part is more like "until they decide it's not worth the grief".
It's also clear that the "Dictator" part isn't really true; the stated reason for Guido leaving the project was the difficulty he had in getting the wider community to agree to a change he was in favour of.
The idea that having a single individual in charge produces a consistency of design seems false over the long term. Each time you burn through one leader you have to pick a new one who might have a relatively different aesthetic sense or set of priorities. And individuals change. Someone who was indifferent to functional programming, for example, in 1995 could be a huge advocate of it 20 years later, making quite different design decisions as a result.
Instead I would strongly encourage the Python community to look at what the Rust community have been doing. Leadership there is group-based, and the core team sets out an explicit vision for the project each year. This allows feedback from the community on direction and enables changes to be assessed against the explicit shared vision (vs assuming that vision exists in someone's head in the BDFL model). Ther exists a process for making changes that ensures that all (unique) feedback is considered before making a change, so that when decisions are made they're made based on shared facts. There is also emphasis on growing contributers into leadership positions, which togther with the team-based approach provides continuity when people move on from the project.
I'm not claiming it's a perfect system, but it seems to be working relatively well in a language that is going through a much more active phase (in terms of adding features) than Python.
I think a lesson to take from this is that the concept of a "BDFL" doesn't really stand up. Putting an individual in charge dramatically increases the chances that they will suffer some kind of burn out compared to a situation where there are more people to share the burden with. That means the "For Life" part is more like "until they decide it's not worth the grief".
It's also clear that the "Dictator" part isn't really true; the stated reason for Guido leaving the project was the difficulty he had in getting the wider community to agree to a change he was in favour of.
The idea that having a single individual in charge produces a consistency of design seems false over the long term. Each time you burn through one leader you have to pick a new one who might have a relatively different aesthetic sense or set of priorities. And individuals change. Someone who was indifferent to functional programming, for example, in 1995 could be a huge advocate of it 20 years later, making quite different design decisions as a result.
Instead I would strongly encourage the Python community to look at what the Rust community have been doing. Leadership there is group-based, and the core team sets out an explicit vision for the project each year. This allows feedback from the community on direction and enables changes to be assessed against the explicit shared vision (vs assuming that vision exists in someone's head in the BDFL model). Ther exists a process for making changes that ensures that all (unique) feedback is considered before making a change, so that when decisions are made they're made based on shared facts. There is also emphasis on growing contributers into leadership positions, which togther with the team-based approach provides continuity when people move on from the project.
I'm not claiming it's a perfect system, but it seems to be working relatively well in a language that is going through a much more active phase (in terms of adding features) than Python.
To any ecosystem that's considering adopting our governance model: we love it, but it does have some drawbacks. We've changed the implementation a few times over the years, and are considering more change. See here for the latest: http://smallcultfollowing.com/babysteps/blog/2018/06/20/prop...
Happy to talk more with anyone who's interested in this topic. :)
Happy to talk more with anyone who's interested in this topic. :)
> That means the "For Life" part is more like "until they decide it's not worth the grief".
That is what “for life” means lots of the time outside of BDFL, too.
Federal judges retire, too. Monarchs and even regular, non-benevolent dictators abdicate or otherwise step down.
That is what “for life” means lots of the time outside of BDFL, too.
Federal judges retire, too. Monarchs and even regular, non-benevolent dictators abdicate or otherwise step down.
I like the idea of a triumvirate, three people with a shared vision but perhaps with unique skills [0]. Hopefully all sharing a benevolent tendency to avoid things going pear-shaped [1].
[0] https://lwn.net/Articles/759798/
[1] https://en.wikipedia.org/wiki/First_Triumvirate
[0] https://lwn.net/Articles/759798/
[1] https://en.wikipedia.org/wiki/First_Triumvirate
Honestly I think the idea of a council of four is better. If they can't come to an agreement, then Python isn't changed.
You know the triumvirates resulted in the fall of the republic, right? Power doesn't like to be shared...
You could say the same thing about dictators. The problem is not the power structure, but whether they are meant to be benevolent or not.
You could also say that a triumvirate is better than a dictatorship since there would be a small system of checks in place (not saying that Guido was being pushy with his position of BDFL, but it would be nice to see other ideas having as much ground as one person's ideas).
You could also say that a triumvirate is better than a dictatorship since there would be a small system of checks in place (not saying that Guido was being pushy with his position of BDFL, but it would be nice to see other ideas having as much ground as one person's ideas).
Sulla and Marius had pretty well smashed the republic a generation before. Not that Rome was ever really the idealized representation of a Republic that everyone at all points in time considered it had become debauched from.
> You know the triumvirates resulted in the fall of the republic, right?
I think its more defensible to stay they were symptoms of the ongoing collapse than causes.
I think its more defensible to stay they were symptoms of the ongoing collapse than causes.
Raymond Hettinger for BDFL! :)
metalliqaz(2)
I seconded Raymond Hettinger. He is a very experienced developer and is much respected one. If he does not want the role, perhaps Victor Stinner can do the job.
I see you share the opinions of Plato's Republic. But philosopher-kings are always in such short supply...
Again and again AMEN.
I would accept a PCOE with lifetime appointments and confirmation by core contributors but turning it to a full democracy seems likely to change the things I love most about the language
I would accept a PCOE with lifetime appointments and confirmation by core contributors but turning it to a full democracy seems likely to change the things I love most about the language
here's my plan
1. elect anyone as BDFL
2. new BDFL announces they will pass a few PEP Guido was adamant against, because, well, now they are the BDFL
3. Guido realizes the mistake and we have the good old BDFL a while longer
1. elect anyone as BDFL
2. new BDFL announces they will pass a few PEP Guido was adamant against, because, well, now they are the BDFL
3. Guido realizes the mistake and we have the good old BDFL a while longer
Interesting that Guido finally gave up dealing with the haters at roughly the same time that Py2 is finally being replaced by Py3. It's almost as if there is some kind of maturity milestone that has been crossed, and it's time for things to change for good.
[deleted]
I hope for another BDFL or at least a king. Democracy is going to be a mess. Choose someone who wants to do it, agrees with Guido on as many as possible fundamental things and isn't too much of a revulotionary please.
This is speculative, but project dictators might be too risky for succession. They can be good at managing the project, they can be bad at managing the project, and there's no reliable way to tell in advance.
Guido was good. If he hadn't been good, Python wouldn't have caught on like it did. If someone who starts a small project turns out to be bad at it, that's no great loss - there are a lot of small projects. You don't see the ones that fail.
But if you put someone in charge of a large project and they mess it up, that's a large problem. It's better to go for a safe option with a reasonable expected value than for the option with the highest best-case value.
Guido was good. If he hadn't been good, Python wouldn't have caught on like it did. If someone who starts a small project turns out to be bad at it, that's no great loss - there are a lot of small projects. You don't see the ones that fail.
But if you put someone in charge of a large project and they mess it up, that's a large problem. It's better to go for a safe option with a reasonable expected value than for the option with the highest best-case value.
Dennis: What I object to is you automatically treatin' me like an inferior.
Arthur: Well, I am king.
Dennis: Oh, king, eh? Very nice. And how'd you get that, then? By exploiting the workers! By hanging on to outdated imperialist dogma which perpetuates the economic and social differences in our society! If there's ever going to be any progress--
Dennis: We're an anarcho-syndicalist commune. We take it in turns to act as sort-of-executive officer for the week--
Arthur: Yes.
Dennis: But all the decisions of that officer have to be ratified at a special biweekly meeting--
Arthur: Yes, I see.
Dennis: By a simple majority, in the case of purely internal affairs--
Arthur: [getting bored] Be quiet.
Dennis: But by a two thirds majority, in the case of more major--
Arthur: Be quiet! I order you to be quiet!
Dennis' Mother: Order, eh? Who does he think he is?
Arthur: I am your king!
Dennis' Mother: Well I didn't vote for you.
Arthur: You don't vote for kings!
Dennis' Mother: How'd you become king, then?
Arthur: The Lady of the Lake, [Angel chorus begins singing in background] her arm clad in the purest shimmering samite, held aloft Excalibur from the bosom of the water signifying by Divine Providence that I, Arthur, was to carry Excalibur. [Angel chorus ends] That is why I am your king!
Dennis: Listen. Strange women lying in ponds distributing swords is no basis for a system of government. Supreme executive power derives from a mandate from the masses, not from some farcical aquatic ceremony.
Arthur: Be quiet!
Dennis: You can't expect to wield supreme power just 'cause some watery tart threw a sword at you!
Arthur: Shut up!
Dennis: I mean, if I went 'round saying I was an emperor just because some moistened bint had lobbed a scimitar at me, they'd put me away!
Arthur: Shut up! Will you shut up?! [Grabs Dennis and shakes him]
Dennis: Ah, now we see the violence inherent in the system!
Arthur: Shut up!
Dennis: Oh! Come and see the violence inherent in the system! Help! Help! I'm being repressed!
OK, now that's cool. I wonder if Christian Heimes saw my post† on the HN topic on the 12th, or if we both proposed the idea independently?
†: https://news.ycombinator.com/item?id=17516186
†: https://news.ycombinator.com/item?id=17516186
Guido's leadership has really been what's kept Python so consistent during its evolution. This is in contrast to languages governed by committee or corporation.
Hopefully Python continues to be guided in this manner, and Guido can help rally the Python community around a successor.
Hopefully Python continues to be guided in this manner, and Guido can help rally the Python community around a successor.
[deleted]
Why not try a president of Python every 4 years with no term limits? Similar to BDFL, except there are chances for change and a consistent voice throughout a term. Voters would consist of core devs and PSF.
Basically the Debian model. It has some drawbacks.
[deleted]
I'm just hoping this leads to a more multiparadigm Python that doesn't have a seemingly irrational fear of FP
This comment puzzles me. For one, I can't recall meeting a stong FP proponent that accepts anything less than a language designed from the ground-up to be true FP. Second, how is Python afraid of FP? This[1] document has been part of the Python docs for as long as I can remember.
[1] https://docs.python.org/2/howto/functional.html
[1] https://docs.python.org/2/howto/functional.html
I’m not a strong FP proponent per se. I just really enjoy using things like Java 8 Streams, Lodash/Ramda, etc. Comprehensions are nice but they have a more limited scope than functions. Honestly the same can be said for decorators. Useful, but ultimately not much more useful than a plain old higher order function.
I love functional style and I think Python is very friendly to that style. You can make pure functions. You can use classes as store of values. Pass values and functions around as they are first class citizens.
That you need some local state to implement a pure function isn't a problem as you can limit it to very simple things. Anonymous functions are not something you need either, just give it a name and pass it, wtp?
I agree most of the "Python is not functional enough" criticism comes from people who just want as pure FP as possible.
That you need some local state to implement a pure function isn't a problem as you can limit it to very simple things. Anonymous functions are not something you need either, just give it a name and pass it, wtp?
I agree most of the "Python is not functional enough" criticism comes from people who just want as pure FP as possible.
Some people think, because python is not fully embracing functional programming, it must fear it. Because anything less than 100% functional is not good enough. Namly the limited lambdas are always brought as a reason.
Most lisps are multiparadigm, and few would claim lisps are anti FP.
I think Python is considered anti FP for two reasons: when suggestions to add more FP features have been raised, Guido has fairly unambiguously rejected those features.
That’s all fine though. Python can do what Python wants. All else being equal, I’d prefer a little more functional flavor than Python has, but I won’t turn my nose up at writing Python if duty calls.
I think Python is considered anti FP for two reasons: when suggestions to add more FP features have been raised, Guido has fairly unambiguously rejected those features.
That’s all fine though. Python can do what Python wants. All else being equal, I’d prefer a little more functional flavor than Python has, but I won’t turn my nose up at writing Python if duty calls.
Many programming languages these days have FP tendencies.
However I can barely think of another mainstream and high level language that is more anti-FP than Python.
And lambdas, in spite of popular opinion, have nothing to do with it ;-)
(Actually I can think of another language that is more anti-FP than Python and that would be Go ... people saying Go is “pythonic” have it right)
However I can barely think of another mainstream and high level language that is more anti-FP than Python.
And lambdas, in spite of popular opinion, have nothing to do with it ;-)
(Actually I can think of another language that is more anti-FP than Python and that would be Go ... people saying Go is “pythonic” have it right)
I'd be curious which of JavaScript, perl, js, and Ruby (and hell, go or Java, which are often considered high level) is more friendly to fp than python, and why, obviously. That's pretty much every other mainstream high level language ;)
I've never heard anyone call go pythonic.
I've never heard anyone call go pythonic.
> I'd be curious which of JavaScript, perl, js, and Ruby (and hell, go or Java, which are often considered high level) is more friendly to fp than python, and why, obviously.
JS (which you listed twice), Perl (5 or 6), and in some ways Ruby (which is a mixed bag, because it doesn't actually have functions per se, but even so is in many ways more friendly to functional style than Python.)
Being expression-oriented languages with full support for anonymous functions (callables in Ruby) and non-awkward creation of full (rather than read-only) closures are the main common factors.
JS (which you listed twice), Perl (5 or 6), and in some ways Ruby (which is a mixed bag, because it doesn't actually have functions per se, but even so is in many ways more friendly to functional style than Python.)
Being expression-oriented languages with full support for anonymous functions (callables in Ruby) and non-awkward creation of full (rather than read-only) closures are the main common factors.
Sorry, php, not js the second time.
I'm not sure what you mean by read only closures, unless you mean a close which can later modify the enclosing scope, which python supports via the nonlocal keyword but also is decidedly bad, and not something I've ever before heard of as an fp concept.
And as far as I can tell, your entire argument reduces to better lambdas. Which is what you said it wouldn't be. I feel misled. Oh wait you're a different user. Still this point stands. I wouldn't have responded if the expected answer was "better lambdas". You can do better.
I guess the next important question is "what are the things you feel make a language functional, and why are those things valuable"?
There are lots of aspects of functional programming that are good, I personally agree that anonymous functions are not one of them, especially when you have no need for callbacks (python doesn't really).
And it's very possible to write functional code, imo, without anonymous functions. Why do you disagree.
I'm not sure what you mean by read only closures, unless you mean a close which can later modify the enclosing scope, which python supports via the nonlocal keyword but also is decidedly bad, and not something I've ever before heard of as an fp concept.
And as far as I can tell, your entire argument reduces to better lambdas. Which is what you said it wouldn't be. I feel misled. Oh wait you're a different user. Still this point stands. I wouldn't have responded if the expected answer was "better lambdas". You can do better.
I guess the next important question is "what are the things you feel make a language functional, and why are those things valuable"?
There are lots of aspects of functional programming that are good, I personally agree that anonymous functions are not one of them, especially when you have no need for callbacks (python doesn't really).
And it's very possible to write functional code, imo, without anonymous functions. Why do you disagree.
Ruby has multi line lambdas and code blocks. Python doesn't. However we can't pass a function as argument (actually a method but it could be a def in a module). We can pass a symbol with the name of the fuction. We can pass the function in Python.
I write very few classes in Python. I tend to write modules and import them. It's what I do in Elixir, obviously.
However I don't write much Ruby code outside Rails and Rails is definitely object oriented and directs the developer to write OO code. Instead the most popular web framework for Python, Django, is almost anarchy, anything will do.
I write very few classes in Python. I tend to write modules and import them. It's what I do in Elixir, obviously.
However I don't write much Ruby code outside Rails and Rails is definitely object oriented and directs the developer to write OO code. Instead the most popular web framework for Python, Django, is almost anarchy, anything will do.
> However we can't pass a function as argument
Right, Ruby doesn't have functions at all, so you can't pass them. This is why Ruby isn't simply better than Python here, though I'd say it's still mostly better.
> We can pass a symbol with the name of the fuction.
No, you can either convert the name to a callable and pass that, or for some methods you can pass the name of a method you'd like called on an object that the called method will get somewhere else. This isn’t esuivslent to having the name of a function. Instead, its a facility that is usually offered by a method to provide a more concise alternative to passing an equivalent block for a no-arg method. E.g.:
Right, Ruby doesn't have functions at all, so you can't pass them. This is why Ruby isn't simply better than Python here, though I'd say it's still mostly better.
> We can pass a symbol with the name of the fuction.
No, you can either convert the name to a callable and pass that, or for some methods you can pass the name of a method you'd like called on an object that the called method will get somewhere else. This isn’t esuivslent to having the name of a function. Instead, its a facility that is usually offered by a method to provide a more concise alternative to passing an equivalent block for a no-arg method. E.g.:
enum.inject(start, :foo)
enum.inject(start) { |obj| obj.send(:foo) }
> No
I think they're referring to Symbol#to_proc.
I think they're referring to Symbol#to_proc.
There has been some pushback on the inclusion of common functional idioms in Python, though. For example, GvR has expressed regret about allowing map, filter, etc. into Python, on the grounds that comprehensions are a more Pythonic way to accomplish most of the same stuff.
I assume it's because of this...
Zen of Python: There should be one-- and preferably only one --obvious way to do it.
Zen of Python: There should be one-- and preferably only one --obvious way to do it.
True, but, if it were just that, I would expect Python to only have the map, filter, etc. functions, which have been in there since 1.0. List comprehensions were introduced much later, in version 2.
That makes comprehensions the 2nd way to do it. They're also less obvious in my book, since their readability tends to drop precipitously once you start adding multiple "for" clauses to one.
That makes comprehensions the 2nd way to do it. They're also less obvious in my book, since their readability tends to drop precipitously once you start adding multiple "for" clauses to one.
But comprehensions are also a functional idiom.
Yeah, sorry, I didn't mean to say that Python's not functional without a "map" function. More trying to guess where that perception comes from. Python's comprehensions are (I believe) inspired by Haskell, but, if you're not a Haskeller, you're probably more used to other ways of doing things.
The version Python has is awkward to work with, to the point that many Haskell programmers don't even realise it exists. The "do notation" style is much clearer than the "comprehension" style; unfortunately Python has no equivalent.
FP means referential transparency. For-comprehensions operate on iterators and iterators are not FP, being a very dirty and mutable protocol.
Do not confuse FP with declarative programming or with laziness. FP often implies declarative APIs and laziness but not vice-versa.
Do not confuse FP with declarative programming or with laziness. FP often implies declarative APIs and laziness but not vice-versa.
Python's comprehensions were lifted from Haskell, and its map and filter functions also operate on iterables. They can't be purely functional because of the surrounding language, but they do follow a functional style.
(expr for item in iterable if cond) is more or less another way to spell map(lambda item: expr, filter(lambda item: cond, iterable)), except readable.
You could define "functional programming" to absolutely require referential transparency, but that's not what the rest of the thread is doing.
(expr for item in iterable if cond) is more or less another way to spell map(lambda item: expr, filter(lambda item: cond, iterable)), except readable.
You could define "functional programming" to absolutely require referential transparency, but that's not what the rest of the thread is doing.
I don't mean to be pedantic but IIRC Python's comprehensions actually came from the SETL language.
Obviously it's ultimately the same thing either way, but that's the lineage (SETL -> ABC -> Python).
https://en.wikipedia.org/wiki/SETL
Obviously it's ultimately the same thing either way, but that's the lineage (SETL -> ABC -> Python).
https://en.wikipedia.org/wiki/SETL
I didn't know about SETL, that's interesting.
https://docs.python.org/3/howto/functional.html#generator-ex... claims Python borrowed them from Haskell, but the ABC link seems more likely.
https://docs.python.org/3/howto/functional.html#generator-ex... claims Python borrowed them from Haskell, but the ABC link seems more likely.
ABC didn't have list comprehensions though, in spite of being influenced by SETL.
As I recall, Python did get them from Haskell, which in turn got them from Miranda, which got them from KRC. Before that it gets fuzzy, but it's likely that SETL was eventually at the root of it.
As I recall, Python did get them from Haskell, which in turn got them from Miranda, which got them from KRC. Before that it gets fuzzy, but it's likely that SETL was eventually at the root of it.
[deleted]
[deleted]
Python will never be FP friendly, even if there have been certain attempts in the past. The reason is that at its core Python is very statement and mutation oriented, instead of being expression oriented and to prefer immutability by default, like all FP languages are.
People feel the need for example for anonymous functions that support statements but Python’s lambdas only support expressions and it turns out there’s not much you can do with those in Python. It’s the reason for why over the years Python acquired features for use cases that can normally be solved via higher order functions in other languages like Ruby.
I think it is time to accept Python for what it is. A dirty, mutable language that gets the job done in certain contexts. Trying to change it I think does more harm than good.
People feel the need for example for anonymous functions that support statements but Python’s lambdas only support expressions and it turns out there’s not much you can do with those in Python. It’s the reason for why over the years Python acquired features for use cases that can normally be solved via higher order functions in other languages like Ruby.
I think it is time to accept Python for what it is. A dirty, mutable language that gets the job done in certain contexts. Trying to change it I think does more harm than good.
As a corollary I think the lack of adoption of 'pure' languages, even after decades of trying, is evidence that they are just less productive than 'dirty' languages like python. Libraries and community are just much more important than the language itself.
The pure-functional features have gradually been adopted. It's hard to imagine a new general-purpose language coming out without map/reduce/filter, or without some form of typing with generics and inference, or without pattern-matching. It's hard to remember that these things were all seen as pure-functional nonsense a decade or two ago.
I'd argue that the more pure FP languages have a higher learning curve, but that doesn't equate lower productivity. Plenty of people are productive in FP languages, and there are a good number of FP languages with decent adoption throughout the industry. They might not be as widely adopted as Python, but that's because it's really easy to learn Python.
There's productivity at the level of an individual developer, and productivity at the level of an enterprise.
Just because an individual or a small team can be highly productive in say, Haskell, doesn't mean it makes sense for the whole company.
In Finance, the area I work in, the only FP success stories that come immediately to mind are a couple of teams at Standard Chartered for Haskell, and Jane Street Capital for OCaml. And they are notable for their rarity, not because there are plenty of other comparable examples.
Just because an individual or a small team can be highly productive in say, Haskell, doesn't mean it makes sense for the whole company.
In Finance, the area I work in, the only FP success stories that come immediately to mind are a couple of teams at Standard Chartered for Haskell, and Jane Street Capital for OCaml. And they are notable for their rarity, not because there are plenty of other comparable examples.
My experience is that pure FP languages have enormous individual productivity but that comes at the expense of lower team productivity/collaboration (my experience, even if not universal or even correct, is that in practice they are fairly idiomatic from developer to developer) and maintenance over time can be an issue for similar reasons. For simple systems and system management scripting, I will take the simpler language.
That said, I'd want a very high concurrence system written in a function language over Python any day (gil notwithstanding). But I'm fine with Python not being that language.
That said, I'd want a very high concurrence system written in a function language over Python any day (gil notwithstanding). But I'm fine with Python not being that language.
...is precisely the attitude that killed perl.
I don't want the extreme strictness of haskell or F# but I'd rather be edging in that direction rather than edging in perl's direction. 572 was definitely the latter.
I don't want the extreme strictness of haskell or F# but I'd rather be edging in that direction rather than edging in perl's direction. 572 was definitely the latter.
The problem with the lack of adoption argument is that the only paradigms that saw widescale adoption was imperative and oop; its difficult to imagine that we as an industry picked so well on the first try (imperative) that only oop could compete, and even then is treated as an extension of imperative than full-on oop. Especially when its easy to imagine viable reasons for the paradigm's success not based on merit: inertia, market economics, network effects, luck, piggybacking off unix's merit, ease of learning (compared to previous major languages), etc.
Hell, even as you claim, libraries/communities is a chicken and egg problem, and its certainly easier to build a community on a familiar language/paradigm, than a different one.
Its a big ask to assume that it boils down to productivity, especially when most alternatives are completely unknown to most: imperative, oop, and recently functional are the only options non-academics would usually imagine. Concatenative, stack-based, logical, etc are gone from the conversation long before productivity ever comes into play.
At best, the productivity question is likely just a short term one: it costs little up-front to jump from C to Python, compared to C to Haskell. The long-term productivity question is more likely than not, not actually in play. And presumably even haskellers don't think of a proper comparison against C, in the long-term benefits (they'll usually note C's weaknesses against haskell's strengths, but not vice-versa; the C programmers will do the same in C's favor)
Hell, even as you claim, libraries/communities is a chicken and egg problem, and its certainly easier to build a community on a familiar language/paradigm, than a different one.
Its a big ask to assume that it boils down to productivity, especially when most alternatives are completely unknown to most: imperative, oop, and recently functional are the only options non-academics would usually imagine. Concatenative, stack-based, logical, etc are gone from the conversation long before productivity ever comes into play.
At best, the productivity question is likely just a short term one: it costs little up-front to jump from C to Python, compared to C to Haskell. The long-term productivity question is more likely than not, not actually in play. And presumably even haskellers don't think of a proper comparison against C, in the long-term benefits (they'll usually note C's weaknesses against haskell's strengths, but not vice-versa; the C programmers will do the same in C's favor)
Some FP constructs can be productive even in a “dirty, mutable language”. It works well for JavaScript, at least.
I'm not a fan of 'multiparadigm'. As another comment on this branch says, the Zen of Python covers this quite well:
> There should be one-- and preferably only one --obvious way to do it
There are already 20 different ways of solving any given problem or of coding any given solution. At least if a single paradigm is used, then those familiar with it are unlikely to run into big surprises about how things are implemented. If your developers are used to an imperative style, a chunk of code in the middle of the codebase written in a strongly functional style is very difficult to comprehend.
In one tool I wrote for work, I use function application to progressively transform a stream of events. It's a beautiful, neat solution to the problem, but confuses the hell out of everyone else because they've never written any Haskell. There are other ways to implement this that are just as clear and abstracted and maybe they take slightly more code, but it is code that is more maintainable by everyone else. Good code to me is not that which looks like it was coded by a genius, but that which looks like any child could have written it. For some code this is very hard, but I find it easier in Python than other languages.
The more 'choices' that you have, the more inconsistency there will be about who chooses what. There is obviously a tradeoff here with giving developers the right tools for the job, but list comprehensions are a great example of how you can do that without having to use a different paradigm.
> There should be one-- and preferably only one --obvious way to do it
There are already 20 different ways of solving any given problem or of coding any given solution. At least if a single paradigm is used, then those familiar with it are unlikely to run into big surprises about how things are implemented. If your developers are used to an imperative style, a chunk of code in the middle of the codebase written in a strongly functional style is very difficult to comprehend.
In one tool I wrote for work, I use function application to progressively transform a stream of events. It's a beautiful, neat solution to the problem, but confuses the hell out of everyone else because they've never written any Haskell. There are other ways to implement this that are just as clear and abstracted and maybe they take slightly more code, but it is code that is more maintainable by everyone else. Good code to me is not that which looks like it was coded by a genius, but that which looks like any child could have written it. For some code this is very hard, but I find it easier in Python than other languages.
The more 'choices' that you have, the more inconsistency there will be about who chooses what. There is obviously a tradeoff here with giving developers the right tools for the job, but list comprehensions are a great example of how you can do that without having to use a different paradigm.
>> There should be one-- and preferably only one --obvious way to do it
And then it offers 20 equally good ways: generators vs comprehensions vs iterators vs foreach loops vs map and filter, async vs threadpools vs processpools, and so on.
And then it offers 20 equally good ways: generators vs comprehensions vs iterators vs foreach loops vs map and filter, async vs threadpools vs processpools, and so on.
It's tough to adhere to that principle, but its nice to see as a focus. Python wasn't even object oriented originally (and a lot of their standard library shows it). Guido has said he wishes he never added functional concepts like map and filter. Deprecating things hasn't been taken too well by the community.
The first public release of Python, 0.9.1, was object-oriented. It had classes, and everything was an object internally, although admittedly not every type had methods yet (from a user perspective), esp. immutable types like tuples, strings and numbers. These methods wouldn't appear until 2.0, if I recall correctly. Types like lists and dicts had methods from the start.
> I'm not a fan of 'multiparadigm'. As another comment on this branch says, the Zen of Python covers this quite well:
>> There should be one-- and preferably only one --obvious way to do it
Unfortunately this was true ten years ago. Now, python is just following C++ and become this behemoth of features, especially with recent PEPs, which aim at saving one or two lines of code.
>> There should be one-- and preferably only one --obvious way to do it
Unfortunately this was true ten years ago. Now, python is just following C++ and become this behemoth of features, especially with recent PEPs, which aim at saving one or two lines of code.
I am a fan of dynamic functional languages, I use them more than I use Python anyway. But I think Python should stick to being Pythonic. There should be less ways of doing the same thing not more.
I don't even like the new assignment PEP because it just adds more complexity and more ways of doing the same thing. And knowing that it was the straw that broke the camel's back and pushed Guido away, makes me like it even less.
I don't even like the new assignment PEP because it just adds more complexity and more ways of doing the same thing. And knowing that it was the straw that broke the camel's back and pushed Guido away, makes me like it even less.
...but people hating on the PEP (and refusing to accept their concerns had been considered) was the reason it drove him over the edge, so your post lamenting the issue is at the same time demonstrating the issue.
I'm not talking about anything crazy here, just don't make map(), filter(), reduce() etc second class citizens and maybe even support tail call optimization. Honestly I don't know why comprehensions are so popular either, it's a slightly more convenient but less powerful construct than pure functions.
There wasn't a way of doing list comprehensions where you use the same expression on the left and right side. You needed a for loop with a temporary variable to achieve it. I think it's much more useful than map/filter for example as those are redundant if you use list comprehensions.
AFAICT, this article repeats the disaster of PEP572: it makes almost no effort to discuss how Python is used. Specifically, it implicitly holds that the BDFL + core contributors model that served Python so beautifully from, say, 1992 to 2002 when Python had perhaps 2 orders of magnitude fewer users than it does now and ran on—how can we know—3? 4? orders of magnitude fewer machines, should be taken for granted as the default governance mechanism for Python in 2018, when it is a key part of the world's infrastructure. I have no idea how to manage something as important as Python, but reading python-dev and seeing the brilliant Tim Peters, who was indispensable to Python's early growth, argue for a significant change in the language's semantics by using it to refactor a few samples from his personal code base, strikes me as prima facie evidence that neither do the core contributors. Millions. Of. People. Write. Python. That. Affects. The. Lives. Of. Billions. Of. People. Start there.
> Millions. Of. People. Write. Python. That. Affects. The. Lives. Of. Billions. Of. People. Start there.
I don't think this is how open source development works. Probably most of the core contributors are doing it for pleasure, not for satisfying the needs of the users.
I don't think this is how open source development works. Probably most of the core contributors are doing it for pleasure, not for satisfying the needs of the users.
Thanks, that's a much improved way of expressing my point.
This idea that are large and influential project like Python is just the same as a hobby project I put on github and do in my spare time is ridculous. I am pretty sure most of the core contributors of Python are doing it as part of their 9-5 job.
Then there is the implication that because they are doing it for pleasure, they don't owe anything to anyone. It's ridculous. This software affects millions of people and it's not a dumb hobby project.
Then there is the implication that because they are doing it for pleasure, they don't owe anything to anyone. It's ridculous. This software affects millions of people and it's not a dumb hobby project.
If it is part of their day job, the responsibility is towards their employer, not their users.
The millions of users are usually providing nothing in return for the software, I don't see how that entitles them to anything. In fact, I think it is the user's responsibility to make sure the software is appropriate for their use.
The millions of users are usually providing nothing in return for the software, I don't see how that entitles them to anything. In fact, I think it is the user's responsibility to make sure the software is appropriate for their use.
> Then there is the implication that because they are doing it for pleasure, they don't owe anything to anyone. It's ridculous. This software affects millions of people and it's not a dumb hobby project.
... no more ridiculous than the idea that software which millions of people depend on should be a commercial product, or a government project, and beholden to the politics of CEOs and/or government bureaucrats.
... no more ridiculous than the idea that software which millions of people depend on should be a commercial product, or a government project, and beholden to the politics of CEOs and/or government bureaucrats.
actually, by using Python you explicitly agree that PSF doesn't owe you anything :)
https://github.com/python/cpython/blob/master/LICENSE
4. PSF is making Python available to Licensee on an "AS IS" basis. PSF MAKES NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED. BY WAY OF EXAMPLE, BUT NOT LIMITATION, PSF MAKES NO AND DISCLAIMS ANY REPRESENTATION OR WARRANTY OF MERCHANTABILITY OR FITNESS FOR ANY PARTICULAR PURPOSE OR THAT THE USE OF PYTHON WILL NOT INFRINGE ANY THIRD PARTY RIGHTS.
5. PSF SHALL NOT BE LIABLE TO LICENSEE OR ANY OTHER USERS OF PYTHON FOR ANY INCIDENTAL, SPECIAL, OR CONSEQUENTIAL DAMAGES OR LOSS AS A RESULT OF MODIFYING, DISTRIBUTING, OR OTHERWISE USING PYTHON, OR ANY DERIVATIVE THEREOF, EVEN IF ADVISED OF THE POSSIBILITY THEREOF.
https://github.com/python/cpython/blob/master/LICENSE
4. PSF is making Python available to Licensee on an "AS IS" basis. PSF MAKES NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED. BY WAY OF EXAMPLE, BUT NOT LIMITATION, PSF MAKES NO AND DISCLAIMS ANY REPRESENTATION OR WARRANTY OF MERCHANTABILITY OR FITNESS FOR ANY PARTICULAR PURPOSE OR THAT THE USE OF PYTHON WILL NOT INFRINGE ANY THIRD PARTY RIGHTS.
5. PSF SHALL NOT BE LIABLE TO LICENSEE OR ANY OTHER USERS OF PYTHON FOR ANY INCIDENTAL, SPECIAL, OR CONSEQUENTIAL DAMAGES OR LOSS AS A RESULT OF MODIFYING, DISTRIBUTING, OR OTHERWISE USING PYTHON, OR ANY DERIVATIVE THEREOF, EVEN IF ADVISED OF THE POSSIBILITY THEREOF.
I'm talking about social responsibilities. Not about legal liabilities.
If there is not implied social responsibility that PSF keeps python running, then no one will be using it.
If there is not implied social responsibility that PSF keeps python running, then no one will be using it.
Why? As long as python.exe runs code, people will use it. And there's too much money invested in it for people that have done so to let it just die.
Because PSF says they will support Python? What happens when there is a bug? You fork Python? PSF gets 3 million in revenue per year. Where do you think the money goes? Python is not a hobby project.
That works for the rinky dink little file browser you put up on Github. It does not work for a project of this scale. Any core contributor who is unwilling to consider that point and treat this like a professional needs to step down, now.
Wow, that's entitled. Did you know that Python has a money-back guarantee?
No. For something of this nature, it is not entitlement to expect the people working on the core team to treat it like a professional. The entitlement comes when you believe that you can take a project like this, that millions of people are using to affect billions more, and treat it like a little hobby project.
You're using a lot of words to say nothing concrete.
What, precisely, do you mean by "professional", and how is the Python team not being "professional" right now? Because the definition of "professional" I use is "Doing something for money, as a profession", with no implications about the quality of the work, and that's obviously not what you mean by it... right?
What, precisely, do you mean by "professional", and how is the Python team not being "professional" right now? Because the definition of "professional" I use is "Doing something for money, as a profession", with no implications about the quality of the work, and that's obviously not what you mean by it... right?
Open source code is a gift. You don't have any right to demand this of them, and neither does anyone else. (What could possibly give you this right?)
If the governance of an open source project is bad enough, the way to fix it is to get a group of people together to maintain a fork. (Companies that depend on open source software can and will maintain their own branches.)
If the governance of an open source project is bad enough, the way to fix it is to get a group of people together to maintain a fork. (Companies that depend on open source software can and will maintain their own branches.)
"Open source code is a gift."
And the ability to work on it is a gift, too. If you're not going to take working on something as high profile as Python seriously, if you're just going to treat it as a hobby, then do everyone a favor and don't bother.
"You don't have any right to demand this of them"
As a user of Python, I absolutely do.
And the ability to work on it is a gift, too. If you're not going to take working on something as high profile as Python seriously, if you're just going to treat it as a hobby, then do everyone a favor and don't bother.
"You don't have any right to demand this of them"
As a user of Python, I absolutely do.
Being a user of Python only gives you the rights granted to you in the software license. If you'll read it over you'll see it doesn't include any right to make any demands of the developers.
> Millions. Of. People. Write. Python. That. Affects. The. Lives. Of. Billions. Of. People. Start there.
How do you take that assertion and turn it into something actionable?
What, concretely, would they be doing differently if they fully signed on to the above?
How do you take that assertion and turn it into something actionable?
What, concretely, would they be doing differently if they fully signed on to the above?
I think what Raymond Hettinger said is a good starting point: slow down and allow the ecosystem at large to catch up. Make big changes in a slower manner, and if there is no widespread agreement on a PEP for more than a year or two, just drop it.
1. I addressed this point by saying "I have no idea." I think the world has no idea. IEEE and other professional standards bodies are the only model I can think of, but it doesn't feel like a great fit. I tried to move the conversation forward. Maybe instead of challenging me, you could turn it into something actionable (or otherwise move the conversation forward).
2. Your "assertion" smacks a little of gaslighting. Python lies near the heart of the major Linux distributions that comprise, for example, AWS and Google Cloud. And they run services that directly or directly touch pretty much everyone in the industrialized world. Netflix by itself has 125M users, for example.
You claim that the python core team should be aware python is used by so many people, but you have no clue what them being deeply aware of that looks like, so how can you possibly claim that they're not doing that now, that doing so will make any difference, and that it's "forwards" for them to internalize that?
I also am absolutely floored that you'd pull out the term gaslighting for the parent comment which makes no assertions and only asks you to elaborate on your point more.
I think you need to step back, re-read this comment chain, and go look at a mirror.
I also am absolutely floored that you'd pull out the term gaslighting for the parent comment which makes no assertions and only asks you to elaborate on your point more.
I think you need to step back, re-read this comment chain, and go look at a mirror.
Learn from Javascript. As a full stack dev who came to python only recently, I think Python could really learn from what's happening in the js ecosystem.
To make sure it does the opposite of anything the JS ecosystem ever did? In that case, I agree.
Don't know why you're being downvoted. As a Pythonista and author of a Python book, I'm really curious. Would you mind suggesting a few aspects of Javascript's ecosystem to look at?
Thanks in advance.
Thanks in advance.
It wasn't a disaster. Some people didn't like the final choice. Some liked. A useful feature was added, this as far from disaster as it can get.
Just another BDFL, that's it.