Re: [Python-Dev] PEP 246: lossless and stateless
On 2005 Jan 16, at 03:17, Phillip J. Eby wrote: ... Uh oh. I just used "view" to describe an iterator as a view on an iterable, as distinct from an adapter that adapts a sequence so that it's iterable. :) I.e., using "view" in the MVC sense where a given Model might have multiple independent Views. I think that in order to do that you need to draw a distinction between two categories of iterables: so, again, a problem of terminology, but one connected to a conceptual difference. An iterator IS-AN iterable: it has __iter__. However, it can't have "multiple independent views"... except maybe if you use itertools.tee for that purpose. Other iterables are, well, ``re-iterables'': each call to their __iter__ makes a new fresh iterator, and using that iterator won't alter the iterable's state. In this case, viewing multiple iterators on the same re-iterables as akin to views on a model seems quite OK. I can't think of any 3rd case -- an iterable that's not an iterator (__iter__ does not return self) but neither is it seamlessly re-iterable. Perhaps the ``file'' built-in type as it was in 2.2 suffered that problem, but it was a design problem, and is now fixed. Alex ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Exceptions *must*? be old-style classes?
Guido van Rossum wrote: The base of the Exception hierarchy happens to be a classic class. But why are they "required" to be classic? More to the point, is this a bug, a missing feature, or just a bug in the documentation for not mentioning the restriction? It's an unfortunate feature; it should be mentioned in the docs; it should also be fixed, but fixing it isn't easy (believe me, or it would have been fixed in Python 2.2). To be honest, I don't recall the exact reasons why this wasn't fixed in 2.2; I believe it has something to do with the problem of distinguishing between string and class exception, and between the various forms of raise statements. I think the main ambiguity is raise "abc", which could be considered short for raise str, "abc", but that would be incompatible with except "abc". I also think that the right way out of there is to simply hardcode a check that says that raise "abc" raises a string exception and raising any other instance raises a class exception. But there's a lot of code that has to be changed. It's been suggested that all exceptions should inherit from Exception, but this would break tons of existing code, so we shouldn't enforce that until 3.0. (Is there a PEP for this? I think there should be.) There's actually a bug open on the fact that exceptions can't be new-style classes: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=518846&group_id=5470 I added some comments to try to stir it up but there ended up being a lot of confusion and I don't think I helped much. The problem is that people want to solve the larger issues (raising strings, wanting to force all exceptions to be new-style, etc) but those all have long-term solutions, while the current bug just languishes. robey ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Exceptions *must*? be old-style classes?
Simon Percivall wrote: What would happen if Exception were made a new-style class, enforce inheritance from Exception for all new-style exceptions, and allow all old-style exceptions as before. string exceptions would break. In addition, code may break which assumes that exceptions are classic instances, e.g. that they are picklable, have an __dict__, and so on. > Am I wrong in assuming that only the most esoteric exceptions inheriting from Exception would break by Exception becoming new-style? Yes, I think so. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Exceptions *must*? be old-style classes?
Phillip J. Eby wrote: Couldn't we require new-style exceptions to inherit from Exception? Since there are no new-style exceptions that work now, this can't break existing code. This would require to make Exception a new-style class, right? This, in itself, could break existing code. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] how to test behavior wrt an extension type?
copy.py, as recently discussed starting from a post by /F, has two kinds of misbehaviors since 2.3 (possibly 2.2, haven't checked), both connected to instance/type/metatype confusion (where do special methods come from? in classic classes and types, from the instance, which may delegate to the type/class; in newstype one, from the class/type which _must not_ delegate to the metaclass): type/metatype confusion, and misbehavior with instances of extension types. So, as per discussion here, I have prepared a patch (to the maintenance branch of 2.3, to start with) which adds unit tests to highlight these issues, and fixes them in copy.py. This patch should go in the maintenance of 2.3 and 2.4, but in 2.5 a different approach based on new special descriptors for special methods is envisaged (though keeping compatibility with classic extension types may also require some patching to copy.py along the lines of my patch). Problem: to write unit tests showing that the current copy.py misbehaves with a classic extension type, I need a classic extension type which defines __copy__ and __deepcopy__ just like /F's cElementTree does. So, I made one: a small trycopy.c and accompanying setup.py whose only purpose in life is checking that instances of a classic type get copied correctly, both shallowly and deeply. But now -- where do I commit this extension type, so that the unit tests in test_copy.py can do their job...? Right now I've finessed the issue by having a try/except ImportError in the two relevant unit tests (for copy and deepcopy) -- if the trycopy module is not available I just don't test how its instances behave under deep or shallow copying. However, if I just commit or send the patch as-is, without putting trycopy.c and its setup.py somewhere, then I'm basically doing a fix without unit tests to back it up, from the point of view of anybody but myself. I do not know what the recommended practice is for this kind of issues, so, I'm asking for guidance (and specifically asking Anthony since my case deals with 2.3 and 2.4 maintenance and he's release manager for both, but, of course, everybody's welcome to help!). Surely this can't be the first case in which a bug got triggered only by a certain behavior in an extension type, but I couldn't find precedents. Ideas, suggestions, ...? Alex ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Exceptions *must*? be old-style classes?
On 2005 Jan 16, at 10:27, Martin v. Löwis wrote: Simon Percivall wrote: What would happen if Exception were made a new-style class, enforce inheritance from Exception for all new-style exceptions, and allow all old-style exceptions as before. string exceptions would break. Couldn't we just specialcase strings specifically, to keep grandfathering them in? In addition, code may break which assumes that exceptions are classic instances, e.g. that they are picklable, have an __dict__, and so on. There would be no problem giving the new class Extension(object): ... a __dict__ and the ability to get pickled, particularly since both come by default. The "and so on" would presumably refer to whether special methods should be looked up on the instance or the type. But as I understand the question (raised in the threads about copy.py) the planned solution is to make special methods their own kind of descriptors, so even that exoteric issue could well be finessed. > Am I wrong in assuming that only the most esoteric exceptions inheriting from Exception would break by Exception becoming new-style? Yes, I think so. It seems to me that if the new-style Exception is made very normally and strings are grandfathered in, we ARE down to exoteric breakage cases (potentially fixable by those new magic descriptors as above for specialmethods). Alex ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Exceptions *must*? be old-style classes?
On 2005 Jan 16, at 10:28, Martin v. Löwis wrote: Phillip J. Eby wrote: Couldn't we require new-style exceptions to inherit from Exception? Since there are no new-style exceptions that work now, this can't break existing code. This would require to make Exception a new-style class, right? Not necessarily, since Python supports multiple inheritance: class MyException(Exception, object): . there -- a newstyle exception class inheriting from oldstyle Exception. (ClassType goes to quite some trouble to allow this, getting the metaclass from _following_ bases if any). Without inheritance you might similarly say: class AnotherOne(Exception): __metaclass__ = type ... This, in itself, could break existing code. Not necessarily, see my previous post. But anyway, PJE's proposal is less invasive than making Exception itself newstyle. Alex ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Exceptions *must*? be old-style classes?
Alex Martelli wrote: What would happen if Exception were made a new-style class, enforce inheritance from Exception for all new-style exceptions, and allow all old-style exceptions as before. string exceptions would break. Couldn't we just specialcase strings specifically, to keep grandfathering them in? Sure. That just wouldn't be the change that Simon described, anymore. You don't specify in which way you would like to specialcase strings. Two alternatives are possible: 1. Throwing strings is still allowed, and to catch them, you need the identical string (i.e. the current behaviour) 2. Throwing strings is allowed, and they can be caught by either the identical string, or by catching str In the context of Simon's proposal, the first alternative would be more meaningful, I guess. The "and so on" would presumably refer to whether special methods should be looked up on the instance or the type. Perhaps. That type(exc) changes might also cause problems. It seems to me that if the new-style Exception is made very normally and strings are grandfathered in, we ARE down to exoteric breakage cases (potentially fixable by those new magic descriptors as above for specialmethods). This would be worth a try. Does anybody have a patch to implement it? Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
RE: [Python-Dev] how to test behavior wrt an extension type?
[Alex] > So, as per discussion here, I have prepared a patch (to the maintenance > branch of 2.3, to start with) which adds unit tests to highlight these > issues, and fixes them in copy.py. This patch should go in the > maintenance of 2.3 and 2.4, but in 2.5 a different approach based on > new special descriptors for special methods is envisaged (though > keeping compatibility with classic extension types may also require > some patching to copy.py along the lines of my patch). For Py2.5, do you have in mind changing something other than copy.py? If so, please outline your plan. I hope your not planning on wrapping all special method access as descriptor look-ups -- that would be a somewhat radical change. Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Re: how to test behavior wrt an extension type?
Alex Martelli wrote: > Problem: to write unit tests showing that the current copy.py misbehaves with > a classic extension > type, I need a classic extension type which defines __copy__ and __deepcopy__ > just like /F's > cElementTree does. So, I made one: a small trycopy.c and accompanying > setup.py whose only purpose > in life is checking that instances of a classic type get copied correctly, > both shallowly and > deeply. But now -- where do I commit this extension type, so that the unit > tests in test_copy.py > can do their job...? Modules/_testcapimodule.c ? (I'm using the C api to define an extension type, after all...) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] how to test behavior wrt an extension type?
On 2005 Jan 16, at 11:17, Raymond Hettinger wrote: [Alex] So, as per discussion here, I have prepared a patch (to the maintenance branch of 2.3, to start with) which adds unit tests to highlight these issues, and fixes them in copy.py. This patch should go in the maintenance of 2.3 and 2.4, but in 2.5 a different approach based on new special descriptors for special methods is envisaged (though keeping compatibility with classic extension types may also require some patching to copy.py along the lines of my patch). For Py2.5, do you have in mind changing something other than copy.py? If so, please outline your plan. I hope your not planning on wrapping all special method access as descriptor look-ups -- that would be a somewhat radical change. The overall plan does appear to be exactly the "somewhat radical change" which you hope is not being proposed, except it's not my plan -- it's Guido's. Quoting his first relevant post on the subject: ''' From: [EMAIL PROTECTED] Subject: Re: getting special from type, not instance (was Re: [Python-Dev] copy confusion) Date: 2005 January 12 18:59:13 CET ... I wonder if the following solution wouldn't be more useful (since less code will have to be changed). The descriptor for __getattr__ and other special attributes could claim to be a "data descriptor" which means that it gets first pick *even if there's also a matching entry in the instance __dict__*. Quick illustrative example: class C(object): foo = property(lambda self: 42) # a property is always a "data descriptor" a = C() a.foo 42 a.__dict__["foo"] = "hello" a.foo 42 Normal methods are not data descriptors, so they can be overridden by something in __dict__; but it makes some sense that for methods implementing special operations like __getitem__ or __copy__, where the instance __dict__ is already skipped when the operation is invoked using its special syntax, it should also be skipped by explicit attribute access (whether getattr(x, "__getitem__") or x.__getitem__ -- these are entirely equivalent). We would need to introduce a new decorator so that classes overriding these methods can also make those methods "data descriptors", and so that users can define their own methods with this special behavior (this would be needed for __copy__, probably). I don't think this will cause any backwards compatibility problems -- since putting a __getitem__ in an instance __dict__ doesn't override the x[y] syntax, it's unlikely that anybody would be using this. "Ordinary" methods will still be overridable. PS. The term "data descriptor" now feels odd, perhaps we can say "hard descriptors" instead. Hard descriptors have a __set__ method in addition to a __get__ method (though the __set__ method may always raise an exception, to implement a read-only attribute). ''' All following discussion was, I believe, in the same thread, mostly among Guido, Phillip and Armin. I'm focusing on getting copy.py fixed in 2.3 and 2.4, w/o any plan yet to implement Guido's idea. If you dislike Guido's idea (which Phillip, Armin and I all liked, in different degrees), it might be best for you to read that other thread and explain the issues there, I think. Alex ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Re: how to test behavior wrt an extension type?
On 2005 Jan 16, at 12:03, Fredrik Lundh wrote: Alex Martelli wrote: Problem: to write unit tests showing that the current copy.py misbehaves with a classic extension type, I need a classic extension type which defines __copy__ and __deepcopy__ just like /F's cElementTree does. So, I made one: a small trycopy.c and accompanying setup.py whose only purpose in life is checking that instances of a classic type get copied correctly, both shallowly and deeply. But now -- where do I commit this extension type, so that the unit tests in test_copy.py can do their job...? Modules/_testcapimodule.c ? (I'm using the C api to define an extension type, after all...) Fine with me, if there are no objections I'll alter the patch accordingly and submit it that way. Thanks, Alex ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Exceptions *must*? be old-style classes?
At 10:28 AM 1/16/05 +0100, Martin v. Löwis wrote: Phillip J. Eby wrote: Couldn't we require new-style exceptions to inherit from Exception? Since there are no new-style exceptions that work now, this can't break existing code. This would require to make Exception a new-style class, right? >>> class MyException(Exception,object): pass >>> Not as far as I can see, no. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] a bunch of Patch reviews
Hello
I've looked at one bug and a bunch of patches and
added a comment to them:
(bug) [ 1102649 ] pickle files should be opened in binary mode
Added a comment about a possible different solution
[ 946207 ] Non-blocking Socket Server
Useless, what are the mixins for? Recommend close
[ 756021 ] Allow socket.inet_aton('255.255.255.255') on Windows
Looks good but added suggestion about when to test for special case
[ 740827 ] add urldecode() method to urllib
I think it's better to group these things into urlparse
[ 579435 ] Shadow Password Support Module
Would be nice to have, I recently just couldn't do the user
authentication that I wanted: based on the users' unix passwords
[ 1093468 ] socket leak in SocketServer
Trivial and looks harmless, but don't the sockets
get garbage collected once the request is done?
[ 1049151 ] adding bool support to xdrlib.py
Simple patch and 2.4 is out now, so...
It would be nice if somebody could have a look at my
own patches or help me a bit with them:
[ 1102879 ] Fix for 926423: socket timeouts + Ctrl-C don't play nice
[ 1103213 ] Adding the missing socket.recvall() method
[ 1103350 ] send/recv SEGMENT_SIZE should be used more in socketmodule
[ 1062014 ] fix for 764437 AF_UNIX socket special linux socket names
[ 1062060 ] fix for 1016880 urllib.urlretrieve silently truncates dwnld
Some of them come from the last Python Bug Day, see
http://www.python.org/moin/PythonBugDayStatus
Thank you !
Regards,
--Irmen de Jong
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 246: let's reset
The various PEP 246 threads are dead AFAIC -- I won't ever have the
time to read them in full length, and because I haven't followed them
I don't get much of the discussion that's still going on.
I hear that Clark and Alex are going to do a revision of the PEP; I'm
looking forward to the results.
In the mean time, here's a proposal to reduce the worries about
implicit adaptation: let's not do it!
Someone posted a new suggestion to my blog: it would be good if an
optimizing compiler (or a lazy one) would be allowed to ignore all
type declarations, and the program should behave the same
(except for things like catching TypeError). This rules out using
adapt() for type declarations, and we're back to pure typechecking.
Given the many and various issues with automamtic adaptation
(transitivity, lossiness, statelessness, and apparently more still)
that might be a better approach.
Typechecking can be trivially defined in terms of adaptation:
def typecheck(x, T):
y = adapt(x, T)
if y is x:
return y
raise TypeError("...")
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 246: let's reset
At 09:15 AM 1/16/05 -0800, Guido van Rossum wrote: Given the many and various issues with automamtic adaptation (transitivity, lossiness, statelessness, and apparently more still) that might be a better approach. Actually, I think Clark, Alex, and I are rapidly converging on a relatively simple common model to explain all this stuff, with only two kinds of adaptation covering everything we've discussed to date in a reasonable way. My most recent version of my pre-PEP (not yet posted) explains the two kinds of adaptation in this way: """One type is the "extender", whose purpose is to extend the capability of an object or allow it to masquerade as another type of object. An "extender" is not truly an object unto itself, merely a kind of "alternate personality" for the object it adapts. For example, a power transformer might be considered an "extender" for a power outlet, because it allows the power to be used with different devices than it would otherwise be usable for. By contrast, an "independent adapter" is an object that provides entirely different capabilities from the object it adapts, and therefore is truly an object in its own right. While it only makes sense to have one extender of a given type for a given base object, you may have as many instances of an independent adapter as you like for the same base object. For example, Python iterators are independent adapters, as are views in a model-view-controller framework, since each iterable may have many iterators in existence, each with its own independent state. Resuming the previous analogy of a power outlet, you may consider independent adapters to be like appliances: you can plug more than one lamp into the same outlet, and different lamps may be on or off at a given point in time. Many appliances may come and go over the lifetime of the power outlet -- there is no inherent connection between them because the appliances are independent objects rather than mere extensions of the power outlet.""" I then go on to propose that extenders be automatically allowed for use with type declaration, but that independent adapters should require additional red tape (e.g. an option when registering) to do so. (An explicit 'adapt()' call should allow either kind of adapter, however.) Meanwhile, no adapt() call should adapt an extender; it should instead adapt the extended object. Clark and Alex have proposed changes to PEP 246 that would support these proposals within the scope of the 'adapt()' system, and I have pre-PEPped an add-on to their system that allows extenders to be automatically assembled from "@like" decorators sprinkled over methods or extension routines. My proposal also does away with the need to have a special interface type to support extender-style adaptation. (I.e., it could supercede PEP 245, because interfaces can then simply be abstract classes or just "like" concrete classes.) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Updated Monkey Typing pre-PEP
I've revised the draft today to simplify the terminology, discussing only two broad classes of adapters. Since Clark's pending proposals for PEP 246 align well with the concept of "extenders" vs. "independent adapters", I've refocused my PEP to focus exclusively on adding support for "extenders", since PEP 246 already provides everything needed for independent adapters. The new draft is here: http://peak.telecommunity.com/DevCenter/MonkeyTyping And you can view diffs from the previous version(s) here: http://peak.telecommunity.com/DevCenter/MonkeyTyping?action=info ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Weekly Python Patch/Bug Summary
Patch / Bug Summary
___
Patches : 272 open ( +5) / 2737 closed (+10) / 3009 total (+15)
Bugs: 793 open ( -5) / 4777 closed (+29) / 5570 total (+24)
RFE : 165 open ( +0) / 141 closed ( +1) / 306 total ( +1)
New / Reopened Patches
__
Enhance tracebacks and stack traces with vars (2005-01-08)
http://python.org/sf/1098732 opened by Skip Montanaro
Single-line option to pygettext.py (2005-01-09)
http://python.org/sf/1098749 opened by Martin Blais
improved smtp connect debugging (2005-01-11)
CLOSED http://python.org/sf/1100140 opened by Wummel
Log gc times when DEBUG_STATS set (2005-01-11)
http://python.org/sf/1100294 opened by Skip Montanaro
deepcopying listlike and dictlike objects (2005-01-12)
http://python.org/sf/1100562 opened by Björn Lindqvist
ast-branch: fix for coredump from new import grammar (2005-01-11)
http://python.org/sf/1100563 opened by logistix
datetime.strptime constructor added (2005-01-12)
http://python.org/sf/1100942 opened by Josh
Feed style codec API (2005-01-12)
http://python.org/sf/1101097 opened by Walter Dörwald
Patch for potential buffer overrun in tokenizer.c (2005-01-13)
http://python.org/sf/1101726 opened by Greg Chapman
ast-branch: hacks so asdl_c.py generates compilable code (2005-01-14)
http://python.org/sf/1102710 opened by logistix
Fix for 926423: socket timeouts + Ctrl-C don't play nice (2005-01-15)
http://python.org/sf/1102879 opened by Irmen de Jong
Boxing up PyDECREF correctly (2005-01-15)
CLOSED http://python.org/sf/1103046 opened by Norbert Nemec
AF_NETLINK sockets basic support (2005-01-15)
http://python.org/sf/1103116 opened by Philippe Biondi
Adding the missing socket.recvall() method (2005-01-16)
http://python.org/sf/1103213 opened by Irmen de Jong
tarfile.py: fix for bug #1100429 (2005-01-16)
http://python.org/sf/1103407 opened by Lars Gustäbel
Patches Closed
__
pydoc data descriptor unification (2004-04-17)
http://python.org/sf/936774 closed by jlgijsbers
xml.dom missing API docs (bugs 1010196, 1013525) (2004-10-21)
http://python.org/sf/1051321 closed by jlgijsbers
Fix for bug 1017546 (2004-08-27)
http://python.org/sf/1017550 closed by jlgijsbers
fixes urllib2 digest to allow arbitrary methods (2005-01-04)
http://python.org/sf/1095362 closed by jlgijsbers
Bug fix 548176: urlparse('http://foo?blah') errs (2003-03-30)
http://python.org/sf/712317 closed by jlgijsbers
bug fix 702858: deepcopying reflexive objects (2003-03-22)
http://python.org/sf/707900 closed by jlgijsbers
minor codeop fixes (2003-05-15)
http://python.org/sf/737999 closed by jlgijsbers
SimpleHTTPServer reports wrong content-length for text files (2003-11-10)
http://python.org/sf/839496 closed by jlgijsbers
improved smtp connect debugging (2005-01-11)
http://python.org/sf/1100140 closed by jlgijsbers
Boxing up PyDECREF correctly (2005-01-15)
http://python.org/sf/1103046 closed by rhettinger
New / Reopened Bugs
___
socket.setdefaulttimeout() breaks smtplib.starttls() (2005-01-08)
http://python.org/sf/1098618 opened by Matthew Cowles
set objects cannot be marshalled (2005-01-09)
CLOSED http://python.org/sf/1098985 opened by Gregory H. Ball
codec readline() splits lines apart (2005-01-09)
CLOSED http://python.org/sf/1098990 opened by Irmen de Jong
Optik OptionParse important undocumented option (2005-01-10)
http://python.org/sf/1099324 opened by ncouture
refman doesn't know about universal newlines (2005-01-10)
http://python.org/sf/1099363 opened by Jack Jansen
raw_input() displays wrong unicode prompt (2005-01-10)
http://python.org/sf/1099364 opened by Petr Prikryl
tempfile files not types.FileType (2005-01-10)
CLOSED http://python.org/sf/1099516 opened by Frans van Nieuwenhoven
copy.deepcopy barfs when copying a class derived from dict (2005-01-10)
http://python.org/sf/1099746 opened by Doug Winter
Cross-site scripting on BaseHTTPServer (2005-01-11)
http://python.org/sf/1100201 opened by Paul Johnston
Scripts started with CGIHTTPServer: missing cgi environment (2005-01-11)
http://python.org/sf/1100235 opened by pacote
Frame does not receive configure event on move (2005-01-11)
http://python.org/sf/1100366 opened by Anand Kameswaran
Wrong "type()" syntax in docs (2005-01-11)
http://python.org/sf/1100368 opened by Facundo Batista
TarFile iteration can break (on Windows) if file has links (2005-01-11)
http://python.org/sf/1100429 opened by Greg Chapman
Python Interpreter shell is crashed (2005-01-12)
http://python.org/sf/1100673 opened by abhishek
test_fcntl fails on netbsd2 (2005-01-12)
http://python.org/sf/1101233 opened
[Python-Dev] "Monkey Typing" pre-PEP, partial draft
This is only a partial first draft, but the Motivation section nonetheless attempts to briefly summarize huge portions of the various discussions regarding adaptation, and to coin a hopefully more useful terminology than some of our older working adjectives like "sticky" and "stateless" and such. And the specification gets as far as defining a simple decorator-based syntax for creating operational (prev. "stateless") and extension (prev. "per-object stateful") adapters. I stopped when I got to the API for declaring volatile (prev. per-adapter stateful) adapters, and for enabling them to be used with type declarations, because Clark's post on his revisions-in-progress seem to indicate that this can probably be handled within the scope of PEP 246 itself. As such, this PEP should then be viewed more as an attempt to formulate how "intrinsic" adapters can be defined in Python code, without the need to manually create adapter classes for the majority of type-compatibility and "extension" use cases. In other words, the implementation described herein could probably become part of the front-end for the PEP 246 adapter registry. Feedback and corrections (e.g. if I've repeated myself somewhere, spelling, etc.) would be greatly appreciated. This uses ReST markup heavily, so if you'd prefer to read an HTML version, please see: http://peak.telecommunity.com/DevCenter/MonkeyTyping But I'd prefer that corrections/discussion quote the relevant section so I know what parts you're talking about. Also, if you find a place where a more concrete example would be helpful, please consider submitting one that I can add. Thanks! PEP: XXX Title: "Monkey Typing" for Agile Type Declarations Version: $Revision: X.XX $ Last-Modified: $Date: 2003/09/22 04:51:50 $ Author: Phillip J. Eby <[EMAIL PROTECTED]> Status: Draft Type: Standards Track Python-Version: 2.5 Content-Type: text/x-rst Created: 15-Jan-2005 Post-History: 15-Jan-2005 Abstract Python has always had "duck typing": a way of implicitly defining types by the methods an object provides. The name comes from the saying, "if it walks like a duck and quacks like a duck, it must *be* a duck". Duck typing has enormous practical benefits for small and prototype systems. For very large frameworks, however, or applications that comprise multiple frameworks, some limitations of duck typing can begin to show. This PEP proposes an extension to "duck typing" called "monkey typing", that preserves most of the benefits of duck typing, while adding new features to enhance inter-library and inter-framework compatibility. The name comes from the saying, "Monkey see, monkey do", because monkey typing works by stating how one object type may *mimic* specific behaviors of another object type. Monkey typing can also potentially form the basis for more sophisticated type analysis and improved program performance, as it is essentially a simplified form of concepts that are also found in languages like Dylan and Haskell. It is also a straightforward extension of Java casting and COM's QueryInterface, which should make it easier to represent those type systems' behaviors within Python as well. Motivation == Many interface and static type declaration mechanisms have been proposed for Python over the years, but few have met with great success. As Guido has said recently [1]_: One of my hesitations about adding adapt() and interfaces to the core language has always been that it would change the "flavor" of much of the Python programming we do and that we'd have to relearn how to write good code. Even for widely-used Python interface systems (such as the one provided by Zope), interfaces and adapters seem to require this change in "flavor", and can require a fair amount of learning in order to use them well and avoid various potential pitfalls inherent in their use. Thus, spurred by a discussion on PEP 246 and its possible use for optional type declarations in Python [2]_, this PEP is an attempt to propose a semantic basis for optional type declarations that retains the "flavor" of Python, and prevents users from having to "relearn how to write good code" in order to use the new features successfully. Of course, given the number of previous failed attempts to create a type declaration system for Python, this PEP is an act of extreme optimism, and it will not be altogether surprising if it, too, ultimately fails. However, if only because the record of its failure will be useful to the community, it is worth at least making an attempt. (It would also not be altogether surprising if this PEP results in the ironic twist of convincing Guido not to include type declarations in Python at all!) Although this PEP will attempt to make adaptation easy, safe, and flexible, the discussion of *how* it will do that must necessarily delve into many detailed aspects of different use cases for adaptation, and the possible pitfalls thereof. It's important
Re: [Python-Dev] "Monkey Typing" pre-PEP, partial draft
Oops. I forgot to cancel this posting; it's an older version. At 11:51 PM 1/15/05 -0500, Phillip J. Eby wrote: This is only a partial first draft, but the Motivation section nonetheless attempts to briefly summarize huge portions of the various discussions regarding adaptation, and to coin a hopefully more useful terminology than some of our older working adjectives like "sticky" and "stateless" and such. And the specification gets as far as defining a simple decorator-based syntax for creating operational (prev. "stateless") and extension (prev. "per-object stateful") adapters. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Re: [Python-checkins] python/dist/src/Python pythonrun.c, 2.161.2.15, 2.161.2.16
[EMAIL PROTECTED] (Kurt B. Kaiser) writes: > [EMAIL PROTECTED] (Kurt B. Kaiser) writes: >> [JH] >>> ../Python/symtable.c:193: structure has no member named `st_tmpname' >>> >>> Do you see that? >> >> Yeah, the merge eliminated it from the symtable struct in symtable.h. >> You moved it to symtable_entry at rev 2.12 in MAIN :-) [...] I checked in a change which adds the st_tmpname element back to symtable. Temporary until someone gets time to evaluate the situation. [...] > Apparently the $(AST_H) $(AST_C): target ran and Python-ast.c was > recreated (without the changes). It's not clear to me how/why that > happened. I did start with a clean checkout, but it seems that the > target only runs if Python-ast.c and/or its .h are missing (they > should have been in the checkout), or older than Python.asdl, which > they are not. I don't see them in the .cvsignore. I believe the problem was caused by the fact that the dates in the local tree aren't the repository dates, so it happened that Parser/Python.adsl had a newer date than Python-ast.[ch]. I did a clean install on my Debian system and got around the issue by touching Python-ast.[c,h] before the build. IMO ASDLGEN s/b a .phony target, run manually as needed by the AST developer. Otherwise there will be no end of trouble when people try to build from CVS after the merge. Absent objection, I'll check in such a change. == The tree compiles, but there is a segfault when make tries to run Python on setup.py. Failure occurs when trying to import site.py == Neal has fixed the import issue and several others!! I was bitten by the Python.asdl / Python-ast.[ch] timing again when updating to his changes Branch now builds and python can be started. There are a number of test failures remaining. -- KBK ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 246, Feedback Request
> - protocol means any object, usually a type or class or interface, > which guides the construction of an adapter Then what do we call the abstract *concept* of a protocol? > - adaptee-class refers to the adaptee's class Please make it explicit that this is a.__class__, not type(a). > - factory refers to a function, f(adaptee) -> adapter, where > the resulting adapter complies with a given protocol Make this adapter factory -- factory by itself is too commonly used. > - First, the registry is checked for a suitable adapter How about checking whether adaptee.__class__ is equal to the protocol even before this? It would be perverse to declare an adapter from a protocol to itself that wasn't the identity adapter. > - PEP 246 will ask for a `adapt' module, with an `adapt' function. Please don't give both the same name. This practice has caused enough problems in the past. The module can be called adaptation, or adapting (cf. threading; but it doesn't feel right so I guess adaptation is better). > - At any stage of adaptation, if None is returned, the adaptation > continues to the next stage. Maybe use NotImplemented instead? I could imagine that occasionally None would be a valid adapter. (And what do we do when asked adapt None to a protocol? I think it should be left alone but not considered an error.) > - At any stage of adaption, if adapt.AdaptException(TypeError) is > raised, then the adaptation process stops, as if None had been > returned from each stage. Why are there two ways to signal an error? TOOWTDI! > - One can also register a None factory from A->B for the > purpose of marking it transitive. In this circumstance, > the composite adapter is built through __conform__ and > __adapt__. The None registration is just a place holder > to signal that a given path exists. Sounds overkill; the None feels too magical. An explicit adapter can't be too difficult to come up with? > There is a problem with the default isinstance() behavior when > someone derives a class from another to re-use implementation, > but with a different 'concept'. A mechanism to disable > isinstance() is needed for this particular case. Do we really have to care about this case? Has someone found that things go harebrained when this case is not handled? It sounds very much like a theoretical problem only. I don't mean that subclasses that reuse implementation without being substitutable are rare (I've seen and written plenty); I mean that I don't expect this to cause additional problems due to incorrect adaptation. > Guido would like his type declaration syntax (see blog entry) to > be equivalent to a call to adapt() without any additional > arguments. However, not all adapters should be created in the > context of a declaration -- some should be created more > explicitly. We propose a mechanism where an adapter factory can > register itself as not suitable for the declaration syntax. I'm considering a retraction of this proposal, given that adaptation appears to be so subtle and fraught with controversies and pitfalls; but more particularly given the possible requirement (which someone added in a response to a blog) that it should be possible to remove or ignore type declarations without changing the meaning of programs that run correctly (except for code that catches TypeError). > - adapt( , intrinsic_only = False) will enable both sorts of adapters, That's one ugly keyword parameter. If we really need this, I'd like to see something that defaults to False and can be switched on by passing mumble=True on the call. But if we could have only one kind that would be much more attractive. Adaptation looks like it is going to fail the KISS test. > There was discussion as to how to get back to the original > object from an adapter. Is this in scope of PEP 246? Seems too complex. Again, KISS. > Sticky adapters, that is, ones where there is only one instance > per adaptee is a common use case. Should the registry of PEP 246 > provide this feature? Ditto. If you really need this, __adapt__ and __conform__ could use a cache. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Getting rid of unbound methods: patch available
https://sourceforge.net/tracker/index.php?func=detail&aid=1103689&group_id=5470&atid=305470 Here's a patch that gets rid of unbound methods, as discussed here before. A function's __get__ method now returns the function unchanged when called without an instance, instead of returning an unbound method object. I couldn't remove support for unbound methods completely, since they were used by the built-in exceptions. (We can get rid of that use once we convert to new-style exceptions.) For backward compatibility, functions now have read-only im_self and im_func attributes; im_self is always None, im_func is always the function itself. (These should issue warnings, but I haven't added that yet.) The test suite passes. (I have only tried "make test" on a Linux box.) What do people think? (My main motivation for this, as stated before, is that it adds complexity without much benefit.) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 246: let's reset
On Sun, 2005-01-16 at 13:00 -0500, Phillip J. Eby wrote: > """One type is the "extender", ... > By contrast, an "independent adapter" ... I really like the way this part of the PEP is sounding, since it really captures two almost, but not quite, completely different use-cases, the confusion between which generated all the discussion here in the first place. The terminology seems a bit cumbersome though. I'd like to propose that an "extender" be called a "transformer", since it provides a transformation for an underlying object - it changes the shape of the underlying object so it will fit somewhere else, without creating a new object. Similarly, the cumbersome "independent adapter" might be called a "converter", since it converts A into B, where B is some new kind of thing. Although the words are almost synonyms, their implications seem to match up with what's trying to be communicated here. A "transformer" is generally used in the electrical sense - it is a device which changes voltage, and only voltage. It takes in one flavor of current and produces one, and exactly one other. Used in the electrical sense, a "converter" is far more general, since it has no technical meaning that I'm aware of - it might change anything about the current. However, other things are also called converters, such as currency converters, which take one kind of currency and produce another, separate currency. Similar to "independent adapters", this conversion is dependent on a moment in time for the conversion - after the conversion, each currency may gain or lose value relative to the other. If nobody likes this idea, it would seem a bit more symmetric to have "dependent" and "independent" adapters, rather than "extenders" and "independent adapters". As it is I'm left wondering what the concept of dependency in an adapter is. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Getting rid of unbound methods: patch available
On Sun, 2005-01-16 at 22:12 -0800, Guido van Rossum wrote: > What do people think? (My main motivation for this, as stated before, > is that it adds complexity without much benefit.) > *** > *** 331,339 > def test_im_class(): > class C: > def foo(self): pass > - verify(C.foo.im_class is C) ^ Without this, as JP Calderone pointed out earlier, you can't serialize unbound methods. I wouldn't mind that so much, but you can't tell that they're any different from regular functions until you're *de*-serializing them. In general I like the patch, but what is the rationale for removing im_class from functions defined within classes? ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Re: Getting rid of unbound methods: patch available
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > What do people think? (My main motivation for this, as stated before, > is that it adds complexity without much benefit.) >From the viewpoint of learning and explaining Python, this is a plus. I never understood why functions were wrapped as unbounds until this proposal was put forth and discussed. Terry J. Reedy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
