In Python 2, PyMapping_Check will return 0 for list objects. In Python
3, it returns 1. Obviously, this makes it rather difficult to
differentiate between mappings and other sized iterables. In addition,
it differs from the behavior of the ``collections.Mapping`` ABC --
isinstance([], collections.M
Thank you for sharing your extensive knowledge of these issues, SJT.
On Sun, May 3, 2009 at 3:32 AM, Stephen J. Turnbull wrote:
> Zooko O'Whielacronx writes:
>
> > However, it is moot because Tahoe is not a new system. It is
> > currently at v1.4.1, has a strong policy of backwards-
> > compat
Larry Hastings wrote:
Removing tp_reserved would affect everybody, with inscrutable
compiler errors.
This would have to be considered in conjunction with the
proposed programmatic type-building API, I think.
I'd like to see a migration towards something like that,
BTW. Recently I had occasio
On Mon, May 4, 2009 at 7:33 AM, Gregor Lingl wrote:
> Hi,
>
> Encouraged by a conversation with Martin at PyCon 2009
> I've prepared a version 1.1b of the turtle module and I'd like to
> get some advice or assistance to get it into the beta as explained
> below. Thus I'd appreciate very much if a
Mark Dickinson wrote:
I *think* that third party code that's recompiled for 3.1 and that
doesn't use the closure field will either just work, or will produce an
easily-fixed compile error. Larry, does this sound right?
Yep.
But I guess the bigger issue is that extensions already compiled
On Mon, May 4, 2009 at 9:15 PM, Antoine Pitrou wrote:
> Mark Dickinson gmail.com> writes:
>>
>> I *think* that third party code that's recompiled for 3.1 and that
>> doesn't use the closure field will either just work, or will produce an
>> easily-fixed compile error. Larry, does this sound righ
Mark Dickinson gmail.com> writes:
>
> I *think* that third party code that's recompiled for 3.1 and that
> doesn't use the closure field will either just work, or will produce an
> easily-fixed compile error. Larry, does this sound right?
This doesn't sound right. The functions in the third par
On Mon, May 4, 2009 at 3:00 PM, Mark Dickinson wrote:
> But I guess the bigger issue is that extensions already compiled against
> 3.0
> that use PyGetSetDef (even if they don't make use of the closure field)
> won't work with 3.1 without a recompile: they'll segfault, or otherwise
> behave
> un
On Mon, May 4, 2009 at 8:11 PM, Daniel Stutzbach
wrote:
> If you make the change, will 3rd party code that relies on it fail in
> unexpected ways, or will they just get a compile error?
I *think* that third party code that's recompiled for 3.1 and that
doesn't use the closure field will either ju
2009/5/4 Bill Janssen :
> Hi, Christian.
>
> Christian Schubert wrote:
>
>> I've created an alternative profiler module which queries per-thread
>> CPU usage via netlink/taskstats, which limits the applicability to
>> Linux (which shouldn't be much of an issue, profiling is usually not
>> done by
On Mon, May 4, 2009 at 4:10 AM, Larry Hastings wrote:
> So: you don't need it, it clutters up our code (particularly typeobject.c),
> and it adds overhead. The only good reason to keep it is backwards
> compatibility, which I admit is a fine reason.
>
If you make the change, will 3rd party code
Amaury Forgeot d'Arc wrote:
Larry Hastings wrote:
My understanding is that there a) 2.x extension modules are not binary
compatible with 3.x, and b) there are essentially no 3.x extension modules
in the field. Is that accurate? If we don't have an installed base (yet)
to worry about, now's
Hi,
Larry Hastings wrote:
>
> Mark Dickinson wrote:
>>
>> Still, binary compatibility seems like a fairly strong reason not to
>> remove the closure field.
>
> My understanding is that there a) 2.x extension modules are not binary
> compatible with 3.x, and b) there are essentially no 3.x extensio
Mark Dickinson wrote:
Still, binary compatibility seems like a fairly strong reason not to
remove the closure field.
My understanding is that there a) 2.x extension modules are not binary
compatible with 3.x, and b) there are essentially no 3.x extension
modules in the field. Is that accura
Hi, Christian.
Christian Schubert wrote:
> I've created an alternative profiler module which queries per-thread
> CPU usage via netlink/taskstats, which limits the applicability to
> Linux (which shouldn't be much of an issue, profiling is usually not
> done by end users).
A surprisingly large
Christian Schubert wrote:
> I've created an alternative profiler module which queries per-thread
> CPU usage via netlink/taskstats, which limits the applicability to
> Linux (which shouldn't be much of an issue, profiling is usually not
> done by end users).
One of the uses for a profiling mod
On Mon, May 04, 2009, Christian Schubert wrote:
>
> Python ships with a profiler module which, unfortunately, is almost
> useless in a multi-threaded environment. *
>
> I've created an alternative profiler module which queries per-thread
> CPU usage via netlink/taskstats, which limits the applicabi
Hi,
Python ships with a profiler module which, unfortunately, is almost useless in
a multi-threaded environment. *
I've created an alternative profiler module which queries per-thread CPU usage
via netlink/taskstats, which limits the applicability to Linux (which shouldn't
be much of an issue,
http://pypi.python.org/pypi
"Copyright © 1990-2007, Python Software Foundation"
:s/2007/2009/
Oleg.
--
Oleg Broytmannhttp://phd.pp.ru/p...@phd.pp.ru
Programmers don't die, they just GOSUB without RETURN.
___
Hi,
Encouraged by a conversation with Martin at PyCon 2009
I've prepared a version 1.1b of the turtle module and I'd like to
get some advice or assistance to get it into the beta as explained
below. Thus I'd appreciate very much if also the release manager
would take notice of this posting.
pyth
On Mon, May 4, 2009 at 10:10 AM, Larry Hastings wrote:
> So: you don't need it, it clutters up our code (particularly typeobject.c),
> and it adds overhead. The only good reason to keep it is backwards
> compatibility, which I admit is a fine reason.
Presumably whoever added the context field h
In issue 5920, Mark Dickinson raises an issue having to do with
float.__format__ and how it handles the default format presentation type
(that is, none of 'f', 'g', or 'e') versus how str() works on floats:
http://bugs.python.org/issue5920
I agree with him that the current behavior is confusin
I should have brought this up to python-dev before--sorry for being so
slow. It's already in the tracker for a couple of days:
http://bugs.python.org/issue5880
The idea: PyGetSetDef has this "void *closure" field that acts like a
context pointer. You stick it in the PyGetSetDef, and it
23 matches
Mail list logo
