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 ;
Will testing an array of chars do?
You can easily allocate 4-5Gb on a regular 64bit pc, even with only 1G of ram,
given that your swap space is sufficient.
If you want to excercise your array, then you might get some paging, but it's
not completely impossible.
K
-Original Message-
From:
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
>
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
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
30 matches
Mail list logo
