Re: [Python-ideas] Trial balloon: adding variable type declarations in support of PEP 484

[Guido van Rossum]

On Mon, Aug 8, 2016 at 11:17 PM, Greg Ewing <greg.ew...@canterbury.ac.nz>
wrote:

> אלעזר wrote:
>
>> class Starship(tuple):
>> damage: int = 0  captain: str  = "Kirk"
>>
>> Is an obvious syntax for
>> Starship = NamedTuple('Starship', [('damage', int), ('captain', str)])
>>
>
> But the untyped version of that already has a meaning --
> it's a tuple subclass with two extra class attributes
> that are unrelated to its indexable items.
>
> I thought that type annotations weren't meant to change
> runtime semantics?


Correct, but we can invent a new base class that has these semantics. It's
no different from Enum.

Anyway, I think this will have to be an add-on to be designed after the
basics are done.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Allow manual creation of DirEntry objects

[Guido van Rossum]

Brendan,

The conclusion is that you should just file a bug asking for a working
constructor -- or upload a patch if you want to.

--Guido

On Wed, Aug 17, 2016 at 12:18 AM, Nick Coghlan <ncogh...@gmail.com> wrote:

> On 17 August 2016 at 09:56, Victor Stinner <victor.stin...@gmail.com>
> wrote:
> > 2016-08-17 1:50 GMT+02:00 Guido van Rossum <gu...@python.org>:
> >> We could expose the class with a
> >> constructor that always fails (the C code could construct instances
> through
> >> a backdoor).
> >
> > Oh, in fact you cannot create an instance of os.DirEntry, it has no
> > (Python) constructor:
> >
> > $ ./python
> > Python 3.6.0a4+ (default:e615718a6455+, Aug 17 2016, 00:12:17)
> >>>> import os
> >>>> os.DirEntry(1)
> > Traceback (most recent call last):
> >   File "", line 1, in 
> > TypeError: cannot create 'posix.DirEntry' instances
> >
> > Only os.scandir() can produce such objects.
> >
> > The question is still if it makes sense to allow to create DirEntry
> > objects in Python :-)
>
> I think it does, as it isn't really any different from someone calling
> the stat() method on a DirEntry instance created by os.scandir(). It
> also prevents folks attempting things like:
>
> def slow_constructor(dirname, entryname):
> for entry in os.scandir(dirname):
> if entry.name == entryname:
> entry.stat()
> return entry
>
> Allowing DirEntry construction from Python further gives us a
> straightforward answer to the "stat caching" question: "just use
> os.DirEntry instances and call stat() to make the snapshot"
>
> If folks ask why os.DirEntry caches results when pathlib.Path doesn't,
> we have the answer that cache invalidation is a hard problem, and
> hence we consider it useful in the lower level interface that is
> optimised for speed, but problematic in the higher level one that is
> more focused on cross-platform correctness of filesystem interactions.
>
> I don't know whether it would make sense to allow a pre-existing stat
> result to be based to DirEntry, but it does seem like it might be
> useful for adapting existing stat-based backend APIs to a more user
> friendly DirEntry based front end API.
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
>



-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] "Immutable Builder" Pattern and Operator

[Guido van Rossum]

On Mon, Jan 23, 2017 at 8:07 AM, Soni L. <fakedme...@gmail.com> wrote:

>
>
> Since it desugars into `x = x.y`, you can literally use anything for `y`.
>
> x .= __call__().whatever().unwrap() * 3
>
> is equivalent to
>
> x = x.__call__().whatever().unwrap() * 3
>
> and
>
> x .= 1
>
> is equivalent to
>
> x = x.1
>
> which is equivalent to
>
> SyntaxError: invalid syntax
>

And that's exactly the problem. Users would be greatly confused because
what's to the right of `.=` is *not* an expression, it's something more
restricted (in particular it must start with a plain identifier). This
makes the `.=` operator a very different beast from `=`, `+=` and friends.

I assume you think that's fine, but given your cavalier attitude about `x
.= 1` my feeling is that you don't have a lot of experience designing and
implementing language features. That is okay, you are learning it here. But
perhaps you should take the hint from the large number of people here who
have gently tried to explain to you that while this is a good idea, it's
not a great idea, and there's no sufficiently important use case to make up
for the confusion (indicated above) that it will inevitably cause.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] globals should accept parenteses for extending beyond 1 line

[Guido van Rossum]

You can just write
  global foo, bar
  global baz, bletch

On Mon, Jan 23, 2017 at 10:43 AM, João Matos <jcrma...@gmail.com> wrote:

> Hello,
>
> I would like to suggest that globals should follow the existing rule
> (followed by the import statement, the if statement and in other places)
> for extending beyond 1 line using parentheses.
> Like this:
> globals (var_1, var_2,
> var_3)
>
> instead of what must be done now, which is:
> globals var_1, var_2 \
> var_3
>
>
> Best regards,
>
> JM
>
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>



-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Fused multiply-add (FMA)

[Guido van Rossum]

Does numpy support this?

--Guido (mobile)

On Jan 16, 2017 7:27 AM, "Stephan Houben"  wrote:

> Hi Steve,
>
> Very good!
> Here is a version which also handles the nan's, infinities,
> negative zeros properly.
>
> ===
> import math
> from fractions import Fraction
>
> def fma2(x, y, z):
> if math.isfinite(x) and math.isfinite(y) and math.isfinite(z):
> result = float(Fraction(x)*Fraction(y) + Fraction(z))
> if not result and not z:
> result = math.copysign(result, x*y+z)
> else:
> result = x * y + z
> assert not math.isfinite(result)
> return result
> ===
>
> Stephan
>
>
> 2017-01-16 12:04 GMT+01:00 Steven D'Aprano :
>
>> On Mon, Jan 16, 2017 at 11:01:23AM +0100, Stephan Houben wrote:
>>
>> [...]
>> > So the following would not be a valid FMA fallback
>> >
>> > double bad_fma(double x, double y, double z) {
>> >   return x*y + z;
>> > }
>> [...]
>> > Upshot: if we want to provide a software fallback in the Python code, we
>> > need to do something slow and complicated like musl does.
>>
>> I don't know about complicated. I think this is pretty simple:
>>
>> from fractions import Fraction
>>
>> def fma(x, y, z):
>> # Return x*y + z with only a single rounding.
>> return float(Fraction(x)*Fraction(y) + Fraction(z))
>>
>>
>> When speed is not the number one priority and accuracy is important,
>> its hard to beat the fractions module.
>>
>>
>> --
>> Steve
>> ___
>> Python-ideas mailing list
>> Python-ideas@python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Ideas for improving the struct module

[Guido van Rossum]

Nevertheless the C meaning *is* the etymology of the module name. :-)

--Guido (mobile)

On Jan 19, 2017 16:54, "Chris Angelico"  wrote:

> On Fri, Jan 20, 2017 at 11:38 AM, Steven D'Aprano 
> wrote:
> > On Fri, Jan 20, 2017 at 05:16:28AM +1100, Chris Angelico wrote:
> >
> >> To be fair, the name "struct" implies a C-style structure, which
> >> _does_ have a fixed size, or at least fixed offsets for its members
> >
> >
> > Ah, the old "everyone thinks in C terms" fallacy raises its ugly head
> > agan :-)
> >
> > The name doesn't imply any such thing to me, or those who haven't been
> > raised on C. It implies the word "structure", which has no implication
> > of being fixed-width.
>
> Fair point. Objection retracted - and it was only minor anyway. This
> would be a handy feature to add. +1.
>
> ChrisA
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Ideas for improving the struct module

[Guido van Rossum]

I'd be wary of making a grab-bag of small improvements, it encourages
bikeshedding.

--Guido (mobile)

On Jan 20, 2017 10:16 AM, "Ethan Furman"  wrote:

> On 01/20/2017 10:09 AM, Joao S. O. Bueno wrote:
>
>> On 20 January 2017 at 16:51, Elizabeth Myers wrote:
>>
>
> Should I write up a PEP about this? I am not sure if it's justified or
>>> not. It's 3 changes (calcsize and two format specifiers), but it might
>>> be useful to codify it.
>>>
>>
>> Yes - maybe a PEP.
>>
>
> I agree, especially if the change, simple as it is, requires a lot of
> rewrite.  In that case someone (ELizabeth?) should collect ideas for other
> improvements and shepherd it through the PEP process.
>
> --
> ~Ethan~
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Let’s make escaping in f-literals impossible

[Guido van Rossum]

I don't think we should take action now.

Would it make sense, as a precaution, to declare the PEP provisional for
one release? Then we can develop a sense of whether the current approach
causes real problems.

We could also emit some kind of warning if the expression part contains an
escaped quote, since that's where a potential change would cause breakage.
(Or we could leave that to the linters.)

-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] real numbers with SI scale factors: next steps

[Guido van Rossum]

On Wed, Aug 31, 2016 at 8:57 PM, Stephen J. Turnbull
<turnbull.stephen...@u.tsukuba.ac.jp> wrote:
> Random832 writes:
>
>  > Also, interesting quirk - it always rounds up. 1025 bytes is "1.1K", and
>  > in SI mode, 1001 bytes is "1.1k"
>
> That seems to be right approach: in system administration, these
> numbers are used mostly to understand resource usage, and
> underestimates are almost never what you want, while quite large
> overestimates are tolerable, and are typically limited because the
> actual precision of calculations is much higher than that of the
> "human-readable" output.

That would seem to apply to "space used" but not to "space available".

-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Let’s make escaping in f-literals impossible

[Guido van Rossum]

Philipp, you need to stop debating this issue *now*.

You need to write a PEP that can go into Python 3.7. Further debate at
the current level (a hair-width close to name-calling) is not going to
sway anyone.

(This actually goes for Chris too -- nothing is obviously going to
change Philipp's mind, so you might as well stop debating and save all
the onlookers the embarrassment.)

-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Let’s make escaping in f-literals impossible

[Guido van Rossum]

Please just call it f-string and move on, we've had the naming debate
previously, it's no longer productive.

Regarding eventually supporting f'{'x'}', that will have to be a new
PEP to extend PEP 498. (I previously thought it would be an
incompatibility, but since f'{' is currently invalid, it's not.
However it's a huge change conceptually and implementation-wise, and I
don't blame Eric if he doesn't want to be responsible for it. So it
has to be a new PEP, to be introduced in 3.7 at the earliest.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] real numbers with SI scale factors

[Guido van Rossum]

On Tue, Aug 30, 2016 at 11:48 AM, Ken Kundert
<python-id...@shalmirane.com> wrote:
> [...] Similarly when people refer to the length of
> the Olympic road race in Rio, they say 56km, not 56000m.

However I can't help to point out that if I said the distance to the
sun is 149.6 Gm, most people would do a double-take.

> This is really only an issue with output.

So maybe the proposal should be toned down to just a way to request SI
units when formatting numbers?

-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] real numbers with SI scale factors: next steps

[Guido van Rossum]

On Wed, Aug 31, 2016 at 5:21 AM, Nick Coghlan <ncogh...@gmail.com> wrote:
> On 31 August 2016 at 17:07, Chris Angelico <ros...@gmail.com> wrote:
>> On Wed, Aug 31, 2016 at 2:08 PM, Ken Kundert
>> <python-id...@shalmirane.com> wrote:
>>> > What's the mnemonic here? Why "r" for scale factor?
>>>
>>> My thinking was that r stands for real like f stands for float.
>>> With the base 2 scale factors, b stands for binary.
>>
>> "Real" has historically often been a synonym for "float", and it
>> doesn't really say that it'll be shown in engineering notation. But
>> then, we currently have format codes 'e', 'f', and 'g', and I don't
>> think there's much logic there beyond "exponential", "floating-point",
>> and... "general format"? I think that's a back-formation, frankly, and
>> 'g' was used simply because it comes nicely after 'e' and 'f'. (C's
>> decision, not Python's, fwiw.) I'll stick with 'r' for now, but it
>> could just as easily become 'h' to avoid confusion with %r for repr.
>
> "h" would be a decent choice - it's not only a continuation of the
> e/f/g pattern, it's also very commonly used as a command line flag for
> "human-readable output" in system utilities that print numbers.

I like it. So after all the drama we're just talking about adding an
'h' format code that's like 'g' but uses SI scale factors instead of
exponents. I guess we need to debate what it should do if the value is
way out of range of the SI scale system -- what's it going to do when
I pass it 1e50? I propose that it should fall back to 'g' style then,
but use "engineering" style where exponents are always a multiple of
3.)

> The existing "alternate form" marker in string formatting could be
> used to request the use of the base 2 scaling prefixes rather than the
> base 10 ones: "#h".

Not sure about this one.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Fwd: Null coalescing operator

[Guido van Rossum]

On Sun, Sep 11, 2016 at 12:44 PM, Daniel Moisset
<dmois...@machinalis.com> wrote:
> Both this discussion, PEP 505, and the one a year ago, tend to mix up 2
> related but separate proposals:

I don't think there's that much of a mix-up. PEP 505 clearly describes
each proposal separately and even gives a choice to accept or reject
each one separately.

> (A) Add a None-coalescing operator (like C# a ?? b, what you would write in
> Python as "a or b" if it didn't have the falsy gotcha)

https://www.python.org/dev/peps/pep-0505/#none-coalescing-operator

> (B) Add some None-aware navigation operators ( The "?.", "?()", "?[]", or
> what you would write in python as "a and a.attribute" if it didn't have the
> falsy gotcha)

https://www.python.org/dev/peps/pep-0505/#none-aware-attribute-access-operator

> Both are things that can be already done in python, so the purpose here is
> to add some convenience (aka "syntax sugar"). IMO, this kind of syntax sugar
> proposals should be weighed with the frequency of the coding pattern where
> the sugar can be applied. And from the stats presented in PEP-505 (B) is one
> order of magnitude less usual than (A); that matches most of the examples I
> see in the threads and FWIW my personal experience.

I can't argue here yet. Honestly I looked at some examples; for those
where it wasn't instantly clear that a None-coalescing operator would
*not* help, I found it hard to figure out how to rewrite it. E.g. this
one -- quick, is there a better way?

  return "Illegal Argument" + (self.message is not None and (": " +
self.message) or "")

I think the answer is, if we had both None-coalescing (??) and
None-severing (!!) it could be written as follows:

  return "Illegal Argument" + ((self.message !! (": " + self.message)) ?? "")

but it took me way too long to prove that to myself.

> So, as a counterproposal I would like to suggest:
>
> * Add an "a ?? b" operator which is equivalent to "a if a is None else b"
> (but evaluating a once)

> * Do not add none-aware navigation; in the less usual scenario where you
> need to do it AND ALSO the "and" operator is not usable (it frequently is,
> given that by default classes are truish), well, you can use a ternary
> operator

Honestly the one thing that makes `?.` attractive is that it's easier
than the None-coalescing and -severing operators to grasp at an
intuitive level. If "foo.bar" raises "AttributeError: 'NoneType'
object has no attribute 'foo'" then try again with "foo?.bar". It's
surprising how often that will work!

> * I don't care if it's an alternate syntax (I'm surprised nobody suggested
> "||" which is also used in other languages for similar purpose)

Interestingly, after analyzing the above example I desperately want to
write it as

  return "Illegal Argument" + (self.message && (": " + self.message) || "")

Note that I already know the relative priorities of && and ||, so I
can drop a set of parentheses.

> Would this satisfy most of the people requesting this? (and, would it
> satisfy the people making the decision?)

Personally, after the above example, I'm less excited about ??/!! or
||/&&, and more excited about `?.` -- so it doesn't satisfy me.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Fwd: Null coalescing operator

[Guido van Rossum]

On Sun, Sep 11, 2016 at 6:00 PM, David Mertz <me...@gnosis.cx> wrote:
> None if a is None else a.foo

This is the crux of the matter to me. It's just too verbose, and the
`if` and `else` keywords are lost in the noise of all the other words
on the line. Plus the big win when it applies) is that if `a` is in
fact something more complex, like `f(a)`, repeating it twice sounds
like a performance penalty, and that's where `f(a)?.foo` really
shines.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] New Python syntax for continuing definitions for existing classes

[Guido van Rossum]

There shall be no standard syntax for monkey-patching.

Decorators are fine. I recommend putting a monkey-patching package on
PyPI and see if people use it.

Maybe eventually it can be in the stdlib but I really don't want to
encourage this idiom (even if it's sometimes useful). You should
always consider other options (like petitioning upstream for a better
API) before accepting the need to monkey-patch.

On Wed, Sep 14, 2016 at 8:46 AM, Pim Schellart
<p.schell...@princeton.edu> wrote:
> Dear All,
>
> Thank you for your feedback!
> While we think the decorator solution is not as writable, readable or 
> discoverable as our
> proposed syntax we understand the desire to discourage a potential
> paradigm switch to `open classes’.
>
> We recognise that in many cases refactoring the code to eliminate the need 
> for monkey patching
> is the preferable solution. However, there are many instances where this is 
> not the case, such as
> the one Guido described in 
> https://mail.python.org/pipermail/python-dev/2008-January/076194.html.
>
> Personally, we have encountered the need for this in many projects each of us 
> have worked on.
> The fact that monkey patching is common enough lexicon to be mentioned in 
> Python programming
> books highlights the fact that programmers may encounter this in codebases 
> they work on.
>
> In particular when using third party libraries or code written in other 
> languages wrapped into Python,
> the existing syntaxes are less readable and non-standard.
> Each project using such codes is thus forced to come up with their own custom 
> solution leading
> to a somewhat fractured appearance in otherwise similar Python codebases.
>
> We had hoped to come up with a standardised solution. And if new syntax is 
> not desirable, perhaps
> including other solutions such as the proposed decorator in the standard 
> library is an option?
> Or do you feel this is a problem that should be solved by better 
> documentation and understanding
> instead?
>
> Kind regards,
>
> Pim Schellart & Nate Lust
>> On 14 Sep 2016, at 08:02, Nick Coghlan <ncogh...@gmail.com> wrote:
>>
>> On 14 September 2016 at 05:46, Ralph Broenink <ra...@ralphbroenink.net> 
>> wrote:
>>> Hi all,
>>>
>>> On Tue, 13 Sep 2016 at 18:30 Chris Angelico <ros...@gmail.com> wrote:
>>>>
>>>> Did you know that you can actually abuse decorators to do this with
>>>> existing syntax? Check out this collection of evil uses of decorators:
>>>>
>>>> https://github.com/Rosuav/Decorators/blob/master/evil.py
>>>
>>> There's also this  post from Guido a few years back in python-dev, which
>>> does something similar using metaclasses:
>>>
>>> https://mail.python.org/pipermail/python-dev/2008-January/076194.html
>>>
>>> I'm not sure it does exactly the same, but it is also an interesting
>>> approach. (Although I like the decorator syntax more.) The discussion that
>>> follows in that thread may also be of interest for this discussion.
>>
>> PEP 422 and its reference implementation had a more fleshed out
>> implementation of that concept:
>> https://www.python.org/dev/peps/pep-0422/#new-ways-of-using-classes
>>
>> With class namespaces becoming ordered by default, I ended up
>> withdrawing PEP 422 in favour of the simpler PEP 487 that's actually
>> in 3.6: https://www.python.org/dev/peps/pep-0487/
>>
>> I do think Pim's proposal is an excellent exemplar of what a PEP
>> should be, and if we *did* want to make class extension easier than it
>> already is, then the suggested "continue class ..." syntax would be an
>> elegant way of spelling it.
>>
>> However, I also believe the proposal founders on:
>>
>> 1. Class extensions are a fundamentally bad idea from a
>> maintainability perspective, as they make the original class
>> definition incomplete with no local indicator of its lack of
>> completeness (hence the "don't do this" caveat on the relevant example
>> in PEP 422)
>> 2. There are already ways to do this using metaclasses that provide a
>> local indicator at the point of definition that the affected class is
>> extensible (i.e. the use of the custom metaclass, or inheritance from
>> a base class that uses it) and hence that the given definition may be
>> incomplete
>>
>> Cheers,
>> Nick.
>>
>> --
>> Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
>> ___
>> Python-ideas mailing list
>> Python-ideas@python.or

Re: [Python-ideas] Changing optimisation level from a script

[Guido van Rossum]

What is to stop you from adding this to micropython as a library
extension? I've never felt the urge to do this and I don't think I've
ever heard it requested before. If you think it should be in the
stdlib, given the timing of the 3.6 feature freeze the earliest time
it could land would be Python 3.7. Finally, let's not define APIs with
British spelling. :-)

On Thu, Sep 8, 2016 at 9:35 PM, Damien George <damien.p.geo...@gmail.com> wrote:
> Hi all,
>
> When starting CPython from the command line you can pass the -O option
> to enable optimisations (eg `assert 0` won't raise an exception when
> -O is passed).  But, AFAIK, there is no way to change the optimisation
> level after the interpreter has started up, ie there is no Python
> function call or variable that can change the optimisation.
>
> In MicroPython we want to be able to change the optimisation level
> from within a script because (on bare metal at least) there is no
> analog of passing options like -O.
>
> My idea would be to have a function like `sys.optimise(value)` that
> sets the optimisation level for all subsequent runs of the
> parser/compiler.  For example:
>
> import sys
> import mymodule # no optimisations
> exec('assert 0') # will raise an exception
> sys.optimise(1) # enable optimisations
> import myothermodule # optimisations are enabled for this (unless it's
> already imported by mymodule)
> exec('assert 0') # will not raise an exception
>
> What do you think?  Sorry if this has been discussed before!
>
> Cheers,
> Damien.
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/



-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Null coalescing operator

[Guido van Rossum]

On Sat, Sep 10, 2016 at 11:09 AM, MRAB <pyt...@mrabarnett.plus.com> wrote:
> On 2016-09-10 18:44, Paul Moore wrote:
>>
>> On 10 September 2016 at 18:26, Guido van Rossum <gu...@python.org> wrote:
>>>
>>> IMO the key syntax is
>>> simply one for accessing attributes returning None instead of raising
>>> AttributeError, so that e.g. `foo?.bar?.baz` is roughly equivalent to
>>> `foo.bar.baz if (foo is not None and foo.bar is not None) else None`,
>>> except evaluating foo and foo.bar only once.
>>
>>
>> If we're not looking to use all the other null-coalescing variants
>> (?=, ?(), ...) - which is something I'm pleased about, as I do think
>> that scattering that many ?'s about is likely to lead to ugly code -
>> then it would probably be fine to just use ? for this operation, so
>> we'd have foo?bar?baz rather than needing foo?.bar?.baz.
>>
> I think that's not as clear; the "?." at least looks like a form of
> attribute access.
>
> It would also mean that it would be more difficult to add the other
> null-coalescing variants later, if the need arose.

Indeed. And ?. is how this is spelled in some other lanuages (C# and Dart).

I forgot one detail that's in PEP 505: e.g. `foo?.bar.baz()` should be
implemented as `foo.bar.baz() if foo is not None else None`. IOW if
foo is None, the entire trailing section `.bar.baz()` should be
skipped. (But this is a property of `?.` as an alternative attribute
access operator; it doesn't mean `?` is a postfix operator on `foo`.)

Another issue already discussed in PEP 505 is a conflict with IPython
(Jupyter Notebook), which uses ? and ?? as custom syntax to request
help. But maybe it can be taught to only recognize those when they're
the last character(s) on the line?

-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Null coalescing operator

[Guido van Rossum]

On Sat, Sep 10, 2016 at 4:27 PM, Chris Angelico <ros...@gmail.com> wrote:
> On Sun, Sep 11, 2016 at 9:10 AM, Guido van Rossum <gu...@python.org> wrote:
>> So you're offering `NoneCoalesce(x).bar` as less-ugly alternative to
>> `x?.bar`... Color me unconvinced.
>
> As a syntactic form? Not interested. But what if it's the underlying
> implementation? We have "yield from X" as a tidy syntax for roughly a
> page of equivalent code. We could have "x?.bar" as syntactic sugar for
> "NoneCoalesce(x).bar".

PEP 505 has an option for a way to customize the coalescing operation
(https://www.python.org/dev/peps/pep-0505/#generalized-coalescing).
Though I think I'd rather not do that.

But it just occurs to me that the implementation given by David Mertz
is not what I'd expect: it seems that `NoneCoalesce([]).flup` would
catch the AttributeError (there' no `[].flup`) and return
NoneCoalesce(None), whereas I would expect `?.` to only return None
when the LHS is None, not when some other not-None object doesn't have
the requested attribute. (And the "pile of poo" operator in PEP 505
agrees with me.)

-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Fwd: Null coalescing operator

[Guido van Rossum]

There seems to be a major misunderstanding here. A None-coalescing
operator is not for catching AttributeError, it's a shortcut similar
to "a or b" except that it checks for "a is None" rather than bool(a).

On Sat, Sep 10, 2016 at 4:38 PM, David Mertz <me...@gnosis.cx> wrote:
> Sorry, I sent this accidentally as private reply, then tried to fix it on
> phone.  The latter produced horrible formatting.  Please just read this
> version.
>
> On Sat, Sep 10, 2016 at 4:10 PM, Guido van Rossum <gu...@python.org> wrote:
>>
>> So you're offering `NoneCoalesce(x).bar` as less-ugly alternative to
>> `x?.bar`... Color me unconvinced.
>
>
> No, I'm offering a more realistic use pattern:
>
> for x in get_stuff():
>
> x = NoneCoalesce(x)
>
> # ... bunch of stuff with x ...
> # ... more stuff with nested keys or attributes ...
>
> x2 = x.foo
>
> x3 = x.bar.baz[x2]
>
> x4 = x(x.val)
>
> result = x3(x4)
>
>
>
> As a less ugly alternative in the fairly uncommon case that you want None
> coalescing as the behavior of getting attributes, keys, call values, etc.
> that may or may not be available (AND where you don't want to wrap all of
> those access patterns in one try/except block).
>
> In contrast, the ugly version of even this pretty simple toy code with the
> hypothetical syntax would be:
>
> for x in get_stuff():
>
> # ... bunch of stuff with x ...
>
> # ... more stuff with nested keys or attributes ...
>
> x2 = x?.foo
>
> x3 = x?.bar?.baz?[x2]
>
> x4 = x?(x?.val)
>
> result = x3?(x4)
>
>
> This second case looks absolutely awful to me.  And real world uses, if
> implemented, would quickly get much worse than that.
>
> Yours, David...
>
> --
> Keeping medicines from the bloodstreams of the sick; food
> from the bellies of the hungry; books from the hands of the
> uneducated; technology from the underdeveloped; and putting
> advocates of freedom in prisons.  Intellectual property is
> to the 21st century what the slave trade was to the 16th.
>
>
>
> --
> Keeping medicines from the bloodstreams of the sick; food
> from the bellies of the hungry; books from the hands of the
> uneducated; technology from the underdeveloped; and putting
> advocates of freedom in prisons.  Intellectual property is
> to the 21st century what the slave trade was to the 16th.
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/



-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Fwd: Null coalescing operator

[Guido van Rossum]

No. PEP 505 actually solves the problem without ever catching
AttributeError. Please read it.

On Sat, Sep 10, 2016 at 5:15 PM, David Mertz <me...@gnosis.cx> wrote:
> On Sep 10, 2016 4:45 PM, "Guido van Rossum" <gu...@python.org> wrote:
>>
>> There seems to be a major misunderstanding here. A None-coalescing
>> operator is not for catching AttributeError, it's a shortcut similar
>> to "a or b" except that it checks for "a is None" rather than bool(a).
>
> That's exactly what the wrapper does. Except it converts all the regular
> operators into their None-coalescing versions by putting the extra checks
> into the wrapped object itself.
>
> Now admittedly, this DOES mean that the behavior of operations is somewhat
> different depending on whether they are wrapped objects or not. False-like
> is a different thing than None-like.
>
> This really MUST BE essentially a way a catching AttributeErrors though.
> With the proposed syntax 'x?.foo?.bar' will resolve even if x has no 'foo'.
> So 'x?.'foo' has to be something special. I guess that special thing could
> be a 3.7-style None that responds to new operators, but that's essentially
> still *wrapping* a 3.6-style None.
>
> In my mind, as I say, the question marks look ugly, especially when repeated
> in chained operations (attribute, call, item get). But even if they didn't
> feel bad visually, I don't believe the use case is common enough to warrant
> dedicated syntax. Even if my keyboard had some character I thought was
> beautiful and intuitive for that meaning, it's still an extra cognitive
> burden to distinguish the plain from None-coalescing versions of every
> operation, especially for learners.
>
> Another problem is that the question mark still doesn't actually get the
> special 'a or b' behavior. For that you still need 'a if a is not None else
> b'. Or I guess, in concept, 'a ?or b'. For what it's worth, the wrapper
> gives you the special 'a or b' semantics by casting non-Nones as truthy...
> But again, 'a' has to have been wrapped first.
>
>>
>> On Sat, Sep 10, 2016 at 4:38 PM, David Mertz <me...@gnosis.cx> wrote:
>> > Sorry, I sent this accidentally as private reply, then tried to fix it
>> > on
>> > phone.  The latter produced horrible formatting.  Please just read this
>> > version.
>> >
>> > On Sat, Sep 10, 2016 at 4:10 PM, Guido van Rossum <gu...@python.org>
>> > wrote:
>> >>
>> >> So you're offering `NoneCoalesce(x).bar` as less-ugly alternative to
>> >> `x?.bar`... Color me unconvinced.
>> >
>> >
>> > No, I'm offering a more realistic use pattern:
>> >
>> > for x in get_stuff():
>> >
>> > x = NoneCoalesce(x)
>> >
>> > # ... bunch of stuff with x ...
>> > # ... more stuff with nested keys or attributes ...
>> >
>> > x2 = x.foo
>> >
>> > x3 = x.bar.baz[x2]
>> >
>> > x4 = x(x.val)
>> >
>> > result = x3(x4)
>> >
>> >
>> >
>> > As a less ugly alternative in the fairly uncommon case that you want
>> > None
>> > coalescing as the behavior of getting attributes, keys, call values,
>> > etc.
>> > that may or may not be available (AND where you don't want to wrap all
>> > of
>> > those access patterns in one try/except block).
>> >
>> > In contrast, the ugly version of even this pretty simple toy code with
>> > the
>> > hypothetical syntax would be:
>> >
>> > for x in get_stuff():
>> >
>> > # ... bunch of stuff with x ...
>> >
>> > # ... more stuff with nested keys or attributes ...
>> >
>> > x2 = x?.foo
>> >
>> > x3 = x?.bar?.baz?[x2]
>> >
>> > x4 = x?(x?.val)
>> >
>> > result = x3?(x4)
>> >
>> >
>> > This second case looks absolutely awful to me.  And real world uses, if
>> > implemented, would quickly get much worse than that.
>> >
>> > Yours, David...
>> >
>> > --
>> > Keeping medicines from the bloodstreams of the sick; food
>> > from the bellies of the hungry; books from the hands of the
>> > uneducated; technology from the underdeveloped; and putting
>> > advocates of freedom in prisons.  Intellectual property is
>> > to the 21st century what the slave trade was to the 16th.
>> >
>> >
>> >
>> > --
>> > Keeping medicines from the bloodstreams of the sick; food
>> > from the bellies of the hungry; books from the hands of the
>> > uneducated; technology from the underdeveloped; and putting
>> > advocates of freedom in prisons.  Intellectual property is
>> > to the 21st century what the slave trade was to the 16th.
>> >
>> > ___
>> > Python-ideas mailing list
>> > Python-ideas@python.org
>> > https://mail.python.org/mailman/listinfo/python-ideas
>> > Code of Conduct: http://python.org/psf/codeofconduct/
>>
>>
>>
>> --
>> --Guido van Rossum (python.org/~guido)



-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Null coalescing operator

[Guido van Rossum]

So you're offering `NoneCoalesce(x).bar` as less-ugly alternative to
`x?.bar`... Color me unconvinced.

On Sat, Sep 10, 2016 at 4:06 PM, David Mertz <me...@gnosis.cx> wrote:
> Actually, I guess the example I liked was from the year ago discussion.  And
> it didn't do *exactly* what I think a wrapper should.  What I'd want would
> be like this:
>
> class NoneCoalesce(object):
> "Standard operations on object for 'is not None'"
> def __init__(self, obj):
> self.obj = obj
>
> def __getattr__(self, name):
> try:
> return getattr(self.obj, name)
> except AttributeError:
> return NoneCoalesce(None)
>
> def __getitem__(self, item):
> try:
> return self.obj[item]
> except (TypeError, KeyError):
> return NoneCoalesce(None)
>
> def __call__(self, *args, **kwds):
> try:
> return self.obj(*args, **kwds)
> except TypeError:
> return NoneCoalesce(None)
>
> def __bool__(self):
> return self.obj is not None
>
> def __repr__(self):
> return "NoneCoalesce[%r]" % self.obj
>
> def __str__(self):
> return "NoneCoalesce[%r]" % self.obj
>
> def __len__(self):
> try:
> return len(self.obj)
> except TypeError:
> return 0
>
>
> Then we might use it similar to this:
>
>>>> from boltons.dictutils import OrderedMultiDict
>>>> from NoneCoalesce import NoneCoalesce
>>>> omd = OrderedMultiDict()
>>>> omd['a'] = 1
>>>> omd['b'] = 2
>>>> omd.add('a', 3)
>>>> nc = NoneCoalesce(omd)
>>>> nc or "Spanish Inquisition"
> Out[8]: NoneCoalesce[OrderedMultiDict([('a', 1), ('b', 2), ('a', 3)])]
>>>> nc.spam or "Spam"
> Out[9]: 'Spam'
>>>> nc['nope'].bar.baz()
> Out[10]: NoneCoalesce[None]
>>>> nc['a']
> Out[11]: 3
>>>> nc.getlist('a')
> Out[12]: [1, 3]
>
>
> Nothing special about boltons' OrderedMultiDict here, just something I've
> been playing with that has some distinctive methods.
>
> The idea is that we can easily have both "regular" behavior and None
> coalescing just by wrapping any objects in a utility class... and WITHOUT
> adding ugly syntax.  I might have missed some corners where we would want
> behavior wrapped, but those shouldn't be that hard to add in principle.
>
> On Sat, Sep 10, 2016 at 3:21 PM, David Mertz <me...@gnosis.cx> wrote:
>>
>> I find the '?.' syntax very ugly, much more so in the examples of chained
>> attributes.
>>
>> A much better way to handle the use case is to wrap objects in a class
>> that gives this "propagating None" behavior with plain attribute access. A
>> nice implementation was presented in this thread.
>>
>>
>> On Sep 10, 2016 3:16 PM, "Random832" <random...@fastmail.com> wrote:
>>>
>>> On Sat, Sep 10, 2016, at 13:26, Guido van Rossum wrote:
>>> > The way I recall it, we arrived at the perfect syntax (using ?) and
>>> > semantics. The issue was purely strong hesitation about whether
>>> > sprinkling ? all over your code is too ugly for Python
>>>
>>> I think that if there's "strong hesitation" about something being "too
>>> ugly" it can't really be described as "the perfect syntax". IIRC there
>>> were a couple alternatives being discussed that would have reduced the
>>> number of question marks to one [or one per object which might be None].
>>> ___
>>> Python-ideas mailing list
>>> Python-ideas@python.org
>>> https://mail.python.org/mailman/listinfo/python-ideas
>>> Code of Conduct: http://python.org/psf/codeofconduct/
>
>
>
>
> --
> Keeping medicines from the bloodstreams of the sick; food
> from the bellies of the hungry; books from the hands of the
> uneducated; technology from the underdeveloped; and putting
> advocates of freedom in prisons.  Intellectual property is
> to the 21st century what the slave trade was to the 16th.
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/



-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Fwd: Null coalescing operator

[Guido van Rossum]

To the contrary. I read and write code that performs explicit checks
for None all the time. Catching AttributeError is often a code smell
or at least a measure of last resort.

On Sat, Sep 10, 2016 at 6:46 PM, David Mertz <me...@gnosis.cx> wrote:
> Ok, I have been thinking of the behavior too broadly. I realize now that
> `x?.foo` might still simply raise an AttributeError if x is neither None nor
> a thing with a foo attribute.
>
> The class I wrote is definitely too aggressive for the behavior described.
> On the other hand, by being narrower in behavior there feels like even less
> motivation for new syntax.
>
>
> On Sep 10, 2016 6:29 PM, "MRAB" <pyt...@mrabarnett.plus.com> wrote:
>>
>> On 2016-09-11 02:02, David Mertz wrote:
>>>
>>> On Sat, Sep 10, 2016 at 5:23 PM, Guido van Rossum <gu...@python.org
>>> <mailto:gu...@python.org>> wrote:
>>>
>>> No. PEP 505 actually solves the problem without ever catching
>>> AttributeError. Please read it.
>>>
>>>
>>> I read it again (I did a year ago, but reviewed it now).  I hadn't been
>>> thinking that the *mechanism* of a new None-coalescing operator would
>>> actually be catching an exception.  It could (and should) work
>>> differently if it becomes syntax.
>>>
>>> What I was getting at with "essentially" was that it would *do the same
>>> thing* that an AttributeError does.  That is, if `x.foo` can't be
>>> evaluated (i.e. x doesn't have an attribute 'foo'), then access is
>>> informally "an error."  The hypothetical "x?.foo" catches that "error"
>>> and substitutes a different value.  The particular implementation
>>> under-the-hood is less important for most programmers who might use the
>>> construct (and I think documentation would actually give an informal
>>> equivalent as something similar to what I put in the NoneCoalesce class).
>>>
>> x?.foo would lookup attribute 'foo' _unless_ x was None, in which case it
>> would return None. It's simply:
>>
>> None if x is None else x.foo
>>
>> This means that None?.__str__() would return None, not 'None'. (None has
>> an attribute called '__str__', and None.__str__() returns 'None', but it
>> would not be looked up because None is, well, None.)
>>
>> ___
>> Python-ideas mailing list
>> Python-ideas@python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
>
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/



-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] An exciting opportunity to update PEP 3156

[Guido van Rossum]

On Sun, Sep 11, 2016 at 11:54 PM, Andrew Svetlov
<andrew.svet...@gmail.com> wrote:
> Should Task.current_task() be declared as a part of supported public API?

Sure.

> Should we declare that every asyncio coroutine is executed in a task
> context?

What importance does this have? Task.get_current_task() can return None.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Naming convention for Enums

[Guido van Rossum]

On Thu, Sep 15, 2016 at 10:54 AM, Chris Angelico <ros...@gmail.com> wrote:
> On Fri, Sep 16, 2016 at 3:03 AM, Steven D'Aprano <st...@pearwood.info> wrote:
>> On Wed, Sep 14, 2016 at 09:51:32PM +1000, Chris Angelico wrote:
>>
>>> Perhaps the advice needs to be along the lines of: Decide what the
>>> purpose of the enum is, and follow a naming convention accordingly.
>>> Uppercase if you're basically making constants; lowercase if you're
>>> not; etcetera.
>>
>> I can't think of any situation where Enums would *not* be treated as
>> constants. Can you give an example?
>
> Sometimes they function as integer constants (esp IntEnum), and
> sometimes more as just arbitrary values. See the examples in the docs
> [1] for Color and Mood, where the exact value is immaterial, just as
> long as Color.red is not Color.blue. Even though they happen to have
> integer values, they're not intended to be used as actual integers.
> For those cases, it's not as clear that they ought to be Color.RED and
> Color.BLUE - it's equally acceptable to have them in lowercase.

I disagree. The whole point of an enum is to define a new *kind* of
constant. Clearly RED and BLUE are new constants. (The uppercase
convention is not just for giving names to literals -- that's not what
"constant" means.)

> But if one convention or the other had to be picked for all enums, I
> would go with all-caps, since they're most often going to be
> representing constant integers, per Guido's post. I don't know of
> _any_ real-world cases where they're not integers, though there are
> some examples in the docs.

Amen.

> ChrisA
>
> [1] https://docs.python.org/3/library/enum.html

-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Flagging blocking functions not to be used with asyncio

[Guido van Rossum]

On Fri, Oct 7, 2016 at 9:52 AM, Yury Selivanov <yselivanov...@gmail.com> wrote:
> On 2016-10-07 11:16 AM, Guido van Rossum wrote:
>
>> Maybe a simpler approach would be to write a linter that checks for a
>> known list of common blocking functions, and anything that calls those
>> automatically gets the same property?
>
> What if somebody uses logging module and logs to a file?  I think this is
> something that linters can't infer (how logging is configured).

And depending on your use case this may be acceptable.

> One way to solve this would be to monkeypatch the io and os modules (gevent
> does that, so it's possible) to issue a warning when it's used in an asyncio
> context.  This can be done as a module on PyPI.
>
> Another way would be to add some kind of IO tracing hooks to CPython.

Honestly before writing a lot of code here I'd like to hear more from
Martin about the spread of mistakes he's observed among his users.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Flagging blocking functions not to be used with asyncio

[Guido van Rossum]

On Fri, Oct 7, 2016 at 1:07 AM, Martin Teichmann
<lkb.teichm...@gmail.com> wrote:
> I am currently developing a Python library based on asyncio.
> Unfortunately, not all users of my library have much experience with
> asynchronous programming, so they often try to use blocking functions.
>
> I thought it would be a good idea if we could somehow flag blocking
> functions in the standard library, such that they issue a warning (or
> even raise an exception) if they are used in an asyncio context. For
> functions implemented in Python, a simple decorator should do the job.
>
> For functions implemented in C, things get a bit more complex.
> Thinking about it, I realized that currently the best indicator for a
> C function to block is that it releases the GIL. There are some false
> positives, like a read with O_NONBLOCK set, in which case we need a
> way to opt out, but in general it could be a good idea that releasing
> the GIL triggers a warning in an asyncio environment.

That implementation idea seems iffy -- it feels like it would be a lot
of work to pull it off. Releasing the GIL is done at an extremely low
level and it's not clear how you'd even raise an exception at that
point.

Maybe a simpler approach would be to write a linter that checks for a
known list of common blocking functions, and anything that calls those
automatically gets the same property?

-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP8 dictionary indenting addition

[Guido van Rossum]

Makes sense, maybe you can send a PR to the Python/peps repo?

--Guido (mobile)

On Oct 8, 2016 12:27 PM, "Jelte Fennema"  wrote:

> I have an idea to improve indenting guidelines for dictionaries for better
> readability: If a value in a dictionary literal is placed on a new line, it
> should have (or at least be allowed to have) a n additional hanging indent.
>
> Below is an example:
>
> mydict = {'mykey':
>   'a very very very very very long value',
>   'secondkey': 'a short value',
>   'thirdkey': 'a very very very '
>   'long value that continues on the next line',
> }
>
>
> As opposed to this IMHO much less readable version:
>
> mydict = {'mykey':
>   'a very very very very very long value',
>   'secondkey': 'a short value',
>   'thirdkey': 'a very very very '
>   'long value that continues on the next line',
> }
>
> As you can see it is much harder in the second version to distinguish
> between keys and values.
>
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP8 dictionary indenting addition

[Guido van Rossum]

Might also send something to pystylechecker at the same time.

--Guido (mobile)

On Oct 8, 2016 1:23 PM, "Jelte Fennema" <m...@jeltef.nl> wrote:

> Alright, I'll make one when I have some time in the near future.
>
> On 8 Oct 2016 10:08 pm, "Guido van Rossum" <gvanros...@gmail.com> wrote:
>
>> Makes sense, maybe you can send a PR to the Python/peps repo?
>>
>> --Guido (mobile)
>>
>> On Oct 8, 2016 12:27 PM, "Jelte Fennema" <m...@jeltef.nl> wrote:
>>
>>> I have an idea to improve indenting guidelines for dictionaries for
>>> better readability: If a value in a dictionary literal is placed on a new
>>> line, it should have (or at least be allowed to have) a n additional
>>> hanging indent.
>>>
>>> Below is an example:
>>>
>>> mydict = {'mykey':
>>>   'a very very very very very long value',
>>>   'secondkey': 'a short value',
>>>   'thirdkey': 'a very very very '
>>>   'long value that continues on the next line',
>>> }
>>>
>>>
>>> As opposed to this IMHO much less readable version:
>>>
>>> mydict = {'mykey':
>>>   'a very very very very very long value',
>>>   'secondkey': 'a short value',
>>>   'thirdkey': 'a very very very '
>>>   'long value that continues on the next line',
>>> }
>>>
>>> As you can see it is much harder in the second version to distinguish
>>> between keys and values.
>>>
>>>
>>> ___
>>> Python-ideas mailing list
>>> Python-ideas@python.org
>>> https://mail.python.org/mailman/listinfo/python-ideas
>>> Code of Conduct: http://python.org/psf/codeofconduct/
>>>
>>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] async objects

[Guido van Rossum]

On Mon, Oct 3, 2016 at 10:37 PM, Rene Nejsum <r...@stranden.com> wrote:
> Ideally I think a language (would love it to be Python) should
> permit many (millions) of what we know as coroutines and then have as many
> threads as the CPU have cores to execute this coroutines, but I do not thing
> you as a programmer should be especially aware of this as you code. (Just
> like GC handles your alloc/free, the runtime should handle your
> “concurrency”)

There's a problem with this model (of using all CPUs to run
coroutines), since when you have two coroutines that can run in
unspecified order but update the same datastructure, the current
coroutine model *promises* that they will not run in parallel -- they
may only alternate running if they use `await`. This promise implies
that you can update the datastructure without worrying about locking
as long as you don't use `await` in the middle. (IOW it's
non-pre-emptive scheduling.)

If you were to change the model to allow multiple coroutines being
executed in parallel on multiple CPUs, such coroutines would have to
use locks locks, and then you have all the problems of threading back
in your coroutines! (There might be other things too, but there's no
wait to avoid a fundamental change in the concurrency model.)
Basically you're asking for Go's concurrency model -- it's nice in
some ways, but asyncio wasn't made to do that, and I'm not planning to
change it (let's wait for a GIL-free Python 4 first).

I'm still trying to figure out my position on the other points of
discussion here -- keep discussing!

-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Make partial a built-in

[Guido van Rossum]

On Tue, Sep 20, 2016 at 8:29 AM, אלעזר <elaz...@gmail.com> wrote:

> Guido, can you please elaborate?
>
> "What's going on" is usually that the same arguments are going to be
> passed over and over again, and the programmer wanted to avoid this
> repetition. The other option is adjusting the function to a predefined
> interface.
>

I did a little searching on a large Python code base I have access to, and
that's not what I found. The partial calls don't seem to produce code
that's in any way clearer than the equivalent use of lambda would. My
conclusion is that most people who are, um, partial to partial do so out of
a habit (or perhaps a belief that it's more performant), not to make their
code clearer. (FWIW I found an order of magnitude more uses of lambda than
of partial in the same code base.)

> The alternative to partial is writing a closure in the form of a function,
> that needs to be carefully inspected to verify that it is indeed just a
> partial application and not something more complex. It has more opportunity
> for introducing an error. And it's longer and adds distance between related
> parts of the code.
>

We seem to have fundamentally different ideas of what sort of code is most
readable. The alternative to partial is usually a lambda, and the signature
of the lambda helps me understand how it is being called. I don't see how
the lambda is longer or creates more distance. There are some exceptions,
when the function has a complex signature that should mostly be preserved
(and a few other, rare exceptions). But most of the uses of partial that I
found had exactly one call site and the call site was not calling a complex
signature.

A big problem I have reading code that uses partial is that *unless I
already know the function being partialed*, the partial() call itself gives
me no clue about the signature of that function. So then I have to look for
the call site of the partial (what do you call that?) and then in my head I
have to combine that with the partial parameters and figure out what is
really happening. A lambda would have given me a simple stepping stone. In
effect it's a little bit of "typing" right there, showing me the signature
that's being called, which is useful for reading the code quickly.

Also, I once timed it and could not show that partial was faster. This
surprised me but it wa what I measured (in one particular case).


> Elazar
>
> בתאריך יום ג׳, 20 בספט' 2016, 18:20, מאת Guido van Rossum ‏<
> gvanros...@gmail.com>:
>
>> I am radically opposed to this proposal. Every time I see a partial
>> application I wonder endlessly about what's going on.
>>
>> --Guido (mobile)
>> ___
>> Python-ideas mailing list
>> Python-ideas@python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
>
>


-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Make partial a built-in

[Guido van Rossum]

I am radically opposed to this proposal. Every time I see a partial
application I wonder endlessly about what's going on.

--Guido (mobile)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] SI scale factors alone, without units or dimensional analysis

[Guido van Rossum]

On Fri, Aug 26, 2016 at 5:47 AM, Steven D'Aprano <st...@pearwood.info>
wrote:

> Ken has made what I consider a very reasonable suggestion, to introduce
> SI prefixes to Python syntax for numbers. For example, typing 1K will be
> equivalent to 1000.
>
> However, there are some complexities that have been glossed over.
> [...]
>

Please curb your enthusiasm. This is not going to happen.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Atomic counter / atomic increment

[Guido van Rossum]

The only reason I can think of for wanting this simple class in the stdlib
would be that on GIL-free Python implementations you could replace it with
a lock-free version. But I think we'd probably want to rethink a bunch of
other datastructures to be lock-free, and a 3rd party package on PyPI makes
more sense to me than jumping right into the stdlib.

On Thu, Aug 25, 2016 at 11:10 AM, Ben Hoyt <benh...@gmail.com> wrote:

>
> As long as Python uses a GIL to protect C level function
>> calls, you can use an iterator for this:
>>
>> import itertools
>> x = itertools.count()
>> ...
>> mycount = next(x)
>>
>
> Yeah, that's a neat hack -- I saw it recommended on StackOverflow, and saw
> it used in the standard library somewhere. I think that's probably okay in
> the *CPython* stdlib, because it's CPython so you know it has the GIL. But
> this wouldn't work in other Python implementations, would it (IronPython
> and Jython don't have a GIL). Or when itertools.count() is implemented in
> pure Python on some system? Seems like it could blow up in someone's face
> when they're least expecting it. I also think using *iter*tools is a pretty
> non-obvious way to get a thread-safe counter.
>
> -Ben
>
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>



-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Null coalescing operator

[Guido van Rossum]

I'm not usually swayed by surveys -- Python is not a democracy. Maybe
a bunch of longer examples would help all of us see the advantages of
the proposals.

On Fri, Oct 14, 2016 at 8:09 PM, Mark E. Haase <meha...@gmail.com> wrote:
> On Fri, Oct 14, 2016 at 12:10 PM, Guido van Rossum <gu...@python.org> wrote:
>>
>> I propose that the next phase of the process should be to pick the
>> best operator for each sub-proposal. Then we can decide which of the
>> sub-proposals we actually want in the language, based on a combination
>> of how important the functionality is and how acceptable we find the
>> spelling.
>>
>> --Guido
>>
>
> I just submitted an updated PEP that removes the emoijs and some other
> cruft.
>
> How I can help with this next phase? Is a survey a good idea or a bad idea?



-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 505 -- None-aware operators

[Guido van Rossum]

On Fri, Oct 14, 2016 at 6:37 AM, Gustavo Carneiro <gjcarne...@gmail.com> wrote:
> I see.  short-circuiting is nice to have, sure.

No. Short-circuiting is the entire point of the proposed operators.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Decorator to avoid a mistake

[Guido van Rossum]

This idea is being kicked around from forum to forum and nobody wants to
have it.

Here it's brought up from time to time and the response is usually "let a
linter do it".

In mypy (which is essentially a powerful linter) it was proposed (
https://github.com/python/mypy/issues/1888) and the response was
essentially "better go to python-ideas or bugs.python.org".

It's also been proposed as a PEP 484 feature:
https://github.com/python/typing/issues/269#issuecomment-243765549 .

I think one reason why such proposals are unwelcome to experienced users
may be that when done right this is totally legitimate, and the requirement
to use an @override decorator is just making code more verbose with very
little benefit. (I could see a benefit -- if this is used consistently it
could make spelunking a large codebase easier, because you would know which
methods are overrides. Something like mypy could then enforce its use. But
an IDE could also just highlight method overrides differently, maybe
PyCharm or PyDev already do that?)

-- 
--Guido van Rossum (python.org/~guido <http://python.org/%7Eguido>)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Decorator to avoid a mistake

[Guido van Rossum]

On Mon, Nov 28, 2016 at 1:32 PM, Chris Barker <chris.bar...@noaa.gov> wrote:

> On Mon, Nov 28, 2016 at 10:22 AM, Guido van Rossum <gu...@python.org>
> wrote:
>
>
>> At calling time, the subclass' method will be found, and used, and the
>>> search stops there -- no way to know if there is one with the same name
>>> further up the MRO.
>>>
>>> This is simply incompatable with a language this dynamic.
>>>
>>
>> Not so fast! Python is also so dynamic that you can easily create a
>> metaclass (or a class decorator) that does the checking (assuming
>> reasonable behavior of all classes involved) at class definition time.
>>
>
> but that's class definition time -- can't classes be dynamically mangled
> later on -- after subclasses have been defined?
>

They can, and they @override can be bypassed. I don't see that as a
condemnation of @overload -- it just means that it's not perfect, which is
fine with me (given that we're talking about monkey-patching here).


> If I have this right the mro is set at class definition time, so it is
> knows which classes are in the tree -- but class objects themselves are
> mutable -- methods can be added later on. so a subclass could  have a
> method that isn't overriding anything when it's defined, but ends up
> overriding something later on, 'cause the base class changed under it.
>
> Isn't this why the mro is searched at method calling time? rather than a
> static table being used? (if not -- wouldnt that be a nice optimization?)
>
> Granted -- this kind of late class mangling has got to be pretty unusual
> (and maybe only useful for mocking, or??) but it is there.
>
> Which is why it could be useful to have some syntax or convention for
> specifying "I'm intending to override a method", that linters or type
> checkers, or whatever external tool, can use. But it can't be enforced at
> runtime in the language.
>

Depends on how much enforcement you need. Bike locks also don't typically
enforce that your bike doesn't get stolen...

-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Decorator to avoid a mistake

[Guido van Rossum]

On Mon, Nov 28, 2016 at 1:44 PM, Chris Barker <chris.bar...@noaa.gov> wrote:

>
> On Mon, Nov 28, 2016 at 1:37 PM, Guido van Rossum <gu...@python.org>
> wrote:
>
>
>> They can, and they @override can be bypassed. I don't see that as a
>> condemnation of @overload -- it just means that it's not perfect, which is
>> fine with me (given that we're talking about monkey-patching here).
>>
>
> sure -- but this all strikes me as kind of like type checking -- there is
> a lot of use for robust code, but we don't want it at run-time in the
> language.
>
> Also -- the ship has kinda sailed on this - maybe a @not_override would
> make more sense.
>
> Isn't the goal to make sure you don't accidentally override a method?
> saying "I know I'm overriding this" is less useful than "I'm not intending
> to override anything here"
>

I think you're fighting a straw man. I never said @override should be added
to the language. I said that it would be useful to have a 3rd party
metaclass or a class decorator that implements it which packages may
voluntarily use to constrain their subclasses (or their own uses --
different designs are possible).

-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Null coalescing operator

[Guido van Rossum]

Obviously the AST needs to be changed. How? I dunno. Sounds like you have
some ideas. :-)

On Mon, Oct 31, 2016 at 2:44 PM, Random832 <random...@fastmail.com> wrote:

> On Mon, Oct 31, 2016, at 13:16, Guido van Rossum wrote:
> > For "everything to the right" it would seem we have some freedom: e.g.
> > if we have "foo.bar?.baz(bletch)" is the call included? The answer is
> > yes -- the concept we're after here is named "trailer" in the Grammar
> > file in the source code (
> > https://github.com/python/cpython/blob/master/Grammar/Grammar#L119),
> > and "primary" in the reference manual (
> > https://docs.python.org/3/reference/expressions.html#primaries). This
> > means all attribute references ("x.y"), index/slice operations
> > ("x[...]"), and calls ("x(...)").
>
> One thing that I think I touched on in an earlier iteration of this
> discussion but hasn't been revisited is: what's the AST going to look
> like?
>
> Right now, foo.bar.baz(bletch) is Call(Attribute(Attribute(Name('foo'),
> 'bar'), 'baz'), [Name('bletch')])), which is identical to
> (foo.bar).baz(bletch) or (foo.bar.baz)(bletch). These are treated,
> essentially, as postfix operators, where you can parenthesize any left
> part of the expression and leave its meaning [and its AST] unchanged.
>
> Is the AST going to be unchanged, leading to the conclusion that the
> short-circuiting in (foo?.bar).baz will "reach outside of" the
> parentheses, and relying on the fact that wanting to do that with None
> is a silly thing to do in almost all cases? Or is there going to be a
> new kind of AST that is sequential rather than recursive in how it
> represents trailer/primary expressions?
> ___________
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>



-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Null coalescing operator

[Guido van Rossum]

I personally find the ?keyword pattern has less appeal than ?, ?? or ?. .

On Tue, Nov 1, 2016 at 4:02 AM, Nick Coghlan <ncogh...@gmail.com> wrote:

> On 1 November 2016 at 20:28, Paul Moore <p.f.mo...@gmail.com> wrote:
> > On 1 November 2016 at 10:11, Nick Coghlan <ncogh...@gmail.com> wrote:
> >>
> >> I do think it would be worth covering the symbol+keyword option
> >> discussed in PEP 531 (i.e. "?else" instead of "??", but keeping "?.",
> >> and "?[")
> >
> > FWIW, I'm not keen on it.
> >
> > As a technical question, would it be treated in the syntax as a
> > keyword, which happened to be made up of a punctuation character
> > followed by letters, or as a ? symbol followed by a keyword?
>
> Combined keyword, rather than two distinct tokens.
>
> If you don't do that, you end up creating ambiguities for other
> possible uses of "?" (like the "." and "?[]" suggestions)
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
> ___________
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>



-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Null coalescing operator

[Guido van Rossum]

I think we should try to improve our intutition about these operators. Many
things that are intuitively clear still require long turgid paragraphs in
reference documentation to state the behavior unambiguously -- but that
doesn't stop us from intuitively grasping concepts like a+b (when does
b.__radd__ get called?) or @classmethod.

The main case to build intuition for is "?." -- once you get that the
"?[...]" operator works just the same. So here's my attempt:

*In a series of attribute accesses like "foo.bar.baz.bletch", putting a `?`
before a specific dot inserts a None check for the expression to the left
and skips everything to the right when the None check is true.*

We still need to clarify what we mean by "expression to the left" and
"everything to the right", but in most situations you will guess right
without thinking about it.

The expression to the left is easy -- it's determined by syntactic operator
precedence, so that if we have "x = y + foo.bar?.baz.bletch", the
expression to the left of the "?." is just "foo.bar". (But see below -- you
won't actually see such usage much.)

For "everything to the right" it would seem we have some freedom: e.g. if
we have "foo.bar?.baz(bletch)" is the call included? The answer is yes --
the concept we're after here is named "trailer" in the Grammar file in the
source code (
https://github.com/python/cpython/blob/master/Grammar/Grammar#L119), and
"primary" in the reference manual (
https://docs.python.org/3/reference/expressions.html#primaries). This means
all attribute references ("x.y"), index/slice operations ("x[...]"), and
calls ("x(...)").

Note that in almost all cases the "?." operator will be used in an context
where there is no other operator of lower precedence before or after it --
given the above meaning, it doesn't make a lot of sense to write "1 + x?.a"
because "1 + None" is always an error (and ditto for "x?.a + 1"). However
it still makes sense to assign such an expression to a variable or pass it
as an argument to a function.

So you can ignore the preceding four paragraphs: just remember the
simplified rule (indented and in bold, depending on your email client) and
let your intuition do the rest. Maybe it can even be simplified more:


*The "?." operator splits the expression in two parts; the second part is
skipped if the first part is None.*

Eventually this *will* become intuitive. The various constraints are all
naturally imposed by the grammar so you won't have to think about them
consciously.

--Guido

On Mon, Oct 31, 2016 at 9:33 AM, Paul Moore <p.f.mo...@gmail.com> wrote:

> On 31 October 2016 at 15:51, Mark E. Haase <meha...@gmail.com> wrote:
> > Therefore, I have updated the PEP with the punctuation mentioned above,
> and
> > at this point the PEP can't go any farther. If the best spelling for this
> > new operator is unacceptable, then there's no getting around that. This
> PEP
> > should be rejected.
>
> While I agree that there's little point arguing over spelling here -
> if the ? spelling is unacceptable we should just reject - I'm not sure
> that's the only sticking point remaining here. I still find the
> short-circuiting behaviour of ?. (and ?[) to be pretty confusing - and
> the fact that there's a long paragraph describing the behaviour, with
> lots of examples of the form "if you think that this example works
> like so, then you're wrong, and it actually does the following",
> suggests to me that I'm not going to be the only one struggling.
> Hopefully, the problem is simply the way the behaviour is presented,
> and a reworking of the description would make it all crystal clear -
> but it feels to me that there's some inherent complexity here that's
> an actual issue with the proposal.
>
> Having said that, it appears that the proposed behaviour is the same
> as in C# (can you just come out and say "C#", rather than hinting with
> the phrase "other popular languages" - if we're stealing the behaviour
> as is from C#, let's say so, and if not, can you include examples from
> more than one language?) Assuming that's the case, then the fact that
> it's not causing confusion to C# programmers is a definite point in
> its favour.
>
> Paul
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>



-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Null coalescing operator

[Guido van Rossum]

Geez.

--Guido (mobile)

On Nov 1, 2016 8:10 PM, "Chris Angelico"  wrote:

> On Wed, Nov 2, 2016 at 11:09 AM, Steven D'Aprano 
> wrote:
> > I don't know when I would ever want to actually do this in practice, but
> > allowing the ?. operator to magically effect code outside of the
> > parentheses definitely counts as "spooky action at a distance". Guido's
> > rule of "everything to the right" is easy to reason about if "to the
> > right" ends where the parenthised expression ends.
> >
>
> We already expect "to the left" and "to the right" to end based on
> operator precedence rules. Parentheses are used to control operator
> precedence. It would surprise people *greatly* if they didn't bound
> the effect of the question mark.
>
> ChrisA
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Adding full() to collections.deque

[Guido van Rossum]

Isn't the problem that you don't know if it's still full on the next
line? After all you supposedly have a multi-threaded app here,
otherwise why bother with any of that? Or maybe you can describe the
real-world use case where you wanted this in more detail? Without much
more evidence I can't support such a change.

On Tue, Oct 11, 2016 at 5:09 AM, Tarek Ziadé <ta...@ziade.org> wrote:
>
> Hey,
>
> When creating deque instances using a value for maxlen, it would be nice
> to have a .full() method like what Queue provides, so one may do:
>
> my_deque = deque(maxlen=300)
>
> if my_deque.full():
>do_something()
>
> instead of doing:
>
> if len(my_deque) == my_deque.maxlen:
>   do_something()
>
>
> If people think it's a good idea, I can add a ticket in the tracker and
> try to provide a patch for the collections module maintainer.
> If this was already talked about, or is a bad idea, sorry! :)
>
> Cheers
> Tarek
> --
>
> Tarek Ziadé | coding: https://ziade.org | running: https://foule.es |
> twitter: @tarek_ziade
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/



-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] [Python-Dev] Optimizing list.sort() by checking type in advance

[Guido van Rossum]

On Mon, Oct 10, 2016 at 7:56 PM, Elliot Gorokhovsky
<elliot.gorokhov...@gmail.com> wrote:
> So here's a simple attempt at taking lots of measurements just using
> time.time() with lists of ints. The results are great, if they are valid
> (which I leave to you to judge); even for lists with just one element, it's
> 16% faster!

But that's suspicious in itself -- since no comparisons are needed to
sort a 1-element list, if it's still faster, there must be something
else you're doing (or not doing) that's affecting the time measured.

I wonder if it's the method lookup that's is slower than the entire
call duration? That explains why s[:1] == 'x' is faster than
s.startswith('x'), for example.

A simple nit on your test code: calling time() twice per iteration
could also affect things. I would just call time() once before and
once after the innermost for-loops. (IIRC timeit tries to compensate
for the cost of the loop itself by measuring an empty loop, but that's
got its own set of problems.)

Anyway, you should ignore me and listen to Tim, so I'll shut up now.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Null coalescing operator

[Guido van Rossum]

I actually think the spelling is the main stumbling block. The
intrinsic value of the behavior is clear, it's finding an acceptable
spelling that hold back the proposal.

I propose that the next phase of the process should be to pick the
best operator for each sub-proposal. Then we can decide which of the
sub-proposals we actually want in the language, based on a combination
of how important the functionality is and how acceptable we find the
spelling.

--Guido

On Thu, Oct 13, 2016 at 8:20 PM, Mark E. Haase <meha...@gmail.com> wrote:
> (Replying to multiple posts in this thread)
>
> Guido van Rossum:
>>
>> Another problem is PEP 505 -- it
>> is full of discussion but its specification is unreadable due to the
>> author's idea to defer the actual choice of operators and use a
>> strange sequence of unicode characters instead.
>
>
> Hi, I wrote PEP-505. I'm sorry that it's unreadable. The choice of emoji as
> operators was supposed to be a blatant joke. I'd be happy to submit a new
> version that is ASCII. Or make any other changes that would facilitate
> making a decision on the PEP.
>
> As I recall, the thread concluded with Guido writing, "I'll have to think
> about this," or something to that effect. I had hoped that the next step
> could be a survey where we could gauge opinions on the various possible
> spellings. I believe this was how PEP-308 was handled, and that was a very
> similar proposal to this one.
>
> Most of the discussion on list was really centered around the fact that
> nobody like the proposed ?? or .? spellings, and nobody could see around
> that fact to consider whether the feature itself was intrinsically valuable.
> (This is why the PEP doesn't commit to a syntax.) Also, as unfortunate side
> effect of a miscommunication, about 95% of the posts on this PEP were
> written _before_ I submitted a complete draft and so most of the
> conversation was arguing about a straw man.
>
> David Mertz:
>>
>> The idea is that we can easily have both "regular" behavior and None
>> coalescing just by wrapping any objects in a utility class... and WITHOUT
>> adding ugly syntax.  I might have missed some corners where we would want
>> behavior wrapped, but those shouldn't be that hard to add in principle.
>
>
> The biggest problem with a wrapper in practice is that it has to be
> unwrapped before it can be passed to any other code that doesn't know how to
> handle it. E.g. if you want to JSON encode an object, you need to unwrap all
> of the NullCoalesce objects because the json module wouldn't know what to do
> with them. The process of wrapping and unwrapping makes the resulting code
> more verbose than any existing syntax.
>>
>> How much of the time is a branch of the None check a single fallback value
>> or attribute access versus how often a suite of statements within the
>> not-None branch?
>>
>> I definitely check for None very often also. I'm curious what the
>> breakdown is in code I work with.
>
> There's a script in the PEP-505 repo that can you help you identify code
> that could be written with the proposed syntax. (It doesn't identify blocks
> that would not be affected, so this doesn't completely answer your
> question.)
>
> https://github.com/mehaase/pep-0505/blob/master/find-pep505.py
>
> The PEP also includes the results of running this script over the standard
> library.
>
> On Sat, Sep 10, 2016 at 1:26 PM, Guido van Rossum <gu...@python.org> wrote:
>>
>> The way I recall it, we arrived at the perfect syntax (using ?) and
>> semantics. The issue was purely strong hesitation about whether
>> sprinkling ? all over your code is too ugly for Python, and in the end
>> we couldn't get agreement on *that*. Another problem is PEP 505 -- it
>> is full of discussion but its specification is unreadable due to the
>> author's idea to defer the actual choice of operators and use a
>> strange sequence of unicode characters instead.
>>
>> If someone wants to write a new, *short* PEP that defers to PEP 505
>> for motivation etc. and just writes up the spec for the syntax and
>> semantics we'll have a better starting point. IMO the key syntax is
>> simply one for accessing attributes returning None instead of raising
>> AttributeError, so that e.g. `foo?.bar?.baz` is roughly equivalent to
>> `foo.bar.baz if (foo is not None and foo.bar is not None) else None`,
>> except evaluating foo and foo.bar only once.
>>
>> On Sat, Sep 10, 2016 at 10:14 AM, Random832 <random...@fastmail.com>
>> wrote:
>> > On Sat, Sep 10, 2016, at 12:48, Stephen J. Turnbull wrote:
>> >> I forget if Guido was very sympa

Re: [Python-ideas] How to respond to trolling

[Guido van Rossum]

Whether the intent was to annoy or just to provoke, the effect was dozens
of messages with people falling over each other trying to engage the OP,
who clearly was ignorant of most language design issues and uninterested in
learning, and threw some insults in for good measure. The respondents
should have known better.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] How to respond to trolling (Guido van Rossum)

[Guido van Rossum]

AFAIK the term comes from a piece by Andrew Kuchling titled "Python warts".
The topic now has its own wiki page:
https://wiki.python.org/moin/PythonWarts

I believe that most of the warts are not even design missteps -- they are
emergent misfeatures, meaning nobody could have predicted how things would
work out.

On Thu, Jan 12, 2017 at 5:09 PM, Brett Cannon <br...@python.org> wrote:

>
>
> On Thu, 12 Jan 2017 at 15:22 Random832 <random...@fastmail.com> wrote:
>
>> On Thu, Jan 12, 2017, at 17:39, Brett Cannon wrote:
>> > On Wed, 11 Jan 2017 at 20:56 Simon Lovell <simon58...@bigpond.com>
>> wrote:
>> > > I don't know what is meant by some insults having been thrown in.
>> > > Calling truthiness of non boolean data "Ugly" is an insult? It is
>> ugly.
>> >
>> > Now *that *is insulting to me. Once again, you are allowed to disagree
>> > and
>> > say you don't like how truthiness is handled in Python, but you flat-out
>> > stating something is ugly insults all the time and effort that me and
>> the
>> > other core developers have put into Python to try and make it the best
>> > language we can with the constraints we have to work within.
>>
>> Just out of curiosity... in your estimation, what is a "wart", and why
>> is the term "wart" used for it?
>
>
> That term has been used since before I got involved in Python so I don't
> know its history. To me, a "wart" is a design misstep; there were reasons
> at the time for the design but it has not held up as necessarily the best
> decision. So to me "wart" is not as bad as "ugly" as it tacitly
> acknowledges circumstances were quite possibly different back then and
> 20/20 hindsight is not something we have when making a decision. As a
> community we have collectively agreed some things are warts in Python
> because enough people over time have shared the opinion that something was
> a design misstep.
>
>
>> I mean, this is an accepted term that
>> the Python community uses to refer to things, that is not generally
>> regarded to be cause for an accusation of personally insulting anyone,
>> right? I haven't stepped into an alternate universe?
>
>
> You're focusing on the word and not how the word was presented. The fact
> that Simon started his email with a blanket statement basically saying his
> ideas were great and right automatically shows arrogance. And then
> continuing to say that something is ugly matter-of-factly just continued on
> that theme. I can normally mentally insert an "I think" phrase for people
> when they make a blanket statement like that when the rest of the email was
> reasonable, but the posturing of the email as a whole just didn't all for
> that.
>
> We can argue what adjective or noun could have been used forever, but the
> fact that it was delivered as if in judgment over those who put the time
> and effort to make the decision all those years ago doesn't ever feel good
> to the people being judged and ridiculed (and I know this can seem small,
> but as one of the people being judged regularly I can attest that the
> constant ridicule contributes to burnout).
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>



-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Things that won't change (proposed PEP)

[Guido van Rossum]

I've not followed this discussion closely, but I would assume that for most
things on the "will never change" list the explanation is simply that the
cost of changing it while maintaining backward compatibility is too high
compared to the benefit of fixing the problem (regardless of whether it
really is a problem).

People who come in with enthusiastic proposals to fix some pet peeve
usually don't have the experience needed to appreciate the difficulty in
maintaining backwards compatibility. (A really weird disconnect from
reality happens when this is mentioned in the same breath as "please fix
the Python 2 vs. 3 problem". :-)

I would also guess that for things that are actually controversial (meaning
some people hate a feature that other people love), it's much easier to
explain why it's too late to change than it is to provide an objective
argument for why the status quo is better. Often the status quo is not
better per se, it's just better because it's the status quo.

from __future__ import no_colons  # :-)

On Thu, Jan 12, 2017 at 4:57 PM, Erik <pyt...@lucidity.plus.com> wrote:

> On 12/01/17 19:51, Todd wrote:
>
>>
>> On Thu, Jan 12, 2017 at 2:33 PM, Sven R. Kunze <srku...@mail.de
>> <mailto:srku...@mail.de>> wrote:
>> First of all, I am anti-censor and pro-change.
>>
>
> There is no "censorship" or "banning thoughts" going on here.  Even with
>> this PEP, people are free to think about and talk about how Python could
>> work differently all they want.  What this PEP does is tell them that
>> certain decisions have been made about how the Python language is going
>> to work, so they should be aware that such talk isn't going to actually
>> result in any changes to the language.
>>
>
> By saying that "these are things that will not change", then you _are_
> sort of banning talk about them (if, as you assert, "such talk isn't going
> to actually result in any changes to the language" then you are saying
> don't waste your breath, we won't even consider your arguments).
>
> I think I get Sven's point. A long time ago, someone probably said "Python
> will never have any sort of type declarations.". But now there is type
> hinting. It's not the same thing, I know, but such a declaration in a PEP
> might have prevented people from even spending time considering hinting.
>
> Instead, if the PEP collected - for each 'frequently' suggested change - a
> summary of the reasons WHY each aspect is designed the way it is (with
> links to archived discussions or whatever) then that IMO that would be a
> good resource to cite in a canned response to such suggestions.
>
> It's not that "these things will never change", it's more of a "you need
> to provide a solid argument why your suggestion is different to, and better
> than, the cited suggestions that have already been rejected".
>
> Probably a lot of work to gather all the references though. But it could
> start out with one or two and grow from there. Add to it as and when people
> bring up the same old stuff next time.
>
> E.
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>



-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Add optional defaults to namedtuple

[Guido van Rossum]

On Wed, Nov 30, 2016 at 7:09 AM, Ethan Furman <et...@stoneleaf.us> wrote:

> On 11/30/2016 02:32 AM, Jelte Fennema wrote:
>
> It would be nice to have a supported way to add defaults to namedtuple,
>>  so the slightly hacky solution here does not have to be used:
>>  http://stackoverflow.com/a/18348004/2570866
>>
>
> Actually, the solution right below it is better [1]:
>
> --> from collections import namedtuple
> --> class Node(namedtuple('Node', ['value', 'left', 'right'])):
> --> __slots__ = ()
> --> def __new__(cls, value, left=None, right=None):
> --> return super(Node, cls).__new__(cls, value, left, right)
>
> But even more readable than that is using the NamedTuple class from my
> aenum [3] library (and on SO as [3]):
>
> --> from aenum import NamedTuple
> --> class Node(NamedTuple):
> --> val = 0
> --> left = 1, 'previous Node', None
> --> right = 2, 'next Node', None
>
> shamelessly-plugging-my-own-solutions'ly yrs,
>

Ditto: with PEP 526 and the latest typing.py (in 3.6) you will be able to
do this:

class Employee(NamedTuple):
name: str
id: int

We should make it so that the initial value in the class is used as the
default value, too. (Sorry, this syntax still has no room for a docstring
per attribute.)

-- 
--Guido van Rossum (python.org/~guido <http://python.org/%7Eguido>)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Adding an 'errors' argument to print

[Guido van Rossum]

On Fri, Mar 24, 2017 at 9:37 AM, Victor Stinner <victor.stin...@gmail.com>
wrote:

> *If* we change something, I would prefer to modify sys.stdout. The
> following issue proposes to add
> sys.stdout.set_encoding(errors='replace'):
> http://bugs.python.org/issue15216
>

I like that.


> You can already set the PYTHONIOENCODING environment variable to
> ":replace" to use "replace" on sys.stdout (and sys.stderr).
>

Great tip, I've needed this!

-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Discourage operator.__dunder__ functions

[Guido van Rossum]

+1

On Apr 13, 2017 11:26 AM, "Steven D'Aprano"  wrote:

> Notice that I said *discourage* rather than *deprecate*.
>
> Quoting the documentation:
>
> The operator module exports a set of efficient functions
> corresponding to the intrinsic operators of Python. For
> example, operator.add(x, y) is equivalent to the expression
> x+y. The function names are those used for special class
> methods; variants without leading and trailing __ are also
> provided for convenience.
>
> https://docs.python.org/3/library/operator.html
>
> I propose four simple documentation changes, and no code change:
>
>
> (1) The quoted paragraph is factually wrong to say:
>
> "The function names are those used for special class methods"
>
> We can fix that by changing it to:
>
> "Some function names are those used for special class methods".
>
>
> (2) Replace the word "convenience" in the quoted paragraph by
> "backward compatibility";
>
>
> (3) Add a note close to the top of the page that the non-dunder
> names are preferred for new code.
>
>
> (4) And a note stating that existing dunder functions will
> remain, but no new ones will be added.
>
>
> The existing dunder names will remain aliases to the non-dunder names;
> they will not be deprecated (maybe in Python 5000 *wink*). Those who
> really want to use them can continue to do so.
>
> Regarding point (1) above:
>
> - Not all operator functions have a dunder alias.
>
> - The dunder functions don't always correspond to a dunder method. For
> example, there is operator.__concat__ for sequence concatenation, but no
> str.__concat__ or list.__concat__ methods.
>
> - Even when the dunder function corresponds by name to the dunder
> method, they don't mean the same thing. For example, operator.__add__ is
> *not* the same as just calling the first argument's __add__ method.
>
> - And finally, I fail to see how having to type an extra four characters
> is a "convenience".
>
>
> Long ago, when the operator module was first introduced, there was a
> much stronger correspondence between the operator.__dunder__ functions
> and dunder methods. But I think that correspondence is now so weak that
> we should simply treat it as a historical artifact.
>
>
>
> --
> Steve
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Thread-safe generators

[Guido van Rossum]

My 2 cent's worth, don't even think about it.

On Apr 15, 2017 3:27 AM, "Serhiy Storchaka"  wrote:

> On 15.04.17 11:55, Stephen J. Turnbull wrote:
>
>> Serhiy Storchaka writes:
>>
>>  > The first thread just sets the running flag (as in current code). Due
>> to
>>  > GIL this doesn't need additional synchronization.
>>
>> Can we assume this lack of additional synchronization for other
>> implementations?  If not, do we care?
>>
>
> Other implementations should have atomic test-and-set operations for the
> running flag. Or other ways to prevent a race condition. So yes, we can
> assume this.
>
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Thread-safe generators

[Guido van Rossum]

I think the two shouldn't be mixed.

On Apr 16, 2017 7:58 AM, "Victor Stinner"  wrote:

> Thread safety is very complex and has an impact on performance. I dislike
> the idea of providing such property to generators which can have a complex
> next method.
>
> IMHO it's better to put a generator in wrapper which adds thread safety.
>
> What do you think?
>
> Victor
>
> Le 14 avr. 2017 18:48, "Serhiy Storchaka"  a écrit :
>
>> When use a generator from different threads you can get a ValueError
>> "generator already executing". Getting this exception with the single
>> thread is a programming error, it in case of different threads it could be
>> possible to wait until other thread finish executing the generator. The
>> generator can be made thread-safe after wrapping it in a class that acquire
>> a lock before calling the generator's __next__ method (for example see
>> [1]). But this is not very efficient of course.
>>
>> I wondering if it is worth to add support of thread-safe generators in
>> the stdlib. Either by providing standard decorator (written in C for
>> efficiency), or adding threading support just in the generator object. The
>> latter may need increasing the size of the generator object for a lock and
>> thread identifier (but may be GIL is enough), but should not affect
>> performance since locking is used only when you faced with a generator
>> running in other thread.
>>
>> This topic already was raised on Python-Dev [2] but didn't moved too
>> much. There are a number of StackOverflow questions about threads and
>> generators. We have already encountered this issue in the stdlib. Once in
>> regrtest with the -j option ([3], [4]), other time after reimplementing
>> tempfile._RandomNameSequence as a generator [5].
>>
>> [1] http://anandology.com/blog/using-iterators-and-generators/
>> [2] https://mail.python.org/pipermail/python-dev/2004-February/0
>> 42390.html
>> [3] https://bugs.python.org/issue7996
>> [4] https://bugs.python.org/issue15320
>> [5] https://bugs.python.org/issue30030
>>
>> ___
>> Python-ideas mailing list
>> Python-ideas@python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Positional-only parameters

[Guido van Rossum]

On Wed, Mar 1, 2017 at 11:25 AM, Serhiy Storchaka <storch...@gmail.com>
wrote:

> On 28.02.17 23:17, Victor Stinner wrote:
>
>> My question is: would it make sense to implement this feature in
>> Python directly? If yes, what should be the syntax? Use "/" marker?
>> Use the @positional() decorator?
>>
>
> I'm strongly +1 for supporting positional-only parameters. The main
> benefit to me is that this allows to declare functions that takes arbitrary
> keyword arguments like Formatter.format() or MutableMapping.update(). Now
> we can't use even the "self" parameter and need to use a trick with parsing
> *args manually. This harms clearness and performance.
>

Agreed.


> The problem with the "/" marker is that it looks ugly. There was an excuse
> for the "*" marker -- it came from omitting the name in "*args". The "*"
> prefix itself means an iterable unpacking, but "/" is not used neither as
> prefix nor suffix.
>

It's in a sense a pun -- * and / are "opposites" in mathematics, and so are
the usages here.


> Do you see concrete cases where it's a deliberate choice to deny
>> passing arguments as keywords?
>>
>
> dict.__init__(), dict.update(), partial.__new__() and partial.__call__()
> are obvious examples. There are others.
>
> And there was performance reason. Just making the function supporting
> keyword arguments added an overhead even to calls with only positional
> arguments. This was changed recently, but I didn't checked whether some
> overhead is left.
>
> Don't you like writing int(x="123") instead of int("123")? :-) (I know
>> that Serhiy Storshake hates the name of the "x" parameter of the int
>> constructor ;-))
>>
>
> I believe weird names like "x" was added when the support of "base"
> keyword was added due to the limitation of PyArg_ParseTupleAndKeywords().
> All or nothing, either builtin function didn't support keyword arguments,
> or it supported passing by keyword for all arguments.
>
> But now it is possible to support passing by keyword only the part of
> parameters. I want to propose to deprecate badly designed keyword names of
> builtins.
>

+1


> By the way, I read that "/" marker is unknown by almost all Python
>> developers, and [...] syntax should be preferred, but
>> inspect.signature() doesn't support this syntax. Maybe we should fix
>> signature() and use [...] format instead?
>>
>
> [...] is not Python syntax too. And it is orthogonal to positional-only
> parameters. [...] doesn't mean that parameters are positional-only. They
> can be passed by keyword, but just don't have default value. On other side,
> mandatory parameters can be positional-only.


FWIW in typeshed we've started using double leading underscore as a
convention for positional-only parameters, e.g. here:

https://github.com/python/typeshed/blob/master/stdlib/3/builtins.pyi#L936

FWIW I think 'self' should also be special-cased as positional-only. Nobody
wants to write 'C.foo(self=C())'. :-)

-- 
--Guido van Rossum (python.org/~guido <http://python.org/%7Eguido>)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Binary arithmetic does not always call subclasses first

[Guido van Rossum]

If this is portant I should probably ponder it.

On Apr 24, 2017 4:47 PM, "Stephan Hoyer"  wrote:

> +Georg Brandl, in case he remembers where "Move the 3k reST doc tree in
> place." moved things from:
> https://github.com/python/cpython/commit/116aa62bf54a39697e25f21d6cf679
> 9f7faa1349
>
> On Mon, Apr 24, 2017 at 4:29 PM, Nick Timkovich 
> wrote:
>
>> GitHub shows that that note hasn't changed in 10 years:
>> https://github.com/python/cpython/blame/master/Doc/
>> reference/datamodel.rst#L2210
>>
>> On Mon, Apr 24, 2017 at 3:15 PM, Terry Reedy  wrote:
>>
>>> On 4/24/2017 12:14 PM, Stephan Hoyer wrote:
>>>
>>> Based on the change in the documentation between 2.x and 3.x, I wonder
 if this is something that someone intended to clean up as part of Python
 3000 but never got around to. I would love to hear from anyone familiar
 with the historical context here.

>>>
>>> We should ask the intention of the person who made the change, which is
>>> in the repository.  If you email me the doc (the last part of the url) and
>>> location within, I will look it up.
>>>
>>> --
>>> Terry Jan Reedy
>>>
>>>
>>> ___
>>> Python-ideas mailing list
>>> Python-ideas@python.org
>>> https://mail.python.org/mailman/listinfo/python-ideas
>>> Code of Conduct: http://python.org/psf/codeofconduct/
>>>
>>
>>
>> ___
>> Python-ideas mailing list
>> Python-ideas@python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>>
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] New PEP 550: Execution Context

[Guido van Rossum]

I may have missed this (I've just skimmed the doc), but what's the
rationale for making the EC an *immutable* mapping? It's impressive that
you managed to create a faster immutable dict, but why does the use case
need one?

-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] New PEP 550: Execution Context

[Guido van Rossum]

Thanks for the explanation. Can you make sure this is explained in the PEP?

On Aug 11, 2017 10:43 PM, "Yury Selivanov" <yselivanov...@gmail.com> wrote:

> > On Fri, Aug 11, 2017 at 10:17 PM, Guido van Rossum <gu...@python.org>
> wrote:
> > > I may have missed this (I've just skimmed the doc), but what's the
> rationale
> > > for making the EC an *immutable* mapping? It's impressive that you
> managed
> > > to create a faster immutable dict, but why does the use case need one?
>
> > In this proposal, you have lots and lots of semantically distinct ECs.
> > Potentially every stack frame has its own (at least in async code). So
> > instead of copying the EC every time they create a new one, they want
> > to copy it when it's written to. This is a win if writes are
> > relatively rare compared to the creation of ECs.
>
> Correct. If we decide to use HAMT, the ratio of writes/reads becomes
> less important though.
>
> Yury
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] New PEP 550: Execution Context

[Guido van Rossum]

Could someone (perhaps in a new thread?) summarize the current proposal,
with some examples of how typical use cases would look? This is an
important topic but the discussion is way too voluminous for me to follow
while I'm on vacation with my family, and the PEP spends too many words on
motivation and not enough on crisply explaining how the proposed feature
works (what state is stored where how it's accessed, and how it's
manipulated behind the scenes).

-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] a new namedtuple

[Guido van Rossum]

On Mon, Jul 17, 2017 at 6:25 PM, Eric Snow <ericsnowcurren...@gmail.com>
wrote:

> On Mon, Jul 17, 2017 at 6:01 PM, Ethan Furman <et...@stoneleaf.us> wrote:
> > Guido has decreed that namedtuple shall be reimplemented with speed in
> mind.
>
> FWIW, I'm sure that any changes to namedtuple will be kept as minimal
> as possible.  Changes would be limited to the underlying
> implementation, and would not include the namedtuple() signature, or
> using metaclasses, etc.  However, I don't presume to speak for Guido
> or Raymond. :)
>

Indeed. I referred people here for discussion of ideas like this:

>>> a = (x=1, y=0)

-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] a new namedtuple

[Guido van Rossum]

On Tue, Jul 18, 2017 at 8:56 AM, Ethan Furman <et...@stoneleaf.us> wrote:

> I certainly don't expect the signature to change, but why is using a
> metaclass out?  The use (or not) of a metaclass /is/ an implementation
> detail.
>

It is until you try to subclass with another metaclass -- then you have a
metaclass conflict. If the namedtuple had no metaclass this would not be a
conflict. (This is one reason to love class decorators.)

-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] a new namedtuple

[Guido van Rossum]

On Tue, Jul 18, 2017 at 3:18 PM, Greg Ewing <greg.ew...@canterbury.ac.nz>
wrote:

> Ethan Furman wrote:
>
>> I certainly don't expect the signature to change, but why is using a
>> metaclass out?  The use (or not) of a metaclass /is/ an implementation
>> detail.
>>
>
> For me, the main benefit of using a metaclass would be that
> it enables using normal class declaration syntax to define a
> namedtuple. That's not just an implementation detail!


Newer versions of the typing module do this:
https://docs.python.org/3/library/typing.html#typing.NamedTuple (and indeed
it's done with a metaclass).

-- 
--Guido van Rossum (python.org/~guido <http://python.org/%7Eguido>)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] namedtuple literals [Was: RE a new namedtuple]

[Guido van Rossum]

Honestly I would like to declare the bare (x=1, y=0) proposal dead. Let's
encourage the use of objects rather than tuples (named or otherwise) for
most data exchanges. I know of a large codebase that uses dicts instead of
objects, and it's a mess. I expect the bare ntuple to encourage the same
chaos.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Binary arithmetic does not always call subclasses first

[Guido van Rossum]

Now that I am with a real keyboard and screen and have tried to understand
the OP, I can actually write up my thoughts on the matter.

There are two aspects to the behavior. Giving preference to the class of
the right operand if it is a subclass of the left operand's class is
reasonable and explained in the docs.

Only doing this if the right operand actually overrides __rop__ was perhaps
meant as an optimization, and I expect that when I introduced that rule I
hadn't thought of the kind of classes that use type(self) or self.__class__
to return an instance of the runtime class.

However there's also another thing to consider. Consider a variant of the
OP example, where B doesn't override __add__ or __radd__, but now add a
different __init__ signature, one that requires completely different
arguments. This is entirely legal and done often enough (though perhaps not
in numpy circles?) -- constructors are not subject to the Liskov rule. So
the call to type(self)() may crash or have an undesirable result.

But given that A does call type(self)(), all its subclasses have to
either have a compatible __init__ or override both __add__ and __radd__.

In the end I agree with the OP that we should fix this. I don't see a
reason to require a PEP or require updating whatever PEP described this
behavior originally -- PEPs generally describe what should be done to a
specific version of Python, they don't prevent future alterations, and they
essentially represent the historical record, not current documentation.

I'm a little worried about breaking existing code, but only a little bit,
and this is clearly a gray area, so I think it's okay to change in 3.7
without deprecations. (But I've been overruled on such matters before, so
if you disagree, speak up now and show us your code!)

--Guido

On Mon, Apr 24, 2017 at 4:54 PM, Guido van Rossum <gvanros...@gmail.com>
wrote:

> If this is portant I should probably ponder it.
>
> On Apr 24, 2017 4:47 PM, "Stephan Hoyer" <sho...@gmail.com> wrote:
>
>> +Georg Brandl, in case he remembers where "Move the 3k reST doc tree in
>> place." moved things from:
>> https://github.com/python/cpython/commit/116aa62bf54a39697e2
>> 5f21d6cf6799f7faa1349
>>
>> On Mon, Apr 24, 2017 at 4:29 PM, Nick Timkovich <prometheus...@gmail.com>
>> wrote:
>>
>>> GitHub shows that that note hasn't changed in 10 years:
>>> https://github.com/python/cpython/blame/master/Doc/re
>>> ference/datamodel.rst#L2210
>>>
>>> On Mon, Apr 24, 2017 at 3:15 PM, Terry Reedy <tjre...@udel.edu> wrote:
>>>
>>>> On 4/24/2017 12:14 PM, Stephan Hoyer wrote:
>>>>
>>>> Based on the change in the documentation between 2.x and 3.x, I wonder
>>>>> if this is something that someone intended to clean up as part of Python
>>>>> 3000 but never got around to. I would love to hear from anyone familiar
>>>>> with the historical context here.
>>>>>
>>>>
>>>> We should ask the intention of the person who made the change, which is
>>>> in the repository.  If you email me the doc (the last part of the url) and
>>>> location within, I will look it up.
>>>>
>>>> --
>>>> Terry Jan Reedy
>>>>
>>>>
>>>> ___
>>>> Python-ideas mailing list
>>>> Python-ideas@python.org
>>>> https://mail.python.org/mailman/listinfo/python-ideas
>>>> Code of Conduct: http://python.org/psf/codeofconduct/
>>>>
>>>
>>>
>>> ___________
>>> Python-ideas mailing list
>>> Python-ideas@python.org
>>> https://mail.python.org/mailman/listinfo/python-ideas
>>> Code of Conduct: http://python.org/psf/codeofconduct/
>>>
>>>
>>
>> ___
>> Python-ideas mailing list
>> Python-ideas@python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>>


-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Generator syntax hooks?

[Guido van Rossum]

On Tue, Aug 8, 2017 at 10:06 PM, Nick Coghlan <ncogh...@gmail.com> wrote:

> On 8 August 2017 at 09:06, Chris Barker <chris.bar...@noaa.gov> wrote:
> > It would be nice to have an easier access to an "slice iterator" though
> --
> > one of these days I may write up a proposal for that.
>
> An idea I've occasionally toyed with [1] is some kind of "iterview"
> that wraps around an arbitrary iterable and produces lazy itertools
> based results rather than immediate views or copies.
>
> However, my experience is also that folks are *really* accustomed to
> syntactic operations on containers producing either full live views
> (e.g. memoryview or numpy slices, range as a dynamically computed
> container), or actual copies (builtin container types). Having them
> produce consumable iterators instead then gets confusing due to the
> number of operations that will implicitly consume them (including
> simple "x in y" checks).
>
> The OP's proposal doesn't fit into that category though: rather it's
> asking about the case where we have an infinite iterator (e.g.
> itertools.count(0)), and want to drop items until they start meeting
> some condition (i.e. itertools.dropwhile) and then terminate the
> iterator as soon as another condition is no longer met (i.e.
> itertools.takewhile).
>

I don't think that's what the OP meant. The original proposal seemed to
assume that it would be somehow reasonable for the input ("integers" in the
example) to be able to see and parse the condition in the generator
expression ("1000 <= x < 10" in the example, with "x" somehow known to
be bound to the iteration value). That's at least what I think the remark
"I like mathy syntax" referred to.


> Right now, getting the "terminate when false" behaviour requires the
> use of takewhile:
>
> {itertools.takewhile(lambda x: x < 100, itertools.count(1000)}
>
> In these cases, the standard generator expression syntax is an
> attractive nuisance because it *looks* right from a mathematical
> perspective, but hides an infinite loop:
>
> {x for x in itertools.count(0) if 1000 <= x < 100}
>
> The most credible proposal to address this that I've seen is to borrow
> the "while" keyword in its "if not x: break" interpretation to get:
>
> {x for x in itertools.count(0) if 1000 <= x while x < 100}
>
> which would be compiled as equivalent to:
>
> x = set()
> for x in itertools.count(0):
> if 1000 <= x:
> set.add(x)
> if not x < 100:
> break
>
> (and similarly for all of the other comprehension variants)
>
> There aren't any technical barriers I'm aware of to implementing that,
> with the main historical objection being that instead of the
> comprehension level while clause mapping to a while loop directly the
> way the for and if clauses map to their statement level counterparts,
> it would instead map to the conditional break in the expanded
> loop-and-a-half form:
>
> while True:
> if not condition:
> break
>
> While it's taken me a long time to come around to the idea, "Make
> subtle infinite loops in mathematical code easier to avoid" *is* a
> pretty compelling user-focused justification for incurring that extra
> complexity at the language design level.
>

I haven't come around to this yet. It looks like it will make explaining
comprehensions more complex, since the translation of "while X" into "if
not X: break" feels less direct than the translations of "for x in xs" or
"if pred(x)". (In particular, your proposal seems to require more
experience with mentally translating loops and conditions into jumps --
most regulars of this forum do that for a living, but I doubt it's second
nature for the OP.)

-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] More Metadata for Variable Annotations

[Guido van Rossum]

A similar approach (though only for class/instance variables) is taken by
the 'attrs' package and by the proposal currently code-named "dataclasses" (
https://github.com/ericvsmith/dataclasses).

On Fri, Aug 18, 2017 at 10:48 AM, Ivan Levkivskyi <levkivs...@gmail.com>
wrote:

> Hi Bagrat,
>
> Thanks for a detailed proposal! Indeed, some projects might want to have
> some additional metadata attached to a variable/argument besides its type.
> However, I think it would be more productive to first discuss this on a
> more specialized forum like https://github.com/python/typing/issues
>
> Note that similar proposals have been discussed and rejected before, see
> for example
> https://www.python.org/dev/peps/pep-0484/#what-about-
> existing-uses-of-annotations
> so that you would need to have a strong argument, for example some popular
> projects that will benefit from your proposal.
>
> --
> Ivan
>
>
>
> On 18 August 2017 at 17:09, Bagrat Aznauryan <bag...@aznauryan.org> wrote:
>
>> # Abstract
>>
>> Before the holly PEP-526 the only option for type hints were comments.
>> And before PEP-484 the docstrings were the main place where variable
>> metadata would go. That variable metadata would include:
>>
>> * the type
>> * the human-readable description
>> * some value constraints (e.g. a range for integer variable)
>>
>> PEP-526 introduced the awesome syntax sugar, which made the first part of
>> the metadata - the type, easily introspectable during the runtime. However,
>> if you still need to add the description and the value constraints to the
>> variable metadata, you still need to fallback to the docstring option.
>>
>> The idea is to make it possible to be able to include all of the
>> mentioned metadata in the variable annotations.
>>
>> # Rationale
>>
>> Having the type specified using the supported annotation syntax and the
>> rest of the metadata in the docstrings, adds duplication and complexity for
>> further maintenance. Moreover, if you need the docstring-contained metadata
>> to be used in the runtime, you need to implement a parser or pick one from
>> existing ones which adds another dependency to your application.
>>
>> The need for the rest of the metadata other than the type, might be
>> proven to be common. A typical example is generating the JSON Schema for a
>> class, e.g. to be used for OpenAPI definition of your API.
>>
>> # Possible Solutions
>>
>> ## A wrapper
>>
>> The proposal is to introduce a new wrapper (probably a function), that
>> will accept the type as the first positional argument and additional
>> keyword arguments for metadata. The wrapper will map the keyword arguments
>> to the type object as attributes and return it. The code would look like
>> this:
>>
>> ```
>> foo: wrapper(
>> int,
>> description="bar",
>> minimum=0,
>> maximum=100
>> )
>> ```
>>
>> Later, the metadata can be accessed as the annotation attributes, like
>> e.g.:
>>
>> ```
>> __annotations__['foo'].description
>> ```
>>
>> ## Annotation as a tuple
>>
>> This solution does not require any code change in Python, but will force
>> other tools change the parsing (e.g. mypy). The proposal is that when the
>> annotation is optionally a tuple instance, use the first element as the
>> type of the variable, and ignore the rest or treat as additional metadata.
>> This will make it possible to add the metadata into a separate dictionary
>> as the second element of the annotation tuple. For example:
>>
>> ```
>> foo: (
>> int,
>> {
>> description="bar",
>> minimum=0,
>> maximum=100
>> }
>> )
>> ```
>>
>> The annotation will be stored as is, so to access the metadata in the
>> runtime, one would need to explicitly access the second item of the
>> annotation tuple.
>>
>> # Summary
>>
>> This option would help to have a well annotated code which will be
>> self-descriptive and provide abilities to generate schemas and other
>> definitions (e.g. OpenAPI) automatically and without duplication.
>>
>> The proposed solutions are definitely not perfect and not the main point
>> of this email. The target is to describe the idea and motivation and start
>> a discussion.
>>
>> ___
>> Python-ideas mailing list
>> Python-ideas@python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>>
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
>


-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 550 v2

[Guido van Rossum]

I'm also confused by these, because they share the noun part of their name,
but their use and meaning is quite different. The PEP defines an EC as a
stack of LCs, and (apart from strings :-) it's usually not a good idea to
use the same term for a container and its items.

On Fri, Aug 18, 2017 at 6:41 PM, Ethan Furman <et...@stoneleaf.us> wrote:

> On 08/16/2017 08:43 AM, Yury Selivanov wrote:
>
> To be honest, I really like Execution Context and Local Context names.
>> I'm curious if other people are confused with them.
>>
>
> +1 confused  :/
>
> --
> ~Ethan~
>
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>



-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] singledispatch for instance methods

[Guido van Rossum]

PS: I didn't see a message from Lisa on the mailing list -- maybe she
replied to you only?

On Sun, May 14, 2017 at 9:25 AM, Guido van Rossum <gu...@python.org> wrote:

> How exactly do you think the process of adopting something into the stdlib
> works? Just posting "bump" messages to the mailing list doesn't really
> help, it just sounds rude.If you need help understanding how to add/improve
> a stdlib module, please ask a specific about that topic.
>
> On Sun, May 14, 2017 at 12:43 AM, Bar Harel <bzvi7...@gmail.com> wrote:
>
>> Bump
>>
>> On Wed, Jan 4, 2017, 8:01 PM Lisa Roach <lisaroac...@gmail.com> wrote:
>>
>>> +1 to this as well, I think this would be really useful in the stdlib.
>>>
>>> On Mon, Dec 26, 2016 at 5:40 AM, Bar Harel <bzvi7...@gmail.com> wrote:
>>>
>>>> Any updates with a singledispatch for methods?
>>>>
>>>> On Tue, Sep 20, 2016, 5:49 PM Bar Harel <bzvi7...@gmail.com> wrote:
>>>>
>>>>> At last! Haven't used single dispatch exactly because of that. Thank
>>>>> you savior!
>>>>> +1
>>>>>
>>>>> On Tue, Sep 20, 2016, 6:03 AM Tim Mitchell <
>>>>> tim.mitch...@leapfrog3d.com> wrote:
>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> We have a modified version of singledispatch at work which works for
>>>>>> methods as well as functions.  We have open-sourced it as methoddispatch
>>>>>> (pypi: https://pypi.python.org/pypi/methoddispatch).
>>>>>>
>>>>>> IMHO I thought it would make a nice addition to python stdlib.
>>>>>>
>>>>>> What does everyone else think?
>>>>>>
>>>>>>
>>>>>> ___
>>>>>> Python-ideas mailing list
>>>>>> Python-ideas@python.org
>>>>>> https://mail.python.org/mailman/listinfo/python-ideas
>>>>>> Code of Conduct: http://python.org/psf/codeofconduct/
>>>>>
>>>>>
>>>> ___
>>>> Python-ideas mailing list
>>>> Python-ideas@python.org
>>>> https://mail.python.org/mailman/listinfo/python-ideas
>>>> Code of Conduct: http://python.org/psf/codeofconduct/
>>>>
>>>
>>>
>> ___
>> Python-ideas mailing list
>> Python-ideas@python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>>
>
>
> --
> --Guido van Rossum (python.org/~guido)
>



-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] singledispatch for instance methods

[Guido van Rossum]

How exactly do you think the process of adopting something into the stdlib
works? Just posting "bump" messages to the mailing list doesn't really
help, it just sounds rude.If you need help understanding how to add/improve
a stdlib module, please ask a specific about that topic.

On Sun, May 14, 2017 at 12:43 AM, Bar Harel <bzvi7...@gmail.com> wrote:

> Bump
>
> On Wed, Jan 4, 2017, 8:01 PM Lisa Roach <lisaroac...@gmail.com> wrote:
>
>> +1 to this as well, I think this would be really useful in the stdlib.
>>
>> On Mon, Dec 26, 2016 at 5:40 AM, Bar Harel <bzvi7...@gmail.com> wrote:
>>
>>> Any updates with a singledispatch for methods?
>>>
>>> On Tue, Sep 20, 2016, 5:49 PM Bar Harel <bzvi7...@gmail.com> wrote:
>>>
>>>> At last! Haven't used single dispatch exactly because of that. Thank
>>>> you savior!
>>>> +1
>>>>
>>>> On Tue, Sep 20, 2016, 6:03 AM Tim Mitchell <tim.mitch...@leapfrog3d.com>
>>>> wrote:
>>>>
>>>>> Hi All,
>>>>>
>>>>> We have a modified version of singledispatch at work which works for
>>>>> methods as well as functions.  We have open-sourced it as methoddispatch
>>>>> (pypi: https://pypi.python.org/pypi/methoddispatch).
>>>>>
>>>>> IMHO I thought it would make a nice addition to python stdlib.
>>>>>
>>>>> What does everyone else think?
>>>>>
>>>>>
>>>>> ___
>>>>> Python-ideas mailing list
>>>>> Python-ideas@python.org
>>>>> https://mail.python.org/mailman/listinfo/python-ideas
>>>>> Code of Conduct: http://python.org/psf/codeofconduct/
>>>>
>>>>
>>> ___
>>> Python-ideas mailing list
>>> Python-ideas@python.org
>>> https://mail.python.org/mailman/listinfo/python-ideas
>>> Code of Conduct: http://python.org/psf/codeofconduct/
>>>
>>
>>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
>


-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] singledispatch for instance methods

[Guido van Rossum]

Maybe ask core membership if they meant you to literally just post just the
word "bump" to the list (my guess is not). Also the last time I see that
you received any advice was a long time ago and regarding to a different
issue. For this idea there's no issue and no patch (and core devs aren't
required to read python-ideas).

Please understand that in this community you are expected to do some work
yourself too -- we're not being paid to implement features proposed (or fix
bugs reported) by users, we mostly implement/fix things we care about
personally, and some of us sometimes volunteer to mentor users who show an
interest in learning. IMO posting "bump" several times does not exhibit
such interest.

On Sun, May 14, 2017 at 9:37 AM, Bar Harel <bzvi7...@gmail.com> wrote:

> I guess so.
>
> Sorry for that.
> To be honest I'm not entirely sure of the entire procedure and if small
> things need a PEP or not. I actually received the tip to bump from
> core-mentorship, so now I'm rather confused.
>
> Anyway, shall I add it to the bug tracker as an enhancement?
>
> On Sun, May 14, 2017, 7:26 PM Guido van Rossum <gu...@python.org> wrote:
>
>> PS: I didn't see a message from Lisa on the mailing list -- maybe she
>> replied to you only?
>>
>> On Sun, May 14, 2017 at 9:25 AM, Guido van Rossum <gu...@python.org>
>> wrote:
>>
>>> How exactly do you think the process of adopting something into the
>>> stdlib works? Just posting "bump" messages to the mailing list doesn't
>>> really help, it just sounds rude.If you need help understanding how to
>>> add/improve a stdlib module, please ask a specific about that topic.
>>>
>>> On Sun, May 14, 2017 at 12:43 AM, Bar Harel <bzvi7...@gmail.com> wrote:
>>>
>>>> Bump
>>>>
>>>> On Wed, Jan 4, 2017, 8:01 PM Lisa Roach <lisaroac...@gmail.com> wrote:
>>>>
>>>>> +1 to this as well, I think this would be really useful in the stdlib.
>>>>>
>>>>> On Mon, Dec 26, 2016 at 5:40 AM, Bar Harel <bzvi7...@gmail.com> wrote:
>>>>>
>>>>>> Any updates with a singledispatch for methods?
>>>>>>
>>>>>> On Tue, Sep 20, 2016, 5:49 PM Bar Harel <bzvi7...@gmail.com> wrote:
>>>>>>
>>>>>>> At last! Haven't used single dispatch exactly because of that. Thank
>>>>>>> you savior!
>>>>>>> +1
>>>>>>>
>>>>>>> On Tue, Sep 20, 2016, 6:03 AM Tim Mitchell <
>>>>>>> tim.mitch...@leapfrog3d.com> wrote:
>>>>>>>
>>>>>>>> Hi All,
>>>>>>>>
>>>>>>>> We have a modified version of singledispatch at work which works
>>>>>>>> for methods as well as functions.  We have open-sourced it as
>>>>>>>> methoddispatch (pypi: https://pypi.python.org/pypi/methoddispatch).
>>>>>>>>
>>>>>>>> IMHO I thought it would make a nice addition to python stdlib.
>>>>>>>>
>>>>>>>> What does everyone else think?
>>>>>>>>
>>>>>>>>
>>>>>>>> ___________
>>>>>>>> Python-ideas mailing list
>>>>>>>> Python-ideas@python.org
>>>>>>>> https://mail.python.org/mailman/listinfo/python-ideas
>>>>>>>> Code of Conduct: http://python.org/psf/codeofconduct/
>>>>>>>
>>>>>>>
>>>>>> ___
>>>>>> Python-ideas mailing list
>>>>>> Python-ideas@python.org
>>>>>> https://mail.python.org/mailman/listinfo/python-ideas
>>>>>> Code of Conduct: http://python.org/psf/codeofconduct/
>>>>>>
>>>>>
>>>>>
>>>> ___
>>>> Python-ideas mailing list
>>>> Python-ideas@python.org
>>>> https://mail.python.org/mailman/listinfo/python-ideas
>>>> Code of Conduct: http://python.org/psf/codeofconduct/
>>>>
>>>>
>>>
>>>
>>> --
>>> --Guido van Rossum (python.org/~guido)
>>>
>>
>>
>>
>> --
>> --Guido van Rossum (python.org/~guido)
>>
>


-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] singledispatch for instance methods

[Guido van Rossum]

Thanks Steven. I think you've just concisely summarized the info in this
section of the devguide:
https://docs.python.org/devguide/stdlibchanges.html

On Sun, May 14, 2017 at 10:28 AM, Steven D'Aprano <st...@pearwood.info>
wrote:

> On Sun, May 14, 2017 at 05:10:53PM +, Bar Harel wrote:
> > As I said, sorry for that.
> >
> > It's just that I'm not entirely sure there's anything to implement here.
> > The implementation already exists. If it doesn't suffice I will help as
> > much as I can to make sure it works :-)
>
> I think you've succeeded in bringing the issue to people's attention :-)
>
> If you care about this enough to do the work (I don't, I expect this
> will be my last post on the topic), then I suggest you should:
>
> - contact Tim Mitchell and see if his offer of contributing the code
> still stands;
>
> - if so, and there are no conclusive objections on this list, then raise
> an issue on the bug tracker;
>
> - if not, then someone will have to fork Tim's code (assuming the
> licence allows it) or reimplement it without violating the licence;
>
> - somebody will have to make a Push Request on GitHub; that might be
> you, or it might be Tim;
>
> - Tim will need to sign a contributor agreement, since it's his code
> being used;
>
> - See the DevGuide for more details. (I don't remember the URL: unless
> someone else volunteers it, you can google for it.)
>
> And I think I've just hit the limit of how much I care about this issue.
> It would be nice to have, but I don't care enough to push it forward.
>
> Good luck.
>
>
> --
> Steve
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>



-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] JavaScript-Style Object Creation in Python (using a constructor function instead of a class to create objects)

[Guido van Rossum]

On Sun, May 14, 2017 at 12:35 AM, Simon Ramstedt <simonramst...@gmail.com>
wrote:

> What do you think are the odds of something like this actually making it
> into the Python and if greater than 0 in which timeframe?
>

If you're asking for language or stdlib support or an official endorsement,
the odds are exactly zero. Of course if this pattern is useful for you in
the context of something you are developing you are free to use it,
presuming it doesn't require language or stdlib changes.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] JavaScript-Style Object Creation in Python (using a constructor function instead of a class to create objects)

[Guido van Rossum]

I expect that we will need someone with a really good sensibility for
Pythonic language/API design to lead the PEP writing.

On Mon, May 15, 2017 at 9:03 AM, אלעזר <elaz...@gmail.com> wrote:

> On Mon, May 15, 2017 at 6:30 PM Guido van Rossum <gu...@python.org> wrote:
> > This should be worked into a PEP, instead of living on as a bunch of
> python-ideas posts and blogs.
>  ...
> > Will someone please write a PEP?
>
> If by "this" you mean adding to stdlib something like
>
> @record
> class Point:
> x: int
> y: int
>
> or something along the lines of my "modifiers" proposal (
> https://mail.python.org/pipermail//python-ideas/2016-September/042360.html),
> then I think I would like to help writing such a PEP. But I thought these
> proposals were rejected.
>
> Elazar
>



-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] JavaScript-Style Object Creation in Python (using a constructor function instead of a class to create objects)

[Guido van Rossum]

On Mon, May 15, 2017 at 9:50 AM, Brett Cannon <br...@python.org> wrote:

>
> On Mon, 15 May 2017 at 08:30 Guido van Rossum <gu...@python.org> wrote:
>
>> This should be worked into a PEP, instead of living on as a bunch of
>> python-ideas posts and blogs.
>>
>> I find the attrs documentation (and Glyph's blog post about it) almost
>> unreadable because of the exalted language -- half the doc seems to be
>> *selling* the library more than *explaining* it. If this style were to
>> become common I would find it a disturbing trend.
>>
>> But having something alongside NamedTuple that helps you declare classes
>> with mutable attributes using the new PEP 526 syntax (and maybe a few
>> variants) would definitely be useful. Will someone please write a PEP? Very
>> few of the specifics of attrs need be retained (its punny naming choices
>> are too much for the stdlib).
>>
>
> In case someone decides to take this on, I wrote a blog post back in March
> that shows how to use __init_subclass__() to do a rough approximation of
> what Guido is suggesting: https://snarky.ca/customizing-class-creation-in-
> python/ .
>
> Based on my thinking on the topic while writing my blog post, the tricky
> bit is going to be deciding how to handle default values (i.e. if you set a
> default value like `attr: int = 42` on the class definition then you have
> `cls.attr` exist which might not be what you want if you would rather have
> the default value explicitly set on every instance but not fall through to
> the class (e.g. `del ins.attr; ins.attr` raises an AttributeError instead
> of falling through to `cls.attr`). You could remove the default from the
> class in your __init_subclass__(), but then you have to decide if that's
> too unexpected/magical for someone looking at the code.
>

I would personally prefer the initializer to stay in the class in cases
like this. If the initializer needs to be a default instance of a mutable
class (e.g. an empty list or dict) there could be a special marker to
indicate that, e.g.

  attacks: List[int] = MAKE_NEW  # Creates a new [] for each instance

while if the default needs to be something more custom it could be a
similar marker with a callable argument, e.g.

  fleet: Dict[str, str] = MAKE_NEW(lambda: {'flagship': 'Enterprise'})

I would prefer not to have cleverness like initialization with a callable
automatically does something different.


> And I too would be interested in seeing something like this, if for any
> other reason than to help people not to misuse NamedTuple for
> quick-and-dirty data objects in new APIs (NamedTuple is meant to help move
> old-style tuple-based APIs to a class-based one).
>

Not sure I agree that is its only purpose.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] JavaScript-Style Object Creation in Python (using a constructor function instead of a class to create objects)

[Guido van Rossum]

I could also try this myself in my spare time at PyCon (surprisingly, I
have some!). It sounds kind of interesting. However I've never used the
'attrs' package...

On Tue, May 16, 2017 at 7:52 AM, Ivan Levkivskyi <levkivs...@gmail.com>
wrote:

> On 15 May 2017 at 18:22, Guido van Rossum <gu...@python.org> wrote:
>
>> I expect that we will need someone with a really good sensibility for
>> Pythonic language/API design to lead the PEP writing.
>>
>
> I probably don't have good sensibility for Pythonic API design yet (and I
> am more focused on PEP 544) so I cannot lead this,
> but I would like to actively participate in writing.
>
> --
> Ivan
>
>
>


-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] JavaScript-Style Object Creation in Python (using a constructor function instead of a class to create objects)

[Guido van Rossum]

This should be worked into a PEP, instead of living on as a bunch of
python-ideas posts and blogs.

I find the attrs documentation (and Glyph's blog post about it) almost
unreadable because of the exalted language -- half the doc seems to be
*selling* the library more than *explaining* it. If this style were to
become common I would find it a disturbing trend.

But having something alongside NamedTuple that helps you declare classes
with mutable attributes using the new PEP 526 syntax (and maybe a few
variants) would definitely be useful. Will someone please write a PEP? Very
few of the specifics of attrs need be retained (its punny naming choices
are too much for the stdlib).

--Guido

On Mon, May 15, 2017 at 4:05 AM, Nick Coghlan <ncogh...@gmail.com> wrote:

> On 14 May 2017 at 17:12, Abdur-Rahmaan Janhangeer <arj.pyt...@gmail.com>
> wrote:
> > Whatever you all propose,
> >
> > coming from a java and c++ background, OOP in python is quite cumbersome.
> >
> > if you tell that i am not a python guy, then consider that current oop
> style
> > does not reflect python's style of ease and simplicity
> >
> > is __init__ really a good syntax choice?
>
> That's a different question, and one with a well-structured third
> party solution: https://attrs.readthedocs.io/en/stable/
>
> See https://mail.python.org/pipermail/python-ideas/2017-April/045514.html
> for some ideas on how something like attrs might be adapted to provide
> better standard library tooling for more concise and readable class
> definitions.
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>



-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] be upfront if you aren't willing to implement your own idea

[Guido van Rossum]

category.
>
> I realize you're not proposing that all such discussion be stopped
> entirely, just that it be tagged as I-can't-implement-this-myself at the
> outset.  However, your last paragraph suggests to me that the effect might
> be similar.  You seem to be saying that (some of) those who do know how to
> implement stuff would like to be able to ignore discussion from anyone who
> doesn't know how to implement stuff.  That's certainly anyone's
> prerogative, but I think it would be a shame if this resulted in a
> bifurcation of the list in which ideas can't reach the attention of people
> who could implement them unless they're proposed by someone who could do so
> themselves.  To me, that would somewhat blur the distinction between
> python-ideas and python-dev, and potentially chill discussion of
> "mid-level" ideas proposed by people who know enough to have a potentially
> useful idea, but not enough to bring it to fruition.  We presumably don't
> want a situation where a person with some amount of knowledge thinks "This
> might be a good idea. . .  but I don't know how to implement it, so if I
> bring it up on the list the more knowledgeable people will ignore it, oh
> well, I guess I won't" --- while a person with no knowledge blithely jumps
> in with "Golly everyone I have this great idea!"  (I don't mean to say that
> is directly what you're proposing, but it is the evolution that came to my
> mind when I read your comment.)
>
> So to put it succinctly, as someone who's found discussion on this
> list interesting and valuable, I think there is value in having discussion
> about "what would Python be like if this idea were implemented" even if we
> never get very far with "how would we implement this idea in Python".  And
> I would find it unfortunate if discussion of the former were prematurely
> restricted by worries about the latter.
>
> --
> Brendan Barnwell
> "Do not follow where the path may lead.  Go, instead, where there is no
> path, and leave a trail."
>--author unknown
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>



-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] socket module: plain stuples vs named tuples

[Guido van Rossum]

There are examples in timemodule.c which went through a similar conversion
from plain tuples to (sort-of) named tuples. I agree that upgrading the
tuples returned by the socket module to named tuples would be nice, but
it's a low priority project. Maybe someone interested can create a PR?
(First open an issue stating that you're interested; point to this email
from me to prevent that some other core dev just closes it again.)

On Mon, Jun 19, 2017 at 2:24 PM, Victor Stinner <victor.stin...@gmail.com>
wrote:

> Hi,
>
> 2017-06-13 22:13 GMT+02:00 Thomas Güttler <guettl...@thomas-guettler.de>:
> > AFAIK the socket module returns plain tuples in Python3:
> >
> >   https://docs.python.org/3/library/socket.html
> >
> > Why not use named tuples?
>
> For technical reasons: the socket module is mostly implemented in the
> C language, and define a "named tuple" in C requires to implement a
> "sequence" time which requires much more code than creating a tuple.
>
> In short, create a tuple is as simple as Py_BuildValue("OO", item1, item2).
>
> Creating a "sequence" type requires something like 50 lines of code,
> maybe more, I don't know exactly.
>
> Victor
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>



-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] tweaking the file system path protocol

[Guido van Rossum]

I see no future for this proposal. Sorry Wolfgang! For future reference,
the proposal was especially weak because it gave no concrete examples of
code that was inconvenienced in any way by the current behavior. (And the
performance hack of checking for exact str/bytes can be made without
changing the semantics.)

On Tue, May 23, 2017 at 10:04 AM, Brett Cannon <br...@python.org> wrote:

>
>
> On Tue, 23 May 2017 at 03:13 Wolfgang Maier <wolfgang.ma...@biologie.uni-
> freiburg.de> wrote:
>
>> What do you think of this idea for a slight modification to os.fspath:
>> the current version checks whether its arg is an instance of str, bytes
>> or any subclass and, if so, returns the arg unchanged. In all other
>> cases it tries to call the type's __fspath__ method to see if it can get
>> str, bytes, or a subclass thereof this way.
>>
>> My proposal is to change this to:
>> 1) check whether the type of the argument is str or bytes *exactly*; if
>> so, return the argument unchanged
>> 2) check wether __fspath__ can be called on the type and returns an
>> instance of str, bytes, or any subclass (just like in the current version)
>> 3) check whether the type is a subclass of str or bytes and, if so,
>> return it unchanged
>>
>> This would have the following implications:
>> a) it would speed up the very common case when the arg is either a str
>> or a bytes instance exactly
>> b) user-defined classes that inherit from str or bytes could control
>> their path representation just like any other class
>> c) subclasses of str/bytes that don't define __fspath__ would still work
>> like they do now, but their processing would be slower
>> d) subclasses of str/bytes that accidentally define a __fspath__ method
>> would change their behavior
>>
>> I think cases c) and d) could be sufficiently rare that the pros
>> outweigh the cons?
>>
>
> What exactly is the performance issue you are having that is leading to
> this proposal? I ask because b) and d) change semantics and so it's not a
> small thing to make this change at this point since Python 3.6 has been
> released. So unless there's a major performance impact I'm reluctant to
> want to change it at this point.
>
> ___________
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
>


-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Exposing CPython's subinterpreter C-API in the stdlib.

[Guido van Rossum]

Hm... Curiously, I've heard a few people at PyCon mention they thought
subinterpreters were broken and not useful (and they share the GIL anyways)
and should be taken out. So we should at least have clarity on which
direction we want to take...

On Wed, May 24, 2017 at 6:01 PM, Eric Snow <ericsnowcurren...@gmail.com>
wrote:

> Although I haven't been able to achieve the pace that I originally
> wanted, I have been able to work on my multi-core Python idea
> little-by-little.  Most notably, some of the blockers have been
> resolved at the recent PyCon sprints and I'm ready to move onto the
> next step: exposing multiple interpreters via a stdlib module.
>
> Initially I just want to expose basic support via 3 successive
> changes.  Below I've listed the corresponding (chained) PRs, along
> with what they add.  Note that the 2 proposed modules take some cues
> from the threading module, but don't try to be any sort of
> replacement.  Threading and subinterpreters are two different features
> that are used together rather than as alternatives to one another.
>
> At the very least I'd like to move forward with the _interpreters
> module sooner rather than later.  Doing so will facilitate more
> extensive testing of subinterpreters, in preparation for further use
> of them in the multi-core Python project.  We can iterate from there,
> but I'd at least like to get the basic functionality landed early.
> Any objections to (or feedback about) the low-level _interpreters
> module as described?  Likewise for the high-level interpreters module?
>
> Discussion on any expanded functionality for the modules or on the
> broader topic of the multi-core project are both welcome, but please
> start other threads for those topics.
>
> -eric
>
>
> basic low-level API: https://github.com/python/cpython/pull/1748
>
>   _interpreters.create() -> id
>   _interpreters.destroy(id)
>   _interpreters.run_string(id, code)
>   _interpreters.run_string_unrestricted(id, code, ns=None) -> ns
>
> extra low-level API: https://github.com/python/cpython/pull/1802
>
>   _interpreters.enumerate() -> [id, ...]
>   _interpreters.get_current() -> id
>   _interpreters.get_main() -> id
>   _interpreters.is_running(id) -> bool
>
> basic high-level API: https://github.com/python/cpython/pull/1803
>
>   interpreters.enumerate() -> [Interpreter, ...]
>   interpreters.get_current() -> Interpreter
>   interpreters.get_main() -> Interpreter
>   interpreters.create() -> Interpreter
>   interpreters.Interpreter(id)
>   interpreters.Interpreter.is_running()
>   interpreters.Interpreter.destroy()
>   interpreters.Interpreter.run(code)
> ___________
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>



-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] JavaScript-Style Object Creation in Python (using a constructor function instead of a class to create objects)

[Guido van Rossum]

So it is only called by __init__ and not by __setattr__?

On Fri, May 19, 2017 at 11:32 AM, Stephan Houben <stephan...@gmail.com>
wrote:

> Let me quote the attrs docs:
>
> ""
> convert (callable) – callable() that is called by attrs-generated __init__
> methods to convert attribute’s value to the desired format. It is given the
> passed-in value, and the returned value will be used as the new value of
> the attribute. The value is converted before being passed to the validator,
> if any.
> """
>
> So the signature is essentially:
>
> self.myattrib = callable (myattrib)
>
> Stephan
>
> Op 19 mei 2017 20:25 schreef "Guido van Rossum" <gu...@python.org>:
>
> For people who don't want to click on links:
>>
>> 1. Allow hash and equality to be based on object identity, rather than
>> structural identity,
>>this is very important if one wants to store un-hashable objects in
>> the instance.
>>   (In my case: mostly dict's and numpy arrays).
>>
>> 2. Not subclassed from tuple. I have been bitten by this subclassing
>> when trying to set up
>>singledispatch on sequences and also on my classes.
>>
>> 3. Easily allow to specify default values. With namedtuple this
>> requires overriding __new__.
>>
>> 4. Easily allow to specify a conversion function. For example I have
>> some code like below:
>> note that I can store a numpy array while keeping hashability and
>> I can make it convert
>>to a numpy array in the constructor.
>>
>>  @attr.s(cmp=False, hash=False)
>>  class SvgTransform(SvgPicture):
>>  child = attr.ib()
>>  matrix = attr.ib(convert=numpy.asarray)
>>
>>
>> I have one question about (4) -- how and when is the conversion function 
>> used, and what is its signature?
>>
>>
>> On Fri, May 19, 2017 at 5:42 AM, Eric V. Smith <e...@trueblade.com>
>> wrote:
>>
>>> Could you point me to this 4-point list of Stephan's? I couldn't find
>>>> anything in the archive that you might be referring to.
>>>>
>>>
>>> Never mind, I found them here:
>>> https://mail.python.org/pipermail/python-ideas/2017-May/045679.html
>>>
>>> Eric.
>>>
>>>
>>> ___
>>> Python-ideas mailing list
>>> Python-ideas@python.org
>>> https://mail.python.org/mailman/listinfo/python-ideas
>>> Code of Conduct: http://python.org/psf/codeofconduct/
>>>
>>
>>
>>
>> --
>> --Guido van Rossum (python.org/~guido)
>>
>> ___
>> Python-ideas mailing list
>> Python-ideas@python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>>


-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] JavaScript-Style Object Creation in Python (using a constructor function instead of a class to create objects)

[Guido van Rossum]

Stephen,

What features of attrs specifically solve your use cases?

--Guido

On Tue, May 16, 2017 at 12:18 PM, Stephan Houben <stephan...@gmail.com>
wrote:

> Hi all,
>
> Thanks to this thread I learned about the "attrs" library. I am a
> heavy namedtuple (ab)user but I think
> I will be using attrs going forward.
>
> If something like attrs would made it in the standard library it would
> be awesome.
>
> Thanks,
>
> Stephan
>
> 2017-05-16 20:08 GMT+02:00 Brett Cannon <br...@python.org>:
> > Maybe we can bring this up as a lightning talk at the language summit to
> see
> > who in the room has the appropriate background knowledge? And obviously
> > someone can talk to Hynek to see if he wants to provide input based on
> > community feedback for attrs and lessons learned.
> >
> > On Tue, 16 May 2017 at 08:11 Guido van Rossum <gvanros...@gmail.com>
> wrote:
> >>
> >> Maybe Lukasz is interested?
> >>
> >> On May 16, 2017 8:00 AM, "Chris Angelico" <ros...@gmail.com> wrote:
> >>>
> >>> On Wed, May 17, 2017 at 12:53 AM, Guido van Rossum <gu...@python.org>
> >>> wrote:
> >>> > I could also try this myself in my spare time at PyCon
> (surprisingly, I
> >>> > have
> >>> > some!). It sounds kind of interesting. However I've never used the
> >>> > 'attrs'
> >>> > package...
> >>>
> >>> Me neither, so I'm not really an ideal person to head this up. Is
> >>> there anyone who (a) knows what is and isn't Pythonic, (b) has used
> >>> 'attrs', and (c) has spare time? It's not an easy trifecta but we can
> >>> hope!
> >>>
> >>> ChrisA
> >>> ___
> >>> Python-ideas mailing list
> >>> Python-ideas@python.org
> >>> https://mail.python.org/mailman/listinfo/python-ideas
> >>> Code of Conduct: http://python.org/psf/codeofconduct/
> >>
> >> ___________
> >> Python-ideas mailing list
> >> Python-ideas@python.org
> >> https://mail.python.org/mailman/listinfo/python-ideas
> >> Code of Conduct: http://python.org/psf/codeofconduct/
> >
> >
> > ___
> > Python-ideas mailing list
> > Python-ideas@python.org
> > https://mail.python.org/mailman/listinfo/python-ideas
> > Code of Conduct: http://python.org/psf/codeofconduct/
> >
>



-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] π = math.pi

[Guido van Rossum]

I would love to show how easy it is to write

from math import pi as π, gamma as Γ

but I had to cheat by copying from the OP since I don't know how to type
these (and even if you were to tell me how I'd forget tomorrow). So, I am
still in favor of the rule "only ASCII in the stdlib".

On Fri, Jun 2, 2017 at 3:48 PM, Ivan Levkivskyi <levkivs...@gmail.com>
wrote:

> On 2 June 2017 at 12:17, Giampaolo Rodola' <g.rod...@gmail.com> wrote:
>
>> On Thu, Jun 1, 2017 at 8:47 AM, Serhiy Storchaka <storch...@gmail.com>
>> wrote:
>>
>>> What you are think about adding Unicode aliases for some mathematic
>>> names in the math module? ;-)
>>>
>>> math.π = math.pi
>>> math.τ = math.tau
>>> math.Γ = math.gamma
>>> math.ℯ = math.e
>>>
>>> Unfortunately we can't use ∞, ∑ and √ as identifiers. :-(
>>>
>>> [...]
>> * duplicated aliases might make sense if they add readability; in this
>> case they don't unless (maybe) you have a mathematical background. I can
>> infer what "math.gamma" stands for but not being a mathematician math.Γ
>> makes absolutely zero sense to me.
>>
>>
> There is a significant number of scientific Python programmers (21%
> according to PyCharm 2016), so it is not that rare to meet someone who
> knows what is Gamma function.
> And for many of them π is much more readable than np.pi. Also there is
> another problem, confusion between Gamma function and Euler–Mascheroni
> constant, the first one is Γ,
> the second one is γ (perfectly opposite to PEP 8 capitalization rules :-),
> while both of them are frequently denoted as just gamma (in particular
> math.gamma follows the PEP8 rules,
> but is counter-intuitive for most scientist).
>
> All that said, I agree that these problems are easily solved by a custom
> import from. Still there is something in (or related to?) this proposal
> I think is worth considering: Can we also allow identifiers like ∫ or √.
> This will make many expressions more similar to usual TeX,
> plus it will be useful for projects like SymPy.
>
> --
> Ivan
>
>
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
>


-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] π = math.pi

[Guido van Rossum]

AFAK it was in whatever PEP introduced Unicode identifiers.

On Jun 3, 2017 11:24 PM, "Nick Coghlan" <ncogh...@gmail.com> wrote:

> On 4 June 2017 at 05:02, Dan Sommers <d...@tombstonezero.net> wrote:
> > On Sat, 03 Jun 2017 17:45:43 +, Brett Cannon wrote:
> >
> >> On Fri, 2 Jun 2017 at 15:56 Guido van Rossum <gu...@python.org> wrote:
> >>
> >>> I would love to show how easy it is to write
> >>>
> >>> from math import pi as π, gamma as Γ
> >
> > [...]
> >
> >>> but I had to cheat by copying from the OP since I don't know how to
> type
> >>> these (and even if you were to tell me how I'd forget tomorrow). So, I
> am
> >>> still in favor of the rule "only ASCII in the stdlib".
> >>
> >> Since this regularly comes up, why don't we add a note to the math
> module
> >> that you can do the above import(s) to bind various mathematical
> constants
> >> to their traditional symbol counterparts? ...
> >
> > Because in order to add that note to the math module, you have to
> > violate the "only ASCII in the stdlib" rule.  ;-)
>
> The ASCII-only restriction in the standard library is merely "all
> public APIs will use ASCII-only identifiers", rather than "We don't
> allow the use of Unicode anywhere" (Several parts of the documentation
> would be rather unreadable if they were restricted to ASCII
> characters).
>
> However, clarifying that made me realise we've never actually written
> that down anywhere - it's just been an assumed holdover from the fact
> that Python 2.7 is still being supported, and doesn't allow for
> Unicode identifiers in the first place.
>
> https://github.com/python/peps/pull/285 is a PR to explicitly document
> the standard library API restriction in the "Names to Avoid" part of
> PEP 8.
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] π = math.pi

[Guido van Rossum]

OK, I think this discussion is pretty much dead then. We definitely
shouldn't allow math operators in identifiers, otherwise in Python 4 or 5
we couldn't introduce them as operators.

On Fri, Jun 2, 2017 at 5:10 PM, Steven D'Aprano <st...@pearwood.info> wrote:

> On Fri, Jun 02, 2017 at 04:29:16PM -0700, Guido van Rossum wrote:
>
> > Are those characters not considered Unicode letters? Maybe we could add
> > their category to the allowed set?
>
> They're not letters:
>
> py> {unicodedata.category(c) for c in '∑√∫∞'}
> {'Sm'}
>
>
> That's Symbol, Math.
>
> One problem is that the 'Sm' category includes a whole lot of
> mathematical symbols that we probably don't want in identifiers:
>
> ∴ ∣ ≈ ≒ ≝ ≫ ≮ ⊞  (plus MANY more variations on = < and > operators)
>
> including some "Confusables":
>
> ∁ ∊ ∨ ∗ ∑ etc
>
> C ε v * Σ
>
> http://www.unicode.org/reports/tr39/
>
> Of course a language can define identifiers however it likes, but I
> think it is relevant that the Unicode Consortium's default algorithm for
> determining an identifier excludes Sm.
>
> http://www.unicode.org/reports/tr31/
>
> I also disagree with Ivan that these symbols would be particularly
> useful in general, even for maths-heavy code, although I wouldn't say no
> to special casing ∞ (infinity) and maybe √ as a unary square root
> operator.
>
>
>
> --
> Steve
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>



-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] π = math.pi

[Guido van Rossum]

Are those characters not considered Unicode letters? Maybe we could add
their category to the allowed set?

On Jun 2, 2017 4:02 PM, "Ivan Levkivskyi" <levkivs...@gmail.com> wrote:

> On 3 June 2017 at 00:55, Guido van Rossum <gu...@python.org> wrote:
>
>> [...]
>> So, I am still in favor of the rule "only ASCII in the stdlib".
>>
>
> But what about the other question? Currently, integral, sum, infinity,
> square root etc. Unicode symbols are all prohibited in identifiers.
> Is it possible to allow them?
>
> (Btw IPython just supports normal TeX notations like \pi, \lambda etc, so
> it is very easy to remember)
>
> --
> Ivan
>
>
>
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Security: remove "." from sys.path?

[Guido van Rossum]

I really don't want people to start using the "from . import foo" idiom for
their first steps into programming. It seems a reasonable "defensive
programming" maneuver  to put in scripts and apps made by professional
Python programmers for surprise-free wide distribution, but (like many of
those) should not be part of the learning experience.

On Sun, Jun 4, 2017 at 12:35 AM, Nick Coghlan <ncogh...@gmail.com> wrote:

> On 4 June 2017 at 10:00, Greg Ewing <greg.ew...@canterbury.ac.nz> wrote:
> > Is this really much of a security issue? Seems to me that
> > for someone to exploit it, they would have to inject a
> > malicious .py file alongside one of my script files. If
> > they can do that, they can probably do all kinds of bad
> > things directly.
>
> There are genuine problems with it, which is why we have the -I switch
> to enable "isolated mode" (where pretty much all per-user settings get
> ignored). However, just dropping the current directory from sys.path
> without also disabling those other features (like user site-packages
> processing and environment variable processing) really doesn't buy you
> much.
>
> So the better answer from a security perspective is PEP 432 and the
> separate system-python binary (and Eric Snow recently got us started
> down that path by merging the initial aspects of that PEP as a private
> development API, so we can adopt the new settings management
> architecture incrementally before deciding whether or not we want to
> support it as a public API).
>
> So rather than anything security related, the key reasons I'm
> personally interested in moving towards requiring main-relative
> imports to be explicit are a matter of making it easier to reason
> about a piece of code just by reading it, as well as automatically
> avoiding certain classes of beginner bugs (i.e. essentially the same
> arguments PEP 328 put forward for the previous switch away from
> implicit relative imports in package submodules:
> https://www.python.org/dev/peps/pep-0328/#rationale-for-absolute-imports).
>
> Currently, main relative imports look like this:
>
> import helper
>
> This means that at the point of reading it, you don't know whether
> "helper" is independently redistributed, or if it's expected to be
> distributed alongside the main script.
>
> By contrast:
>
> from . import helper
>
> Makes it clear that "helper" isn't a 3rd party thing, it's meant to be
> distributed alongside the main script, and if it's missing, you don't
> want to pick up any arbitrary top level module that happens to be
> called "helper".
>
> Reaching a point where we require main relative imports to be written
> as "from . import helper" also means that a script called "socket.py"
> could include the statement "import socket" and actually get the
> standard library's socket module as it expected - the developer of
> such a script would have to write "from . import socket" in order to
> reimport the main script as a module.
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>



-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] π = math.pi

[Guido van Rossum]

I think the strictness comes from the observation that the stdlib is read
and edited using *lots* of different tools and not every tool is with the
program. That argument may be weaker now than when that PEP was written,
but I still get emails and see websites with mojibake. (Most recently, the
US-PyCon badges had spaces for all non-ASCII letters.)

The argument is also weaker for comments than it is for identifiers, since
stdlib identifiers will be used through *even more* tools (anyone who uses
a name imported from stdlib). Docstrings are perhaps halfway in between.


On Sun, Jun 4, 2017 at 8:33 PM, Nick Coghlan <ncogh...@gmail.com> wrote:

> On 5 June 2017 at 07:00, Guido van Rossum <gvanros...@gmail.com> wrote:
> > AFAK it was in whatever PEP introduced Unicode identifiers.
>
> Ah, indeed it is: https://www.python.org/dev/peps/pep-3131/#policy-
> specification
>
> Interestingly, that's stricter than my draft PR for PEP 8, and I'm not
> entirely sure we follow the "string literals and comments must be in
> ASCII" part in its entirety:
>
> 
> All identifiers in the Python standard library MUST use ASCII-only
> identifiers, and SHOULD use English words wherever feasible (in many
> cases, abbreviations and technical terms are used which aren't
> English). In addition, string literals and comments must also be in
> ASCII. The only exceptions are (a) test cases testing the non-ASCII
> features, and (b) names of authors. Authors whose names are not based
> on the Latin alphabet MUST provide a Latin transliteration of their
> names.
> 
>
> That said, all the potential counter-examples that come to mind are in
> the documentation, but *not* in the corresponding docstrings (e.g. the
> Euro symbol used in in the docs for chr() and ord()).
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
>



-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Proposed PEP 484 addition: describe a way of annotating decorated declarations

[Guido van Rossum]

On Mon, May 1, 2017 at 12:28 AM, Nick Coghlan <ncogh...@gmail.com> wrote:

> On 1 May 2017 at 03:07, Guido van Rossum <gu...@python.org> wrote:
> > There's a PR to the peps proposal here:
> > https://github.com/python/peps/pull/242
> >
> > The full text of the current proposal is below. The motivation for this
> is
> > that for complex decorators, even if the type checker can figure out
> what's
> > going on (by taking the signature of the decorator into account), it's
> > sometimes helpful to the human reader of the code to be reminded of the
> type
> > after applying the decorators (or a stack thereof). Much discussion can
> be
> > found in the PR. Note that we ended up having `Callable` in the type
> because
> > there's no rule that says a decorator returns a function type (e.g.
> > `property` doesn't).
>
> So a rigorous typechecker that understood the full decorator stack
> would be able to check whether or not the argument to `decorated_type`
> was correct, while all typecheckers (and human readers) would be able
> to just believe the argument rather than having to run through all the
> decorator transformations?
>

Yes. In fact the intention is that the checker should check the declared
type with the inferred and complain if they don't fit. In some cases the
inferred type would have `Any` where the declared type would have a
specific type and then the declared type would "win" (for uses of the
decorated function) -- this is an example of where "erosion" in type
inference can be counteracted by explicit declarations.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP 563 and expensive backwards compatibility

[Guido van Rossum]

On Wed, Sep 13, 2017 at 11:56 AM, Jim J. Jewett <jimjjew...@gmail.com>
wrote:

> It should be possible to opt out for an entire module, and it should
> be possible to do so *without* first importing typing.
>

PEP 484 has a notation for this -- put

  # type: ignore

at the top of your file and the file won't be type-checked. (Before you
test this, mypy doesn't yet support this. But it could.)

IIUC functions and classes will still have an __annotations__ attribute
(except when it would be empty) so even with the __future__ import (or in
Python 4.0) you could still make non-standard use of annotations pretty
easily -- you'd just get a string rather than an object. (And a simple
eval() will turn the string into an object -- the PEP has a lot of extra
caution because currently the evaluation happens in the scope where the
annotation is encountered, but if you don't care about that everything's
easy.)

-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] A reminder for PEP owners

[Guido van Rossum]

I know there's a lot of excitement around lots of new ideas. And the 3.7
feature freeze is looming (January is in a few months). But someone has to
review and accept all those PEPs, and I can't do it all by myself.

If you want your proposal to be taken seriously, you need to include a
summary of the discussion on the mailing list (including objections, even
if you disagree!) in your PEP, e.g. as an extended design rationale or
under the Rejected Ideas heading.

If you don't do this you risk having to repeat yourself -- also you risk
having your PEP rejected, because at this point there's no way I am going
to read all the discussions.

-- 
--Guido van Rossum (python.org/~guido <http://python.org/%7Eguido>)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Hexadecimal floating literals

[Guido van Rossum]

Yeah, I agree, +0. It won't confuse anyone who doesn't care about it and
those who need it will benefit.

On Wed, Sep 20, 2017 at 6:13 PM, Nick Coghlan <ncogh...@gmail.com> wrote:

> On 21 September 2017 at 10:44, Chris Barker - NOAA Federal
> <chris.bar...@noaa.gov> wrote:
> [Thibault]
> >> To sum up:
> >> -  In some specific context, hexadecimal floating-point constants make
> it easy for the programmers to reproduce the exact value. Typically, a
> software engineer who is concerned about floating-point accuracy would
> prepare hexadecimal floating-point constants for use in a program by
> generating them with special software (e.g., Maple, Mathematica, Sage or
> some multi-precision library). These hexadecimal literals have been added
> to C (since C99), Java, Lua, Ruby, Perl (since v5.22), etc. for the same
> reasons.
> >> - The exact grammar has been fully documented in the IEEE-754-2008 norm
> (section 5.12.13), and also in C99 (or C++17 and others)
> >> - Of course, hexadecimal floating-point can be manipulated with
> float.hex() and float.fromhex(), *but* it works from strings, and the
> translation is done at execution-time...
> >
> > Right. But it addresses all of the points you make. The functionality
> > is there. Making a new literal will buy a slight improvement in
> > writability and performance.
> >
> > Is that worth much in a dynamic language like python?
>
> I think so, as consider this question: how do you write a script that
> accepts a user-supplied string (e.g. from a CSV file) and treats it as
> hex floating point if it has the 0x prefix, and decimal floating point
> otherwise?
>
> You can't just blindly apply float.fromhex(), as that will also treat
> unprefixed strings as hexadecimal:
>
> >>> float.fromhex("0x10")
> 16.0
> >>> float.fromhex("10")
> 16.0
>
> So you need to do the try/except dance with ValueError instead:
>
> try:
> float_data = float(text)
> except ValueError:
> float_values = float.fromhex(text)
>
> At which point you may wonder why you can't just write "float_data =
> float(text, base=0)" the way you can for integers:
>
> >>> int("10", base=0)
> 10
> >>> int("0x10", base=0)
> 16
>
> And if the float() builtin were to gain a "base" parameter, then it's
> only a short step from there to allow at least the "0x" prefix on
> literals, and potentially even "0b" and "0o" as well.
>
> So I'm personally +0 on the idea - it would improve interface
> consistency between integers and floating point values, and make it
> easier to write correctness tests for IEEE754 floating point hardware
> and algorithms in Python (where your input & output test vectors are
> going to use binary or hex representations, not decimal).
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>



-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Use __all__ for dir(module) (Was: PEP 562)

[Guido van Rossum]

I ave to agree with the other committers who already spoke up.

I'm not using tab completion much (I have a cranky old Emacs setup), but
isn't making tab completion better a job for editor authors (or
language-support-for-editor authors) rather than for the core language?
What editor are you using that calls dir() for tab completion?

On Sun, Sep 17, 2017 at 7:34 PM, Cody Piersall <cody.piers...@gmail.com>
wrote:

> On Tue, Sep 12, 2017 at 3:26 AM, Ivan Levkivskyi <levkivs...@gmail.com>
> wrote:
> > @Cody
> >> I still think the better way
> >> to solve the custom dir()  would be to change the module __dir__
> >> method to check if __all__ is defined and use it to generate the
> >> result if it exists. This seems like a logical enhancement to me,
> >> and I'm planning on writing a patch to implement this. Whether it
> >> would be accepted is still an open issue though.
> >
> > This seems a reasonable rule to me, I can also make this patch if
> > you will not have time.
>
> I submitted a PR:https://github.com/python/cpython/pull/3610
> and a BPO issue: https://bugs.python.org/issue31503
>
> R. David Murray pointed out that this is a backwards-incompatible
> change.  This is technically true, but I don't know of any code that
> depends on this behavior.  (Of course, that does not mean it does not
> exist!)
>
> From my perspective, the big benefit of this change is that
> tab-completion will get better for libraries which are already
> defining __all__.  This will make for a better REPL experience.  The
> only code in the stdlib that broke were tests in test_pkg which were
> explicitly checking the return value of dir().  Apart from that,
> nothing broke.
>
> If a module does not have __all__ defined, then nothing changes for that
> module.
>
> Cody
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>



-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] sys.py

[Guido van Rossum]

My preference is (1), revert. You have to understand how sys.modules works
before you can change it, and if you waste time debugging your mistake, so
be it. I think the sys.py proposal is the wrong way to fix the mistake you
made there.

On Wed, Sep 13, 2017 at 4:00 PM, Eric Snow <ericsnowcurren...@gmail.com>
wrote:

> On Tue, Sep 12, 2017 at 9:30 PM, Guido van Rossum <gu...@python.org>
> wrote:
> > I find this a disturbing trend.
>
> Which trend?  Moving away from "consenting adults"?  In the case of
> sys.modules, the problem is that assigning a bogus value (e.g. []) can
> cause the interpreter to crash.  It wasn't a problem until recently
> when I removed PyInterpreterState.modules and made sys.modules
> authoritative (see https://bugs.python.org/issue28411).  The options
> there are:
>
> 1. revert that change (which means assigning to sys.modules
> deceptively does nothing)
> 2. raise an exception in all the places that expect sys.modules to be
> a mapping (far from where sys.modules was re-assigned)
> 3. raise an exception if you try to set sys.modules to a non-mapping
> 4. let a bogus sys.modules break the interpreter (basically, tell
> people "don't do that")
>
> My preference is #3 (obviously), but it sounds like you'd rather not.
>
> > I think we have bigger fish to fry and this sounds like it could slow
> down startup.
>
> It should have little impact on startup.  The difference is the cost
> of importing the new sys module (which we could easily freeze to
> reduce the cost).  That cost would apply only to programs that
> currently import sys.  Everything in the stdlib would be updated to
> use _sys directly.
>
> If you think it isn't worth it then I'll let it go.  I brought it up
> because I consider it a cheap, practical solution to the problem I ran
> into.  Thanks!
>
> -eric
>



-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Hexadecimal floating literals

[Guido van Rossum]

On Thu, Sep 21, 2017 at 8:30 PM, David Mertz <me...@gnosis.cx> wrote:

> Simply because the edge cases for working with e.g. '0xC.68p+2' in a
> hypothetical future Python are less obvious and less simple to demonstrate,
> I feel like learners will be tempted to think that using this base-2/16
> representation saves them all their approximation issues and their need
> still to use isclose() or friends.
>

Show them 1/49*49, and explain why for i < 49, (1/i)*i equals 1 (lucky
rounding).

-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Hexadecimal floating literals

[Guido van Rossum]

On Thu, Sep 21, 2017 at 7:57 PM, David Mertz <me...@gnosis.cx> wrote:

> I think you are missing the point I was assuming at. Having a binary/hex
> float literal would tempt users to think "I know EXACTLY what number I'm
> spelling this way"... where most users definitely don't in edge cases.
>

That problem has never stopped us from using decimals. :-)


> Spelling it float.fromhex(s) makes it more obvious "this is an expert
> operation I may not understand the intricacies of."
>

I don't see why that would be more obvious than if it were built into the
language -- just because something is a function doesn't mean it's an
expert operation.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] Hexadecimal floating literals

[Guido van Rossum]

On Thu, Sep 21, 2017 at 9:20 PM, Nick Coghlan <ncogh...@gmail.com> wrote:

> >>> one_tenth = 0x1.0 / 0xA.0
> >>> two_tenths = 0x2.0 / 0xA.0
> >>> three_tenths = 0x3.0 / 0xA.0
> >>> three_tenths == one_tenth + two_tenths
> False
>

OMG Regardless of whether we introduce this feature, .hex() is the way to
show what's going on here:

>>> 0.1.hex()
'0x1.ap-4'
>>> 0.2.hex()
'0x1.ap-3'
>>> 0.3.hex()
'0x1.3p-2'
>>> (0.1+0.2).hex()
'0x1.33334p-2'
>>>

This shows so clearly that there's 1 bit difference!

-- 
--Guido van Rossum (python.org/~guido <http://python.org/%7Eguido>)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP draft: context variables

[Guido van Rossum]

On Sun, Oct 8, 2017 at 11:46 PM, Nick Coghlan <ncogh...@gmail.com> wrote:

> On 8 October 2017 at 08:40, Koos Zevenhoven <k7ho...@gmail.com> wrote:
>
>> On Sun, Oct 8, 2017 at 12:16 AM, Nathaniel Smith <n...@pobox.com> wrote:
>>
>>> On Oct 7, 2017 12:20, "Koos Zevenhoven" <k7ho...@gmail.com> wrote:
>>>
>>>
>>> ​Unfortunately, we actually need a third kind of generator semantics,
>>> something like this:
>>>
>>> @​contextvars.caller_context
>>> def genfunc():
>>> assert cvar.value is the_value
>>> yield
>>> assert cvar.value is the_value
>>>
>>> with cvar.assign(the_value):
>>> gen = genfunc()
>>>
>>> next(gen)
>>>
>>> with cvar.assign(1234567890):
>>> try:
>>> next(gen)
>>> except StopIteration:
>>> pass
>>>
>>> Nick, Yury and I (and Nathaniel, Guido, Jim, ...?) somehow just narrowly
>>> missed the reasons for this in discussions related to PEP 550. Perhaps
>>> because we had mostly been looking at it from an async angle.
>>>
>>>
>>> That's certainly a semantics that one can write down (and it's what the
>>> very first version of PEP 550 did),
>>>
>>
>> ​​I do remember Yury mentioning that the first draft of PEP 550 captured
>> something when the generator function was called. I think I started reading
>> the discussions after that had already been removed, so I don't know
>> exactly what it was. But I doubt that it was *exactly* the above, because
>> PEP 550 uses set and get operations instead of "assignment contexts" like
>> PEP 555 (this one) does. ​​
>>
>
> We didn't forget it, we just don't think it's very useful.
>

I'm not sure I agree on the usefulness. Certainly a lot of the complexity
of PEP 550 exists just to cater to Nathaniel's desire to influence what a
generator sees via the context of the send()/next() call. I'm still not
sure that's worth it. In 550 v1 there's no need for chained lookups.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP draft: context variables

[Guido van Rossum]

On Tue, Oct 10, 2017 at 5:34 AM, Nick Coghlan <ncogh...@gmail.com> wrote:

> On 10 October 2017 at 01:24, Guido van Rossum <gu...@python.org> wrote:
>
>> On Sun, Oct 8, 2017 at 11:46 PM, Nick Coghlan <ncogh...@gmail.com> wrote:
>>
>>> On 8 October 2017 at 08:40, Koos Zevenhoven <k7ho...@gmail.com> wrote:
>>>
>>>> ​​I do remember Yury mentioning that the first draft of PEP 550
>>>> captured something when the generator function was called. I think I
>>>> started reading the discussions after that had already been removed, so I
>>>> don't know exactly what it was. But I doubt that it was *exactly* the
>>>> above, because PEP 550 uses set and get operations instead of "assignment
>>>> contexts" like PEP 555 (this one) does. ​​
>>>>
>>>
>>> We didn't forget it, we just don't think it's very useful.
>>>
>>
>> I'm not sure I agree on the usefulness. Certainly a lot of the complexity
>> of PEP 550 exists just to cater to Nathaniel's desire to influence what a
>> generator sees via the context of the send()/next() call. I'm still not
>> sure that's worth it. In 550 v1 there's no need for chained lookups.
>>
>
> The compatibility concern is that we want developers of existing libraries
> to be able to transparently switch from using thread local storage to
> context local storage, and the way thread locals interact with generators
> means that decimal (et al) currently use the thread local state at the time
> when next() is called, *not* when the generator is created.
>

Apart from the example in PEP 550, is that really a known idiom?


> I like Yury's example for this, which is that the following two examples
> are currently semantically equivalent, and we want to preserve that
> equivalence:
>
> with decimal.localcontext() as ctx:
> ctc.prex = 30
> for i in gen():
>pass
>
> g = gen()
> with decimal.localcontext() as ctx:
> ctc.prex = 30
> for i in g:
>   pass
>

Do we really want that equivalence? It goes against the equivalence from
Koos' example.


> The easiest way to maintain that equivalence is to say that even though
> preventing state changes leaking *out* of generators is considered a
> desirable change, we see preventing them leaking *in* as a gratuitous
> backwards compatibility break.
>

I dunno, I think them leaking in in the first place is a dubious feature,
and I'm not too excited that the design of the way forward should bend over
backwards to be compatible here.

The only real use case I've seen so far (not counting examples that just
show how it works) is Nathaniel's timeout example (see point 9 in Nathaniel’s
message
<https://mail.python.org/pipermail/python-ideas/2017-August/046736.html>),
and I'm still not convinced that that example is important enough to
support either.

It would all be easier to decide if there were use cases that were less
far-fetched, or if the far-fetched use cases would be supportable with a
small tweak. As it is, it seems that we could live in a simpler, happier
world if we gave up on context values leaking in via next() etc. (I still
claim that in that case we wouldn't need chained lookup in the exposed
semantics, just fast copying of contexts.)


> This does mean that *neither* form is semantically equivalent to eager
> extraction of the generator values before the decimal context is changed,
> but that's the status quo, and we don't have a compelling justification for
> changing it.
>

I think the justification is that we could have a *significantly* simpler
semantics and implementation.


> If folks subsequently decide that they *do* want "capture on creation" or
> "capture on first iteration" semantics for their generators, those are easy
> enough to add as wrappers on top of the initial thread-local-compatible
> base by using the same building blocks as are being added to help event
> loops manage context snapshots for coroutine execution.
>

(BTW Capture on first iteration sounds just awful.)

I think we really need to do more soul-searching before we decide that a
much more complex semantics and implementation is worth it to maintain
backwards compatibility for leaking in via next().

-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-ideas] PEP draft: context variables

[Guido van Rossum]

I would like to reboot this discussion (again). It feels to me we're
getting farther and farther from solving any of the problems we might solve.

I think we need to give up on doing anything about generators; the use
cases point in too many conflicting directions. So we should keep the
semantics there, and if you don't want your numeric or decimal context to
leak out of a generator, don't put `yield` inside `with`. (Yury and Stefan
have both remarked that this is not a problem in practice, given that there
are no bug reports or StackOverflow questions about this topic.)

Nobody understands async generators, so let's not worry about them.

That leaves coroutines (`async def` and `await`). It looks like we don't
want to change the original semantics here either, *except* when a
framework like asyncio or Twisted has some kind of abstraction for a
"task". (I intentionally don't define tasks, but task switches should be
explicit, e.g. via `await` or some API -- note that even gevent qualifies,
since it only switches when you make a blocking call.)

The key things we want then are (a) an interface to get and set context
variables whose API is independent from the framework in use (if any), and
(b) a way for a framework to decide when context variables are copied,
shared or reinitialized.

For (a) I like the API from PEP 550:

var = contextvars.ContextVar('description')
value = var.get()
var.set(value)

It should be easy to adopt this e.g. in the decimal module instead of the
current approach based on thread-local state.

For (b) I am leaning towards something simple that emulates thread-local
state. Let's define "context" as a mutable mapping whose keys are
ContextVar objects, tied to the current thread (each Python thread knows
about exactly one context, which is deemed the current context). A
framework can decide to clone the current context and assign it to a new
task, or initialize a fresh context, etc. The one key feature we want here
is that the right thing happens when we switch tasks via `await`, just as
the right thing happens when we switch threads. (When a framework uses some
other API to switch tasks, the framework do what it pleases.)

I don't have a complete design, but I don't want chained lookups, and I
don't want to obsess over performance. (I would be fine with some kind of
copy-on-write implementation, and switching out the current context should
be fast.) I also don't want to obsess over API abstraction. Finally I don't
want the design to be closely tied to `with`.

Maybe I need to write my own PEP?

-- 
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/