On 11/27/2019 3:24 PM, Abdur-Rahmaan Janhangeer wrote:

Greetings list,

Using 3.7, in json module of the std lib there is json.load and json.loads . I gather json.loads is more used to convert string to dict structure. json.load might cause (it already causes) confusions.

Suggestion: Rename json.load() so as not to confuse with json.loads()

You'd  either have to breaking existing code, or having 2 identical functions with different names. In either case, the churn and confusion would not be worth it. Eric

On Nov 27, 2019, at 12:27, Abdur-Rahmaan Janhangeer <arj.python@gmail.com> wrote:

Using 3.7, in json module of the std lib there is json.load and json.loads . I gather json.loads is more used to convert string to dict structure.

Yes, loads is to load from a string; load is used to load from a file (or file-like object).

json.load might cause (it already causes) confusions.

I’m curious what names you would use? Maybe load_string and load_file? Anyway, more explicit names might have been better, but load/loads is so well established—across other document types, and third-party modules as well as stdlib, and so on—that changing it in just one module would cause a lot more confusion than it could possibly solve, and changing it everywhere isn’t feasible. Plus, there’s decades worth of working code using these names; breaking all that code requires a really big benefit. Also, I think the other two quasi-standards out there for similar cases are much worse. Some modules have a single function that type-switches on string as contents vs. file, while others have a function that type-switches on string as pathname vs. file plus a separate fromstring function for parsing contents. That’s a lot more confusing. I frequently accidentally try to parse a pathname as an XML document, or to open a file using an XML document as a pathname, but I never make that mistake with JSON.

Side q: Is there yet a way to get ? and/or ?? In IPython/Jupyter to list {typeshed,} annotations? On Thursday, November 28, 2019, Wes Turner <wes.turner@gmail.com> wrote:

An IDE with support for PEP 484 / mypy / type annotations (and/or writing tests) can help minimize typing-related errors.

https://github.com/python/typeshed/blob/master/stdlib/3/json/__init__.pyi

https://github.com/python/mypy/blob/master/README.md#ide-linter-integrations...

On Wednesday, November 27, 2019, Eric V. Smith <eric@trueblade.com> wrote:

...

On 11/27/2019 3:24 PM, Abdur-Rahmaan Janhangeer wrote:

...

Greetings list,

Using 3.7, in json module of the std lib there is json.load and

json.loads . I gather json.loads is more used to convert string to dict structure. json.load might cause (it already causes) confusions.

...

...

Suggestion: Rename json.load() so as not to confuse with json.loads()

You'd either have to breaking existing code, or having 2 identical functions with different names. In either case, the churn and confusion would not be worth it.

Eric

_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/INEF3F... Code of Conduct: http://python.org/psf/codeofconduct/

On Thu, Nov 28, 2019 at 02:06:08PM +0400, Abdur-Rahmaan Janhangeer wrote:

It's about ambiguity. Maybe loads is short for load string which in english is also a verb.

True. It took me a long time to stop getting confused between pickle.load and .loads until I stopped reading it as "loads" and started reading it as "load-s(tring)". I agree with you that this is a sub-optimal naming convention, and we would have been better if a different choice was made at the beginning. But unfortunately it is a widely used naming convention: * pickle * marshall * json * yaml (I think) * and probably more and not just in Python. But I agree with the others that the pain and disruption from changing it is greater than the benefit. We all just have to memorise that "loads" means "load-string" and not the present tense of load. -- Steven

I happen to be teaching essential std lib modules this week, i had a headache with how naming goes on (i was looking at how a beginner would learn). Poor me, what could be an intuitive learning journey has some clogs down the road.

To some degree, that's an inevitable part of the learning process. The most we can realistically do is try to be aware of it during design, but I suspect there's always going to be some "more intuitive" way we could have done it when looking back with hindsight. On Thu, Nov 28, 2019 at 6:04 AM Abdur-Rahmaan Janhangeer < arj.python@gmail.com> wrote:

For the future, at least

I happen to be teaching essential std lib modules this week, i had a headache with how naming goes on (i was looking at how a beginner would learn). Poor me, what could be an intuitive learning journey has some clogs down the road.

Abdur-Rahmaan Janhangeer http://www.pythonmembers.club | https://github.com/Abdur-rahmaanJ Mauritius

On Thu, 28 Nov 2019, 14:57 Steven D'Aprano, <steve@pearwood.info> wrote:

...

On Thu, Nov 28, 2019 at 02:06:08PM +0400, Abdur-Rahmaan Janhangeer wrote:

...

It's about ambiguity. Maybe loads is short for load string which in english is also a verb.

True. It took me a long time to stop getting confused between pickle.load and .loads until I stopped reading it as "loads" and started reading it as "load-s(tring)".

I agree with you that this is a sub-optimal naming convention, and we would have been better if a different choice was made at the beginning. But unfortunately it is a widely used naming convention:

* pickle * marshall * json * yaml (I think) * and probably more

and not just in Python. But I agree with the others that the pain and disruption from changing it is greater than the benefit. We all just have to memorise that "loads" means "load-string" and not the present tense of load.

-- Steven _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/FVP522... Code of Conduct: http://python.org/psf/codeofconduct/

_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/7ATKEJ... Code of Conduct: http://python.org/psf/codeofconduct/

Maybe methods for learning to search the code and docs (rather than memorizing APIs) would be a worthwhile exercise? # Python import json help(json) # IPython !pydoc json import json json? json?? # RTD: Read The Docs (and/or update the docs) https://docs.python.org/3/search.html?q=loads https://docs.python.org/3/library/json.html#basic-usage https://github.com/python/cpython/blob/master/Doc/library/json.rst # RTS: Read The Source https://duckduckgo.com/?q=github+cpython+json https://github.com/python/cpython/blob/master/Lib/json/__init__.py#L299 https://github.com/python/cpython/tree/master/Lib/test/test_json On Thursday, November 28, 2019, Abdur-Rahmaan Janhangeer < arj.python@gmail.com> wrote:

"Designed With Learning in Mind"

Abdur-Rahmaan Janhangeer http://www.pythonmembers.club | https://github.com/Abdur-rahmaanJ Mauritius

Abdur-Rahmaan Janhangeer writes:

"Designed With Learning in Mind"

That's Python. Guido said so from the beginning, and in modern Python development we tend to favor full words with a consistent convention for separating them in multiword identifiers and so on. Syntax additions get fully bikeshedded; "tend to favor" is not acceptable there! Python is also developed mainly by volunteers, with a relatively conservative attitude toward additions to the stdlib. Some packages do get developed here on Python Ideas and Python Dev, and fast-tracked because their proponents are well-respected. Those tend to get quite a lot of attention to nomenclature ("bikeshedding", as it's called). But most aren't (and that includes most by famous proponents, too![1]) That means that some volunteer typically spends years polishing up their package to *their* satisfaction, and by the time it gets added it has a substantial following and a substantial installed base (if it didn't, it likely wouldn't get added), making backward compatibility a thing. At that point adding synonyms may backfire. People using synonyms run into trouble, they ask on StackExchange, and the grizzled old folks (who constitute a large fraction of the People Who Answer) will go "WTF is this?" and move on to a question they can answer off the top of their heads. You don't have to like it. I don't think anybody likes suboptimal naming, they just like it better than they like backward-incompatible renames or namespace pollution. You can't really expect others to be happy with wholesale changes to the environment, even if they're fully backward compatible as the proposals to add aliases for json.loads and calendar.calendar are. (As usual, you can say "I just want these two," and we'll respond "OK, but the community as a whole will want a million of them, we all have our favorites, and if we accept yours, how do we deny theirs?") You can always just write wrapper modules that do nothing but rename any identifiers you think are unintuitive. It would be interesting to see how much uptake you get from new users. (I exclude existing users because, however much they *like* your names, they are likely to be biased against the changes by backward compatibility with their own code and with third-party code -- not really a fair test. Although if you get a lot of uptake there it would be a strong recommendation.) Footnotes: [1] For example, consider the dates of implementation of PEPs 3107 and 484. 3107 wasn't written by Guido, but he wanted and advocated it, and AIUI he always intended it to support something like 484.

On Fri, Nov 29, 2019 at 12:55:13AM +0900, Stephen J. Turnbull wrote:

Abdur-Rahmaan Janhangeer writes:

...

"Designed With Learning in Mind"

That's Python. Guido said so from the beginning,

Is it? Did he? Do you have references for that? https://duckduckgo.com/?q=python+%22Designed+With+Learning+in+Mind%22 I don't think that Python is "designed with learning in mind". Python is not Scratch, nor is it ABC. ABC was a *big* influence on the evolution of Python, but (in my opinion) at least half of that influence was to convince Guido *not* to make Python "designed with learning in mind". For example, ABC used its own alledgedly "beginner friendly" terminology that nobody else in programming used; Python mostly sticks to common terminology used by other languages which will be recognised by programmers coming from other languages. [...]

Footnotes: [1] For example, consider the dates of implementation of PEPs 3107 and 484. 3107 wasn't written by Guido, but he wanted and advocated it, and AIUI he always intended it to support something like 484.

Off-topic: I'm consistently and frequently frustrated by the community's use of PEP id numbers as jargon. I consider it to be a classic example of the use of jargon to exclude, rather than the sense of using it to streamline communication. They're like the old joke about the members of a club who have collected all their old jokes and funny anecdotes into a numbered list, so one need only announce "5379" and the club members will burst out into laughter. Great for those who have memorised the list, and perplexing and exclusionary to everyone else. They're worse than three- and four-letter acronyms, because at least acronyms have some connection to the English phrase (usually the initial letters) and you can often work out the meaning in context; but PEPs are arbitrary identifiers. Unless you have memorised the mapping from PEP ids to descriptions, there is nothing to link the id to the meaning. Apart from PEP 8, I don't know a single PEP id off by heart (not even the PEPs I have authored) and your footnote above reads as pure gobbledygook to me. There is not enough context to guess the meaning of 3107 or 484 (Guido intended 3107 to support 484 did he? how uninformative) so there is nothing to be done except to stop reading, switch to a browser, and google them both. And there are so many PEPs, most of which are of interest only to a tiny subset of the Python community, or old and obscure, that (apart from PEP 8) most of us don't even get the chance to memorise them through repetition. If I casually mentioned 317 into a conversation, how many people would know it was about prohibiting implicit exception instantiation? Here endeth the rant. -- Steven

On 2019-11-28 20:51, Steven D'Aprano wrote: [snip]

I'm consistently and frequently frustrated by the community's use of PEP id numbers as jargon. I consider it to be a classic example of the use of jargon to exclude, rather than the sense of using it to streamline communication.

[snip]

Apart from PEP 8, I don't know a single PEP id off by heart (not even the PEPs I have authored) and your footnote above reads as pure gobbledygook to me. There is not enough context to guess the meaning of 3107 or 484 (Guido intended 3107 to support 484 did he? how uninformative) so there is nothing to be done except to stop reading, switch to a browser, and google them both.

And there are so many PEPs, most of which are of interest only to a tiny subset of the Python community, or old and obscure, that (apart from PEP 8) most of us don't even get the chance to memorise them through repetition. If I casually mentioned 317 into a conversation, how many people would know it was about prohibiting implicit exception instantiation?

Well, there's PEP 0, which is the index. Oh, and PEP 404. :-) The only other one I can remember is PEP 393 (Flexible String Representation), and that's because of writing an extension.

Ricky Teachey writes:

Leading by example of not sticking forever with obfuscated naming.

We do push back against obfuscated naming, including abbreviations like loads, but forward-looking, not backward-looking. There's also the problem in the stdlib that often a requirement for a module to be added is that it have a large following. In those cases the author may or may not have followed what we consider good naming practices, but they were good enough for the users.

So I'm still +1. Just add the better named function as an option and be done with it; other than adding it to the docs, leave everything else as it is.

I would find this very annoying, because I believe it would lead to widespread namespace pollution. I use dir() a lot to remind myself of APIs, and aliases that would confuse me and slow reading (I'm old enough to have vision issues) would anger me. Using dir() works for me because I read docs before I start typing code (hentai, I know), and have a relatively good memory after one or two readings. I don't know how many people have those characteristics, though. There's second aspect of namespace pollution, which is that users will frequently use plausible alternatives for their own value-added APIs. I don't know if this actually causes confusion, though.

No one sees that example as a signal that it's a good idea to do objectively bad naming, like loads() does. But someone sees loads() and thinks, "ah, short names are really good", and go with prof() rather than process_file().

People who think short names are good are more worried about typing them than anything else in my experience. They're not imitating anybody, they're optimizing the code in front of them.

So here I'm really talking about what I'm calling obfuscated names, not necessarily names that aren't as intuitive as they could be.

One person's unintuitive can easily be another's obfuscated. pickle.dump() is *obfuscated* to anybody old enough to have used "set limit core unlimited" (even if they were born in 2010). For those of us old enough to remember "can't eat just one", "memory dump" (of which "core dump" is a special case) is an extremely strong association. I'm basically -1 on any aliasing. I think there's way too many that have been proposed. I can't see a way limit them that doesn't read "screw you" to the proposals that are denied, and it would be a burden on me, it would cause confusion, and I don't think the benefits are likely to be great. Those are all subjective priors, so I could be moved if some proponent is willing to go through the last five years of Python List, Python Ideas, Python Dev, and the tracker and provide a list of aliasing and renaming proposals, and show that the likely level of namespace pollution is low.

Education is one side of it. It's about intuitive API Abdur-Rahmaan Janhangeer http://www.pythonmembers.club | https://github.com/Abdur-rahmaanJ Mauritius

On Thu, Nov 28, 2019 at 06:18:11PM -0500, Ricky Teachey wrote:

Leading by example of not sticking forever with obfuscated naming.

"loads" is not obfuscated naming. It has an easy-to-remember (if not totally obvious) meaning once you realise it is supposed to be pronounced as "load-s" (s for string) rather than "loads". json.xtagbe would be obfuscated naming. Or json._9263, or json.pencil. Python uses close-to natural language identifiers. And we need to learn how to correctly parse natural language identifiers: the os module is "o s", not "os sounds like aus or oz". "thread" is "th-red", not "th-read". English spelling is weird and inconsistent, with dozens or more of homonyms and homographs, like: project, bat, lie, fair, second, fine (homonyms) refuse, resume, minute (homographs) etc. "loads" is a homograph, as it can be read as loads (as in "he loads the dishwasher") or load-s (s for string). There may be languages with a perfectly rational and consistent relationship between written symbols and sounds, but I don't know of any. (And I'd expect that such a language would either have a very large number of symbols, or support only a very small fraction of the sounds that human speach can make.) For good or ill, if we want our code to look even a little bit like English, we're going to need to deal with the complexity of English spelling. Programming uses lots of initialisms, abbreviations and hybrid words, such as: os ram ssd dir json xml len chr EOF I/O rlcompleter pprint sqlite etc, and loads is not particularly worse than the rest.

So I'm still +1. Just add the better named function as an option and be done with it; other than adding it to the docs, leave everything else as it is. New people will start using it (because it is so much more obvious what it is) and their understanding, and the new code they write mimicking the standard library, will be improved. And later other libraries will follow the lead that better names for things are very very important.

I dispute that the alternative is a "better" name. Better for who? Better in what way? Forcing newbies to learn *two* names for the same method does not sound like an improvement to me. You say "leave everything else as it is", so newcomers will still see the old name in code, in tutorials, in blog posts, in books, on Stackoverflow answers, etc. So they still have to learn that "loads" is "load s(tring)". Effectively you are swapping one problem: "what's the difference between load and loads?" for two problems: "what's the difference between load and loads?" "what's the difference between loads and load_string?" -- Steven

On 29/11/2019 10:45, Abdur-Rahmaan Janhangeer wrote:

One of them can maybe be deprectated

json.load(<string here>)

for file:

json.load(file=<file obj>)

Ew ew ew ew ew! No thanks, I'd like my string parser to remain *clearly different* from my file parser. json.loads() is just fine, please don't mess with it. -- Rhodri James *-* Kynesim Ltd

Message to author of PEP 1437: _please read some threads like these_

-1 on renaming. -1 on deprecating. -1 on creating an unnecessary alias.

Maybe if the change's a breaking one, we might wait for a breaking event to sneak this one in. Knowing Python, maybe a stdlib intuitiveness workgroup will be set up. They'll work (hard) to make the std lib as candy as possible while candy-ing everyone onboard This week i have "cool 3rd party packages", a thread like this won't appear 🛫 Abdur-Rahmaan Janhangeer http://www.pythonmembers.club | https://github.com/Abdur-rahmaanJ Mauritius

On 29/11/2019 13:36, Abdur-Rahmaan Janhangeer wrote:

...

= Chris Angelico -1 on renaming. -1 on deprecating. -1 on creating an unnecessary alias.

Maybe if the change's a breaking one, we might wait for a breaking event to sneak this one in.

Or we could accept that it is what it is. I'm with Chris: -1 on making life complicated. -- Rhodri James *-* Kynesim Ltd

On Sat, Nov 30, 2019 at 1:33 AM Richard Damon <Richard@damon-family.org> wrote:

My personal feeling is that adding a significantly better name, and deprecating the old name (maybe never going past the state of documenting that it is deprecated and suggesting using the better name, one reason not to have an automatic removal of deprecated features) is viable if the name improvement is big enough.

Perhaps, IF the improvement is big enough. A marginal improvement is not worth all that hassle. And if you keep both names, you forever have people wondering what the difference is. As an example, Python's threading module has duplicate names eg "current_thread" and "currentThread". The depreferred names are documented up to and including Python 2.7, but they still exist in the latest 3.x.

If we are going to use the existing web mentions, then Python would still be back as a 2.x version, and the language would be very static and 'old'

This applies only to bare renames. If a completely new feature is added, it's not going to run into this problem; you have the normal thing of "requires Python 3.5+", but that doesn't get more complicated as you add more features - if you have one that was introduced in 3.5 and another that was introduced in 3.7, then you need 3.7, it's that simple. Much more complicated when some things come and go, so the correct thing to do will change multiple times.

That doesn't answer the question of if the new name is enough better to be worth it.

Agreed. I don't see that it is, in this instance.

One issue is that since Python allows the user to monkey-patch library code, ANY expansion of name space is potentially breaking, Python has almost no namespace reserved for the language designers that users are allowed to intrude on (maybe dunders are reserved enough, but we don't want to be using dunders as part of user accessed API). Which means that even if we deprecate loads, the standard library should continue to use it and not the new load_string for awhile until it is felt safe that few people are monkey patching in a load_string member, and we can break the code.

I don't think we need to worry about people poking arbitrary values into a stdlib module and breaking things. If someone's doing that and their code breaks in Python 3.10, that's on them. ChrisA

On Fri, Nov 29, 2019 at 12:23:41PM +0900, Stephen J. Turnbull wrote:

Steven D'Aprano writes:

...

On Fri, Nov 29, 2019 at 12:55:13AM +0900, Stephen J. Turnbull wrote:

...

Abdur-Rahmaan Janhangeer writes:

...

"Designed With Learning in Mind"

That's Python. Guido said so from the beginning,

Is it? Did he? Do you have references for that?

Yes, it is in my opinion (I use it in teaching all the time in the same way I would use pseudo-code, and I haven't taught a class in programming in 25 years).

Yes, he did.

No, just my memory of occasions where he has said or posted that use of Python as a teaching language informed his design philosophy and decisions (which is the minimum that "with learning in mind" implies).

Guido might have something different to say about all this, but according to his blog, he *literally* designed Python as a scripting language for himself to glue together libraries written in C for the Amoeba operating system. "My original motivation for creating Python was the perceived need for a higher level language in the Amoeba project. ... So there was a need for a language that would “bridge the gap between C and the shell.” For a long time, this was Python’s main catchphrase." http://python-history.blogspot.com/2009/01/personal-history-part-1-cwi.html He describes his design of the language here: http://python-history.blogspot.com/2009/01/pythons-design-philosophy.html and notably missing from that list of design principles is anything about teaching programming or making it easier to learn or "Designed With Learning in Mind". In fact, some of the features of ABC that actually were designed with learning in mind were consciously rejected by Guido when designing Python. Honestly, this discussion is quite surreal. The json.load/loads API is clearly copied from the same API in the pickle and marshal modules, which are some of the oldest APIs in Python, going back to at least Python 1.5 if not older. So we have people simultaneously arguing that: * the load/loads distinction is hard to learn * and that Python was designed to be easy to learn from the earliest days which is contradictory. If it had been, the pickle/marshal API probably wouldn't have used loads and json wouldn't have copied it. Python naming conventions have evolved, and the oldest APIs are not "Designed With Learning In Mind".

...

Python is not Scratch, nor is it ABC. ABC was a *big* influence on the evolution of Python, but (in my opinion) at least half of that influence was to convince Guido *not* to make Python "designed with learning in mind".

"Design with learning in mind" literally means "don't forget about beginners in Python and in programming", not "sacrifice everything else on the altar of education".

That's not what it *literally* means. Its literal meaning is a lot closer to the second statement than the first, only without the perjorative elements of sacrificing to the cult of education. In any case, it is a matter of historical fact (to the degree that we believe Guido's account, and we have no reason to think that he is lying) that he didn't design Python with beginners in mind.

...

For example, ABC used its own alledgedly "beginner friendly" terminology that nobody else in programming used; Python mostly sticks to common terminology used by other languages which will be recognised by programmers coming from other languages.

Which is a decision that has learning Python (vs. learning programming in general) in mind, no?

No. If you want to learn programming concepts, you might prefer ABCs terminology. That at least was what the ABC designers thought; your mileage may vary. But ABC was designed with learning in mind: https://homepages.cwi.nl/~steven/abc/teaching.html just as Scratch and similar languages are. Using ABC for learning was the reason why it was created, and its design reflected that. This is not why Python was created, and while Guido copied some of the concepts from ABC, he consciously rejected others. One of those concepts he intentionally rejected was that the user had no prior experience and was learning how to program. -- Steven

On Nov 29, 2019, at 02:42, Steven D'Aprano <steve@pearwood.info> wrote:

Programming uses lots of initialisms, abbreviations and hybrid words, such as:

os ram ssd dir json xml len chr EOF I/O rlcompleter pprint sqlite

etc, and loads is not particularly worse than the rest.

I agree with your sentiment; and I’m -1 on the change, but it’s worth pointing out that the amount of abbreviation and portmanteuing that’s considered appropriate has changed over the years. The names Guido gave things in 1991 aren’t necessarily the names he’d come up with today; if he were inventing `loads` 28 years later, I think he would have called it `load_string`. And, if not, he would have changed his mind during the bikeshedding process when 80% of the people paying attention argued against it. It’s not even that people have decided that reading code is more important than writing it (or that the novice learning curve matters), After all, sometimes brevity is better for reading, too. So there’s still a balance. It’s just that the balance in the 70s was based on reading and writing on slow teletypes where you had to fit your program into a few KB, while now you have all the screen space and storage you could want and instantaneous auto-complete and so on, so the cost of longer names is a lot lower. And, while Python isn’t quite _that_ old, the balance in Python 0.9 was about fitting in with C in a Unix-ish system, while now Python is about being good for everything from scripts to servers. That’s why we usually get names like `get_current_loop` today instead of names like `getcwd`. (But not always—e.g., new additions to `math` that wrap or emulate `math.h` functions still get C-style names.)

Steven D'Aprano writes:

He describes his design of the language here:

We're talking about different things. Specifically:

...

"Design with learning in mind" literally means "don't forget about beginners in Python and in programming", not "sacrifice everything else on the altar of education".

That's not what it *literally* means.

You're confusing "literally" with "idiomatically". "Design with learning in mind" doesn't say *anything* about what else is in mind, or relative priority. *Idiomatically*, yes, it's used as you and Abdur-Rahmaan have. But *literally* it means that when you're thinking about design, "learning" is in there with all that other stuff. Guido literally quotes the Zen of Python as his design principles. Of the 19 verses, only the two concerned with timing ("now" vs. "right now") are not clearly related to the language being learnable. The fact that Tim didn't explicitly use words like "learning" or "education" in the Zen doesn't mean that Guido hasn't had "learning in mind" when he actually conducted design. The only way we can be sure is to ask him, but I'm willing to stand on the inference from the language we actually have.

In any case, it is a matter of historical fact (to the degree that we believe Guido's account, and we have no reason to think that he is lying) that he didn't design Python with beginners in mind.

Specious. Beginners are not the only people who have need to learn.

One of those concepts he intentionally rejected was that the user had no prior experience and was learning how to program.

You have a *very* restrictive idea of what "learning" means in the context of programming. Not everything that makes a concept learnable is useful or necessary for beginners, not everything that is useful or necessary for beginners is useless for experts. It is of course true that teaching beginning concepts to beginners and advanced concepts to experts are very different activities and benefit from different approaches. That doesn't at all mean that the same set of principles aren't conducive to learning at all levels. It doesn't necessarily mean that they are. But I believe that such a set can be, and that Python's set of design principles as embodied in the Zen as well as some other folk sayings is an example of a set of principles that leads to a language that is conducive to learning. In several domains: about the language itself, about the generic activity of programming, and about the real systems that our programs simulate or implement. Steve

Why, we could even number them, call them Python-Issues Common Threads, abbreviate that as "PICT", and then refer to them as, e.g., "PICT-114"!! :-D :-D :-D :-D ... |-[

On Sat, 30 Nov 2019 at 10:57, Brian Skinn <brian.skinn@gmail.com> wrote:

Why, we could even number them, call them Python-Issues Common Threads, abbreviate that as "PICT", and then refer to them as, e.g., "PICT-114"!! :-D :-D :-D :-D ... |-[

I nominate this statement for the position of PICT-001 :-) Paul

Christopher Barker writes:

Frankly, I get confused when there are discussion on this list (or python-dev, or) about currently PEPs in the midst of active discussion!

I would take that as a signal to ignore that thread or poster, to be honest. If it's not clear from thread and post context what they're talking about, either I didn't really care in the first place and probably shouldn't waste time on it, or they are confused, not me. YMMV, but I consider that good advice.

Is is THAT hard to add a little text?

No. Thing is, I'm not going to go to the effort to do it, mostly because I'm old, set in my ways, and I'm rarely going to think of it unless a bunch of folks are willing to try to train me (which to be effective would probably involve behavior that will get them CoC'd). I suspect more or less the same is true of others with the habit. And in fact, it's so easy a machine can do it. Mailman is a Python application, it would be easy to add that function to either the Decorate handler (which adds text to the body) or put it in a separate handler. The Mailman API is easy enough, you just need a Handler subclass with a process() method which calls (or implements directly) that function. How about one of you number-haters being a hero and writing a Mailman Handler? I'll be happy to answer questions, and make sure it gets added to contrib. Bonus points for recognizing titles or substantial prefixes thereof, and adding the PEP number. ;-) Steve

Though, PICT-001 should probably be reserved as an index for other PICT documents. On Saturday, November 30, 2019, Paul Moore <p.f.moore@gmail.com> wrote:

On Sat, 30 Nov 2019 at 10:57, Brian Skinn <brian.skinn@gmail.com> wrote:

...

Why, we could even number them, call them Python-Issues Common Threads,

abbreviate that as "PICT", and then refer to them as, e.g., "PICT-114"!! :-D :-D :-D :-D ... |-[

I nominate this statement for the position of PICT-001 :-)

Paul _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/2BZ74W... Code of Conduct: http://python.org/psf/codeofconduct/

It sounds like many would agree that renaming some things could have many benefits, but the cost seems to be higher than I imagined. What if an easier way could be created to manage renaming that avoided many of these problems? Perhaps aliases of objects could be something worth baking into the language itself. I don't mean having multiple names pointing to the same object as we can do today, but something new entirely. *THE FOLLOWING IS PROBABLY A CRACKPOT IDEA*, hear it out of you are in the mood to humor me on this Saturday morning. What if the __dict__ for modules and classes could be something like a ChainMap, with multiple internal lookup mappings. The first level (by which I mean, the first mapping consulted) would be the same as exists today, but the second would contain a weak value dictionary with aliases pointing to objects so that when you do json.load_str, it returns json.loads object just like it would if you had added the alias in the way you would today. But the dict is weak value so that if an object is garbage collected, its alias entries are removed. So the second mapping would be a so called "alias dictionary". How could this be done to overcome some of the same objections raised? *First, regarding discoverability: * dir() would work identically to as it does today, but you could give an argument to also provide aliases, something like:

...

...

dir(json, alias=True) ['JSONDecodeError', 'JSONDecoder', 'JSONEncoder', '__all__', '__author__', '__builtins__', '__cached__', '__doc__', '__file__', '__loader__', '__name__', '__package__', '__path__', '__spec__', '__version__', '_default_decoder', '_default_encoder', 'codecs', 'decoder', 'detect_encoding', 'dump', 'dumps [dump_str]', 'encoder', 'load', 'loads [load_str]', 'scanner']

Note that when you tell dir() that alias=True, additional aliases for objects are added to the output in the form of a string-ified list. Also change the default object repr so that it says something like:

...

...

json.loads <function loads (alias: load_str) at 0x.... >

The help() could be modified to be something like:

...

...

help(json.load_str)

Help on function loads in module json (alias: load_str): ... *Second objection: "people are going to be confused because now they will ask 'What is the difference between these TWO functions, or between these TWO methods?'":* There are no longer "two different functions/methods". Since aliases are something baked into the language, both new and old folks would need to learn to be GENERALLY aware that they exist, and there will need to be an easy way to retrieve the aliases for an object. So there's a big new thing to learn there. But once that exists, it mostly becomes a single point of learning. People would still periodically see the different names in code and ask the question "what's the difference" of course, but the answer would change. Instead of simply "oh it is the same function with a second name", the answer would be "those are a thing called python aliases; here is a link to the docs talking about how to find aliases". The docs for the object would also list aliases (if there are any). However I dare say you'd probably get this question less often because of the repl output I am suggesting above. *Third objection: it polluts the namespace.* It still would do this to a degree, but I think in a more tolerable way. Most importantly, it seems like it would be preferred for * importing everything from a module to import only the first level dictionary and not all the aliases. Additionally, you can still add or monkeypatch new objects into a namespace (they would go into the first level dictionary, therefore overriding any aliases in the second level). Beyond that, since I'm talking about something new baked into the language, the code writing tools would be updated to know about aliases and provide useful auto complete functionality that makes it clear this is an alias. But yes, of course I knowledge there would definitely be the possibility of bugs created by an accidental typo that happened to also be an alias. *For convenient addition of aliases and discovering them for a specific member: * There are likely all sorts of ways you could do this. Perhaps a dunder alias combined with an alias decorator could be added (probably in functools? not top level)? You could add an alias like: @functools.alias("load_str") def loads(...): ... assert loads.__alias__ == ["load_str"] class MyClass: @functools.alias("prof") def process_file(self, ...): ... assert MyClass.process_file.__alias__ == ["prof"] I'm sure this is an extreme idea and likely nobody is going to be interested. But I started writing it and couldn't stop.

What happens when aliases collide with proper attributes? Could you have an attribute 'foo', combined with an attribute 'bar' with alias 'foo'? If so, how would that work?

Using a ChainMap makes this choice for us. The first level dictionary-- which would contain the attribute with the name collision-- wins.

What happens when a subclass of Foo adds an attribute that masks an alias defined for an attribute of Foo?

Again, the child attribute wins because ChainMap.

On 2019-11-30 05:28, Andrew Barnert via Python-ideas wrote:

On Nov 29, 2019, at 02:42, Steven D'Aprano <steve@pearwood.info> wrote:

...

Programming uses lots of initialisms, abbreviations and hybrid words, such as:

os ram ssd dir json xml len chr EOF I/O rlcompleter pprint sqlite

etc, and loads is not particularly worse than the rest.

I agree with your sentiment; and I’m -1 on the change, but it’s worth pointing out that the amount of abbreviation and portmanteuing that’s considered appropriate has changed over the years. The names Guido gave things in 1991 aren’t necessarily the names he’d come up with today; if he were inventing `loads` 28 years later, I think he would have called it `load_string`. And, if not, he would have changed his mind during the bikeshedding process when 80% of the people paying attention argued against it.

It’s not even that people have decided that reading code is more important than writing it (or that the novice learning curve matters), After all, sometimes brevity is better for reading, too. So there’s still a balance. It’s just that the balance in the 70s was based on reading and writing on slow teletypes where you had to fit your program into a few KB, while now you have all the screen space and storage you could want and instantaneous auto-complete and so on, so the cost of longer names is a lot lower. And, while Python isn’t quite _that_ old, the balance in Python 0.9 was about fitting in with C in a Unix-ish system, while now Python is about being good for everything from scripts to servers. That’s why we usually get names like `get_current_loop` today instead of names like `getcwd`. (But not always—e.g., new additions to `math` that wrap or emulate `math.h` functions still get C-style names.)

I wouldn't like it if the names got too long. I find a certain amount of abbreviation makes it easier to read in the long run.

On Nov 30, 2019, at 05:10, Stephen J. Turnbull <turnbull.stephen.fw@u.tsukuba.ac.jp> wrote:

Why "new" users? Because experienced users will have their "intuition" informed by their experience with "traditional" ways of expression as codified in identifiers and syntax. For example, while augmented assignment turns out to be useful to provide mutating operations and signal them to the reader, the increment operation is purely syntactic sugar compared to "i += 1" as a statement, but insufficiently powerful and orthogonal as an expression to add to Python. Yet C-experienced users frequently requested the increment operator.

I’m not sure this example really argues the case. To an experienced C programmer, both += and ++ are intuitive. But to a novice who’s never programmed, neither one is intuitive. The way to distinguish between them is to delve into the C programmers’ intuition and understand what drives it. First, ++ is used almost entirely as an expression in C, and the postfix form is only useful as an expression, but += is often used as a statement. But Python expressions (for the next few decades until :=, at least) normally don’t mutate things, except for explicit method calls which by convention return None. So neither of them should be an expression in Python, which is a strike against the C intuition for usability of ++ being transferable to Python, but not against +=. Furthermore, ++ is only useful on index-like values, and, unlike C, all of these are immutable in Python (at least until someone invents numpy index arrays as indexes), while += is useful on all numeric-like and sequence-like values, and the prototypical sequence-like type, list, is mutable. This is another strike against ++ but not +=. Of course that’s only two strikes. But now, when you’re balancing the cost (two extra methods, one of which is mildly confusing, vs. one, and prefix ++ requires an extra lookahead to distinguish from prefix +, but += and postfix ++ don’t) against the benefit… I don’t think Guido actually went through all of this in conscious detail, much less on paper (the way we would if someone were proposing ++ and += in the age of PEPs and -ideas and -dev), but I think it’s the main underlying reason he decided that borrowing += but not ++ made sense for Python. Not imagining whether new users would clamor first += but not ++, or be able to learn each when they see it, but knowing that C programmers would find them both intuitive but that their intuition for ++ doesn’t make sense for Python while their intuition for += does.

On Nov 30, 2019, at 10:25, MRAB <python@mrabarnett.plus.com> wrote:

On 2019-11-30 05:28, Andrew Barnert via Python-ideas wrote:

...

...

On Nov 29, 2019, at 02:42, Steven D'Aprano <steve@pearwood.info> wrote: Programming uses lots of initialisms, abbreviations and hybrid words, such as: os ram ssd dir json xml len chr EOF I/O rlcompleter pprint sqlite etc, and loads is not particularly worse than the rest. I agree with your sentiment; and I’m -1 on the change, but it’s worth pointing out that the amount of abbreviation and portmanteuing that’s considered appropriate has changed over the years. The names Guido gave things in 1991 aren’t necessarily the names he’d come up with today; if he were inventing `loads` 28 years later, I think he would have called it `load_string`. And, if not, he would have changed his mind during the bikeshedding process when 80% of the people paying attention argued against it. It’s not even that people have decided that reading code is more important than writing it (or that the novice learning curve matters), After all, sometimes brevity is better for reading, too. So there’s still a balance. It’s just that the balance in the 70s was based on reading and writing on slow teletypes where you had to fit your program into a few KB, while now you have all the screen space and storage you could want and instantaneous auto-complete and so on, so the cost of longer names is a lot lower. And, while Python isn’t quite _that_ old, the balance in Python 0.9 was about fitting in with C in a Unix-ish system, while now Python is about being good for everything from scripts to servers. That’s why we usually get names like `get_current_loop` today instead of names like `getcwd`. (But not always—e.g., new additions to `math` that wrap or emulate `math.h` functions still get C-style names.) I wouldn't like it if the names got too long. I find a certain amount of abbreviation makes it easier to read in the long run.

Sure. That’s why I said “After all, sometimes brevity is better for reading too. So there’s still a balance.” I’m not suggesting that the default has shifted all the way to spelling out everything, or that it ever will, much less arguing that we should change it. Just pointing out that we spell things out _more_ in 2019 Python than we did in 1978 C or even 1991 Python, and we probably wouldn’t have spelled this function `loads` if it were part of a new module added today rather than part of marshal added in 1.x.

On Sat, Nov 30, 2019 at 01:30:55PM -0500, Ricky Teachey wrote:

Consulting two dictionaries instead of one is a very very very minor penalty.

It's more than twice as expensive: not only do you have to do two look ups rather than one, but you have to also look up the second dict as well. And there's the overhead of the ChainMap itself. $ ./python -m timeit -s "d = {}" "d.get('aardvark')" 500000 loops, best of 5: 702 nsec per loop $ ./python -m timeit -s "from collections import ChainMap" -s "d = ChainMap([{}, {}])" "d.get('aardvark')" 20000 loops, best of 5: 12.3 usec per loop That's 17 times slower on my PC. -- Steven

On Sat, Nov 30, 2019 at 06:21:29PM +0000, MRAB wrote:

I wouldn't like it if the names got too long. I find a certain amount of abbreviation makes it easier to read in the long run.

This. People are beginners for what, maybe 2 or 5% of their career as programmers? The minor benefit they get at their beginning of their career from reading "load_from_string" instead of "loads" is outweighed twenty times over by the cost of having to read "load_from_string" instead of "loads" for the rest of their career. There's a reason why fluent English speakers prefer short words like "car" or "bus" over long words like "automobile" and "omnibus". (German speakers may disagree.) -- Steven

Me too. I'm a relative python-ideas newb, though, so I don't really know the back catalog. On Sat, Nov 30, 2019, 18:46 Christopher Barker <pythonchb@gmail.com> wrote:

On Sat, Nov 30, 2019 at 3:02 AM Brian Skinn <brian.skinn@gmail.com> wrote:

...

That aside, absolutely +1 for curating such a list. Excellent idea.

Thanks -- I hope you'll be able to contribute.

-CHB

...

_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/4W3WDQ... Code of Conduct: http://python.org/psf/codeofconduct/

-- Christopher Barker, PhD

Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython

On Nov 30, 2019, at 16:15, Steven D'Aprano <steve@pearwood.info> wrote:

On Sat, Nov 30, 2019 at 11:54:35AM -0800, Andrew Barnert via Python-ideas wrote:

...

To an experienced C programmer, both += and ++ are intuitive. But to a novice who’s never programmed, neither one is intuitive.

Can we have a moratorium on the use of the word "intuitive" until people learn to stop misusing it for "things people have learned to expect"?

It’s not “things people have learned to expect”, it’s “things people apprehend without having to think consciously”. Which is what “intuitive” means. It doesn’t matter whether that intuition is pre-wired instinct or conditioning or intellectual learning or some neurotic mistake.

Neither += or ++ are intuitive to C programmers, or anyone else. You wouldn't say that the meaning of "python" was intuitive would you? Or driving a car?

Yes. There are books about intuitive design that talk about why you wouldn’t make a new left-side-drive car with the gas pedal on the left. Why? Because that would violate drivers’ intuitions.

intuitive adj 1: spontaneously derived from or prompted by a natural tendency; "an intuitive revulsion" 2: obtained through intuition rather than from reasoning or observation [syn: intuitive, nonrational, visceral]

What dictionary gives “intuitive” as a synonym for itself? The first definition on Wiktionary is “Spontaneous, without requiring conscious thought”. You used “The reader has become accustomed to the symbol, and understands it without having to consciously think about it” as a description of whatever-it-is to contrast with intuition, but it is intuition. When you apprehend something without being conscious of how you got there, that’s intuition. Even using your definition: How does a C programmers understand that `x += 2`? It’s not by reasoning or observation; it’s by knowing what += means without having to reason it through. (It’s definitely not a conditioned response, as you suggested later, unless you’re a hardcore behaviorist who believes that things like responding in a conversation or writing code are directly mediated by external stimuli.)

I think you are talking about reading of words/symbols which, through long use, have become second-nature.

I was quoting Stephen, who wrote a whole long email explaining what he was talking about. Admittedly he did use scare quotes, but I don’t think they were needed. Since we’re talking about programming languages, it’s worth looking next door at how mathematicians (and philosophers of math) use the word. When they talk about the need to get a new construction into their intuition so they can play with it, they’re not talking about needing a time machine to go back and change human history so they will have been born pre-wired to get this construction “naturally”, they’re talking about learning it to the point where using it feels the same as the things that were pre-wired, like (maybe) counting. When you can read XYX^-1 and understand what it means without having to translate it to the low-level matrix multiplication rules and work it out, you understand matrix multiplication intuitively. (Of course there are people who disagree with this view of math—including the ones that call themselves intuitionists—but their disagreement assumes the same notion of intuitive; they just believe things like infinity can’t possibly be intuitive, and therefore most mathematicians must be fooling themselves about what they “know”. ) But yes, learning things until they become second-nature (at least learning how to use things, as opposed to learning about them) is exactly what getting things into your intuition means, not just for math but for everything. If you want to, you can get prescriptivist and argue that mathematicians and everyone else are misusing the word (and Wiktionary shouldn’t be endorsing this destruction of our language), but if you look at the history back to the original etymology, it’s always been about “look at it and get it”, not about whether that ability was inborn, conditioned, or learned intellectually.

Abdur-Rahmaan Janhangeer http://www.pythonmembers.club | https://github.com/Abdur-rahmaanJ Mauritius On Thu, 28 Nov 2019, 15:24 Abdur-Rahmaan Janhangeer, <arj.python@gmail.com> wrote:

"Designed With Learning in Mind"

I had no idea Guido told that or Python vowed that but thought it was a cool concept to design APIs with teachability in mind.

Does functools.update_wrapper() *copy* __doc__ and __annotations__ or *reference* those function/method attributes so that the API docs have the docstrings and tools with type annotation support have the correct type annotations? https://docs.python.org/3/library/functools.html#functools.update_wrapper On Saturday, November 30, 2019, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:

On 1/12/19 5:00 am, Ricky Teachey wrote:

...

Perhaps aliases of objects could be something worth baking into the

language itself.

We would have to be using aliases a *lot* to make something like this worthwhile. I don't think that's something we should be doing or encouraging.

Also, for the use case being considered -- renaming functions and methods -- garbage collection is hardly an issue.

If you want the help for an alias to be different from the thing it aliases, you can achieve that now using a stub function that delegates to the replacement.

-- Greg _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/FEERFE... Code of Conduct: http://python.org/psf/codeofconduct/

On Sat, Nov 30, 2019 at 11:13:54PM -0500, Wes Turner wrote:

Does functools.update_wrapper() *copy* __doc__ and __annotations__ or *reference* those function/method attributes so that the API docs have the docstrings and tools with type annotation support have the correct type annotations? https://docs.python.org/3/library/functools.html#functools.update_wrapper

Right at the top of the page is a link to the source code, so you ought to be able to tell from reading the source, which is in Python. I would expect that since __doc__ is a string or None, and in both cases immutable, copying it would be a waste of time. (And impossible in the case of None.) I'm gratified to see from the source that I'm correct: update_wrapper calls: setattr(wrapper, attr, value) not setattr(wrapper, attr, copy.copy(value)) or similar. Does that answer your question? If I have misunderstood your question, please clarify. -- Steven

I'm lost in that new mail interfacs, i'm lost, really lost. It's the 'HyperTrippy' version. Abdur-Rahmaan Janhangeer http://www.pythonmembers.club | https://github.com/Abdur-rahmaanJ Mauritius

Andrew Barnert via Python-ideas writes:

It’s not “things people have learned to expect”, it’s “things people apprehend without having to think consciously”. Which is what “intuitive” means.

I believe many people make a distinction between unconscious apprehension as perception ("intuition") and unconscious apprehension as memory ("training", "custom", or "habit"). Practically that may be a distinction without a difference, but that's a different argument. This distinction is made, even if you wouldn't.

It doesn’t matter whether that intuition is pre-wired instinct or conditioning or intellectual learning or some neurotic mistake.

I think "pre-wired instinct" is indeed different, though. That will evolve on a different time scale from conditioning, etc (at least, the millennials who made "OK, Boomer" trend think so!) You also omit the mystical "direct grasping" of Zen, which supposes that intuition is an emergent phenomenon of conscious mind. (I don't claim such "direct grasping" exists, or that anyone in this thread does, but there are definitely people who do.) Steve

Well, `json` and the other modules could add another standard: `serialize` and `deserialize` As an example, this is how I deserialize from a custom class: def __init__(self, source): path = None try: # most common case: JSON string self._data_raw = json.loads(source) except TypeError: try: # check if it's a dict-like object source.items self._data_raw = copy.deepcopy(source) except AttributeError: try: # maybe a file object? self._data_raw = json.load(f) except AttributeError: # maybe a PathLike? path = source except JSONDecodeError: # maybe a path string? path = source if path: with open(path) as f: self._data_raw = json.load(f) Apart the `dict` check, this logic could be applied to a `json.deserialize()` function. Python let you function overloading more simple, so why not use it?