Re: [Python-Dev] Aaron Hall, Introduction and pull-request bump
Hello! And welcome aboard this mailing list ship. :) ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 549: Instance Properties (aka: module properties)
On 09/11/2017 07:22 PM, Guido van Rossum wrote:
I still don't follow. How does one use InstanceDescriptor?
If you write a class that inherits from InstanceDescriptor and supports
the descriptor protocol, module objects will call the descriptor
protocol functions when that object is accessed inside a module instance.
Example: if this is "module.py":
import collections.abc
class CustomInstanceProperty(collections.abc.InstanceDescriptor):
def __get__(self, instance, owner):
print("CustomInstanceProperty.__get__ called!")
return 44
cip = CustomInstanceProperty()
If you then "import module" and reference "module.cip", it'll print
"CustomInstanceProperty.__get__ called!" and you'll get the value 44.
All three magic methods for descriptors work fine.
(BTW, I didn't know the best way to make this work. I wound up
implementing InstanceDescriptor by copying-and-pasting
PyBaseObject_Type, setting the special tp_flag, and ensuring the special
flag gets propagated to subclasses in inherit_special(). If there's a
better way to do it I'd happily improve the implementation.)
Is this still about modules, or is it a generalization of properties
for non-module instances? (If it is specific to modules, why doesn't
it have "module" in its name? Or if it's not, why is it in this
discussion?)
It's a generalization of supporting descriptors for instances, but
currently it's only supported by modules. It's opt-in and modules are
the only class doing so.
The prototype is linked to from the PEP; for your convenience
here's a link:
https://github.com/larryhastings/cpython/tree/module-properties
I found that link in the PEP, but it's just a branch of a fork of
cpython. It would be easier to review the prototype as a PR to
upstream cpython.
Okay, I'll make a PR tomorrow and post a reply here (and update the PEP).
//arry/
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 549: Instance Properties (aka: module properties)
@Larry > "@property" 375 hits > "def __getattr__" 28 hits I don't think it is fair to compare occurrences of __getattr__ vs occurrences of @property, since in the first case one would use a single __getattr__ per class, while in the second case @property is required for every attribute. @Guido > I'm still poindering this. I am far from decided about whether it's better to ... The decision is up to you, I just wanted to bring an idea that is both simpler and more performance efficient. -- Ivan ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 490 "Chain exceptions at C level" rejected
Hi, In March 2015, I proposed the PEP 490 to chain implicitly C exceptions by default: https://www.python.org/dev/peps/pep-0490/ The discussion on python-dev was quickly in favor of keeping the status quo: don't chain C exceptions by default, but only do that explicitly where it makes sense. I forgot this PEP, but I just rejected it to close the old discussion :-) Note: The PEP is not yet rejected on python.org, it will be done at the next cron job run. Victor ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] breakpoint() and $PYTHONBREAKPOINT
On 12 September 2017 at 11:15, Nathaniel Smith wrote: > On Mon, Sep 11, 2017 at 5:27 PM, Barry Warsaw wrote: >> On Sep 10, 2017, at 13:46, Nathaniel Smith wrote: >>> >>> On Sun, Sep 10, 2017 at 12:06 PM, Barry Warsaw wrote: For PEP 553, I think it’s a good idea to support the environment variable $PYTHONBREAKPOINT[*] but I’m stuck on a design question, so I’d like to get some feedback. Should $PYTHONBREAKPOINT be consulted in breakpoint() or in sys.breakpointhook()? >>> >>> Wouldn't the usual pattern be to check $PYTHONBREAKPOINT once at >>> startup, and if it's set use it to initialize sys.breakpointhook()? >>> Compare to, say, $PYTHONPATH. >> >> Perhaps, but what would be the visible effects of that? I.e. what would >> that buy you? > > Why is this case special enough to break the rules? > > Compared to checking it on each call to sys.breakpointhook(), I guess > the two user-visible differences in behavior would be: > > - whether mutating os.environ["PYTHONBREAKPOINT"] inside the process > affects future calls. I would find it quite surprising if it did; > generally when we mutate envvars like os.environ["PYTHONPATH"] it's a > way to set things up for future child processes and doesn't affect our > process. I think this case is closer to PYTHONINSPECT than it is to PYTHONPATH, and we *do* delay checking PYTHONINSPECT until the application is shutting down specifically so programs can set the env var during execution. > - whether the import happens immediately at startup, or is delayed > until the first call to breakpoint(). If it's imported once at > startup, then this adds overhead to programs that set PYTHONBREAKPOINT > but don't use it, and if the envvar is set to some nonsense then you > get an error immediately instead of at the first call to breakpoint(). > These both seem like fairly minor differences to me, but maybe saving > that 30 ms or whatever of startup time is an important enough > optimization to justify the special case? This is independent of whether the check happens in the builtin or in the default hook, and I agree with Barry that it should be queried lazily regardless of whether it's the builtin or the default hook that checks it. I think it would be reasonable for the default hook to cache the result of PYTHONBREAKPOINT on the first lookup and then not check it again on future calls, though. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 557: Data Classes
> On Sep 12, 2017, at 9:01 AM, Chris Barker - NOAA Federal > wrote: > This really does match well with the record concept in databases, and most > people are familiar with that. Though it will. E a touch confusing until (if > ever) most of the database and cab traders, etc start using them. I REALLY need to stop quickly posting from my phone... ... Though it will be a touch confusing until (if ever) most of the database and csv readers etc. start using them. -CHB ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 557: Data Classes
- record +1 This really does match well with the record concept in databases, and most people are familiar with that. Though it will. E a touch confusing until (if ever) most of the database and cab traders, etc start using them. It also matches pretty well with numpy "record arrays": https://docs.scipy.org/doc/numpy-1.13.0/user/basics.rec.html - bag I also like this -- not many folks will have a ore-conceived notion of what it is. - declarative Yeach-- that's an adjective (at least on most common use) -- and a programming term that means something else. Also, considering their uses, it might make sense to put them in the collections module. Yup. -CHB ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 490 "Chain exceptions at C level" rejected
On 09/12/2017 02:49 AM, Victor Stinner wrote: Note: The PEP is not yet rejected on python.org, it will be done at the next cron job run. My understanding is that the docs are built once a day via cron job, but the PEPs are built every time the repo changes thanks to Travis CI. So it should be only a matter of minutes between you pushing a change to a PEP and the change showing up live on the web. //arry/ ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 490 "Chain exceptions at C level" rejected
On Sep 12, 2017, at 12:18, Larry Hastings wrote: > On 09/12/2017 02:49 AM, Victor Stinner wrote: >> Note: The PEP is not yet rejected on python.org, it will be done at >> the next cron job run. > My understanding is that the docs are built once a day via cron job, but the > PEPs are built every time the repo changes thanks to Travis CI. So it should > be only a matter of minutes between you pushing a change to a PEP and the > change showing up live on the web. I believe peps on python.org are updated every 15 minutes. The html version of docs for maintenance and feature branches (currently, master->3.7, 3.6, 2.7) on docs.python.org are updated every 3 hours and, in theory, the downloadable versions are updated once a day. But take that with a grain of salt (nudge nudge, wink wink). -- Ned Deily [email protected] -- [] ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 actually something I've been exploring and was one of the motivations for consolidating the C globals. -eric ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 554 v2 (new "interpreters" module)
On Sat, Sep 9, 2017 at 1:04 AM, Paul Moore wrote: > On 9 September 2017 at 00:04, Eric Snow wrote: >>add_recv_fifo(name=None): >>add_send_fifo(name=None): > > Personally, I *always* read these names backwards - from the POV of > the caller. So when I see "add_send_fifo", I then expect to be able to > send stuff on the returned FIFO (i.e., I get a writer back). But > that's not how it works. > > I may be alone in this - I've had similar problems in the past with > how people name pipes, for example - but I thought I'd raise it while > there's still a possibility that it's not just me and the names can be > changed. Yeah, those names are bugging me too. I'm stewing over possible alternatives. It's the one piece of the PEP that I want to address before I re-post to the list. -eric ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 fast as multiprocessing and as cheap as threading, you will > find a lot of people starting to want to use it. Note that subinterpreters share the GIL currently, and the objects you can pass between interpreters will be quite restricted initially. However, the ultimate goal is to stop sharing the GIL between interpreters and to broaden the types that can be passed between interpreters. Regardless, the isolation inherent to subinterpreters provides benefits immediately. -eric ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 names since they confuse me too. :) > How does it get to learn the *name*? The main way is that the programmer hard-codes it. I'd expect close proximity between the code that adds the FIFO and the code that get's run in the subinterpreter. > > Why are FIFOs unidirectional? Does it really make them significantly > cheaper? With bidirectional pipes, the whole recv/send confusion would > be avoided. > > As a point of comparison, for default for `multiprocessing.Pipe()` is > to create a bidirectional pipe (*), yet I'm sure a multiprocessing Pipe > has more overhead than an in-process FIFO. The choice wasn't about cost or performance. In part it's a result of my experience with Go's channels. Bidirectional channels are problematic in certain situations, including when it relates to which goroutine is responsible for managing the channel's lifetime. Also, bidirectional channels require both the reader and the writer (of the code) to keep track of the two roles that the channel plays. It's easy to forget about one or the other, and accidentally do the wrong thing. Unidirectional channels resolve all those problems. Granted, the FIFOs from the PEP aren't the same as Go's channels. They are more rudimentary and they lack the support provided by a static compiler (e.g. deadlock detection), but my intention is that they provide all the functionality we need as a building block. -eric ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 554 v2 (new "interpreters" module)
On Sat, Sep 9, 2017 at 5:05 AM, Antoine Pitrou wrote: > On Fri, 8 Sep 2017 16:04:27 -0700, Eric Snow > wrote: >> ``list()``:: > > It's called ``enumerate()`` in the threading module. Not sure there's > a point in choosing a different name here. Yeah, in the first version of the PEP it was called "enumerate()". I changed it to "list()" at Raymond's recommendation. The reasoning is that it's less confusing to most people that way. TBH, I'd rather leave it "list()", but could be swayed. Perhaps it would be enough for the PEP to not mention any relationship to "threading"? >> The current interpreter (which called ``run()``) will block >> until the subinterpreter finishes running the requested code. Any >> uncaught exception in that code will bubble up to the current >> interpreter. > > Why does it block? How is concurrency supposed to be achieved in that > model? It would be more flexible if run(code) returned an object that > can later be waited on. Something like... a Future :-) I expect this is more a problem with my description than with the feature. :) I've already re-written this bit to be more clear. It's not that the thread blocks. It's more like a function call, where the current frame is paused while the call is executed. Then it returns to the calling frame. Likewise the interpreter in the current thread gets swapped out with the target interpreter, where the code gets run, and then the original interpreter gets swapped back in. This is how you do it in the C-API and it made sense (to me) to do it the same way in Python. > > And why guarantee that it executes in the "current OS thread"? > I would say you don't want to specify where it executes exactly, as it > opens the door for more sophisticated implementations (such as > automatic assignment of subinterpreters inside a pool of threads). Again, I had explained this poorly in the PEP. The key thing here is that subinterpreters don't do anything special relative to threading. If you want to call "Interpreter.run()" in a thread then you stick it in a "threading.Thread". If you want to auto-assign to a pool of threads then you treat it like any other function you would auto-assign to a pool of threads. >>get_fifo(name): >>list_fifos(): > > If fifos are uniquely named, why not return a name->fifo mapping? I suppose we could. Then we could get rid of "get_fifo()" too. I'm still mulling over the right API for the FIFO parts of the PEP. > >> ``FIFOReader(name)``:: >> [...] > > I don't think the method naming choice is very adequate here. The API > model for the FIFO objects can either be a (threading or > multiprocessing) Queue or a multiprocessing Pipe. > > - if a Queue, then it should have a get() / put() pair of methods > - if a Pipe, then it should have a recv() / send() pair of methods > > Now, since Queues are multi-producer multi-consumer, while Pipes are > single-producer single-consumer (they aren't "synchronized"), the > better analogy seems to the multiprocessing Pipe here, so I would vote > for recv() / send(). > > But, in any case, definitely not a pop() / push() pair. Thanks for pointing that out. Prior art, FTW! I'll factor that in. > Has any thought been given to how FIFOs could integrate with async code > driven by an event loop (e.g. asyncio)? I think the model of executing > several asyncio (or Tornado) applications each in their own > subinterpreter may prove quite interesting to reconcile multi-core > concurrency with ease of programming. That would require the FIFOs to > be able to synchronize on something an event loop can wait on (probably > a file descriptor?). Personally I've given pretty much no thought to the relationship with async. TBH, the FIFO parts of the PEP were added only recently and haven't fully baked yet. I'd be interested more feedback on async relative to PEP, not just with the FIFO bits; my experience with async is pretty limited thus far. -eric ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 I've updated the PEP to clarify. > it'd mean sharing not just arbitrary user defined exception classes but full > frame objects... My current implementation does the right thing currently. However, it would probably struggle under a more tightly controlled inter-interpreter boundary. I'll take a look and also update the PEP. -eric ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] parallelizing
There are times when you deal with completely independent input/output 'pipes' - where parallelizing would really help speed things up. Can't there be a way to capture that idiom and multi thread it in the language itself? Example: loop: read an XML produce a JSON like Regards, MB ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 557: Data Classes
On 13 September 2017 at 02:01, Chris Barker - NOAA Federal wrote: > This really does match well with the record concept in databases, and most > people are familiar with that. No, most people aren't familiar with that - they only become familiar with it *after* they've learned to program and learned what a database is. > Though it will. E a touch confusing until (if > ever) most of the database and cab traders, etc start using them. Aside from the potential confusion with other technical uses of "record", a further problem with "record" is that it's ambiguous as to whether its referring to the noun (wreck-ord) or the verb (ree-cord). Even if folks correctly interpret it as a noun, there's still plenty of opportunities for folks to guess incorrectly about what it means based on the other conventional English uses of the word (e.g. a "personal record" will consist of multiple "records" in the database sense). So in this case, the vagueness of "data class" is considered a feature - since it doesn't inherently mean *anything*, folks are more likely to realise that they need to look up "Python data class", and if I search for that in a private window, the first Google hit is https://stackoverflow.com/questions/3357581/using-python-class-as-a-data-container and the second is Eric's PEP. > Also, considering their uses, it might make sense to put them in the > collections module. Data classes are things you're likely to put *in* a collection, rather than really being collections themselves (they're only collections in the same sense that all Python classes are collections of attributes, and that's not the way the collections module uses the term). Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 554 v2 (new "interpreters" module)
On 13 September 2017 at 07:43, Eric Snow wrote: > On Sat, Sep 9, 2017 at 5:05 AM, Antoine Pitrou wrote: >> On Fri, 8 Sep 2017 16:04:27 -0700, Eric Snow >> wrote: >>> ``list()``:: >> >> It's called ``enumerate()`` in the threading module. Not sure there's >> a point in choosing a different name here. > > Yeah, in the first version of the PEP it was called "enumerate()". I > changed it to "list()" at Raymond's recommendation. The reasoning is > that it's less confusing to most people that way. TBH, I'd rather > leave it "list()", but could be swayed. Perhaps it would be enough > for the PEP to not mention any relationship to "threading"? I think you should just say that you're not using interpreters.enumerate() because that conflicts with the enumerate builtin. However, replacing that with a *different* naming conflict with an even more commonly used builtin wouldn't be a good idea either :) I also think the "list interpreters" question is more subtle than you think, as there are two potential sets of interpreters to consider: 1. Getting a listing of all interpreters in the process (creating Interpreter objects in the current interpreter for each of them) 2. Getting a listing of all other interpreters created by calling interpreters.create_interpreter() in *this* interpreter Since it's not clear yet whether or not we're actually going to track the metadata needed to report the latter, I'd suggest only offering "interpreters.list_all()" initially, and requiring folks to do their own tracking if they want a record of the interpreters their own code has created. >>> The current interpreter (which called ``run()``) will block >>> until the subinterpreter finishes running the requested code. Any >>> uncaught exception in that code will bubble up to the current >>> interpreter. >> >> Why does it block? How is concurrency supposed to be achieved in that >> model? It would be more flexible if run(code) returned an object that >> can later be waited on. Something like... a Future :-) > > I expect this is more a problem with my description than with the > feature. :) I've already re-written this bit to be more clear. It's > not that the thread blocks. It's more like a function call, where the > current frame is paused while the call is executed. Then it returns > to the calling frame. Likewise the interpreter in the current thread > gets swapped out with the target interpreter, where the code gets run, > and then the original interpreter gets swapped back in. This is how > you do it in the C-API and it made sense (to me) to do it the same way > in Python. I'm not sure if it would create more confusion than it would resolve, but I'm wondering if it may be worth including an example where you delegate the subinterpreter call to another thread via concurrent.futures.ThreadExecutor. >>>get_fifo(name): >>>list_fifos(): >> >> If fifos are uniquely named, why not return a name->fifo mapping? > > I suppose we could. Then we could get rid of "get_fifo()" too. I'm > still mulling over the right API for the FIFO parts of the PEP. The FIFO parts of the proposal are feeling a lot like the Mailbox objects in TI-RTOS to me, just with a more user-friendly API since we're dealing with Python rather than C: http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/sysbios/6_35_01_29/exports/bios_6_35_01_29/docs/cdoc/ti/sysbios/knl/Mailbox.html >>> ``FIFOReader(name)``:: >>> [...] >> >> I don't think the method naming choice is very adequate here. The API >> model for the FIFO objects can either be a (threading or >> multiprocessing) Queue or a multiprocessing Pipe. >> >> - if a Queue, then it should have a get() / put() pair of methods >> - if a Pipe, then it should have a recv() / send() pair of methods >> >> Now, since Queues are multi-producer multi-consumer, while Pipes are >> single-producer single-consumer (they aren't "synchronized"), the >> better analogy seems to the multiprocessing Pipe here, so I would vote >> for recv() / send(). >> >> But, in any case, definitely not a pop() / push() pair. > > Thanks for pointing that out. Prior art, FTW! I'll factor that in. +1 from me for treating this as a split Pipe model, where the SendPipe and RecvPipe are distinct objects (since they'll exist in different interpreters). >> Has any thought been given to how FIFOs could integrate with async code >> driven by an event loop (e.g. asyncio)? I think the model of executing >> several asyncio (or Tornado) applications each in their own >> subinterpreter may prove quite interesting to reconcile multi-core >> concurrency with ease of programming. That would require the FIFOs to >> be able to synchronize on something an event loop can wait on (probably >> a file descriptor?). > > Personally I've given pretty much no thought to the relationship with > async. TBH, the FIFO parts of the PEP were added only recently and > haven't fully baked yet. I'd be interested more fee
Re: [Python-Dev] PEP 557: Data Classes
On Tue, Sep 12, 2017 at 7:09 PM, Nick Coghlan wrote: > So in this case, the vagueness of "data class" is considered a feature > - since it doesn't inherently mean *anything*, folks are more likely > to realise that they need to look up "Python data class", and if I > search for that in a private window, the first Google hit is > https://stackoverflow.com/questions/3357581/using-python-class-as-a-data- > container > and the second is Eric's PEP. > I think "data classes" is a fine moniker for this concept. It's ironic that some people dislike "data classes" because these are regular classes, not just for data, while others are proposing alternative names that emphasize the data container aspect. So "data classes" splits the difference, by referring to both data and classes. Let's bikeshed about something else. -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 554 v2 (new "interpreters" module)
On Tue, Sep 12, 2017 at 2:43 PM, Eric Snow wrote: > Yeah, in the first version of the PEP it was called "enumerate()". I > changed it to "list()" at Raymond's recommendation. The reasoning is > that it's less confusing to most people that way. TBH, I'd rather > leave it "list()", but could be swayed. Perhaps it would be enough > for the PEP to not mention any relationship to "threading"? > Really, you're going to change it from a name conflict with a builtin function to a name conflict with a builtin type? -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
