Re: [Python-Dev] PEP 572: Assignment Expressions

[Greg Ewing]

Steven D'Aprano wrote:
"Not sure"? Given that you listed seven ways, how much more evidence do 
you need to conclude that it is simply wrong to say that Python has a 
single way to assign a value to a name?


Yes, but six of those are very specialised, and there's rarely
any doubt about when it's appropriate to use them.

The proposed :=, on the other hand, would overlap a lot with
the functionality of =. It's not a case of "Python already
has seven ways of assigning, so one more can't hurt."

--
Greg
___
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] [RELEASE] Python 2.7.15

[Hasan Diwan]

Congrats to all involved! -- H

On 30 April 2018 at 21:09, Benjamin Peterson  wrote:

> Greetings,
> I'm pleased to announce the immediate availability of Python 2.7.15, the
> latest bug fix release in the senescent Python 2.7 series.
>
> Source and binary downloads may be found on python.org:
>
>  https://www.python.org/downloads/release/python-2715/
>
> Bugs should be reported to https://bugs.python.org/
>
> The source tarball contains a complete changelog in the Misc/NEWS file.
> The only change since the release candidate is a fix for undefined C
> behavior that newer compilers (including GCC 8) have started to exploit.
>
> Users of the macOS binaries should note that all python.org macOS
> installers now ship with a builtin copy of OpenSSL. Additionally, there is
> a new additional installer variant for macOS 10.9+ that includes a built-in
> version of Tcl/Tk 8.6. See the installer README for more information.
>
> Happy May,
> Benjamin
> 2.7 release manager
> ___
> 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/
> hasan.diwan%40gmail.com
>



-- 
OpenPGP:
https://sks-keyservers.net/pks/lookup?op=get&search=0xFEBAD7FFD041BBA1
If you wish to request my time, please do so using
http://bit.ly/hd1ScheduleRequest.
Si vous voudrais faire connnaisance, allez a
http://bit.ly/hd1ScheduleRequest.

Sent
from my mobile device
Envoye de mon portable
___
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] [RELEASE] Python 2.7.15

[Benjamin Peterson]

Greetings,
I'm pleased to announce the immediate availability of Python 2.7.15, the latest 
bug fix release in the senescent Python 2.7 series.

Source and binary downloads may be found on python.org:

 https://www.python.org/downloads/release/python-2715/

Bugs should be reported to https://bugs.python.org/

The source tarball contains a complete changelog in the Misc/NEWS file. The 
only change since the release candidate is a fix for undefined C behavior that 
newer compilers (including GCC 8) have started to exploit.

Users of the macOS binaries should note that all python.org macOS installers 
now ship with a builtin copy of OpenSSL. Additionally, there is a new 
additional installer variant for macOS 10.9+ that includes a built-in version 
of Tcl/Tk 8.6. See the installer README for more information.

Happy May,
Benjamin
2.7 release manager
___
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: Usage of assignment expressions in C

[Tim Peters]

[Raymond Hettinger ]
> Thanks Antoine, this is an important point that I hope doesn't get lost.
> In a language with exceptions, assignment expressions are less needful.
> Also, the pattern of having of having mutating methods return None
> further limits the utility.

It doesn't diminish the utility one whit in cases where binding
expressions are helpful ;-)

What you're saying is that there are _fewer_ such opportunities in
Python than in C.  Which may or may not be true (depending on the code
you're working with).  If you believe it is true, fine, then that also
argues against that people will rush to abuse the feature (to the
extent that it's even plausibly useful less often, to that extent also
will there be less temptation to use it at all).

But then I only care about use cases at heart, and have presented
real-life examples wherein binding expressions read both better and
worse than what they're replacing.  I intend to limit myself to the
cases where they read better :-)  Which are most of the cases I even
considered, BTW - in the vast majority of cases in real code I'd use
them, they'd be replacing the annoyingly bare-bones yet somehow
repetitive anyway:

value = f()
if value;
doing something with value

with the still bare-bones but minimally repetitive:

if value := f():
doing something with value

For example, tons of functions I write and use return None or 0 or
False when they want to communicate "I have nothing useful to return
in this case - but since you expected that might happen, I'm not going
to annoy you with an exception".  That pattern isn't solely limited to
regexp search and match functions.

The "win" above is minor but frequent.  It adds up.

There are other cases where binding expressions really shine, but
they're much rarer in all the code I looked at (e.g., see the
uselessly ever-increasing indentation levels near the end of `copy()`
in the std library's copy.py).

In all, I expect I'd use them significantly more often than ternary
`if`, but far less often than augmented assignments.  If the PEP is
accepted, that's what all Pythoneers will be saying 5 years from now
;-)
___
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: Usage of assignment expressions in C

[Raymond Hettinger]

> On Apr 28, 2018, at 8:45 AM, Antoine Pitrou  wrote:
> 
>> I personally haven't written a lot of C, so have no personal experience,
>> but if this is at all a common approach among experienced C developers, it
>> tells us a lot.
> 
> I think it's a matter of taste and personal habit.  Some people will
> often do it, some less.  Note that C also has a tendency to make it
> more useful, because doesn't have exceptions, so functions need to
> (ab)use return values when they want to indicate an error.  When you're
> calling such functions (for example I/O functions), you routinely have
> to check for special values indicating an error, so it's common to see
> code such as:
> 
>  // Read up to n bytes from file descriptor
>  if ((bytes_read = read(fd, buf, n)) == -1) {
>  // Error occurred while reading, do something
>  }

Thanks Antoine, this is an important point that I hope doesn't get lost.
In a language with exceptions, assignment expressions are less needful.
Also, the pattern of having of having mutating methods return None
further limits the utility.


Raymond
___
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: A backward step in readability

[Raymond Hettinger]

> On Apr 30, 2018, at 9:37 AM, Steven D'Aprano  wrote:
> 
> On Mon, Apr 30, 2018 at 08:09:35AM +0100, Paddy McCarthy wrote:
> [...]
>> A PEP that can detract from readability; *readability*, a central
>> tenet of Python, should
>> be rejected, (on principle!), when such objections are treated so 
>> dismissively.
> 
> Unless you have an objective measurement of readability, that objection 
> is mere subjective personal preference, and not one that everyone agrees 
> with.

Sorry Steven, but that doesn't seem like it is being fair to Paddy.
Of course, readability can't be measured objectively with ruler
(that is a false standard).  However, readability is still a real issue
that affects us daily even though objective measurement aren't possible.

All of us who do code reviews make assessments of readability
on a daily basis even though we have no objective measures.
We know hard to read when we see it.

In this thread, several prominent and highly experienced devs
reported finding it difficult to parse some of the examples and
some mis-parsed the semantics of the examples.  It is an objective
fact that they reported readability issues.  That is of great concern
and shouldn't be blown off with a comment that readability,
"is a mere subjective personal preference".  At its heart, readability
is the number one concern in language design.

Also, there another area where it looks like valid concerns
are being dismissed out of hand.  Several respondents worried
that the proposed feature will lead to writing bad code.  
Their comments seem to have been swept under the table with
responses along the lines of "well any feature can be used badly,
so we don't care about that, some people will write bad code no
matter what we do".  While that is true to some extent, there remains 
a valid issue concerning the propensity for misuse.

ISTM the proposed feature relies on users showing a good deal
of self-restriaint and having a clear knowledge of boundary
between the "clear-win" cases (like the regex match object example)
and the puzzling cases (assignments being used in and-operator
and or-operator chains).  It also relies on people not making
hard to find mistakes (like mistyping := when == was intended).

There is a real difference between a feature that could be abused
versus a feature that has a propensity for being misused, being
mistyped, or being misread (all of which have occurred multiple
times in these threads).


> The "not readable" objection has been made, extremely vehemently, 
> against nearly all major syntax changes to Python:

I think that is a false recollection of history.  Comprehensions were
welcomed and highly desired.  Decorators were also highly sought
after -- there was only a question of the best possible syntax. 
The ternary operator was clamored for by an enormous number
of users (though there was little agreement on the best spelling).
Likewise, the case for augmented assignments was somewhat strong
(eliminating having to spell the assignment target twice).

Each of those proposals had their debates, but none of them 
had a bunch of core devs flat-out opposed like we do now.
It really isn't the same at all.

However, even if the history had been recalled correctly, it would
still be a logical fallacy to posit "in the past, people opposed
syntax changes that later proved to be popular, therefore we
should ignore all concerns being expressed today".  To me,
that seems like a rhetorical trick for dismissing a bunch of
thoughtful posts.

Adding this new syntax is a one-way trip -- we don't get to express
regrets later.   Accordingly, it would be nice if the various concerns
being presented were addressed directly rather than being
dismissed with a turn of phrase.  Nor should it matter whether
concerns were articulately expressed (being articulate isn't
always correlated with being right).


Raymond


___
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

[Chris Jerdonek]

On Thu, Apr 26, 2018 at 10:33 AM, Sven R. Kunze  wrote:
> On 25.04.2018 01:19, Steven D'Aprano wrote:
>>
>> Sorry, gcd(diff, n) is not the "perfect name", and I will tell you that
>> sometimes g is better. [...]
>
> We were talking about the real-world code snippet of Tim (as a justification
> of := ) and alternative rewritings of it without resorting to new syntax.

Apologies if this idea has already been discussed (I might have missed
the relevant email), but thinking back to Tim's earlier example--

if (diff := x - x_base) and (g := gcd(diff, n)) > 1:
return g

it occurs to me this could be implemented with current syntax using a
pattern like the following:

stashed = [None]

def stash(x):
stashed[0] = x
return x

if stash(x - x_base) and stash(gcd(stashed[0], n)) > 1:
return stashed[0]

There are many variations to this idea, obviously. For example, one
could allow passing a "name" to stash(), or combine stash / stashed
into a single, callable object that allows setting and reading from
its store. I wonder if one of them could be made into a worthwhile
pattern or API..

--Chris
___
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] Every Release Can Be a Mini "Python 4000", Within Reason (was (name := expression) doesn't fit the narrative of PEP 20)

[Terry Reedy]

On 4/30/2018 4:00 PM, Jeff Allen wrote:

They were not "statements", but "formulas" while '=' was assignment (sec 
8) *and* comparison (sec 10B). So conversely to our worry, they actually 
wanted users to think of assignment initially as a mathematical formula 
(page 2) in order to exploit the similarity to a familiar concept, 
albeit a=a+i makes no sense from this perspective.


When explaining iterative algorithms, such as Newton's method, 
mathematicians write things like a' = a+1 or a(sub i+1 or sub new) = 
f(a(sub i or sub old)) .  For computer, we drop the super/subscript.  Or 
one can write more circuitously,

anew = update(aold)
aold = anew
The abbreviations should be explained when teaching loops.

For proving that the body of a loop maintains a loop constant, one may 
reinstate the super- or sub-script.


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

[Steven D'Aprano]

On Mon, Apr 30, 2018 at 05:27:08PM -0700, Larry Hastings wrote:
> 
> On 04/30/2018 07:30 AM, Mark Shannon wrote:
> >Would Python be better with two subtly different assignment operators?
> >The answer of "no" seems self evident to me.
> 
> Maybe this has been covered in the thread earlier--if so, I missed it, 
> sorry.  But ISTM that Python already has multiple ways to perform an 
> assignment.
> 
> All these statements assign to x:
[snip SEVEN distinct binding operations]

> I remain -1 on 572, but I'm not sure it can genuinely be said that 
> Python only has one way to assign a value to a variable.

"Not sure"? Given that you listed seven ways, how much more evidence do 
you need to conclude that it is simply wrong to say that Python has a 
single way to assign a value to a name?

:-)


-- 
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] PEP 572: Assignment Expressions

[Larry Hastings]

On 04/30/2018 07:30 AM, Mark Shannon wrote:

Would Python be better with two subtly different assignment operators?
The answer of "no" seems self evident to me.


Maybe this has been covered in the thread earlier--if so, I missed it, 
sorry.  But ISTM that Python already has multiple ways to perform an 
assignment.


All these statements assign to x:

   x = y
   for x in y:
   with y as x:
   except Exception as x:

And, if you want to get *super* pedantic:

   import x
   def x(): ...
   class x: ...

I remain -1 on 572, but I'm not sure it can genuinely be said that 
Python only has one way to assign a value to a variable.



//arry/
___
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] Every Release Can Be a Mini "Python 4000", Within Reason (was (name := expression) doesn't fit the narrative of PEP 20)

[Jeff Allen]

On 30/04/2018 07:22, Greg Ewing wrote:

Jeff Allen wrote:
I speculate this all goes back to some pre-iteration version of 
FORmula TRANslation, where to its inventors '=' was definition and 
these really were "statements" in the normal sense of stating a truth.


Yeah, also the earliest FORTRAN didn't even *have* comparison
operators. A conditional branch was something like

I should have known that would turn out to be the most interesting part 
in my message. Not to take us further off topic, I'll just say thanks to 
Eitan's reply, I found this:

http://www.softwarepreservation.org/projects/FORTRAN/BackusEtAl-Preliminary%20Report-1954.pdf

They were not "statements", but "formulas" while '=' was assignment (sec 
8) *and* comparison (sec 10B). So conversely to our worry, they actually 
wanted users to think of assignment initially as a mathematical formula 
(page 2) in order to exploit the similarity to a familiar concept, 
albeit a=a+i makes no sense from this perspective.


Jeff Allen

___
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: A backward step in readability

[Paddy McCarthy]

On 30 April 2018 at 17:37, Steven D'Aprano  wrote:
>
> On Mon, Apr 30, 2018 at 08:09:35AM +0100, Paddy McCarthy wrote:
> [...]
> > A PEP that can detract from readability; *readability*, a central
> > tenet of Python, should
> > be rejected, (on principle!), when such objections are treated so 
> > dismissively.

> Unless you have an objective measurement of readability, that objection
> is mere subjective personal preference, and not one that everyone agrees
> with.

True, as is the dismissal from the PEP. It is the PEP, looking to
force change to
the language, to prove its point rather than dismiss statements of its
detractors.

>
> The "not readable" objection has been made, extremely vehemently,
> against nearly all major syntax changes to Python:

I don't count myself as usually against change. I applaud the move to Python 3,
I use all of the language features you mention at times; many in my Rosetta Code
task examples; but this change opens the door to a class of bug that will
take care to avoid and  which I remember cutting my C coding to get away from.

The PEP fails to adequately address the concerns of "us naysayers"

For example; if someone were to find out that "assignment expressions were
faster", then you would be hard pressed to stop their over-use.
As soon as someone assigns to a name and uses that same name in the one
expression, you need a better grasp of the order of expression evaluation to
read it. hat is best avoided, in my subjective, personal, view.


> --
> Steve

With respect, but in disagreement - Paddy.
___
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] [python-committers] IMPORTANT - final 3.7.0 beta cutoff!

[Victor Stinner]

Hi,

I modified the behaviour of the socketserver module: ThreadingMixIn
now waits until all threads complete and ForkingMixIn now waits until
all child processes complete

https://bugs.python.org/issue31233
https://bugs.python.org/issue31151

I was supposed to do something, like add an option to at least opt-in
for the old behaviour, but I didn't have the bandwidth to work on
these issues.

Python 3.7 may be shipped with the new behavior and no option to get
the old behaviour (stop immediately, don't wait for
threads/processes). Any volunteer to work on these issues?

Victor

2018-04-30 21:37 GMT+02:00 Ned Deily :
> Just a reminder that 3.7.0b4 is almost upon us. Please get your
> feature fixes, bug fixes, and documentation updates in before
> 2018-04-30 ~23:59 Anywhere on Earth (UTC-12:00). That's about 16
> hours from now.
>
> IMPORTANT: We are now in the final phase of 3.7.0. Tomorrow's 3.7.0b4
> is the final beta planned for 3.7.0. After tomorrow, the next planned
> release is the 3.7.0 release candidate, on 2018-05-21, for final
> testing. Our goal is to have no changes between the release candidate
> and final; after rc1, changes applied to the 3.7 branch will be
> released in 3.7.1. Between now and the rc1 cutoff, please
> double-check that there are no critical problems outstanding and that
> documentation for new features in 3.7 is complete (including NEWS and
> What's New items), and that 3.7 is getting exposure and tested with
> our various platorms and third-party distributions and applications.
> Also, during the time leading up to the release candidate, we will be
> completing the What's New in 3.7 document.
>
> As noted before, the ABI for 3.7.0 was frozen as of 3.7.0b3. You
> should now be treating the 3.7 branch as if it were already released
> and in maintenance mode. That means you should only push the kinds of
> changes that are appropriate for a maintenance release:
> non-ABI-changing bug and feature fixes and documentation updates. If
> you find a problem that requires an ABI-altering or other significant
> user-facing change (for example, something likely to introduce an
> incompatibility with existing users' code or require rebuilding of
> user extension modules), please make sure to set the b.p.o issue to
> "release blocker" priority and describe there why you feel the change
> is necessary. If you are reviewing PRs for 3.7 (and please do!), be
> on the lookout for and flag potential incompatibilities (we've all
> made them).
>
> Thanks again for all of your hard work towards making 3.7.0 yet
> another great release - coming to a website near you on 06-15!
>
> --Ned
>
> --
>   Ned Deily
>   n...@python.org -- []
>
> ___
> python-committers mailing list
> python-committ...@python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
___
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: A backward step in readability

[Tres Seaver]

On 04/30/2018 12:37 PM, Steven D'Aprano wrote:
> - comprehensions? not readable, easy to abuse, hard for beginners
>   to comprehend;

I still refer to them as "list incomprehensions" in my head, particularly
for those whic expand across line breaks.


Tres.
-- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   "Excellence by Design"http://palladion.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

[Python-Dev] IMPORTANT - final 3.7.0 beta cutoff!

[Ned Deily]

Just a reminder that 3.7.0b4 is almost upon us. Please get your
feature fixes, bug fixes, and documentation updates in before
2018-04-30 ~23:59 Anywhere on Earth (UTC-12:00). That's about 16
hours from now.

IMPORTANT: We are now in the final phase of 3.7.0. Tomorrow's 3.7.0b4
is the final beta planned for 3.7.0. After tomorrow, the next planned
release is the 3.7.0 release candidate, on 2018-05-21, for final
testing. Our goal is to have no changes between the release candidate
and final; after rc1, changes applied to the 3.7 branch will be
released in 3.7.1. Between now and the rc1 cutoff, please
double-check that there are no critical problems outstanding and that
documentation for new features in 3.7 is complete (including NEWS and
What's New items), and that 3.7 is getting exposure and tested with
our various platorms and third-party distributions and applications.
Also, during the time leading up to the release candidate, we will be
completing the What's New in 3.7 document.

As noted before, the ABI for 3.7.0 was frozen as of 3.7.0b3. You
should now be treating the 3.7 branch as if it were already released
and in maintenance mode. That means you should only push the kinds of
changes that are appropriate for a maintenance release:
non-ABI-changing bug and feature fixes and documentation updates. If
you find a problem that requires an ABI-altering or other significant
user-facing change (for example, something likely to introduce an
incompatibility with existing users' code or require rebuilding of
user extension modules), please make sure to set the b.p.o issue to
"release blocker" priority and describe there why you feel the change
is necessary. If you are reviewing PRs for 3.7 (and please do!), be
on the lookout for and flag potential incompatibilities (we've all
made them).

Thanks again for all of your hard work towards making 3.7.0 yet
another great release - coming to a website near you on 06-15!

--Ned

--
  Ned Deily
  n...@python.org -- []

___
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: A backward step in readability

[Guido van Rossum]

TBH I think the text of the PEP could be much improved -- for example it
should use motivating examples from real code, not artificial examples to
show edge cases of the semantics.

At this point I don't think that more people expressing an opinion one way
or another are going to make a difference. Nobody whose vote matters is
going to be convinced either way.

On Mon, Apr 30, 2018 at 9:53 AM, Paul Moore  wrote:

> On 30 April 2018 at 17:37, Steven D'Aprano  wrote:
> > On Mon, Apr 30, 2018 at 08:09:35AM +0100, Paddy McCarthy wrote:
> > [...]
> >> A PEP that can detract from readability; *readability*, a central
> >> tenet of Python, should
> >> be rejected, (on principle!), when such objections are treated so
> dismissively.
> >
> > Unless you have an objective measurement of readability, that objection
> > is mere subjective personal preference, and not one that everyone agrees
> > with. I for one think that used wisely, binding expressions will be
> > *more* readable than the alternatives. (Even though := is not my
> > preferred syntax.)
>
> On the other hand, the PEP doesn't do much to address the various
> claims of readability issues. Whether they are subjective or not,
> well-founded or not, the PEP does (in my view) come across as
> unnecessarily dismissive of the question of readability. I suspect
> that's largely due to Chris being extremely tired of having the same
> arguments over and over again, and I can understand that. However, I
> think it could be covered more completely - the remainder of your post
> is exactly the sort of response that would be useful to have recorded.
>
> But one way or another, I think people will vote on the PEP based on
> their (subjective) views, and so readability will get factored into
> the overall response, one way or another. To what extent that response
> affects Guido's final decision (I can't see him delegating on this
> one!) remains to be seen, and honestly, I'm willing to trust Guido's
> intuition.
>
> 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/
> guido%40python.org
>



-- 
--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] Superseding PEPs (was Re: PEP 394: Allow the `python` command to not be installed (and other minor edits))

[Barry Warsaw]

On Apr 30, 2018, at 06:36, Nick Coghlan  wrote:

> Instead of editing old PEPs, would it make sense to write a new one
> which replaces the old one?

As a general rule, at least the way I think about it, Informational PEPs can 
mostly be updated inline, evolving with new insights as we go along.  As Nick 
points out, this gives folks a consistent place to read our current 
recommendations and guidelines.  They’re informational so almost by definition 
contemporaneous.

Standards Track PEPs on the other hand shouldn’t be changed once finalized, 
except around the margins, e.g. typos, updated URLs, that kind of thing.  These 
PEPs should capture the discussion and design at the time that the feature is 
solidified and lands; they do *not* serve as latest up-to-date documentation on 
the feature.  If the feature changes or becomes obsolete in future versions of 
Python, a new PEP should be written to supersede the old PEP.  We even have an 
official `Superseded` Status value, and a `Superseded-By` header.

-Barry



signature.asc
Description: Message signed with OpenPGP
___
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

[Yury Selivanov]

On Mon, Apr 30, 2018 at 1:03 PM Chris Angelico  wrote:
> > That's a weird argument, Chris :-)
> >
> > If `f(x)` has no meaningful name, then *what* is the result of the
> > comprehension?  Perhaps some meaningless data? ;)

> f(x) might have side effects. Can you give a meaningful name to the
> trivial helper function?

I don't understand your question. How is `f(x)` having side effects or not
having them is relevant to the discussion? Does ':=' work only with pure
functions?

> Not every trivial helper can actually have a
> name that saves people from having to read the body of the function.

I don't understand this argument either, sorry.

> >> We've been over this argument plenty, and I'm not going to rehash it.
> >
> > Hand-waving the question the way you do simply alienates more core devs
to
> > the PEP.  And PEP 572 hand-waves a lot of questions and concerns.
Asking
> > people to dig for answers in 700+ emails about the PEP is a bit too
much,
> > don't you agree?
> >
> > I think it's PEP's author responsibility to address questions right in
> > their PEP.

> If I answer every question, I make that number into 800+, then 900+,
> then 1000+. If I don't, I'm alienating everyone by being dismissive.
> If every question is answered in the PEP, the document itself becomes
> so long that nobody reads it. Damned if I do, damned if I don't. Got
> any alternative suggestions?

IMO, big part of why that we have 100s of emails is because people are very
concerned with readability.  The PEP just hand-waives the question
entirely, instead of listing good and realistic examples of code, as well
as listing bad examples.  So that, you know, people could compare them and
understand *both* pros and cons.

Instead we have a few very questionable examples in the PEP that most
people don't like at all. Moreover, half of the PEP is devoted to fixing
comprehensions scoping, which is almost an orthogonal problem to adding a
new syntax.

So my suggestion remains to continue working on the PEP, improving it and
making it more comprehensive. You're free to ignore this advice, but don't
be surprised that you see new emails about what ':=' does to code
readability (with the same arguments).  PEP 572 proponents answering to
every email with the same dismissive template doesn't help either.

> >> > def do_things(fire_missiles=False, plant_flowers=False): ...
> >> > do_things(plant_flowers:=True) # whoops!
> >
> >> If you want your API to be keyword-only, make it keyword-only. If you
> >
> > Another hand-waving.  Should we deprecate passing arguments by name if
> > their corresponding parameters are not keyword-only?
> >
> > Mark shows another potential confusion between '=' and ':=' that people
> > will have, and it's an interesting one.

> A very rare one compared to the confusions that we already have with
> '=' and '=='. And this is another argument that we've been over,
> multiple times.

How do you know if it's rare or not?  '=' is used to assign, ':=' is used
to assign, '==' is used to compare.  I can easily imagine people being
confused why '=' works for setting an argument, and why ':=' doesn't.
Let's agree to disagree on this one :)

> > Strange. I see people who struggle to format their code properly or use
the
> > language properly *every day* ;)

> And do they blame the language for having a comparison operator that
> is so easy to type? Or do they fix their bugs and move on? Again,
> language syntax is not the solution to bugs.

I'm not sure how to correlate what I was saying with your reply, sorry.

Anyways, Chris, I think that the PEP hand-waves a lot of questions and
doesn't have a comprehensive analysis of how the PEP will affect syntax and
readability. It's up to you to consider taking my advice or not. I'll try
to (again) restrain myself posting about this topic.

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

[Chris Angelico]

On Tue, May 1, 2018 at 2:53 AM, Yury Selivanov  wrote:
> On Mon, Apr 30, 2018 at 11:32 AM Chris Angelico  wrote:
>
>> On Tue, May 1, 2018 at 12:30 AM, Mark Shannon  wrote:
>> > List comprehensions
>> > ---
>> > The PEP uses the term "simplifying" when it really means "shortening".
>> > One example is
>> > stuff = [[y := f(x), x/y] for x in range(5)]
>> > as a simplification of
>> > stuff = [(lambda y: [y,x/y])(f(x)) for x in range(5)]
>
>> Now try to craft the equivalent that captures the condition in an if:
>
>> results = [(x, y, x/y) for x in input_data if (y := f(x)) > 0]
>
> Easy:
>
>results = []
>for x in input_data:
>   y = f(x)
>   if y > 0:
> results.append((x, y, x/y))
>
> Longer, but way more readable and debuggable if you're into that.  This has
> worked for us many years and only a handful of people complained about
> this.
>
> OTOH, I see plenty of people complaining that nested list comprehensions
> are hard to read.  In my own code reviews I ask people to avoid using
> complex comprehensions all the time.
>
>> Do that one with a lambda function.
>
> Why would I?  Is using lambda functions mandatory?

The claim was that assignment expressions were nothing more than a
shorthand for lambda functions. You can't rewrite my example with a
lambda function, ergo assignment expressions are not a shorthand for
lambda functions.

Do you agree?

>> > IMO, the "simplest" form of the above is the named helper function.
>> >
>> > def meaningful_name(x):
>> > t = f(x)
>> > return t, x/t
>> >
>> > [meaningful_name(i) for i in range(5)]
>> >
>> > Is longer, but much simpler to understand.
>
>> Okay, but what if there is no meaningful name? It's easy to say "pick
>> a meaningful name". It's much harder to come up with an actual name
>> that is sufficiently meaningful that a reader need not go look at the
>> definition of the function.
>
> That's a weird argument, Chris :-)
>
> If `f(x)` has no meaningful name, then *what* is the result of the
> comprehension?  Perhaps some meaningless data? ;)

f(x) might have side effects. Can you give a meaningful name to the
trivial helper function? Not every trivial helper can actually have a
name that saves people from having to read the body of the function.

>> > I am also concerned that the ability to put assignments anywhere
>> > allows weirdnesses like these:
>> >
>> > try:
>> > ...
>> > except (x := Exception) as x:
>> > ...
>> >
>> > with (x: = open(...)) as x:
>> > ...
>
>> We've been over this argument plenty, and I'm not going to rehash it.
>
> Hand-waving the question the way you do simply alienates more core devs to
> the PEP.  And PEP 572 hand-waves a lot of questions and concerns.  Asking
> people to dig for answers in 700+ emails about the PEP is a bit too much,
> don't you agree?
>
> I think it's PEP's author responsibility to address questions right in
> their PEP.

If I answer every question, I make that number into 800+, then 900+,
then 1000+. If I don't, I'm alienating everyone by being dismissive.
If every question is answered in the PEP, the document itself becomes
so long that nobody reads it. Damned if I do, damned if I don't. Got
any alternative suggestions?

>> > def do_things(fire_missiles=False, plant_flowers=False): ...
>> > do_things(plant_flowers:=True) # whoops!
>
>> If you want your API to be keyword-only, make it keyword-only. If you
>
> Another hand-waving.  Should we deprecate passing arguments by name if
> their corresponding parameters are not keyword-only?
>
> Mark shows another potential confusion between '=' and ':=' that people
> will have, and it's an interesting one.

A very rare one compared to the confusions that we already have with
'=' and '=='. And this is another argument that we've been over,
multiple times.

>> want a linter that recognizes unused variables, get a linter that
>> recognizes unused variables.
>
> Many want Python to be readable and writeable without linters.

And it will be. But there are going to be certain types of bug that
you won't catch as quickly. You can't use language syntax to catch
every bug. That's provably impossible.

>> Neither of these is the fault of the
>> proposed syntax; you could just as easily write this:
>
>> do_things(plant_flowers==True)
>
>> but we don't see myriad reports of people typing too many characters
>> and blaming the language.
>
> Strange. I see people who struggle to format their code properly or use the
> language properly *every day* ;)

And do they blame the language for having a comparison operator that
is so easy to type? Or do they fix their bugs and move on? Again,
language syntax is not the solution to bugs.

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] PEP 572: Assignment Expressions

[Yury Selivanov]

On Mon, Apr 30, 2018 at 11:32 AM Chris Angelico  wrote:

> On Tue, May 1, 2018 at 12:30 AM, Mark Shannon  wrote:
> > List comprehensions
> > ---
> > The PEP uses the term "simplifying" when it really means "shortening".
> > One example is
> > stuff = [[y := f(x), x/y] for x in range(5)]
> > as a simplification of
> > stuff = [(lambda y: [y,x/y])(f(x)) for x in range(5)]

> Now try to craft the equivalent that captures the condition in an if:

> results = [(x, y, x/y) for x in input_data if (y := f(x)) > 0]

Easy:

   results = []
   for x in input_data:
  y = f(x)
  if y > 0:
results.append((x, y, x/y))

Longer, but way more readable and debuggable if you're into that.  This has
worked for us many years and only a handful of people complained about
this.

OTOH, I see plenty of people complaining that nested list comprehensions
are hard to read.  In my own code reviews I ask people to avoid using
complex comprehensions all the time.

> Do that one with a lambda function.

Why would I?  Is using lambda functions mandatory?


> > IMO, the "simplest" form of the above is the named helper function.
> >
> > def meaningful_name(x):
> > t = f(x)
> > return t, x/t
> >
> > [meaningful_name(i) for i in range(5)]
> >
> > Is longer, but much simpler to understand.

> Okay, but what if there is no meaningful name? It's easy to say "pick
> a meaningful name". It's much harder to come up with an actual name
> that is sufficiently meaningful that a reader need not go look at the
> definition of the function.

That's a weird argument, Chris :-)

If `f(x)` has no meaningful name, then *what* is the result of the
comprehension?  Perhaps some meaningless data? ;)


> > I am also concerned that the ability to put assignments anywhere
> > allows weirdnesses like these:
> >
> > try:
> > ...
> > except (x := Exception) as x:
> > ...
> >
> > with (x: = open(...)) as x:
> > ...

> We've been over this argument plenty, and I'm not going to rehash it.

Hand-waving the question the way you do simply alienates more core devs to
the PEP.  And PEP 572 hand-waves a lot of questions and concerns.  Asking
people to dig for answers in 700+ emails about the PEP is a bit too much,
don't you agree?

I think it's PEP's author responsibility to address questions right in
their PEP.


> > def do_things(fire_missiles=False, plant_flowers=False): ...
> > do_things(plant_flowers:=True) # whoops!

> If you want your API to be keyword-only, make it keyword-only. If you

Another hand-waving.  Should we deprecate passing arguments by name if
their corresponding parameters are not keyword-only?

Mark shows another potential confusion between '=' and ':=' that people
will have, and it's an interesting one.

> want a linter that recognizes unused variables, get a linter that
> recognizes unused variables.

Many want Python to be readable and writeable without linters.

> Neither of these is the fault of the
> proposed syntax; you could just as easily write this:

> do_things(plant_flowers==True)

> but we don't see myriad reports of people typing too many characters
> and blaming the language.

Strange. I see people who struggle to format their code properly or use the
language properly *every day* ;)

Yury
___
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: A backward step in readability

[Paul Moore]

On 30 April 2018 at 17:37, Steven D'Aprano  wrote:
> On Mon, Apr 30, 2018 at 08:09:35AM +0100, Paddy McCarthy wrote:
> [...]
>> A PEP that can detract from readability; *readability*, a central
>> tenet of Python, should
>> be rejected, (on principle!), when such objections are treated so 
>> dismissively.
>
> Unless you have an objective measurement of readability, that objection
> is mere subjective personal preference, and not one that everyone agrees
> with. I for one think that used wisely, binding expressions will be
> *more* readable than the alternatives. (Even though := is not my
> preferred syntax.)

On the other hand, the PEP doesn't do much to address the various
claims of readability issues. Whether they are subjective or not,
well-founded or not, the PEP does (in my view) come across as
unnecessarily dismissive of the question of readability. I suspect
that's largely due to Chris being extremely tired of having the same
arguments over and over again, and I can understand that. However, I
think it could be covered more completely - the remainder of your post
is exactly the sort of response that would be useful to have recorded.

But one way or another, I think people will vote on the PEP based on
their (subjective) views, and so readability will get factored into
the overall response, one way or another. To what extent that response
affects Guido's final decision (I can't see him delegating on this
one!) remains to be seen, and honestly, I'm willing to trust Guido's
intuition.

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] PEP 572: A backward step in readability

[Steven D'Aprano]

On Mon, Apr 30, 2018 at 08:09:35AM +0100, Paddy McCarthy wrote:
[...]
> A PEP that can detract from readability; *readability*, a central
> tenet of Python, should
> be rejected, (on principle!), when such objections are treated so 
> dismissively.

Unless you have an objective measurement of readability, that objection 
is mere subjective personal preference, and not one that everyone agrees 
with. I for one think that used wisely, binding expressions will be 
*more* readable than the alternatives. (Even though := is not my 
preferred syntax.)

The "not readable" objection has been made, extremely vehemently, 
against nearly all major syntax changes to Python:

- comprehensions? not readable, easy to abuse, hard for beginners
  to comprehend;

- decorators? not readable, looks like Perl with the arbitrary
  use of @ symbol, hard to understand;

- ternary if operator? not readable, doesn't look enough like C,
  weird order;

- augmented assignments += etc -- not readable, too terse, requires
  the reader to be familiar with C.

I was guilty of making that last one. And if I had been around for the 
debate over decorators, I probably would have hated them too. But all 
four additions to the syntax have been *great* for the language, despite 
the nay-sayers.

I still know people with many years experience in Python who say they 
don't get comprehensions, and of course it is true that they are hard 
for beginners to get. But the advantages from comprehensions is 
immeasurably greater than the disadvantages.

Will this PEP be like comprehensions or decorators, and completely 
change the way we write Python code (for the better)? I doubt it. But I 
expect it will be like augmented assignment and the ternary if: it will 
make certain kinds of code more pleasurable to write *and read*, and 
when it doesn't, people won't use it.


-- 
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] PEP 575: Unifying function/method classes

[Jeroen Demeyer]

On 2018-04-30 15:38, Mark Shannon wrote:

While a unified *interface* makes sense, a unified class hierarchy and
implementation, IMO, do not.


The main reason for the common base class is performance: in the 
bytecode interpreter, when we call an object, CPython currently has a 
special case for calling Python functions, a special case for calling 
methods, a special case for calling method descriptors, a special case 
for calling built-in functions.


By introducing a common base class, we reduce the number of special 
cases. Second, we allow using this fast path for custom classes. With 
PEP 575, it is possible to create new classes with the same __call__ 
performance as the current built-in function class.



Bound-methods may be callables, but they are not functions, they are a
pair of a function and a "self" object.


From the Python language point of view, that may be true but that's not 
how you want to implement methods. When I write a method in C, I want 
that it can be called either as unbound method or as bound method: the C 
code shouldn't see the difference between the calls X.foo(obj) or 
obj.foo(). And you want both calls to be equally fast, so you don't want 
that the bound method just wraps the unbound method. For this reason, it 
makes sense to unify functions and methods.



IMO, there are so many versions of "function" and "bound-method", that a
unified class hierarchy and the resulting restriction to the
implementation will make implementing a unified interface harder, not
easier.


PEP 575 does not add any restrictions: I never claimed that all 
callables should inherit from base_function. Regardless, why would the 
common base class add restrictions? You can still add attributes and 
customize whatever you want in subclasses.



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] PEP 572: Assignment Expressions

[Antoine Pitrou]

Le 30/04/2018 à 17:30, Chris Angelico a écrit :



def do_things(fire_missiles=False, plant_flowers=False): ...
do_things(plant_flowers:=True) # whoops!


If you want your API to be keyword-only, make it keyword-only. If you
want a linter that recognizes unused variables, get a linter that
recognizes unused variables. Neither of these is the fault of the
proposed syntax; you could just as easily write this:

do_things(plant_flowers==True)


Unless you have a `plant_flowers` variable already defined, this will 
raise a NameError, not plant a silent bug.


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

[Python-Dev] PEP 572: A backward step in readability

[Paddy McCarthy]

The PEP s section on Frequently raised objections includes:

(https://www.python.org/dev/peps/pep-0572/#this-could-be-used-to-create-ugly-code)

> This could be used to create ugly code!
>
> So can anything else. This is a tool, and it is up to the programmer to use 
> it where
> it makes sense, and not use it where superior constructs can be used.

The above is so dismissive of a very real problem.

* Python makes syntax decisions to make it easier to read.
* One of the first, and enduring ones was "No  assignment within expressions".
* I had both seen, and debugged problems in the C-language caused by assignment
  expressions; and was glad to be rid of them in Python.

Assignment within expressions was, I think,  difficult to *teach* in
C. And will become
something error-prone to *learn* in Python.

The Python community has grown over the decades, and we have attracted community
members who want to help  and are motivated, but Python is not a
tick-list of features.

A PEP that can detract from readability; *readability*, a central
tenet of Python, should
be rejected, (on principle!), when such objections are treated so dismissively.
___
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

[Chris Angelico]

On Tue, May 1, 2018 at 12:30 AM, Mark Shannon  wrote:
> List comprehensions
> ---
> The PEP uses the term "simplifying" when it really means "shortening".
> One example is
> stuff = [[y := f(x), x/y] for x in range(5)]
> as a simplification of
> stuff = [(lambda y: [y,x/y])(f(x)) for x in range(5)]

Now try to craft the equivalent that captures the condition in an if:

results = [(x, y, x/y) for x in input_data if (y := f(x)) > 0]

Do that one with a lambda function.

> IMO, the "simplest" form of the above is the named helper function.
>
> def meaningful_name(x):
> t = f(x)
> return t, x/t
>
> [meaningful_name(i) for i in range(5)]
>
> Is longer, but much simpler to understand.

Okay, but what if there is no meaningful name? It's easy to say "pick
a meaningful name". It's much harder to come up with an actual name
that is sufficiently meaningful that a reader need not go look at the
definition of the function.

> I am also concerned that the ability to put assignments anywhere
> allows weirdnesses like these:
>
> try:
> ...
> except (x := Exception) as x:
> ...
>
> with (x: = open(...)) as x:
> ...

We've been over this argument plenty, and I'm not going to rehash it.

> def do_things(fire_missiles=False, plant_flowers=False): ...
> do_things(plant_flowers:=True) # whoops!

If you want your API to be keyword-only, make it keyword-only. If you
want a linter that recognizes unused variables, get a linter that
recognizes unused variables. Neither of these is the fault of the
proposed syntax; you could just as easily write this:

do_things(plant_flowers==True)

but we don't see myriad reports of people typing too many characters
and blaming the language.

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] PEP 572: Assignment Expressions

[Mark Shannon]

Hi,

On 17/04/18 08:46, Chris Angelico wrote:

Having survived four rounds in the boxing ring at python-ideas, PEP
572 is now ready to enter the arena of python-dev. 


I'm very strongly opposed to this PEP.

Would Python be better with two subtly different assignment operators?
The answer of "no" seems self evident to me.

Do we need an assignment expression at all (regardless of the chosen 
operator)? I think we do not.

Assignment is clear at the moment largely because of the context;
it can only occur at the statement level.
Consequently, assignment and keyword arguments are never confused
despite have the same form `name = expr`

List comprehensions
---
The PEP uses the term "simplifying" when it really means "shortening".
One example is
stuff = [[y := f(x), x/y] for x in range(5)]
as a simplification of
stuff = [(lambda y: [y,x/y])(f(x)) for x in range(5)]

IMO, the "simplest" form of the above is the named helper function.

def meaningful_name(x):
t = f(x)
return t, x/t

[meaningful_name(i) for i in range(5)]

Is longer, but much simpler to understand.



I am also concerned that the ability to put assignments anywhere
allows weirdnesses like these:

try:
...
except (x := Exception) as x:
...

with (x: = open(...)) as x:
...

def do_things(fire_missiles=False, plant_flowers=False): ...
do_things(plant_flowers:=True) # whoops!


It is easy to say "don't do that", but why allow it in the first place?

Cheers,
Mark.
___
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 575: Unifying function/method classes

[Nick Coghlan]

On 30 April 2018 at 23:38, Mark Shannon  wrote:

>
> On 12/04/18 17:12, Jeroen Demeyer wrote:
>
>> Dear Python developers,
>>
>> I would like to request a review of PEP 575, which is about changing the
>> classes used for built-in functions and Python functions and methods. The
>> text of the PEP can be found at
>>
>
>
> The motivation of PEP 575 is to allow introspection of built-in functions
> and to allow functions implemented in Python to be re-implemented in C.
>
> These are excellent goals.
>

That summary misses the 3rd goal, which is the one that answers your other
questions: to allow 3rd party extension modules access to the hot paths in
CPython that are currently restricted to true built-in and Python native
functions (without making those hot paths measurably slower).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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 575: Unifying function/method classes

[Mark Shannon]

On 12/04/18 17:12, Jeroen Demeyer wrote:

Dear Python developers,

I would like to request a review of PEP 575, which is about changing the 
classes used for built-in functions and Python functions and methods. 
The text of the PEP can be found at



The motivation of PEP 575 is to allow introspection of built-in 
functions and to allow functions implemented in Python to be 
re-implemented in C.


These are excellent goals.

The PEP then elaborates a complex class hierarchy, and various 
extensions to the C API.

This adds a considerable maintainance burden and restricts future
changes and optimisations to CPython.

While a unified *interface* makes sense, a unified class hierarchy and 
implementation, IMO, do not.


The hierarchy also seems to force classes that are dissimilar to share a 
common base-class.
Bound-methods may be callables, but they are not functions, they are a 
pair of a function and a "self" object.


As the PEP points out, Cython functions are able to mimic Python 
functions, why not do the same for CPython builtin-functions?


As an aside, rather than unifying the classes of all non-class 
callables, CPython's builtin-function class could be split in two. 
Currently it is both a bound-method and a function.

The name 'builtin_function_or_method' is a give away :)

Consider the most common "function" and "method" classes:

>>> class C:
...def f(self): pass

# "functions"

>>> type(C.f)

>>> type(len)

>>> type(list.append)

>>> type(int.__add__)


# "bound-methods"

>>> type(C().f)

>>> type([].append)

>>> type(1 .__add__)


IMO, there are so many versions of "function" and "bound-method", that a 
unified class hierarchy and the resulting restriction to the 
implementation will make implementing a unified interface harder, not 
easier.


For "functions", all that is needed is to specify an interface, say a 
single property "__signature__".
Then all that a class that wants to be a "function" need do is have a 
"__signature__" property and be callable.


For "bound-methods", we should reuse the interface of 'method';
two properties, "__func__" and "__self__".


Cheers,
Mark.

___
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 394: Allow the `python` command to not be installed (and other minor edits)

[Nick Coghlan]

On 30 April 2018 at 18:11, Victor Stinner  wrote:

> 2018-04-27 17:37 GMT+02:00 Petr Viktorin :
> > (...)
> > - The paragraph about the anticipated future where python points to
> Python 3
> > is removed.
>
> Instead of editing old PEPs, would it make sense to write a new one
> which replaces the old one?
>
> The PEP 394 has been written in 2011 and accepted in 2012. Editing an
> accepted PEP makes it harder to dig into the history of PEPs.
>
> I know that the PEP 8 is updated regularly, so it's not a requirement,
> just a proposal for the special PEP 394.
>

We edit PEP 394 in place for the same reason we edit PEP 8 in place: so
people have a consistent place to get our current recommendations.

It isn't like a packaging interoperability spec or the Python language &
library specs, where folks regularly need to know what changed between
particular revisions.

If folks really want to know how the recommendations have changed over
time, then browsing
https://github.com/python/peps/commits/master/pep-0394.txt isn't overly
difficult.

(That said, I also wouldn't be opposed to adding an inline change log to
the PEP, since it helps highlights the cases where the recommendations
*have* changed, which can be helpful for folks that were already familiar
with the older versions)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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 394: Allow the `python` command to not be installed (and other minor edits)

[Victor Stinner]

2018-04-27 17:37 GMT+02:00 Petr Viktorin :
> (...)
> - The paragraph about the anticipated future where python points to Python 3
> is removed.

Instead of editing old PEPs, would it make sense to write a new one
which replaces the old one?

The PEP 394 has been written in 2011 and accepted in 2012. Editing an
accepted PEP makes it harder to dig into the history of PEPs.

I know that the PEP 8 is updated regularly, so it's not a requirement,
just a proposal for the special PEP 394.

Victor
___
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: Usage of assignment expressions in C

[Victor Stinner]

2018-04-28 17:45 GMT+02:00 Antoine Pitrou :
>   // Read up to n bytes from file descriptor
>   if ((bytes_read = read(fd, buf, n)) == -1) {
>   // Error occurred while reading, do something
>   }

About C, there is a popular coding style (not used by our PEP 7) for comparison:

   if (-1 == n) ...

The advantage is to prevent typo mistakes because "-1 = n" is a syntax error.

Victor
___
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] Bugs Migration to OpenShift

[Victor Stinner]

Does it mean that the final switch will happen during the sprints?
Would it be possible to do it before or after? If bugs.python.org
doesn't work during the sprint, it will be much harder to contribute
to CPython during the sprints.

(If I misunderstood, ignore my message :-))

Victor

2018-04-29 19:07 GMT+02:00 Mark Mangoba :
> Hi All,
>
> We’re planning to finish up the bugs.python.org migration to Red Hat
> OpenShift by May 14th (US Pycon Sprints).  For the most part
> everything will stay same, with the exception of cleaning up some old
> URL’s and redirects from the previous hosting provider:  Upfront
> Software.
>
> We will post a more concrete timeline here by May 1st, but wanted to
> share this exciting news to move bugs.python.org into a more stable
> and optimal state.
>
> Thank you all for your patience and feedback.  A special thanks to
> Maciej Szulik and Red Hat for helping the PSF with this project.
>
> Best regards,
> Mark
>
> --
> Mark Mangoba | PSF IT Manager | Python Software Foundation |
> mmang...@python.org | python.org | Infrastructure Staff:
> infrastructure-st...@python.org | GPG: 2DE4 D92B 739C 649B EBB8 CCF6
> DC05 E024 5F4C A0D1
> ___
> 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/vstinner%40redhat.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] Every Release Can Be a Mini "Python 4000", Within Reason (was (name := expression) doesn't fit the narrative of PEP 20)

[Terry Reedy]

On 4/29/2018 11:51 PM, Guido van Rossum wrote:
On Sun, Apr 29, 2018 at 10:45 AM, Eitan Adler > wrote:


On 29 April 2018 at 01:34, Jeff Allen mailto:ja...@farowl.co.uk>> wrote:
> On 27/04/2018 08:38, Greg Ewing wrote:

> I speculate this all goes back to some pre-iteration version of FORmula
> TRANslation, where to its inventors '=' was definition and these really 
were
> "statements" in the normal sense of stating a truth.

https://www.hillelwayne.com/post/equals-as-assignment/



That blog post was brought up before in this discussion (probably on 
python-ideas). I have my doubts about whether it accurately represents 
the historic truth though.


It is woefully incomplete in omitting the common usage of = to mean 
'equals' both as statement (comparison) and command (assignment) in both 
English and math.  I don't have any math books that I know of that 
predate computers, but I suspect the usage is not new.


The pre-C computer language history has a gaping hole: BASIC, which uses 
= for both assignment and comparison, was released May 1, 1964.  I don't 
believe the syntax allowed any ambiguity as to the meaning of each 
occurrence.  To me, it is the use of anything else that needs explaining.


--
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] (Looking for) A Retrospective on the Move to Python 3

[Victor Stinner]

2018-04-28 3:33 GMT+02:00 Greg Ewing :
> Victor Stinner wrote:
>>
>> In my opinion, the largest failure of Python 3 is that we failed to
>> provide a smooth and *slow* transition from Python 2 and Python 3.
>
> Although for some things, such as handling of non-ascii text, it's
> hard to see how a smooth transition *could* have been achieved.
> Is it a failure if we don't succeed in doing the impossible?

Technically, it is easy to add an option to Python 2 to raise an
exception on str+unicode and str < unicode.

You can imagine the same option or a different one to really get the
bytes type of Python 3 (b'abc'[0] returns 97).

Such option would ease a lot to port code to Python 3, since you only
have to care of bytes vs Unicode issue. You don't have to worry about
the long list of other Python 3 changes (like the new stdlib
names...).

Note: Python 3 Unicode is stricter in other ways, like UTF-8 reject
lone surrogates. But I don't think that it matters for most users, and
technically it would also be possible to add an option to Python 2 to
get the new behaviour.

Moreover, Python 2 *already* has an option to switch to the new division mode:

$ python2 -Q new -c 'print(1/2)'
0.5

I'm proposing that a backward incompatible change must always be
prepared in the previous release.

Victor
___
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