"else if" as equivalent for "elif"
Parse the sequence "else if" equivalently to "elif". This would be 100% backward compatible. It wouldn't require adding any new keywords to the language. It shouldn't be burdensome to maintain, since "elif" only appears in one place in the grammar. And it solves a minor readability complaint. Thoughts?
The Python Zen says: There should be one-- and preferably only one --obvious way to do it. elif uses less typing, anyway. Why type 3 more characters when you really don't need to? :D On October 21, 2015 12:57:36 PM CDT, Ian Kelly <ian.g.kelly@gmail.com> wrote:
-- Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity.
On Oct 21, 2015, at 11:16, Sven R. Kunze <srkunze@mail.de> wrote:
Unless you also deprecate "elif", Python will still look strange—it'll just look inconsistently strange, which is even worse than consistently strange. Besides, it's not as if "else if" reads like English any more than "elif" does. In English, you'd use a semicolon and an "if" for all but the last, and "or if" for the last (or, if there's only one, maybe "otherwise if" or "but if", depending on the connotations). Also, the number of people coming to Python from C and its descendants (especially Java and JavaScript) is high enough that the false impression given by "else if" (that it's just an if statement controlled by an else clause) could be harmful. Yes, once you think about it, the fact that there's no colon after the "else" and only one level of indentation instead of two makes sense, but you shouldn't have to think about it.
On 2015-10-21 19:16, Sven R. Kunze wrote:
The C preprocessor has #elif. Is that strange too? :-) (It could be argued that it _is_ strange that the C preprocessor has an explicitly-terminated "#if ... #endif", whereas the C language itself doesn't have an explicitly-terminated "if".)
On Wed, Oct 21, 2015 at 3:26 PM, MRAB <python@mrabarnett.plus.com> wrote:
"We stole this short spelling from C" shouldn't be an argument in favor of any spelling, in my opinion. (Not creating a second way to do something or deprecating a language keyword is a much stronger argument, of course; I'm as opposed to this proposal as I'd be to a propose to rename strptime and strftime, but I'd also think "but that's how C spells them!" would be a bad argument in that case. Don't even get me started about Popen objects...)
On Wed, Oct 21, 2015 at 3:49 PM, Geoffrey Spear <geoffspear@gmail.com> wrote:
"We stole this short spelling from C" shouldn't be an argument in favor of any spelling, in my opinion.
Can you explain your opinion? C is by far the most influential language in the history of computing. As a source of keywords it is second only to English.
On Wed, Oct 21, 2015 at 4:09 PM, Alexander Belopolsky < alexander.belopolsky@gmail.com> wrote:
Lots of stuff in C favors terseness over readability. Python generally takes the opposite approach to naming things. Obviously this is sometimes a cause of confusion to people new to the language, when people think "oh, Python is just like English, so I should use 'is' instead of '=='" or "why doesn't `if foo or bar == 'baz'` do what I mean?", but for the most part having easy-to-read actual English words for keywords and functions with names that actually say what they do instead of making some obscure reference to a badly-named C library function written at a time when limiting identifiers to 6 letters seemed like a good idea to save precious disk space (or room on a punchcard), in my opinion, has greatly contributed to Python's reputation as a readable language. "elif" is a wart, but again, one I think we're stuck with.
On 22 October 2015 at 18:22, Sven R. Kunze <srkunze@mail.de> wrote:
It's a big deal due to opportunity cost - any time that is spent on making a second spelling of "elif" possible is time not spent working on something that directly improves developer productivity (like format strings) or application correctness (like gradual typing support). Time spent on frivolous changes also (justifiably) annoys users of the language given the large numbers of known problems we've yet to figure out how to find the time and resources to resolve.
From a readability perspective, inserting an "se " in the middle of every elif clause doesn't really improve things:
if x == 1: ... elif x == 2: ... elif x == 3: ... else: ... vs: if x == 1: ... else if x == 2: ... else if x == 3: ... else: ... It can actually be argued that it's *harder* to read, since the typical English phrasing for this kind of formulation is more along the lines of "X if case A, else Y if case B, else Z", which is the way conditional expressions are written. By contrast, the statement form has an implied "then" after each condition: "if case A, then X, else if case B, then Y, else Z". Compared to dropping "then" entirely, abbreviating "else if" to "elif" is a fairly minor change. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On 23.10.2015 18:09, Nick Coghlan wrote:
1) I may re-iterate. Such thinking is dangerous. It could mean standstill. It prevents thinking and progress. That is python-ideas; not python-controlling. 2) Is Python not an open-source project? Could not anybody contribute? To me that means, the sky is the limit. 3) Well, that the features you mentioned really do what they promise can be only be proved if they are implemented and used. So, we will see how they fare. Same, btw., would be for "else if". All of your and mine great thoughts are just that: thoughts, assumptions, arguments. Not facts.
Cf. above. Okay, enough of resource-thinking. Back to topic.
Let's remember that.
I thought "elif" is an abbreviation of "else if" as is "don't" to "do not". So, why are you arguing with differing semantics when it comes to readability? I for one think it improves things (as does several other people on the list), that is why it is on the list. ;-) Why you may ask? Because it just reads like an English sentence: "If that condition, then (==colon) do this, else if another condition, then (==colon) do that, etc. etc." So, we got "if", ":", and "else", this is just all we need to learn. Something, I would be interested in is: what was the reason for introducing the non-English keyword "elif"? Parsing difficulties? Best, Sven
On Oct 24, 2015, at 01:39, Sven R. Kunze <srkunze@mail.de> wrote:
I for one think it improves things (as does several other people on the list), that is why it is on the list. ;-) Why you may ask? Because it just reads like an English sentence: "If that condition, then (==colon) do this, else if another condition, then (==colon) do that, etc. etc."
Nobody has ever spoken a sentence in that form. Maybe with "otherwise", even more likely with no connective at all (which you'd spell with a semicolon), but never with "else". That's what's wrong with this whole argument: it's an attempt to make Python "more like English" in a way that's not actually like English.
Something, I would be interested in is: what was the reason for introducing the non-English keyword "elif"? Parsing difficulties?
Think about the way "else if" works in C and its descendants and influencees: it's just an "else" clause whose body happens to be an "if" statement. By convention, you don't wrap the "if" statement in braces or indent it an extra level, but there's no syntactic reason not to do so. (And formatter tools need a special case to make them not do so.) In Python, indentation is not optional or conventional, it's syntactic. So the if would have to be indented under the else. Either that, or it would have to work differently from the way it works in all those other languages. Of course that's possible, but that demolishes the other argument for this change: to make Python more like other languages, we'd make it misleadingly appear to be like all those other languages, when it actually works differently. Which would be a great way to confuse people coming to Python from Java, or alternating Python. C, and JS code in their work, etc.
"Sven R. Kunze" <srkunze@mail.de> writes:
2) Is Python not an open-source project? Could not anybody contribute? To me that means, the sky is the limit.
Easy for you to say, but that's not the limit. The limit in *this* forum is the finite attention of the Python core developers. If you want to discuss sky-is-the-limit ideas, use ‘python-list’ which is a forum for all topics Python-related. -- \ “Repetition leads to boredom, boredom to horrifying mistakes, | `\ horrifying mistakes to God-I-wish-I-was-still-bored, and it | _o__) goes downhill from there.” —Will Larson, 2008-11-04 | Ben Finney
On Sat, Oct 24, 2015 at 3:39 AM, Sven R. Kunze <srkunze@mail.de> wrote:
Two things: 1. That doesn't read like an English sentence. It sounds like an English sentence spoken by someone who's been through a 48-hour C hackathon. 2. Well, elif is used almost everywhere, so 99% of the people who learn Python will have to learn 'elif' the day after 'else if'.
-- Ryan [ERROR]: Your autotools build scripts are 200 lines longer than your program. Something’s wrong. http://kirbyfan64.github.io/
On Sat, Oct 24, 2015 at 7:39 PM, Sven R. Kunze <srkunze@mail.de> wrote:
The point of discussing ideas is to sort out the good ones from the bad ones. One of the most effective ways to do this is to have someone advocate an idea, and someone else criticize it, with the resulting discussion being (hopefully!) a fruitful analysis of the idea's qualities. So while you're correct that this is called "python-ideas" for a reason, Nick is also absolutely correct in criticizing the idea. A good idea will be able to stand up to critics.
2) Is Python not an open-source project? Could not anybody contribute? To me that means, the sky is the limit.
"Open source" and "free software" and so on do not mean that anyone can make changes to the core. It does mean, however, that you're legally, morally, and ethically permitted to make your own version of CPython that includes the "else if" notation, play around with it, and demonstrate your idea in action. This is actually a great way to support an idea; you can find out exactly how much code would have to change to make this work, and start playing around with it. And then if the idea does end up being accepted, your patch can be incorporated into the main body of code.
Yep. And that's why it helps to spin up a patch. Unfortunately this is a change to the language grammar, which is not the easiest thing to tweak (if you were proposing a change to a pure Python module in the standard library, you could play with it much more easily); but if you write the patch yourself, you are directly answering (part of) Nick's objection about opportunity cost. Personally, I'm not in favour of adding another way of spelling elif. If every other language in the world spelled it "else if" and Python alone used "elif", then I'd support adding the alias, for the convenience of people working with multiple languages; but it's not that consistent (some languages use "elsif", "elseif", and various other forms). The readability argument is weak, and I don't see any reason to create two distinct ways of spelling the exact same thing. But hey! Play with the patch, have some fun with it. ChrisA
Here is yet another argument against this change -- indentation. Indentation is, as we all well know, one of the core aspects of Python's syntax. In every project I have worked on, and in PEP 8 ( https://www.python.org/dev/peps/pep-0008/#indentation ), 4-space indents are used. 'elif' is exactly 4 characters long, which means it lines up pretty well with other similar keywords such as 'else' or 'for' (with the space that follows it). In that regard, 'else if' would actually make code *harder* to read, not easier! In the same sense that 'def' (followed by a space) makes it very easy to spot the functions' names (if for some reason you don't have syntax highlighting ... ), 'elif' makes it easy to spot the beginning of another condition statement within a block. Cheers,-Emanuel Barry
On Sun, Oct 25, 2015 at 7:28 PM, Emanuel Barry <vgr255@live.ca> wrote:
I'm not following. Can you provide an example of how this hurts indentation? It seems a stretch to suggest that "elif" lines up with "for" because you're including the space that follows "for", but you're excluding the space that follows "elif". I note that "else if" has the same length as "finally", if that matters.
I agree it might sound a bit inconsistent that I take into account the space following 'for' but not the one following 'elif' - my point is that a human reader can easily look at the first characters before the next indentation level kicks in. This might not be a good example though now that I think of it, as a human reader would see that the line is not just 'else' (which was pretty much my original point). I recognize that you're right though, and I take back my words. Cheers,-Emanuel Barry
On 24/10/2015 09:39, Sven R. Kunze wrote:
I have a very strong feeling that you haven't got the faintest idea how the Python development process works, from the time that an idea gets put forward here, until the first full release with that shiny new feature that everybody has been wanting for since forever. To me the most important thing that needs sorting is the core workflow. Sure other things need doing, but to me "else if" doesn't even get on the bottom of the infinitely long list of Python jobs that need doing. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence
On 24 October 2015 at 09:39, Sven R. Kunze <srkunze@mail.de> wrote:
2) Is Python not an open-source project? Could not anybody contribute? To me that means, the sky is the limit.
The problem is that many people contribute ideas (hence this list) but only a few contribute code, and even fewer contribute the commitment to maintain that code long-term. One of the roles needed on this list is for people to say that the *current* developers (i.e, those contributing code and maintenance) are unlikely to spend their time implementing and maintaining an idea proposed here. That doesn't mean the idea is rejected out of hand, it just means that to progress the idea the person proposing it is likely to have to go further, and offer code, and potentially ongoing maintenance if it's a change that can't be covered by "normal" maintenance (e.g., a inclusion of a new or specialist library). So ideas are welcome, but they need to be backed by an implementation, and "I'm not interested in implementing this idea for you" is an entirely legitimate (and not uncommon) response that people need to be prepared to accept. Paul
On 26 October 2015 at 09:37, Paul Moore <p.f.moore@gmail.com> wrote:
It's also the case that the number of ways we can make Python worse is uncountably infinite, while the number of ways we can make it easier to use without also making it harder to learn is vanishingly small by comparison. (Hence the controversy over concepts like gradual typing, which improves usability for larger projects and teams, but introduces a new concept that people are likely to eventually have to learn as they gain further experience with the language) This means that *both* python-ideas and python-dev serve primarily as filters when it comes to new features: python-ideas finds the ideas that *might* have potential, and helps refine them into a concrete pitch to python-dev (or an enhancement request on the issue tracker for simpler ideas that don't need full python-dev review), while python-dev is more focused on delivering a relatively prompt yes/no answer on whether or not an idea is acceptable in principle, and then refining the practical details if the answer is "yes". Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Oct 21, 2015, at 12:26, MRAB <python@mrabarnett.plus.com> wrote:
C++ of course solved that by embedding a whole compile-time language that's even less like C than the preprocessor, where the clauses have to be bounded in angle brackets, removing all ambiguity and leading to nice readable things like this: typedef typename if_c<spam, SpamType, typename if_c<eggs, EggsType, CheeseType>::type> ::type type; Compare to: if (spam) type = SpamType; else if (eggs) type = EggsType; else type = CheeseType; The second one leaves it unclear to the reader that the final else is actually part of the second if which is itself controlled by the first if's else. If you indebted this "properly" it would be a lot uglier. Which is the whole problem elif is meant to solve. But the first version makes the tree structure the clearest thing in the whole construction, without needing elif, so it's clearly better. ;)
The Python Zen says: There should be one-- and preferably only one --obvious way to do it. elif uses less typing, anyway. Why type 3 more characters when you really don't need to? :D On October 21, 2015 12:57:36 PM CDT, Ian Kelly <ian.g.kelly@gmail.com> wrote:
-- Sent from my Nexus 5 with K-9 Mail. Please excuse my brevity.
On Oct 21, 2015, at 11:16, Sven R. Kunze <srkunze@mail.de> wrote:
Unless you also deprecate "elif", Python will still look strange—it'll just look inconsistently strange, which is even worse than consistently strange. Besides, it's not as if "else if" reads like English any more than "elif" does. In English, you'd use a semicolon and an "if" for all but the last, and "or if" for the last (or, if there's only one, maybe "otherwise if" or "but if", depending on the connotations). Also, the number of people coming to Python from C and its descendants (especially Java and JavaScript) is high enough that the false impression given by "else if" (that it's just an if statement controlled by an else clause) could be harmful. Yes, once you think about it, the fact that there's no colon after the "else" and only one level of indentation instead of two makes sense, but you shouldn't have to think about it.
On 2015-10-21 19:16, Sven R. Kunze wrote:
The C preprocessor has #elif. Is that strange too? :-) (It could be argued that it _is_ strange that the C preprocessor has an explicitly-terminated "#if ... #endif", whereas the C language itself doesn't have an explicitly-terminated "if".)
On Wed, Oct 21, 2015 at 3:26 PM, MRAB <python@mrabarnett.plus.com> wrote:
"We stole this short spelling from C" shouldn't be an argument in favor of any spelling, in my opinion. (Not creating a second way to do something or deprecating a language keyword is a much stronger argument, of course; I'm as opposed to this proposal as I'd be to a propose to rename strptime and strftime, but I'd also think "but that's how C spells them!" would be a bad argument in that case. Don't even get me started about Popen objects...)
On Wed, Oct 21, 2015 at 3:49 PM, Geoffrey Spear <geoffspear@gmail.com> wrote:
"We stole this short spelling from C" shouldn't be an argument in favor of any spelling, in my opinion.
Can you explain your opinion? C is by far the most influential language in the history of computing. As a source of keywords it is second only to English.
On Wed, Oct 21, 2015 at 4:09 PM, Alexander Belopolsky < alexander.belopolsky@gmail.com> wrote:
Lots of stuff in C favors terseness over readability. Python generally takes the opposite approach to naming things. Obviously this is sometimes a cause of confusion to people new to the language, when people think "oh, Python is just like English, so I should use 'is' instead of '=='" or "why doesn't `if foo or bar == 'baz'` do what I mean?", but for the most part having easy-to-read actual English words for keywords and functions with names that actually say what they do instead of making some obscure reference to a badly-named C library function written at a time when limiting identifiers to 6 letters seemed like a good idea to save precious disk space (or room on a punchcard), in my opinion, has greatly contributed to Python's reputation as a readable language. "elif" is a wart, but again, one I think we're stuck with.
On 22 October 2015 at 18:22, Sven R. Kunze <srkunze@mail.de> wrote:
It's a big deal due to opportunity cost - any time that is spent on making a second spelling of "elif" possible is time not spent working on something that directly improves developer productivity (like format strings) or application correctness (like gradual typing support). Time spent on frivolous changes also (justifiably) annoys users of the language given the large numbers of known problems we've yet to figure out how to find the time and resources to resolve.
From a readability perspective, inserting an "se " in the middle of every elif clause doesn't really improve things:
if x == 1: ... elif x == 2: ... elif x == 3: ... else: ... vs: if x == 1: ... else if x == 2: ... else if x == 3: ... else: ... It can actually be argued that it's *harder* to read, since the typical English phrasing for this kind of formulation is more along the lines of "X if case A, else Y if case B, else Z", which is the way conditional expressions are written. By contrast, the statement form has an implied "then" after each condition: "if case A, then X, else if case B, then Y, else Z". Compared to dropping "then" entirely, abbreviating "else if" to "elif" is a fairly minor change. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On 23.10.2015 18:09, Nick Coghlan wrote:
1) I may re-iterate. Such thinking is dangerous. It could mean standstill. It prevents thinking and progress. That is python-ideas; not python-controlling. 2) Is Python not an open-source project? Could not anybody contribute? To me that means, the sky is the limit. 3) Well, that the features you mentioned really do what they promise can be only be proved if they are implemented and used. So, we will see how they fare. Same, btw., would be for "else if". All of your and mine great thoughts are just that: thoughts, assumptions, arguments. Not facts.
Cf. above. Okay, enough of resource-thinking. Back to topic.
Let's remember that.
I thought "elif" is an abbreviation of "else if" as is "don't" to "do not". So, why are you arguing with differing semantics when it comes to readability? I for one think it improves things (as does several other people on the list), that is why it is on the list. ;-) Why you may ask? Because it just reads like an English sentence: "If that condition, then (==colon) do this, else if another condition, then (==colon) do that, etc. etc." So, we got "if", ":", and "else", this is just all we need to learn. Something, I would be interested in is: what was the reason for introducing the non-English keyword "elif"? Parsing difficulties? Best, Sven
On Oct 24, 2015, at 01:39, Sven R. Kunze <srkunze@mail.de> wrote:
I for one think it improves things (as does several other people on the list), that is why it is on the list. ;-) Why you may ask? Because it just reads like an English sentence: "If that condition, then (==colon) do this, else if another condition, then (==colon) do that, etc. etc."
Nobody has ever spoken a sentence in that form. Maybe with "otherwise", even more likely with no connective at all (which you'd spell with a semicolon), but never with "else". That's what's wrong with this whole argument: it's an attempt to make Python "more like English" in a way that's not actually like English.
Something, I would be interested in is: what was the reason for introducing the non-English keyword "elif"? Parsing difficulties?
Think about the way "else if" works in C and its descendants and influencees: it's just an "else" clause whose body happens to be an "if" statement. By convention, you don't wrap the "if" statement in braces or indent it an extra level, but there's no syntactic reason not to do so. (And formatter tools need a special case to make them not do so.) In Python, indentation is not optional or conventional, it's syntactic. So the if would have to be indented under the else. Either that, or it would have to work differently from the way it works in all those other languages. Of course that's possible, but that demolishes the other argument for this change: to make Python more like other languages, we'd make it misleadingly appear to be like all those other languages, when it actually works differently. Which would be a great way to confuse people coming to Python from Java, or alternating Python. C, and JS code in their work, etc.
"Sven R. Kunze" <srkunze@mail.de> writes:
2) Is Python not an open-source project? Could not anybody contribute? To me that means, the sky is the limit.
Easy for you to say, but that's not the limit. The limit in *this* forum is the finite attention of the Python core developers. If you want to discuss sky-is-the-limit ideas, use ‘python-list’ which is a forum for all topics Python-related. -- \ “Repetition leads to boredom, boredom to horrifying mistakes, | `\ horrifying mistakes to God-I-wish-I-was-still-bored, and it | _o__) goes downhill from there.” —Will Larson, 2008-11-04 | Ben Finney
On Sat, Oct 24, 2015 at 3:39 AM, Sven R. Kunze <srkunze@mail.de> wrote:
Two things: 1. That doesn't read like an English sentence. It sounds like an English sentence spoken by someone who's been through a 48-hour C hackathon. 2. Well, elif is used almost everywhere, so 99% of the people who learn Python will have to learn 'elif' the day after 'else if'.
-- Ryan [ERROR]: Your autotools build scripts are 200 lines longer than your program. Something’s wrong. http://kirbyfan64.github.io/
On Sat, Oct 24, 2015 at 7:39 PM, Sven R. Kunze <srkunze@mail.de> wrote:
The point of discussing ideas is to sort out the good ones from the bad ones. One of the most effective ways to do this is to have someone advocate an idea, and someone else criticize it, with the resulting discussion being (hopefully!) a fruitful analysis of the idea's qualities. So while you're correct that this is called "python-ideas" for a reason, Nick is also absolutely correct in criticizing the idea. A good idea will be able to stand up to critics.
2) Is Python not an open-source project? Could not anybody contribute? To me that means, the sky is the limit.
"Open source" and "free software" and so on do not mean that anyone can make changes to the core. It does mean, however, that you're legally, morally, and ethically permitted to make your own version of CPython that includes the "else if" notation, play around with it, and demonstrate your idea in action. This is actually a great way to support an idea; you can find out exactly how much code would have to change to make this work, and start playing around with it. And then if the idea does end up being accepted, your patch can be incorporated into the main body of code.
Yep. And that's why it helps to spin up a patch. Unfortunately this is a change to the language grammar, which is not the easiest thing to tweak (if you were proposing a change to a pure Python module in the standard library, you could play with it much more easily); but if you write the patch yourself, you are directly answering (part of) Nick's objection about opportunity cost. Personally, I'm not in favour of adding another way of spelling elif. If every other language in the world spelled it "else if" and Python alone used "elif", then I'd support adding the alias, for the convenience of people working with multiple languages; but it's not that consistent (some languages use "elsif", "elseif", and various other forms). The readability argument is weak, and I don't see any reason to create two distinct ways of spelling the exact same thing. But hey! Play with the patch, have some fun with it. ChrisA
Here is yet another argument against this change -- indentation. Indentation is, as we all well know, one of the core aspects of Python's syntax. In every project I have worked on, and in PEP 8 ( https://www.python.org/dev/peps/pep-0008/#indentation ), 4-space indents are used. 'elif' is exactly 4 characters long, which means it lines up pretty well with other similar keywords such as 'else' or 'for' (with the space that follows it). In that regard, 'else if' would actually make code *harder* to read, not easier! In the same sense that 'def' (followed by a space) makes it very easy to spot the functions' names (if for some reason you don't have syntax highlighting ... ), 'elif' makes it easy to spot the beginning of another condition statement within a block. Cheers,-Emanuel Barry
On Sun, Oct 25, 2015 at 7:28 PM, Emanuel Barry <vgr255@live.ca> wrote:
I'm not following. Can you provide an example of how this hurts indentation? It seems a stretch to suggest that "elif" lines up with "for" because you're including the space that follows "for", but you're excluding the space that follows "elif". I note that "else if" has the same length as "finally", if that matters.
I agree it might sound a bit inconsistent that I take into account the space following 'for' but not the one following 'elif' - my point is that a human reader can easily look at the first characters before the next indentation level kicks in. This might not be a good example though now that I think of it, as a human reader would see that the line is not just 'else' (which was pretty much my original point). I recognize that you're right though, and I take back my words. Cheers,-Emanuel Barry
On 24/10/2015 09:39, Sven R. Kunze wrote:
I have a very strong feeling that you haven't got the faintest idea how the Python development process works, from the time that an idea gets put forward here, until the first full release with that shiny new feature that everybody has been wanting for since forever. To me the most important thing that needs sorting is the core workflow. Sure other things need doing, but to me "else if" doesn't even get on the bottom of the infinitely long list of Python jobs that need doing. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence
On 24 October 2015 at 09:39, Sven R. Kunze <srkunze@mail.de> wrote:
2) Is Python not an open-source project? Could not anybody contribute? To me that means, the sky is the limit.
The problem is that many people contribute ideas (hence this list) but only a few contribute code, and even fewer contribute the commitment to maintain that code long-term. One of the roles needed on this list is for people to say that the *current* developers (i.e, those contributing code and maintenance) are unlikely to spend their time implementing and maintaining an idea proposed here. That doesn't mean the idea is rejected out of hand, it just means that to progress the idea the person proposing it is likely to have to go further, and offer code, and potentially ongoing maintenance if it's a change that can't be covered by "normal" maintenance (e.g., a inclusion of a new or specialist library). So ideas are welcome, but they need to be backed by an implementation, and "I'm not interested in implementing this idea for you" is an entirely legitimate (and not uncommon) response that people need to be prepared to accept. Paul
On 26 October 2015 at 09:37, Paul Moore <p.f.moore@gmail.com> wrote:
It's also the case that the number of ways we can make Python worse is uncountably infinite, while the number of ways we can make it easier to use without also making it harder to learn is vanishingly small by comparison. (Hence the controversy over concepts like gradual typing, which improves usability for larger projects and teams, but introduces a new concept that people are likely to eventually have to learn as they gain further experience with the language) This means that *both* python-ideas and python-dev serve primarily as filters when it comes to new features: python-ideas finds the ideas that *might* have potential, and helps refine them into a concrete pitch to python-dev (or an enhancement request on the issue tracker for simpler ideas that don't need full python-dev review), while python-dev is more focused on delivering a relatively prompt yes/no answer on whether or not an idea is acceptable in principle, and then refining the practical details if the answer is "yes". Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Oct 21, 2015, at 12:26, MRAB <python@mrabarnett.plus.com> wrote:
C++ of course solved that by embedding a whole compile-time language that's even less like C than the preprocessor, where the clauses have to be bounded in angle brackets, removing all ambiguity and leading to nice readable things like this: typedef typename if_c<spam, SpamType, typename if_c<eggs, EggsType, CheeseType>::type> ::type type; Compare to: if (spam) type = SpamType; else if (eggs) type = EggsType; else type = CheeseType; The second one leaves it unclear to the reader that the final else is actually part of the second if which is itself controlled by the first if's else. If you indebted this "properly" it would be a lot uglier. Which is the whole problem elif is meant to solve. But the first version makes the tree structure the clearest thing in the whole construction, without needing elif, so it's clearly better. ;)
participants (14)
-
Alexander Belopolsky -
Andrew Barnert -
Ben Finney -
Chris Angelico -
Emanuel Barry -
Geoffrey Spear -
Ian Kelly -
Mark Lawrence -
MRAB -
Nick Coghlan -
Paul Moore -
Random832 -
Ryan Gonzalez -
Sven R. Kunze