Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

[Steven D'Aprano]

On Fri, Jun 22, 2018 at 09:08:37PM -0700, Chris Barker wrote:

> > So if you absolutely need to teach it to a beginner, it
> > shouldn't be difficult once they understand the difference between an
> > expression and a statement.
> >
> 
> probably not, though that's a distinction that's mostly academic in the
> early stages of learning,

I don't think so.

People do try to use assignment in expressions, even if only by mistake 
writing = when they meant == and need to distinguish between them. In 
Python 2, the most common clash between statements and expressions was 
print, but at least that's gone.

https://www.quora.com/Whats-the-difference-between-a-statement-and-an-expression-in-Python-Why-is-print-%E2%80%98hi%E2%80%99-a-statement-while-other-functions-are-expressions

https://stackoverflow.com/questions/4728073/what-is-the-difference-between-an-expression-and-a-statement-in-python

https://stackoverflow.com/questions/43435850/what-is-the-difference-between-a-statement-and-a-function-in-python

Even without assignment expressions, people still need to know why they 
can't write "if mo = re.match(pattern, text)". 


> again, not a huge deal, just a little bit more complexity

Every new feature is added complexity.


-- 
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] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

[Chris Barker via Python-Dev]

On Fri, Jun 22, 2018 at 7:23 PM, Steven D'Aprano 
wrote:

> > But once it becomes a more common idiom, students will see it in the wild
> > pretty early in their path to learning python. So we'll need to start
> > introducing it earlier than later.
>
> Students see many features early in their path. I've had people still
> struggling with writing functions ask about metaclasses. People
> will see async code everywhere. We don't have to teach *everything* at
> once.
>

These are not similar at all -- if you want similar examples, I"d say
comprehensions, and lambda, both of which I DO introduce fairly early

While newbies will *ask* about metaclasses, it's probably because they read
about them somewhere, not because someone actually used a metaclass in a
simple script or answer to a common question on SO.

As for async, you are either doing async or not -- you can't even run an
async def function without an event loop -- so again, it won't show up in
real code newbies need to understand (at least until async becomes common
practice with python...)

-CHB

 So if you absolutely need to teach it to a beginner, it
> shouldn't be difficult once they understand the difference between an
> expression and a statement.
>

probably not, though that's a distinction that's mostly academic in the
early stages of learning, it may become more critical now...

again, not a huge deal, just a little bit more complexity

-CHB

-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
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] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

[Chris Angelico]

On Sat, Jun 23, 2018 at 1:48 PM, Steven D'Aprano  wrote:
> I can't say I've done a broad survey, but the third-party documentation
> I've read on comprehensions typically glosses over the scoping issues
> without mentioning them. To the extent that scoping is even hinted at,
> comprehensions are treated as expressions which are exactly equivalent
> to re-writing them as a for-loop in the current scope.

Even first-party documentation elides that distinction. The same
inaccurate-but-simple equivalency - even using the word "equivalent" -
comes up here:

https://docs.python.org/3/howto/functional.html?highlight=equivalent#generator-expressions-and-list-comprehensions

So I'm very sympathetic to the desire to have assignment expressions
inside comprehensions behave like assignment expressions outside
comprehensions. The trouble is that they are then _not_ the same as
other names inside comprehensions. One way or another, there's a
confusing distinction, especially at class scope. Unless this comes
with an actual semantic change that affects existing code, there is
going to be a bizarre disconnect *somewhere*, and it's just a matter
of where.

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] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

[Steven D'Aprano]

On Sat, Jun 23, 2018 at 12:22:33AM +1000, Nick Coghlan wrote:

[...]
> * for the reactions to my description of the currently proposed parent
> local scoping behaviour in comprehensions, I'd use the word
> "horrified", and feel I wasn't overstating the response :)

Without knowing how you worded the question, and the reasons for this 
horrified reaction, I'm afraid that isn't really helpful. It is nothing 
more than an appeal to emotion:

https://en.wikipedia.org/wiki/Wisdom_of_repugnance

Such strong emotions as "horrified" are typically a sign of an 
immediate, emotional gut reaction, not careful thought. We often see 
those sorts of reactions attached to the most objectively trivial 
matters. Immediate gut reactions are rarely a good guide because they 
tend to over-value the status quo, exaggerate the difficulty and costs 
of change, and under-estimate the benefits.

Speaking personally, I've learned to question my immediately gut 
reaction. (And I remember to do so at least half the time.) PEP 572 is 
an example: when the issue was first raised back in February, my gut 
reaction was "Not in MY Python!!!" but by taking it seriously and 
running through some examples over the course of the discussion, I 
realised that, actually, I cautiously favour the idea.

Of course, matters of *personal taste* cannot be anything but gut 
reaction, but in those matters, what one person holds strongly another 
can legitimately reject strongly. We ought to try to look beyond 
personal taste, and try (even if only imperfectly) to consider rational 
reasons for and against a proposal. If we do, reactions like "horrified" 
are rarely justified. It's just a minor feature in a programming 
language, the world will go on one way or the other, and Python already 
has trickier gotchas.


> While I try to account for the fact that I implemented the current
> comprehension semantics for the 3.x series, and am hence biased
> towards considering them the now obvious interpretation,

While we certainly don't want to make "non-obvious" a virtue for its own 
sake, obviousness (obvious to who?) ought to take a distant second place 
to *useful*. Otherwise we'd have to give up an awful lot of existing 
Python, starting with the fundamental execution model.

(Oh, the number and length of arguments about whether Python uses call 
by value or call by reference, why mutable defaults and [[]]*3 are 
"broken"... if you think Python's execution model is "obvious" you've 
been using Python too long ;-)

But as Tim Peters has said on a number of occasions, nobody is 
suggesting changing the interpretation of current comprehension 
semantics. Comprehension loop variables will continue to remain 
isolated to the comprehension.

(And for the record, that makes *comprehensions* a weird special case, 
not assignment expressions. All other expressions run in the current 
lexical scope. Comprehensions introduce an implicit, invisible, 
sub-local scope that doesn't match up with a change in indentation as 
class and def statements do.)

The behaviour in question is a matter of *assignment expression* 
semantics, not comprehensions. And honestly, I don't see why the 
proposed behaviour is "horrifying". Here's the high-level overview:

- at the top level of a module, assignment expressions assign in
  the global scope;

- inside a class, assignment expressions assign in the class scope;

- inside a function, assignment expressions assign in the function
  local scope (unless declared global or nonlocal);

- inside a comprehension, assignment expressions assign in the 
  surrounding lexical scope (the surrounding function, class or
  module).


The first three are the same as ordinary statement assignment. The last 
one is what you would expect if you treat comprehensions as any other 
expression which run in the current lexical scope. (The current function 
or class or module.) Even if we treat it as a "weird special case" (I 
don't think it is, but for the sake of the argument let's say it is) its 
not hard to explain.

As I discuss below, you can get a very long way indeed working with 
comprehensions without once thinking about the scope they run in. By the 
time you need to think about comprehension scope, it shouldn't be hard 
to deal with the rule:

- loop variables are hidden in a comprehension private scope;
- explicit assignment expression variables are not.

This is not async, or metaclasses, or even Unicode.


[...]
> plenty of
> functional-language-inspired documentation to instead encourage folks
> to view comprehensions as tightly encapsulated declarative container
> construction syntax.

I can't say I've done a broad survey, but the third-party documentation 
I've read on comprehensions typically glosses over the scoping issues 
without mentioning them. To the extent that scoping is even hinted at, 
comprehensions are treated as expressions which are exactly equivalent 
to re-writing them as a for-loop in the current scope.

This is a 

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

[Steven D'Aprano]

On Fri, Jun 22, 2018 at 10:59:43AM -0700, Michael Selik wrote:

> > > I've started testing the proposed syntax when I teach. I don't have a
> > > large
> > > sample yet, but most students either dislike it or don't appreciate the
> > > benefits. They state a clear preference for shorter, simpler lines at the
> > > consequence of more lines of code.

Of course they do -- they're less fluent at reading code. They don't 
have the experience to judge good code from bad.

The question we should be asking is, do we only add features to Python 
if they are easy for beginners? It's not that I especially want to add 
features which *aren't* easy for beginners, but Python isn't Scratch and 
"easy for beginners" should only be a peripheral concern.


> > This is partly because students, lacking the experience to instantly
> > recognize larger constructs, prefer a more concrete approach to
> > coding. "Good code" is code where the concrete behaviour is more
> > easily understood. As a programmer gains experience, s/he learns to
> > grok more complex expressions, and is then better able to make use of
> > the more expressive constructs such as list comprehensions.
> >
> 
> I don't think that's the only dynamic going on here. List comprehensions
> are more expressive, but also more declarative and in Python they have nice
> parallels with SQL and speech patterns in natural language. The concept of
> a comprehension is separate from its particular expression in Python. For
> example, Mozilla's array comprehensions in Javascript are/were ugly [0].

Mozilla's array comprehensions are almost identical to Python's, aside 
from a couple of trivial differences:

evens = [for (i of numbers) if (i % 2 === 0) i];

compared to:

evens = [i for i in numbers if (i % 2 == 0)]

- the inexplicable (to me) decision to say "for x of array" instead of
  "for x in array";

- moving the expression to the end, instead of the beginning.

The second one is (arguably, though not by me) an improvement, since it 
preserves a perfect left-to-right execution order within the 
comprehension.

 
> Students who are completely new to programming can see the similarity of
> list comprehensions to spoken language. 

o_O

I've been using comprehensions for something like a decade, and I can't 
:-)

The closest analogy to comprehensions I know of is set builder notation 
in mathematics, which is hardly a surprise. That's where Haskell got the 
inspiration from, and their syntax is essentially an ASCIIfied version 
of set builder notation:

Haskell: [(i,j) | i <- [1,2], j <- [1..4]]

Maths:   {(i,j) : i ∈ {1, 2}, j ∈ {1...4}}

I teach secondary school children maths, and if there's a plain English 
natural language equivalent to list builder notation, neither I nor any 
of my students, nor any of the text books I've read, have noticed 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] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

[Steven D'Aprano]

On Fri, Jun 22, 2018 at 11:28:45AM -0700, Chris Barker via Python-Dev wrote:
> On Fri, Jun 22, 2018 at 10:09 AM, Michael Selik  wrote:
> 
> > I forgot to add that I don't anticipate changing my lesson plans if this
> > proposal is accepted. There's already not enough time to teach everything
> > I'd like. Including a new assignment operator would distract from the
> > learning objectives.
> >
> 
> nor would I. For a while, anyway
> 
> But once it becomes a more common idiom, students will see it in the wild
> pretty early in their path to learning python. So we'll need to start
> introducing it earlier than later.

Students see many features early in their path. I've had people still 
struggling with writing functions ask about metaclasses. People 
will see async code everywhere. We don't have to teach *everything* at 
once.

The *subtleties* of assignment expressions might have some funny corner 
cases, but the high-level overview is simple. It is like ordinary 
assignment, but it is an expression that returns the value being 
assigned. So if you absolutely need to teach it to a beginner, it 
shouldn't be difficult once they understand the difference between an 
expression and a statement.


[...]
> I really have no idea how much harder thats going to make the langauge to
> teach, but it will make it a bit harder -- I see enough confusion with "is"
> vs == already...

I think that the biggest source of confusion with "is" is that it 
*sometimes* seems to do what is wanted, i.e. test equality, but other 
times doesn't. It is that inconsistency that bites.

Whereas with assignment expressions, there's no such inconsistency:

- regular assignment using = only works as a statement, always;
- assignment expression can go anywhere an expression can go, always;
- regular assignment never returns a value;
- assignment expression always returns a value;
- regular assignments have lots of complex forms, such as sequence 
  unpacking, and complex targets like spam[eggs](arg).attr;
- assignment expressions only takes a plain name, always.

Although there is some overlap in behaviour between the two, unlike 
"is", there's no inconsist behaviour to lead people astray.

A better syntax error for things like this:

py> if mo = regex.match(string):
  File "", line 1
if mo = regex.match(string):
  ^
SyntaxError: invalid syntax

will also help, although of course some users won't read error messages 
for love or money.



-- 
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] About [].append == [].append

[Guido van Rossum]

On Fri, Jun 22, 2018 at 6:52 PM Steven D'Aprano  wrote:

> On Fri, Jun 22, 2018 at 11:44:07AM -0700, Guido van Rossum wrote:
> [...]
> > > I know why it happens -- at the REPL, the interpreter uses the same
> > > object for both 17.1 instances when they're part of the same statement,
> > > but not when they're on separate lines. I just don't know whether this
> > > is desirable or not.
> > >
> >
> > But there's nothing new about that example. It's just the same as the
> issue
> > that sometimes `1 is 1` and sometimes it isn't.
>
> Sure, but this is closer to "sometimes 1 == 1 and sometimes it isn't".
> But if you're okay with it, I don't have a counter-argument.
>

A bound method is a fairly complicated object, and for builtin bound
methods, the == comparison has the following definition:
- if the `__self__` objects are not the same object, return False
- otherwise, return True iff it's the same method (i.e. the same name / the
same underlying C function)


> I think it is more important that builtin methods and Python methods
> behave the same. Should Python methods be changed to compare self with
> "is" or are we too late to make that change?
>

I am not sure. It's surprising, but I fear it may be too late to change.
Are there tests in the stdlib for this behavior?

-- 
--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] About [].append == [].append

[Steven D'Aprano]

On Fri, Jun 22, 2018 at 11:44:07AM -0700, Guido van Rossum wrote:
[...]
> > I know why it happens -- at the REPL, the interpreter uses the same
> > object for both 17.1 instances when they're part of the same statement,
> > but not when they're on separate lines. I just don't know whether this
> > is desirable or not.
> >
> 
> But there's nothing new about that example. It's just the same as the issue
> that sometimes `1 is 1` and sometimes it isn't.

Sure, but this is closer to "sometimes 1 == 1 and sometimes it isn't". 
But if you're okay with it, I don't have a counter-argument.

I think it is more important that builtin methods and Python methods 
behave the same. Should Python methods be changed to compare self with 
"is" or are we too late to make that change?



-- 
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] We now have C code coverage!

[Nathaniel Smith]

On Fri, Jun 22, 2018 at 6:16 PM, Terry Reedy  wrote:
> On 6/22/2018 8:43 PM, Terry Reedy wrote:
>>
>> On 6/22/2018 6:21 PM, Brett Cannon wrote:
>>>
>>> Thanks to a PR from Ammar Askar we now run Python under lcov as part of
>>> the code coverage build. And thanks to codecov.io 
>>> automatically merging code coverage reports we get a complete report of our
>>> coverage (the first results of which can now be seen at
>>> https://codecov.io/gh/python/cpython).
>>>
>>> And funny enough the coverage average changed less than 1%. :)
>>
>>
>> Questions:
>>
>> 1. Is it possible, given that we are not paying for those reports, to
>> customize the .coveragerc exclude_lines definitions?  Without such, the
>> idlelib measures are biased downward.
>>
>> 2. What do the colors of test files mean?  Every line of nearly all the
>> idlelib test files are executed, but over half are red.
>>
>> The Learn More page does not say anything about either.
>
>
> I discovered the answer to 2. by shift-clicking on a text_x file to see
> their coverage report for the file.  The colors actually do reflect the test
> lines executed.  codecov.io excludes gui tests*, so the reported coverage
> for tkinter, idlelib, and turtle is deceptive and bogus, and under-reports
> the total cpython coverage by a percent or two.  It would be better to
> exclude these modules.
>
> * I assume that codecov.io uses linux servers.  I have read that there are
> programs that simulate X-Windows so that gui code will execute without
> actual terminals.

Codecov.io doesn't run any tests itself; it's just a service for
aggregation and reporting. The coverage information is being gathered
while running CPython's regular CI tests, and then uploaded to
codecov.io to view.

So if you want to run the gui tests -- which seems like a good idea if
possible! -- then the way to do that would be to make them run as part
of the regular Travis/Appveyor/VSTS checks.

-n

-- 
Nathaniel J. Smith -- https://vorpus.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] We now have C code coverage!

[Terry Reedy]

On 6/22/2018 8:43 PM, Terry Reedy wrote:

On 6/22/2018 6:21 PM, Brett Cannon wrote:
Thanks to a PR from Ammar Askar we now run Python under lcov as part 
of the code coverage build. And thanks to codecov.io 
 automatically merging code coverage reports we get 
a complete report of our coverage (the first results of which can now 
be seen at https://codecov.io/gh/python/cpython).


And funny enough the coverage average changed less than 1%. :)


Questions:

1. Is it possible, given that we are not paying for those reports, to 
customize the .coveragerc exclude_lines definitions?  Without such, the idlelib 
measures are biased downward.


2. What do the colors of test files mean?  Every line of nearly all the 
idlelib test files are executed, but over half are red.


The Learn More page does not say anything about either.


I discovered the answer to 2. by shift-clicking on a text_x file to see 
their coverage report for the file.  The colors actually do reflect the 
test lines executed.  codecov.io excludes gui tests*, so the reported 
coverage for tkinter, idlelib, and turtle is deceptive and bogus, and 
under-reports the total cpython coverage by a percent or two.  It would 
be better to exclude these modules.


* I assume that codecov.io uses linux servers.  I have read that there 
are programs that simulate X-Windows so that gui code will execute 
without actual terminals.


--
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] We now have C code coverage!

[Terry Reedy]

On 6/22/2018 6:21 PM, Brett Cannon wrote:
Thanks to a PR from Ammar Askar we now run Python under lcov as part of 
the code coverage build. And thanks to codecov.io  
automatically merging code coverage reports we get a complete report of 
our coverage (the first results of which can now be seen at 
https://codecov.io/gh/python/cpython).


And funny enough the coverage average changed less than 1%. :)


Questions:

1. Is it possible, given that we are not paying for those reports, to 
customize the 'exclude_lines' definitions?  Without such, the idlelib 
measures are biased downward.


2. What do the colors of test files mean?  Every line of nearly all the 
idlelib test files are executed, but over half are red.


The Learn More page does not say anything about either.

--
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] PySequence_Check but no __len__

[Terry Reedy]

On 6/22/2018 7:57 PM, Greg Ewing wrote:

Terry Reedy wrote:
I am surprised that a C-API function calls something a 'sequence' 
without it having __len__.


It's a bit strange that PySequence_Check exists at all.
The principle of duck typing would suggest that one
should be checking for the specific methods one needs.

I suspect it's a holdover from very early Python, where
the notion of a "sequence type" and a "mapping type"
were more of a concrete thing. This is reflected in
the existence of the tp_as_sequence and tp_as_mapping
substructures. It was expected that a given type would
either implement all the methods in one of those
substructures or none of them, so shorcuts such as
checking for just one method and assuming the others
would exist made sense.

But user-defined classes messed all that up, because
it became possible to create a type that has __getitem__
but not __len__, etc. It also made it impossible to
distinguish reliably between a sequence and a mapping.

So it seems to me that PySequence_Check and related
functions are not very useful any more, since it's not
possible for them to really do what they claim to do.


So one should not take them as defining what they appear to define.
In a sense, 'PySequence_Check' should be 'PySubscriptable_Check'.


--
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] PySequence_Check but no __len__

[Greg Ewing]

Ivan Pozdeev via Python-Dev wrote:
the documentation seems to use "sequence" in the sense 
"finite iterable". Functions that need to know the length of input in 
advance seem to be the minority.


The official classifications we have are:

Sequence: __iter__, __getitem__, __len__

Iterable: __iter__

There isn't any official term for a sequential thing that
has __iter__ and __getitem__ but not __len__.

That's probably because the need for such a thing doesn't
seem to come up very much. One usually processes a
potentially infinite sequence by iterating over it, not
picking things out at arbitrary positions. And usually
its items are generated by an algorithm that works
sequentially, so random access would be difficult to
implement.

--
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] PySequence_Check but no __len__

[Greg Ewing]

Terry Reedy wrote:
I am surprised that a C-API function calls something a 'sequence' 
without it having __len__.


It's a bit strange that PySequence_Check exists at all.
The principle of duck typing would suggest that one
should be checking for the specific methods one needs.

I suspect it's a holdover from very early Python, where
the notion of a "sequence type" and a "mapping type"
were more of a concrete thing. This is reflected in
the existence of the tp_as_sequence and tp_as_mapping
substructures. It was expected that a given type would
either implement all the methods in one of those
substructures or none of them, so shorcuts such as
checking for just one method and assuming the others
would exist made sense.

But user-defined classes messed all that up, because
it became possible to create a type that has __getitem__
but not __len__, etc. It also made it impossible to
distinguish reliably between a sequence and a mapping.

So it seems to me that PySequence_Check and related
functions are not very useful any more, since it's not
possible for them to really do what they claim to do.

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

[Python-Dev] We now have C code coverage!

[Brett Cannon]

Thanks to a PR from Ammar Askar we now run Python under lcov as part of the
code coverage build. And thanks to codecov.io automatically merging code
coverage reports we get a complete report of our coverage (the first
results of which can now be seen at https://codecov.io/gh/python/cpython).

And funny enough the coverage average changed less than 1%. :)
___
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] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

[Greg Ewing]

Nick Coghlan wrote:

x:= f():" implies "x" is already defined as a target somewhere else in
the current scope, while "if x := f() given x:" potentially introduces
"x" as a new local target


N. this is just taking a bad idea and making it
worse, IMO.

I'm -1 on any contortions designed to allow comprehensions
to assign to things in outer scopes. All the proposed use
cases I've seen for this have not improved readability
over writing a function that does things the usual way.

Can we please leave comprehensions as declarative
constructs? The best tools do just one thing and do
it well. These proposals seem to be trying to turn
comprehensions into swiss army knives.

--
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] PySequence_Check but no __len__

[Paul Moore]

On 22 June 2018 at 20:17, Ivan Pozdeev via Python-Dev
 wrote:
> On 22.06.2018 22:07, Terry Reedy wrote:

>> https://docs.python.org/3/library/collections.abc.html#collections-abstract-base-classes
>>
>> says that a Sequence has both __getitem__ and __len__.
>>
>> I am surprised that a C-API function calls something a 'sequence' without
>> it having __len__.
>>
> A practical sequence check is checking for __iter__ . An iterator doesn't
> necessarily have a defined length -- e.g. a stream or a generator.

There's a difference between the ABC "Sequence" and the informally
named sequence concept used in the C API. It's basically just that the
C API term predates the ABC significantly, and there's no way that
we'd change the C API naming because it would break too much code, but
IMO it's just one of those "historical reasons" type of things that
can't really be adequately explained, but just needs to be accepted...

An ABC Sequence has __getitem__ and __len__. In terms of ABCs,
something with __iter__ is an Iterable. Informal terminology is a
different matter...

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] PySequence_Check but no __len__

[Ivan Pozdeev via Python-Dev]

On 22.06.2018 22:17, Ivan Pozdeev wrote:

On 22.06.2018 22:07, Terry Reedy wrote:

On 6/22/2018 7:17 AM, Christian Tismer wrote:



My problem is to find out how to deal with a class which has
__getitem__ but no __len__.

The documentation suggests that the length of a sequence can always
be obtained by len().
https://docs.python.org/3/reference/datamodel.html


It says that plainly: "The built-in function len() returns the number 
of items of a sequence. "


https://docs.python.org/3/library/collections.abc.html#collections-abstract-base-classes 



says that a Sequence has both __getitem__ and __len__.

I am surprised that a C-API function calls something a 'sequence' 
without it having __len__.


A practical sequence check is checking for __iter__ . An iterator 
doesn't necessarily have a defined length -- e.g. a stream or a 
generator.


Now, I know this isn't what 
https://docs.python.org/3/glossary.html#term-sequence says.
But practically, the documentation seems to use "sequence" in the sense 
"finite iterable". Functions that need to know the length of input in 
advance seem to be the minority.


--
Regards,
Ivan

___
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] PySequence_Check but no __len__

[Ivan Pozdeev via Python-Dev]

On 22.06.2018 22:07, Terry Reedy wrote:

On 6/22/2018 7:17 AM, Christian Tismer wrote:



My problem is to find out how to deal with a class which has
__getitem__ but no __len__.

The documentation suggests that the length of a sequence can always
be obtained by len().
https://docs.python.org/3/reference/datamodel.html


It says that plainly: "The built-in function len() returns the number 
of items of a sequence. "


https://docs.python.org/3/library/collections.abc.html#collections-abstract-base-classes 



says that a Sequence has both __getitem__ and __len__.

I am surprised that a C-API function calls something a 'sequence' 
without it having __len__.


A practical sequence check is checking for __iter__ . An iterator 
doesn't necessarily have a defined length -- e.g. a stream or a generator.


--
Regards,
Ivan

___
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] PySequence_Check but no __len__

[Terry Reedy]

On 6/22/2018 7:17 AM, Christian Tismer wrote:



My problem is to find out how to deal with a class which has
__getitem__ but no __len__.

The documentation suggests that the length of a sequence can always
be obtained by len().
https://docs.python.org/3/reference/datamodel.html


It says that plainly: "The built-in function len() returns the number of 
items of a sequence. "


https://docs.python.org/3/library/collections.abc.html#collections-abstract-base-classes

says that a Sequence has both __getitem__ and __len__.

I am surprised that a C-API function calls something a 'sequence' 
without it having __len__.


--
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] About [].append == [].append

[Guido van Rossum]

On Fri, Jun 22, 2018 at 9:43 AM Steven D'Aprano  wrote:

> On Fri, Jun 22, 2018 at 08:13:44AM -0700, Guido van Rossum wrote:
>
> > Honestly it looks to me like the status quo is perfect.
>
> Does this example work for you?
>
> py> (17.1).hex == (17.1).hex
> True
>
> But:
>
> py> a = 17.1
> py> b = 17.1
> py> a.hex == b.hex
> False
>
> I know why it happens -- at the REPL, the interpreter uses the same
> object for both 17.1 instances when they're part of the same statement,
> but not when they're on separate lines. I just don't know whether this
> is desirable or not.
>

But there's nothing new about that example. It's just the same as the issue
that sometimes `1 is 1` and sometimes it isn't.

-- 
--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] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

[Chris Barker via Python-Dev]

On Fri, Jun 22, 2018 at 10:09 AM, Michael Selik  wrote:

> I forgot to add that I don't anticipate changing my lesson plans if this
> proposal is accepted. There's already not enough time to teach everything
> I'd like. Including a new assignment operator would distract from the
> learning objectives.
>

nor would I. For a while, anyway

But once it becomes a more common idiom, students will see it in the wild
pretty early in their path to learning python. So we'll need to start
introducing it earlier than later.

I think this reflects that the "smaller" a language is, the easier it is to
learn.

Python has already grown a fair bit since 1.5 (when I started using it :-)
). Some things, like generators, are special purpose enough that I can wait
pretty far into the program before teaching them. But others, like
comprehensions (and lambda) are common enough that I have to introduce them
pretty early on.

Adding := is not a HUGE change, but it IS an expansion of the language, and
one that we WILL have to introduce in an introductory course once it starts
seeing common use.

I really have no idea how much harder thats going to make the langauge to
teach, but it will make it a bit harder -- I see enough confusion with "is"
vs == already...

-CHB

-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
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] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

[Michael Selik]

On Fri, Jun 22, 2018 at 10:19 AM Chris Angelico  wrote:

> On Sat, Jun 23, 2018 at 3:02 AM, Michael Selik  wrote:
> > On Fri, Jun 22, 2018 at 8:09 AM Antoine Pitrou 
> wrote:
> >>
> >> Thank you.  Personally, I'd like to see feedback from
> >> educators/teachers after they take the time to read the PEP and take
> >> some time to think about its consequences.
> >
> >
> > I've started testing the proposed syntax when I teach. I don't have a
> large
> > sample yet, but most students either dislike it or don't appreciate the
> > benefits. They state a clear preference for shorter, simpler lines at the
> > consequence of more lines of code.
>
> This is partly because students, lacking the experience to instantly
> recognize larger constructs, prefer a more concrete approach to
> coding. "Good code" is code where the concrete behaviour is more
> easily understood. As a programmer gains experience, s/he learns to
> grok more complex expressions, and is then better able to make use of
> the more expressive constructs such as list comprehensions.
>

I don't think that's the only dynamic going on here. List comprehensions
are more expressive, but also more declarative and in Python they have nice
parallels with SQL and speech patterns in natural language. The concept of
a comprehension is separate from its particular expression in Python. For
example, Mozilla's array comprehensions in Javascript are/were ugly [0].

Students who are completely new to programming can see the similarity of
list comprehensions to spoken language. They also appreciate the revision
of certain 3-line and 4-line for-loops to comprehensions. I didn't get the
same sense of "Oh! That looks better!" from my students when revising code
with an assignment expression.

Despite my best efforts to cheerlead, some students initially dislike list
comprehensions. However, they come around to the idea that there's a
tradeoff between line density and code block density. Comprehensions have a
3-to-1 or 4-to-1 ratio of code line shrinkage. They're also often used in
sequence, like piping data through a series of transforms. Even if students
dislike a single comprehension, they agree that turning 15 lines into 5
lines improves the readability.

In contrast, an assignment expression only has a 2-to-1 code line
compression ratio. It might save a level of indentation, but I think there
are usually alternatives. Also, the assignment expression is less likely to
be used several times in the same block.

A good pitch for an assignment expression is refactoring a cascade of
regular expressions:


for line in f:
mo = foo_re.search(line)
if mo is not None:
foo(mo.groups())
continue

mo = bar_re.search(line)
if mo is not None:
bar(mo.groups())
continue

mo = baz_re.search(line)
if mo is not None:
baz(mo.groups())
continue


Here the assignment operator makes a clear improvement:

for line in f:
if (mo := foo_re.search(line)) is not None:
foo(mo.groups())
elif (mo := bar_re.search(line)) is not None:
bar(mo.groups())
elif (mo := baz_re.search(line)) is not None:
baz(mo.groups())


However, I think this example is cheating a bit. While I've written similar
code many times, it's almost never just a function call in each if-block.
It's nearly always a handful of lines of logic which I wouldn't want to cut
out into a separate function. The refactor is misleading, because I'd
nearly always make a visual separation with a newline and the code would
still look similar to the initial example.


[0]
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Array_comprehensions
___
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] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

[Chris Angelico]

On Sat, Jun 23, 2018 at 3:02 AM, Michael Selik  wrote:
> On Fri, Jun 22, 2018 at 8:09 AM Antoine Pitrou  wrote:
>>
>> Thank you.  Personally, I'd like to see feedback from
>> educators/teachers after they take the time to read the PEP and take
>> some time to think about its consequences.
>
>
> I've started testing the proposed syntax when I teach. I don't have a large
> sample yet, but most students either dislike it or don't appreciate the
> benefits. They state a clear preference for shorter, simpler lines at the
> consequence of more lines of code.

This is partly because students, lacking the experience to instantly
recognize larger constructs, prefer a more concrete approach to
coding. "Good code" is code where the concrete behaviour is more
easily understood. As a programmer gains experience, s/he learns to
grok more complex expressions, and is then better able to make use of
the more expressive constructs such as list comprehensions.

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] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

[Michael Selik]

On Fri, Jun 22, 2018 at 10:02 AM Michael Selik  wrote:

> On Fri, Jun 22, 2018 at 8:09 AM Antoine Pitrou 
> wrote:
>
>> Thank you.  Personally, I'd like to see feedback from
>> educators/teachers after they take the time to read the PEP and take
>> some time to think about its consequences.
>
>
I forgot to add that I don't anticipate changing my lesson plans if this
proposal is accepted. There's already not enough time to teach everything
I'd like. Including a new assignment operator would distract from the
learning objectives.
___
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] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

[Michael Selik]

On Fri, Jun 22, 2018 at 8:09 AM Antoine Pitrou  wrote:

> Thank you.  Personally, I'd like to see feedback from
> educators/teachers after they take the time to read the PEP and take
> some time to think about its consequences.
>

I've started testing the proposed syntax when I teach. I don't have a large
sample yet, but most students either dislike it or don't appreciate the
benefits. They state a clear preference for shorter, simpler lines at the
consequence of more lines of code. This may partially be caused by the
smaller screen real estate on a projector or large TV than a desktop
monitor.

My intuition is that one strength of Python for beginners is the relative
lack of punctuation and operators compared with most other languages. This
proposal encourages denser lines with more punctuation. Because of the
order of operations, many uses of ``:=`` will also require parentheses.
Even relatively simple uses, like ``if (match := pattern.search(data)) is
not None:`` require doubled parentheses on one side or the other. Beginners
are especially prone to typographical errors with mismatched parentheses
and missing colons and get easily frustrated by the associated syntax
errors.


Given the following options:

A.

if (row := cursor.fetchone()) is None:
raise NotFound
return row


B.

row = cursor.fetchone()
if row is None:
raise NotFound
return row


C.

if (row := cursor.fetchone()) is not None:
return row
raise NotFound


D.

row = cursor.fetchone()
if row is not None:
return row
raise NotFound


The majority of students preferred option B. I also tested some regex match
examples. Results were similar.




> My main concern is we're introducing a second different way of doing
> something which is really fundamental.
>

The few students who like the proposal ask why it requires creating a new
operator instead of repurposing the ``=`` operator.

I'll reserve my personal opinions for a different thread.
___
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] About [].append == [].append

[Ivan Pozdeev via Python-Dev]

On 22.06.2018 19:41, Steven D'Aprano wrote:

On Fri, Jun 22, 2018 at 08:13:44AM -0700, Guido van Rossum wrote:


Honestly it looks to me like the status quo is perfect.

Does this example work for you?

py> (17.1).hex == (17.1).hex
True

But:

py> a = 17.1
py> b = 17.1
py> a.hex == b.hex
False

I know why it happens -- at the REPL, the interpreter uses the same
object for both 17.1 instances when they're part of the same statement,
but not when they're on separate lines. I just don't know whether this
is desirable or not.


Strictly speaking, I can't see anything in the docs about method 
equality semantics.
If that's true, it's an implementation detail, and users shouldn't rely 
on it.
Consequently, anything is "desirable" that is sufficient for the Python 
codebase.


--
Regards,
Ivan

___
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] About [].append == [].append

[Steven D'Aprano]

On Fri, Jun 22, 2018 at 08:13:44AM -0700, Guido van Rossum wrote:

> Honestly it looks to me like the status quo is perfect.

Does this example work for you?

py> (17.1).hex == (17.1).hex
True

But:

py> a = 17.1
py> b = 17.1
py> a.hex == b.hex
False

I know why it happens -- at the REPL, the interpreter uses the same 
object for both 17.1 instances when they're part of the same statement, 
but not when they're on separate lines. I just don't know whether this 
is desirable or not.


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

[Python-Dev] Summary of Python tracker Issues

[Python tracker]

ACTIVITY SUMMARY (2018-06-15 - 2018-06-22)
Python tracker at https://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open6700 ( +9)
  closed 38994 (+64)
  total  45694 (+73)

Open issues with patches: 2651 


Issues opened (49)
==

#23660: Turtle left/right inverted when using different coordinates or
https://bugs.python.org/issue23660  reopened by willingc

#32500: PySequence_Length() raises TypeError on dict type
https://bugs.python.org/issue32500  reopened by serhiy.storchaka

#33871: Possible integer overflow in iov_setup()
https://bugs.python.org/issue33871  opened by serhiy.storchaka

#33873: False positives when running leak tests with -R 1:1
https://bugs.python.org/issue33873  opened by pablogsal

#33875: Allow dynamic password evaluation in pypirc configuration file
https://bugs.python.org/issue33875  opened by jperras

#33877: doc Mention Windows along UNIX for script running instructions
https://bugs.python.org/issue33877  opened by adelfino

#33878: Doc: Assignment statement to tuple or list: case missing.
https://bugs.python.org/issue33878  opened by mdk

#33880: namedtuple should use NFKD to find duplicate members
https://bugs.python.org/issue33880  opened by John Cooke

#33881: dataclasses should use NFKC to find duplicate members
https://bugs.python.org/issue33881  opened by eric.smith

#33882: doc Mention breakpoint() in debugger-related FAQ
https://bugs.python.org/issue33882  opened by adelfino

#33883: doc Mention mypy, pytype and PyAnnotate in FAQ
https://bugs.python.org/issue33883  opened by adelfino

#33884: [multiprocessing] Multiprocessing in spawn mode doesn't work w
https://bugs.python.org/issue33884  opened by Yoni Rozenshein

#33885: doc Replace "hook function" with "callable" in urllib.request.
https://bugs.python.org/issue33885  opened by adelfino

#33886: SSL on aiomysql hangs on reconnection
https://bugs.python.org/issue33886  opened by andr04

#33887: doc Add TOC in Design and History FAQ
https://bugs.python.org/issue33887  opened by adelfino

#33888: Use CPython instead of Python when talking about implementatio
https://bugs.python.org/issue33888  opened by adelfino

#33894: tempfile.tempdir cannot be unset
https://bugs.python.org/issue33894  opened by philiprowlands

#33895: LoadLibraryExW called with GIL held can cause deadlock
https://bugs.python.org/issue33895  opened by Tony Roberts

#33896: Document what components make up the filecmp.cmp os.stat signa
https://bugs.python.org/issue33896  opened by Dean Morin

#33897: Add a restart option to logging.basicConfig()
https://bugs.python.org/issue33897  opened by rhettinger

#33898: pathlib issues with Windows device paths
https://bugs.python.org/issue33898  opened by eryksun

#33899: Tokenize module does not mirror "end-of-input" is newline beha
https://bugs.python.org/issue33899  opened by ammar2

#33909: PyObject_CallFinalizerFromDealloc is not referenced in any doc
https://bugs.python.org/issue33909  opened by Eric.Wieser

#33911: [EASY] test_docxmlrpc fails when run with -Werror
https://bugs.python.org/issue33911  opened by vstinner

#33913: test_multiprocessing_spawn random failures on x86 Windows7 3.6
https://bugs.python.org/issue33913  opened by vstinner

#33914: test_gdb fails for Python 2.7.15
https://bugs.python.org/issue33914  opened by vibhutisawant

#33916: test_lzma: test_refleaks_in_decompressor___init__() leaks 100 
https://bugs.python.org/issue33916  opened by vstinner

#33918: Hooking into pause/resume of iterators/coroutines
https://bugs.python.org/issue33918  opened by Liran Nuna

#33919: Expose _PyCoreConfig structure to Python
https://bugs.python.org/issue33919  opened by barry

#33920: test_asyncio: test_run_coroutine_threadsafe_with_timeout() fai
https://bugs.python.org/issue33920  opened by vstinner

#33921: Explain that '' can be used to bind to all interfaces for the 
https://bugs.python.org/issue33921  opened by John Hagen

#33923: py.ini cannot set 32/64bits for specific version
https://bugs.python.org/issue33923  opened by mrh1997

#33926: test_gdb is skipped in builds since gdb is not installed as pa
https://bugs.python.org/issue33926  opened by xtreak

#33927: Allow json.tool to have identical infile and outfile
https://bugs.python.org/issue33927  opened by kuhlmann

#33929: test_multiprocessing_spawn: WithProcessesTestProcess.test_many
https://bugs.python.org/issue33929  opened by vstinner

#33930: Segfault with deep recursion into object().__dir__
https://bugs.python.org/issue33930  opened by a-j-buxton

#33931: Building 2.7 on Windows with PC\VS9.0 is broken
https://bugs.python.org/issue33931  opened by anselm.kruis

#33932: Calling Py_Initialize() twice now triggers a fatal error (Pyth
https://bugs.python.org/issue33932  opened by vstinner

#33933: Error message says dict has no len
https://bugs.python.org/issue33933  opened by veky

#33934: locale.getlocale() 

Re: [Python-Dev] Intent to accept PEP 561 -- Distributing and Packaging Type Information

[Nick Coghlan]

On 23 June 2018 at 01:16, Guido van Rossum  wrote:
> That sounds like you're supporting PEP 561 as is, right?

Aye, I'm personally fine with it - we do need to do something about
automatically reserving the derived names on PyPI, but I don't think
that's a blocker for the initial PEP acceptance (instead, it will go
the other way: PEP acceptance will drive Warehouse getting updated to
handle the convention already being adopted by the client tools).

> Excuse my
> ignorance, but where are API testing stub interfaces described or used?

They're not - it's just the context for Donald referring to "stubs" as
being a general technical term with other meanings beyond the "type
hinting stub file" one.

As such, there's three parts to explaining why we're not worried about
the terminology clash:

- Ethan searched for projects called "*-stubs" or "*_stubs" and didn't
find any, so the practical impact of any terminology clash will be low
- there isn't an established need to automatically find testing stub
libraries based on an existing project name the way there is for type
hints
- even if such a need did arise in the future, the "py.typed" marker
file and the different file extension for stub files within a package
still gives us an enormous amount of design flexibility

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

[Python-Dev] PEP 580 (C call protocol) draft implementation

[Jeroen Demeyer]

Hello all,

I have a first draft implementation of PEP 580 (introducing the C call 
protocol):


https://github.com/jdemeyer/cpython/tree/pep580

Almost all tests pass, only test_gdb and test_pydoc fail for me. I still 
have to fix those.



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] Intent to accept PEP 561 -- Distributing and Packaging Type Information

[Guido van Rossum]

That sounds like you're supporting PEP 561 as is, right? Excuse my
ignorance, but where are API testing stub interfaces described or used?

--Guido

On Fri, Jun 22, 2018 at 6:10 AM Nick Coghlan  wrote:

> On 21 June 2018 at 07:06, Guido van Rossum  wrote:
> > Only the last two commits are new since the last posting: support for
> > partial packages and a bunch of small textual tweaks I found today while
> > reviewing. There wasn't a lot of feedback then so I don't expect a
> flamewar
> > today, but better late than never. ;-)
>
> Something that was raised indirectly in
> https://github.com/pypa/warehouse/issues/4164 was the terminology
> collision between type hinting stub files, and API testing stub
> interfaces.
>
> I don't think that's actually a problem, since type hinting stubs will
> only contain interface files, and not regular source files. This means
> that a type hinting stub could later be expanded in scope to also
> become an API emulating testing stub, and the two use cases wouldn't
> conflict (I'm not commenting on whether or not that would actually be
> a good idea - I'm just noting that PEP 561 claiming the
> "-stubs" naming convention on PyPI doesn't close out that
> option).
>
> Beyond that, I think the other points I raised in the Warehouse
> tracker issues can be considered derived requirements arising from the
> PEP acceptance - if anyone tries to use the window between PEP 561
> being accepted, and the related permissions being enforced in PyPI to
> squat on stubs-related project names, then PEP 541 provides a
> mechanism for addressing that.
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
>


-- 
--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] About [].append == [].append

[Guido van Rossum]

Honestly it looks to me like the status quo is perfect.

>>> a = []
>>> a.append is a.append
False
>>> a.append == a.append
True
>>> b = []
>>> a.append == b.append
False
>>>



On Thu, Jun 21, 2018 at 10:02 PM Serhiy Storchaka 
wrote:

> 22.06.18 00:04, Ivan Pozdeev via Python-Dev пише:
> > On 21.06.2018 23:40, Guido van Rossum wrote:
> >> I'm with Serhiy here, for mutable values I don't think the methods
> >> should compare equal, even when the values do. For immutables I don't
> >> care either way, it's an implementation detail.
> >>
> > In this light, methods rather shouldn't have a rich comparison logic at
> > all
>
> This would be so if you get the same method object when resolve an
> attribute. But a.f is not a.f. Every time a new method object is
> created. If we want a.f == a.f, we need to implement a rich comparison
> logic.
>
> > -- at the very least, until we have a realistic use case and can
> > flesh out the requirements for it.
>
> There are realistic use cases. You will get a number of failures in the
> Python tests if make method objects incomparable.
>
> ___
> 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

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

[Antoine Pitrou]

On Sat, 23 Jun 2018 00:22:33 +1000
Nick Coghlan  wrote:
> On 22 June 2018 at 02:26, Antoine Pitrou  wrote:
> > Indeed.  But, for a syntax addition such as PEP 572, I think it would be
> > a good idea to ask their opinion to teaching/education specialists.
> >
> > As far as I'm concerned, if teachers and/or education specialists were
> > to say PEP 572 is not a problem, my position would shift from negative
> > towards neutral.  
> 
> I asked a handful of folks at the Education Summit the next day about it:
> 
> * for the basic notion of allowing expression level name binding using
> the "NAME := EXPR" notation, the reactions ranged from mildly negative
> (I read it as only a "-0" rather than a "-1") to outright positive.

Thank you.  Personally, I'd like to see feedback from
educators/teachers after they take the time to read the PEP and take
some time to think about its consequences.

My main concern is we're introducing a second different way of doing
something which is really fundamental.

> * for the reactions to my description of the currently proposed parent
> local scoping behaviour in comprehensions, I'd use the word
> "horrified", and feel I wasn't overstating the response :) [...]

Hmm... I don't think conflating the assignment expression proposal
with comprehension semantics issues is helping the discussion.

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] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)

[Nick Coghlan]

On 22 June 2018 at 02:26, Antoine Pitrou  wrote:
> Indeed.  But, for a syntax addition such as PEP 572, I think it would be
> a good idea to ask their opinion to teaching/education specialists.
>
> As far as I'm concerned, if teachers and/or education specialists were
> to say PEP 572 is not a problem, my position would shift from negative
> towards neutral.

I asked a handful of folks at the Education Summit the next day about it:

* for the basic notion of allowing expression level name binding using
the "NAME := EXPR" notation, the reactions ranged from mildly negative
(I read it as only a "-0" rather than a "-1") to outright positive.
* for the reactions to my description of the currently proposed parent
local scoping behaviour in comprehensions, I'd use the word
"horrified", and feel I wasn't overstating the response :)

While I try to account for the fact that I implemented the current
comprehension semantics for the 3.x series, and am hence biased
towards considering them the now obvious interpretation, it's also the
case that generator expressions have worked like nested functions
since they were introduced in Python 2.4 (more than 13 years ago now),
and comprehensions have worked the same way as generator expressions
since Python 3.0 (which has its 10th birthday coming up in December
this year).

This means that I take any claims that the legacy Python 2.x
interpretation of comprehension behaviour is intuitively obvious with
an enormous grain of salt - for the better part of a decade now, every
tool at a Python 3 user's disposal (the fact that the iteration
variable is hidden from the current scope, reading the language
reference [1], printing out locals(), using the dis module, stepping
through code in a debugger, writing their own tracing function, and
even observing the quirky interaction with class scopes) will have
nudged them towards the "it's a hidden nested function" interpretation
of expected comprehension behaviour.

Acquiring the old mental model for the way comprehensions work pretty
much requires a developer to have started with Python 2.x themselves
(perhaps even before comprehensions and lexical closures were part of
the language), or else have been taught the Python 2 comprehension
model by someone else - there's nothing in Python 3's behaviour to
encourage that point of view, and plenty of
functional-language-inspired documentation to instead encourage folks
to view comprehensions as tightly encapsulated declarative container
construction syntax.

I'm currently working on a concept proposal at
https://github.com/ncoghlan/peps/pull/2 that's much closer to PEP 572
than any of my previous `given` based suggestions: for already
declared locals, it devolves to being the same as PEP 572 (except that
expressions are allowed as top level statements), but for any names
that haven't been previously introduced, it prohibits assigning to a
name that doesn't already have a defined scope, and instead relies on
a new `given` clause on various constructs that allows new target
declarations to be introduced into the current scope (such that "if
x:= f():" implies "x" is already defined as a target somewhere else in
the current scope, while "if x := f() given x:" potentially introduces
"x" as a new local target the same way a regular assignment statement
does).

One of the nicer features of the draft proposal is that if all you
want to do is export the iteration variable from a comprehension, you
don't need to use an assignment expression at all: you can just append
"... given global x" or "... given nonlocal x" and export the
iteration variable directly to the desired outer scope, the same way
you can in the fully spelled out nested function equivalent.

Cheers,
Nick.

[1] From 
https://docs.python.org/3.0/reference/expressions.html#displays-for-lists-sets-and-dictionaries:
'Note that the comprehension is executed in a separate scope, so names
assigned to in the target list don’t “leak” in the enclosing scope.'
-- 
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] Intent to accept PEP 561 -- Distributing and Packaging Type Information

[Nick Coghlan]

On 21 June 2018 at 07:06, Guido van Rossum  wrote:
> Only the last two commits are new since the last posting: support for
> partial packages and a bunch of small textual tweaks I found today while
> reviewing. There wasn't a lot of feedback then so I don't expect a flamewar
> today, but better late than never. ;-)

Something that was raised indirectly in
https://github.com/pypa/warehouse/issues/4164 was the terminology
collision between type hinting stub files, and API testing stub
interfaces.

I don't think that's actually a problem, since type hinting stubs will
only contain interface files, and not regular source files. This means
that a type hinting stub could later be expanded in scope to also
become an API emulating testing stub, and the two use cases wouldn't
conflict (I'm not commenting on whether or not that would actually be
a good idea - I'm just noting that PEP 561 claiming the
"-stubs" naming convention on PyPI doesn't close out that
option).

Beyond that, I think the other points I raised in the Warehouse
tracker issues can be considered derived requirements arising from the
PEP acceptance - if anyone tries to use the window between PEP 561
being accepted, and the related permissions being enforced in PyPI to
squat on stubs-related project names, then PEP 541 provides a
mechanism for addressing that.

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] PySequence_Check but no __len__

[Nick Coghlan]

On 22 June 2018 at 21:45, Christian Tismer  wrote:
> Answering myself:
>
> PySequence_Check determines a sequence. See the docs.
>
> len() can but does not have to exist.
> The size is always limited.

Just to throw a couple of extra wrinkles on this:

Due to a C API implementation detail in CPython, not only can len()
throw TypeError for non-finite sequences (which implement other parts
of the sequence API, but not that), but sufficiently large finite
sequences may also throw OverflowError:

>>> data = range(-2**64, 2**64)
>>> format((data.stop - data.start) // data.step, "e")
'3.689349e+19'
>>> format(sys.maxsize, "e")
'9.223372e+18'
>>> len(data)
Traceback (most recent call last):
  File "", line 1, in 
OverflowError: Python int too large to convert to C ssize_t
>>> data.__len__()
Traceback (most recent call last):
  File "", line 1, in 
OverflowError: Python int too large to convert to C ssize_t

Infinite sequences that want to prevent infinite loops or unbounded
memory consumption in consumers may also choose to implement a
__length_hint__ that throws TypeError (see
https://bugs.python.org/issue33939 for a proposal to do that in
itertools).

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] PySequence_Check but no __len__

[Christian Tismer]

Answering myself:

PySequence_Check determines a sequence. See the docs.

len() can but does not have to exist.
The size is always limited.

After evicting my initial fault, this is now obvious.
Sorry about the noise.


On 22.06.18 13:17, Christian Tismer wrote:
> Hi Brett,
> 
> because you did not understand me, I must have had a fundamental
> misunderstanding. So I started a self-analysis and came to the
> conclusion that this was my error since maybe a decade:
> 
> When iterators and generators came into existence, I somehow
> fell into the trap to think that there are now sequences with
> undetermined or infinite length. They would be exactly those sequences
> which have no __len__ attribute.
> 
> I understand now that sequences are always of fixed length
> and adjusted myself.
> 
> -
> 
> My problem is to find out how to deal with a class which has
> __getitem__ but no __len__.
> 
> The documentation suggests that the length of a sequence can always
> be obtained by len().
> https://docs.python.org/3/reference/datamodel.html
> 
> But the existence of __len__ is not guaranteed or enforced.
> And if you look at the definition of PySequence_Fast(), you find that
> a sequence can be turned into a list with iteration only and no __len__.
> 
> So, is a sequence valid without __len__, if iteration is supported,
> instead?
> 
> There is the whole chapter about sequence protocol
> https://docs.python.org/3/c-api/sequence.html?highlight=sequence
> 
> but I cannot find out an exact definition what makes up a sequence?
> 
> Sorry if I'm again the only one who misunderstands the obvious :)
> 
> Best -- Chris
> 
> 
> On 21.06.18 18:29, Brett Cannon wrote:
>> Sorry, I don't quite follow.
>>
>> On Thu, 21 Jun 2018 at 08:50 Christian Tismer > > wrote:
>>
>> Hi friends,
>>
>> there is a case in the Python API where I am not sure what to do:
>>
>> If an object defines __getitem__() only but no __len__(),
>> then PySequence_Check() already is true and does not care.
>>
>>
>> Which matches
>> https://docs.python.org/3/c-api/sequence.html#c.PySequence_Check .
>>
>> From Objects/abstract.c:
>>
>> int
>> PySequence_Check(PyObject *s)
>> {
>>     if (PyDict_Check(s))
>>     return 0;
>>     return s != NULL && s->ob_type->tp_as_sequence &&
>>     s->ob_type->tp_as_sequence->sq_item != NULL;
>> }
>>
>>  
>>
>>
>> So if I define no __len__, it simply fails. Is this intended?
>>
>>
>> What is "it" in this case that is failing? It isn't PySequence_Check()
>> so I'm not sure what the issue is.
>>
>> -Brett
>>  
>>
>>
>> I was mislead and thought this was the unlimited case, but
>> it seems still to be true that sequences are always finite.
>>
>> Can someone please enlighten me?
>> -- 
>> Christian Tismer-Sperling    :^)   tis...@stackless.com
>> 
>> Software Consulting          :     http://www.stackless.com/
>> Karl-Liebknecht-Str. 121     :     http://pyside.org
>> 14482 Potsdam                :     GPG key -> 0xE7301150FB7BEE0E
>> phone +49 173 24 18 776   fax +49 (30)
>> 700143-0023 
>>
>> ___
>> 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/brett%40python.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/tismer%40stackless.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/tismer%40stackless.com
> 


-- 
Christian Tismer-Sperling:^)   tis...@stackless.com
Software Consulting  : http://www.stackless.com/
Karl-Liebknecht-Str. 121 : http://pyside.org
14482 Potsdam: GPG key -> 0xE7301150FB7BEE0E
phone +49 173 24 18 776  fax +49 (30) 700143-0023



signature.asc
Description: OpenPGP digital signature
___
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] PySequence_Check but no __len__

[Christian Tismer]

Hi Brett,

because you did not understand me, I must have had a fundamental
misunderstanding. So I started a self-analysis and came to the
conclusion that this was my error since maybe a decade:

When iterators and generators came into existence, I somehow
fell into the trap to think that there are now sequences with
undetermined or infinite length. They would be exactly those sequences
which have no __len__ attribute.

I understand now that sequences are always of fixed length
and adjusted myself.

-

My problem is to find out how to deal with a class which has
__getitem__ but no __len__.

The documentation suggests that the length of a sequence can always
be obtained by len().
https://docs.python.org/3/reference/datamodel.html

But the existence of __len__ is not guaranteed or enforced.
And if you look at the definition of PySequence_Fast(), you find that
a sequence can be turned into a list with iteration only and no __len__.

So, is a sequence valid without __len__, if iteration is supported,
instead?

There is the whole chapter about sequence protocol
https://docs.python.org/3/c-api/sequence.html?highlight=sequence

but I cannot find out an exact definition what makes up a sequence?

Sorry if I'm again the only one who misunderstands the obvious :)

Best -- Chris


On 21.06.18 18:29, Brett Cannon wrote:
> Sorry, I don't quite follow.
> 
> On Thu, 21 Jun 2018 at 08:50 Christian Tismer  > wrote:
> 
> Hi friends,
> 
> there is a case in the Python API where I am not sure what to do:
> 
> If an object defines __getitem__() only but no __len__(),
> then PySequence_Check() already is true and does not care.
> 
> 
> Which matches
> https://docs.python.org/3/c-api/sequence.html#c.PySequence_Check .
> 
> From Objects/abstract.c:
> 
> int
> PySequence_Check(PyObject *s)
> {
>     if (PyDict_Check(s))
>     return 0;
>     return s != NULL && s->ob_type->tp_as_sequence &&
>     s->ob_type->tp_as_sequence->sq_item != NULL;
> }
> 
>  
> 
> 
> So if I define no __len__, it simply fails. Is this intended?
> 
> 
> What is "it" in this case that is failing? It isn't PySequence_Check()
> so I'm not sure what the issue is.
> 
> -Brett
>  
> 
> 
> I was mislead and thought this was the unlimited case, but
> it seems still to be true that sequences are always finite.
> 
> Can someone please enlighten me?
> -- 
> Christian Tismer-Sperling    :^)   tis...@stackless.com
> 
> Software Consulting          :     http://www.stackless.com/
> Karl-Liebknecht-Str. 121     :     http://pyside.org
> 14482 Potsdam                :     GPG key -> 0xE7301150FB7BEE0E
> phone +49 173 24 18 776   fax +49 (30)
> 700143-0023 
> 
> ___
> 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/brett%40python.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/tismer%40stackless.com
> 


-- 
Christian Tismer-Sperling:^)   tis...@stackless.com
Software Consulting  : http://www.stackless.com/
Karl-Liebknecht-Str. 121 : http://pyside.org
14482 Potsdam: GPG key -> 0xE7301150FB7BEE0E
phone +49 173 24 18 776  fax +49 (30) 700143-0023



signature.asc
Description: OpenPGP digital signature
___
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