Mailman 3 March 2009 - Python-Dev

Interpreter crash in test_strftime?
by Antoine Pitrou 03 Mar '09

03 Mar '09

Hello everybody, I'm trying the current py3k under a Windows virtual machine (with VS Express 2008), and the interpreter crashes in test_strftime in test_datetime.py. Has anyone been getting something like that? (not being a Windows user, it's a bit hard for me to investigate what's wrong) Regards Antoine.

2 4

first 3.1 alpha this Saturday
by Benjamin Peterson 03 Mar '09

03 Mar '09

Hi everyone! The first alpha of 3.1 will be coming out this Saturday, so I would appreciate you not breaking anything too egregiously. :) If you think some thing should hold up the release, mark the issue a release blocker or contact me by email or "gutworth" on #python-dev. I have been talking with Antoine about io in C implementation. We would like to merge the branch before Saturday, so it can get some real world testing. io-c, however, hasn't received much through review. Would somebody have time to go through a diff on Rietveld? On Saturday, I will try to start doing the release around 16:00 UTC. -- Regards, Benjamin

2 1

Instructions on using git mirror
by Neil Schemenauer 02 Mar '09

02 Mar '09

I've revised my instructions on using the experimental git mirror of the Python SVN repository: http://python.ca/nas/tmp/git-notes.txt Stories of success or failure welcome. Neil

6 10

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

02 Mar '09

At 09:14 PM 3/2/2009 +0000, Paul Moore wrote: >2009/3/2 Jeffrey Yasskin <jyasskin(a)gmail.com>: > > I tend to think it's a bug in ABCs. You seem to have thought of > > several possible ways to fix it, and I don't have strong preferences > > between them. > >I've discussed ways of fixing simplegeneric, but not of fixing the >issue with ABCs. I'm not sure the ABC "issue" is fixable - after all, >it's by design that ABCs can implement __issubclass__ and "magically" >become superclasses of arbitrary classes as a result. > >I'm not happy about fixing simplegeneric, though, as the whole point >was just to expose an existing implementation, because it might be >generally useful. If we start expanding and enhancing it, there are >better implementations already available on PyPI (better in the sense >of having seen real-world use). And if they don't handle ABCs, then >that might indicate that needing to handle ABCs isn't as vital as this >discussion would seem to imply (but I have no real-world data myself >to make such a claim). I would say it's mainly an annoyance, as long as you have a way to access the method registered for a given ABC, because then you can explicitly register it for types that are being dynamically detected. Now, how widespread an annoyance/FAQ issue it'll be, will depend on: 1. whether the stdlib itself is using GF's and 2. whether those GF's are meaningfully used against ABCs, and 3. how common it is for classes to be "implicit subclasses" of one of those ABCs *and* used with one of those GFs. This sounds like a lot of conditions that have to line up, for it to become an (easily worked-around) annoyance. My inclination is simply to document that it works on explicit type relationships, and note that ABC's and other exotic users of __*check__ methods may require explicit method registrations to work correctly.

1 0

ABCs and simplegeneric use case
by Paul Moore 02 Mar '09

02 Mar '09

2009/3/1 Nick Coghlan <ncoghlan(a)gmail.com>: > As much as I'd like to get a simple generic implementation into > functools, the lack of support for ABCs still bothers me (despite my > last post about that on the tracker item). I'd be a -0 on it going in as > is, but if someone can figure out a clever way of supporting ABCs > without completing killing the invocation speed for generics, that would > go up to a +1. Nick, Armin Ronacher pointed out that it's not likely to be possible to enumerate ABCs even in theory, as ABCs can do semantic checks (e.g. checking for the presence of special methods like __iter__) without needing either inheritance or explicit registration. As you had a genuine use case for simplegeneric, how badly does this limitation damage it? Paul.

2 1

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