Trent Nelson schrieb:
> On Fri, Mar 20, 2009 at 08:00:46PM +0100, Thomas Heller wrote:
>> Since I do not have a machine with so much memory: Does one
>> of the buildbots allow to run tests for this feature, or
>> do I have to wait for the snakebite farm?
>
> Will you be at PyCon? The wait mig
On Fri, Mar 20, 2009 at 08:00:46PM +0100, Thomas Heller wrote:
> Since I do not have a machine with so much memory: Does one
> of the buildbots allow to run tests for this feature, or
> do I have to wait for the snakebite farm?
Will you be at PyCon? The wait might not be as bad as you think ;
From: python-dev-bounces+kristjan=ccpgames@python.org
[mailto:python-dev-bounces+kristjan=ccpgames@python.org] On Behalf Of
Thomas Heller
Sent: 20. mars 2009 19:01
To: python-dev@python.org
Subject: [Python-Dev] Py_ssize_t support for ctypes arrays and pointers
I received some (s
I received some (so far unfinished) patches for ctypes
that will allow to create arrays with more than 2**31
elements and that will eventually also support pointer
offsets larger than int, on 64-bit platforms.
Since I do not have a machine with so much memory: Does one
of the buildbots allow to ru
Fredrik Lundh schrieb:
>> My suspicion is that building Python for an 64-bit address space is
>> still a somewhat academic exercise.
>
> arbitrary 64-bit systems, perhaps. the first Python system I ever built was
> deployed
> on an LP64 system back in 1995. it's still running, and is still bein
Guido van Rossum wrote:
> My suspicion is that building Python for an 64-bit address space is
> still a somewhat academic exercise.
arbitrary 64-bit systems, perhaps. the first Python system I ever built was
deployed
on an LP64 system back in 1995. it's still running, and is still being
maint
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, 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
> 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
-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.
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
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
On 5/14/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
Georg Brandl wrote:>> Right. At least, not with changing structmember.[ch].>> Did you mean "without"?Oops, right.> Can I submit a patch?I personally don't mind having more types added to structmember,
so I'm +0 on adding Py_ssize_t to the lis
Georg Brandl wrote:
>> Right. At least, not with changing structmember.[ch].
>
> Did you mean "without"?
Oops, right.
> Can I submit a patch?
I personally don't mind having more types added to structmember,
so I'm +0 on adding Py_ssize_t to the list of types supported.
I wonder what the specif
[Neal]
>> Looking in stringobject.c, I don't see how %zu (or %lu) can be used
>> with String_FromFormatV.
[Martin]
> Right. It currently cannot be used. So if it is desired, it needs to
> be added first, and then should be used.
I added it: %u, %lu, and %zu can be used now in PyString_FromFormat
Neal Norwitz wrote:
>> That's a bug. It should print it signed. If unsigned printing of size_t
>> is desired, %zu should be used.
>
> Looking in stringobject.c, I don't see how %zu (or %lu) can be used
> with String_FromFormatV.
Right. It currently cannot be used. So if it is desired, it needs to
On 5/13/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>
> > '%zd' won't work since my value can be negative, and the 'z' modifier
> > converts the argument to size_t.
>
> That's a bug. It should print it signed. If unsigned printing of size_t
> is desired, %zu should be used.
Looking in stringo
Martin v. Löwis wrote:
> Georg Brandl wrote:
>> Similary, there's no way for a structmember to be of type Py_ssize_t...
>
> Right. At least, not with changing structmember.[ch].
Did you mean "without"? Can I submit a patch?
Georg
___
Python-Dev mailin
Georg Brandl wrote:
> Similary, there's no way for a structmember to be of type Py_ssize_t...
Right. At least, not with changing structmember.[ch].
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo
Martin v. Löwis wrote:
> Georg Brandl wrote:
>> which formatting code should be used for a Py_ssize_t value in e.g.
>> PyString_FromFormat?
>
> %zd
>
>> '%zd' won't work since my value can be negative, and the 'z' modifier
>> converts the argument to size_t.
>
> That's a bug. It should print it
Georg Brandl wrote:
> which formatting code should be used for a Py_ssize_t value in e.g.
> PyString_FromFormat?
%zd
> '%zd' won't work since my value can be negative, and the 'z' modifier
> converts the argument to size_t.
That's a bug. It should print it signed. If unsigned printing of size_t
Hi,
which formatting code should be used for a Py_ssize_t value in e.g.
PyString_FromFormat?
'%zd' won't work since my value can be negative, and the 'z' modifier
converts the argument to size_t.
Georg
___
Python-Dev mailing list
Python-Dev@python.org
Thomas Heller wrote:
> #if (PY_VERSION_HEX < 0x0205)
> typedef int Py_ssize_t;
> #define lenfunc inquiry
> #define readbufferproc getreadbufferproc
> #define writebufferproc getwritebufferproc
> #define segcountproc getsegcountproc
> #define charbufferproc getcharbufferproc
> #define ss
M.-A. Lemburg wrote:
> Right, but I don't see the point of each and every
> extension having to go through these hoops when you
> could add support for these checks (including error
> reporting) to the few APIs in question, in particular
> the PyArg_ParseTuple() API.
I don't want to rename the exi
Martin v. Löwis wrote:
> M.-A. Lemburg wrote:
>> What if x64 has a 64-bit value ? How do you catch
>> and process the truncation error ?
>
> We were *both* discussing a scenario where no sizes
> exceed 2**31, right?
Right, but I don't see the point of each and every
extension having to go through
M.-A. Lemburg wrote:
> What if x64 has a 64-bit value ? How do you catch
> and process the truncation error ?
We were *both* discussing a scenario where no sizes
exceed 2**31, right?
Under such a scenario, this just won't happen.
OTOH, if you were discussing a scenario where sizes
might exceed 2
Martin v. Löwis wrote:
> M.-A. Lemburg wrote:
>> ... and then the type change of that variable propagates
>> throughout the extension.
>
> That depends on the usage of the code. If the variable
> is passed by value, no further changes are necessary.
> If a pointer to the variable is passed, you co
M.-A. Lemburg wrote:
> ... and then the type change of that variable propagates
> throughout the extension.
That depends on the usage of the code. If the variable
is passed by value, no further changes are necessary.
If a pointer to the variable is passed, you could replace
it with
Py_ssize_t x
Martin v. Löwis wrote:
> M.-A. Lemburg wrote:
>>> I don't believe the change is major. It only affects a few extensions,
>>> and for these, it is only a minor change. A single line of changing
>>> will be enough.
>>
>> This is true for all the changes related to parameters passed by
>> value. It is
M.-A. Lemburg wrote:
>>I don't believe the change is major. It only affects a few extensions,
>>and for these, it is only a minor change. A single line of changing
>>will be enough.
>
>
> This is true for all the changes related to parameters passed by
> value. It is not true for output parameter
33 matches
Mail list logo
