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

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

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

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

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

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

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

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

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

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

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

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

Re: [Python-Dev] About [].append == [].append

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

Re: [Python-Dev] About [].append == [].append

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

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

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

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

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

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

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

Re: [Python-Dev] PySequence_Check but no __len__

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

Re: [Python-Dev] PySequence_Check but no __len__

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:

Re: [Python-Dev] PySequence_Check but no __len__

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

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

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

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

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

Re: [Python-Dev] PySequence_Check but no __len__

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

Re: [Python-Dev] PySequence_Check but no __len__

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

Re: [Python-Dev] PySequence_Check but no __len__

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().

Re: [Python-Dev] PySequence_Check but no __len__

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

Re: [Python-Dev] About [].append == [].append

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 =

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

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

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

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

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

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

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

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

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

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

Re: [Python-Dev] About [].append == [].append

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

Re: [Python-Dev] About [].append == [].append

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

[Python-Dev] Summary of Python tracker Issues

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

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

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

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

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

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

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

Re: [Python-Dev] About [].append == [].append

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

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

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

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

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

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

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

Re: [Python-Dev] PySequence_Check but no __len__

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

Re: [Python-Dev] PySequence_Check but no __len__

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

Re: [Python-Dev] PySequence_Check but no __len__

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