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

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 write it just for the fun factor. -- Greg

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

On Fri, 2 Sep 2016 at 17:37 MRAB wrote: > On 2016-09-02 23:45, Brett Cannon wrote: > > > > > > On Fri, 2 Sep 2016 at 15:11 Chris Angelico > > wrote: > > > > On Sat, Sep 3, 2016 at 7:56 AM, Brett Cannon

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

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. The checker could have a type 'smallint' that it considers promotable to float. But that wouldn't avoid the problem entirely, because e.g.

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

On 2016-09-02 23:45, Brett Cannon wrote: On Fri, 2 Sep 2016 at 15:11 Chris Angelico > wrote: On Sat, Sep 3, 2016 at 7:56 AM, Brett Cannon > wrote: > On Fri, 2 Sep 2016 at 13:31 Dino Viehland via

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

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 bytearray(bchr(...))? ___

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

On 09/01/2016 04:07 PM, Victor Stinner wrote: 2016-09-02 0:04 GMT+02:00 Ethan Furman: - `fromord` to replace the mistaken purpose of the default constructor To replace a bogus bytes(obj)? If someone writes bytes(obj) but expect to create a byte string from an integer, why not using bchr()

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

On Fri, Sep 2, 2016, at 18:49, Koos Zevenhoven wrote: > Then again, (b) instead of that being working code, it might be an > error and spam only takes float. No problem, the type checker will > catch that. There are very few functions that should only take float and not int. > On Fri, Sep 2,

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

Won't you ll agree that this thread belongs on python-ideas? -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe:

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

On Sat, Sep 3, 2016 at 8:49 AM, Koos Zevenhoven wrote: > On Fri, Sep 2, 2016 at 9:04 PM, Steven D'Aprano wrote: >> On Fri, Sep 02, 2016 at 08:10:24PM +0300, Koos Zevenhoven wrote: >> >>> A good checker should be able to infer that x is a union type at the

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

On Sat, Sep 3, 2016 at 8:45 AM, Brett Cannon wrote: >> I'm not following how this solves the collision problem. If you have a >> tuple, how do the two (or more) users of it know which index they're >> using? They'd need to keep track separately for each object, or else >>

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

On Fri, Sep 2, 2016 at 9:04 PM, Steven D'Aprano wrote: > On Fri, Sep 02, 2016 at 08:10:24PM +0300, Koos Zevenhoven wrote: > >> A good checker should be able to infer that x is a union type at the >> point that it's passed to spam, even without the type annotation. For >>

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

On Fri, 2 Sep 2016 at 15:11 Chris Angelico wrote: > On Sat, Sep 3, 2016 at 7:56 AM, Brett Cannon wrote: > > On Fri, 2 Sep 2016 at 13:31 Dino Viehland via Python-Dev > > wrote: > >> > >> So it looks like both list and tuple are about

[Python-Dev] Updated version of PEP 526 (Syntax for Variable Annotations)

We've prepared an updated version of PEP 526: https://www.python.org/dev/peps/pep-0526/ This changes the title to "Syntax for Variable Annotations", now that we've settled on global, class, instance, and local variables as the things you might annotate. There is one substantial change: where the

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

On Sat, Sep 3, 2016 at 7:56 AM, Brett Cannon wrote: > On Fri, 2 Sep 2016 at 13:31 Dino Viehland via Python-Dev > wrote: >> >> So it looks like both list and tuple are about within 5% of using co_extra >> directly. Using a tuple instead of a list is about

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

On Fri, 2 Sep 2016 at 13:31 Dino Viehland via Python-Dev < python-dev@python.org> wrote: > So it looks like both list and tuple are about within 5% of using co_extra > directly. Using a tuple instead of a list is about a wash except for > make_v2 where list is 1.4x slower for some reason (which

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

So it looks like both list and tuple are about within 5% of using co_extra directly. Using a tuple instead of a list is about a wash except for make_v2 where list is 1.4x slower for some reason (which I didn't dig into). I would say that using a tuple and copying the tuple on updates makes

Re: [Python-Dev] Please reject or postpone PEP 526

On Fri, Sep 2, 2016 at 10:47 AM, Steve Dower wrote: > "I'm not seeing what distinction you think you are making here. What > distinction do you see between: > > x: int = func(value) > > and > > x = func(value) # type: int" > > Not sure whether I agree with Mark on

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

So I ran the tests with both a list and a tuple. They were about 5% slower on a handful of benchmarks, and then the difference between the tuple and list again had a few benchmarks that were around 5% slower. There was one benchmark where the tuple one significantly for some reason (mako_v2)

Re: [Python-Dev] Need help in debugging the python core

Yes Thanks and Regards, Amresh From: Burkhard Meier Date: Saturday, September 3, 2016 at 12:12 AM To: Amresh Sajjanshetty Cc: "python-dev@python.org" Subject: Re: [Python-Dev] Need help in debugging the python

Re: [Python-Dev] Need help in debugging the python core

You are using bash? On Sep 2, 2016 8:56 AM, "Sajjanshetty, Amresh" < amresh.sajjanshe...@netapp.com> wrote: > Dear All, > > > > I’m using asyncio and paramiko to multiplex different channels into a > single SSH connection. Things were working fine till recently but suddenly > started seeing that

Re: [Python-Dev] Need help in debugging the python core

Surprisingly I’m not seeing the core dump/crash after adding ‘faulthandler.enable()’ . Would it catch the signal and ignore by default? Thanks and Regards, Amresh From: Burkhard Meier Date: Friday, September 2, 2016 at 11:19 PM To: Victor Stinner

Re: [Python-Dev] Please reject or postpone PEP 526

[Replying to Steve Dower] On Sat, Sep 03, 2016 at 04:19:13AM +1000, Steven D'Aprano wrote: > On Fri, Sep 02, 2016 at 10:47:41AM -0700, Steve Dower wrote: > > "I'm not seeing what distinction you think you are making here. What > > distinction do you see between: > > > > x: int = func(value)

Re: [Python-Dev] Please reject or postpone PEP 526

On Fri, Sep 02, 2016 at 10:47:41AM -0700, Steve Dower wrote: > "I'm not seeing what distinction you think you are making here. What > distinction do you see between: > > x: int = func(value) > > and > > x = func(value) #type: int" > > Not sure whether I agree with Mark on this

Re: [Python-Dev] Please reject or postpone PEP 526

On Fri, Sep 02, 2016 at 08:10:24PM +0300, Koos Zevenhoven wrote: > A good checker should be able to infer that x is a union type at the > point that it's passed to spam, even without the type annotation. For > example: > > def eggs(cond:bool): > if cond: > x = 1 > else: >

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

On 2 September 2016 at 18:17, Guido van Rossum wrote: > On Fri, Sep 2, 2016 at 6:43 AM, Ivan Levkivskyi wrote: > > On 2 September 2016 at 04:38, Nick Coghlan wrote: > >> However, a standalone Ellipsis doesn't currently have a meaning

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

Some quick comments below, a few more later: On Thu, Sep 1, 2016 at 10:36 PM, Ethan Furman wrote: > One more iteration. PEPs repo not updated yet. Changes are renaming of > methods to be ``fromsize()`` and ``fromord()``, and moving ``memoryview`` to > an Open Questions

Re: [Python-Dev] Need help in debugging the python core

How could I help? Burkhard On Fri, Sep 2, 2016 at 10:47 AM, Victor Stinner wrote: > Oh, I forgot to mention that it would help to get the Python traceback > on the crash. Try faulthandler: add faulthandler.enable() at the > beginning of your program. >

Re: [Python-Dev] Please reject or postpone PEP 526

On 2 September 2016 at 17:59, Guido van Rossum wrote: > On Fri, Sep 2, 2016 at 6:47 AM, Mark Shannon wrote: > > Quoting from the PEP: > > ``` > > a: int > > a: str # Static type checker will warn about this. > > ``` > > In other words, it is illegal for a

Re: [Python-Dev] Please reject or postpone PEP 526

"I'm not seeing what distinction you think you are making here. What distinction do you see between: x: int = func(value) and x = func(value) #type: int" Not sure whether I agree with Mark on this particular point, but the difference I see here is that the first describes what types

Re: [Python-Dev] Need help in debugging the python core

Oh, I forgot to mention that it would help to get the Python traceback on the crash. Try faulthandler: add faulthandler.enable() at the beginning of your program. https://docs.python.org/dev/library/faulthandler.html Maybe I should write once tools to debug such bug :-) Victor

Re: [Python-Dev] Need help in debugging the python core

2016-09-02 8:49 GMT+02:00 Sajjanshetty, Amresh : > I’m using asyncio and paramiko to multiplex different channels into a single > SSH connection. Hum, asyncio found bugs in CPython. Please try with a more recent version of CPython than 3.4.3 :-/ > Program

Re: [Python-Dev] Please reject or postpone PEP 526

I agree about some concerns and disagree about several. I see most use for class/instance attribute annotations, both for type checking and for other uses. I'm least sure about their syntax and about annotations in functions or at module level in the proposed form. Below some comments: On Fri,

Re: [Python-Dev] Please reject or postpone PEP 526

Hi Mark, I agree with you about postponing. Not so much because of the issues you mentioned. Those all seem resolvable to me and mostly concerns type checkers, linters and coding styles not Python itself. However, I also don't like the rushing through as if this beta were the only chance to

Re: [Python-Dev] Please reject or postpone PEP 526

Hi Mark, I'm going to trim your post drastically, down to the bare essentials, in order to keep this already long post down to a manageable size. On Fri, Sep 02, 2016 at 02:47:00PM +0100, Mark Shannon wrote: [...] > With type comments, this is intuitively correct and should type check: > def

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

On Fri, Sep 2, 2016 at 6:43 AM, Ivan Levkivskyi wrote: > On 2 September 2016 at 04:38, Nick Coghlan wrote: >> However, a standalone Ellipsis doesn't currently have a meaning as a >> type annotation (it's only meaningful when subscripting Tuple and >>

[Python-Dev] Summary of Python tracker Issues

ACTIVITY SUMMARY (2016-08-26 - 2016-09-02) Python tracker at http://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: open5630 (+24) closed 34067 (+49) total 39697 (+73) Open issues

Re: [Python-Dev] Please reject or postpone PEP 526

On Fri, Sep 2, 2016 at 6:47 AM, Mark Shannon wrote: > Hi everyone, > > I think we should reject, or at least postpone PEP 526. > > PEP 526 represents a major change to the language, however there are, I > believe, a number of technical flaws with the PEP. > > It is probable that

[Python-Dev] Need help in debugging the python core

Dear All, I’m using asyncio and paramiko to multiplex different channels into a single SSH connection. Things were working fine till recently but suddenly started seeing that python getting crashed whenever I tried to write to the channel. I have very limited knowledge on how python

Re: [Python-Dev] Please reject or postpone PEP 526

On Sep 2, 2016 8:51 AM, "Mark Shannon" wrote: > > Hi everyone, > > I think we should reject, or at least postpone PEP 526. > > PEP 526 represents a major change to the language, however there are, I believe, a number of technical flaws with the PEP. > > It is probable that with

[Python-Dev] Please reject or postpone PEP 526

Hi everyone, I think we should reject, or at least postpone PEP 526. PEP 526 represents a major change to the language, however there are, I believe, a number of technical flaws with the PEP. It is probable that with significant revisions it can be a worthwhile addition to the language, but

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

On 1 September 2016 at 22:37, Guido van Rossum wrote: > On Thu, Sep 1, 2016 at 9:30 AM, Ivan Levkivskyi wrote: > > There is a convention for function annotations in PEP 484 that a missing > > annotation is equivalent to Any, so that I like your first

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

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 point. It may currently raise OSError if that > truncated to zero length, as I believe that's not currently

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

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 callback for GCed with a

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

On 1 September 2016 at 23:31, Steve Dower wrote: [...] > As a result, POSIX-focused library authors prefer to use bytes to represent > paths. A minor point, but in my experience, a lot of POSIX-focused authors are happy to move to a better text/bytes separation, so I'd