On Sun, Feb 1, 2009 at 21:33, "Mark Dickinson" wrote:
> On Sun, Feb 1, 2009 at 6:03 PM, "Martin v. Löwis" wrote:
> > [...] sizeof(void*) may be
> > different from sizeof(cmpfunc*) on some platforms.
> Do you know of a platform where this is actually the case?
> I don't, so if no-one else does e
Campbell Barton wrote:
Hi, I have been writing a new C api that can build with both python 2.6 and 3.0
Questions about using current releases should be directed to the
python-list (or comp.lang.python or gmane.comp.python.general), not
python-dev, which is for development of future releases.
Hi, I have been writing a new C api that can build with both python 2.6 and 3.0
I found that when building with python 2.6, doing "a==b" between 2
different pyrna_struct_Type's would run tp_compare
But with python 3.0, "a==b" will always be false and tp_compare
function would not even run.
The on
Nick Coghlan wrote:
That won't work:
... = 1
File "", line 1
SyntaxError: can't assign to Ellipsis
Well, I was trying to be funny and was under the impression that
Python 3.0 had Unicode identifiers, but apparently it doesn't. (I used
…, not ...)
- Ludvig
_
On Sun, Feb 1, 2009 at 6:03 PM, "Martin v. Löwis" wrote:
> No. I thought someone (you?) proposed that it should cause a runtime
> error if a type definitions fills the tp_compare slot. I say that
> 3.0.1 must not produce such an error.
Thanks. I'm with you now. I'll get rid of the relevant bit
On Sun, Feb 01, 2009, Reto Sch?ttel wrote:
>
> While helping Brandon Rhodes to port PyEphem[1] to Python 3 we
> struggled over a strange locale-related problem on OS X.
Please file a report at bugs.python.org -- that's the only way to ensure
that this gets tracked.
--
Aahz (a...@pythoncraft.com)
Hi
While helping Brandon Rhodes to port PyEphem[1] to Python 3 we
struggled over a
strange locale-related problem on OS X. PyEphem is a library which can
do
astronomical computations like tracking the position of stars, planets
and
earth satellites relative to the earth's position. When tes
Mark Dickinson wrote:
> On Sat, Jan 31, 2009 at 9:28 PM, "Martin v. Löwis" wrote:
>
>> tp_reserved sounds fine. In 3.0.1, filling it with a function pointer
>> should give no error, since that would be a binary-incompatible change.
>
> I'm not sure I understand you here. Are you saying that in
On Sun, Feb 1, 2009 at 4:21 PM, Guido van Rossum wrote:
> Sounds like Martin is referring to your suggestion to raise an
> exception when initializing a type that has a non-NULL thing here. I
> agree with him.
Got it. Thank you.
Mark
___
Python-Dev ma
On Sun, Feb 1, 2009 at 4:22 AM, Mark Dickinson wrote:
> On Sat, Jan 31, 2009 at 9:28 PM, "Martin v. Löwis" wrote:
>
>> tp_reserved sounds fine. In 3.0.1, filling it with a function pointer
>> should give no error, since that would be a binary-incompatible change.
>
> I'm not sure I understand you
On Sat, Jan 31, 2009 at 9:28 PM, "Martin v. Löwis" wrote:
> tp_reserved sounds fine. In 3.0.1, filling it with a function pointer
> should give no error, since that would be a binary-incompatible change.
I'm not sure I understand you here. Are you saying that in your
opinion it is safe to chang
Guido van Rossum writes:
> Depending on the use for the exit function you might or might not want
> it run at the occasion of exec*(). E.g. I imagine that in a typical
> fork() + exec*() scenario, calling the exit functions in the child
> process would be a mistake.
>
> So I don't think the
12 matches
Mail list logo