Re: [Python-Dev] confusing exec error message in 3.0
Guido van Rossum wrote:
> On Wed, Aug 27, 2008 at 6:21 PM, Steven D'Aprano <[EMAIL PROTECTED]> wrote:
>> On Thu, 28 Aug 2008 08:39:01 am Georg Brandl wrote:
>>> Fredrik Lundh schrieb:
(using 3.0a4)
>>> exec(open("file.py"))
Traceback (most recent call last):
File "", line 1, in
TypeError: exec() arg 1 must be a string, file, or code object, not
TextIOWrapper
so what's "file" referring to here?
(the above works under 2.5, of course)
>>> See http://bugs.python.org/issue1762972 -- it has been decided to
>>> drop that possibility.
>> Hmmm... I have a concern with one of the patches in that issue; I refer
>> to patch that changes the semantics of module's __file__ attribute.
>>
>> Guido noted that exec(open(M.__file__).read(), M.__dict__) almost worked
>> as a replacement for reload(), except that there were issues with file
>> extensions (.py, .pyc, .pyo and even things like .pyc24). So it was
>> decided that M.__file__ should always point to the source file.
>>
>> But now that reload() is now moved into the imp module, I don't see that
>> the justification for changing the semantics of M.__file__ still
>> exists. imp.reload(M) is much better for interactive use than
>> exec(open(M.__file__).read(), M.__dict__).
>>
>> Is there still a justification for having M.__file__ point to the source
>> even if the module was actually loaded from the .pyc version? If so,
>> what is that?
>>
>> Some years ago, as a newbie, I was having trouble with reload()
>> repeatedly not picking up changes I was making to a module. The problem
>> turned out to be user-error, but how I discovered that was by looking
>> at M.__file__ and noticing that Python was loading the .pyc file
>> instead of the .py file I was expecting. Had M.__file__ given
>> misleading information, I would have been mislead for much longer.
>> Here's a small contrived example under Python 2.5:
>>
> import parrot
> parrot.__file__
>> 'parrot.py'
> # pretend that I made changes to the source
>> ... # in my editor, but forgot to save them
>> ... reload(parrot)
>>
> parrot.__file__
>> 'parrot.pyc'
>>
>>
>> I don't think M.__file__ should lie and say it was loaded from a file
>> that it wasn't loaded from. It's useful to be able to look at a module
>> and see what file it was actually loaded from.
>
> While appreciate the use case, there are way more use cases where
> there's code that must painstakingly strip the trailing 'c' or 'o'
> from __file__ in order to read the source code. Perhaps we should have
> a separate API for finding out whether a module was loaded from source
> or from a .pyc file; but I think it would be better to have such an
> API somewhere in the imp module. It's also possible to follow what
> goes on by watching the verbose -v output.
>
Painstakingly? Surely the pain level isn't that high, and I agree with
Michael that the __file__ information would be better as the literal truth.
regards
Steve
--
Steve Holden+1 571 484 6266 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/
___
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] Stable / unstable buildbots
Hello everyone, What is the rationale behind the distinction between "stable" and "unstable" buildbots? I ask that because the OpenBSD buildbot has failed compiling 3.0 for quite some time, but since that buildbot was in the "unstable" bunch, it was not discovered until someone filed a bug report for it (see http://bugs.python.org/issue3696). Regards Antoine. ___ 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] Stable / unstable buildbots
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Aug 28, 2008, at 6:28 AM, Antoine Pitrou wrote: What is the rationale behind the distinction between "stable" and "unstable" buildbots? I ask that because the OpenBSD buildbot has failed compiling 3.0 for quite some time, but since that buildbot was in the "unstable" bunch, it was not discovered until someone filed a bug report for it (see http://bugs.python.org/issue3696) . Mostly, it was a determination that Neal and I made at Pycon, about which bots we should "trust" to judge the health of the trees. I don't think the current list needs to be set in stone, and in fact several of the "stable" bots have had simple svn or other non-tree related problems for a while. As for the "unstable" ones, I personally rarely check them. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSLaXKXEjvBPtnXfVAQJfqgQAiyoqqUNQWByKEalKmWpRyqlX56PJIzPB S5gqubUZOvUTjVvHgvUtePPmJwEntyE+WcWXrX2tRlmMiCwantjgYOuNJeqonuwE BVZRrIjU/mayM9gRiN9NhuGHfV/YiLKpte+DKzuYZwGW2TnaCM3ijWe2QuMxmgqZ MMAO1w+M1kE= =qIFo -END PGP 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] Stable / unstable buildbots
2008/8/28 Barry Warsaw <[EMAIL PROTECTED]>: > bots we should "trust" to judge the health of the trees. I don't think the > current list needs to be set in stone, and in fact several of the "stable" > bots have had simple svn or other non-tree related problems for a while. Maybe a good requisite to move a buildbot from unstable to stable is to find a champion for it. I mean, something that can test on that platform and cares enough about it to, or fix the issue himself/herself, or find who broke it and bother the responsible until it gets fixed. Regards, -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ 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] Stable / unstable buildbots
Facundo Batista gmail.com> writes: > > Maybe a good requisite to move a buildbot from unstable to stable is > to find a champion for it. I mean, something that can test on that > platform and cares enough about it to, or fix the issue > himself/herself, or find who broke it and bother the responsible until > it gets fixed. By that metric, I fear that the only remaining buildbots would be the Linux/Windows x86/x64 ones. I'm not sure anyone here, for example, cares really much about Sparc buildbots, apart from the fact that having red "stable" buildbots doesn't make Python look very good, and we try to avoid that. But then Python wouldn't be really cross-platform anymore, or just in a very theoretical way. Also, lacking stable buildbots means some chunks of the language or stdlib aren't even tested anymore. For example, the bigmem/bigaddrspace tests are completely broken in the py3k branch. Regards Antoine. ___ 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] Stable / unstable buildbots
2008/8/28 Antoine Pitrou <[EMAIL PROTECTED]>: > By that metric, I fear that the only remaining buildbots would be the > Linux/Windows x86/x64 ones. I'm not sure anyone here, for example, cares > really Note that I meant to "move from unstable to stable, starting from the actual state", not to "decide again which ones will be stables or not". I agree with you in all the other matters. -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ 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] Things to Know About Super
At 06:35 AM 8/28/2008 +0200, Michele Simionato wrote: Multiple inheritance of metaclasses is perhaps the strongest use case for multiple inheritance, but is it strong enough? I mean, in real code how many times did I need that? I would not mind make life harder for gurus and simpler for application programmers. Then you need to leave MI and co-operation the hell alone. Right now, an application programmer can mix metaclasses like this: class FooBar(Foo, Bar): class __metaclass__(Foo.__class__, Bar.__class__): pass ... Or, in 3.x: class FooBarClass(Foo.__class__, Bar.__class__): pass class FooBar(Foo, Bar, metaclass=FooBarClass): ... Either way, this is useful in cases where Foo and Bar come from different frameworks. That's the *only* way to get such things to co-operate, in fact. I do not think removing cooperation would be so bad in practice. In many practical cases, one could just write the metaclass by hand, How is that making things easier for application programmers? Maybe you would need to duplicate a couple of lines and/or to introduce an helper function, ...which then has to have an agreed-upon protocol that all metaclass authors have to follow... which we already have... but which you're proposing to get rid of... so we can re-invent it lots of times... in mutually incompatible ways. :) ___ 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] Things to Know About Super
On Aug 28, 5:30 pm, "Phillip J. Eby" <[EMAIL PROTECTED]> wrote: > How is that making things easier for application programmers? We have different definitions of "application programmer". For me a typical application programmer is somebody who never fiddles with metaclasses, which are the realm of framework builders. But the borders are fluid, I agree. > >Maybe you would need to duplicate a couple of lines and/or to introduce > >an helper function, > > ...which then has to have an agreed-upon protocol that all metaclass > authors have to follow... which we already have... but which you're > proposing to get rid of... so we can re-invent it lots of > times... in mutually incompatible ways. :) Notice that I was discussing an hypothetical language. I was arguing that in principle one could write a different language from Python, with single inheritance only, and not lose much expressivity. I am not advocating any change to current Python. My point was in language design: I want to know how much I can remove from a language and still have something useful, in the spirit of the famous Saint-Exupery quote. Michele Simionato ___ 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] Things to Know About Super
Greg, Do you have a real-life example of this where multiple inheritance is actually used? I have built a framework that I have called the "capability pattern" which uses multiple inheritance in a way that might be unique (I'm not familiar enough with other frameworks to know for sure). There are two classes, a Collector and a Capability. The result of calling a function of the collector is a list of results of calling the functions of the bound capabilities. For example, these three are capability classes: class X(Capability): def f(self): return 'X.f' class Y(Capability): def g(self): return 'Y.g' class Z(Capability): def f(self): return 'Z.f' def g(self): return 'Z.g' Now to create a sample collector: class A(Collector, X, Y, Z): pass Calling A().f() returns ['X.f', 'Z.f']. I use this pattern in a web application. The do_GET call is mapped into do_SHOW, and each 'capability' can return something from its do_SHOW (usually a element) and the results are sent back to the user. In my case I have lots of combinations of capabilities that can be mixed together. I decided to use multiple inheritance over other patterns because I wanted to leverage isinstance(obj,Y) to indicate that some object has some capability, and not having to duplicate the method resolution order code for other kinds of methods is really nice. A non-contrived example or two would be a good thing to have in tutorials etc. where super() is discussed. It would help to convey the kinds of situations in which use of super() is and is not appropriate. So this is a collection of cooperative classes, and super() isn't used. Joel ___ 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] Things to Know About Super
At 05:50 PM 8/28/2008 +0200, Michele Simionato wrote: On Aug 28, 5:30 pm, "Phillip J. Eby" <[EMAIL PROTECTED]> wrote: > How is that making things easier for application programmers? We have different definitions of "application programmer". For me a typical application programmer is somebody who never fiddles with metaclasses, which are the realm of framework builders. Application programmers use frameworks, and sometimes more than one. If they're subclassing from two different frameworks, each using a different metaclass, they will need to also multiple-inherit the metaclass. This is in fact so annoying that I created a "universal metaclass" in DecoratorTools whose sole function is to delegate metaclass __new__, __init__, and __call__ to class-level methods (e.g. __class_new__, __class_call__, etc.), thereby eliminating the need to have custom metaclasses for most use cases in the first place. Now, wherever possible, I use that single metaclass in my frameworks, so that there's no need to mix them. That, IMO, would be a more useful change than getting rid of super(); it would get rid of the explicit metaclass mixing. (It would still not remove the need for co-operative methods, as the class-delegated methods still need to be co-operative for MI to work.) There are, of course, other ways to create co-operative function calls besides super(), and I've certainly created more a few of them in my time. (E.g. generic function method combination, instancemethod() chains, and next-method-iterators, to name the ones that occur to me right off.) But these are more for cases where super() is wholly inadequate to the purpose, and none are anywhere near as convenient as super(). ___ 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] Documentation Error for __hash__
Hello all, The documentation for __hash__ seems to be outdated. I'm happy to submit a patch, so long as I am not misunderstanding something. http://docs.python.org/dev/reference/datamodel.html#object.__hash__ The documentation states: If a class does not define a __cmp__() or __eq__() method it should not define a __hash__() operation either; if it defines __cmp__() or __eq__() but not __hash__(), its instances will not be usable as dictionary keys. If a class defines mutable objects and implements a __cmp__() or __eq__() method, it should not implement __hash__(), since the dictionary implementation requires that a key’s hash value is immutable (if the object’s hash value changes, it will be in the wrong hash bucket). This may have been true for old style classes, but as new style classes inherit a default __hash__ from object - mutable objects *will* be usable as dictionary keys (hashed on identity) *unless* they implement a __hash__ method that raises a type error. Shouldn't the advice be that classes that implement comparison methods should always implement __hash__ (wasn't this nearly enforced?), and that mutable objects should raise a TypeError in __hash__. Additionally the following documentation states that __reversed__ is new in Python 2.6 and I think it was actually new in Python 2.4 (it certainly works for Python 2.5 and IronPython 1 which targets 2.4...). http://docs.python.org/dev/reference/datamodel.html#object.__reversed__ Michael Foord -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/ http://www.trypython.org/ http://www.ironpython.info/ http://www.theotherdelia.co.uk/ http://www.resolverhacks.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] Things to Know About Super
Michele Simionato wrote: Notice that I was discussing an hypothetical language. I was arguing that in principle one could write a different language from Python, with single inheritance only, and not lose much expressivity. I am not advocating any change to current Python. Since this is a list for discussing changing current Python, you will have to excuse misunderstanding on that point. I do realize that you began with a concrete offer of improving the documentation of the super you hypothetically would like to be rid of ;-) ___ 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] Documentation Error for __hash__
I'm not sure about the first but as for the __reversed__ we had a discussion yesterday and it was indeed added in 2.4 (oddly, my 2.5 documentation has this correct... ) -- Haikus are easy Most make very little sense Refrigerator ___ 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] Documentation Error for __hash__
Michael Foord wrote: > This may have been true for old style classes, but as new style classes > inherit a default __hash__ from object - mutable objects *will* be > usable as dictionary keys (hashed on identity) *unless* they implement a > __hash__ method that raises a type error. > > Shouldn't the advice be that classes that implement comparison methods > should always implement __hash__ (wasn't this nearly enforced?), and > that mutable objects should raise a TypeError in __hash__. Hmm, I thought I fixed those docs when I did the PyObject_HashNotImplemented patch... (you can set __hash__ = None rather than raising a TypeError explicitly now so that collections.Hashable correctly returns False - the slot machinery in typeobject.c will then take of turning that into PyObject_HashNotImplemented at the C level). However, looking at the relevant checkins, it appears I only updated the C API docs and didn't correct the library or language references. I reopened http://bugs.python.org/issue2235 - there are some other doc fixes I need to do this weekend for RC1, so I can tackle this at the same time. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ 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] Documentation Error for __hash__
Jeff Hall wrote: I'm not sure about the first but as for the __reversed__ we had a discussion yesterday and it was indeed added in 2.4 (oddly, my 2.5 documentation has this correct... ) 2.4 doc: reversed( seq) Return a reverse iterator. seq must be an object which supports the sequence protocol (the __len__() method and the __getitem__() method with integer arguments starting at 0). New in version 2.4. [no mention of __reversed__] 3.3.6 Additional methods for emulation of sequence types [ditto] However, I confirmed that __reversed__ is used by reverse() class C: def __reversed__(self): return 'abc' c=C() print(reversed(c)) >>> abc ___ 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] Documentation Error for __hash__
> This may have been true for old style classes, but as new style classes > inherit a default __hash__ from object - mutable objects *will* be usable as > dictionary keys (hashed on identity) *unless* they implement a __hash__ > method that raises a type error. > I always thought this was a bug in new-style classes (due to the fact that, as you say, they inherit __hash__ from object whether it's wanted or not). However, it seems to be fixed in Python 3.0. So this documentation is only "wrong" for Python 2.x branch. See: Python 2.6b3+ (trunk:66055, Aug 29 2008, 07:50:39) [GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class X(object): ... def __eq__(self, other): ... return True ... >>> x = X() >>> hash(x) -1211564180 versus Python 3.0b3+ (py3k:66055M, Aug 29 2008, 07:52:23) [GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class X(object): ... def __eq__(self, other): ... return True ... >>> x = X() >>> hash(x) Traceback (most recent call last): File "", line 1, in TypeError: unhashable type: 'X' Matt ___ 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] confusing exec error message in 3.0
Steven D'Aprano wrote: I don't think M.__file__ should lie and say it was loaded from a file that it wasn't loaded from. It's useful to be able to look at a module and see what file it was actually loaded from. On the other hand, it could be useful to be able to find the source file for a module, regardless of whether it was loaded from a .py, .pyc or .pyo. Maybe there should be a __source__ attribute for that? Or is os.path.splitext(M.__file__)[0] + ".py" considered good enough for that? -- Greg ___ 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] confusing exec error message in 3.0
On Fri, 29 Aug 2008, Greg Ewing wrote: Steven D'Aprano wrote: I don't think M.__file__ should lie and say it was loaded from a file that it wasn't loaded from. It's useful to be able to look at a module and see what file it was actually loaded from. On the other hand, it could be useful to be able to find the source file for a module, regardless of whether it was loaded from a .py, .pyc or .pyo. Maybe there should be a __source__ attribute for that? Or is os.path.splitext(M.__file__)[0] + ".py" considered good enough for that? I think .__source__ is a much better idea. It's more explicit to start with, and on top of that it can simply be None when there is no source file available, which is much more explicit than "file not found means no source file available". Also, if a feature is ever added to allow telling Python to put the compiled files in a separate tree (like javac -d directory in the Java universe) then it will be even more clear that computing the source location from __file__ is not the way to go. PS, in case it's not clear, I want that feature, in order to keep .pyc files out of my SVN checkouts. I hate having automatically generated files in my workspace. Isaac Morland CSCF Web Guru DC 2554C, x36650WWW Software Specialist ___ 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] confusing exec error message in 3.0
2008/8/28 Steve Holden <[EMAIL PROTECTED]>:
> Guido van Rossum wrote:
>> On Wed, Aug 27, 2008 at 6:21 PM, Steven D'Aprano <[EMAIL PROTECTED]>
wrote:
>>> On Thu, 28 Aug 2008 08:39:01 am Georg Brandl wrote:
Fredrik Lundh schrieb:
> (using 3.0a4)
>
> >>> exec(open("file.py"))
>
> Traceback (most recent call last):
>File "", line 1, in
> TypeError: exec() arg 1 must be a string, file, or code object, not
> TextIOWrapper
>
> so what's "file" referring to here?
>
> (the above works under 2.5, of course)
See http://bugs.python.org/issue1762972 -- it has been decided to
drop that possibility.
>>> Hmmm... I have a concern with one of the patches in that issue; I refer
>>> to patch that changes the semantics of module's __file__ attribute.
>>>
>>> Guido noted that exec(open(M.__file__).read(), M.__dict__) almost worked
>>> as a replacement for reload(), except that there were issues with file
>>> extensions (.py, .pyc, .pyo and even things like .pyc24). So it was
>>> decided that M.__file__ should always point to the source file.
>>>
>>> But now that reload() is now moved into the imp module, I don't see that
>>> the justification for changing the semantics of M.__file__ still
>>> exists. imp.reload(M) is much better for interactive use than
>>> exec(open(M.__file__).read(), M.__dict__).
>>>
>>> Is there still a justification for having M.__file__ point to the source
>>> even if the module was actually loaded from the .pyc version? If so,
>>> what is that?
>>>
>>> Some years ago, as a newbie, I was having trouble with reload()
>>> repeatedly not picking up changes I was making to a module. The problem
>>> turned out to be user-error, but how I discovered that was by looking
>>> at M.__file__ and noticing that Python was loading the .pyc file
>>> instead of the .py file I was expecting. Had M.__file__ given
>>> misleading information, I would have been mislead for much longer.
>>> Here's a small contrived example under Python 2.5:
>>>
>> import parrot
>> parrot.__file__
>>> 'parrot.py'
>> # pretend that I made changes to the source
>>> ... # in my editor, but forgot to save them
>>> ... reload(parrot)
>>>
>> parrot.__file__
>>> 'parrot.pyc'
>>>
>>>
>>> I don't think M.__file__ should lie and say it was loaded from a file
>>> that it wasn't loaded from. It's useful to be able to look at a module
>>> and see what file it was actually loaded from.
>>
>> While appreciate the use case, there are way more use cases where
>> there's code that must painstakingly strip the trailing 'c' or 'o'
>> from __file__ in order to read the source code. Perhaps we should have
>> a separate API for finding out whether a module was loaded from source
>> or from a .pyc file; but I think it would be better to have such an
>> API somewhere in the imp module. It's also possible to follow what
>> goes on by watching the verbose -v output.
>>
> Painstakingly? Surely the pain level isn't that high, and I agree with
> Michael that the __file__ information would be better as the literal
truth.
Some people have custom mods to Python that change the extension, and then
the c/o stripping code breaks. What is the literal truth depends on your use
case. It is the literal truth that the source file is the .py file.
--
--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] Things to Know About Super
On Thu, Aug 28, 2008 at 8:54 PM, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > I created a "universal metaclass" in > DecoratorTools whose sole function is to delegate metaclass __new__, > __init__, and __call__ to class-level methods (e.g. __class_new__, > __class_call__, etc.), thereby eliminating the need to have custom > metaclasses for most use cases in the first place. Now, wherever possible, > I use that single metaclass in my frameworks, so that there's no need to mix > them. easy_installed DecoratorTools and found it: classy_class. >From the point of view of the code, this is a beautiful and elegant snippet. However, suppose that from tomorrow everybody starts using it. Since metaclasses would become so easy to use, possibly a lot of people would take advantage of them. Then we would have potentially complex (multiple) inheritance hierarchies with chains of methods (_class__new__/_class__init__) calling themselves cooperatively in the MRO. Would the resulting code be readable? How easy would be for an average framework user to understand what is happening to his class? I think class decorators would be a much better solution than classy_class for most use cases and we should push that way, not the cooperative inheritance way. Generally speaking I like more solutions bases on functional composition (as in WSGI that you know very well) than on method cooperation. Rather than improve the support for inheritance, I would like (in an ideal world) to reduce it, to make easier the choice for people between inheritance and alternatives (object composition, delegation, functional composition). In the real world, I am content in documenting the pitfalls of super, warn people about the dangers of complex design involving multiple inheritance and cooperation, and suggest alternatives. Michele Simionato ___ 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] Things to Know About Super
At 06:07 AM 8/29/2008 +0200, Michele Simionato wrote: On Thu, Aug 28, 2008 at 8:54 PM, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > I created a "universal metaclass" in > DecoratorTools whose sole function is to delegate metaclass __new__, > __init__, and __call__ to class-level methods (e.g. __class_new__, > __class_call__, etc.), thereby eliminating the need to have custom > metaclasses for most use cases in the first place. Now, wherever possible, > I use that single metaclass in my frameworks, so that there's no need to mix > them. easy_installed DecoratorTools and found it: classy_class. >From the point of view of the code, this is a beautiful and elegant snippet. However, suppose that from tomorrow everybody starts using it. Since metaclasses would become so easy to use, possibly a lot of people would take advantage of them. That was sort of the idea. ;-) Then we would have potentially complex (multiple) inheritance hierarchies with chains of methods (_class__new__/_class__init__) calling themselves cooperatively in the MRO. Would the resulting code be readable? Readability's orthogonal. Some of them might be readable, some not. Depends on who's writing them. :) How easy would be for an average framework user to understand what is happening to his class? You're right, let's abolish inheritance, too, because then you might have to read more than one class to see what's happening. I think class decorators would be a much better solution than classy_class for most use cases Obviously, I disagree. :) You'll notice that DecoratorTools supports class decorators for Python 2.3 and up (actually, I think that particular bit worked in 2.2 as well). So, it's not the absence of class decorators that motivated the 'classy' mixin. Generally speaking I like more solutions bases on functional composition (as in WSGI that you know very well) than on method cooperation. Rather than improve the support for inheritance, I would like (in an ideal world) to reduce it, to make easier the choice for people between inheritance and alternatives (object composition, delegation, functional composition). In the real world, I am content in documenting the pitfalls of super, warn people about the dangers of complex design involving multiple inheritance and cooperation, and suggest alternatives. Naturally, if you can design a system to use delegates instead of class hierarchy to represent a chain of responsibility, it might well be an improvement. But there are tradeoffs, and no matter what you are going to end up coding chains of responsibility. Co-operative inheritance is a nice solution for chains of responsibility that can be expressed in a class hierarchy, and are no more "dangerous" than any other sort of chain of responsibility. In fact, they are in some ways less so since the patterns are likely to be better documented than anything you come up with on your own. ___ 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] Things to Know About Super
On Fri, Aug 29, 2008 at 6:22 AM, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > You're right, let's abolish inheritance, too, because then you might have to > read more than one class to see what's happening. You are joking, but I actually took this idea quite seriously. Once (four years ago or so) I did implement an object system from scratch in Scheme, completely without inheritance, to see how far it would go. It didn't go far, of course (nor I did expect it to go very far) but at least I learned exactly what (single) inheritance was good for. OTOH, for what concerns multiple inheritance, I am still not convinced it is really worth it. I mean, the MRO is beautiful, elegant and all that on paper, but on real-life code things as different, especially from the side of the users of frameworks heavily based on inheritance. > Naturally, if you can design a system to use delegates instead of class > hierarchy to represent a chain of responsibility, it might well be an > improvement. But there are tradeoffs, and no matter what you are going to > end up coding chains of responsibility. Agreed, it is all about tradeoffs. We have a different opinion on what a good tradeoff is in this case, but that's fine. I guess it depends on personal experience and the kind of code one has to work with. For instance I never had to integrated different frameworks using different metaclasses in my daily work, so I don't see a very strong case for classy_class over class decorators, but I could change my mind in the future, who knows? Anyway, It would be nice to have a good simple *real life* use case of cooperative inheritance not involving metaclasses, suitable for a beginners' tutorial about super, but I haven't found one yet :-( M.S. ___ 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
