4 ms·

I often read concerns that complexity keeps being added to the language with yet another flavour of string or whatnot. Given that those who author and deliberat

I often read concerns that complexity keeps being added to the language with yet another flavour of string or whatnot. Given that those who author and deliberate on PEPs are, kind of by definition, experts who spend a lot of time with the language, they might struggle to grok the Python experience from the perspective of a novice or beginner. How does the PEP process guard against this bias?

davepeck 2y ago
You might find the Python discussion forums ([0] and [1]) interesting; conversation that guides the evolution of PEPs happens there. As Nick mentioned, PEP 750 had a long and winding road to its final acceptance; as the process wore on, and the complexities of the earliest cuts of the PEPs were reconsidered, the two converged. [0] The very first announcement: https://discuss.python.org/t/pep-750-tag-strings-for-writing-domain-specific-languages/60408 https://discuss.python.org/t/pep-750-tag-strings-for-writing... [1] Much later in the PEP process: https://discuss.python.org/t/pep750-template-strings-new-updates/71594 https://discuss.python.org/t/pep750-template-strings-new-upd...
nhumrich 2y ago
All discussion on PEP's happens in public forums where anyone can opine on things before they are accepted. I agree that the experts are more likely to participate in this exchange. And while this is wish-washy, I feel like the process is really intended to benefit the experts more than the novices anyways. There have been processes put into place in recent years to try to curb the difficulty of things. One of those is that all new PEPs have to include a "how can you teach this to beginers" section, as seen here on this pep: https://peps.python.org/pep-0750/#how-to-teach-this https://peps.python.org/pep-0750/#how-to-teach-this
- Waterluvian 2y ago
  I think "how can you teach this to beginners?" is a fantastic, low-hanging fruit option for encouraging the wizards to think about that very important type of user. Other than a more broad "how is the language as a whole faring?" test, which might be done through surveys or other product-style research, I think this is just plainly a hard problem to approach, just by the nature that it's largely about user experience.
  - gtirloni 2y ago
    "How does this fit with everything else beginners have to learn to understand basic code?" is sorely needed.
- anon-3988 2y ago
  The average Python developer does not even know what a "PEP" is. Open discussion is good yes, but no one really knows what the average developer wants because they simply does not care if its Python or Java or whatever else. "Some hammers are just shaped weird, oh well, just make do with it." For example, some people that I interview does not "get" why you have to initialize the dict before doing dict[k] += 1. They know that they have to do some ritual of checking for k in dict and dict[k] = 0. But they don't get that += desugars into dict[k] = dict[k] + 1.
  - Waterluvian 2y ago
    defaultdict is so regularly useful for just this reason!
jackpirate 2y ago
Building off this question, it's not clear to me why Python should have both t-strings and f-strings. The difference between the two seems like a stumbling block to new programmers, and my "ideal python" would have only one of these mechanisms.
- davepeck 2y ago
  For one thing, `f"something"` is of type `str`; `t"something"` is of type `string.templatelib.Template`. With t-strings, your code can know which parts of the string were dynamically substituted and which were not.
  - deleted 2y ago
    [deleted]
  - all2 2y ago
    The types aren't so important. __call__ or reference returns type string, an f and a t will be interchangeable from the consumer side. Example, if you can go through (I'm not sure you can) and trivially replace all your fs with ts, and then have some minor fixups where the final product is used, I don't think a migration from one to the other would be terribly painful. Time-consuming, yes.
    - itishappy 2y ago
      Not sure that's true. `Template`s don't provide a `__str__` function, so you need to pass them to a processing function to get a `str` back. https://peps.python.org/pep-0750/#no-template-str-implementation https://peps.python.org/pep-0750/#no-template-str-implementa...
- nhumrich 2y ago
  f-strings immediately become a string, and are "invisible" to the runtime from a normal string. t-strings introduce an object so that libraries can do custom logic/formatting on the template strings, such as decided _how_ to format the string. My main motivation as an author of 501 was to ensure user input is properly escaped when inserting into sql, which you cant enforce with f-strings.
rtpg 2y ago
There are many long-term users of Python who participate in PEP discussion who argue for beginners[0], often because they professionally are teaching Python. There are also loads of people basically defaulting to "no" on new features, because they understand that there is a cost of supporting things. I will often disagree about the evaluation of that cost, but it's hard to say there is no cost. Nobody wants a system that is unusable, slow, hard to implement for, or hard to understand. People sometimes just have different weights on each of these properties. And some people are in a very awkward position of overestimating costs due to overestimating implementation effort. So you end up in discussions like "this is hard to understand!" "No it isn't!" Hard to move beyond, but the existence of these kinds of conversations serve, in a way, as proof that people aren't jumping on every new feature. Python is still a language that is conservative in what it adds. This should actually inspire more confidence in people that features added to Python are _useful_, because there are many people who are defaulting to not adding new features. Recent additions to Python speeding up is more an indicator of the process improving and identifying the good stuff rather than a lowering of the bar. [0]: I often think that these discussions often get fairly intense. Understandability is definitely a core Python value, but I Think sometimes discussions confuse "understandability" with "amount of things in the system". You don't have to fully understand pervasive hashing to understand Python's pervasive value equality semantics! A complex system is needed to support a simple one!

davepeck 2y ago

You might find the Python discussion forums ([0] and [1]) interesting; conversation that guides the evolution of PEPs happens there. As Nick mentioned, PEP 750 had a long and winding road to its final acceptance; as the process wore on, and the complexities of the earliest cuts of the PEPs were reconsidered, the two converged. [0] The very first announcement: https://discuss.python.org/t/pep-750-tag-strings-for-writing-domain-specific-languages/60408 https://discuss.python.org/t/pep-750-tag-strings-for-writing... [1] Much later in the PEP process: https://discuss.python.org/t/pep750-template-strings-new-updates/71594 https://discuss.python.org/t/pep750-template-strings-new-upd...

nhumrich 2y ago

All discussion on PEP's happens in public forums where anyone can opine on things before they are accepted. I agree that the experts are more likely to participate in this exchange. And while this is wish-washy, I feel like the process is really intended to benefit the experts more than the novices anyways. There have been processes put into place in recent years to try to curb the difficulty of things. One of those is that all new PEPs have to include a "how can you teach this to beginers" section, as seen here on this pep: https://peps.python.org/pep-0750/#how-to-teach-this https://peps.python.org/pep-0750/#how-to-teach-this

Waterluvian 2y ago
I think "how can you teach this to beginners?" is a fantastic, low-hanging fruit option for encouraging the wizards to think about that very important type of user. Other than a more broad "how is the language as a whole faring?" test, which might be done through surveys or other product-style research, I think this is just plainly a hard problem to approach, just by the nature that it's largely about user experience.
- gtirloni 2y ago
  "How does this fit with everything else beginners have to learn to understand basic code?" is sorely needed.
anon-3988 2y ago
The average Python developer does not even know what a "PEP" is. Open discussion is good yes, but no one really knows what the average developer wants because they simply does not care if its Python or Java or whatever else. "Some hammers are just shaped weird, oh well, just make do with it." For example, some people that I interview does not "get" why you have to initialize the dict before doing dict[k] += 1. They know that they have to do some ritual of checking for k in dict and dict[k] = 0. But they don't get that += desugars into dict[k] = dict[k] + 1.
- Waterluvian 2y ago
  defaultdict is so regularly useful for just this reason!

jackpirate 2y ago

Building off this question, it's not clear to me why Python should have both t-strings and f-strings. The difference between the two seems like a stumbling block to new programmers, and my "ideal python" would have only one of these mechanisms.

davepeck 2y ago
For one thing, `f"something"` is of type `str`; `t"something"` is of type `string.templatelib.Template`. With t-strings, your code can know which parts of the string were dynamically substituted and which were not.
- deleted 2y ago
  [deleted]
- all2 2y ago
  The types aren't so important. __call__ or reference returns type string, an f and a t will be interchangeable from the consumer side. Example, if you can go through (I'm not sure you can) and trivially replace all your fs with ts, and then have some minor fixups where the final product is used, I don't think a migration from one to the other would be terribly painful. Time-consuming, yes.
  - itishappy 2y ago
    Not sure that's true. `Template`s don't provide a `__str__` function, so you need to pass them to a processing function to get a `str` back. https://peps.python.org/pep-0750/#no-template-str-implementation https://peps.python.org/pep-0750/#no-template-str-implementa...
nhumrich 2y ago
f-strings immediately become a string, and are "invisible" to the runtime from a normal string. t-strings introduce an object so that libraries can do custom logic/formatting on the template strings, such as decided _how_ to format the string. My main motivation as an author of 501 was to ensure user input is properly escaped when inserting into sql, which you cant enforce with f-strings.

rtpg 2y ago

There are many long-term users of Python who participate in PEP discussion who argue for beginners[0], often because they professionally are teaching Python. There are also loads of people basically defaulting to "no" on new features, because they understand that there is a cost of supporting things. I will often disagree about the evaluation of that cost, but it's hard to say there is no cost. Nobody wants a system that is unusable, slow, hard to implement for, or hard to understand. People sometimes just have different weights on each of these properties. And some people are in a very awkward position of overestimating costs due to overestimating implementation effort. So you end up in discussions like "this is hard to understand!" "No it isn't!" Hard to move beyond, but the existence of these kinds of conversations serve, in a way, as proof that people aren't jumping on every new feature. Python is still a language that is conservative in what it adds. This should actually inspire more confidence in people that features added to Python are _useful_, because there are many people who are defaulting to not adding new features. Recent additions to Python speeding up is more an indicator of the process improving and identifying the good stuff rather than a lowering of the bar. [0]: I often think that these discussions often get fairly intense. Understandability is definitely a core Python value, but I Think sometimes discussions confuse "understandability" with "amount of things in the system". You don't have to fully understand pervasive hashing to understand Python's pervasive value equality semantics! A complex system is needed to support a simple one!