On Feb 15, 2007, at 2:59 PM, Raymond Hettinger wrote:
> * Enhance doctest with a method that computes updated doctest
> results. If the
> only change I make to a matrix suite is to add commas to long
> numbers in the
> matrix repr(), then it would be nice to have an automated way to
> update
Sorry, forgot to include the output of doctest_driver.py --help.
Here it is:
-Edward
Usage: doctest_driver.py [options] NAME ...
Options:
--version show program's version number and exit
-h, --helpshow this help message and exit
Actions (default=check):
Michele Simionato gmail.com> writes:
> Finally I did some timing of code like this::
>
> from itertools import imap
> Point = namedtuple('Point x y'.split())
>
> lst = [(i, i*i) for i in range(500)]
>
> def with_imap():
> for _ in imap(Point, lst):
> pass
>
> def with_star()
Josiah Carlson wrote:
> Larry Hastings <[EMAIL PROTECTED]> wrote:
>
>> For new code, I can't think of a single place I'd want to use a
>> "NamedTuple" where a "record" wouldn't be arguably more suitable. The
>> "NamedTuple" makes sense only for "fixing" old APIs like os.stat.
>>
> I disa
Larry Hastings <[EMAIL PROTECTED]> wrote:
> For new code, I can't think of a single place I'd want to use a
> "NamedTuple" where a "record" wouldn't be arguably more suitable. The
> "NamedTuple" makes sense only for "fixing" old APIs like os.stat.
I disagree.
def add(v1, v2)
retu
At 09:56 AM 2/20/2007 -0800, Larry Hastings wrote:
>My final bit of feedback: why is it important that a NamedTuple have a
>class name?
In a word: pickling.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python
Michele Simionato wrote:
> ``Contract = namedtuple('Contract stock strike volatility expiration rate
> iscall'.split())`` is not that bad either, but I agree that this is a
> second order issue.
>
That also nicely makes another point: this form accepts not just a list
of strings but any iterab
At 10:17 AM 2/20/2007 +, Fuzzyman wrote:
>Michele Simionato wrote:
>
> >Raymond Hettinger verizon.net> writes:
> >
> >
> >>* Add a pure python named_tuple class to the collections module. I've
> been
> >>using the class for about a year and found that it greatly improves the
> >>usability of
Michele Simionato wrote:
>Raymond Hettinger verizon.net> writes:
>
>
>>* Add a pure python named_tuple class to the collections module. I've been
>>using the class for about a year and found that it greatly improves the
>>usability of tuples as records.
>>http://aspn.activestate.com/ASPN/Co
Raymond Hettinger wrote:
> The constructor signature has been experimented with
> several time and had best results in its current form
> which allows the *args for casting a record set returned
> by SQL or by the CSV module as in Point(*fetchall(s)),
I think you mean something like [Point(*tup) f
>> * I remembered why the __repr__ function had a 'show' argument. I've
>> changed the name now to make it more clear and added a docstring.
>> The idea was the some use cases require that the repr exactly match
>> the default style for tuples and the optional argument allowed for that
>> possibli
Raymond Hettinger rcn.com> writes:
>
> More thoughts on named tuples after trying-out all of Michele's suggestions:
>
> * The lowercase 'namedtuple' seemed right only because it's a function, but
> as a factory function, it is somewhat class-like. In use, 'NamedTuple' more
> closely matches my
More thoughts on named tuples after trying-out all of Michele's suggestions:
* The lowercase 'namedtuple' seemed right only because it's a function, but
as a factory function, it is somewhat class-like. In use, 'NamedTuple' more
closely matches my mental picture of what is happening and distingui
that it is not part of the API.
Thanks for the accolades and the suggestions.
Raymond
- Original Message -
From: "Michele Simionato" <[EMAIL PROTECTED]>
To:
Sent: Monday, February 19, 2007 9:25 PM
Subject: Re: [Python-Dev] Py2.6 ideas
> Raymond Hettinger verizon.net
Raymond Hettinger verizon.net> writes:
> * Add a pure python named_tuple class to the collections module. I've been
> using the class for about a year and found that it greatly improves the
> usability of tuples as records.
> http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/500261
The
"Raymond Hettinger" <[EMAIL PROTECTED]> wrote:
> > Raymond Hettinger schrieb:
> >> d, g, v, t, r = model(somecontract)
>
> [MvL]
> > I find that line quite unreadable
>
> Of course, I can't give you the fully spelled-out line from proprietary code.
> But at this point we're just talking about t
> Raymond Hettinger schrieb:
>> d, g, v, t, r = model(somecontract)
[MvL]
> I find that line quite unreadable
Of course, I can't give you the fully spelled-out line from proprietary code.
But at this point we're just talking about the use cases for tuples with or
without named attributes. Some
Raymond Hettinger schrieb:
> d, g, v, t, r = model(somecontract)
I find that line quite unreadable, and find it likely that I would
not be able to remember the standard order of the fields.
You almost "had me" with the two fields example, but this makes
me think "-1" again.
Is it really that you
> Maybe Raymond's proposed record type should have two versions: one
> that's also a tuple, for compatibility, and one that's just a record.
FWIW, ML unifies tuples and records by defining a tuple to be a record whose
component names are all consecutive integers starting with 1.
For example, in M
[Martin v. Löwis]
>Why does this still need to support the
> tuple interface (i.e. indexed access)?
I used named tuples whereever I need a tuple but the number and meaning
of the fields starts to tax my memory. For doctests, I return a named
tuple like TestResults(failed=0, attempted=15). That n
On 2/16/07, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Martin v. Löwis wrote:
> > Raymond Hettinger schrieb:
> >> No need to go so widely off-track. The idea is to have an efficient type
> >> that
> >> is directly substitutable for tuples but is a bit more self-descriptive.
> >> I like
> >> to h
At 01:38 PM 2/16/2007 +0100, Martin v. Löwis wrote:
>Nick Coghlan schrieb:
> > However, another aspect that occurred to me is that inheriting from
> > tuple has significant practical benefits in terms of speed and memory
> > consumption, at which point it doesn't seem worthwhile to *remove* the
> >
Nick Coghlan schrieb:
> However, another aspect that occurred to me is that inheriting from
> tuple has significant practical benefits in terms of speed and memory
> consumption, at which point it doesn't seem worthwhile to *remove* the
> indexing capability.
I'm not so sure that inheriting fro
Martin v. Löwis wrote:
> Nick Coghlan schrieb:
>>> I'd like to repeat Guido's question: Why does this still need to
>>> support the tuple interface (i.e. indexed access)?
>>
>> So that it remains interoperable with existing libraries that expect a
>> tuple? Otherwise you'd be casting (and copying
Nick Coghlan schrieb:
>> I'd like to repeat Guido's question: Why does this still need to
>> support the tuple interface (i.e. indexed access)?
>
> So that it remains interoperable with existing libraries that expect a
> tuple? Otherwise you'd be casting (and copying) every time you needed to
>
Martin v. Löwis wrote:
> Raymond Hettinger schrieb:
>> No need to go so widely off-track. The idea is to have an efficient type
>> that
>> is directly substitutable for tuples but is a bit more self-descriptive. I
>> like
>> to have the doctest result cast at NamedTuple('TestResults failed
>
Raymond Hettinger schrieb:
> No need to go so widely off-track. The idea is to have an efficient type
> that
> is directly substitutable for tuples but is a bit more self-descriptive. I
> like
> to have the doctest result cast at NamedTuple('TestResults failed attempted).
> The repr of that
On 15/02/2007 20.59, Raymond Hettinger wrote:
> * Add a pure python named_tuple class to the collections module. I've been
> using the class for about a year and found that it greatly improves the
> usability of tuples as records.
> http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/50026
[Raymond Hettinger]
>>> * Add a pure python named_tuple class to the collections module.
>>> I've been using the class for about a year and found that it greatly
>>> improves the usability of tuples as records.
>>> http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/500261
[Delaney, Timothy]
>
On Thu, Feb 15, 2007 at 05:41:51PM -0600, [EMAIL PROTECTED] wrote:
> Tim> Hmm - possibilities. "record" definitely has greater connotations
> Tim> of heterogeneous elements than "tuple", which would put paid to the
> Tim> constant arguments that "a tuple is really just an immutable list
[EMAIL PROTECTED] wrote:
> >> Hm, but why would they still have to be tuples? Why not just
> have a >> generic 'record' class?
>
> Tim> Hmm - possibilities. "record" definitely has greater
> connotations Tim> of heterogeneous elements than "tuple", which
> would put paid to th
>> Hm, but why would they still have to be tuples? Why not just have a
>> generic 'record' class?
Tim> Hmm - possibilities. "record" definitely has greater connotations
Tim> of heterogeneous elements than "tuple", which would put paid to the
Tim> constant arguments that "a tup
Guido van Rossum wrote:
> On 2/15/07, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>> * Add a pure python named_tuple class to the collections module.
>> I've been using the class for about a year and found that it greatly
>> improves the usability of tuples as records.
>> http://aspn.activestate
On 2/15/07, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> * Add a pure python named_tuple class to the collections module. I've been
> using the class for about a year and found that it greatly improves the
> usability of tuples as records.
> http://aspn.activestate.com/ASPN/Cookbook/Python/Recip
* Teach vars() to work with classes defining __slots__. Essentially, __slots__
are just an implementation detail designed to make instances a bit more compact.
* Make the docstring writable for staticmethods, classmethods, and properties.
We did this for function objects and it worked-out well.
35 matches
Mail list logo
