Re: [Python-Dev] Tweak to PEP 523 for storing a tuple in co_extra

On Sat, Sep 3, 2016, 17:45 Yury Selivanov wrote: > > > > > But without that new API (basically what Christian proposed) you'd > > need > > to iterate over the list in order to find the object that belongs to > > Pyjion. > > > > > > Yes. > > Yeah, which means the same for my opcode

Re: [Python-Dev] PEP 525, third round, better finalization

Nick Coghlan wrote: For synchronous code, that's a relatively easy burden to push back onto the programmer - assuming fair thread scheduling, a with statement can ensure reliably ensure prompt resource cleanup. That assurance goes out the window as soon as you explicitly pause code execution ins

Re: [Python-Dev] Tweak to PEP 523 for storing a tuple in co_extra

Great, thanks! On Sat, Sep 3, 2016, 17:59 Guido van Rossum wrote: > Brett, I have not followed everything here but I have no problem with > tweaks at this level as long as you are happy with it. > > --Guido (mobile) > > On Sep 3, 2016 5:39 PM, "Brett Cannon" wrote: > >> >> >> On Sat, 3 Sep 2016

Re: [Python-Dev] Tweak to PEP 523 for storing a tuple in co_extra

Brett, I have not followed everything here but I have no problem with tweaks at this level as long as you are happy with it. --Guido (mobile) On Sep 3, 2016 5:39 PM, "Brett Cannon" wrote: > > > On Sat, 3 Sep 2016 at 17:27 Yury Selivanov > wrote: > >> >> On 2016-09-03 5:19 PM, Brett Cannon wrot

Re: [Python-Dev] Tweak to PEP 523 for storing a tuple in co_extra

But without that new API (basically what Christian proposed) you'd need to iterate over the list in order to find the object that belongs to Pyjion. Yes. Yeah, which means the same for my opcode patch... Which unfortunately will make things slower :( If we manage t

Re: [Python-Dev] Tweak to PEP 523 for storing a tuple in co_extra

On Sat, 3 Sep 2016 at 17:27 Yury Selivanov wrote: > > On 2016-09-03 5:19 PM, Brett Cannon wrote: > > > > > > On Sat, 3 Sep 2016 at 16:43 Yury Selivanov > > wrote: > > > > > > > > On 2016-09-03 4:15 PM, Christian Heimes wrote: > > > On 2016-09-04 00:03, Yur

Re: [Python-Dev] Tweak to PEP 523 for storing a tuple in co_extra

On 2016-09-03 5:19 PM, Brett Cannon wrote: On Sat, 3 Sep 2016 at 16:43 Yury Selivanov > wrote: On 2016-09-03 4:15 PM, Christian Heimes wrote: > On 2016-09-04 00:03, Yury Selivanov wrote: >> >> On 2016-09-03 12:27 PM, Brett Cannon wrote: >

Re: [Python-Dev] Tweak to PEP 523 for storing a tuple in co_extra

On Sat, 3 Sep 2016 at 16:55 Yury Selivanov wrote: > > > On 2016-09-03 4:13 PM, Chris Angelico wrote: > > On Sun, Sep 4, 2016 at 8:03 AM, Yury Selivanov > wrote: > >> On 2016-09-03 12:27 PM, Brett Cannon wrote: > >>> Below is the `co_extra` section of PEP 523 with the update saying that > >>> use

Re: [Python-Dev] Tweak to PEP 523 for storing a tuple in co_extra

On Sat, 3 Sep 2016 at 16:43 Yury Selivanov wrote: > > > On 2016-09-03 4:15 PM, Christian Heimes wrote: > > On 2016-09-04 00:03, Yury Selivanov wrote: > >> > >> On 2016-09-03 12:27 PM, Brett Cannon wrote: > >>> Below is the `co_extra` section of PEP 523 with the update saying that > >>> users are

Re: [Python-Dev] Tweak to PEP 523 for storing a tuple in co_extra

On Sun, Sep 4, 2016 at 9:49 AM, Yury Selivanov wrote: > > > On 2016-09-03 4:13 PM, Chris Angelico wrote: >> Replace it, but only as they register themselves with a particular >> function. Imagine a profiler doing something vaguely like this: > > > "Replacing" makes it error prone to cache the poin

Re: [Python-Dev] Tweak to PEP 523 for storing a tuple in co_extra

On 2016-09-03 4:13 PM, Chris Angelico wrote: On Sun, Sep 4, 2016 at 8:03 AM, Yury Selivanov wrote: On 2016-09-03 12:27 PM, Brett Cannon wrote: Below is the `co_extra` section of PEP 523 with the update saying that users are expected to put a tuple in the field for easier simultaneous use of

Re: [Python-Dev] Tweak to PEP 523 for storing a tuple in co_extra

On 2016-09-03 4:15 PM, Christian Heimes wrote: On 2016-09-04 00:03, Yury Selivanov wrote: On 2016-09-03 12:27 PM, Brett Cannon wrote: Below is the `co_extra` section of PEP 523 with the update saying that users are expected to put a tuple in the field for easier simultaneous use of the field

Re: [Python-Dev] Tweak to PEP 523 for storing a tuple in co_extra

On 2016-09-04 00:03, Yury Selivanov wrote: > > > On 2016-09-03 12:27 PM, Brett Cannon wrote: >> Below is the `co_extra` section of PEP 523 with the update saying that >> users are expected to put a tuple in the field for easier simultaneous >> use of the field. >> >> Since the `co_extra` discussi

Re: [Python-Dev] Tweak to PEP 523 for storing a tuple in co_extra

On Sun, Sep 4, 2016 at 8:03 AM, Yury Selivanov wrote: > On 2016-09-03 12:27 PM, Brett Cannon wrote: >> >> Below is the `co_extra` section of PEP 523 with the update saying that >> users are expected to put a tuple in the field for easier simultaneous use >> of the field. >> >> Since the `co_extra`

Re: [Python-Dev] PEP 467: last round (?)

On Sun, Sep 4, 2016 at 1:23 AM, Ivan Levkivskyi wrote: > On 4 September 2016 at 00:11, Random832 wrote: >> >> On Sat, Sep 3, 2016, at 18:06, Koos Zevenhoven wrote: >> > I guess one reason I don't like bchr (nor chrb, really) is that they >> > look just like a random sequence of letters in builtin

Re: [Python-Dev] PEP 467: last round (?)

On 4 September 2016 at 00:11, Random832 wrote: > On Sat, Sep 3, 2016, at 18:06, Koos Zevenhoven wrote: > > I guess one reason I don't like bchr (nor chrb, really) is that they > > look just like a random sequence of letters in builtins, but not > > recognizable the way asdf would be. > > > > I gu

Re: [Python-Dev] PEP 467: last round (?)

On Sat, Sep 3, 2016 at 6:41 PM, Ethan Furman wrote: >>> >>> Open Questions >>> == >>> >>> Do we add ``iterbytes`` to ``memoryview``, or modify >>> ``memoryview.cast()`` to accept ``'s'`` as a single-byte interpretation? >>> Or >>> do we ignore memory for now and add it later? >> >> >>

Re: [Python-Dev] PEP 467: last round (?)

On Sat, Sep 3, 2016, at 18:06, Koos Zevenhoven wrote: > I guess one reason I don't like bchr (nor chrb, really) is that they > look just like a random sequence of letters in builtins, but not > recognizable the way asdf would be. > > I guess I have one last pair of suggestions for the name of this

Re: [Python-Dev] PEP 467: last round (?)

On Sat, Sep 3, 2016, at 08:08, Martin Panter wrote: > On 1 September 2016 at 19:36, Ethan Furman wrote: > > Deprecation of current "zero-initialised sequence" behaviour without removal > > > > > > Currently, the ``bytes

Re: [Python-Dev] PEP 467: last round (?)

On Sat, Sep 3, 2016 at 7:59 PM, Nick Coghlan wrote: > On 3 September 2016 at 03:54, Koos Zevenhoven wrote: >> chrb seems to be more in line with some bytes versions in for instance os >> than bchr. > > The mnemonic for the current name in the PEP is that bchr is to chr as > b"" is to "". The PEP

Re: [Python-Dev] Tweak to PEP 523 for storing a tuple in co_extra

On 2016-09-03 12:27 PM, Brett Cannon wrote: Below is the `co_extra` section of PEP 523 with the update saying that users are expected to put a tuple in the field for easier simultaneous use of the field. Since the `co_extra` discussions do not affect CPython itself I'm planning on landing t

Re: [Python-Dev] PEP 526 ready for review: Syntax for Variable and Attribute Annotations

On 2016-08-30 2:20 PM, Guido van Rossum wrote: I'm happy to present PEP 526 for your collective review: https://www.python.org/dev/peps/pep-0526/ (HTML) https://github.com/python/peps/blob/master/pep-0526.txt (source) There's also an implementation ready: https://github.com/ilevkivskyi/cpython

[Python-Dev] Tweak to PEP 523 for storing a tuple in co_extra

Below is the `co_extra` section of PEP 523 with the update saying that users are expected to put a tuple in the field for easier simultaneous use of the field. Since the `co_extra` discussions do not affect CPython itself I'm planning on landing the changes stemming from the PEP probably on Monday

Re: [Python-Dev] PEP 525, third round, better finalization

Hi Oscar, I don't think PyPy is in breach of the language spec here. Python made a decision a long time ago to shun RAII-style implicit cleanup in favour if with-style explicit cleanup. The solution to this problem is to move resource management outside of the generator functions. This is true f

Re: [Python-Dev] PEP 525, third round, better finalization

On 4 September 2016 at 04:38, Oscar Benjamin wrote: > On 3 September 2016 at 16:42, Nick Coghlan wrote: >> On 2 September 2016 at 19:13, Nathaniel Smith wrote: >>> This works OK on CPython because the reference-counting gc will call >>> handle.__del__() at the end of the scope (so on CPython it'

Re: [Python-Dev] PEP 525, third round, better finalization

Hi Nathaniel, On 2016-09-02 2:13 AM, Nathaniel Smith wrote: On Thu, Sep 1, 2016 at 3:34 PM, Yury Selivanov wrote: Hi, I've spent quite a while thinking and experimenting with PEP 525 trying to figure out how to make asynchronous generators (AG) finalization reliable. I've tried to replace the

Re: [Python-Dev] PEP 525, third round, better finalization

On 3 September 2016 at 16:42, Nick Coghlan wrote: > On 2 September 2016 at 19:13, Nathaniel Smith wrote: >> This works OK on CPython because the reference-counting gc will call >> handle.__del__() at the end of the scope (so on CPython it's at level >> 2), but it famously causes huge problems whe

Re: [Python-Dev] PEP 529: Change Windows filesystem encoding to UTF-8

Nick Coghlan (ncoghlan at gmail.com) on Sat Sep 3 12:27:44 EDT 2016 wrote: > After also reading the Windows console encoding PEP, I realised > there's a couple of missing discussions here regarding the impacts on > sys.argv, os.environ, and os.environb. > > The reason that's relevant is that "sys.

Re: [Python-Dev] PEP 467: last round (?)

On 3 September 2016 at 03:54, Koos Zevenhoven wrote: > chrb seems to be more in line with some bytes versions in for instance os > than bchr. The mnemonic for the current name in the PEP is that bchr is to chr as b"" is to "". The PEP should probably say that in addition to pointing out the 'unic

Re: [Python-Dev] PEP 467: last round (?)

On 3 September 2016 at 21:35, Martin Panter wrote: >> Le samedi 3 septembre 2016, Random832 a écrit : >>> On Fri, Sep 2, 2016, at 19:44, Ethan Furman wrote: >>> > The problem with only having `bchr` is that it doesn't help with >>> > `bytearray`; >>> >>> What is the use case for bytearray.fromord

Re: [Python-Dev] PEP 529: Change Windows filesystem encoding to UTF-8

On 4 September 2016 at 00:49, Nick Coghlan wrote: > On 2 September 2016 at 08:31, Steve Dower wrote: >> This proposal would remove all use of the *A APIs and only ever call the *W >> APIs. When Windows returns paths to Python as str, they will be decoded from >> utf-16-le and returned as text (in

Re: [Python-Dev] Update on PEP 523 and adding a co_extra field to code objects

On Sun, Sep 4, 2016 at 2:09 AM, Nick Coghlan wrote: > On 3 September 2016 at 08:50, Chris Angelico wrote: >> Got it, thanks. I hope the vagaries of linear search don't mess with >> profilers - a debugger isn't going to be bothered by whether it gets >> first slot or second, but profiling and perf

Re: [Python-Dev] [erratum] Emotional responses to PEPs 484 and 526

On Sat, Sep 3, 2016 at 8:18 AM, Stephen J. Turnbull wrote: > Stephen J. Turnbull writes: > > > My version ... furthermore makes mypy into a units checker, > > That isn't true, mypy does want annotations on all the variables it > checks and does not infer them from initializer type. But it does!

Re: [Python-Dev] Update on PEP 523 and adding a co_extra field to code objects

On 3 September 2016 at 08:50, Chris Angelico wrote: > Got it, thanks. I hope the vagaries of linear search don't mess with > profilers - a debugger isn't going to be bothered by whether it gets > first slot or second, but profiling and performance might get subtle > differences based on which thin

Re: [Python-Dev] What should a good type checker do? (was: Please reject or postpone PEP 526)

What's up with the weird subthreads, Stephen?! On Guido's suggestion, I'm working on posting those type-checking thoughts here. -- Koos On Sat, Sep 3, 2016 at 6:17 PM, Stephen J. Turnbull wrote: > Please respect Reply-To, set to python-ideas. > > Greg Ewing writes: > > Chris Angelico wrote: >

Re: [Python-Dev] PEP 525, third round, better finalization

On 2 September 2016 at 19:13, Nathaniel Smith wrote: > This works OK on CPython because the reference-counting gc will call > handle.__del__() at the end of the scope (so on CPython it's at level > 2), but it famously causes huge problems when porting to PyPy with > it's much faster and more sophi

Re: [Python-Dev] PEP 467: last round (?)

On 09/02/2016 06:17 PM, Greg Ewing wrote: Ethan Furman wrote: The problem with only having `bchr` is that it doesn't help with `bytearray`; the problem with not having `bchr` is who wants to write `bytes.fromord`? If we called it 'bytes.fnord' (From Numeric Ordinal) people would want to wr

Re: [Python-Dev] PEP 467: last round (?)

On 09/03/2016 05:08 AM, Martin Panter wrote: On 1 September 2016 at 19:36, Ethan Furman wrote: Deprecation of current "zero-initialised sequence" behaviour without removal Currently, the ``bytes`` and ``bytearray`` c

Re: [Python-Dev] [erratum] Emotional responses to PEPs 484 and 526

On 3 September 2016 at 17:18, Stephen J. Turnbull < turnbull.stephen...@u.tsukuba.ac.jp> wrote: > Stephen J. Turnbull writes: > > > My version ... furthermore makes mypy into a units checker, > > That isn't true, mypy does want annotations on all the variables it > checks and does not infer them

[Python-Dev] [erratum] Emotional responses to PEPs 484 and 526

Stephen J. Turnbull writes: > My version ... furthermore makes mypy into a units checker, That isn't true, mypy does want annotations on all the variables it checks and does not infer them from initializer type. Sorry for the misinformation. ___ Pyth

Re: [Python-Dev] What should a good type checker do? (was: Please reject or postpone PEP 526)

Please respect Reply-To, set to python-ideas. Greg Ewing writes: > Chris Angelico wrote: > > Forcing people to write 1.0 just to be compatible with 1.5 will cause > > a lot of annoyance. > > Indeed, this would be unacceptable IMO. But "forcing" won't happen. Just ignore the warning. *All*

Re: [Python-Dev] PEP 529: Change Windows filesystem encoding to UTF-8

On 2 September 2016 at 08:31, Steve Dower wrote: > This proposal would remove all use of the *A APIs and only ever call the *W > APIs. When Windows returns paths to Python as str, they will be decoded from > utf-16-le and returned as text (in whatever the minimal representation is). > When > Windo

Re: [Python-Dev] [New-bugs-announce] [issue27948] f-strings: allow backslashes only in the string parts, not in the expression parts

I'm aware of the buildbot failures due to this commit. I'm working on it. Sorry about that: tests passed on my machine. Eric. On 09/03/2016 09:24 AM, Eric V. Smith wrote: > > New submission from Eric V. Smith: > > See issue 27921. > > Currently (and for 3.6 beta 1), backslashes are not allowe

Re: [Python-Dev] PEP 528: Change Windows console encoding to UTF-8

On 1 September 2016 at 23:28, Random832 wrote: > On Thu, Sep 1, 2016, at 18:28, Steve Dower wrote: >> This is a raw (bytes) IO class that requires text to be passed encoded >> with utf-8, which will be decoded to utf-16-le and passed to the Windows >> APIs. >> Similarly, bytes read from the class

Re: [Python-Dev] Emotional responses to PEPs 484 and 526

On 3 September 2016 at 18:03, Stephen J. Turnbull wrote: > Therefore, I think Nick's version was an abuse of variable annotation. > I don't mean to criticize Nick, as he was trying to make the best of > an unlikely proposal. But if Nick can fall into this trap[2], I think > the fears of many that

Re: [Python-Dev] PEP 526 ready for review: Syntax for Variable and Attribute Annotations

On 3 September 2016 at 02:17, Guido van Rossum wrote: > Pinning down the semantics is not why I am pushing for PEP 526 -- I > only want to pin down the *syntax* to the point where we won't have to > change it again for many versions, since it's much harder to change > the syntax than it is to chan

Re: [Python-Dev] PEP 467: last round (?)

On 1 September 2016 at 19:36, Ethan Furman wrote: > Deprecation of current "zero-initialised sequence" behaviour without removal > > > Currently, the ``bytes`` and ``bytearray`` constructors accept an integer > argument a

Re: [Python-Dev] PEP 467: last round (?)

> Le samedi 3 septembre 2016, Random832 a écrit : >> On Fri, Sep 2, 2016, at 19:44, Ethan Furman wrote: >> > The problem with only having `bchr` is that it doesn't help with >> > `bytearray`; >> >> What is the use case for bytearray.fromord? Even in the rare case >> someone needs it, why not bytea

Re: [Python-Dev] PEP 467: last round (?)

On 2 September 2016 at 17:54, Koos Zevenhoven wrote: > On Thu, Sep 1, 2016 at 10:36 PM, Ethan Furman wrote: >> * Deprecate passing single integer values to ``bytes`` and ``bytearray`` >> * Add ``bytes.fromsize`` and ``bytearray.fromsize`` alternative >> constructors >> * Add ``bytes.fromord`` and

Re: [Python-Dev] PEP 528: Change Windows console encoding to UTF-8

> > The use of an ASCII compatible encoding is required to maintain > compatibility with code that bypasses the TextIOWrapper and directly > writes ASCII bytes to the standard streams (for example, > [process_stdinreader.py] > ). >

Re: [Python-Dev] PEP 528: Change Windows console encoding to UTF-8

Steve Dower (steve.dower at python.org) on Thu Sep 1 18:28:53 EDT 2016 wrote I'm about to be offline for a few days, so I wanted to get my current > draft PEPs out for people can read and review. > > I don't believe there is a lot of change as a result of either PEP, but > the impact of what chang

Re: [Python-Dev] PEP 528: Change Windows console encoding to UTF-8

Paul Moore (p.f.moore at gmail.com) on Fri Sep 2 05:23:04 EDT 2016 wrote > > On 2 September 2016 at 03:35, Steve Dower > wrote: > >* I'd need to test to be sure, but writing an incomplete code point should > *>* just truncate to before that poi

[Python-Dev] Emotional responses to PEPs 484 and 526

Guido van Rossum writes: > I just spoke to someone who noted that [PEP 526] is likely to evoke > an outsize emotional response. (Similar to what happened with PEP 484.) Emotional, yes, but I resent the "outsize" part. Although that word to the wise is undoubtedly enough, i.e., tl:dr if you lik

Re: [Python-Dev] PEP 467: last round (?)

Yes, this was my point: I don't think that we need a bytearray method to create a mutable string from a single byte. Victor Le samedi 3 septembre 2016, Random832 a écrit : > On Fri, Sep 2, 2016, at 19:44, Ethan Furman wrote: > > The problem with only having `bchr` is that it doesn't help with >