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
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
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
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
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
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 ([email protected])
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
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
_
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
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.
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
12 matches
Mail list logo
