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
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
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
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.
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,
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
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
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
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
This doesn't require a PEP as it falls under "adding" to a pre-existing
module: https://devguide.python.org/stdlibchanges/.
On Sun, 16 Jul 2017 at 22:06 Evan Adler wrote:
> I would like to submit the following proposal. In the logging module, I
> would like handlers
First, I would like to make it clear that I am not claiming that
the current design of standard Exceptions cannot be improved, nor do I
necessarily have a problem with doing it at the BaseException level.
My argument has always been directed to the issue of "does changing
BaseException actually
On 16/07/17 16:15, Steven D'Aprano wrote:
Hi Connor, and welcome!
On Sun, Jul 16, 2017 at 10:37:26AM -0400, Connor Farrell wrote:
Background: I work in scientific computing and use Community Pycharm IDE.
In the end, I end up with very well folded code (except for large parameter
lists) and a
On 17 July 2017 at 04:59, Ken Kundert wrote:
> Nick,
> I see. The Python C interface provides a very simple way of raising an
> exception in the case where the exception is only passed one argument, the
> error
> message. It even makes it easy to interpolate
13 matches
Mail list logo