Re: [Python-ideas] a new namedtuple

2017-07-20 Thread Steven D'Aprano
On Tue, Jul 18, 2017 at 06:06:00PM -0300, Joao S. O. Bueno wrote: > In the other thread, I had mentioned my "extradict" implementation - it > does have quite a few differences as it did not try to match namedtuple > API, but it works nicely for all common use cases - these are the timeit >

Re: [Python-ideas] a new namedtuple

2017-07-18 Thread Guido van Rossum
On Tue, Jul 18, 2017 at 3:18 PM, Greg Ewing wrote: > Ethan Furman wrote: > >> I certainly don't expect the signature to change, but why is using a >> metaclass out? The use (or not) of a metaclass /is/ an implementation >> detail. >> > > For me, the main benefit of

Re: [Python-ideas] a new namedtuple

2017-07-18 Thread Ethan Furman
On 07/18/2017 09:09 AM, Guido van Rossum wrote: On Tue, Jul 18, 2017 at 8:56 AM, Ethan Furman wrote: I certainly don't expect the signature to change, but why is using a metaclass out? The use (or not) of a metaclass /is/ an implementation detail. It is until you try to subclass with

Re: [Python-ideas] a new namedtuple

2017-07-18 Thread Joao S. O. Bueno
In the other thread, I had mentioned my "extradict" implementation - it does have quite a few differences as it did not try to match namedtuple API, but it works nicely for all common use cases - these are the timeit timings: (env) [gwidion@caylus ]$ python3 -m timeit --setup "from collections

Re: [Python-ideas] a new namedtuple

2017-07-18 Thread Guido van Rossum
On Tue, Jul 18, 2017 at 8:56 AM, Ethan Furman wrote: > I certainly don't expect the signature to change, but why is using a > metaclass out? The use (or not) of a metaclass /is/ an implementation > detail. > It is until you try to subclass with another metaclass -- then you

Re: [Python-ideas] a new namedtuple

2017-07-18 Thread Ethan Furman
On 07/17/2017 06:25 PM, Eric Snow wrote: On Mon, Jul 17, 2017 at 6:01 PM, Ethan Furman wrote: Guido has decreed that namedtuple shall be reimplemented with speed in mind. FWIW, I'm sure that any changes to namedtuple will be kept as minimal as possible. Changes would be limited to the

Re: [Python-ideas] a new namedtuple

2017-07-18 Thread Nick Coghlan
On 18 July 2017 at 14:31, Guido van Rossum wrote: > On Mon, Jul 17, 2017 at 6:25 PM, Eric Snow > wrote: >> >> On Mon, Jul 17, 2017 at 6:01 PM, Ethan Furman wrote: >> > Guido has decreed that namedtuple shall be reimplemented

Re: [Python-ideas] a new namedtuple

2017-07-17 Thread Guido van Rossum
On Mon, Jul 17, 2017 at 6:25 PM, Eric Snow wrote: > On Mon, Jul 17, 2017 at 6:01 PM, Ethan Furman wrote: > > Guido has decreed that namedtuple shall be reimplemented with speed in > mind. > > FWIW, I'm sure that any changes to namedtuple will be

Re: [Python-ideas] a new namedtuple

2017-07-17 Thread David Mertz
Can you try across a range of tuple sizes? E.g. what about with 100 items? 1000? On Jul 17, 2017 7:56 PM, "Ethan Furman" wrote: On 07/17/2017 06:34 PM, Steven D'Aprano wrote: > On Mon, Jul 17, 2017 at 05:01:58PM -0700, Ethan Furman wrote: > Guido has decreed that

Re: [Python-ideas] a new namedtuple

2017-07-17 Thread Ethan Furman
On 07/17/2017 06:34 PM, Steven D'Aprano wrote: On Mon, Jul 17, 2017 at 05:01:58PM -0700, Ethan Furman wrote: Guido has decreed that namedtuple shall be reimplemented with speed in mind. I haven't timed it (I'm hoping somebody will volunteer to be the bench mark guru), I'll offer my

Re: [Python-ideas] a new namedtuple

2017-07-17 Thread Steven D'Aprano
On Mon, Jul 17, 2017 at 05:01:58PM -0700, Ethan Furman wrote: > Guido has decreed that namedtuple shall be reimplemented with speed in mind. > > I haven't timed it (I'm hoping somebody will volunteer to be the bench mark > guru), I'll offer my NamedTuple implementation from my aenum [1] library.

Re: [Python-ideas] a new namedtuple

2017-07-17 Thread Eric Snow
On Mon, Jul 17, 2017 at 6:01 PM, Ethan Furman wrote: > Guido has decreed that namedtuple shall be reimplemented with speed in mind. FWIW, I'm sure that any changes to namedtuple will be kept as minimal as possible. Changes would be limited to the underlying implementation,

Re: [Python-ideas] a new namedtuple

2017-07-17 Thread Joseph Jevnik
If we are worried about speed but want to keep the same API I have a near drop in replacement for collections.namedtuple that dramatically improves class and instance creation speed [1]. The only things missing from this implementation are `_source` and `verbose` which could be dynamically

Re: [Python-ideas] a new namedtuple

2017-07-17 Thread Ivan Levkivskyi
Just FYI, typing.NamedTuple is there for almost a year and already supports default values, methods, docstrings etc. Also there is ongoing work towards dataclasses PEP, see https://github.com/ericvsmith/dataclasses So that would keep namedtuple API as it is, and focus only on performance

Re: [Python-ideas] a new namedtuple

2017-07-17 Thread Ethan Furman
On 07/17/2017 05:01 PM, Ethan Furman wrote: I haven't timed it (I'm hoping somebody will volunteer to be the bench mark guru), I'll offer my NamedTuple implementation from my aenum [1] library. It uses the same metaclass techniques as Enum, and offers doc string and default value support in

[Python-ideas] a new namedtuple

2017-07-17 Thread Ethan Furman
Guido has decreed that namedtuple shall be reimplemented with speed in mind. I haven't timed it (I'm hoping somebody will volunteer to be the bench mark guru), I'll offer my NamedTuple implementation from my aenum [1] library. It uses the same metaclass techniques as Enum, and offers doc