Re: [Python-Dev] Can Python guarantee the order of keyword-only parameters?

On Mon, Nov 27, 2017 at 10:05 AM, Larry Hastings wrote: > I'd like inspect.signature to guarantee that the order of keyword-only > parameters always matches the order they were declared in. Technically this > isn't a language feature, it's a library feature. But making this

Re: [Python-Dev] Python initialization and embedded Python

On Mon, Nov 20, 2017 at 3:03 PM, Victor Stinner wrote: > To statically initialize PyMemAllocatorEx fields, you need to export a > lot of allocator functions. I would prefer to not do that. > > [snip] > > The rules to choose the allocator to each domain are also complex >

Re: [Python-Dev] Python initialization and embedded Python

On Mon, Nov 20, 2017 at 8:43 AM, Victor Stinner <victor.stin...@gmail.com> wrote: > 2017-11-20 16:31 GMT+01:00 Eric Snow <ericsnowcurren...@gmail.com>: >> That Py_DecodeLocale() can use PyMem_RawMalloc() pre-init is an >> implementation detail. > > Py_DecodeLocale

Re: [Python-Dev] Python initialization and embedded Python

On Nov 18, 2017 19:20, "Nick Coghlan" wrote: OK, in that case I think the answer to Victor's question is: 1. Breaking calling Py_DecodeLocale() before calling Py_Initialize() is a compatibility break with the API implied by our own usage examples, and we'll need to revert

Re: [Python-Dev] The current dict is not an "OrderedDict"

On Nov 7, 2017 08:12, "INADA Naoki" wrote: Additionally, class namespace should keep insertion order. It's language spec from 3.6. So we should have two mode for such optimization. It makes dict more complicated. FWIW, PEP 520 (Preserving Class Attribute Definition

Re: [Python-Dev] PEP 554 v3 (new interpreters module)

On Thu, Oct 5, 2017 at 4:57 AM, Nick Coghlan wrote: > This would be hard to get to work reliably, because "orig.tp_share()" would > be running in the receiving interpreter, but all the attributes of "orig" > would have been allocated by the sending interpreter. It gets more

Re: [Python-Dev] PEP 554 v3 (new interpreters module)

On Tue, Oct 3, 2017 at 8:55 AM, Antoine Pitrou wrote: > I think we need a sharing protocol, not just a flag. We also need to > think carefully about that protocol, so that it does not imply > unnecessary memory copies. Therefore I think the protocol should be > something

Re: [Python-Dev] PEP 554 v3 (new interpreters module)

On Tue, Oct 3, 2017 at 11:36 PM, Nick Coghlan wrote: > The problem relates to the fact that there aren't any memory barriers > around CPython's INCREF operations (they're implemented as an ordinary > C post-increment operation), so you can get the following scenario: > > *

Re: [Python-Dev] PEP 554 v3 (new interpreters module)

On Tue, Oct 3, 2017 at 5:00 AM, Antoine Pitrou <solip...@pitrou.net> wrote: > On Mon, 2 Oct 2017 22:15:01 -0400 > Eric Snow <ericsnowcurren...@gmail.com> wrote: >> >> I'm still not convinced that sharing synchronization primitives is >> important enough to be wo

Re: [Python-Dev] PEP 554 v3 (new interpreters module)

On Wed, Sep 27, 2017 at 1:26 AM, Nick Coghlan wrote: > It's also the case that unlike Go channels, which were designed from > scratch on the basis of implementing pure CSP, FWIW, Go's channels (and goroutines) don't implement pure CSP. They provide a variant that the Go

Re: [Python-Dev] PEP 554 v3 (new interpreters module)

On Mon, Sep 25, 2017 at 8:42 PM, Nathaniel Smith wrote: > It's fairly reasonable to implement a mutex using a CSP-style > unbuffered channel (send = acquire, receive = release). And the same > trick turns a channel with a fixed-size buffer into a bounded > semaphore. It won't be

Re: [Python-Dev] PEP 554 v3 (new interpreters module)

On Mon, Oct 2, 2017 at 9:31 PM, Eric Snow <ericsnowcurren...@gmail.com> wrote: > On DECREF there shouldn't be a problem except possibly with a small > race between decrementing the refcount and checking for a refcount of > 0. We could address that several different ways, inc

Re: [Python-Dev] PEP 554 v3 (new interpreters module)

After having looked it over, I'm leaning toward supporting buffering, as well as not blocking by default. Neither adds much complexity to the implementation. On Sat, Sep 23, 2017 at 5:45 AM, Antoine Pitrou <solip...@pitrou.net> wrote: > On Fri, 22 Sep 2017 19:09:01 -0600 &g

Re: [Python-Dev] PEP 554 v3 (new interpreters module)

On Thu, Sep 14, 2017 at 8:44 PM, Nick Coghlan wrote: > Not really, because the only way to ensure object separation (i.e no > refcounted objects accessible from multiple interpreters at once) with > a bytes-based API would be to either: > > 1. Always copy (eliminating most of

Re: [Python-Dev] PEP 554 v3 (new interpreters module)

Thanks for the feedback, Antoine. Sorry for the delay; it's been a busy week for me. I just pushed an updated PEP to the repo. Once I've sorted out the question of passing bytes through channels I plan on posting the PEP to the list again for another round of discussion. In the meantime, I've

[Python-Dev] PEP 554 v3 (new interpreters module)

has moved down below the examples Please let me know what you think. I'm especially interested in feedback about the channels. Thanks! -eric PEP: 554 Title: Multiple Interpreters in the Stdlib Author: Eric Snow <ericsnowcurren...@gmail.com> Sta

Re: [Python-Dev] PEP 554 v2 (new "interpreters" module)

On Sat, Sep 9, 2017 at 11:04 AM, Nathaniel Smith wrote: > This phrase "bubble up" here is doing a lot of work :-). Can you elaborate > on what you mean? The text now makes it seem like the exception will just > pass from one interpreter into another, but that seems impossible

Re: [Python-Dev] PEP 554 v2 (new "interpreters" module)

On Sat, Sep 9, 2017 at 5:05 AM, Antoine Pitrou <solip...@pitrou.net> wrote: > On Fri, 8 Sep 2017 16:04:27 -0700, Eric Snow <ericsnowcurren...@gmail.com> > wrote: >> ``list()``:: > > It's called ``enumerate()`` in the threading module. Not sure there's > a point

Re: [Python-Dev] PEP 554 v2 (new "interpreters" module)

On Sat, Sep 9, 2017 at 4:45 AM, Antoine Pitrou wrote: > How does the other interpreter get the FIFO "tied" to it? > Is it `get_current().get_fifo(name)`? Something else? Yep, that's it. I've added some examples to the PEP to illustrate. That said, I'm re-working the method

Re: [Python-Dev] PEP 554 v2 (new "interpreters" module)

On Fri, Sep 8, 2017 at 8:54 PM, Michel Desmoulin wrote: > Le 09/09/2017 à 01:28, Stefan Krah a écrit : >> Still, the argument "who uses subinterpreters?" of course still remains. > > For now, nobody. But if we expose it and web frameworks manage to create > workers as

Re: [Python-Dev] PEP 554 v2 (new "interpreters" module)

On Sat, Sep 9, 2017 at 1:04 AM, Paul Moore <p.f.mo...@gmail.com> wrote: > On 9 September 2017 at 00:04, Eric Snow <ericsnowcurren...@gmail.com> wrote: >>add_recv_fifo(name=None): >>add_send_fifo(name=None): > > Personally, I *always* read the

Re: [Python-Dev] PEP 554 v2 (new "interpreters" module)

On Fri, Sep 8, 2017 at 4:28 PM, Stefan Krah wrote: > The most promising model to me is to put *all* globals in a tls structure > and cache the whole structure. Extrapolating from my experiences with the > context, this might have a slowdown of "only" 4%. Yeah, this is

[Python-Dev] PEP 554 v2 (new "interpreters" module)

Title: Multiple Interpreters in the Stdlib Author: Eric Snow <ericsnowcurren...@gmail.com> Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 2017-09-05 Python-Version: 3.7 Post-History: Abstract This proposal introduces the stdlib ``interpreters`` module. It e

Re: [Python-Dev] [RFC] Removing pure Python implementation of OrderedDict

On Tue, Sep 5, 2017 at 1:38 AM, INADA Naoki wrote: > Like that, how about removing OrderedDict Pure Python implementation > from stdlib and require it to implementation? -1 Like Antoine, I consider the pure Python implementation to be valuable. Furthermore, the pure

Re: [Python-Dev] PEP 550 V5

Nice working staying on top of this! Keeping up with discussion is arguably much harder than actually writing the PEP. :) I have some comments in-line below. -eric On Fri, Sep 1, 2017 at 5:02 PM, Yury Selivanov wrote: > [snip] > > Abstract > > > [snip] > >

Re: [Python-Dev] PEP 550 v4

On Sat, Aug 26, 2017 at 10:31 AM, Yury Selivanov wrote: > On Sat, Aug 26, 2017 at 9:33 AM, Sven R. Kunze wrote: > [..] >> Why not the same interface as thread-local storage? This has been the >> question which bothered me from the beginning of PEP550. I

Re: [Python-Dev] PEP 550 v4

On Sat, Aug 26, 2017 at 3:09 PM, Nathaniel Smith wrote: > You might be interested in these notes I wrote to motivate why we need > a chain of namespaces, and why simple "async task locals" aren't > sufficient: > >

Re: [Python-Dev] PEP 550 v4

On Sat, Aug 26, 2017 at 11:19 AM, Yury Selivanov wrote: > This is similar to namedtuples, and nobody really complains about them. FWIW, there are plenty of complaints on python-ideas about this (and never a satisfactory solution). :) That said, I don't think it is as

Re: [Python-Dev] PEP 550 v4

Thanks for the update. Comments in-line below. -eric On Fri, Aug 25, 2017 at 4:32 PM, Yury Selivanov wrote: > [snip] > > This PEP adds a new generic mechanism of ensuring consistent access > to non-local state in the context of out-of-order execution, such > as in

Re: [Python-Dev] Scope, not context? (was Re: PEP 550 v3 naming)

On Fri, Aug 25, 2017 at 9:10 AM, Barry Warsaw wrote: > It’s ideas like this that do make me think of scopes when talking about > global state and execution contexts. I understand that the current PEP 550 > invokes an explicit separate namespace, Right. The observation that

Re: [Python-Dev] Scope, not context? (was Re: PEP 550 v3 naming)

On Fri, Aug 25, 2017 at 8:18 AM, Yury Selivanov wrote: > Another idea: > > 1. We alter PyModule to make it possible to add properties (descriptor > protocol, or we implement custom __getattr__). I think we can make it > so that only sys module would be able to actually

Re: [Python-Dev] PEP 550 v3 naming

On Thu, Aug 24, 2017 at 5:37 AM, Nick Coghlan wrote: > Migrating a (variant of a) naming subthread from python-ideas over to > here, does the following sound plausible to anyone else?: > > ContextLocal - read/write access API (via get()/set() methods) >

Re: [Python-Dev] Scope, not context? (was Re: PEP 550 v3 naming)

On Thu, Aug 24, 2017 at 8:23 AM, Yury Selivanov wrote: > Contrary to scoping, the programmer is much less likely to deal with > Execution Context. How often do we use "threading.local()"? This is an important point. PEP 550 is targeting library authors, right? Most

Re: [Python-Dev] Scope, not context? (was Re: PEP 550 v3 naming)

On Thu, Aug 24, 2017 at 7:52 AM, Barry Warsaw wrote: > Guido van Rossum wrote: >> On Tue, Aug 22, 2017 at 7:12 PM, Nathaniel Smith wrote: >> >> I worry that that's going to lead more people astray thinking this has >> something to do with contextlib, which it

Re: [Python-Dev] startup time repeated? why not daemon

On Thu, Jul 20, 2017 at 11:53 AM, Jim J. Jewett wrote: > I agree that startup time is a problem, but I wonder if some of the pain > could be mitigated by using a persistent process. > > [snip] > > Is it too hard to create a daemon server? > Is the communication and context

Re: [Python-Dev] 2017 Python Language Summit coverage

On Thu, May 25, 2017 at 7:03 AM, Jake Edge wrote: > > Hola python-dev, > > Thanks to Larry and Barry, I was able to sit in on the Python Language > Summit again this year. The start of the coverage for that is now > available. > > [snipped] > > Hopefully I captured things

Re: [Python-Dev] why _PyGen_Finalize(gen) propagates close() to _PyGen_yf() ?

On Mon, Mar 20, 2017 at 11:30 AM, Oleg Nesterov wrote: > Hello, > > Let me first clarify, I do not claim this is a bug, I am trying to learn > python and now I trying to understand yield-from. Given that you haven't gotten a response here, you may want to take this over to the

Re: [Python-Dev] Benchmarking Python and micro-optimizations

On Thu, Oct 20, 2016 at 4:56 AM, Victor Stinner wrote: > Hi, > > Last months, I worked a lot on benchmarks. I ran benchmarks, analyzed > results in depth (up to the hardware and kernel drivers!), I wrote new > tools and enhanced existing tools. This is a massive

Re: [Python-Dev] Update to PEP 1 re: content type

On Thu, Oct 13, 2016 at 3:59 PM, Barry Warsaw wrote: > I don't understand the question: isn't the whole point of reST that it's a > easily readable markup language? Just post the reST! +1 -eric ___ Python-Dev mailing list

Re: [Python-Dev] Python 3.6 dict becomes compact and gets a private version; and keywords become ordered

On Tue, Sep 20, 2016 at 5:11 AM, INADA Naoki wrote: > But both of OrderedDict and lru_cache improvements can't be in 3.6 > since 3.6 is beta now. > I'll try it after 3.6rc1. When you do, make sure you keep in mind the performance constraints of *all* the OrderedDict

Re: [Python-Dev] Python 3.6 dict becomes compact and gets a private version; and keywords become ordered

On Sep 15, 2016 06:06, "Serhiy Storchaka" wrote: > Python 3.5: 10 loops, best of 3: 33.5 msec per loop > Python 3.6: 10 loops, best of 3: 37.5 msec per loop > > These results look surprisingly and inexplicably to me. I expected that even if there is some performance

Re: [Python-Dev] Python 3.6 dict becomes compact and gets a private version; and keywords become ordered

On Wed, Sep 14, 2016 at 7:33 AM, INADA Naoki wrote: > I'll improve OrderedDict after dict in 3.6 is stable enough. +1 and if it's done carefully we could even utilize the pure Python OrderedDict and get rid of odictobject.c (and fold dict-common.h back into

Re: [Python-Dev] Python 3.6 dict becomes compact and gets a private version; and keywords become ordered

On Mon, Sep 12, 2016 at 4:46 PM, Ethan Furman wrote: > Does anyone have a short explanation of the interaction between hash > randomization and this new always ordered dict? Why doesn't one make the > other useless? Before 3.6, dict iteration was based on the hash table,

Re: [Python-Dev] PEP520 and absence of __definition_order__

On Sep 10, 2016 10:11, "Guido van Rossum" wrote: > > Thanks for bringing this up. I think it's definitely possible to argue > either way. I think what happened before was that I approved > __definition_order__ because I wasn't expecting dict to be ordered by > default. Now that

Re: [Python-Dev] PEP520 and absence of __definition_order__

On Sep 10, 2016 11:00, "Nick Coghlan" wrote: > > On 11 September 2016 at 03:08, Guido van Rossum wrote: > > So I'm happy to continue thinking about this, but I expect this is not > > such a big deal as you fear. Anyway, let's see if someone comes up > > with

[Python-Dev] PEP 468 ready for pronouncement.

see: https://github.com/python/peps/blob/master/pep-0468.txt With the introduction of the compact dict implementation for CPython 3.6, PEP 468 becomes no more than a change to the language reference. I've adjusted the PEP to specify use of an ordered mapping rather than exactly OrderedDict.

[Python-Dev] A Pseudo-Post-Mortem (not dead yet) on my Multi-Core Python Project.

I'm not anticipating much discussion on this, but wanted to present a summary of my notes from the project I proposed last year and have since tabled. http://ericsnowcurrently.blogspot.com/2016/09/solving-mutli-core-python.html -eric ___ Python-Dev

Re: [Python-Dev] The devguide is now hosted on GitHub

Thanks for doing all this, Brett. :) -eric On Fri, Jul 22, 2016 at 2:04 PM, Brett Cannon wrote: > https://github.com/python/devguide > > I have also moved all issues over as well and hooked up Read The Docs so > that there's a mirror which is always up-to-date (vs. >

Re: [Python-Dev] Convert from unsigned long long to PyLong

On Fri, Jul 22, 2016 at 3:02 AM, Stefan Ring wrote: > So to sum this up, you claim that PyLong_FromUnsignedLongLong can > somehow produce a number larger than the value range of a 64 bit > number (0x10180). I have a hard time believing this. Perhaps I

Re: [Python-Dev] PEP487: Simpler customization of class creation

Great job, Martin! Thanks for seeing this through. :) -eric On Sun, Jul 17, 2016 at 10:57 AM, Guido van Rossum wrote: > This PEP is now accepted for inclusion in Python 3.6. Martin, > congratulations! Someone (not me) needs to review and commit your > changes, before

Re: [Python-Dev] Status of Python 3.6 PEPs?

On Tue, Jul 12, 2016 at 3:26 AM, Victor Stinner wrote: > "PEP 520 -- Preserving Class Attribute Definition Order" > https://www.python.org/dev/peps/pep-0520/ > => accepted -- what is the status of its implementation? The implementation is currently under review

Re: [Python-Dev] PEP 520: Preserving Class Attribute Definition Order (round 5)

On Jun 28, 2016 2:56 PM, "Guido van Rossum" wrote: > > Awesome. That addresses my last concerns. PEP 520 is now accepted. > Congratulations! Yay! Thank you and to all those that gave such good feedback. -eric (phone) ___ Python-Dev

Re: [Python-Dev] PEP 520: Preserving Class Attribute Definition Order (round 5)

On Tue, Jun 28, 2016 at 11:43 AM, Guido van Rossum <gu...@python.org> wrote: > On Tue, Jun 28, 2016 at 10:30 AM, Eric Snow <ericsnowcurren...@gmail.com> > wrote: >> I suppose I'm having a hard time letting go of the attractiveness of >> "read-only == complete

Re: [Python-Dev] PEP 520: Preserving Class Attribute Definition Order (round 5)

On Sun, Jun 26, 2016 at 5:55 PM, Guido van Rossum wrote: >> On Fri, Jun 24, 2016 at 4:37 PM, Nick Coghlan wrote: >> > This version looks fine to me. > > Same to me, mostly. I've updated the PEP per everyone's comments [1], except I still haven't dropped the

Re: [Python-Dev] PEP 520: Preserving Class Attribute Definition Order (round 5)

On Fri, Jun 24, 2016 at 5:56 PM, Random832 <random...@fastmail.com> wrote: > On Fri, Jun 24, 2016, at 17:52, Eric Snow wrote: >> - 2 open questions (__slots__? drop read-only requirement?) > > It's worth noting that __slots__ itself doesn't have a read-only > requirement

Re: [Python-Dev] PEP 520: Preserving Class Attribute Definition Order (round 5)

On Fri, Jun 24, 2016 at 4:37 PM, Nick Coghlan wrote: > This version looks fine to me. \o/ > The definition order question has been dropped from PEP 487, so this > cross-reference doesn't really make sense any more :) Ah, so much for my appeal to authority. > I'd

Re: [Python-Dev] PEP XXX: Compact ordered dict

There are a number of ways to make it work (mostly). However, I'll defer to Raymond on how strictly OrderedDict should "subclass" from dict. -eric On Thu, Jun 23, 2016 at 9:26 AM, INADA Naoki <songofaca...@gmail.com> wrote: > On Fri, Jun 24, 2016 at 12:03 AM, Eric S

Re: [Python-Dev] PEP 487: Simpler customization of class creation

On Fri, Jun 24, 2016 at 1:50 PM, Nick Coghlan wrote: > Honestly though, I'm not sure this additional user-visible complexity > is worth it - "The default type metaclass has this new behaviour" is a > lot easier to document and explain than "We added a new opt-in > alternate

[Python-Dev] PEP 520: Preserving Class Attribute Definition Order (round 5)

- a clearer motivation section - include "dunder" names - 2 open questions (__slots__? drop read-only requirement?) -eric --- PEP: 520 Title: Preserving Class Attribute Definition Order Version: $Revision$ Last-Modified: $Date$ Author: Eric Snow <e

Re: [Python-Dev] PEP XXX: Compact ordered dict

On Mon, Jun 20, 2016 at 11:02 PM, INADA Naoki wrote: > On Tue, Jun 21, 2016 at 12:17 PM, Oleg Broytman wrote: >> (if a PEP is needed at all) > > I don't think so. My PEP is not for changing Python Language, > just describe implementation detail. > >

Re: [Python-Dev] PEP 487: Simpler customization of class creation

On Tue, Jun 21, 2016 at 3:01 PM, Nick Coghlan wrote: > RIght, if *tp_dict itself* on type objects is guaranteed to be > order-preserviing, then we don't need to do anything except perhaps > provide a helper method or descriptor on type that automatically > filters out the

Re: [Python-Dev] PEP 487: Simpler customization of class creation

On Tue, Jun 21, 2016 at 11:18 AM, Guido van Rossum wrote: > If we had had these semantics in the language from the start, there would have > been plenty uses of this order, and I suspect nobody would have considered > asking for __definition_order__. True. The key thing that

Re: [Python-Dev] Review of PEP 520: Ordered Class Definition Namespace

On Tue, Jun 21, 2016 at 3:21 PM, Nick Coghlan wrote: > It occurs to me that a settable __definition_order__ provides a > benefit that an ordered tp_dict doesn't: to get the "right" definition > order in something like Cython or dynamic type creation, you don't > need to

Re: [Python-Dev] PEP 487: Simpler customization of class creation

On Mon, Jun 20, 2016 at 12:31 PM, Nikita Nemkin wrote: > Right. Ordered by default is a very serious implementation constraint. > It's only superior in a sense that it completely subsumes/obsoletes > PEP 520. Just to be clear, PEP 520 is more than just OrderedDict-by-default.

[Python-Dev] PEP 520: Preserving Class Attribute Definition Order (round 4)

I've updated PEP 520 to reflect a clearer focus on the definition order and less emphasis on OrderedDict. -eric === PEP: 520 Title: Preserving Class Attribute Definition Order Version: $Revision$ Last-Modified: $Date$ Author: Eric Snow <ericsnowcur

Re: [Python-Dev] Review of PEP 520: Ordered Class Definition Namespace

On Mon, Jun 20, 2016 at 10:32 AM, Guido van Rossum wrote: > - I don't like the exception for dunder names. I can see that __module__, > __name__ etc. that occur in every class are distractions, but since you're > adding methods, you should also add methods with dunder names

Re: [Python-Dev] PEP 520: Ordered Class Definition Namespace

On Mon, Jun 20, 2016 at 9:49 AM, Guido van Rossum wrote: > I agree it's better to define the order as computed at runtime. I don't > think there's much of a point to mandate that all builtin/extension types > reveal their order too -- I doubt there will be many uses for that --

Re: [Python-Dev] PEP 520: Ordered Class Definition Namespace

On Fri, Jun 17, 2016 at 7:32 PM, Nick Coghlan wrote: > The discussion in the PEP 487 thread made me realise that I'd like to > see a discussion in PEP 520 regarding whether or not to define > __definition_order__ for builtin types initialised via PyType_Ready or > created via

Re: [Python-Dev] PEP 487: Simpler customization of class creation

On Thu, Jun 16, 2016 at 3:36 PM, Nick Coghlan wrote: > I don't think that's a side note, I think it's an important point (and > relates to one of Nikita's questions as well): we have the option of > carving out certain aspects of PEP 520 as CPython implementation > details. >

Re: [Python-Dev] PEP 487: Simpler customization of class creation

On Thu, Jun 16, 2016 at 12:56 PM, Martin Teichmann wrote: > I am looking forward to a lot of comments on this! I'd be glad to give feedback on this, probably later today or tomorrow. In particular, I'd like to help resolve the intersection with PEP 520. :) -eric

Re: [Python-Dev] PEP 520: Ordered Class Definition Namespace

On Thu, Jun 16, 2016 at 5:11 AM, Nikita Nemkin wrote: > I'll reformulate my argument: > > Ordered class namespaces are a minority use case that's already covered > by existing language features (custom metaclasses) and doesn't warrant > the extension of the language (i.e. making

Re: [Python-Dev] PEP 520: Ordered Class Definition Namespace

Thanks for raising these good points, Nikita. I'll make sure the PEP reflects this discussion. (inline responses below...) -eric On Tue, Jun 14, 2016 at 3:41 AM, Nikita Nemkin wrote: > Is there any rationale for rejecting alternatives like: > > 1. Adding standard metaclass

Re: [Python-Dev] PEP 520: Ordered Class Definition Namespace (round 3)

On Sat, Jun 11, 2016 at 7:51 PM, Émanuel Barry <vgr...@live.ca> wrote: >> From: Eric Snow >> 1. if ``__definition_order__`` is defined in the class body then it >> must be a ``tuple`` of identifiers or ``None``; any other value >> will result in ``Ty

[Python-Dev] PEP 520: Ordered Class Definition Namespace (round 3)

been clarification. Guido, at this point I believe the PEP is ready for pronouncement. * I've included the most recent copy of the text below. Thanks. -eric == PEP: 520 Title: Ordered Class Definition Namespace Version: $Revision$ Last-Modified: $Date$ Author: Eric

Re: [Python-Dev] PEP 520: Ordered Class Definition Namespace

On Fri, Jun 10, 2016 at 11:29 AM, Nick Coghlan <ncogh...@gmail.com> wrote: > On 10 June 2016 at 09:42, Eric Snow <ericsnowcurren...@gmail.com> wrote: >> On Thu, Jun 9, 2016 at 2:39 PM, Nick Coghlan <ncogh...@gmail.com> wrote: >>> That restriction would be com

Re: [Python-Dev] PEP 468

On Fri, Jun 10, 2016 at 11:54 AM, Franklin? Lee wrote: > Eric, have you any work in progress on compact dicts? Nope. I presume you are talking the proposal Raymond made a while back. -eric ___ Python-Dev mailing list

Re: [Python-Dev] PEP 468

On Thu, Jun 9, 2016 at 1:10 PM, Émanuel Barry wrote: > As stated by Guido (and pointed out in the PEP): > > Making **kwds ordered is still open, but requires careful design and > implementation to avoid slowing down function calls that don't benefit. > > The PEP has not been

Re: [Python-Dev] PEP 468

On Thu, Jun 9, 2016 at 12:41 PM, wrote: > Is there any further thoughts on including this in 3.6? I don't have any plans and I don't know of anyone willing to champion the PEP for 3.6. Note that the implementation itself shouldn't take very long. > Similar to the > recent

Re: [Python-Dev] PEP 520: Ordered Class Definition Namespace

On Thu, Jun 9, 2016 at 2:39 PM, Nick Coghlan wrote: > I'm guessing Ethan is suggesting defining it as: > > __definition_order__ = tuple(ns["__definition_order__"]) > > When the attribute is present in the method body. Ah. I'd rather stick to "consenting adults" in the

Re: [Python-Dev] PEP 520: Ordered Class Definition Namespace

On Wed, Jun 8, 2016 at 1:07 AM, Victor Stinner wrote: >> Abstract >> >> >> This PEP changes the default class definition namespace to ``OrderedDict``. >> Furthermore, the order in which the attributes are defined in each class >> body will now be preserved in

Re: [Python-Dev] PEP 520: Ordered Class Definition Namespace

On Wed, Jun 8, 2016 at 12:07 AM, Franklin? Lee <leewangzhong+pyt...@gmail.com> wrote: > On Jun 7, 2016 8:52 PM, "Eric Snow" <ericsnowcurren...@gmail.com> wrote: >> * the default class *definition* namespace is now ``OrderdDict`` >> * the order in which clas

Re: [Python-Dev] PEP 520: Ordered Class Definition Namespace

On Tue, Jun 7, 2016 at 6:20 PM, Ethan Furman <et...@stoneleaf.us> wrote: > On 06/07/2016 05:50 PM, Eric Snow wrote: >> __definition_order__ = tuple(k for k in locals() >> if (!k.startswith('__') or >>

[Python-Dev] PEP 520: Ordered Class Definition Namespace

Class Definition Namespace Version: $Revision$ Last-Modified: $Date$ Author: Eric Snow <ericsnowcurren...@gmail.com> Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 7-Jun-2016 Python-Version: 3.6 Post-History: 7-Jun-2016 Abstract This PEP changes the default

Re: [Python-Dev] PEP: Ordered Class Definition Namespace

On Tue, Jun 7, 2016 at 2:34 PM, Ethan Furman <et...@stoneleaf.us> wrote: > On 06/07/2016 02:20 PM, Eric Snow wrote: >> I think both of those make __definition_order__ more complicated and >> less useful. As the PEP stands, folks can be confident in what >> __definitio

Re: [Python-Dev] PEP: Ordered Class Definition Namespace

On Tue, Jun 7, 2016 at 2:34 PM, Nick Coghlan <ncogh...@gmail.com> wrote: > On 7 June 2016 at 14:20, Eric Snow <ericsnowcurren...@gmail.com> wrote: >> What would you consider to be the >> benefit of a mutable (or replaceable) __definition_order__ that >> o

Re: [Python-Dev] PEP: Ordered Class Definition Namespace

On Tue, Jun 7, 2016 at 12:30 PM, Nick Coghlan <ncogh...@gmail.com> wrote: > On 7 June 2016 at 10:51, Eric Snow <ericsnowcurren...@gmail.com> wrote: >> * ``__definition_order__`` is a tuple >> * ``__definition_order__`` is a read-only attribute > > Thinking abou

Re: [Python-Dev] PEP: Ordered Class Definition Namespace

On Tue, Jun 7, 2016 at 11:45 AM, Ethan Furman <et...@stoneleaf.us> wrote: > On 06/07/2016 11:13 AM, Eric Snow wrote: >> A __definition_order__ in the class body always takes precedence. So >> a supplied value will be honored (and not replaced with None). > > Will the su

Re: [Python-Dev] PEP: Ordered Class Definition Namespace

On Tue, Jun 7, 2016 at 11:36 AM, Émanuel Barry <vgr...@live.ca> wrote: >> From: Eric Snow >> * "dunder" attributes (e.g. ``__init__``, ``__module__``) are ignored > > What does this imply? If I define some __dunder__ methods, will they simply > not be prese

Re: [Python-Dev] PEP: Ordered Class Definition Namespace

On Tue, Jun 7, 2016 at 11:32 AM, Terry Reedy <tjre...@udel.edu> wrote: > On 6/7/2016 1:51 PM, Eric Snow wrote: > >> Note: just to be clear, this PEP is *not* about changing > >> ``type.__dict__`` to ``OrderedDict``. > > By 'type', do you mean the one and one

Re: [Python-Dev] PEP: Ordered Class Definition Namespace

On Tue, Jun 7, 2016 at 11:01 AM, Ethan Furman <et...@stoneleaf.us> wrote: > On 06/07/2016 10:51 AM, Eric Snow wrote: >> Specification >> = > > >>* types for which `__prepare__()`` returned something other than >>

[Python-Dev] PEP: Ordered Class Definition Namespace

Namespace Version: $Revision$ Last-Modified: $Date$ Author: Eric Snow <ericsnowcurren...@gmail.com> Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 4-Jun-2016 Python-Version: 3.6 Post-History: 7-Jun-2016 Abstract This PEP changes the default class defi

Re: [Python-Dev] Improving the bytecode

You should get in touch with Mark Shannon, while you're working on ceval. He has some definite improvements that can be made to the eval loop. -eric On Sat, Jun 4, 2016 at 2:08 AM, Serhiy Storchaka wrote: > Following the converting 8-bit bytecode to 16-bit bytecode

Re: [Python-Dev] support of the android platform

On Sun, Apr 24, 2016 at 1:20 AM, Xavier de Gaye wrote: > Starting with API level 21 (Android 5.0), the build of python3 with the > official android toolchains (that is, without resorting to external > libraries > for wide character support) runs correctly. With the set of

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On Tue, Apr 19, 2016 at 10:50 AM, Brett Cannon wrote: > Ah, but you see that doesn't make porting easy. If I have a bunch of > path-manipulating code using os.path already and I want to add support for > pathlib I can either (a) rewrite all of that path-manipulating code to work

Re: [Python-Dev] Pathlib enhancments - method name only

On Fri, Apr 8, 2016 at 7:41 PM, Brett Cannon <br...@python.org> wrote: > > > On Fri, Apr 8, 2016, 16:13 Glenn Linderman <v+pyt...@g.nevcal.com> wrote: >> >> On 4/8/2016 3:28 PM, Eric Snow wrote: >> >> All this matters because it impacts the value ret

Re: [Python-Dev] Pathlib enhancments - method name only

On Fri, Apr 8, 2016 at 3:57 PM, Eric Snow <ericsnowcurren...@gmail.com> wrote: > On Fri, Apr 8, 2016 at 12:25 PM, Brett Cannon <br...@python.org> wrote: >> I personally still like __ospath__ as well. > > Same here. The strings are essentially an OS-dependent serializa

Re: [Python-Dev] Pathlib enhancments - method name only

On Fri, Apr 8, 2016 at 12:25 PM, Brett Cannon wrote: > I personally still like __ospath__ as well. Same here. The strings are essentially an OS-dependent serialization, rather than related to a particular file system. -eric ___

[Python-Dev] Other pathlib improvements? was: When should pathlib stop being provisional?

On Apr 6, 2016 11:11 PM, "Raymond Hettinger" wrote: > Having worked through the API when it is first released, I find it to be highly forgettable (i.e. I have to re-read the docs each time I've revisited it). Agreed, though it's arguably better than argparse,

Re: [Python-Dev] Defining a path protocol

On Apr 7, 2016 1:22 AM, "Georg Brandl" wrote: > > On 04/06/2016 07:26 PM, Brett Cannon wrote: > > 1. Name: __path__, __fspath__, or something else? > > __path__ is already taken as a module attribute, so I would avoid it. > __fspath__ is fine with me, although the more explicit

Re: [Python-Dev] When should pathlib stop being provisional?

On Apr 6, 2016 14:00, "Barry Warsaw" wrote: > Aside from the name of the attribute (though I'm partial to __path__), Ahem, pkg.__path__. -eric ___ Python-Dev mailing list Python-Dev@python.org

<    1   2   3   4   5   6   >