Re: [Python-Dev] backporting stdlib 2.7.x from pypy to cpython
On 2012-06-08, at 20:29 , Brett Cannon wrote: > On Fri, Jun 8, 2012 at 2:21 PM, [email protected] > wrote: > >> On Fri, Jun 8, 2012 at 10:59 AM, Brett Cannon wrote: >>> R. David already replied to this, but just to reiterate: tests can always >>> get updated, and code that fixes a bug (and leaving a file open can be >>> considered a bug) can also go in. It's just stuff like code refactoring, >>> speed improvements, etc. that can't go into Python 2.7 at this point. >> Thanks for the clarification! >> >>> If/until the stdlib is made into its own repo, should the various VMs >>> consider keeping a common Python 2.7 repo that contains nothing but the >>> stdlib (or at least just modifications to those) so they can modify in >> ways >>> that CPython can't accept because of compatibility policy? You could >> keep it >>> on hg.python.org (or wherever) and then all push to it. This might also >> be a >>> good way to share Python implementations of extension modules for Python >> 2.7 >>> instead of everyone maintaining there own for the next few years >> (although I >>> think those modules should go into the stdlib directly for Python 3 as >>> well). Basically this could be a test to see if communication and >>> collaboration will be high enough among the other VMs to bother with >>> breaking out the actual stdlib into its own repo or if it would just be a >>> big waste of time. >> I'd be up for trying this. I don't think it's easy to fork a >> subdirectory of CPython though - right now I just keep an unchanged >> copy of the 2.7 LIb in our repo (PyPy does the same, at least the last >> time I checked). >> > > Looks like hg doesn't have support yet: > http://stackoverflow.com/questions/920355/how-do-i-clone-a-sub-folder-of-a-repository-in-mercurial > Using that would mean commits in the "externalized stdlib" would go into the Python 2.7 repo, which I assume is *not* desirable. A better-fitting path of action would be a hg -> hg convert using a filemap, as the first comment in your link shows. That would create a full copy (with history replay) of the standard library, in a brand new repository. Then *that* could be used by everybody. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] backporting stdlib 2.7.x from pypy to cpython
On Sun, Jun 10, 2012 at 12:05 PM, Brett Cannon wrote: >> Well, the question is, are many python-dev discussions CPython(specific? >> If not, then it doesn't make a lot of sense to create python-implementations >> (and it's one more subscription to manage for those of us who want to keep >> an eye on all core development-related discussions). >> > > But the other VMs don't necessarily care about the development of the > language, so when the occasional thing comes up regarding all the VMs, > should that require they follow python-dev in its entirety? And I don't see > the list making sweeping decisions that would affect CPython and python-dev > without bringing it up there later. Think of the proposed list more like a > SIG than anything else. Yeah, I think it makes sense. With the current situation, the bridges between the implementations are limited to those with the personal bandwidth to follow their implementation's core list *and* python-dev. With a separate list, it becomes easier to get feedback on cases where we want to check that an idea we're considering is feasible for all the major implementations. It also creates a neutral space for the other VMs to discuss stuff like collaborating on pure Python versions of C implemented modules. If we can get to the point where there's a separate "stdlib-only" pure Python mirror based on CPython's Mercurial repo that other implementations can all share, *without* requiring changes to CPython itself, that would be pretty nice. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: Note that the _asdict() method is outdated
On Sun, Jun 10, 2012 at 12:15 PM, raymond.hettinger wrote: > http://hg.python.org/cpython/rev/fecbcd5c3978 > changeset: 77397:fecbcd5c3978 > user: Raymond Hettinger > date: Sat Jun 09 19:15:26 2012 -0700 > summary: > Note that the _asdict() method is outdated This checkin changed a lot of the indentation in the collections docs. Did you mean to do that? Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Updated PEP 362 (Function Signature Object)
2012/6/5 Brett Cannon : > * is_keyword_only : bool > True if the parameter is keyword-only, else False. > * is_args : bool > True if the parameter accepts variable number of arguments > (``\*args``-like), else False. How about "vararg" as its named in AST. > * is_kwargs : bool > True if the parameter accepts variable number of keyword > arguments (``\*\*kwargs``-like), else False. Can the "is_" be dropped? It's quite ugly. Even better, since these are all mutually exclusive, they could be cascaded into a single "type" attribute. > * is_implemented : bool > True if the parameter is implemented for use. Some platforms > implement functions but can't support specific parameters > (e.g. "mode" for os.mkdir). Passing in an unimplemented > parameter may result in the parameter being ignored, > or in NotImplementedError being raised. It is intended that > all conditions where ``is_implemented`` may be False be > thoroughly documented. -- Regards, Benjamin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Updated PEP 362 (Function Signature Object)
On 06/10/2012 10:59 AM, Benjamin Peterson wrote: 2012/6/5 Brett Cannon: * is_keyword_only : bool True if the parameter is keyword-only, else False. * is_args : bool True if the parameter accepts variable number of arguments (``\*args``-like), else False. How about "vararg" as its named in AST. Please read the rest of the thread; this has already been discussed. Can the "is_" be dropped? It's quite ugly. I suppose that's in the eye of the beholder: if parameter.is_kwargs: reads quite naturally to me. Even better, since these are all mutually exclusive, they could be cascaded into a single "type" attribute. Can you make a more concrete suggestion? "type" strikes me as a poor choice of name, as it makes one think immediately of type(), which is another, uh, variety of "type". //arry/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Updated PEP 362 (Function Signature Object)
2012/6/10 Larry Hastings : > Can you make a more concrete suggestion? "type" strikes me as a poor choice > of name, as it makes one think immediately of type(), which is another, uh, > variety of "type". kind -> "position" or "keword_only" or "vararg" or "kwarg" -- Regards, Benjamin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] backporting stdlib 2.7.x from pypy to cpython
Really? Are we now proposing multiple lists? That just makes it easier to miss stuff for me. On Sun, Jun 10, 2012 at 5:53 AM, Nick Coghlan wrote: > On Sun, Jun 10, 2012 at 12:05 PM, Brett Cannon wrote: >>> Well, the question is, are many python-dev discussions CPython(specific? >>> If not, then it doesn't make a lot of sense to create python-implementations >>> (and it's one more subscription to manage for those of us who want to keep >>> an eye on all core development-related discussions). >>> >> >> But the other VMs don't necessarily care about the development of the >> language, so when the occasional thing comes up regarding all the VMs, >> should that require they follow python-dev in its entirety? And I don't see >> the list making sweeping decisions that would affect CPython and python-dev >> without bringing it up there later. Think of the proposed list more like a >> SIG than anything else. > > Yeah, I think it makes sense. With the current situation, the bridges > between the implementations are limited to those with the personal > bandwidth to follow their implementation's core list *and* python-dev. > With a separate list, it becomes easier to get feedback on cases where > we want to check that an idea we're considering is feasible for all > the major implementations. > > It also creates a neutral space for the other VMs to discuss stuff > like collaborating on pure Python versions of C implemented modules. > If we can get to the point where there's a separate "stdlib-only" pure > Python mirror based on CPython's Mercurial repo that other > implementations can all share, *without* requiring changes to CPython > itself, that would be pretty nice. > > Cheers, > Nick. > > -- > Nick Coghlan | [email protected] | Brisbane, Australia > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] backporting stdlib 2.7.x from pypy to cpython
I am proposing a single list to just discuss multi-vm issues so that it doesn't force all other VM contributors to sign up for python-dev if they don't care about language issues. We could hijack the stdlib-sig mailing list, but that isn't the right focus necessarily. On Jun 10, 2012 8:42 PM, "Guido van Rossum" wrote: > Really? Are we now proposing multiple lists? That just makes it easier > to miss stuff for me. > > On Sun, Jun 10, 2012 at 5:53 AM, Nick Coghlan wrote: > > On Sun, Jun 10, 2012 at 12:05 PM, Brett Cannon wrote: > >>> Well, the question is, are many python-dev discussions > CPython(specific? > >>> If not, then it doesn't make a lot of sense to create > python-implementations > >>> (and it's one more subscription to manage for those of us who want to > keep > >>> an eye on all core development-related discussions). > >>> > >> > >> But the other VMs don't necessarily care about the development of the > >> language, so when the occasional thing comes up regarding all the VMs, > >> should that require they follow python-dev in its entirety? And I don't > see > >> the list making sweeping decisions that would affect CPython and > python-dev > >> without bringing it up there later. Think of the proposed list more > like a > >> SIG than anything else. > > > > Yeah, I think it makes sense. With the current situation, the bridges > > between the implementations are limited to those with the personal > > bandwidth to follow their implementation's core list *and* python-dev. > > With a separate list, it becomes easier to get feedback on cases where > > we want to check that an idea we're considering is feasible for all > > the major implementations. > > > > It also creates a neutral space for the other VMs to discuss stuff > > like collaborating on pure Python versions of C implemented modules. > > If we can get to the point where there's a separate "stdlib-only" pure > > Python mirror based on CPython's Mercurial repo that other > > implementations can all share, *without* requiring changes to CPython > > itself, that would be pretty nice. > > > > Cheers, > > Nick. > > > > -- > > Nick Coghlan | [email protected] | Brisbane, Australia > > ___ > > Python-Dev mailing list > > [email protected] > > http://mail.python.org/mailman/listinfo/python-dev > > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > > > > -- > --Guido van Rossum (python.org/~guido) > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] backporting stdlib 2.7.x from pypy to cpython
But what guarantee do you have that (a) the right people sign up for the new list, and (b) topics are correctly brought up there instead of on python-dev? I agree that python-dev is turning into a firehose, but I am reluctant to create backwaters where people might arrive at what they think is a consensus only because the important opinions aren't represented there. On Sun, Jun 10, 2012 at 6:10 PM, Brett Cannon wrote: > I am proposing a single list to just discuss multi-vm issues so that it > doesn't force all other VM contributors to sign up for python-dev if they > don't care about language issues. We could hijack the stdlib-sig mailing > list, but that isn't the right focus necessarily. > > On Jun 10, 2012 8:42 PM, "Guido van Rossum" wrote: >> >> Really? Are we now proposing multiple lists? That just makes it easier >> to miss stuff for me. >> >> On Sun, Jun 10, 2012 at 5:53 AM, Nick Coghlan wrote: >> > On Sun, Jun 10, 2012 at 12:05 PM, Brett Cannon wrote: >> >>> Well, the question is, are many python-dev discussions >> >>> CPython(specific? >> >>> If not, then it doesn't make a lot of sense to create >> >>> python-implementations >> >>> (and it's one more subscription to manage for those of us who want to >> >>> keep >> >>> an eye on all core development-related discussions). >> >>> >> >> >> >> But the other VMs don't necessarily care about the development of the >> >> language, so when the occasional thing comes up regarding all the VMs, >> >> should that require they follow python-dev in its entirety? And I don't >> >> see >> >> the list making sweeping decisions that would affect CPython and >> >> python-dev >> >> without bringing it up there later. Think of the proposed list more >> >> like a >> >> SIG than anything else. >> > >> > Yeah, I think it makes sense. With the current situation, the bridges >> > between the implementations are limited to those with the personal >> > bandwidth to follow their implementation's core list *and* python-dev. >> > With a separate list, it becomes easier to get feedback on cases where >> > we want to check that an idea we're considering is feasible for all >> > the major implementations. >> > >> > It also creates a neutral space for the other VMs to discuss stuff >> > like collaborating on pure Python versions of C implemented modules. >> > If we can get to the point where there's a separate "stdlib-only" pure >> > Python mirror based on CPython's Mercurial repo that other >> > implementations can all share, *without* requiring changes to CPython >> > itself, that would be pretty nice. >> > >> > Cheers, >> > Nick. >> > >> > -- >> > Nick Coghlan | [email protected] | Brisbane, Australia >> > ___ >> > Python-Dev mailing list >> > [email protected] >> > http://mail.python.org/mailman/listinfo/python-dev >> > Unsubscribe: >> > http://mail.python.org/mailman/options/python-dev/guido%40python.org >> >> >> >> -- >> --Guido van Rossum (python.org/~guido) -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Updated PEP 362 (Function Signature Object)
On Sun, Jun 10, 2012 at 1:27 PM, Benjamin Peterson wrote: > 2012/6/10 Larry Hastings : >> Can you make a more concrete suggestion? "type" strikes me as a poor choice >> of name, as it makes one think immediately of type(), which is another, uh, >> variety of "type". > > kind -> > "position" or > "keword_only" or > "vararg" or > "kwarg" > > > -- > Regards, > Benjamin > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/alexandre.zani%40gmail.com I prefer the flags. Flags means I can just look at the Parameter object. A "type" or "kind" or whatever means I need to compare to a bunch of constants. That's more stuff to remember. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Updated PEP 362 (Function Signature Object)
2012/6/10 Alexandre Zani : > > I prefer the flags. Flags means I can just look at the Parameter > object. A "type" or "kind" or whatever means I need to compare to a > bunch of constants. That's more stuff to remember. I don't see why remembering 4 names is any harder than remember four attributes. -- Regards, Benjamin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Updated PEP 362 (Function Signature Object)
On Sun, Jun 10, 2012 at 11:13 PM, Benjamin Peterson wrote: > 2012/6/10 Alexandre Zani : >> >> I prefer the flags. Flags means I can just look at the Parameter >> object. A "type" or "kind" or whatever means I need to compare to a >> bunch of constants. That's more stuff to remember. > > I don't see why remembering 4 names is any harder than remember four > attributes. If it's 4 flags, you can tab-complete on the signature object itself, the meaning of the flags are self-documenting and if you make a mistake, you get an AttributeError which is easier to debug. Also, param.is_args is much simpler/cleaner than param.type == "args" or param.type == inspect.Parameter.VARARGS > > > -- > Regards, > Benjamin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
