Re: [Python-Dev] PEP 575, 576, 579 and 580

[Jeroen Demeyer]

On 2018-07-08 23:13, Mark Shannon wrote:

I've added you suggestion, and everyone else's, to this github repo:
https://github.com/markshannon/extended-calling-convention

Feel free to comment on github, submit PRs or just email me directly if
you have anything else you want to add.


Do you agree to add this to PEP 579 instead?
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Call for prudence about PEP-572

[Matěj Cepl]

On 2018-07-07, 15:48 GMT, Guido van Rossum wrote:
> if validate(name := re.search(pattern, line).group(1)):
> return name

Except there is no error handling for situations when 
re.search() returns None, so one shouldn't use it anyway (most 
of the time). Which seems to me like another nice example why 
one should stay away from this style as much as possible. I am 
too lazy to be tempted into this 
nice-example-terrible-production-code world.

Best,

Matěj
-- 
https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz
GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
 
They that can give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety.
-- Benjamin Franklin, Historical Review
   of Pennsylvania, 1759.

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Call for prudence about PEP-572

[Berker Peksağ]

On Mon, Jul 9, 2018 at 8:54 AM, Tim Peters  wrote:
> [Eric V. Smith]
>>
>> > there is at least one place
>>
>> > where the grammar does forbid you from doing something that would
>> > otherwise make be allowable: decorators.
>
>
> [Greg Ewing]
>>
>>  And that was a controversial issue at the time. I don't remember
>>
>> there being much of an objective argument for the restriction --
>> it was more or less a matter of "Guido wanted it that way".
>
>
> Start here:
>
> https://mail.python.org/pipermail/python-dev/2004-August/046711.html

There is also an open issue about removing that restriction:
https://bugs.python.org/issue19660

https://bugs.python.org/file32745/decorator-syntax.patch removes a
test that raises SyntaxError for the following snippet:

@x[3]
def foo():
pass

--Berker
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Time for 3.4.9 and 3.5.6

[Matěj Cepl]

On 2018-07-08, 22:32 GMT, Larry Hastings wrote:
> More importantly, 3.4 is in security-fixes-only mode, which 
> means that changes that aren't security fixes won't be 
> accepted.

So, why isn’t https://bugs.python.org/issue31623 closed as 
WONTFIX (or whatever is the equivalent in b.p.o)? If we don't 
close our bugs, we surely will drown in them even more.

Best,

Matěj
-- 
https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz
GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
 
Give your heartache to him. (1Pt 5,7; Mt 11:28-30)

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] why is not 64-bit installer the default download link for Windows?

[Cosimo Lupo]

If one goes to httWhps://www.python.org/downloads
 from a Windows browser, the default
download URL is for the 32-bit installer instead of the 64-bit one.
I wonder why is this still the case?
Shouldn't we encourage new Windows users (who may not even know the
distinction between the two architectures) to use the 64-bit version of
Python, since most likely they can?
If this is not the correct forum for this, please let me know where I can
direct my question/feature request, thanks.

Cosimo

-- 
Cosimo Lupo
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] why is not 64-bit installer the default download link for Windows?

[Steve Dower]

On 09Jul2018 0803, Cosimo Lupo wrote:
If one goes to httWhps://www.python.org/downloads 
 from a Windows browser, the default 
download URL is for the 32-bit installer instead of the 64-bit one.

I wonder why is this still the case?
Shouldn't we encourage new Windows users (who may not even know the 
distinction between the two architectures) to use the 64-bit version of 
Python, since most likely they can?


The difficulty is that they *definitely* can use the 32-bit version, and 
those few who are on older machines or older installs of Windows may not 
understand why the link we provide didn't work for them.


From the various telemetry I've seen (and I work at Microsoft, so I 
have better access than most :) ), there is still enough 32-bit Windows 
out there that I'm not confident enough with "most likely". I haven't 
checked any location data (not even sure if we've got it), but I'd guess 
that there's higher 32-bit usage among less privileged countries and people.


I've thought a bit about making a single installer that can offer the 
option of 32-bit/64-bit at install time, but I don't actually think it's 
that big a problem to deserve that much effort as a solution.


Perhaps we should add non-button text below the button saying "Get the 
64-bit version"?


Cheers,
Steve
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Call for prudence about PEP-572

[Paddy McCarthy]

On Sat, 7 Jul 2018 at 16:50, Guido van Rossum  wrote:

> This seems more suitable for a style guide.
>

Which would be good enough, if the automatic checkers were improved  to
flag such poor use of ':='..

Would that be possible?
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] why is not 64-bit installer the default download link for Windows?

[Antoine Pitrou]

On Mon, 9 Jul 2018 09:01:00 -0700
Steve Dower  wrote:

> On 09Jul2018 0803, Cosimo Lupo wrote:
> > If one goes to httWhps://www.python.org/downloads 
> >  from a Windows browser, the default 
> > download URL is for the 32-bit installer instead of the 64-bit one.
> > I wonder why is this still the case?
> > Shouldn't we encourage new Windows users (who may not even know the 
> > distinction between the two architectures) to use the 64-bit version of 
> > Python, since most likely they can?  
> 
> The difficulty is that they *definitely* can use the 32-bit version, and 
> those few who are on older machines or older installs of Windows may not 
> understand why the link we provide didn't work for them.
> 
>  From the various telemetry I've seen (and I work at Microsoft, so I 
> have better access than most :) ), there is still enough 32-bit Windows 
> out there that I'm not confident enough with "most likely". I haven't 
> checked any location data (not even sure if we've got it), but I'd guess 
> that there's higher 32-bit usage among less privileged countries and people.
> 
> I've thought a bit about making a single installer that can offer the 
> option of 32-bit/64-bit at install time, but I don't actually think it's 
> that big a problem to deserve that much effort as a solution.
> 
> Perhaps we should add non-button text below the button saying "Get the 
> 64-bit version"?

Or perhaps the 32-bit installer could detect a 64-bit system and add
an info box at the beginning?

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Call for prudence about PEP-572

[Chris Angelico]

On Tue, Jul 10, 2018 at 2:20 AM, Paddy McCarthy  wrote:
>
>
> On Sat, 7 Jul 2018 at 16:50, Guido van Rossum  wrote:
>>
>> This seems more suitable for a style guide.
>
>
> Which would be good enough, if the automatic checkers were improved  to flag
> such poor use of ':='..
>
> Would that be possible?
>

I would recommend letting it be for a while, and seeing what abuses
actually happen. Then linters can be coded to flag the abuses.

ChrisA
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] why is not 64-bit installer the default download link for Windows?

[Paul Moore]

On 9 July 2018 at 17:01, Steve Dower  wrote:
> On 09Jul2018 0803, Cosimo Lupo wrote:
>>
>> If one goes to httWhps://www.python.org/downloads
>>  from a Windows browser, the default
>> download URL is for the 32-bit installer instead of the 64-bit one.
>> I wonder why is this still the case?
>> Shouldn't we encourage new Windows users (who may not even know the
>> distinction between the two architectures) to use the 64-bit version of
>> Python, since most likely they can?

I agree, I'd rather see the 64-bit version be more accessible.

> The difficulty is that they *definitely* can use the 32-bit version, and
> those few who are on older machines or older installs of Windows may not
> understand why the link we provide didn't work for them.
>
> From the various telemetry I've seen (and I work at Microsoft, so I have
> better access than most :) ), there is still enough 32-bit Windows out there
> that I'm not confident enough with "most likely". I haven't checked any
> location data (not even sure if we've got it), but I'd guess that there's
> higher 32-bit usage among less privileged countries and people.

I'm happy to go with your research on whether the 32-bit version
should be the obvious choice, but I don't think that means we have to
hide the 64-bit version as much as we do.

> I've thought a bit about making a single installer that can offer the option
> of 32-bit/64-bit at install time, but I don't actually think it's that big a
> problem to deserve that much effort as a solution.

I agree, having 2 versions of the installer seems fine to me.

> Perhaps we should add non-button text below the button saying "Get the
> 64-bit version"?

Why not just have a second button, "Download Python 3.7.0 (64-bit)"
alongside or below the "Download Python 3.7.0" button? People who
don't know the difference will just ignore it, people who do will be
able to choose straight from the main download page.

Paul
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] why is not 64-bit installer the default download link for Windows?

[Ivan Pozdeev via Python-Dev]

On 09.07.2018 19:01, Steve Dower wrote:

On 09Jul2018 0803, Cosimo Lupo wrote:
If one goes to httWhps://www.python.org/downloads 
 from a Windows browser, the 
default download URL is for the 32-bit installer instead of the 
64-bit one.

I wonder why is this still the case?
Shouldn't we encourage new Windows users (who may not even know the 
distinction between the two architectures) to use the 64-bit version 
of Python, since most likely they can?


The difficulty is that they *definitely* can use the 32-bit version, 
and those few who are on older machines or older installs of Windows 
may not understand why the link we provide didn't work for them.


From the various telemetry I've seen (and I work at Microsoft, so I 
have better access than most :) ), there is still enough 32-bit 
Windows out there that I'm not confident enough with "most likely". I 
haven't checked any location data (not even sure if we've got it), but 
I'd guess that there's higher 32-bit usage among less privileged 
countries and people.


I've thought a bit about making a single installer that can offer the 
option of 32-bit/64-bit at install time, but I don't actually think 
it's that big a problem to deserve that much effort as a solution.


Perhaps we should add non-button text below the button saying "Get the 
64-bit version"?




Maybe infer the bitness from User-Agent instead. This seems to be the 
trend among official sites in general.



Cheers,
Steve
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/vano%40mail.mipt.ru


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] why is not 64-bit installer the default download link for Windows?

[Steve Dower]

On 09Jul2018 0927, Ivan Pozdeev via Python-Dev wrote:

On 09.07.2018 19:01, Steve Dower wrote:
Perhaps we should add non-button text below the button saying "Get the 
64-bit version"?




Maybe infer the bitness from User-Agent instead. This seems to be the 
trend among official sites in general.


I'm not into creating that much work for someone else, since I'm 
certainly not going to be the one making this change.


Adding static text or a second button (as Paul suggested) is fine by me. 
But I don't want to start receiving bugs (or more likely, I don't want 
webmaster to start receiving emails) saying that the download is broken 
because someone who didn't think got the incompatible version.


Cheers,
Steve
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] why is not 64-bit installer the default download link for Windows?

[Steve Dower]

On 09Jul2018 0922, Antoine Pitrou wrote:

On Mon, 9 Jul 2018 09:01:00 -0700
Steve Dower  wrote:

I've thought a bit about making a single installer that can offer the
option of 32-bit/64-bit at install time, but I don't actually think it's
that big a problem to deserve that much effort as a solution.

Perhaps we should add non-button text below the button saying "Get the
64-bit version"?


Or perhaps the 32-bit installer could detect a 64-bit system and add
an info box at the beginning?


That's not a bad idea. Needs a bpo issue, but shouldn't be too hard to 
do. And it should be safe to backport for 3.7.1, as there's no real 
behaviour change.


Cheers,
Steve
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Naming comprehension syntax [was Re: Informal educator feedback on PEP 572 ...]

[Chris Barker - NOAA Federal via Python-Dev]

TL;DR-

+1 on advocating the term “generator comprehension” as a synonym for
“generator expression” in future documentation and instructional
materials.

The long version:

If we were starting from scratch, maybe it would makes sense to use “
builder” or something else, rather than comprehension. But we’re  not
starting from scratch.

And “list comprehension” has become a pretty universal (or at least
common) term in the python world. So we really can’t expect to re-name
that.

And despite the term having its roots in an esoteric corner of
mathematics, I’ve never seen anyone confused by it — it’s just a new
word for a new thing to most folks.

Which is actually why “generator expression” is a bit confusing — it
seems to have more in common with comprehensions than with generators

(As in: the things functions with a yield in them produce)

In fact, the term “generator” is a bit confusing itself — due to it
being a common English word, it seems to refer to the generic idea of
“a thing that generates values on the fly”, which, of course it can be
in Python. But it actually is a specific type. And you can make a
“thing that generates values in the fly” with a regular class that
follows the iterator protocol.

So re-using the word in “generator expression” just adds a bit to the
confusion. (Even though it’s technically correct, it does “make” an
actual generator object, doesn’t it? (On a phone, so I can’t check)
but that’s kind of an implementation detail.

Also: if you google: “python list comprehension” you get a LOT of hits
to tutorials, etc.

So it is WAY too late to change that name.

When you google “python generator expression” the top hit is the
python docs, and the next few are about comparing generator
expressions and list comprehensions.

So I think we could start a new naming scheme for those.

 ‘cause then we’d get lost of questions about the difference between
generator expressions and generator comprehensions ;-)


-CHB
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Naming comprehension syntax [was Re: Informal educator feedback on PEP 572 ...]

[Guido van Rossum]

I think this is worth a try.

On Mon, Jul 9, 2018 at 12:04 PM Chris Barker - NOAA Federal <
chris.bar...@noaa.gov> wrote:

> TL;DR-
>
> +1 on advocating the term “generator comprehension” as a synonym for
> “generator expression” in future documentation and instructional
> materials.
>
> The long version:
>
> If we were starting from scratch, maybe it would makes sense to use “
> builder” or something else, rather than comprehension. But we’re  not
> starting from scratch.
>
> And “list comprehension” has become a pretty universal (or at least
> common) term in the python world. So we really can’t expect to re-name
> that.
>
> And despite the term having its roots in an esoteric corner of
> mathematics, I’ve never seen anyone confused by it — it’s just a new
> word for a new thing to most folks.
>
> Which is actually why “generator expression” is a bit confusing — it
> seems to have more in common with comprehensions than with generators
>
> (As in: the things functions with a yield in them produce)
>
> In fact, the term “generator” is a bit confusing itself — due to it
> being a common English word, it seems to refer to the generic idea of
> “a thing that generates values on the fly”, which, of course it can be
> in Python. But it actually is a specific type. And you can make a
> “thing that generates values in the fly” with a regular class that
> follows the iterator protocol.
>
> So re-using the word in “generator expression” just adds a bit to the
> confusion. (Even though it’s technically correct, it does “make” an
> actual generator object, doesn’t it? (On a phone, so I can’t check)
> but that’s kind of an implementation detail.
>
> Also: if you google: “python list comprehension” you get a LOT of hits
> to tutorials, etc.
>
> So it is WAY too late to change that name.
>
> When you google “python generator expression” the top hit is the
> python docs, and the next few are about comparing generator
> expressions and list comprehensions.
>
> So I think we could start a new naming scheme for those.
>
>  ‘cause then we’d get lost of questions about the difference between
> generator expressions and generator comprehensions ;-)
>
>
> -CHB
>


-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 574 -- Pickle protocol 5 with out-of-band data

[Olivier Grisel]

Hi Serhiy,

Do you have any bug / issue to track the work you want to do to add native
pickling support for locally defined function and classes by serializing
the code objects like cloudpickle does?

Is this work public on some git branch on GitHub or somewhere else?

Cheers,

-- 
Olivier
​
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Naming comprehension syntax [was Re: Informal educator feedback on PEP 572 ...]

[Brett Cannon]

On Mon, 9 Jul 2018 at 12:05 Guido van Rossum  wrote:

> I think this is worth a try.
>

How far do we want to go with this? Update the docs? Update the grammar
and/or code? I think the former is probably good enough for now to see if
it takes, and if it does then we can talk about updating code to not
confuse people.


>
> On Mon, Jul 9, 2018 at 12:04 PM Chris Barker - NOAA Federal <
> chris.bar...@noaa.gov> wrote:
>
>> TL;DR-
>>
>> +1 on advocating the term “generator comprehension” as a synonym for
>> “generator expression” in future documentation and instructional
>> materials.
>>
>> The long version:
>>
>> If we were starting from scratch, maybe it would makes sense to use “
>> builder” or something else, rather than comprehension. But we’re  not
>> starting from scratch.
>>
>> And “list comprehension” has become a pretty universal (or at least
>> common) term in the python world. So we really can’t expect to re-name
>> that.
>>
>> And despite the term having its roots in an esoteric corner of
>> mathematics, I’ve never seen anyone confused by it — it’s just a new
>> word for a new thing to most folks.
>>
>> Which is actually why “generator expression” is a bit confusing — it
>> seems to have more in common with comprehensions than with generators
>>
>> (As in: the things functions with a yield in them produce)
>>
>> In fact, the term “generator” is a bit confusing itself — due to it
>> being a common English word, it seems to refer to the generic idea of
>> “a thing that generates values on the fly”, which, of course it can be
>> in Python. But it actually is a specific type. And you can make a
>> “thing that generates values in the fly” with a regular class that
>> follows the iterator protocol.
>>
>> So re-using the word in “generator expression” just adds a bit to the
>> confusion. (Even though it’s technically correct, it does “make” an
>> actual generator object, doesn’t it? (On a phone, so I can’t check)
>> but that’s kind of an implementation detail.
>>
>> Also: if you google: “python list comprehension” you get a LOT of hits
>> to tutorials, etc.
>>
>> So it is WAY too late to change that name.
>>
>> When you google “python generator expression” the top hit is the
>> python docs, and the next few are about comparing generator
>> expressions and list comprehensions.
>>
>> So I think we could start a new naming scheme for those.
>>
>>  ‘cause then we’d get lost of questions about the difference between
>> generator expressions and generator comprehensions ;-)
>>
>>
>> -CHB
>>
>
>
> --
> --Guido van Rossum (python.org/~guido)
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Naming comprehension syntax [was Re: Informal educator feedback on PEP 572 ...]

[Guido van Rossum]

Definitely docs first. And we should keep references to generator
expressions too, if only to explain that they've been renamed.

Perhaps someone should try it out in a 3rd party tutorial to see how it
goes? I'm CC'ing Raymond Hettinger.

On Mon, Jul 9, 2018 at 12:57 PM Brett Cannon  wrote:

>
>
> On Mon, 9 Jul 2018 at 12:05 Guido van Rossum  wrote:
>
>> I think this is worth a try.
>>
>
> How far do we want to go with this? Update the docs? Update the grammar
> and/or code? I think the former is probably good enough for now to see if
> it takes, and if it does then we can talk about updating code to not
> confuse people.
>
>
>>
>> On Mon, Jul 9, 2018 at 12:04 PM Chris Barker - NOAA Federal <
>> chris.bar...@noaa.gov> wrote:
>>
>>> TL;DR-
>>>
>>> +1 on advocating the term “generator comprehension” as a synonym for
>>> “generator expression” in future documentation and instructional
>>> materials.
>>>
>>> The long version:
>>>
>>> If we were starting from scratch, maybe it would makes sense to use “
>>> builder” or something else, rather than comprehension. But we’re  not
>>> starting from scratch.
>>>
>>> And “list comprehension” has become a pretty universal (or at least
>>> common) term in the python world. So we really can’t expect to re-name
>>> that.
>>>
>>> And despite the term having its roots in an esoteric corner of
>>> mathematics, I’ve never seen anyone confused by it — it’s just a new
>>> word for a new thing to most folks.
>>>
>>> Which is actually why “generator expression” is a bit confusing — it
>>> seems to have more in common with comprehensions than with generators
>>>
>>> (As in: the things functions with a yield in them produce)
>>>
>>> In fact, the term “generator” is a bit confusing itself — due to it
>>> being a common English word, it seems to refer to the generic idea of
>>> “a thing that generates values on the fly”, which, of course it can be
>>> in Python. But it actually is a specific type. And you can make a
>>> “thing that generates values in the fly” with a regular class that
>>> follows the iterator protocol.
>>>
>>> So re-using the word in “generator expression” just adds a bit to the
>>> confusion. (Even though it’s technically correct, it does “make” an
>>> actual generator object, doesn’t it? (On a phone, so I can’t check)
>>> but that’s kind of an implementation detail.
>>>
>>> Also: if you google: “python list comprehension” you get a LOT of hits
>>> to tutorials, etc.
>>>
>>> So it is WAY too late to change that name.
>>>
>>> When you google “python generator expression” the top hit is the
>>> python docs, and the next few are about comparing generator
>>> expressions and list comprehensions.
>>>
>>> So I think we could start a new naming scheme for those.
>>>
>>>  ‘cause then we’d get lost of questions about the difference between
>>> generator expressions and generator comprehensions ;-)
>>>
>>>
>>> -CHB
>>>
>>
>>
>> --
>> --Guido van Rossum (python.org/~guido)
>>
>

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Micro-benchmarks for function calls (PEP 576/579/580)

[Jeroen Demeyer]

Here is an initial version of a micro-benchmark for C function calling:

https://github.com/jdemeyer/callbench

I don't have results yet, since I'm struggling to find the right options 
to "perf timeit" to get a stable result. If somebody knows how to do 
this, help is welcome.



Jeroen.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Call for prudence about PEP-572

[Anthony Flury via Python-Dev]

On 09/07/18 08:26, Matěj Cepl wrote:

On 2018-07-07, 15:48 GMT, Guido van Rossum wrote:

 if validate(name := re.search(pattern, line).group(1)):
 return name

Except there is no error handling for situations when
re.search() returns None, so one shouldn't use it anyway (most
of the time). Which seems to me like another nice example why
one should stay away from this style as much as possible. I am
too lazy to be tempted into this
nice-example-terrible-production-code world.

So wrap it in a try/except to capture the re.search returning None:

    try:
        if validate(name := re.search(pattern, line).group(1)):
         return name
except TypeError:
          # No match case

And this solution is even better if the validate function raises an 
exception rather than True/False


which I think is much better than trying to do multiple steps :

   match = re.search(pattern, line)
   if match is not None:
       name = match.group(1)
       if name and validate(name):
          return name
   else:
   # No valid case
   else:
       # No Match case


Best,

Matěj



--
--
Anthony Flury
email : *anthony.fl...@btinternet.com*
Twitter : *@TonyFlury *

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] PEP 572: Assignment Expressions -- intention to accept, near-final draft

[Guido van Rossum]

A lot has been said about PEP 572. I am planning to accept it soon,
hopefully within a week. I realize I should have posted the draft from May
22 (when Tim and I were added as authors and it was significantly updated
-- see https://github.com/python/peps/pull/654). For this I apologize.
Since then we've been diligently updating various details, tightening the
spec without really changing the intended design.

I know it is inevitable that there will be replies attempting to convince
us that a different syntax is better or that we shouldn't do this at all.
Please save your breath. Iv'e seen every possible such response before, and
they haven't convinced me. At this point we're just looking for feedback on
the text of the document, e.g. pointing out ambiguities or requests for
more clarity in some part of the spec, *not* for alternative designs or
passionate appeals to PEP 20.

Below is the latest draft. All three authors are happy with it. You can
also read the PEP online at https://www.python.org/dev/peps/pep-0572/. We
strongly prefer feedback in the form of Pull Requests to the peps repo (the
file is at https://github.com/python/peps/blob/master/pep-0572.rst).


PEP: 572
Title: Assignment Expressions
Author: Chris Angelico , Tim Peters ,
Guido van Rossum 
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 28-Feb-2018
Python-Version: 3.8
Post-History: 28-Feb-2018, 02-Mar-2018, 23-Mar-2018, 04-Apr-2018,
17-Apr-2018,
  25-Apr-2018, 09-Jul-2018


Abstract


This is a proposal for creating a way to assign to variables within an
expression using the notation ``NAME := expr``.

Pending Acceptance
--

This PEP will be accepted, however it needs some editing for clarity
and exact specification.  A final draft will be posted to python-dev.
Note that alternate syntax proposals ("EXPR as NAME", "EXPR given
...") are no longer under consideration.  Hopefully the final draft
will be posted well before the end of July 2018.


Rationale
=

Naming the result of an expression is an important part of programming,
allowing a descriptive name to be used in place of a longer expression,
and permitting reuse.  Currently, this feature is available only in
statement form, making it unavailable in list comprehensions and other
expression contexts.

Additionally, naming sub-parts of a large expression can assist an
interactive
debugger, providing useful display hooks and partial results. Without a way
to
capture sub-expressions inline, this would require refactoring of the
original
code; with assignment expressions, this merely requires the insertion of a
few
``name :=`` markers. Removing the need to refactor reduces the likelihood
that
the code be inadvertently changed as part of debugging (a common cause of
Heisenbugs), and is easier to dictate to another programmer.

The importance of real code
---

During the development of this PEP many people (supporters and critics
both) have had a tendency to focus on toy examples on the one hand,
and on overly complex examples on the other.

The danger of toy examples is twofold: they are often too abstract to
make anyone go "ooh, that's compelling", and they are easily refuted
with "I would never write it that way anyway".

The danger of overly complex examples is that they provide a
convenient strawman for critics of the proposal to shoot down ("that's
obfuscated").

Yet there is some use for both extremely simple and extremely complex
examples: they are helpful to clarify the intended semantics.
Therefore there will be some of each below.

However, in order to be *compelling*, examples should be rooted in
real code, i.e. code that was written without any thought of this PEP,
as part of a useful application, however large or small.  Tim Peters
has been extremely helpful by going over his own personal code
repository and picking examples of code he had written that (in his
view) would have been *clearer* if rewritten with (sparing) use of
assignment expressions.  His conclusion: the current proposal would
have allowed a modest but clear improvement in quite a few bits of
code.

Another use of real code is to observe indirectly how much value
programmers place on compactness.  Guido van Rossum searched through a
Dropbox code base and discovered some evidence that programmers value
writing fewer lines over shorter lines.

Case in point: Guido found several examples where a programmer
repeated a subexpression, slowing down the program, in order to save
one line of code, e.g. instead of writing::

match = re.match(data)
group = match.group(1) if match else None

they would write::

group = re.match(data).group(1) if re.match(data) else None

Another example illustrates that programmers sometimes do more work to
save an extra level of indentation::

match1 = pattern1.match(data)
match2 = pattern2.match(data)
if match1:
return match1.group(1)
elif match2:
return 

[Python-Dev] Encoding variable-length integers/counts in pickle

[MRAB]

In the regex module I use an encoding scheme when pickling pattern 
objects which is based on the way MIDI encodes variable-length integers, 
and I think it might have a use in a pickle protocol.


In the basic format, an integer is split up into 7-bit chunks, each 
chunk put into a byte, and the most-significant bit of the byte used to 
signal whether the value continues into the following byte.


And integer must be encoded into the minimum number of bytes, so an 
encoded sequence of bytes would never start with 0x80.


MIDI deviates from the basic idea in order to reduce the number of 
bytes, so as sequence of bytes in MIDI _can_ start with x080; this is 
fine for MIDI because it doesn't need to represent negative integers.


The format I'm suggesting uses an initial 0x80 as a way of letting it 
encode negative integers.


Here are a couple of Python functions that summarise the encoding and 
decoding (minus obvious optimisations for simplicity):



def encode_varint(value: int) -> List[int]:
negative = value < 0
encoded = []

if negative:
final = -1
else:
final = 0

while True:
encoded.append(0x80 | (value & 0x7F))
value >>= 7

if value == final:
break

if negative:
encoded.append(0x80)

encoded.reverse()

encoded[-1] &= 0x7F

return encoded


def decode_varint(encoded: Iterable[int]) -> int:
byte = next(encoded)

if byte == 0x80:
value = -1
byte = next(encoded)
else:
value = 0

value = (value << 7) | (byte & 0x7F)

while (byte & 0x80) != 0:
byte = next(encoded)
value = (value << 7) | (byte & 0x7F)

return value


The advantage of encoding integers in this way is that there's no limit 
to their size, so there's no need to add a new protocol to support 
larger counts.


They can also make pickles smaller.

Example:

# Pickle (None, )
0: \x80 PROTO  4
2: \x95 FRAME  4
   11: NNONE
   12: \x85 TUPLE1
   13: \x94 MEMOIZE(as 0)
   14: .STOP

Here, FRAME takes an argument of 8 bytes. If you replaced FRAME with a 
version that accepted a variable-length count, you could reduce that 
argument to 1 byte.


You also wouldn't need to have different fixed-length versions of an 
opcode, e.g. BINUNICODE and SHORT_BINUNICODE.


Whether you do anything with this is entirely up to the core devs, I 
just thought someone might find it useful.

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 572: Assignment Expressions -- intention to accept, near-final draft

[Glenn Linderman]

On 7/9/2018 6:00 PM, Guido van Rossum wrote:

This rule is included to simplify the choice for the user between an
  assignment statements and an assignment expression -- there is no


"statements" should not be plural in the above line.


syntactic position where both are valid.




An exception to this special case applies when the target name is the
same as a loop control variable for a comprehension containing it.
This is invalid.  This exception exists to rule out edge cases of the
above scope rules as illustrated by ``[i := i+1 for i in range(5)]``
or ``[[(j := j) for i in range(5)] for j in range(5)]``.  Note that
this exception also applies to ``[i := 0 for i, j in stuff]``, as well
as to cases like ``[i+1 for i in i := stuff]``.



It is unclear whether exactly what is invalid. Is the use of the target 
name that is the same as (any of the nested) loop control variable 
invalid? I think, from discussions, that that is what is meant. But this 
paragraph could be interpreted as meaning the special case doesn't 
apply, meaning that the target name would be in a "sublocal" scope.




The ``:=`` operator groups more tightly than a comma in all syntactic
positions where it is legal, but less tightly than all operators,


If comma is considered an operator, this sentence is inconsistent, would 
need to be "all other operators".  Even if comma is not considered an 
operator, the sentence would be more clear with "other" added, since 
":=" is an operator.



Sorry, I haven't learned pull requests.
Glenn

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] why is not 64-bit installer the default download link for Windows?

[Alex Walters]

> -Original Message-
> From: Python-Dev  list=sdamon@python.org> On Behalf Of Paul Moore
 
> Why not just have a second button, "Download Python 3.7.0 (64-bit)"
> alongside or below the "Download Python 3.7.0" button? People who
> don't know the difference will just ignore it, people who do will be
> able to choose straight from the main download page.
> 

I think this is the solution.

* If you don't know your architecture, 32-bit will mostly work so should
remain the default (I say most, not all, since there are windows versions
that run on ARM, but I think you can only install software through the store
on those anyways.)

* It's not exposed in the download drop down at all that x64 editions exist
for those who know they want it.  The drop down is wide enough to support a
second download button.

> Paul
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/tritium-
> list%40sdamon.com

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 572: Assignment Expressions -- intention to accept, near-final draft

[Rob Cliffe via Python-Dev]

I apologise for not replying in the form of a Pull Request - I don't 
know how to make one.



On 10/07/2018 02:00, Guido van Rossum wrote:

Rationale
=

Naming the result of an expression is an important part of programming,
allowing a descriptive name to be used in place of a longer expression,
and permitting reuse.  Currently, this feature is available only in
statement form, making it unavailable in list comprehensions and other
expression contexts.
I think the wording of the last sentence gives too much importance to 
list comprehensions (IMO influenced by the amount of discussion of the 
PEP that was related to list comprehensions, understandably since that 
was the case where the semantics were most debatable).  I would suggest

"... making it unavailable in expression contexts."
or maybe
"... making it unavailable in expression contexts (including list 
comprehension)."



Another example illustrates that programmers sometimes do more work to
save an extra level of indentation::

    match1 = pattern1.match(data)
    match2 = pattern2.match(data)
    if match1:
    return match1.group(1)
    elif match2:
    return match2.group(2)

This code tries to match ``pattern2`` even if ``pattern1`` has a match
(in which case the match on ``pattern2`` is never used). The more
efficient rewrite would have been::

    match1 = pattern1.match(data)
    if match1:
    return match1.group(1)
    else:
    match2 = pattern2.match(data)
    if match2:
    return match2.group(2)

I suggest
... The more efficient rewrite would have been:
    match1 = pattern1.match(data)
    if match1:
    return match1.group(1)
    match2 = pattern2.match(data)
    if match2:
    return match2.group(2)
(a more natural way to write it which avoids cascading indentation).


    # Handle a matched regex
    if (match := pattern.search(data)) is not None:
    ...

I suggest
    # Handle a matched regex
    if (match := pattern.search(data)) is not None:
    # do something with match
I think it is really important to make clear the benefit of the PEP 
here: that "match" is bound to a value and can be used subsequently.



    # A more explicit alternative to the 2-arg form of iter() invocation
    while (value := read_next_item()) is not None:
    ...
As the 2-arg form of iter() is not that well known, I suggest that the 
iter version is spelled out for contrast.  (Sorry, I can't quite work it 
what it would be.)


    # Share a subexpression between a comprehension filter clause and 
its output

    filtered_data = [y for x in data if (y := f(x)) is not None]
That's fine, but what about also having an example that illustrates, 
simply, the "permitting reuse" in an expression part of the Rationale, e.g.

        powers = [ (y := x+1), y**2, y**3, y**4 ]
(I appreciate that this sort of overlaps with the section "Simplifying 
list comprehensions", but it seems to me to be such an important part of 
the Rationale that it should be illustrated here.)



Relative precedence of ``:=``
-

The ``:=`` operator groups more tightly than a comma in all syntactic
positions where it is legal, but less tightly than all operators,
including ``or``, ``and`` and ``not``.

and presumably including "if" and "else", as in
    x := y if y else -1
Might it be worth adding "if" and "else" to the list?



- Single assignment targets other than than a single ``NAME`` are
  not supported::

    # No equivalent
    a[i] = x
    self.rest = []

[snip]

- Iterable packing and unpacking (both regular or extended forms) are
  not supported::

    # Equivalent needs extra parentheses
    loc = x, y  # Use (loc := (x, y))
    info = name, phone, *rest  # Use (info := (name, phone, *rest))

    # No equivalent
    px, py, pz = position
    name, phone, email, *other_info = contact

[snip]
    total += tax  # Equivalent: (total := total + tax)
Is it conceivable that some of these restrictions might be removed in a 
future version of Python?  If so, the PEP might include a note to this 
effect.


Oh, and what I think are typos:

(Note that ``with EXPR as VAR`` does *not* simply assing the value
   of ``EXPR`` to ``VAR`` -- it calls ``EXPR.__enter__()`` and assigns
   the result of *that* to ``VAR``.)

    assing -> assign

(eg where the condition is ``f(x) < 0``

    eg -> e.g.

members of the core-mentorship mailing list

    core-mentorship -> core mentorship

is a vast improvment over the briefer::

    improvment -> improvement

Best wishes
Rob Cliffe


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 572: Assignment Expressions -- intention to accept, near-final draft

[Guido van Rossum]

On Mon, Jul 9, 2018 at 7:40 PM, Glenn Linderman 
wrote:

> On 7/9/2018 6:00 PM, Guido van Rossum wrote:
>
>   This rule is included to simplify the choice for the user between an
>   assignment statements and an assignment expression -- there is no
>
>
> "statements" should not be plural in the above line.
>

Will fix.

  syntactic position where both are valid.
>
>
>
> An exception to this special case applies when the target name is the
> same as a loop control variable for a comprehension containing it.
> This is invalid.  This exception exists to rule out edge cases of the
> above scope rules as illustrated by ``[i := i+1 for i in range(5)]``
> or ``[[(j := j) for i in range(5)] for j in range(5)]``.  Note that
> this exception also applies to ``[i := 0 for i, j in stuff]``, as well
> as to cases like ``[i+1 for i in i := stuff]``.
>
>
>
> It is unclear whether exactly what is invalid. Is the use of the target
> name that is the same as (any of the nested) loop control variable invalid?
> I think, from discussions, that that is what is meant. But this paragraph
> could be interpreted as meaning the special case doesn't apply, meaning
> that the target name would be in a "sublocal" scope.
>

Really? If it didn't say "this is invalid" I could see that "exception to
the special case" might be interpreted as "the special case doesn't apply".
But with "This is invalid" explicitly added I don't see how that
interpretation could be valid. Is it clearer if I changed that to "Such
code is invalid"? Or perhaps I should move "This is invalid" to the end of
the paragraph?


> The ``:=`` operator groups more tightly than a comma in all syntactic
> positions where it is legal, but less tightly than all operators,
>
>
> If comma is considered an operator, this sentence is inconsistent, would
> need to be "all other operators".  Even if comma is not considered an
> operator, the sentence would be more clear with "other" added, since ":="
> is an operator.
>

Makes sense.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 572: Assignment Expressions -- intention to accept, near-final draft

[Glenn Linderman]

On 7/9/2018 8:43 PM, Guido van Rossum wrote:



An exception to this special case applies when the target name is the
same as a loop control variable for a comprehension containing it.
This is invalid.  This exception exists to rule out edge cases of the
above scope rules as illustrated by ``[i := i+1 for i in range(5)]``
or ``[[(j := j) for i in range(5)] for j in range(5)]``. Note that
this exception also applies to ``[i := 0 for i, j in stuff]``, as
well
as to cases like ``[i+1 for i in i := stuff]``.



It is unclear whether exactly what is invalid. Is the use of the
target name that is the same as (any of the nested) loop control
variable invalid? I think, from discussions, that that is what is
meant. But this paragraph could be interpreted as meaning the
special case doesn't apply, meaning that the target name would be
in a "sublocal" scope.


Really? If it didn't say "this is invalid" I could see that "exception 
to the special case" might be interpreted as "the special case doesn't 
apply". But with "This is invalid" explicitly added I don't see how 
that interpretation could be valid. Is it clearer if I changed that to 
"Such code is invalid"? Or perhaps I should move "This is invalid" to 
the end of the paragraph?


That's better; even better might be to say what is invalid... instead of 
used pronoun.


"Use of any of the comprension loop control variables as a target name 
in an assignment expression is invalid."


It isn't really an exception to the special case, it is an exception to 
the general rule than any old name can be used as an assignment 
expression target, IIUC.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 572: Assignment Expressions -- intention to accept, near-final draft

[Guido van Rossum]

On Mon, Jul 9, 2018 at 8:24 PM, Rob Cliffe via Python-Dev <
python-dev@python.org> wrote:

> I apologise for not replying in the form of a Pull Request - I don't know
> how to make one.
>
>
> On 10/07/2018 02:00, Guido van Rossum wrote:
>
>> Rationale
>> =
>>
>> Naming the result of an expression is an important part of programming,
>> allowing a descriptive name to be used in place of a longer expression,
>> and permitting reuse.  Currently, this feature is available only in
>> statement form, making it unavailable in list comprehensions and other
>> expression contexts.
>>
>

> I think the wording of the last sentence gives too much importance to list
> comprehensions (IMO influenced by the amount of discussion of the PEP that
> was related to list comprehensions, understandably since that was the case
> where the semantics were most debatable).  I would suggest
> "... making it unavailable in expression contexts."
> or maybe
> "... making it unavailable in expression contexts (including list
> comprehension)."
>

Hm, I don't think it's worth tweaking the text here. The PEP has some
choice things to say about comprehensions, and I don't mind calling them
out especially here. Also, when you need a temporary variable outside a
comprehension it's easy enough to rewrite the code a bit -- but for a
comprehension you'd have to refactor the whole comprehension away (into a
regular for-loop), which is a bit more effort.



> Another example illustrates that programmers sometimes do more work to
>> save an extra level of indentation::
>>
>> match1 = pattern1.match(data)
>> match2 = pattern2.match(data)
>> if match1:
>> return match1.group(1)
>> elif match2:
>> return match2.group(2)
>>
>> This code tries to match ``pattern2`` even if ``pattern1`` has a match
>> (in which case the match on ``pattern2`` is never used). The more
>> efficient rewrite would have been::
>>
>> match1 = pattern1.match(data)
>> if match1:
>> return match1.group(1)
>> else:
>> match2 = pattern2.match(data)
>> if match2:
>> return match2.group(2)
>>
> I suggest
> ... The more efficient rewrite would have been:
> match1 = pattern1.match(data)
> if match1:
> return match1.group(1)
> match2 = pattern2.match(data)
> if match2:
> return match2.group(2)
> (a more natural way to write it which avoids cascading indentation).
>

Hm, I think I might have simplified this a bit from the code I actually
found -- there might not have been a `return` in the original. I don't want
to break the `if...elif` pattern in the rewrite. I guess I'll rewrite it
using assignment to a variable instead of `return`.


> # Handle a matched regex
>> if (match := pattern.search(data)) is not None:
>> ...
>>
> I suggest
> # Handle a matched regex
> if (match := pattern.search(data)) is not None:
> # do something with match
> I think it is really important to make clear the benefit of the PEP here:
> that "match" is bound to a value and can be used subsequently.
>
> # A more explicit alternative to the 2-arg form of iter() invocation
>> while (value := read_next_item()) is not None:
>> ...
>>
> As the 2-arg form of iter() is not that well known, I suggest that the
> iter version is spelled out for contrast.  (Sorry, I can't quite work it
> what it would be.)
>

Hm, you have a point there. I was referring to

  for value in iter(read_next_item, None):
  ...

The example would be more convincing if there was an additional argument to
read_next_value(), since then the 2-arg iter() version would have required
a lambda. Maybe I shouldn't mention 2-arg iter here at all.


> # Share a subexpression between a comprehension filter clause and its
>> output
>> filtered_data = [y for x in data if (y := f(x)) is not None]
>>
> That's fine, but what about also having an example that illustrates,
> simply, the "permitting reuse" in an expression part of the Rationale, e.g.
> powers = [ (y := x+1), y**2, y**3, y**4 ]
> (I appreciate that this sort of overlaps with the section "Simplifying
> list comprehensions", but it seems to me to be such an important part of
> the Rationale that it should be illustrated here.)
>

I could add this (before the filtered_data example):

# Reuse a value that's expensive to compute
[y := f(x), y**2, y**3]



> Relative precedence of ``:=``
>> -
>>
>> The ``:=`` operator groups more tightly than a comma in all syntactic
>> positions where it is legal, but less tightly than all operators,
>> including ``or``, ``and`` and ``not``.
>>
> and presumably including "if" and "else", as in
> x := y if y else -1
> Might it be worth adding "if" and "else" to the list?
>

Good call, I'll add conditional expressions to the list.


> - Single assignment targets other than than a single ``NAME`` are
>>   not supported::
>>
>> # No equivalent
>>  

Re: [Python-Dev] Micro-benchmarks for function calls (PEP 576/579/580)

[INADA Naoki]

On Tue, Jul 10, 2018 at 7:23 AM Jeroen Demeyer  wrote:
>
> Here is an initial version of a micro-benchmark for C function calling:
>
> https://github.com/jdemeyer/callbench
>
> I don't have results yet, since I'm struggling to find the right options
> to "perf timeit" to get a stable result. If somebody knows how to do
> this, help is welcome.
>

I suggest `--duplicate 10` option.

While it is good for start point, please don't forget we need "application"
benchmark.

Even if some function call overhead can be 3x faster, if it takes only 3%
of application execution time, total execution time only 1% faster.
It's too small to accept PEP 580 complexity.

Realistic application benchmark demonstrates not only "how much faster",
but also "how important it is".

Regards,

>
> Jeroen.
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> https://mail.python.org/mailman/options/python-dev/songofacandy%40gmail.com



-- 
INADA Naoki  
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 572: Assignment Expressions -- intention to accept, near-final draft

[Terry Reedy]

On 7/9/2018 9:00 PM, Guido van Rossum wrote:
We strongly prefer feedback in the form of Pull Requests to the peps 
repo (the file is at 
https://github.com/python/peps/blob/master/pep-0572.rst 
).


I couple of people have said they don't know how to make pull requests 
against a PEP.  I believe the following works with the web editor.


1. Go to url above.
2. Click upper right pencil icon.  I don't know just who can do this.
3. Edit on the web page.  It might be easier to read the html and then 
use browser find to change anything seen.
4. Note that there are two scrollbars -- one for webpage and one for 
editing box.
5. At the bottom of the webpage, click 'Create a new branch for this 
commit and start a PR'.  This should unclick 'Commit directly to the 
master branch.'

6. Click Green [Propose file change] button.
7. I expect one will end up on the PR diff page.  If not, click 'files 
changed to get there.  Add comments explaining changes that need such.


The problem I see with this is that I don't know of any way to accept or 
reject the different proposed changes within the PR.  If there is, I 
would like to know how.


--
Terry Jan Reedy

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 572: Assignment Expressions -- intention to accept, near-final draft

[Jonathan Goble]

On Tue, Jul 10, 2018 at 2:00 AM Terry Reedy  wrote:

> On 7/9/2018 9:00 PM, Guido van Rossum wrote:
> > We strongly prefer feedback in the form of Pull Requests to the peps
> > repo (the file is at
> > https://github.com/python/peps/blob/master/pep-0572.rst
> > ).
>
> I couple of people have said they don't know how to make pull requests
> against a PEP.  I believe the following works with the web editor.
>
> 1. Go to url above.
> 2. Click upper right pencil icon.  I don't know just who can do this.
> 3. Edit on the web page.  It might be easier to read the html and then
> use browser find to change anything seen.
> 4. Note that there are two scrollbars -- one for webpage and one for
> editing box.
> 5. At the bottom of the webpage, click 'Create a new branch for this
> commit and start a PR'.  This should unclick 'Commit directly to the
> master branch.'
> 6. Click Green [Propose file change] button.
> 7. I expect one will end up on the PR diff page.  If not, click 'files
> changed to get there.  Add comments explaining changes that need such.
>

This is almost precisely how I, a newbie to contributing, fixed a typo in
this PEP tonight. At step 2, anyone who is logged in can click the pencil
icon; if you don't have write access to the repo, GitHub automatically
forks the repo and commits your change to a new branch within your fork,
eliminating step 5.

The problem I see with this is that I don't know of any way to accept or
> reject the different proposed changes within the PR.  If there is, I
> would like to know how.
>

I don't believe there is a way to merge part of a PR. The rejected changes
would have to be reverted with a new commit prior to merging.

-- 
> Terry Jan Reedy
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/jcgoble3%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com