Josiah Carlson wrote:
> one thing to note with your method - you can't guarantee the order of the
> attributes as they are being displayed.
>
Actually, my record type *can*; see the hack using the __names__ field.
It won't preserve that order during iteration--but it's only a prototype
so fa
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:
>
> Steven Bethard wrote:
> > On 2/20/07, Larry Hastings <[EMAIL PROTECTED]> wrote:
> >> I considered using __slots__, but that was gonna take too long.
> > Here's a simple implementation using __slots__:
>
> Thanks for steering me to it. However, your
Steven Bethard wrote:
> On 2/20/07, Larry Hastings <[EMAIL PROTECTED]> wrote:
>> I considered using __slots__, but that was gonna take too long.
> Here's a simple implementation using __slots__:
Thanks for steering me to it. However, your implementation and Mr.
Hettinger's original NamedTuple bo
Steven Bethard gmail.com> writes:
> Here's a simple implementation using __slots__:
>
> http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/502237
That's pretty cool! Two suggestions:
1. rename the _items method to __iter__, so that you have easy casting
to tuple and lists;
2. put a check
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
Raymond Hettinger writes:
> Two people had some difficulty building non-upgraded third-party modules
> with Py2.5 on 64-bit machines (I think wxPython was one of the problems)
In my experience wxPython is problematic, period. It's extremely
tightly bound to internal details of everything aroun
On 2/20/07, Larry Hastings <[EMAIL PROTECTED]> wrote:
> # the easy way to define a "subclass" of record
> def Point(x, y):
> return record(x = x, y = y)
>
> # you can use hack-y features to make your "subclasses" more swell
> def Point(x, y):
> x = record(x = x
Larry Hastings wrote:
I'd prefer a lightweight frozen dict, let's call it a "record"
after one of the suggestions in this thread. That achieves symmetry:
mutable & immutable &
heavyweight lightweight
+--
On 2/20/07, Tim Peters <[EMAIL PROTECTED]> wrote:
> In any case, hash codes are defined to be of type "long" in the C API,
> so there appears no painless way to boost their size on boxes where
> sizeof(Py_ssize_t) > sizeof(long).
But that would only be on Windows; I believe other vendors have a
64
[Raymond Hettinger]
> After thinking more about Py_ssize_t, I'm surprised that we're not hearing
> about
> 64 bit users having a couple of major problems.
>
> If I'm understanding what was done for dictionaries, the hash table can grow
> larger than the range of hash values. Accordingly, I would
[Raymond Hettinger]
> The constructor signature ... Point(*fetchall(s)),
> and it allows for direct construction with Point(2,3) without
> the slower and weirder form: Point((2,3)).
[Jim Jewett]
>> If you were starting from scratch, I would agree
>> whole-heartedly; this is one of my most frequen
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
Raymond Hettinger explained:
> The constructor signature ... Point(*fetchall(s)),
> and it allows for direct construction with Point(2,3) without the
> slower and weirder form: Point((2,3)).
If you were starting from scratch, I would agree whole-heartedly;
this is one of my most frequent mistakes
> My suspicion is that building Python for an 64-bit address space is
> still a somewhat academic exercise. I know we don't do this at Google
> (we switch to other languages long before the datasets become so large
> we'd need a 64-bit address space for Python). What's your experience
> at EWT?
Tw
On 2/20/07, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> After thinking more about Py_ssize_t, I'm surprised that we're not hearing
> about
> 64 bit users having a couple of major problems.
>
> If I'm understanding what was done for dictionaries, the hash table can grow
> larger than the range o
If this is not a replay of an old message, please move the discussion
to python-ideas.
On 2/20/07, Steven Elliott <[EMAIL PROTECTED]> wrote:
> I'm finally getting back into this. I'd like to take one more shot at
> it with a revised version of what I proposed before.
>
> For those of you that did
I'm finally getting back into this. I'd like to take one more shot at
it with a revised version of what I proposed before.
For those of you that did not see the original thread it was about ways
that accessing builtins could be more efficient. It's a bit much to
summarize again now, but you sh
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Feb 20, 2007, at 4:47 AM, Raymond Hettinger wrote:
> The other area where I expected to hear wailing and gnashing of
> teeth is users
> compiling with third-party extensions that haven't been updated to
> a Py_ssize_t
> API and still use longs.
Juan Carlos:
Please note that the python-dev list is for the developers of the Python
language, rather than for Python application developer, so your query
isn't really appropriate for this list.
I would suggest that you read the mailman license carefully, as it will
tell you what you are allo
Good morning, thanks a lot for your answer, I confirmed by this means my
subscription.
What I really wish and need is to be able to use Mailman as a freely
distributer , as a distributer of my own mailing lists ,as a mailing list
manager , to be able to send my mails by Mailman and to be able t
Raymond Hettinger schrieb:
> If I'm understanding what was done for dictionaries, the hash table can grow
> larger than the range of hash values. Accordingly, I would expect large
> dictionaries to have an unacceptably large number of collisions. OTOH, we
> haven't heard a single complaint, so
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
On 20 Feb, 2007, at 10:47, Raymond Hettinger wrote:
>
> The other area where I expected to hear wailing and gnashing of
> teeth is users
> compiling with third-party extensions that haven't been updated to
> a Py_ssize_t
> API and still use longs. I would have expected some instability
>
After thinking more about Py_ssize_t, I'm surprised that we're not hearing
about
64 bit users having a couple of major problems.
If I'm understanding what was done for dictionaries, the hash table can grow
larger than the range of hash values. Accordingly, I would expect large
dictionaries to
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
30 matches
Mail list logo
