[Python-ideas] Re: Renaming json.load()

I second that.. json.load/loads and json.dump/dumps should be more understandable.. On Thu, 26 Dec, 2019, 04:50 python-ideas--- via Python-ideas, < python-ideas@python.org> wrote: > Well, `json` and the other modules could add another standard: `serialize` > and `deserialize` > > As an example, t

[Python-ideas] Re: Renaming json.load()

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 = js

[Python-ideas] Re: Renaming json.load()

Andrew Barnert writes: > 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. I'm sorry, I expressed my point poorly, which is, first, that IMHO your statement a

[Python-ideas] Re: Renaming json.load()

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 ("intuitio

[Python-ideas] Re: Renaming json.load()

On Nov 30, 2019, at 20:13, Steven D'Aprano wrote: > > On Sat, Nov 30, 2019 at 05:31:01PM -0800, Andrew Barnert wrote: >>> On Nov 30, 2019, at 16:15, Steven D'Aprano wrote: >>> On Sat, Nov 30, 2019 at 11:54:35AM -0800, Andrew Barnert via Python-ideas >>> wrote: >>> To an experienced C pr

[Python-ideas] Re: Renaming json.load()

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 ___ Python-ideas mailing list -- python-ideas@python.org To u

[Python-ideas] Re: Renaming json.load()

On Sat, Nov 30, 2019 at 07:40:13PM -0500, Brian Skinn wrote: > Me too. I'm a relative python-ideas newb, though, so I don't really know > the back catalog. In your Copious Spare Time(TM), I can highly recommend randomly browsing the archives looking for subjects which seem interesting to you. I'

[Python-ideas] Re: Renaming json.load()

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?

[Python-ideas] Re: Renaming json.load()

Apparently hitting "Send" when I intended to hit "Save" to come back and edit the message further is also "intuitive", since it involved no conscious thought. Sorry about that. Aside from cleaning up or removing some of the unfinished paragraphs, one of the major points I intended to make is th

[Python-ideas] Re: Renaming json.load()

Abdur-Rahmaan Janhangeer http://www.pythonmembers.club | https://github.com/Abdur-rahmaanJ Mauritius On Thu, 28 Nov 2019, 15:24 Abdur-Rahmaan Janhangeer, 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 AP

[Python-ideas] Re: Renaming json.load()

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 ca

[Python-ideas] Re: Renaming json.load()

On Nov 30, 2019, at 16:15, Steven D'Aprano 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 mora

[Python-ideas] Re: Renaming json.load()

> > 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-ideas] Re: Renaming json.load()

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 wrote: > > > On Sat, Nov 30, 2019 at 3:02 AM Brian Skinn wrote: > >> That aside, absolutely +1 for curating such a list. Excellent idea. >> > > Thanks -- I

[Python-ideas] Re: Renaming json.load()

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

[Python-ideas] Re: Renaming json.load()

On Sat, Nov 30, 2019 at 06:21:29PM +, 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

[Python-ideas] Re: Renaming json.load()

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

[Python-ideas] Re: Renaming json.load()

On Sat, Nov 30, 2019 at 3:02 AM Brian Skinn 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 unsubs

[Python-ideas] Re: Renaming json.load()

On 1/12/19 8:54 am, Andrew Barnert via Python-ideas wrote: but that their intuition for ++ doesn’t make sense for Python while their intuition for += does. Another couple of possible reasons: * There is far less use for ++ in Python. In C, it's extremely common to step through arrays by incre

[Python-ideas] Re: Renaming json.load()

On Nov 30, 2019, at 10:25, MRAB wrote: > > On 2019-11-30 05:28, Andrew Barnert via Python-ideas wrote: >>> On Nov 29, 2019, at 02:42, Steven D'Aprano wrote: >>> Programming uses lots of initialisms, abbreviations and hybrid words, such >>> as: >>> os ram ssd dir json xml len chr EOF I/O rlco

[Python-ideas] Re: Renaming json.load()

On Nov 30, 2019, at 08:02, Ricky Teachey wrote: > >  > 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? >

[Python-ideas] Re: Renaming json.load()

On Nov 30, 2019, at 05:10, Stephen J. Turnbull 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

[Python-ideas] Re: Renaming json.load()

> Also, I have to think this would be appreciably slower than the current > mechanism, having to run through this ChainMap cascade for (almost) *every* > attribute lookup? > If I remember correctly, ChainMap is pretty fast. I doubt it would be appreciably slower, though it would undoubtedly be som

[Python-ideas] Re: Renaming json.load()

On 2019-11-30 05:28, Andrew Barnert via Python-ideas wrote: On Nov 29, 2019, at 02:42, Steven D'Aprano 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 particular

[Python-ideas] Re: Renaming json.load()

Ah, right -- relatively straightforward rule. But, one that's going to require a lot of careful thought to track down exactly how a name will resolve across an inheritance tree. Seems like a lot of extra complexity and potential for confusion for a comparatively small benefit. Also, I have to t

[Python-ideas] Re: Renaming json.load()

> 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 nam

[Python-ideas] Re: Renaming json.load()

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? What happens when a subclass of Foo adds an attribute that masks an alias defined for an attribute of Foo? Dragons. Compli

[Python-ideas] Re: Renaming json.load()

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 l

[Python-ideas] Re: Renaming json.load()

That would be PICT-000 (PEP 0 is the index) On 11/30/19 8:25 AM, Wes Turner wrote: > Though, PICT-001 should probably be reserved as an index for other > PICT documents. > > On Saturday, November 30, 2019, Paul Moore > wrote: > > On Sat, 30 Nov 2019 at 10:57, Brian Ski

[Python-ideas] Re: Renaming json.load()

Though, PICT-001 should probably be reserved as an index for other PICT documents. On Saturday, November 30, 2019, Paul Moore wrote: > On Sat, 30 Nov 2019 at 10:57, Brian Skinn wrote: >> >> Why, we could even number them, call them Python-Issues Common Threads, abbreviate that as "PICT", and the

[Python-ideas] Re: Renaming json.load()

I'd like to propose potentially adding my comments about strategies for learning APIs and typing through type annotations and introspection tooling with a potential PR to PICT-001. If there's interest, I'll consider preparing a PR? On Saturday, November 30, 2019, Paul Moore wrote: > On Sat, 30 N

[Python-ideas] Re: Renaming json.load()

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 conte

[Python-ideas] Re: Renaming json.load()

Abdur-Rahmaan Janhangeer writes: > Education is one side of it. It's about intuitive API Problem is, just the reactions to examples given in this thread demonstrate that personal intuition varies substantially. To identify the "intuitions" that reach the largest audience, the only halfway objec

[Python-ideas] Re: Renaming json.load()

On Sat, 30 Nov 2019 at 10:57, Brian Skinn 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] Re: Renaming json.load()

That aside, absolutely +1 for curating such a list. Excellent idea. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Mes

[Python-ideas] Re: Renaming json.load()

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 ... |-[ ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an ema

[Python-ideas] Re: Renaming json.load()

Abdur-Rahmaan Janhangeer http://www.pythonmembers.club | https://github.com/Abdur-rahmaanJ Mauritius On Sat, 30 Nov 2019, 09:36 Christopher Barker, wrote: > So we don't have to have this entire discussion the next time this comes > up, I've posted a summary here: > > > https://pythonchb.github.i

[Python-ideas] Re: Renaming json.load()

So we don't have to have this entire discussion the next time this comes up, I've posted a summary here: https://pythonchb.github.io/PythonListsSummaries/python_ideas/better_name.html Please feel free to link to that the next time :-) Better yet, contribute more summaries to the common issues th

[Python-ideas] Re: Renaming json.load()

On Fri, Nov 29, 2019 at 6:52 PM Steven D'Aprano wrote: > 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/

[Python-ideas] Re: Renaming json.load()

On Nov 29, 2019, at 02:42, Steven D'Aprano 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 sentime

[Python-ideas] Re: Renaming json.load()

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 sa

[Python-ideas] Re: Renaming json.load()

> I don't think we need to worry about people poking arbitrary values > into a stdlib module and breaking things. Agreed — and from years of participating in this community, I don’t think the danger of adding names to stdlib modules breaking people’s monkey-patched code has been a reason not to

[Python-ideas] Re: Renaming json.load()

On Sat, Nov 30, 2019 at 1:33 AM Richard Damon 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

[Python-ideas] Re: Renaming json.load()

On 11/29/19 7:21 AM, Chris Angelico wrote: > On Fri, Nov 29, 2019 at 9:48 PM Abdur-Rahmaan Janhangeer > wrote: >> One of them can maybe be deprectated >> >> json.load() >> >> for file: >> >> json.load(file=) >> > Deprecation is not a solution. You're still going to have stuff out > there using the

[Python-ideas] Re: Renaming json.load()

On 29/11/2019 10:45, Abdur-Rahmaan Janhangeer wrote: One of them can maybe be deprectated json.load() for file: json.load(file=) 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.

[Python-ideas] Re: Renaming json.load()

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 C

[Python-ideas] Re: Renaming json.load()

For python it's: for 2 use this, for 3 that (now everyone's pretty smart to distinguish). Talking of react, i'm thankful enough for py's std lib. Each time i switch to Js, i wish the std lib was a tidbit more furnished. Abdur-Rahmaan Janhangeer http://www.pythonmembers.club | https://github.com/Ab

[Python-ideas] Re: Renaming json.load()

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 wil

[Python-ideas] Re: Renaming json.load()

On Fri, Nov 29, 2019 at 9:48 PM Abdur-Rahmaan Janhangeer wrote: > > One of them can maybe be deprectated > > json.load() > > for file: > > json.load(file=) > Deprecation is not a solution. You're still going to have stuff out there using the old name (Stack Overflow posts, blogs, articles, books,

[Python-ideas] Re: Renaming json.load()

One of them can maybe be deprectated json.load() for file: json.load(file=) Abdur-Rahmaan Janhangeer http://www.pythonmembers.club | https://github.com/Abdur-rahmaanJ Mauritius ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe

[Python-ideas] Re: Renaming json.load()

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 s

[Python-ideas] Re: Renaming json.load()

> > > And PEP numbers have a fourth purpose when used as jargon (this > applies to any numbered formal standard such as RFCs or ISO): they are > self-citing. In that sense, they are *inclusive*. They're an > invitation to learn more than you ever wanted to know about the things > the community ca

[Python-ideas] Re: Renaming json.load()

Education is one side of it. It's about intuitive API Abdur-Rahmaan Janhangeer http://www.pythonmembers.club | https://github.com/Abdur-rahmaanJ Mauritius ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ide

[Python-ideas] Re: Renaming json.load()

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? Y

[Python-ideas] Re: Renaming json.load()

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

[Python-ideas] Re: Renaming json.load()

> > > I'd be +1 on adding a better named alias for loading strings to all of > these libraries. > > Including the ones that aren’t in the stdlib? If so, how do we do that? > Leading by example of not sticking forever with obfuscated naming. So the Very Good Thing isn’t actually as good... you ne

[Python-ideas] Re: Renaming json.load()

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

[Python-ideas] Re: Renaming json.load()

On Fri, Nov 29, 2019 at 7:59 AM Steven D'Aprano wrote: > 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 > commun

[Python-ideas] Re: Renaming json.load()

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

[Python-ideas] Re: Renaming json.load()

On Nov 28, 2019, at 06:31, Ricky Teachey wrote: > > I'd be +1 on adding a better named alias for loading strings to all of these > libraries. Including the ones that aren’t in the stdlib? If so, how do we do that? If not, won’t it be even more confusing for people who learn json.load_string

[Python-ideas] Re: Renaming json.load()

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 bike

[Python-ideas] Re: Renaming json.load()

I'd be +1 on adding a better named alias for loading strings to all of these libraries. Seems to me like it is a pretty awful naming convention even if it is standard across the profession, and that adding load_string or load_str as an alias for loads would be a Very Good Thing (TM) with few downs

[Python-ideas] Re: Renaming json.load()

"Designed With Learning in Mind" Abdur-Rahmaan Janhangeer http://www.pythonmembers.club | https://github.com/Abdur-rahmaanJ Mauritius ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org h

[Python-ideas] Re: Renaming json.load()

> 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 proc

[Python-ideas] Re: Renaming json.load()

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.py

[Python-ideas] Re: Renaming json.load()

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

[Python-ideas] Re: Renaming json.load()

It's about ambiguity. Maybe loads is short for load string which in english is also a verb. Abdur-Rahmaan Janhangeer http://www.pythonmembers.club | https://github.com/Abdur-rahmaanJ Mauritius On Thu, 28 Nov 2019, 12:38 Wes Turner, wrote: > An IDE with support for PEP 484 / mypy / type annotati

[Python-ideas] Re: Renaming json.load()

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 wrote: > An IDE with support for PEP 484 / mypy / type annotations (and/or writing tests) can help minimize typing-related errors. > > https://github.com/py

[Python-ideas] Re: Renaming json.load()

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-and-pre-commit On Wedne

[Python-ideas] Re: Renaming json.load()

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

[Python-ideas] Re: Renaming json.load()

On Nov 27, 2019, at 12:27, Abdur-Rahmaan Janhangeer 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-li

[Python-ideas] Re: Renaming json.load()

Those functions, ``load`` and ``loads``, for better or worse, are a standard across many modules. Now that the standard has been established, it's good to stick with it. Good interface design needs to consider familiarity as well as what might be best without any history. On Wed, Nov 27, 2019 at 1