Re: [Python-Dev] backporting stdlib 2.7.x from pypy to cpython
On 11Jun2012 15:35, PJ Eby p...@telecommunity.com wrote: | Yes, perhaps if the list were *just* a place to cc: in or send a heads-up | to python-dev discussions, and not to have actual list discussions per se, | that would do the trick. This approach has its own problems. Is the proposed list, like many lists, restricted to accept posts only from subscribers? If that is the case, when someone CCs the VM list, everyone honouring the CC in replies needs to be a VM list member if they are not to get annoying bounce messages. It is a core reason that mailing list cross posting is discouraged in many lists; the receivers are not all members of all the cross posted lists, and so get lots of shrapnel when they try to participate. Personally, I am _for_ cross posting (when on topic), except for this unfortunate issue. | IOW, the idea is, If you're a contributor to a non-CPython implementation, | subscribe here to get a heads-up on Python-Dev discussions you should be | following. Not, here's a list to discuss Python implementations in | general, and definitely not a place to *actually conduct discussions* at | all: +1 to this, but how to keep this etiquette maintained? | the only things ever posted there should be cc:'d from or to | Python-Dev, or be pointers to Python-Dev threads. And (premised on my concern above), do people wanting to CC: the VM list for the heads-up purpose need to join it first? Conversely, some of this discussion mentions that people don't subscribe to python-dev; do they need to subscribe to chime in when the bat signal goes off? To reiterate, I'm all for the bat signal, but will there be shrapnel? Hackish idea: suppose there were a special purpose mail forwarder, like a write-only mailing list? It would require special Mailman hackery, but imagine: - a bat-signal list, which rejected posts not from members of python-dev - accepted messages get forwarded to all the relevant VM-specific lists, but with a rewritten From: line of bat-sig...@python.org or such, and we subscribe _that_ address to the relevant lists to allow it in. And replies directed to , as done with bounce messages, perhaps? Or python-dev, probably better. - if the rewritten From: address is the bat-signal list itself (pleasing), the copies sent back are dropped (special hack - drop inbound from the list address) This mechanical approach would get you access control to block spam to the bat-signal and send alerts to the other lists, and send discussion back to python-dev. Cheers, -- Cameron Simpson c...@zip.com.au Nothing is impossible for the man who doesn't have to do it. ___ Python-Dev mailing list Python-Dev@python.org 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
Cameron Simpson writes: This approach has its own problems. Is the proposed list, like many lists, restricted to accept posts only from subscribers? If that is the case, when someone CCs the VM list, everyone honouring the CC in replies needs to be a VM list member if they are not to get annoying bounce messages. Mailman has a feature called sibling lists, which seems to include cross-checking membership on posts, although I'm not sure if it is tuned to exactly this purpose. In any cases, if the proposed list is not a discussion list, it can be configured not to send bounce messages just because somebody honored CC. For example, by keying on the Reference and In-Reply-To headers, and discarding the message if they are present (possible by ordinary configuration of the spam filters). For bonus points, bounce such messages when python-dev is not present among the visible addressees. (Might require a special Handler, but it wouldn't be a big deal to write it because it can be installed only for the new list.) +1 to this, but how to keep this etiquette maintained? A filter on the new list, implemented as above. It's pretty much trivial for those with the know-how. And (premised on my concern above), do people wanting to CC: the VM list for the heads-up purpose need to join it first? Probably not, but this is hardly burdensome; many people with the background to know when to CC: may want to subscribe anyway even if they are subscribed to python-dev, and traffic should be quite low. If even so that's a bother, they can set their subscription to no-mail. Conversely, some of this discussion mentions that people don't subscribe to python-dev; do they need to subscribe to chime in when the bat signal goes off? Maybe not: I believe it's possible to post to python-dev via Gmane if you're not subscribed. Even if they need to be subscribed, there is a wealth of options, including Gmane and the archives, for reading traffic without receiving it as mail (ie, by subscribing and then setting the no-mail flag). Hackish idea: suppose there were a special purpose mail forwarder, like a write-only mailing list? It would require special Mailman hackery, Not that special. ___ Python-Dev mailing list Python-Dev@python.org 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 Jun 13, 2012 8:31 PM, Stephen J. Turnbull step...@xemacs.org wrote: Cameron Simpson writes: This approach has its own problems. Is the proposed list, like many lists, restricted to accept posts only from subscribers? If that is the case, when someone CCs the VM list, everyone honouring the CC in replies needs to be a VM list member if they are not to get annoying bounce messages. Mailman has a feature called sibling lists, which seems to include cross-checking membership on posts, although I'm not sure if it is tuned to exactly this purpose. In any cases, if the proposed list is not a discussion list, it can be configured not to send bounce messages just because somebody honored CC. For example, by keying on the Reference and In-Reply-To headers, and discarding the message if they are present (possible by ordinary configuration of the spam filters). For bonus points, bounce such messages when python-dev is not present among the visible addressees. (Might require a special Handler, but it wouldn't be a big deal to write it because it can be installed only for the new list.) +1 to this, but how to keep this etiquette maintained? A filter on the new list, implemented as above. It's pretty much trivial for those with the know-how. And (premised on my concern above), do people wanting to CC: the VM list for the heads-up purpose need to join it first? Probably not, but this is hardly burdensome; many people with the background to know when to CC: may want to subscribe anyway even if they are subscribed to python-dev, and traffic should be quite low. If even so that's a bother, they can set their subscription to no-mail. Conversely, some of this discussion mentions that people don't subscribe to python-dev; do they need to subscribe to chime in when the bat signal goes off? Maybe not: I believe it's possible to post to python-dev via Gmane if you're not subscribed. Even if they need to be subscribed, there is a wealth of options, including Gmane and the archives, for reading traffic without receiving it as mail (ie, by subscribing and then setting the no-mail flag). Hackish idea: suppose there were a special purpose mail forwarder, like a write-only mailing list? It would require special Mailman hackery, Not that special. Can someone create python-dev-meta? ___ Python-Dev mailing list Python-Dev@python.org 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
Brett Cannon writes: Not necessarily. Just like discussions on SIGs can start and end there, I see no requirement that discussions on the list end up on python-dev. You've missed my point, which is that for many people working on CPython, python-dev will be the natural place to discuss those issues, and the thread will end up on two different lists. Discussions on the list would universally affect all VMs, so there is an incentive to pay attention. You've missed the point again, which is that the incentive only motivates those who care about VMs. It does not motivate those who care about features that affect VMs. ___ Python-Dev mailing list Python-Dev@python.org 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 Mon, Jun 11, 2012 at 8:58 AM, Nick Coghlan ncogh...@gmail.com wrote: On Mon, Jun 11, 2012 at 11:29 AM, Guido van Rossum gu...@python.org wrote: 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. If that's a concern, I'd be happy to limit the use of the new list to Input from other implementations needed on python-dev thread x. At the moment, it's a PITA to chase other implementations to get confirmation that they can cope with a change we're considering, so I'd like confirmation that either: Hm. Maybe we can do something to change the python-dev ethics in order to alleviate the problem? I'm skimming python-dev and read some of the discussion. The problem is when a VM-related question shows up in the message 77 of a thread that does not have anything in topic that would catch my attention. If all the interesting questions that we have to answer are in their own topic, I think it's fine to be subscribed to python-dev, provided I don't have to read all the bikeshedding. But maybe I'm too optimistic and this is not changeable. Cheers, fijal ___ Python-Dev mailing list Python-Dev@python.org 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 Mon, Jun 11, 2012 at 10:46 PM, Nick Coghlan ncogh...@gmail.com wrote: To allow easier transition to a separate list (if that seems necessary at a later date), my preferred colour for the bikeshed is [compatibility-sig]. I for one approve of this bikeshed colour :) -Frank ___ Python-Dev mailing list Python-Dev@python.org 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 Tue, Jun 12, 2012 at 4:09 AM, Stephen J. Turnbull step...@xemacs.orgwrote: Brett Cannon writes: Not necessarily. Just like discussions on SIGs can start and end there, I see no requirement that discussions on the list end up on python-dev. You've missed my point, which is that for many people working on CPython, python-dev will be the natural place to discuss those issues, and the thread will end up on two different lists. Ah, but you helped make my point! For the people working on CPython, python-dev is a natural place. But what about PyPy, IronPython, or Jython (toss in Cython or any future VMs and it just became an even larger spread of teams)? Do they naturally think to discuss things on python-dev or their own list? If anything this new list would act as a showing of good will that python-dev does not view CPython as the centre of the world when it comes to VMs (but obviously does for the language) and that the other VM authors' time as just as important by not forcing them to wade through python-dev (or have to set up a special filter just for python-dev to get the occasional email thread). Discussions on the list would universally affect all VMs, so there is an incentive to pay attention. You've missed the point again, which is that the incentive only motivates those who care about VMs. It does not motivate those who care about features that affect VMs. But if you are doing something which will affect the VMs I hope you do care about VMs period. We can also easily tell someone that they need to discuss something on the other list if needed (we already do this when something should be discussed in a SIG first as well). Anyway, it looks like everyone else chiming in is capitulating to keeping it on python-dev with a proper subject line, so we will start with there and if it proves ineffective I will create the list. ___ Python-Dev mailing list Python-Dev@python.org 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 Tue, Jun 12, 2012 at 9:49 AM, fwierzbi...@gmail.com fwierzbi...@gmail.com wrote: On Mon, Jun 11, 2012 at 10:46 PM, Nick Coghlan ncogh...@gmail.com wrote: To allow easier transition to a separate list (if that seems necessary at a later date), my preferred colour for the bikeshed is [compatibility-sig]. I for one approve of this bikeshed colour :) Fine by me. We will start with that then. ___ Python-Dev mailing list Python-Dev@python.org 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 12/06/2012 15:40, Brett Cannon wrote: Ah, but you helped make my point! For the people working on CPython, python-dev is a natural place. But what about PyPy, IronPython, or Jython (toss in Cython or any future VMs and it just became an even larger spread of teams)? Do they naturally think to discuss things on python-dev or their own list? If anything this new list would act as a showing of good will that python-dev does not view CPython as the centre of the world when it comes to VMs (but obviously does for the language) and that the other VM authors' time as just as important by not forcing them to wade through python-dev (or have to set up a special filter just for python-dev to get the occasional email thread). A bit late in the day and possibly the most stupid suggestion ever, but why not name python-dev cpython-dev? At least everybody would know where they stand. -- Cheers. Mark Lawrence. ___ Python-Dev mailing list Python-Dev@python.org 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 Tue, Jun 12, 2012 at 10:59 AM, Mark Lawrence breamore...@yahoo.co.ukwrote: On 12/06/2012 15:40, Brett Cannon wrote: Ah, but you helped make my point! For the people working on CPython, python-dev is a natural place. But what about PyPy, IronPython, or Jython (toss in Cython or any future VMs and it just became an even larger spread of teams)? Do they naturally think to discuss things on python-dev or their own list? If anything this new list would act as a showing of good will that python-dev does not view CPython as the centre of the world when it comes to VMs (but obviously does for the language) and that the other VM authors' time as just as important by not forcing them to wade through python-dev (or have to set up a special filter just for python-dev to get the occasional email thread). A bit late in the day and possibly the most stupid suggestion ever, but why not name python-dev cpython-dev? At least everybody would know where they stand. Way too much stuff out there says python-dev over cpython-dev. Plus python-dev covers the language of Python as well, which is not specific to CPython. -- Cheers. Mark Lawrence. __**_ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/**mailman/listinfo/python-devhttp://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/**mailman/options/python-dev/** brett%40python.orghttp://mail.python.org/mailman/options/python-dev/brett%40python.org ___ Python-Dev mailing list Python-Dev@python.org 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 Mon, 11 Jun 2012 20:13:53 -0700 fwierzbi...@gmail.com fwierzbi...@gmail.com wrote: On Sun, Jun 10, 2012 at 11:58 PM, Nick Coghlan ncogh...@gmail.com wrote: 1. Asking on python-dev is considered adequate. If an implementation wants to be consulted on changes, one or more of their developers *must* follow python-dev sufficiently closely that they don't miss cross-VM compatibility questions. (My concern is that this isn't reliable - we know from experience that other VMs can miss such questions when they're mixed in with the rest of the python-dev traffic) 2. As 1, but we adopt a subject line convention to make it easier to filter out general python-dev traffic for those that are just interested in cross-vm questions 3. Create a separate list for cross-VM discussions, *including* discussions that aren't directly relevant to Python-the-language or CPython-the-reference-interpreter (e.g. collaborating on a shared standard library fork). python-dev threads may be advertised on the new list if cross-VM feedback is considered particularly necessary. (2) and (3) work for me - I try to do (1) but often miss discussions until they have gone stale. Either would be fine with me too. cheers Antoine. ___ Python-Dev mailing list Python-Dev@python.org 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
Brett Cannon writes: On Tue, Jun 12, 2012 at 4:09 AM, Stephen J. Turnbull step...@xemacs.orgwrote: Brett Cannon writes: Ah, but you helped make my point! Not at all; your point has long since been made. I certainly agree that the current situation is unfortunate. I think it's a bit rude of you to assume that those who oppose a new discussion list don't understand that. The question is whether a new list will be a net positive for the *whole* community, and whether it will significantly benefit the VM developers (beyond giving them some leverage to say you really should have posted this to compatibility-sig, you know!) If anything this new list would act as a showing of good will The road to Hell, as they say. We tried this a couple of times at XEmacs; it didn't work. In practice, threads didn't move, they split, and the actual decisions were taken on the main list, sometimes seriously offending the members of the SIG list. The analogy of topics is not exact, and Python is more disciplined, so it might work better here. But you should plan for it, not merely appeal to men of good will. Anyway, it looks like everyone else chiming in is capitulating to keeping it on python-dev with a proper subject line, so we will start with there and if it proves ineffective I will create the list. At that time, please consider an announce-only list that VM developers can subscribe to in lieu of python-dev (maybe with reply-to directing discussion to python-dev). ___ Python-Dev mailing list Python-Dev@python.org 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 Wed, Jun 13, 2012 at 2:30 PM, Stephen J. Turnbull step...@xemacs.org wrote: Brett Cannon writes: If anything this new list would act as a showing of good will The road to Hell, as they say. We tried this a couple of times at XEmacs; it didn't work. In practice, threads didn't move, they split, and the actual decisions were taken on the main list, sometimes seriously offending the members of the SIG list. The analogy of topics is not exact, and Python is more disciplined, so it might work better here. But you should plan for it, not merely appeal to men of good will. Aye, we already suffer the split discussion problem with import-sig (and any other sig once conclusions are brought to python-dev for ratification, although here every SIG already knows they will eventually have to make their case on the main list for any standard library changes). I think the idea of using topic markers as a way to allow people to set up their own filters that doesn't require spinning out a whole new list is a good compromise. Adding a subject header is even less of a burden than remembering to pass a question to a different list. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org 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 Mon, Jun 11, 2012 at 11:29 AM, Guido van Rossum gu...@python.org wrote: 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. If that's a concern, I'd be happy to limit the use of the new list to Input from other implementations needed on python-dev thread x. At the moment, it's a PITA to chase other implementations to get confirmation that they can cope with a change we're considering, so I'd like confirmation that either: 1. Asking on python-dev is considered adequate. If an implementation wants to be consulted on changes, one or more of their developers *must* follow python-dev sufficiently closely that they don't miss cross-VM compatibility questions. (My concern is that this isn't reliable - we know from experience that other VMs can miss such questions when they're mixed in with the rest of the python-dev traffic) 2. As 1, but we adopt a subject line convention to make it easier to filter out general python-dev traffic for those that are just interested in cross-vm questions 3. Create a separate list for cross-VM discussions, *including* discussions that aren't directly relevant to Python-the-language or CPython-the-reference-interpreter (e.g. collaborating on a shared standard library fork). python-dev threads may be advertised on the new list if cross-VM feedback is considered particularly necessary. As Brett pointed out, it's similar to the resurrection of import-sig - we know that decisions aren't final until they're resolved on python-dev, but it also means we're not flooding python-dev with interminable arcane discussions on import system internals. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org 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 Mon, Jun 11, 2012 at 12:58 AM, Nick Coghlan ncogh...@gmail.com wrote: On Mon, Jun 11, 2012 at 11:29 AM, Guido van Rossum gu...@python.org wrote: 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. If that's a concern, I'd be happy to limit the use of the new list to Input from other implementations needed on python-dev thread x. At the moment, it's a PITA to chase other implementations to get confirmation that they can cope with a change we're considering, so I'd like confirmation that either: 1. Asking on python-dev is considered adequate. If an implementation wants to be consulted on changes, one or more of their developers *must* follow python-dev sufficiently closely that they don't miss cross-VM compatibility questions. (My concern is that this isn't reliable - we know from experience that other VMs can miss such questions when they're mixed in with the rest of the python-dev traffic) 2. As 1, but we adopt a subject line convention to make it easier to filter out general python-dev traffic for those that are just interested in cross-vm questions 3. Create a separate list for cross-VM discussions, *including* discussions that aren't directly relevant to Python-the-language or CPython-the-reference-interpreter (e.g. collaborating on a shared standard library fork). python-dev threads may be advertised on the new list if cross-VM feedback is considered particularly necessary. As Brett pointed out, it's similar to the resurrection of import-sig - we know that decisions aren't final until they're resolved on python-dev, but it also means we're not flooding python-dev with interminable arcane discussions on import system internals. +1 While soliciting feedback on PEP 421 (sys.implementation), the first option got me nearly no responses from the other major Python implementations. In the end, I tracked down which would be the appropriate mailing lists for PyPy, Jython, and IronPython, and directly wrote to them, which seemed a less than optimal approach. It also means that I left out any other interested parties. As well, I'm still not positive I wrote to the best lists for those implementations. Nick's option 2 would be an improvement, but I imagine that option 3 would have been the most effective by far. Of course, the key thing is how closely the various implementors would follow the new list. Only they could say, though Frank Wierzbicki seemed positive about it. FWIW, I also like Nick's idea of redirecting to ongoing python-dev threads and his comparison of the proposed new list to import-sig. -eric ___ Python-Dev mailing list Python-Dev@python.org 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
Eric Snow ericsnowcurrently at gmail.com writes: Nick's option 2 would be an improvement, but I imagine that option 3 would have been the most effective by far. Of course, the key thing is how closely the various implementors would follow the new list. Only they could say, though Frank Wierzbicki seemed positive about it. -eric I'm +1 on such a list, I don't have the time to follow every single thread on python-dev, and I'm sure I miss a lot of things, have a dedicated place for things I know are relevant to my work would be a great help. Alex ___ Python-Dev mailing list Python-Dev@python.org 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 Mon, Jun 11, 2012 at 8:28 AM, Eric Snow ericsnowcurren...@gmail.com wrote: Nick's option 2 would be an improvement, but I imagine that option 3 would have been the most effective by far. Of course, the key thing is how closely the various implementors would follow the new list. Only they could say, though Frank Wierzbicki seemed positive about it. This has come up a couple of times recently (discussions on PEP 421 and PEP 405), so I think it would be worth while. I don't have the time to track all of the different proposals that are in flux; it would be nice to know when they're done and just need a sanity check to make sure everything will work for other implementations. - Jeff ___ Python-Dev mailing list Python-Dev@python.org 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 Mon, Jun 11, 2012 at 12:33 PM, Jeff Hardy jdha...@gmail.com wrote: On Mon, Jun 11, 2012 at 8:28 AM, Eric Snow ericsnowcurren...@gmail.com wrote: Nick's option 2 would be an improvement, but I imagine that option 3 would have been the most effective by far. Of course, the key thing is how closely the various implementors would follow the new list. Only they could say, though Frank Wierzbicki seemed positive about it. This has come up a couple of times recently (discussions on PEP 421 and PEP 405), so I think it would be worth while. I don't have the time to track all of the different proposals that are in flux; it would be nice to know when they're done and just need a sanity check to make sure everything will work for other implementations. Yes, perhaps if the list were *just* a place to cc: in or send a heads-up to python-dev discussions, and not to have actual list discussions per se, that would do the trick. IOW, the idea is, If you're a contributor to a non-CPython implementation, subscribe here to get a heads-up on Python-Dev discussions you should be following. Not, here's a list to discuss Python implementations in general, and definitely not a place to *actually conduct discussions* at all: the only things ever posted there should be cc:'d from or to Python-Dev, or be pointers to Python-Dev threads. That way, we'd have a solution for the periodic, hmm, we should get other implementations to weigh in on this thread problem, that wouldn't actually divide the discussion. Instead, we'd have a Bat Signal (Snake Signal?) to bring the other heroes in to meet with Commissioner Guido. ;-) ___ Python-Dev mailing list Python-Dev@python.org 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 Jun 11, 2012, at 04:58 PM, Nick Coghlan wrote: 1. Asking on python-dev is considered adequate. If an implementation wants to be consulted on changes, one or more of their developers *must* follow python-dev sufficiently closely that they don't miss cross-VM compatibility questions. That's certainly my preference. (My concern is that this isn't reliable - we know from experience that other VMs can miss such questions when they're mixed in with the rest of the python-dev traffic) 2. As 1, but we adopt a subject line convention to make it easier to filter out general python-dev traffic for those that are just interested in cross-vm questions +1 As Brett pointed out, it's similar to the resurrection of import-sig - we know that decisions aren't final until they're resolved on python-dev, but it also means we're not flooding python-dev with interminable arcane discussions on import system internals. I personally already ignore much of python-dev and only chime in on subjects I both care about and delude myself into thinking I have something useful to contribute. For cases where I miss something and need to catch up, Gmane is perfect. -Barry ___ Python-Dev mailing list Python-Dev@python.org 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 Mon, Jun 11, 2012 at 3:35 PM, PJ Eby p...@telecommunity.com wrote: On Mon, Jun 11, 2012 at 12:33 PM, Jeff Hardy jdha...@gmail.com wrote: On Mon, Jun 11, 2012 at 8:28 AM, Eric Snow ericsnowcurren...@gmail.com wrote: Nick's option 2 would be an improvement, but I imagine that option 3 would have been the most effective by far. Of course, the key thing is how closely the various implementors would follow the new list. Only they could say, though Frank Wierzbicki seemed positive about it. This has come up a couple of times recently (discussions on PEP 421 and PEP 405), so I think it would be worth while. I don't have the time to track all of the different proposals that are in flux; it would be nice to know when they're done and just need a sanity check to make sure everything will work for other implementations. Yes, perhaps if the list were *just* a place to cc: in or send a heads-up to python-dev discussions, and not to have actual list discussions per se, that would do the trick. IOW, the idea is, If you're a contributor to a non-CPython implementation, subscribe here to get a heads-up on Python-Dev discussions you should be following. Not, here's a list to discuss Python implementations in general, and definitely not a place to *actually conduct discussions* at all: the only things ever posted there should be cc:'d from or to Python-Dev, or be pointers to Python-Dev threads. Do you know how much of a pain that could become if you were moderator of that list? Having to potentially clear every email that goes to some thread by hand would become nearly unmanageable. That way, we'd have a solution for the periodic, hmm, we should get other implementations to weigh in on this thread problem, that wouldn't actually divide the discussion. Instead, we'd have a Bat Signal (Snake Signal?) to bring the other heroes in to meet with Commissioner Guido. ;-) But we already have the various SIGs carry out discussions outside of python-dev and just bring forward their results to python-dev when they are ready. Why would this list be any different? ___ Python-Dev mailing list Python-Dev@python.org 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 Mon, Jun 11, 2012 at 12:39 PM, Barry Warsaw ba...@python.org wrote: On Jun 11, 2012, at 04:58 PM, Nick Coghlan wrote: 1. Asking on python-dev is considered adequate. If an implementation wants to be consulted on changes, one or more of their developers *must* follow python-dev sufficiently closely that they don't miss cross-VM compatibility questions. That's certainly my preference. Right, because it's easiest for you and everyone else who follows python-dev already. =) But that doesn't improve the situation; those of us who have needed to chat with the other VMs know the status quo is not an optimal (or even decent) solution. I only pull anything off because I know someone on every VM team and so I have email addresses and names. But that shouldn't be a private email conversation, nor should it require that much effort, especially if it requires pulling in someone from some other VM team that I either don't know or didn't have a clue should be included in the conversation. (My concern is that this isn't reliable - we know from experience that other VMs can miss such questions when they're mixed in with the rest of the python-dev traffic) 2. As 1, but we adopt a subject line convention to make it easier to filter out general python-dev traffic for those that are just interested in cross-vm questions +1 But that then requires new people to the list learn about this magical convention. We already know people don't always read the intro paragraph to the mailing list to say this is for development *of* Python, why do you think this will be any better? The anti-top-posting happens only because everyone replies inline so people just naturally follow that. I don't see people remembering to use the magical subject line consistently. This would also be the first time one has to set up a special email filtering rule for python-dev to get a result that people are expected to have available to them. As Brett pointed out, it's similar to the resurrection of import-sig - we know that decisions aren't final until they're resolved on python-dev, but it also means we're not flooding python-dev with interminable arcane discussions on import system internals. I personally already ignore much of python-dev and only chime in on subjects I both care about and delude myself into thinking I have something useful to contribute. For cases where I miss something and need to catch up, Gmane is perfect. But your search area of interest is probably quite larger than that for other VM implementers. Being into VMs and compatibility into language design which the bulk of python-dev is about (and yes, I used that not-equals operator just for you, Barry, to get the point across =). ___ Python-Dev mailing list Python-Dev@python.org 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
Brett Cannon writes: But we already have the various SIGs carry out discussions outside of python-dev and just bring forward their results to python-dev when they are ready. Why would this list be any different? (1) Because AIUI the main problem this list is supposed to solve is contacting interested parties and getting them to come to python-dev where the actual discussion will take place. Almost certainly some of the actual discussion will take place on python-dev, no? It *is* on-topic for python-dev, right? (Guido seems to think so, anyway) So it's not going to focus discussion the way a SIG list does. (2) Because it delegates issue triage to people who don't actually know which of the various VMs will care about a particular change, so it's unlikely to be terribly accurate. (3) The SIGs attract long-term interest from a body of usual suspects. It's worth it to them to invest in the SIG list. While the VM folks will have a long term interest, by the current definition of the new list they won't be starting threads very often! The people who should be starting threads are quite likely to have interest in only one thread, so their incentive to move it to the new list will be low; their natural tendency will be to post to python-dev and let George move the thread if needed. None of that means the new list is a bad idea -- it might be accurate *enough* to be a big improvement, etc -- just that it clearly is different from the various SIGs in some important ways. ___ Python-Dev mailing list Python-Dev@python.org 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 11:58 PM, Nick Coghlan ncogh...@gmail.com wrote: 1. Asking on python-dev is considered adequate. If an implementation wants to be consulted on changes, one or more of their developers *must* follow python-dev sufficiently closely that they don't miss cross-VM compatibility questions. (My concern is that this isn't reliable - we know from experience that other VMs can miss such questions when they're mixed in with the rest of the python-dev traffic) 2. As 1, but we adopt a subject line convention to make it easier to filter out general python-dev traffic for those that are just interested in cross-vm questions 3. Create a separate list for cross-VM discussions, *including* discussions that aren't directly relevant to Python-the-language or CPython-the-reference-interpreter (e.g. collaborating on a shared standard library fork). python-dev threads may be advertised on the new list if cross-VM feedback is considered particularly necessary. (2) and (3) work for me - I try to do (1) but often miss discussions until they have gone stale. I bet (2) would work well enough as long as there are enough interested participants to remember to add the conventional string to the subject of an ongoing discussion. It would be very easy for me to add a filter for such a string. -Frank ___ Python-Dev mailing list Python-Dev@python.org 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 Monday, June 11, 2012, Stephen J. Turnbull wrote: Brett Cannon writes: But we already have the various SIGs carry out discussions outside of python-dev and just bring forward their results to python-dev when they are ready. Why would this list be any different? (1) Because AIUI the main problem this list is supposed to solve is contacting interested parties and getting them to come to python-dev where the actual discussion will take place. Almost certainly some of the actual discussion will take place on python-dev, no? It *is* on-topic for python-dev, right? (Guido seems to think so, anyway) So it's not going to focus discussion the way a SIG list does. Not necessarily. Just like discussions on SIGs can start and end there, I see no requirement that discussions on the list end up on python-dev. (2) Because it delegates issue triage to people who don't actually know which of the various VMs will care about a particular change, so it's unlikely to be terribly accurate. (3) The SIGs attract long-term interest from a body of usual suspects. It's worth it to them to invest in the SIG list. While the VM folks will have a long term interest, by the current definition of the new list they won't be starting threads very often! The people who should be starting threads are quite likely to have interest in only one thread, so their incentive to move it to the new list will be low; their natural tendency will be to post to python-dev and let George move the thread if needed. Discussions on the list would universally affect all VMs, so there is an incentive to pay attention. None of that means the new list is a bad idea -- it might be accurate *enough* to be a big improvement, etc -- just that it clearly is different from the various SIGs in some important ways. -- [sent from my iPad] ___ Python-Dev mailing list Python-Dev@python.org 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 6/11/2012 11:13 PM, fwierzbi...@gmail.com wrote: On Sun, Jun 10, 2012 at 11:58 PM, Nick Coghlanncogh...@gmail.com wrote: 2. As 1, but we adopt a subject line convention to make it easier to filter out general python-dev traffic for those that are just interested in cross-vm questions (2) and (3) work for me - I try to do (1) but often miss discussions until they have gone stale. I bet (2) would work well enough as long as there are enough interested participants to remember to add the conventional string to the subject of an ongoing discussion. It would be very easy for me to add a filter for such a string. This is simple to try and see what happens. [X] or [XI] for X(cross) implementation. --- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org 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 Tue, Jun 12, 2012 at 3:24 PM, Terry Reedy tjre...@udel.edu wrote: This is simple to try and see what happens. [X] or [XI] for X(cross) implementation. To allow easier transition to a separate list (if that seems necessary at a later date), my preferred colour for the bikeshed is [compatibility-sig]. I think a subject line marker is actually a reasonable approach - we can just add the header to the subject line whenever we reach a point in the discussion where we're asking it would be good to get feedback from PyPy/Jython/IronPython/etc on this. It serves exactly the same purpose as posting the question to a separate list would, without risking splitting the discussion. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org 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 2012-06-08, at 20:29 , Brett Cannon wrote: On Fri, Jun 8, 2012 at 2:21 PM, fwierzbi...@gmail.com fwierzbi...@gmail.com wrote: On Fri, Jun 8, 2012 at 10:59 AM, Brett Cannon br...@python.org 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 Python-Dev@python.org 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 br...@yvrsfo.ca 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 | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org 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 ncogh...@gmail.com wrote: On Sun, Jun 10, 2012 at 12:05 PM, Brett Cannon br...@yvrsfo.ca 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 | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org 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 Python-Dev@python.org 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 gu...@python.org 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 ncogh...@gmail.com wrote: On Sun, Jun 10, 2012 at 12:05 PM, Brett Cannon br...@yvrsfo.ca 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 | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org 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 Python-Dev@python.org 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 br...@yvrsfo.ca 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 gu...@python.org 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 ncogh...@gmail.com wrote: On Sun, Jun 10, 2012 at 12:05 PM, Brett Cannon br...@yvrsfo.ca 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 | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org 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 Python-Dev@python.org 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 8/06/2012 9:29 PM, Brett Cannon wrote: On Fri, Jun 8, 2012 at 2:21 PM, fwierzbi...@gmail.com fwierzbi...@gmail.com wrote: On Fri, Jun 8, 2012 at 10:59 AM, Brett Cannon br...@python.org 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 . The only sane option I can see then is to keep doing what you and PyPy are doing and keep a copy of the stdlib, but now you all simply share the repo instead of keeping your own copies and possibly use subrepos to pull it into your own hg repos. P.S. Do we need a python-implementations mailing list or something for discussing overall VM-related stuff among all VMs instead of always bringing this up on python-dev? E.g. I wish I had a place where I could get all the VM stakeholders' attention to make sure that importlib as it stands in Python 3.3 will skip trying to import Python bytecode properly (or if the VMs will simply provide their own setup function and that won't be a worry). And I would have no problem with keeping it like python-committers in terms of closed subscriptions, open archive in order to keep the noise low. I think a python-implementations list would be a fantastic idea - I sometimes miss multi-implementation discussions in python-dev, or at least come in very late. If other people agree then I will get Barry to create it. I will follow a path of contributing the changes using bugs.python.org. Suggested changes will be the minumum needed to make the stdlib modules functional on pypy Thanks, Matti ___ Python-Dev mailing list Python-Dev@python.org 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 Friday, June 8, 2012, Antoine Pitrou wrote: Le 08/06/2012 20:29, Brett Cannon a écrit : P.S. Do we need a python-implementations mailing list or something for discussing overall VM-related stuff among all VMs instead of always bringing this up on python-dev? E.g. I wish I had a place where I could get all the VM stakeholders' attention to make sure that importlib as it stands in Python 3.3 will skip trying to import Python bytecode properly (or if the VMs will simply provide their own setup function and that won't be a worry). And I would have no problem with keeping it like python-committers in terms of closed subscriptions, open archive in order to keep the noise low. I think a python-implementations list would be a fantastic idea - I sometimes miss multi-implementation discussions in python-dev, or at least come in very late. If other people agree then I will get Barry to create it. 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. -Brett Regards Antoine. __**_ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/**mailman/listinfo/python-devhttp://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/**mailman/options/python-dev/** brett%40python.orghttp://mail.python.org/mailman/options/python-dev/brett%40python.org -- [sent from my iPad] ___ Python-Dev mailing list Python-Dev@python.org 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 Fri, Jun 8, 2012 at 8:13 AM, Matti Picus matti.pi...@gmail.com wrote: The windows port of pypy makes special demands on stdlib, specifically that files are explicitly closed. There are some other minor issues, in order to merge all the changes necessary to get pypy windows up to speed, around 10 modules or at least their tests seem to need to be modified. I have been doing a bit of work on the stdlib shipped with pypy 1.9 (version 2.7.2 unfortunately) to make it compliant. Assuming there is interest, what would be the best path to get, for instance, a modified version of mailbox.py with its tests (test_mailbox.py and test_old_mailbox.py) backported to cpython? These fixes would also be useful for IronPython and possibly Jython as well. Unclosed files are probably the biggest set of failures when running CPython's tests on IronPython (along with assuming that sys.platform == 'win32' means Windows). Whether or not they get backported to CPython, it might be worth finding a way to share the 2.7 stdlib between the alternative implementations (changes to 3.x should go into CPython, obviously). - Jeff ___ Python-Dev mailing list Python-Dev@python.org 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 Fri, Jun 8, 2012 at 9:22 AM, Jeff Hardy jdha...@gmail.com wrote: On Fri, Jun 8, 2012 at 8:13 AM, Matti Picus matti.pi...@gmail.com wrote: The windows port of pypy makes special demands on stdlib, specifically that files are explicitly closed. There are some other minor issues, in order to merge all the changes necessary to get pypy windows up to speed, around 10 modules or at least their tests seem to need to be modified. I have been doing a bit of work on the stdlib shipped with pypy 1.9 (version 2.7.2 unfortunately) to make it compliant. Assuming there is interest, what would be the best path to get, for instance, a modified version of mailbox.py with its tests (test_mailbox.py and test_old_mailbox.py) backported to cpython? These fixes would also be useful for IronPython and possibly Jython as well. Unclosed files are probably the biggest set of failures when running CPython's tests on IronPython (along with assuming that sys.platform == 'win32' means Windows). Whether or not they get backported to CPython, it might be worth finding a way to share the 2.7 stdlib between the alternative implementations (changes to 3.x should go into CPython, obviously). I think it's supposed to be alright to push changes to CPython's 2.7 *tests* (like test_mailbox.py) but not other parts of the standard library (like mailbox.py) -- I'd love to find a way to share the modifications from various implementations though -- and in the 3.x future hopefully it can all just end up in CPython's Lib. -Frank ___ Python-Dev mailing list Python-Dev@python.org 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 Fri, 08 Jun 2012 09:39:47 -0700, fwierzbi...@gmail.com fwierzbi...@gmail.com wrote: On Fri, Jun 8, 2012 at 9:22 AM, Jeff Hardy jdha...@gmail.com wrote: On Fri, Jun 8, 2012 at 8:13 AM, Matti Picus matti.pi...@gmail.com wrote: The windows port of pypy makes special demands on stdlib, specifically that files are explicitly closed. There are some other minor issues, in order to merge all the changes necessary to get pypy windows up to speed, around 10 modules or at  least their tests seem to need to be modified. I have been doing a bit of work on the stdlib shipped with pypy 1.9 (version 2.7.2 unfortunately) to make it compliant. Assuming there is interest, what would be the best path to get, for instance, a modified version of mailbox.py with its tests (test_mailbox.py and test_old_mailbox.py) backported to cpython? These fixes would also be useful for IronPython and possibly Jython as well. Unclosed files are probably the biggest set of failures when running CPython's tests on IronPython (along with assuming that sys.platform == 'win32' means Windows). Whether or not they get backported to CPython, it might be worth finding a way to share the 2.7 stdlib between the alternative implementations (changes to 3.x should go into CPython, obviously). I think it's supposed to be alright to push changes to CPython's 2.7 *tests* (like test_mailbox.py) but not other parts of the standard library (like mailbox.py) -- I'd love to find a way to share the modifications from various implementations though -- and in the 3.x future hopefully it can all just end up in CPython's Lib. If you can write a test that shows a problem with the code, it doesn't matter if you found in in a different implementation. As long as the change conforms to our backward compatibility policy it can be fixed in 2.7. And yes, I agree with your understanding that fixing tests (especially for things like resources not getting cleaned up correctly) is appreciated for the 2.7 tests. We should of course verify whether or not similar changes are needed for Python3. As for path to get them in...if you have any question about whether or not the change is appropriate, post a proposed patch to the tracker. --David ___ Python-Dev mailing list Python-Dev@python.org 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 Fri, Jun 8, 2012 at 12:39 PM, fwierzbi...@gmail.com fwierzbi...@gmail.com wrote: On Fri, Jun 8, 2012 at 9:22 AM, Jeff Hardy jdha...@gmail.com wrote: On Fri, Jun 8, 2012 at 8:13 AM, Matti Picus matti.pi...@gmail.com wrote: The windows port of pypy makes special demands on stdlib, specifically that files are explicitly closed. There are some other minor issues, in order to merge all the changes necessary to get pypy windows up to speed, around 10 modules or at least their tests seem to need to be modified. I have been doing a bit of work on the stdlib shipped with pypy 1.9 (version 2.7.2 unfortunately) to make it compliant. Assuming there is interest, what would be the best path to get, for instance, a modified version of mailbox.py with its tests (test_mailbox.py and test_old_mailbox.py) backported to cpython? These fixes would also be useful for IronPython and possibly Jython as well. Unclosed files are probably the biggest set of failures when running CPython's tests on IronPython (along with assuming that sys.platform == 'win32' means Windows). Whether or not they get backported to CPython, it might be worth finding a way to share the 2.7 stdlib between the alternative implementations (changes to 3.x should go into CPython, obviously). I think it's supposed to be alright to push changes to CPython's 2.7 *tests* (like test_mailbox.py) but not other parts of the standard library (like mailbox.py) 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. -- I'd love to find a way to share the modifications from various implementations though -- and in the 3.x future hopefully it can all just end up in CPython's Lib. 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. P.S. Do we need a python-implementations mailing list or something for discussing overall VM-related stuff among all VMs instead of always bringing this up on python-dev? E.g. I wish I had a place where I could get all the VM stakeholders' attention to make sure that importlib as it stands in Python 3.3 will skip trying to import Python bytecode properly (or if the VMs will simply provide their own setup function and that won't be a worry). And I would have no problem with keeping it like python-committers in terms of closed subscriptions, open archive in order to keep the noise low. ___ Python-Dev mailing list Python-Dev@python.org 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 Fri, Jun 8, 2012 at 10:59 AM, Brett Cannon br...@python.org 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). P.S. Do we need a python-implementations mailing list or something for discussing overall VM-related stuff among all VMs instead of always bringing this up on python-dev? E.g. I wish I had a place where I could get all the VM stakeholders' attention to make sure that importlib as it stands in Python 3.3 will skip trying to import Python bytecode properly (or if the VMs will simply provide their own setup function and that won't be a worry). And I would have no problem with keeping it like python-committers in terms of closed subscriptions, open archive in order to keep the noise low. I think a python-implementations list would be a fantastic idea - I sometimes miss multi-implementation discussions in python-dev, or at least come in very late. -Frank ___ Python-Dev mailing list Python-Dev@python.org 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 Fri, Jun 8, 2012 at 2:21 PM, fwierzbi...@gmail.com fwierzbi...@gmail.com wrote: On Fri, Jun 8, 2012 at 10:59 AM, Brett Cannon br...@python.org 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 . The only sane option I can see then is to keep doing what you and PyPy are doing and keep a copy of the stdlib, but now you all simply share the repo instead of keeping your own copies and possibly use subrepos to pull it into your own hg repos. P.S. Do we need a python-implementations mailing list or something for discussing overall VM-related stuff among all VMs instead of always bringing this up on python-dev? E.g. I wish I had a place where I could get all the VM stakeholders' attention to make sure that importlib as it stands in Python 3.3 will skip trying to import Python bytecode properly (or if the VMs will simply provide their own setup function and that won't be a worry). And I would have no problem with keeping it like python-committers in terms of closed subscriptions, open archive in order to keep the noise low. I think a python-implementations list would be a fantastic idea - I sometimes miss multi-implementation discussions in python-dev, or at least come in very late. If other people agree then I will get Barry to create it. ___ Python-Dev mailing list Python-Dev@python.org 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 Fri, Jun 8, 2012 at 11:57 AM, Eric Snow ericsnowcurren...@gmail.com wrote: This would have been handy for feedback on sys.implementation. FWIW I followed the discussion and am happy with the result :) -Frank ___ Python-Dev mailing list Python-Dev@python.org 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
Le 08/06/2012 20:29, Brett Cannon a écrit : P.S. Do we need a python-implementations mailing list or something for discussing overall VM-related stuff among all VMs instead of always bringing this up on python-dev? E.g. I wish I had a place where I could get all the VM stakeholders' attention to make sure that importlib as it stands in Python 3.3 will skip trying to import Python bytecode properly (or if the VMs will simply provide their own setup function and that won't be a worry). And I would have no problem with keeping it like python-committers in terms of closed subscriptions, open archive in order to keep the noise low. I think a python-implementations list would be a fantastic idea - I sometimes miss multi-implementation discussions in python-dev, or at least come in very late. If other people agree then I will get Barry to create it. 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). Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
