Re: [Python-Dev] Getting rid of unbound methods: patch available
Guido van Rossum wrote: What do people think? (My main motivation for this, as stated before, is that it adds complexity without much benefit.) I'm in favour, since it removes the "an unbound method is almost like a bare function, only not quite as useful" distinction. It would allow things like str.join(sep, seq) to work correctly for a Unicode separator. It also allows 'borrowing' of method implementations without inheritance. I'm a little concerned about the modification to pyclbr_input.py, though (since it presumably worked before the patch). Was the input file tweaked before or after the test itself was fixed? (I'll probably get around to trying out the patch myself, but that will be on Linux as well, so I doubt my results will differ from yours). The other question is the pickling example - an unbound method currently stores meaningful data in im_class, whereas a standard function doesn't have that association. Any code which makes use of im_class on unbound methods (even without involving pickling)is going to have trouble with the change. (Someone else will need to provide a real-life use case though, since I certainly don't have one). Regards, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.skystorm.net ___ Python-Dev mailing list Python-Dev@python.org 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?
Hi,
On Fri, Jan 14, 2005 at 07:20:31PM -0500, Jim Jewett wrote:
> The base of the Exception hierarchy happens to be a classic class.
> But why are they "required" to be classic?
For reference, PyPy doesn't have old-style classes at all so far, so we had to
come up with something about exceptions. After some feedback from python-dev
it appears that the following scheme works reasonably well. Actually it's
surprizing how little problems we actually encountered by removing the
old-/new-style distinction (particularly when compared with the extremely
obscure workarounds we had to go through in PyPy itself, e.g. precisely
because we wanted exceptions that are member of some (new-style) class
hierarchy).
Because a bit of Python code tells more than long and verbose explanations,
here it is:
def app_normalize_exception(etype, value, tb):
"""Normalize an (exc_type, exc_value) pair:
exc_value will be an exception instance and exc_type its class.
"""
# mistakes here usually show up as infinite recursion, which is fun.
while isinstance(etype, tuple):
etype = etype[0]
if isinstance(etype, type):
if not isinstance(value, etype):
if value is None:
# raise Type: we assume we have to instantiate Type
value = etype()
elif isinstance(value, tuple):
# raise Type, Tuple: assume Tuple contains the constructor
#args
value = etype(*value)
else:
# raise Type, X: assume X is the constructor argument
value = etype(value)
# raise Type, Instance: let etype be the exact type of value
etype = value.__class__
elif type(etype) is str:
# XXX warn -- deprecated
if value is not None and type(value) is not str:
raise TypeError("string exceptions can only have a string value")
else:
# raise X: we assume that X is an already-built instance
if value is not None:
raise TypeError("instance exception may not have a separate"
" value")
value = etype
etype = value.__class__
# for the sake of language consistency we should not allow
# things like 'raise 1', but it's probably fine (i.e.
# not ambiguous) to allow them in the explicit form 'raise int, 1'
if not hasattr(value, '__dict__') and not hasattr(value, '__slots__'):
raise TypeError("raising built-in objects can be ambiguous, "
"use 'raise type, value' instead")
return etype, value, tb
Armin
___
Python-Dev mailing list
Python-Dev@python.org
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
Guido van Rossum wrote:
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("...")
Assuming the type error displayed contains information on T, the caller can then
trivially correct the type error by invoking adapt(arg, T) at the call point
(assuming the argument actually *is* adaptable to the desired protocol). The
code inside the function still gets to assume the supplied object has the
correct type - the only difference is that if adaptation is actually needed, the
onus is on the caller to provide it explicitly (and they will get a specific
error telling them so).
This strikes me as quite an elegant solution.
Regards,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://boredomandlaziness.skystorm.net
___
Python-Dev mailing list
Python-Dev@python.org
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
Nick Coghlan wrote: Guido van Rossum wrote: What do people think? (My main motivation for this, as stated before, is that it adds complexity without much benefit.) I'm in favour, since it removes the "an unbound method is almost like a bare function, only not quite as useful" distinction. It would allow things like str.join(sep, seq) to work correctly for a Unicode separator. This won't work. Strings and Unicode are two different types, not subclasses of one another. It also allows 'borrowing' of method implementations without inheritance. > I'm a little concerned about the modification to pyclbr_input.py, though (since it presumably worked before the patch). Was the input file tweaked before or after the test itself was fixed? (I'll probably get around to trying out the patch myself, but that will be on Linux as well, so I doubt my results will differ from yours). The other question is the pickling example - an unbound method currently stores meaningful data in im_class, whereas a standard function doesn't have that association. Any code which makes use of im_class on unbound methods (even without involving pickling)is going to have trouble with the change. (Someone else will need to provide a real-life use case though, since I certainly don't have one). I don't think there's much to worry about. At the C level, bound and unbound methods are the same type. The only difference is that bound methods have the object attribute im_self set to an instance object, while unbound methods have it set NULL. Given that the two are already the same type, I don't really see much benefit from dropping the printing of "unbound" in case im_self is NULL... perhaps I'm missing something. As for real life examples: basemethod() in mxTools uses .im_class to figure the right base method to use (contrary to super(), basemethod() also works for old-style classes). basemethod() in return if used in quite a few applications to deal with overriding methods in mixin classes. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 10 2005) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ Python-Dev mailing list Python-Dev@python.org 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?
On Sunday 16 January 2005 20:38, 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...? > 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, ...? Beats me - worst comes to worst, I guess we ship the unittest code there with a try/except around the ImportError on the new 'copytest' module, and the test skips if it's not built. Then we don't build it by default, but if someone wants to build it and check it, they can. I don't like this much, but I can't think of a better alternative. Shipping a new extension module just for this unittest seems like a bad idea. Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Deprecating old bugs
Title: Deprecating old bugs As I discussed in this list, in the "Policy about old Python versions" thread at 8-Nov-2004, I started verifying the old bugs. Here are the results for 2.1.*. This maybe should be put in an informational PEP. When I verified the bug, I filled two fields: - Group: the bug's group at verifying time. - Bug #: the bug number - Verified: is the date when I checked the bug. - Action: is what I did then. If the bug survived the verification, the next two fields are applicable (if not, I put a dash, the idea is to keep this info easily parseable): - Final: is the action took by someone who eliminated the bug from that category (closed, moved to Py2.4, etc). - By: is the someone who did the final action. Group: 2.1.1 Bug #: 1020605 Verified: 08-Nov-2004 Action: Closed: Invalid. Was a Mailman issue, not a Python one. Final: - By: - Group: 2.1.2 Bug #: 771429 Verified: 08-Nov-2004 Action: Deprecation alerted. I can not try it, don't have that context. Final: Closed: Won't fix. By: facundobatista Group: 2.1.2 Bug #: 629345 Verified: 08-Nov-2004 Action: Deprecation alerted. Can't discern if it's really a bug or not. Final: Closed: Won't fix. By: facundobatista Group: 2.1.2 Bug #: 589149 Verified: 08-Nov-2004 Action: Closed: Fixed. The problem is solved from Python 2.3a1, as the submitter posted. Final: - By: - I included here only 2.1.* because there were only four, so it's a good trial. If you think I should change the format or add more information, please let me know ASAP. The next chapter of this story will cover 2.2 bugs. Regards, . Facundo Bitácora De Vuelo: http://www.taniquetil.com.ar/plog PyAr - Python Argentina: http://pyar.decode.com.ar/ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ADVERTENCIA. La información contenida en este mensaje y cualquier archivo anexo al mismo, son para uso exclusivo del destinatario y pueden contener información confidencial o propietaria, cuya divulgación es sancionada por la ley. Si Ud. No es uno de los destinatarios consignados o la persona responsable de hacer llegar este mensaje a los destinatarios consignados, no está autorizado a divulgar, copiar, distribuir o retener información (o parte de ella) contenida en este mensaje. Por favor notifíquenos respondiendo al remitente, borre el mensaje original y borre las copias (impresas o grabadas en cualquier medio magnético) que pueda haber realizado del mismo. Todas las opiniones contenidas en este mail son propias del autor del mensaje y no necesariamente coinciden con las de Telefónica Comunicaciones Personales S.A. o alguna empresa asociada. Los mensajes electrónicos pueden ser alterados, motivo por el cual Telefónica Comunicaciones Personales S.A. no aceptará ninguna obligación cualquiera sea el resultante de este mensaje. Muchas Gracias. ___ Python-Dev mailing list Python-Dev@python.org 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 17, at 14:45, Anthony Baxter wrote: ... 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, ...? Beats me - worst comes to worst, I guess we ship the unittest code there with a try/except around the ImportError on the new 'copytest' module, and the test skips if it's not built. Then we don't build it by default, but if someone wants to build it and check it, they can. I don't like this much, but I can't think of a better alternative. Shipping a new extension module just for this unittest seems like a bad idea. Agreed about this issue not warranting the shipping of a new extension module -- however, in the patch (to the 2.3 maintenance branch) which I uploaded (and assigned to you), I followed the effbot's suggestion, and added the type needed for testing to the already existing "extension module for testing purposes", namely Modules/_testcapi.c -- I don't think it can do any harm there, and lets test/test_copy.py do all of its testing blissfully well. I haven't even made the compilation of the part of Modules/_testcapi.c which hold the new type conditional upon anything, because I don't think that having it there unconditionally can possibly break anything anyway... _testcapi IS only used for testing, after all...! Alex ___ Python-Dev mailing list Python-Dev@python.org 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 <[EMAIL PROTECTED]> writes: > 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. A few months back I hacked an attempt to make all exceptions new-style. It's not especially hard, but it's tedious. There's lots of code (more than I expected, anyway) to change and my attempt ended up being pretty messy. I suspect allowing both old- and new-style classes would be no harder, but even more tedious and messy. It would still be worth doing, IMHO. Cheers, mwh -- If you are anal, and you love to be right all the time, C++ gives you a multitude of mostly untimportant details to fret about so you can feel good about yourself for getting them "right", while missing the big picture entirely -- from Twisted.Quotes ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] 2.3.5 delayed til next week
As I'd kinda feared, my return to work has left me completely buried this week, and so I'm going to have to push 2.3.5 until next week. Thomas and Fred: does one of the days in the range 25-27 January suit you? The 26th is a public holiday here, and so that's the day that's most likely for me... Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list Python-Dev@python.org 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?
[Armin]
> For reference, PyPy doesn't have old-style classes at all so far, so we had to
> come up with something about exceptions. After some feedback from python-dev
> it appears that the following scheme works reasonably well. Actually it's
> surprizing how little problems we actually encountered by removing the
> old-/new-style distinction (particularly when compared with the extremely
> obscure workarounds we had to go through in PyPy itself, e.g. precisely
> because we wanted exceptions that are member of some (new-style) class
> hierarchy).
>
> Because a bit of Python code tells more than long and verbose explanations,
> here it is:
>
> def app_normalize_exception(etype, value, tb):
[...]
> elif type(etype) is str:
> # XXX warn -- deprecated
> if value is not None and type(value) is not str:
> raise TypeError("string exceptions can only have a string value")
That is stricter than classic Python though -- it allows the value to
be anything (and you get the value back unadorned in the except 's',
x: clause).
[Michael]
> It would still be worth doing, IMHO.
Then let's do it. Care to resurrect your patch? (And yes, classic
classes should also be allowed for b/w compatibility.)
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
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
At 10:12 PM 1/16/05 -0800, Guido van Rossum wrote: 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.) Will it still be possible to create an unbound method with new.instancemethod? (I know the patch doesn't change this, I mean, is it planned to remove the facility from the instancemethod type?) ___ Python-Dev mailing list Python-Dev@python.org 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
[Guido] > > def test_im_class(): > > class C: > > def foo(self): pass > > - verify(C.foo.im_class is C) [Glyph] > ^ 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. Note that you can't pickle unbound methods anyway unless you write specific suppport code to do that; it's not supported by pickle itself. I think that use case is weak. If you really have the need to pickle an individual unbound method, it's less work to create a global helper function and pickle that, than to write the additional pickling support for picking unbound methods. > In general I like the patch, but what is the rationale for removing > im_class from functions defined within classes? The information isn't easily available to the function. I could go around and change the parser to make this info available, but that would require changes in many places currently untouched by the patch. [Nick] > I'm a little concerned about the modification to pyclbr_input.py, though > (since > it presumably worked before the patch). Was the input file tweaked before or > after the test itself was fixed? (I'll probably get around to trying out the > patch myself, but that will be on Linux as well, so I doubt my results will > differ from yours). It is just a work-around for stupidity in the test code, which tries to filter out cases like "om = Other.om" because the pyclbr code doesn't consider these. pyclbr.py hasn't changed, and still doesn't consider these (since it parses the source code); but the clever test in the test code no longer works. > The other question is the pickling example - an unbound method currently > stores > meaningful data in im_class, whereas a standard function doesn't have that > association. Any code which makes use of im_class on unbound methods (even > without involving pickling)is going to have trouble with the change. (Someone > else will need to provide a real-life use case though, since I certainly don't > have one). Apart from the tests that were testing the behavior of im_class, I found only a single piece of code in the standard library that used im_class of an unbound method object (the clever test in the pyclbr test). Uses of im_self and im_func were more widespread. Given the level of cleverness in the pyclbr test (and the fact that I wrote it myself) I'm not worried about widespread use of im_class on unbound methods. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org 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 01:49 AM 1/17/05 -0500, Glyph Lefkowitz wrote: 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. Heh. As long as you're going to continue the electrical metaphor, why not just call them transformers and appliances? Appliances "convert" electricity into useful non-electricity things, and it's obvious that you can have more than one, they're independent objects, etc. Whereas a transformer or converter would be something you use in order to be able to change the electricity itself. Calling views and iterators "appliances" might be a little weird at first, but it fits. (At one point, I thought about calling them "accessories".) 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. It's that independent adapters each have state independent from other independent adapters of the same type for the same object. (vs. extenders having shared state amongst themselves, even if you have more than one) ___ Python-Dev mailing list Python-Dev@python.org 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
> Will it still be possible to create an unbound method with > new.instancemethod? (I know the patch doesn't change this, I mean, is it > planned to remove the facility from the instancemethod type?) I was hoping to be able to get rid of this as soon as the built-in exceptions code no longer depends on it. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Re: 2.3.5 delayed til next week
Anthony Baxter <[EMAIL PROTECTED]> writes: > As I'd kinda feared, my return to work has left me completely > buried this week, and so I'm going to have to push 2.3.5 until > next week. Thomas and Fred: does one of the days in the > range 25-27 January suit you? The 26th is a public holiday here, > and so that's the day that's most likely for me... > 25-27 January are all ok for me. Will there be a lot of backports, or are they already in place? If they are already there, I can build the installer as soon as Fred has built the html docs. Thomas ___ Python-Dev mailing list Python-Dev@python.org 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?
Hi Guido, On Mon, Jan 17, 2005 at 07:27:33AM -0800, Guido van Rossum wrote: > That is stricter than classic Python though -- it allows the value to > be anything (and you get the value back unadorned in the except 's', > x: clause). Thanks for the note ! Armin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] a bunch of Patch reviews
If someone could take a look at:
[ 1069624 ] incomplete support for AF_PACKET in socketmodule.c
I have to ship my own patched copy of the socket module because of
this... :|
On Sun, 2005-01-16 at 17:08 +0100, Irmen de Jong wrote:
> 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
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/gjc%40inescporto.pt
--
Gustavo J. A. M. Carneiro
<[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
The universe is always one step beyond logic.
smime.p7s
Description: S/MIME cryptographic signature
___
Python-Dev mailing list
Python-Dev@python.org
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
Phillip J. Eby wrote: > Heh. As long as you're going to continue the electrical metaphor, > why not just call them transformers and appliances? [ ... ] Next we'll see Appliance-Oriented Programming ;-) Just ___ Python-Dev mailing list Python-Dev@python.org 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 <[EMAIL PROTECTED]> writes: > [Michael] >> It would still be worth doing, IMHO. > > Then let's do it. Care to resurrect your patch? (And yes, classic > classes should also be allowed for b/w compatibility.) I found it and uploaded it here: http://starship.python.net/crew/mwh/new-style-exception-hacking.diff The change to type_str was the sort of unexpected change I was talking about. TBH, I'm not sure it's really worth working from my patch, a more sensible course would be to just do the work again, but paying a bit more attention to getting a maintainable result. Questions: a) Is Exception to be new-style? b) Somewhat but not entirely independently, would demanding that all new-style exceptions inherit from Exception be reasonable? Cheers, mwh -- ZAPHOD: You know what I'm thinking? FORD: No. ZAPHOD: Neither do I. Frightening isn't it? -- The Hitch-Hikers Guide to the Galaxy, Episode 11 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Re: 2.3.5 delayed til next week
On Monday 17 January 2005 08:41, Anthony Baxter wrote: > As I'd kinda feared, my return to work has left me completely > buried this week, and so I'm going to have to push 2.3.5 until > next week. Thomas and Fred: does one of the days in the > range 25-27 January suit you? The 26th is a public holiday here, > and so that's the day that's most likely for me... Sounds good to me. Anything in that range is equally doable. -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list Python-Dev@python.org 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 04:06 PM 1/17/05 +, Michael Hudson wrote: a) Is Exception to be new-style? Probably not in 2.5; Martin and others have suggested that this could introduce instability for users' existing exception classes. b) Somewhat but not entirely independently, would demanding that all new-style exceptions inherit from Exception be reasonable? Yes. Right now you can't have a new-style exception at all, so it would be quite reasonable to require new ones to inherit from Exception. ___ Python-Dev mailing list Python-Dev@python.org 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 Mon, 17 Jan 2005 11:35:53 -0500, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > At 04:06 PM 1/17/05 +, Michael Hudson wrote: > >a) Is Exception to be new-style? > > Probably not in 2.5; Martin and others have suggested that this could > introduce instability for users' existing exception classes. Really? I thought that was eventually decided to be a very small amount of code. > >b) Somewhat but not entirely independently, would demanding that all > >new-style exceptions inherit from Exception be reasonable? > > Yes. Right now you can't have a new-style exception at all, so it would be > quite reasonable to require new ones to inherit from Exception. That would be much more reasonable if Exception itself was a new-style class. As long as it isn't, you'd have to declare new-style classes like this: class MyError(Exception, object): ... which is ugly. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org 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
> Heh. As long as you're going to continue the electrical metaphor, why not > just call them transformers and appliances? Please don't. Transformer is commonly used in all sorts of contexts. But appliances applies mostly to kitchenware and the occasional marketing term for cheap computers. The electrical metaphor is cute, but doesn't cut it IMO. Adapter, converter and transformer all sound to me like they imply an "as a" relationship rather than "has a". The "has a" kind feels more like a power tool to me. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org 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: 2.3.5 delayed til next week
Thomas Heller <[EMAIL PROTECTED]> writes: > 25-27 January are all ok for me. Will there be a lot of backports, or > are they already in place? If they are already there, I can build the > installer as soon as Fred has built the html docs. I've got a couple, I'll get them in by tomorrow. -- KBK ___ Python-Dev mailing list Python-Dev@python.org 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:16 AM 1/17/05 -0800, Guido van Rossum wrote: On Mon, 17 Jan 2005 11:35:53 -0500, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > At 04:06 PM 1/17/05 +, Michael Hudson wrote: > >a) Is Exception to be new-style? > > Probably not in 2.5; Martin and others have suggested that this could > introduce instability for users' existing exception classes. Really? I thought that was eventually decided to be a very small amount of code. Guess I missed that part of the thread in the ongoing flood of PEP 246 stuff. :) That would be much more reasonable if Exception itself was a new-style class. As long as it isn't, you'd have to declare new-style classes like this: class MyError(Exception, object): ... which is ugly. I was thinking the use case was that you were having to add 'Exception', not that you were adding 'object'. The two times in the past that I wanted to make a new-style class an exception, I *first* made it a new-style class, and *then* tried to make it an exception. I believe the OP on this thread described the same thing. But whatever; as long as it's *possible*, I don't care much how it's done, and I can't think of anything in my code that would break from making Exception new-style. ___ Python-Dev mailing list Python-Dev@python.org 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 10:21 AM 1/17/05 -0800, Guido van Rossum wrote: > Heh. As long as you're going to continue the electrical metaphor, why not > just call them transformers and appliances? Please don't. Transformer is commonly used in all sorts of contexts. But appliances applies mostly to kitchenware and the occasional marketing term for cheap computers. The electrical metaphor is cute, but doesn't cut it IMO. Adapter, converter and transformer all sound to me like they imply an "as a" relationship rather than "has a". The "has a" kind feels more like a power tool to me. By the way, another use case for type declarations supporting dynamic "as-a" adapters... Chandler's data model has a notion of "kinds" that a single object can be, like Email, Appointment, etc. A single object can be of multiple kinds, sort of like per-instance multiple-inheritance. Which means that passing the same object to routines taking different types would "do the right thing" with such an object if they adapted to the desired kind, and if such adaptation removed the existing kind-adapter and replaced it with the destination kind-adapter. So, there's an underlying object that just represents the identity, and then everything else is "as-a" adaptation. ___ Python-Dev mailing list Python-Dev@python.org 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?
> >That would be much more reasonable if Exception itself was a new-style > >class. As long as it isn't, you'd have to declare new-style classes > >like this: > > > >class MyError(Exception, object): > > ... > > > >which is ugly. > > I was thinking the use case was that you were having to add 'Exception', > not that you were adding 'object'. The two times in the past that I wanted > to make a new-style class an exception, I *first* made it a new-style > class, and *then* tried to make it an exception. I believe the OP on this > thread described the same thing. > > But whatever; as long as it's *possible*, I don't care much how it's done, > and I can't think of anything in my code that would break from making > Exception new-style. Well, right now you would only want to make an exception a new style class if you had a very specific use case for wanting the new style class. But once we allow new-style exceptions *and* require them to inherit from Exception, we pretty much send the message "if you're not using new-style exceptions derived from Exception your code is out of date" and that means it should be as simple as possible to make code conform. And that means IMO making Exception a new style class. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] a bunch of Patch reviews
Gustavo J. A. M. Carneiro wrote: If someone could take a look at: [ 1069624 ] incomplete support for AF_PACKET in socketmodule.c The rule applies: five reviews, with results posted to python-dev, and I will review your patch. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org 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: a) Is Exception to be new-style? Probably not in 2.5; Martin and others have suggested that this could introduce instability for users' existing exception classes. Really? I thought that was eventually decided to be a very small amount of code. I still think that only an experiment could decide: somebody should come up with a patch that does that, and we will see what breaks. I still have the *feeling* that this has significant impact, but I could not pin-point this to any specific problem I anticipate. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] a bunch of Patch reviews
On Mon, 2005-01-17 at 23:12 +0100, "Martin v. Löwis" wrote: > Gustavo J. A. M. Carneiro wrote: > > If someone could take a look at: > > > > [ 1069624 ] incomplete support for AF_PACKET in socketmodule.c > > > The rule applies: five reviews, with results posted to python-dev, > and I will review your patch. Oh... sorry, I didn't know about any rules. /me hides in shame. -- Gustavo J. A. M. Carneiro <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> The universe is always one step beyond logic ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] a bunch of Patch reviews
Gustavo J. A. M. Carneiro wrote: Oh... sorry, I didn't know about any rules. My apologies - I had announced this (personal) rule a few times, so I thought everybody on python-dev knew. If you really want to push a patch, you can do so by doing your own share of work, namely by reviewing other's patches. If you don't, someone will apply your patch when he finds the time to do so. So if you can wait, it might be best to wait a few months (this won't go into 2.4 patch releases, anyway). I think Brett Cannon now also follows this rule; it really falls short enough in practice because (almost) nobody really wants to push his patch bad enough to put some work into it to review other patches. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org 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
Guido van Rossum wrote: Apart from the tests that were testing the behavior of im_class, I found only a single piece of code in the standard library that used im_class of an unbound method object (the clever test in the pyclbr test). Uses of im_self and im_func were more widespread. Given the level of cleverness in the pyclbr test (and the fact that I wrote it myself) I'm not worried about widespread use of im_class on unbound methods. I guess this depends on how you define widespread use. I'm using this feature a lot via the basemethod() function in mxTools for calling the base method of an overridden method in mixin classes (basemethod() predates super() and unlike the latter works for old-style classes). What I don't understand in your reasoning is that you are talking about making an unbound method look more like a function. Unbound methods and bound methods are objects of the same type - the method object. By turning an unbound method into a function type, you break code that tests for MethodType in Python or does a PyMethod_Check() at C level. If you want to make methods look more like functions, the method object should become a subclass of the function object (function + added im_* attributes). -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 10 2005) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ Python-Dev mailing list Python-Dev@python.org 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 Mon, 2005-01-17 at 07:43 -0800, Guido van Rossum wrote: > Note that you can't pickle unbound methods anyway unless you write > specific suppport code to do that; it's not supported by pickle > itself. It's supported by Twisted. Alternatively, replace "pickle" with "python object serializer of my design" - I am concerned both about useful information being removed, and about specific features of Pickle. Twisted's .tap files have always pushed the limits of pickle. I don't remember why my users wanted this specific feature - the code in question is almost 3 years old - but when you think of a pickle as a self-contained universe of running Python objects, any plausible reason why one might want a reference to an unbound method in code becomes a reason to want to serialize one. The only time I've used it myself was to pickle attributes of interfaces, which I no longer need to do since zope.interface has its own object types for that, so it's not really _that_ important to me. On the other hand, if PJE's "monkey typing" PEP is accepted, there will probably be lots more reasons to serialize unbound methods, for descriptive purposes. > I think that use case is weak. It's not the strongest use-case in the world, but is the impetus to remove unbound method objects from Python that much stronger? I like the fact that it's simpler, but it's a small amount of extra simplicity, it doesn't seem to enable any new use-cases, and it breaks the potential for serialization. In general, Pickle handles other esoteric, uncommon use-cases pretty well: >>> x = [] >>> y = (x,) >>> x.append(y) >>> import cPickle >>> cPickle.dumps(x) '(lp1\n(g1\ntp2\na.' >>> x [([...],)] since when you need 'em, you really need 'em. Method objects were previously unsupported, which is fine because they're pretty uncommon. Not only would this patch continue to not support them, though, it makes the problem impossible to fix in 3rd-party code. By removing the unbound method type, it becomes an issue that has to be fixed in the standard library. Assuming that 3rd party code will not be able to change the way that functions are pickled and unpickled in cPickle, in python2.5. Ironically, I think that this use case is also going to become more common if the patch goes in, because then it is going to be possible to "borrow" functionality without going around a method's back to grab its im_func. > If you really have the need to pickle an individual unbound method, > it's less work to create a global helper function and pickle that, > than to write the additional pickling support for picking unbound > methods. This isn't true if you've already got the code written, which I do ;-). ___ Python-Dev mailing list Python-Dev@python.org 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 Mon, 2005-01-17 at 23:58 +0100, M.-A. Lemburg wrote: > If you want to make methods look more like functions, > the method object should become a subclass of the function > object (function + added im_* attributes). I think this suggestion would fix my serialization problem as well... but does it actually buy enough extra simplicity to make it worthwhile? ___ Python-Dev mailing list Python-Dev@python.org 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 Mon, 2005-01-17 at 17:58, M.-A. Lemburg wrote: > If you want to make methods look more like functions, > the method object should become a subclass of the function > object (function + added im_* attributes). I have no personal use cases, but it does make me vaguely uncomfortable to lose im_class. Isn't it possible to preserve this attribute? -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list Python-Dev@python.org 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 Jan 17, 2005, at 18:33, Glyph Lefkowitz wrote: It's not the strongest use-case in the world, but is the impetus to remove unbound method objects from Python that much stronger? I like the fact that it's simpler, but it's a small amount of extra simplicity, it doesn't seem to enable any new use-cases, and it breaks the potential for serialization. Well, it lets you meaningfully do: class Foo: def someMethod(self): pass class Bar: someMethod = Foo.someMethod Where now you have to do: class Bar: someMethod = Foo.someMethod.im_func I'm not sure how useful this actually is, though. -bob ___ Python-Dev mailing list Python-Dev@python.org 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
[Guido] > > Apart from the tests that were testing the behavior of im_class, I > > found only a single piece of code in the standard library that used > > im_class of an unbound method object (the clever test in the pyclbr > > test). Uses of im_self and im_func were more widespread. Given the > > level of cleverness in the pyclbr test (and the fact that I wrote it > > myself) I'm not worried about widespread use of im_class on unbound > > methods. [Marc-Andre] > I guess this depends on how you define widespread use. I'm using > this feature a lot via the basemethod() function in mxTools for > calling the base method of an overridden method in mixin classes > (basemethod() predates super() and unlike the latter works for > old-style classes). I'm not sure I understand how basemethod is supposed to work; I can't find docs for it using Google (only three hits for the query mxTools basemethod). How does it depend on im_class? > What I don't understand in your reasoning is that you are talking > about making an unbound method look more like a function. That's a strange interpretation. I'm getting rid of the unbound method object altogether. > Unbound > methods and bound methods are objects of the same type - > the method object. Yeah I know that. :-) And it is one of the problems -- the two uses are quite distinct and yet it's the same object, which is confusing. > By turning an unbound method into a function > type, you break code that tests for MethodType in Python > or does a PyMethod_Check() at C level. My expectation is that there is very little code like that. Almost all the code that I found doing that in the core Python code (none in C BTW) was in the test suite. > If you want to make methods look more like functions, > the method object should become a subclass of the function > object (function + added im_* attributes). Can't do that, since the (un)bound method object supports binding other callables besides functions. [Glyph] > On the other hand, if PJE's "monkey typing" PEP is accepted, there will > probably be lots more reasons to serialize unbound methods, for > descriptive purposes. Let's cross that bridge when we get to it. > It's not the strongest use-case in the world, but is the impetus to > remove unbound method objects from Python that much stronger? Perhaps not, but we have to strive for simplicity whenever we can, to counteract the inevitable growth in complexity of the language elsewhere. > I like > the fact that it's simpler, but it's a small amount of extra simplicity, > it doesn't seem to enable any new use-cases, I think it does. You will be able to get a method out of a class and put it into another unrelated class. Previously, you would have to use __dict__ or im_func to do that. Also, I've always liked the explanation of method calls that C().f() is the same as C.f(C()) and to illustrate this it would be nice to say "look, C.f is just a function". > and it breaks the potential for serialization. For which you seem to have no use yourself. The fact that you support it doesn't prove that it's used -- large software packages tend to accrete lots of unused features over time, because it's safer to keep it in than to remove it. This is a trend I'd like to buck with Python. There's lots of dead code in Python's own standard library, and one day it will bite the dust. [Barry] > I have no personal use cases, but it does make me vaguely uncomfortable > to lose im_class. Isn't it possible to preserve this attribute? That vague uncomfort is called FUD until proven otherwise. :-) Keeping im_class would be tricky -- the information isn't easily available when the function is defined, and adding it would require changing unrelated code that the patch so far didn't have to get near. Also, it would not be compatible -- the unbound method sets im_class to whichever class was used to retrieve the attribute, not the class in which the function was defined. -- --Guido van Rossum (home page: http://www.python.org/~guido/)> ___ Python-Dev mailing list Python-Dev@python.org 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?
> I still think that only an experiment could decide: somebody should > come up with a patch that does that, and we will see what breaks. > > I still have the *feeling* that this has significant impact, but > I could not pin-point this to any specific problem I anticipate. This sounds like a good approach. We should do this now in 2.5, and as alpha and beta testing progresses we can decide whether to roll it back of what kind of backwards compatibility to provide. (Most exceptions are very short classes with very limited behavior, so I expect that in the large majority of cases it won't matter. The question is of course how small the remaining minority is.) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org 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
Guido van Rossum wrote: > Keeping im_class would be tricky -- the information isn't easily > available when the function is defined, and adding it would require > changing unrelated code that the patch so far didn't have to get near. > Also, it would not be compatible -- the unbound method sets im_class > to whichever class was used to retrieve the attribute, not the class > in which the function was defined. I actually do have a use case for im_class, but not in its current incarnation. It would be useful if im_class was set (permanently) to the class in which the function was defined. My use case is my autosuper recipe. Currently I have to trawl through the MRO, comparing code objects to find out which class I'm currently in. Most annoyingly, I have to trawl *beyond* where I first find the function, in case it's actually come from a base class (otherwise infinite recursion can result ;) If im_func were set to the class where the function was defined, I could definitely avoid the second part of the trawling (not sure about the first yet, since I need to get at the function object). Cheers. Tim Delaney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
