At 09:56 AM 11/24/2007 -0800, Guido van Rossum wrote:
>Also, there was discussion of this before:
>-- why didn't we decide to do it then?
There were also a few protests of use cases that could not be worked
around (e.g. pickling methods), and a few people pointed out that the
type checking actually *is* useful when using explicit base calls
(BaseClass.somemethod(self,...)), as it usually catches when you
forget to include the self argument.)
(Note that super() doesn't do away with the need for such explicit
upcalls, especially in __init__, as multiple-inheriting classes with
non-cooperative bases usually need to individually call the base
class __init__ methods.)
I'm having a bit of a trouble getting the deprecation warning for
backquotes `repr` right. Neither the ast_for_* functions in Python/ast.c
nor the node structures have access to the filename.
Should the node structure gain an additional field to drag the filename
around? Or can we simply life with the fact that the user won't get a
filename in the deprecation warning?
since ssl module is still in development I thought it would have been
better asking such question here instead of on comp.lang.python.
I'm interested in using the ssl module with asyncore but since there's
no real documentation about it yet I've been not able to write
something useful with it.
Currently I'm trying to add the SSL support to an asyncore-based FTP
server I wrote.
I tried to write some code by watching the ssl-related test-suite
scripts with no luck since there are no available tests for asyncore
I tried to play with the wrap_socket() function a little bit but
different types of error are raised every time.
I'm sure this happens because I'm not doing things in the right way.
Could someone please show me an example code about how the ssl module
could be integrated with asyncore?
Dear fellow Python developers!
The Python bug tracker contains more than 1,300 bugs and it's growing.
And growing ... and growing. I'm picking a bug once in a while or
tossing some invalid bugs away but it's a helpless cause. The bugs are
augmenting with anybody stopping them.
Well, I'm exaggerating a bit but you probably get my point. The core
developers can't keep up with new bugs and check old bugs at the same
time. The resources are already stretched thin. But Brett gave me an
idea how we could solve the problem when he posted the link to
What do you think about inviting some trustworthy and experienced Python
users to join the cause? They don't need to solve every problem and they
won't need developer access to the svn. Instead their task is cleaning
up the tracker, categorizing bugs and checking patches. The tracker sure
contains a lot of outdated junk and already fixed bugs.
A group of five to ten highly motivated people could squall through the
tracker smashing all those ugly bugs like the infantry in Starship
Troopers - but hopefully with less loss on our side. :]
At 08:19 PM 11/22/2007 -0800, Guido van Rossum wrote:
>It looks like we're in agreement to drop unbound methods and have a
>reasonable set or arguments around it (e.g. keep staticmethod, no
>changes to methods of builtin types, etc.). Do we need a PEP? It's
>essentially a 2-line change in funcobject.c (func_descr_get()) -- plus
>fixing up half a dozen or so unittests that specifically seem to test
>the behavior of unbound methods.
Since the only meaningful difference between an unbound method and a
function is the availability of the im_class attribute, I Googled
'im_class ext:py' to see what's using it. There were 314 hits uses
in published code, and I skimmed the first 60 or 70 of those.
Of the ones I looked at, relatively few actually do anything with
unbound methods specifically. Most are just custom pickling or
persistence for methods, or method replacements like a "weakref
method" that doesn't keep a strong reference to im_self.
However, a few uses relevant to unbound methods turned up,
however. Some documentation tools, an AOP library, an xreload()-like
module reloader from Enthought, plus one usage in the stdlib.
There were also a few modules where it was difficult to tell if
unbound methods were actually important. While for most of the
documentation tools it was probably not relevant, there were some
(like a method deprecation utility) that looked like they would lose
functionality by not being able to get the im_class of an object.
The stdlib usage is in the unittest module: the test loading
machinery needs to know the class of an unbound method so it knows
what TestCase subclass to instantiate, when loading a single test by
name. This could probably be worked around by making the routine
keep track of the object from which the target object was retrieved.
This is far from a comprehensive survey; 'UnboundMethodType ext:py'
turns up 102 more hits, including another testing tool that uses
unbound methods in a different way. There are also usage patterns
that can't easily be searched for. For example, code that wants to
be able to distinguish static methods and instance methods at the class level.
Most of these use cases could probably be worked around, with
sufficient effort. Many will probably have bigger problems porting
to 3.0 than the absence of unbound methods. And I don't personally
have a horse in this race, as my own code is surprisingly free of im_class use.
Actually, given how many places my code is peppered with '.im_func'
calls to *unwrap* unbound methods and reuse them in other classes, I
probably lean more towards getting rid of them. :)
Just for your information: I've back-ported the PCbuild9 directory from
py3k to the trunk. You now can build Python 2.6 and 3.0 with the new
Visual Studio 2008. As far as I've heard from other it works with the
free Express Edition.
MSDN subscribers with the Standard or Professional version can also
create PGO builds with the new directory. Preliminary tests are showing
that PGO builds are roughly 10% faster than standard builds.
Is it only me who thinks that the current daily summaries are a bit
frequent? Would it be possible to reduce the frequency to, say, once a
I can set up a filter to simply ditch the things, but I thought I'd
check what other people's views are before I did.
An extension module I use makes extensive use of the PyGILState API's
in callback functions for C APIs. Some of the functions that use the
PyGILState APIs are used in the tp_dealloc of methods. This seems
cause problems when objects are cleaned up during interpreter
shutdown: when an object is deallocated during
PyInterpreterState_Clear I get a hard crash because the GILState
machinery has been shut down at that time :-(
The bug report for this: http://bugs.python.org/issue1402
The report includes a patch, but I know just enough about the python
threading infrastructure to be dangerous and am not convinced that the
patch is actually correct.
At 01:41 AM 11/22/2007 +0100, Amaury Forgeot d'Arc wrote:
>Could we check for "real" inheritance first, and call
>__instancecheck__ only when the previous is false? It would speed-up
>the common cases.
>Or is there really a use case for a derived class to appear as NOT
>being a subclass of its base class?
The only reason to do this would be to work around badly written
code, but IMO the cure is worse than the disease at that point.
The lookup sequence should probably be something like:
1. type(ob) is cls
2. issubclass(type(ob), cls)
3. ob.__class__ is cls
4. issubclass(ob.__class__, cls)
Where issubclass() checks __mro__ before calling the subclass check
method, and #3 and #4 can be skipped if ob.__class__ is type(ob).