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
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
due to
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
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
-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. I
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
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 not
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 of hash
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?
Two
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.
At 10:17 AM 2/20/2007 +, Fuzzyman wrote:
Michele Simionato wrote:
Raymond Hettinger raymond.hettinger at 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
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 iterable.
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
[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 frequent
[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
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-bit
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, 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, y = y)
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 around
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)
return
Steven Bethard steven.bethard at 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;
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 both
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 implementation
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 disagree.
def
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 far,
25 matches
Mail list logo
