Re: [Python-Dev] Posting frequent spurious changes in bugtracker

2013-01-03 Thread Stephen J. Turnbull
Now that Jesus has provided a heads-up, detailed discussion belongs on the metatracker IMO. Warning: Reply-To set to tracker-disc...@python.org. metatracker workers: Created issue500. More info: see this thread: http://mail.python.org/pipermail/python-dev/2013-January/123437.html Brett Cannon w

Re: [Python-Dev] Posting frequent spurious changes in bugtracker

2013-01-03 Thread Glenn Linderman
On 1/3/2013 2:43 PM, Brett Cannon wrote: On Thu, Jan 3, 2013 at 4:06 PM, Glenn Linderman > wrote: On 1/3/2013 12:13 PM, Brett Cannon wrote: It is a form so technically nothing is being done incorrectly in changing values based on what you submit, wh

Re: [Python-Dev] Posting frequent spurious changes in bugtracker

2013-01-03 Thread Brett Cannon
On Thu, Jan 3, 2013 at 4:06 PM, Glenn Linderman wrote: > On 1/3/2013 12:13 PM, Brett Cannon wrote: > > It is a form so technically nothing is being done incorrectly in changing > values based on what you submit, whether you view them stale or not. > > > Well, it sounds like a pretty shaky technol

Re: [Python-Dev] PyTypeObject type names in Modules/

2013-01-03 Thread Benjamin Peterson
2013/1/3 Eli Bendersky : > > > > On Thu, Jan 3, 2013 at 6:50 AM, Benjamin Peterson > wrote: >> >> 2013/1/3 Eli Bendersky : >> > etree has a C accelerator that was improved and extended in 3.3 and was >> > made >> > the default when importing etree. But a regression (issue #16076) occurs >> > becau

Re: [Python-Dev] Posting frequent spurious changes in bugtracker

2013-01-03 Thread Chris Jerdonek
On Thu, Jan 3, 2013 at 1:06 PM, Glenn Linderman wrote: > Jesus' suggestion of a hidden version field would help, but could be > annoying for the case of someone writing a lengthy response, and having it > discarded because the hidden version field is too old... so care would have > to be taken to

Re: [Python-Dev] Posting frequent spurious changes in bugtracker

2013-01-03 Thread Glenn Linderman
On 1/3/2013 12:13 PM, Brett Cannon wrote: It is a form so technically nothing is being done incorrectly in changing values based on what you submit, whether you view them stale or not. Well, it sounds like a pretty shaky technology foundation, if simultaneous updates of a shared data reposito

Re: [Python-Dev] Posting frequent spurious changes in bugtracker

2013-01-03 Thread Brett Cannon
On Thu, Jan 3, 2013 at 2:58 PM, Jesus Cea wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > This happens to me very frequently. > > I get the notification about new issues open in the bugtracker. If I > see an interesting "bug", I usually open a Firefox tab with it, to > monitor it, de

[Python-Dev] Posting frequent spurious changes in bugtracker

2013-01-03 Thread Jesus Cea
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This happens to me very frequently. I get the notification about new issues open in the bugtracker. If I see an interesting "bug", I usually open a Firefox tab with it, to monitor it, decide if I will work on it in the future, whatever. When I have t

Re: [Python-Dev] PyTypeObject type names in Modules/

2013-01-03 Thread Stefan Krah
Eli Bendersky wrote: > Yes, of course. All of that is already implemented in patches Daniel Shahaf > has > submitted to the issue. The "controversial" question here is whether it's > valid > to change the __module__ of the type between 3.3 and 3.3.1 ? In 3.2 and in the Python version of 3.3 we

Re: [Python-Dev] PyTypeObject type names in Modules/

2013-01-03 Thread Eli Bendersky
On Thu, Jan 3, 2013 at 6:50 AM, Benjamin Peterson wrote: > 2013/1/3 Eli Bendersky : > > etree has a C accelerator that was improved and extended in 3.3 and was > made > > the default when importing etree. But a regression (issue #16076) occurs > > because _elementree.Element has no pickling suppor

Re: [Python-Dev] PyTypeObject type names in Modules/

2013-01-03 Thread Benjamin Peterson
2013/1/3 Eli Bendersky : > etree has a C accelerator that was improved and extended in 3.3 and was made > the default when importing etree. But a regression (issue #16076) occurs > because _elementree.Element has no pickling support, while the Python > version does by default (being a plain Python

Re: [Python-Dev] PyTypeObject type names in Modules/

2013-01-03 Thread Eli Bendersky
On Thu, Jan 3, 2013 at 6:43 AM, Benjamin Peterson wrote: > 2013/1/3 Eli Bendersky : > > > > > >> >> > >> >> 2013/1/1 Eli Bendersky : > >> >> > Hello and happy 2013, > >> >> > > >> >> > Something I noticed earlier today is that some C versions of stdlib > >> >> > modules > >> >> > define their name

Re: [Python-Dev] PyTypeObject type names in Modules/

2013-01-03 Thread Benjamin Peterson
2013/1/3 Eli Bendersky : > > >> >> >> >> 2013/1/1 Eli Bendersky : >> >> > Hello and happy 2013, >> >> > >> >> > Something I noticed earlier today is that some C versions of stdlib >> >> > modules >> >> > define their name similarly to the Python version in their >> >> > PyTypeObject. >> >> > Some e

Re: [Python-Dev] PyTypeObject type names in Modules/

2013-01-03 Thread Eli Bendersky
>> > >> 2013/1/1 Eli Bendersky : > >> > Hello and happy 2013, > >> > > >> > Something I noticed earlier today is that some C versions of stdlib > >> > modules > >> > define their name similarly to the Python version in their > PyTypeObject. > >> > Some examples: Decimal, xml.etree's Element. Others

Re: [Python-Dev] More compact dictionaries with faster iteration

2013-01-03 Thread Maciej Fijalkowski
Hello everyone. Thanks raymond for writing down a pure python version ;-) I did an initial port to RPython for experiments. The results (on large dicts only) are inconclusive - it's either a bit faster or a bit slower, depending what exactly you do. There is a possibility I messed something up to