Mailman 3 March 2009 - Python-Dev

Re: [Python-Dev] ABCs and MRO
by P.J. Eby 02 Mar '09

02 Mar '09

At 10:41 AM 3/2/2009 +0000, Paul Moore wrote: >2009/3/2 Benjamin Peterson <benjamin(a)python.org>: > > 2009/3/1 Paul Moore <p.f.moore(a)gmail.com>: > >> > >> Is it worth getting simplegeneric exposed in 3.1 > >> (http://bugs.python.org/issue5135)? If it's going to be in 2.7, I'd > >> like to see it hit 3.1. The patch is against trunk (for 2.7) at the > >> moment, I'm not sure what the process would be for forward-porting it > >> (do I generate a new patch against the py3k branch, or should it be > >> applied to trunk and merged in?) By the way guys, are you aware of: http://pypi.python.org/pypi/simplegeneric There might be a bit of name confusion by exposing pkgutils' internal simplegeneric there. Perhaps it should be called "trivialgeneric", as it's even tinier than simplegeneric. ;-) >The key problem with the patch is that ABCs do not play well with the >type of introspection required to implement a generic function - >namely enumeration of the superclasses of a class. The MRO of the >class is fine for normal inheritance, but for ABCs it is possible to >register classes which don't inherit from the ABC, so that you have a >situation where issubclass (C, MyABC) can be true without MyABC being >in C.__mro__: > > >>> import abc > >>> class MyABC(object): >... __metaclass__ = abc.ABCMeta >... > >>> class C(object): >... pass >... > >>> MyABC.register(C) > >>> issubclass(C, MyABC) >True > >>> C.__mro__ >(<class '__main__.C'>, <type 'object'>) > >>> > >More generally, there is NO WAY to determine the list of classes for >which issubclass(C, x) is true. > >This could be considered a limitation of, or a bug in, ABCs, I don't >have a particular opinion on that, but it does mean that no code which >relies on being able to traverse the class inheritance graph will see >ABCs. One particular case of this is (any implementation I can think >of, of) generic functions. > >In my view, this implies one of the following: > >1) It should be a documented limitation of such code that it doesn't >work with ABCs (and conversely, this limitation of ABCs should be >documented in the ABC documentation) >2) Generic functions, and any other code requiring this type of >introspection, is essentially useless unless it can support ABCs, and >should not be used in the light of this limitation. >3) This is a bug in ABCs and should be fixed. >4) Something else I didn't think of :-) > >In my view, (2) is an unreasonable position to take, given the fact >that (as I understand it) ABCs are supposed to be largely optional and >shouldn't affect code that doesn't care about them... > >It's not clear to me how (3) should be addressed. Adding a slot to all >classes to hold a list of ABCs they are registered against seems to be >a large overhead for a relatively rarely used feature. I guess having >a global registry of ABC registrations could work, but it seems >clumsy. Any other suggestions? This isn't really a new problem; if you base your generic function methods off of interfaces implemented by a type or instance, you have the same basic issues. For systems that use a cache based on object type (like Guido's tuple-dispatch prototype, and my enhanced version in PEAK-Rules), the actual lookup is not a big deal. You have a type-based test and you cache the result for the type. PEAK-Rules' predicate dispatching is a bit more complex, because you need a rather more complex type test; the tree generator has to look at whether a type test is an ABC, and effectively translate it to "oldstyleisinstance(arg, ABC) or not oldstyleisinstance(arg, ABC) and ABC.__instancecheck__(arg)". (Where oldstyleisinstance represents an __instancecheck__-free version of isinstance.) This isn't a major problem either, just a bit of a bore/pain to implement. The hairier issue for these types of systems is method precedence, though. Since __mro__'s have to be consistently ordered, you can straightforwardly determine whether one class is "more specific" than another in a static way. But with dynamic registration, the question could be more complex. Personally, I'd like to see some way to subscribe to changes in ABC registration, so that generic functions or other tools can update their caches. With that feature, you might even be able to implement full ABC support for simplegeneric, by treating ABC registrations as equivalent to mass registration of the ABC's registrants. That is, if "AnABC.register(X)" and "afunc.register(AnABC, meth)" then "afunc.register(X, meth)". So each time AnABC gets a new registrant, you automatically register the ABC method for the new registrant, as long as there's not already a method registered for that specific type. That would probably be sufficient for what simplegeneric is doing.

2 1

help-tkinter
by ramesh nayak 02 Mar '09

02 Mar '09

Dear Sir, I have a fortran-95 code for my own mathematical application . and also I have the *.exe fiel for the same. when I double click it , it will run. I want to make a GUI for it by using TKinter and run the program through the button on GUI. Could you please send the syntax for the same? Thanks in advance for your help. Thanks. Regards Ramesh

2 1

executable
by toks teewey 02 Mar '09

02 Mar '09

Hello, I want to ask if it is possible to link a program written in python to a database and also on how to make a program written in python executable. Regards

2 1

Patch Ready for review
by Heracles 01 Mar '09

01 Mar '09

I have a patch submitted, with docs changes etc. The patch is to the curses library module, and adds support for color_set, addchstr, addchnstr, mvaddchstr, mvaddchnstr, mvwaddchstr, mvwaddchnstr, waddchstr, and waddchnstr. I am wondering what to expect next. How long will it be before it is applied etc. This is my first attempt to submit a patch to Python. Also, does anyone know who the main person is for running changes to the curses library I wanted to get guidance for implementing support for family of functions newterm, set_term, reset_term. The main question I have is to support these functions consistently, would it be recommended to implement a new Python Screen object? -- View this message in context: http://www.nabble.com/Patch-Ready-for-review-tp22254109p22254109.html Sent from the Python - python-dev mailing list archive at Nabble.com.

2 2