5 ms·

From my point of view, the Python release cycle presents several challenges in terms of two-way communication with users. Ideally, we want people to download t

From my point of view, the Python release cycle presents several challenges in terms of two-way communication with users. Ideally, we want people to download the beta releases and give feedback on their real world experience with new features while there is still time to make changes. (That is almost the entire point of a beta-release accompanied by a feature freeze). Actual practice tends to fall short of the ideal for several reasons: * Not many users download the beta and try out the features. On the bug tracker, we tend to get very little feedback on our beta releases. * Some features land with little to no documentation (the walrus operator, for example). This makes it difficult for users to assess the feature. * The PEP process is decisive. Once a PEP is approved, it is too late for developers to give feedback. The feature will happen regardless of user feedback. * Downstream tooling needs time to update, so it is difficult to try out a beta when you can't get your dependencies to run (MyPy, Black, requests, etc).

coldtea 7y ago
>The PEP process is decisive. Once a PEP is approved, it is too late for developers to give feedback. The feature will happen regardless of user feedback. That shouldn't be the case. There should be a PEP-re-evaluation stage, once the feature is available. It might not affect major parts of the PEP (that should be handled in the original PEP discussions), but for things that are found to be problematic in actual use, once the feature is available in beta, changes should be considered before the final release.
- Skunkleton 7y ago
  A new PEP can be created. At some point the RFC phase ends and the feature needs to be committed to.
  - deleted 7y ago
    [deleted]
- joshuamorton 7y ago
  Generally speaking, for a pep to be approved, there has to be a working proof of concept. This isn't always true, but I've seen it be the case for most recent peps.
- raymondh 7y ago
  That isn't practical. The PEP process is already exhausting and we aim to solicit feedback before the PEP is decided. By the time a beta is out, we're already in feature freeze and it is somewhat late in the game.
  - coldtea 7y ago
    >That isn't practical. The PEP process is already exhausting and we aim to solicit feedback before the PEP is decided. By the time a beta is out, we're already in feature freeze and it is somewhat late in the game. Isn't it the case tho, that a PEP is usually just a document + discussion? I've seen someone having a PoC sometimes, but iirc it's not often readily available for use. Unless a feature is available to try (in alpha, beta, whatever), people can't really evaluate its ergonomics and how it affects or integrates with their use cases. I know that at least a few languages, including Go and Rust, don't commit to a feature after the relevant proposal is accepted, but have version you can try, that they might change and/or revoke. As someone in the Python community often says, "there must be a better way"! Maybe a PEP could include the stage where there is something like a "from __pep_proposals__ import new_feature". This might slow down the PEP rate (if every new candidate feature needs a trial implementation), but that's not necessarily a bad thing. Or it could just be required for larger changes to the language. (THE RaymondH? !!!)
lifeisstillgood 7y ago
On the beta testers front I think it's not impossible to get a dozen or more full time devs at a major bank I work at to commit to downloading and using it and giving feedback - can you indicate what might be useful ?
- raymondh 7y ago
  This would be a big help. The process is simple. Download the beta, try-out the features, and let us know how they work out in real world code -- is it learnable or prone to misunderstanding, are the docs intelligible, does it solve the problem it was intended to solve, does it fit in with the rest of the ecosystem, etc. APIs are really hard to change once released. Prior to release, we can fix just about anything.
  - lifeisstillgood 7y ago
    I'll see what I can get going next week. cheers nice idea.
robomartin 7y ago
For me the walrus operator is an example of how things can take a turn for the worse. It's a bad idea. I have yet to see any example that justifies its existence. Put a different way, I have yet to see a reason for not extending "=" to add this behavior. This is how a nice language can be ruined and can become a Tower of Babel scenario. In some ways this is how J is a ruined version of APL, because it completely destroys what the language was about in the first place. Next thing we know we are going to end-up with 23 different assignment operators, one for each chromosome pair. The other part I don't get is the religious insistence against not implementing something like a "switch" statement. This is one of the most useful constructs in all of computer science and Python rejects it due to what amounts to religious belief. In fact, one of the most powerful tools you get when moving from assembler to C is the "switch()" statement. If you've ever coded and maintained the equivalent in assembler you know exactly what I am talking about. Because, you know, a pile of "if" statements is somehow better. Ah, OK, with "if" you can use data types other than integer. Sure, because we couldn't define a Python "switch" to work with anything other than integers...like a "switch" that could take a dictionary and route based on key/value matching, etc. Every single state machine I have written in who knows how many decades --in C, C++, Objective-C, PHP, Verilog, etc.-- has had, at it's core, a single or multi-layer "switch" statement. Can't do that in Python, 'cause. <rant off>
- zapzupnz 7y ago
  Could you give a concrete example of how the walrus operator is worse for the language? I know you've admitted that this is a rant but without anything to back it up, it isn't much interesting to read. As for the switch statement, I'm inclined to agree although if we see `switch` as syntactic sugar for a bunch of other conditional statements, then what makes it a more important candidate for inclusion than the walrus operator? Thanks in advance, I'm genuinely curious to know.
  - FakeComments 7y ago
    Not GP, but — What makes if statements and loop statements more useful than goto statements? Switch is a powerful abstraction over chained and/or nested if statements, in much the same way other constructs are abstractions over goto. A programming language is for humans to read — and switch statements greatly enhance comprehension. While other languages use := for assignment, and perhaps there’s arguments that’s better in the face of typos, Python doesn’t in general — and I don’t see the utility in adding a second way to do assignment. The use cases of the walrus operator are useful, but they’re just cases of assignment in many languages; a second sometimes used assignment operator is not.

coldtea 7y ago

>The PEP process is decisive. Once a PEP is approved, it is too late for developers to give feedback. The feature will happen regardless of user feedback. That shouldn't be the case. There should be a PEP-re-evaluation stage, once the feature is available. It might not affect major parts of the PEP (that should be handled in the original PEP discussions), but for things that are found to be problematic in actual use, once the feature is available in beta, changes should be considered before the final release.

Skunkleton 7y ago
A new PEP can be created. At some point the RFC phase ends and the feature needs to be committed to.
- deleted 7y ago
  [deleted]
joshuamorton 7y ago
Generally speaking, for a pep to be approved, there has to be a working proof of concept. This isn't always true, but I've seen it be the case for most recent peps.
raymondh 7y ago
That isn't practical. The PEP process is already exhausting and we aim to solicit feedback before the PEP is decided. By the time a beta is out, we're already in feature freeze and it is somewhat late in the game.
- coldtea 7y ago
  >That isn't practical. The PEP process is already exhausting and we aim to solicit feedback before the PEP is decided. By the time a beta is out, we're already in feature freeze and it is somewhat late in the game. Isn't it the case tho, that a PEP is usually just a document + discussion? I've seen someone having a PoC sometimes, but iirc it's not often readily available for use. Unless a feature is available to try (in alpha, beta, whatever), people can't really evaluate its ergonomics and how it affects or integrates with their use cases. I know that at least a few languages, including Go and Rust, don't commit to a feature after the relevant proposal is accepted, but have version you can try, that they might change and/or revoke. As someone in the Python community often says, "there must be a better way"! Maybe a PEP could include the stage where there is something like a "from __pep_proposals__ import new_feature". This might slow down the PEP rate (if every new candidate feature needs a trial implementation), but that's not necessarily a bad thing. Or it could just be required for larger changes to the language. (THE RaymondH? !!!)

lifeisstillgood 7y ago

On the beta testers front I think it's not impossible to get a dozen or more full time devs at a major bank I work at to commit to downloading and using it and giving feedback - can you indicate what might be useful ?

raymondh 7y ago
This would be a big help. The process is simple. Download the beta, try-out the features, and let us know how they work out in real world code -- is it learnable or prone to misunderstanding, are the docs intelligible, does it solve the problem it was intended to solve, does it fit in with the rest of the ecosystem, etc. APIs are really hard to change once released. Prior to release, we can fix just about anything.
- lifeisstillgood 7y ago
  I'll see what I can get going next week. cheers nice idea.

robomartin 7y ago

For me the walrus operator is an example of how things can take a turn for the worse. It's a bad idea. I have yet to see any example that justifies its existence. Put a different way, I have yet to see a reason for not extending "=" to add this behavior. This is how a nice language can be ruined and can become a Tower of Babel scenario. In some ways this is how J is a ruined version of APL, because it completely destroys what the language was about in the first place. Next thing we know we are going to end-up with 23 different assignment operators, one for each chromosome pair. The other part I don't get is the religious insistence against not implementing something like a "switch" statement. This is one of the most useful constructs in all of computer science and Python rejects it due to what amounts to religious belief. In fact, one of the most powerful tools you get when moving from assembler to C is the "switch()" statement. If you've ever coded and maintained the equivalent in assembler you know exactly what I am talking about. Because, you know, a pile of "if" statements is somehow better. Ah, OK, with "if" you can use data types other than integer. Sure, because we couldn't define a Python "switch" to work with anything other than integers...like a "switch" that could take a dictionary and route based on key/value matching, etc. Every single state machine I have written in who knows how many decades --in C, C++, Objective-C, PHP, Verilog, etc.-- has had, at it's core, a single or multi-layer "switch" statement. Can't do that in Python, 'cause. <rant off>

zapzupnz 7y ago
Could you give a concrete example of how the walrus operator is worse for the language? I know you've admitted that this is a rant but without anything to back it up, it isn't much interesting to read. As for the switch statement, I'm inclined to agree although if we see `switch` as syntactic sugar for a bunch of other conditional statements, then what makes it a more important candidate for inclusion than the walrus operator? Thanks in advance, I'm genuinely curious to know.
- FakeComments 7y ago
  Not GP, but — What makes if statements and loop statements more useful than goto statements? Switch is a powerful abstraction over chained and/or nested if statements, in much the same way other constructs are abstractions over goto. A programming language is for humans to read — and switch statements greatly enhance comprehension. While other languages use := for assignment, and perhaps there’s arguments that’s better in the face of typos, Python doesn’t in general — and I don’t see the utility in adding a second way to do assignment. The use cases of the walrus operator are useful, but they’re just cases of assignment in many languages; a second sometimes used assignment operator is not.