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
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/
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
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
> 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
I'm sure there is any exemplary threads -- I don't recall one where we
didn't wonder off into the weeds, and repeat heck out of ourselves :-)
But this one wasn't too bad:
https://mail.python.org/pipermail/python-ideas/2015-January/030947.html
Lead to PEP 485 -- A Function for testing approximat
On Fri, Nov 29, 2019 at 8:30 AM Brandt Bucher
wrote:
> Yep. It’s also the only way that I know of to get the sign of a NaN. We
> can’t even parse the repr for that!
>
Exactly -- while a tiny bit handy for ints, floats are where it is really
*needed*.
And back to Guido's point -- while called "m
Yep. It’s also the only way that I know of to get the sign of a NaN. We can’t
even parse the repr for that!
Brandt
> On Nov 28, 2019, at 21:36, Guido van Rossum wrote:
> I suspect the only reason it exists as a builtin is that it handles -0.0
> correctly. But that's really only of interest to
Hi, Titus.
I’m not sure if this fits the bill, but this is the discussion that led to PEP
498 and f-strings:
https://mail.python.org/pipermail/python-ideas/2015-July/034657.html
--
Eric V. Smith
(301) 502-0945 cell
> On Nov 29, 2019, at 9:02 AM, C. Titus Brown wrote:
>
> Hi folks,
>
> I’m
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
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
Hi folks,
I’m working on some help documentation for python-ideas and first-time
contributors, and I’d like to include a few examples of discussions that were
productive and led to changes. I browsed through the archives and found a few
positive and negative examples (below) but didn’t find one
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.
On 11/28/19 2:51 PM, Marein wrote:
> The math.copysign(x, y) function always returns a float, even when the
> given x is an int, i.e. math.copysign(3, -1) gives -3.0. This is
> documented behaviour, but I find it somewhat surprising given that the
> name suggests that it only copies a sign, and it'
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
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
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
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,
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
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
20 matches
Mail list logo
