[Python-Dev] distutils small fix
Hello Marc-André and I are looking for one more reviewer for the patch http://bugs.python.org/issue2562 It makes it possible to use accented letters in distutils' metadata, like the author name, by switching those fields to Unicode. setuptools and PyPI are both fine with this, it is just a matter of making distutils writing the PKG_FILE correctly. Regards Tarek -- Tarek Ziadé | Association AfPy | www.afpy.org Blog FR | http://programmation-python.org Blog EN | http://tarekziade.wordpress.com/ ___ 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] Things to Know About Super
[Michele Simionato] Recently I have opened a blog on Artima and I am publishing a few Python-related essays I had in store. In particular a trilogy of papers about "super". From the foreword: """ In 2004 I decided to write a comprehensive paper documenting ``super`` pitfalls and traps, ... Thanks for posting these blogs. I think they serve as a nice compilation of docs, original analysis, and various discussions on super(). What I would really like to see is a fourth blog entry that shows how to use super() reliably and correctly. In general, I opposed to creating documentation in the form of "danger, danger this could explode " IMO, there is not much point in dwelling on bugs that have already been fixed, nor is there an advantage to showing all the ways the tool can be misused. In applications without multiple inheritance, it is a straight-forward to use super() as a way to avoid directly naming an immediate parent class. This is useful in and of itself. For cooperative multiple inheritance, I take issue with the abstracted examples provided (i.e. inconsistent signatures). In a real app that actually needs cooperative multiple inheritance, it becomes self-evident what "cooperative" actually means -- the methods *have* to be designed to interoperate -- it is intrinsic to the problem at hand. Your reasoning is akin to saying that cooperative multitasking is intrinsically flawed because one of the tasks could be designed to not cooperate (never yield). Cooperative multiple inheritance is *not* about mixing two unrelated parents that just happen to use the same method name but have different semantics and were not designed to cooperate with each other. The A-B-C-D diagrams and foo/bar methods in the examples are deceptive because they silently drop the precondition of cooperation while attempting to demonstrate a supposed flaw in the tool. If I understand the problem correctly, in the rare cases where you do need cooperative multiple inheritance, then super() is the only workable solution short of designing some equivalent using composition instead of inheritance. I do agree with you that the docs can be improved. I'll work on patch that makes clear that super() returns a proxy-object (not an actual parent class) that dispatches explict method calls (not syntax driven) to one of multiple parents designed to interact cooperatively. Also, it may be controversial, but there may be some merit in de-documenting the "unbound" case. It seems to add more confusion than it's worth. Lastly, I take issue with one other part of the blogs. While they show a clear dislike for cooperative multiple inheritance, they take a potshot at multiple inheritance in general. I don't follow the logic here. IMO, mixin classes like DictMixin have proven themselves as being very useful. Plenty of frameworks share this approach. Likewise, the new ABCs offer mixin capabilities that are really nice. I think it is a non-sequiter to reason from "diamond diagrams are complicated" to "mixins should be disallowed". Instead, I think it better to simply recommend that a key to happiness is to keep various mixin classes completely orthogonal to one another (no overlapping method names). Lest I sound negative, let me thank you again for the blog entries and for compiling the most complete discussion of it in one place. 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] Mercurial mirrors
Hello, Thanks to Neil Schemenauer, we now have some Mercurial mirrors hosted at http://code.python.org/hg/ Here are the URLs for each of the available repositories: - http://code.python.org/hg/trunk/ - http://code.python.org/hg/branches/py3k/ - http://code.python.org/hg/branches/release2.5-maint/ For Mercurial beginners, each of the URLs above references both a human-readable Web interface to browse the repositories (view changesets, subscribe to an RSS feed, annotate source files...), and a machine-queryable address to "clone" the repositories for local, offline use. That is, if you run "hg clone http://code.python.org/hg/trunk/";, you'll get a "trunk" subdirectory containing the whole trunk history in a local repository, as well as a working copy. You can then do, e.g. "hg annotate setup.py" at light speed. The Mercurial mirrors are sync'ed with the SVN repo every 5 minutes. They are read-only, that is you cannot push to them. (technical note: the mirrors are done using my own "hgsvn", but an alternate strategy would be to use the builtin "hg convert" instead) Regards Antoine. ___ 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] Things to Know About Super
On Tue, Aug 26, 2008 at 5:32 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > What I would really like to see is a fourth blog entry that shows > how to use super() reliably and correctly. That could be arranged. > In general, I opposed > to creating documentation in the form of "danger, danger this > could explode " IMO, there is not much point in dwelling on > bugs that have already been fixed, nor is there an advantage to > showing all the ways the tool can be misused. Yep. The parts about the bugs of super in 2.2 and 2.3 were written years ago, when they were relevant. Nowadays they are less relevant, but since they were already written and since there are still people using older versions of Python I decided to keep them. I would not keep them in a revised version intended as "semi-official" documentation of super. Still, I think they are fine as a blog post. > For cooperative multiple inheritance, I take issue with the abstracted > examples provided (i.e. inconsistent signatures). In a real app that > actually needs cooperative multiple inheritance, it becomes self-evident > what "cooperative" actually means -- the methods *have* to be > designed to interoperate -- it is intrinsic to the problem at hand. > Cooperative multiple inheritance is *not* about mixing two unrelated > parents that just happen to use the same method name but have > different semantics and were not designed to cooperate with each other. > > The A-B-C-D diagrams and foo/bar methods in the examples are > deceptive because they silently drop the precondition of cooperation > while attempting to demonstrate a supposed flaw in the tool. They just show that the tool is delicate and not easy to use. > If I understand the problem correctly, in the rare cases where you do > need cooperative multiple inheritance, then super() is the only workable > solution short of designing some equivalent using composition instead > of inheritance. In my experience, one can go a long way using composition instead of inheritance. I also think that Python would not lose much without cooperative multiple inheritance. This is however a personal opinion and in any case the point is moot because the language is the way it is. Still, in a blog post personal opinions and even rants have their place. That part could be removed in an "semi-official" document. > Also, it may be controversial, but there may be some merit in de-documenting > the "unbound" case. It seems to add more confusion than it's worth. Fine with me. > Lastly, I take issue with one other part of the blogs. While they show > a clear dislike for cooperative multiple inheritance, they take a potshot > at multiple inheritance in general. I don't follow the logic here. IMO, > mixin classes like DictMixin have proven themselves as being very > useful. Plenty of frameworks share this approach. Likewise, the > new ABCs offer mixin capabilities that are really nice. > > I think it is a non-sequiter to reason from "diamond diagrams are > complicated" to "mixins should be disallowed". Instead, I think it better > to simply recommend that a key to happiness is to keep various mixin classes > completely orthogonal to one another (no overlapping method names). I not completely against multiple inheritance. I am against multiple inheritance as it is now. A restricted form of multiple inheritance in which mixins classes are guaranteed to be orthogonal would be fine with me (provided it is not abused). This concept exists already in other languages, the orthogonal mixins are called "traits". I have written a trilogy of papers about mixins: if you read them, you will see where I come from (Zope, which I do not like) and you will also see that I like DictMixin instead. I will publish the papers in the blog soon or later, but you can find the Italian version here: http://stacktrace.it/articoli/2008/06/i-pericoli-della-programmazione-con-i-mixin1/ http://stacktrace.it/articoli/2008/07/i-pericoli-della-programmazione-con-i-mixin2/ http://stacktrace.it/articoli/2008/08/i-pericoli-della-programmazione-con-i-mixin3/ Michele Simionato ___ 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] Mercurial mirrors
On Tue, Aug 26, 2008 at 10:53 AM, Antoine Pitrou <[EMAIL PROTECTED]> wrote: > > Hello, > > Thanks to Neil Schemenauer, we now have some Mercurial mirrors hosted at > http://code.python.org/hg/ Cool! It's nice to have these become "official". My hg branches are all pointing to your site. Can I easily relocate the parent branch? -- Cheers, Benjamin Peterson "There's no place like 127.0.0.1." ___ 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] Mercurial mirrors
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Aug 26, 2008, at 12:42 PM, Benjamin Peterson wrote: On Tue, Aug 26, 2008 at 10:53 AM, Antoine Pitrou <[EMAIL PROTECTED]> wrote: Hello, Thanks to Neil Schemenauer, we now have some Mercurial mirrors hosted at http://code.python.org/hg/ Cool! It's nice to have these become "official". My hg branches are all pointing to your site. Can I easily relocate the parent branch? Actually, right now anything that's not Subversion is still experimental. But agreed that it's nice Mercurial and Bazaar are available. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSLQ6yXEjvBPtnXfVAQK/fgP/aRTdNeqdWddQetANArV8zpYLbS7TUUbl b/h0p6fWJdSf4ZPkuN4yjXZz8F+4QXc+B1qF8qxEdtc9BjvSBbgOED/GEjF++9OJ fQ2JpT01+Cj2Z8rl034leTrGq1CQ9uDC7YTWJblJjyFiFiCEzSiiJ6aETe3LDpwe ZJT6OxyQVwU= =7YSu -END PGP SIGNATURE- ___ 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] Fix python darwin build to look for non-framework Tk if not a framework build?
Python's own setup.py file seems to only look for a Framework Tcl/Tk on darwin. This is a headache if one is trying to build a non-framework python that uses a non-framework tcl/tk. Any chance of getting this fixed? I'm willing to work on a patch if it has any chance of being accepted. Any hints on how to determine if it is a framework build from within setup.py would be most welcome! -- Russell ___ 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] Mercurial mirrors
On Tue, Aug 26, 2008 at 8:53 AM, Antoine Pitrou <[EMAIL PROTECTED]> wrote: > > Hello, > > Thanks to Neil Schemenauer, we now have some Mercurial mirrors hosted at > http://code.python.org/hg/ > > Here are the URLs for each of the available repositories: > - http://code.python.org/hg/trunk/ > - http://code.python.org/hg/branches/py3k/ > - http://code.python.org/hg/branches/release2.5-maint/ > > For Mercurial beginners, each of the URLs above references both a > human-readable > Web interface to browse the repositories (view changesets, subscribe to an RSS > feed, annotate source files...), and a machine-queryable address to "clone" > the > repositories for local, offline use. > > That is, if you run "hg clone http://code.python.org/hg/trunk/";, you'll get a > "trunk" subdirectory containing the whole trunk history in a local repository, > as well as a working copy. You can then do, e.g. "hg annotate setup.py" at > light > speed. > > The Mercurial mirrors are sync'ed with the SVN repo every 5 minutes. They are > read-only, that is you cannot push to them. > But can we push branches up to our personal directories on code.python.org like we can with bzr? -Brett ___ 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] Things to Know About Super
[Raymond] Cooperative multiple inheritance is *not* about mixing two unrelated parents that just happen to use the same method name but have different semantics and were not designed to cooperate with each other. The A-B-C-D diagrams and foo/bar methods in the examples are deceptive because they silently drop the precondition of cooperation while attempting to demonstrate a supposed flaw in the tool. [Michele] They just show that the tool is delicate and not easy to use. To me, they miss the point. Simply, if you don't have diamonds, then super() is easy to use and if you do have have diamonds, then super() is the *only* way to do it. Diamonds impose a set of design constraints (making the classes cooperative). The A-B-C-D diagrams ignore this point and make super() seem like an accident waiting to happen. In contrast, with a concrete example, accidental non-cooperativeness would be more self-evident. The problem isn't that super() is fragile. The problem is that a cooperative design pattern requires you to actually make the classes cooperate. This is no different than a visitor design pattern requiring that you attach a conformant visit() method for on each of the visited classes. [Michele] In my experience, one can go a long way using composition instead of inheritance. While that is often true, I don't think it applies to the case of cooperative multiple inheritence. To achieve substantially the same functionality using composition, you would likely have to re-invent much of what super() does for us automatically, and you would still be imposing constraits on the composed classes that are substantially the same as what you have with inheritance. [Michele] I also think that Python would not lose much without cooperative multiple inheritance. I would state this differently: "The use cases for cooperative multiple inheritence don't arise often in practice; so, if we dropped support for those cases, you probably wouldn't notice until you encountered one of the rare occasions where it was the right answer to your problem." There was some quote floating around that expressed the situation well -- it went something like: "Python makes most problems easy and hard problems possible". The use cases for cooperative multiple inheritance fall in the latter category. BTW, I really like your paper explaining the MRO. Excellent work. 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] Confusing listreverseiterator Behavior
Hi, I stumbled upon a confusing listreverseiterator behavior: >>> l = [1, 2, 3, 4] >>> i = iter(l) >>> ri = reversed(l) >>> len(i) Traceback (most recent call last): File "", line 1, in TypeError: object of type 'listiterator' has no len() >>> len(ri) 4 >>> ri.next() 4 >>> len(ri) 3 This is the only reverse iterator with that sort of behavior. Is that intentional if yes, why? I stumbled upon that when writing a templating engine that tried to lazily get the length of the sequence / iterator but failed doing so after the first iteration because the length of the reverse iterator changes every iteration. Regards, Armin ___ 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] Confusing listreverseiterator Behavior
Unless I'm misconstruing something the problem is that reversed returns two different object types depending on if it's a list or a tuple >>> l = [1,2,3,4] >>> i = iter(l) >>> ri = reversed(l) >>> l [1, 2, 3, 4] >>> ri >>> i >>> t = (1,2,3,4) >>> it = iter(t) >>> rit = reversed(t) >>> it >>> rit >>> reversing a tuple (or a string) returns a "reversed object" reversing a list returns a "listreverseiterator" definitely an inconsistency ___ 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] Confusing listreverseiterator Behavior
I realized after I fired off my response that this was still bugging me... it appears that the documentation is incorrect from 2.1 Built-in Functions (v2.5 in case it matters... a quick search of bugs doesn't seem to show anything though) *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. the above appears to only be true for lists. For tuples and strings it creates a reverse OBJECT which behaves slightly differently (notably by not including a len() method as you noticed) I can't find how to actually create a "tuplereverseiterator" or "stringreverseiterator" objects... nor does there appear to be a way to create a "reversed" object from a list... Just tested this s = 'bob' t = (1,2,3,4) l = [1,2,3,4) rs = reversed(s) rt = reversed(t) rl = reversed(l) type(rs) type(rt) type(rl) type(rs) == type(rt) True type(rs) == type(rl) False Surely this isn't intentional? Haikus are easy Most make very little sense Refrigerator ___ 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] Confusing listreverseiterator Behavior
Jeff Hall gmail.com> writes:
> 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. the above appears to only be true for lists. For
> tuples and strings it creates a reverse OBJECT which behaves slightly
> differently (notably by not including a len() method as you noticed)
> I can't find how to actually create a "tuplereverseiterator" or
> "stringreverseiterator" objects... nor does there appear to be a way to
> create a "reversed" object from a list...
That's an implementation detail what exactly the reverse iterator is. The
same applies to iter() calls. iter("foo") for example returns a iterator
type, iter([]) returns a list iterator. The thing you quoted above is the
requirement for the object that you pass to reverse(), not the object
returned which is some kind of iterator that happens to iterate over the
sequence in reverse.
The problem I personally have with it is that the listreverseiterator is the
only iterator in the standard library that changes the length during
iteration and that it's the only reverse iterator that has a length. Even
more stunning as the normal iterator doesn't have one.
Regards,
Armin
___
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] Confusing listreverseiterator Behavior
From: "Armin Ronacher" <[EMAIL PROTECTED]> len(ri) 4 ri.next() 4 len(ri) 3 This is the only reverse iterator with that sort of behavior. Use the bug tracker please and assign to me. At one time, some iterators had the ability to know their own length and that would change as the iterator got consumed. Later, it was decided that iterators should not report length and should instead report a length hint. It looks like listreversediterator got missed when this was changed. 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
Re: [Python-Dev] Confusing listreverseiterator Behavior
Jeff Hall schrieb: > I realized after I fired off my response that this was still bugging > me... it appears that the documentation is incorrect > > from 2.1 Built-in Functions (v2.5 in case it matters... a quick search > of bugs doesn't seem to show anything though) > > *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. > > the above appears to only be true for lists. Not at all. (I think you misread; the __len__ method must be present on the argument, not the returned object.) > For tuples and strings it > creates a reverse OBJECT which behaves slightly differently (notably by > not including a len() method as you noticed) > > I can't find how to actually create a "tuplereverseiterator" or > "stringreverseiterator" objects... nor does there appear to be a way to > create a "reversed" object from a list... You don't need to. An object returned by reversed() only needs to follow the iterator protocol. Whether it is a listreverseiterator or a general reversed object doesn't matter. In fact, reversed() calls __reversed__ on its argument if it exists, so that custom types may provide their own optimized reverse iterator. Georg ___ 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] Fix python darwin build to look for non-framework Tk if not a framework build?
On Tue, Aug 26, 2008 at 12:59 PM, Russell E. Owen <[EMAIL PROTECTED]> wrote: > Python's own setup.py file seems to only look for a Framework Tcl/Tk on > darwin. This is a headache if one is trying to build a non-framework > python that uses a non-framework tcl/tk. > > Any chance of getting this fixed? I'm willing to work on a patch if it > has any chance of being accepted. Any hints on how to determine if it is > a framework build from within setup.py would be most welcome! If you do, please file a ticket on the tracker with your patch. Thanks! > > -- Russell > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/musiccomposition%40gmail.com > -- Cheers, Benjamin Peterson "There's no place like 127.0.0.1." ___ 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] Things to Know About Super
Michele Simionato wrote: > On Tue, Aug 26, 2008 at 5:32 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote: [...] >> I think it is a non-sequiter to reason from "diamond diagrams are >> complicated" to "mixins should be disallowed". Instead, I think it better >> to simply recommend that a key to happiness is to keep various mixin classes >> completely orthogonal to one another (no overlapping method names). > > I not completely against multiple inheritance. I am against multiple > inheritance > as it is now. A restricted form of multiple inheritance in which mixins > classes > are guaranteed to be orthogonal would be fine with me (provided it is > not abused). > This concept exists already in other languages, the orthogonal mixins > are called "traits". > If you aren't aware of it you should take a look at Enthought's traits package. It's part of the Enthought Tool Suite (ETS). https://svn.enthought.com/enthought/wiki While I too appreciate your comments about super I believe you have perhaps overdone it. I do look forward to seeing the edited edition as a part of the documentation. [Hint: the *docs* aren't in feature freeze ;-)] regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ ___ 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] Mercurial mirrors
Benjamin Peterson gmail.com> writes: > > Cool! It's nice to have these become "official". My hg branches are > all pointing to your site. Can I easily relocate the parent branch? Just edit .hg/hgrc in your branches and modify the "default" value in the "[paths]" section. Then "hg in" to be sure everything went ok. Regards Antoine. ___ 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] Mercurial mirrors
Brett Cannon python.org> writes: > > But can we push branches up to our personal directories on > code.python.org like we can with bzr? If you have an ssh access to code.python.org, it should be easy. However, giving other people anonymous read-only access would require some manual configuration I think (not lots of, though). ___ 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] class attributes slower in py3k
Antoine Pitrou pitrou.net> writes: > > > NormalClassAttribute:339ms340ms0.28us1.111ms > > > > Over twice as slow? > > Yes, should be investigated. > [...] > > > > SpecialClassAttribute:534ms535ms0.45us1.121ms > > > > ~4x slower! > > Should be investigated as well. It turns out that these two slowdowns are due to classes always being new-style in py3k. Indeed, if I add "__metaclass__ = type" at the beginning of Tools/pybench/Lookups.py, 2.6 becomes as slow as 3.0. Regards Antoine. ___ 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] Mercurial mirrors
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Aug 26, 2008, at 6:28 PM, Antoine Pitrou wrote: Brett Cannon python.org> writes: But can we push branches up to our personal directories on code.python.org like we can with bzr? If you have an ssh access to code.python.org, it should be easy. However, giving other people anonymous read-only access would require some manual configuration I think (not lots of, though). It should not be too hard to adapt the generalizations we made when we brought up the Bazaar repository. Unfortunately, I don't have time to do it, but Thomas and Martin (who are both also probably pretty swamped) probably know how we did it. If not before, we should spend time after the releases in making this available. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSLSS03EjvBPtnXfVAQKAVQP+KCbGOHU0xjfR1mghhdPhlzhHslC1Jwc+ WJAIoDfO/qWGwzBBImIoEqsAqdEBWVbaEjQN57EtL0LRUoR0S3bJdg9P/EeOBDlv 2RHxYZomMFE4rlUJer27oHVBXRO/MgIfWiePQEHowEQQ1pe4INnqiF0OeMlou8sb fYsrpEIun5k= =gtAb -END PGP SIGNATURE- ___ 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] Things to Know About Super
On Tue, Aug 26, 2008 at 8:56 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > I would state this differently: "The use cases for cooperative multiple > inheritence don't arise often in practice; so, if we dropped support > for those cases, you probably wouldn't notice until you encountered > one of the rare occasions where it was the right answer to your problem." > > There was some quote floating around that expressed the situation > well -- it went something like: "Python makes most problems easy > and hard problems possible". The use cases for cooperative multiple > inheritance fall in the latter category. It is just a matter of how rare the use cases really are. Cooperative methods has been introduced 6+ years ago. In all this time surely they must have been used. How many compelling uses of cooperation we can find in real life code? For instance in the standard library or in some well known framework? This is a serious question I have been wanting to ask for years. I am sure people here can find some example, so just give me a pointer and we will see. > BTW, I really like your paper explaining the MRO. Excellent work. The issue with that paper is that I wrote it when my Python experience was reduced to six month and my experience with real life large object oriented frameworks was zero. Nowadays I value simplicity more. ___ 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] Things to Know About Super
On Tue, Aug 26, 2008 at 6:16 PM, Michele Simionato <[EMAIL PROTECTED]> wrote: ... > It is just a matter of how rare the use cases really are. Cooperative > methods has been introduced 6+ years ago. In all this time surely > they must have been used. How many compelling uses of cooperation > we can find in real life code? For instance in the standard library or > in some well known framework? This is a serious question I have been > wanting to ask for years. I am sure people here can find some example, > so just give me a pointer and we will see. http://www.koders.com/default.aspx?s=super&btn=&la=Python&li=* finds over 5,000 hits, but it would take substantial work to sift through them (in particular because not all refer to the built-in super, as you'll see even in the first page!) -- and a random hit I found by going to p.7 is really bad...: """Mixin to enable reification.""" def __init__(self): super(ReificationStore, self).__init__() [there's *nothing else* in this __init__!]. 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] subprocess insufficiently platform-independent?
Guido quotes a colleague:
> """
> Given a straightforward command list like:
>
> cmd = ['svn', 'ls', 'http://rietveld.googlecode.com/svn/trunk']
>
> You apparently cannot pass this list to any subprocess function
> (subprocess.call() or otherwise) with a set of arguments that allow it
> to "just work" on both Windows and non-Windows systems.
>
> If you call:
>
> subprocess.call(cmd, shell=False)
>
> Then it works on Linux, but fails on Windows because it does not
> perform the Windows %PATHEXT% search that allows it to find that
> "svn.exe" is the actual executable to be invoked.
I can't reproduce this as described.
>>> subprocess.call(['svn', 'ls'], shell=False)
svn: '.' is not a working copy
1
The reason this works is that Windows itself (CreateProcess) has support
both for implied '.exe' extensions and searching $PATH. Thus, PATHEXT
handling isn't required for executables.
I *can* reproduce with another extension - eg, 'svn.py' - for this test I
had a 'foo.py' on my PATH (but not in the cwd), and .py in PATHEXT.
>>> import subprocess
>>> subprocess.call(['foo'], shell=False)
... fails
>>> subprocess.call(['foo'], shell=True)
Hello
0
So I can't see this problem for 'svn.exe' and at face value the behaviour on
Windows looks quite correct - you *do* need the shell for this functionality
on Windows (in the same way you would to execute a .bat file, for example)
> If you call:
>
> subprocess.call(cmd, shell=True)
>
> Then it works on Windows (it finds the "svn.exe" executable), but it
> fails on Linux because it *only* executes the first argument in the
> list ("svn") and does not pass the remaining arguments in the list to
> the "svn" invocation.
It sounds like in this particular example at least, this behaviour on Linux
is the problem?
Mark
___
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] Things to Know About Super
At 03:16 AM 8/27/2008 +0200, Michele Simionato wrote: It is just a matter of how rare the use cases really are. Cooperative methods has been introduced 6+ years ago. In all this time surely they must have been used. How many compelling uses of cooperation we can find in real life code? For instance in the standard library or in some well known framework? This is a serious question I have been wanting to ask for years. I am sure people here can find some example, so just give me a pointer and we will see. ISTR pointing out on more than one occasion that a major use case for co-operative super() is in the implementation of metaclasses. The __init__ and __new__ signatures are fixed, multiple inheritance is possible, and co-operativeness is a must (as the base class methods *must* be called). I'm hard-pressed to think of a metaclass constructor or initializer that I've written in the last half-decade or more where I didn't use super() to make it co-operative. That, IMO, is a compelling use case even if there were not a single other example of the need for super. However, I'm pretty sure I've had other cases where it was necessary to co-operate in cases where multiple inheritance occurred later; ie. where it was possible for a subclass to add a new class between parents. Remember that subclasses of a new-style class do not always have the same MRO tail as the original class; i.e., a subclass of "class A(B, C):" is only constrained to have [A...B...C] in its MRO; semi-arbitrary classes may be inserted between e.g. A and B. So, a new-style class cannot, as a general rule, statically determine what base class implementation of a method should be invoked. I personally consider the rare case where I have to force such static knowledge to be an unfortunate wart in the design (of that code, not Python). ___ 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] Things to Know About Super
On Wed, Aug 27, 2008 at 3:30 AM, Alex Martelli <[EMAIL PROTECTED]> wrote: > On Tue, Aug 26, 2008 at 6:16 PM, Michele Simionato > <[EMAIL PROTECTED]> wrote: > ... >> It is just a matter of how rare the use cases really are. Cooperative >> methods has been introduced 6+ years ago. In all this time surely >> they must have been used. How many compelling uses of cooperation >> we can find in real life code? For instance in the standard library or >> in some well known framework? This is a serious question I have been >> wanting to ask for years. I am sure people here can find some example, >> so just give me a pointer and we will see. > > http://www.koders.com/default.aspx?s=super&btn=&la=Python&li=* finds > over 5,000 hits, but it would take substantial work to sift through > them (in particular because not all refer to the built-in super, as > you'll see even in the first page!) Yep. Notice (I am sure you understood the point correctly, but just to clarify) that I am not interested in random occurrences of super, but in code/frameworks expressly designed to leverage on cooperation and doing it in a compelling way. IOW, I want to see cases where using cooperation is really better than relying on other techniques. Guido gives an example in http://www.python.org/download/releases/2.2.3/descrintro/#cooperation with a .save method, so in theory there are good use cases, but I wonder in practice how common they are and if they are frequent enough to justify the added complication. M.S. ___ 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] Things to Know About Super
On Tue, Aug 26, 2008 at 6:13 PM, Michele Simionato <[EMAIL PROTECTED]> wrote: > I not completely against multiple inheritance. I am against multiple > inheritance > as it is now. A restricted form of multiple inheritance in which mixins > classes > are guaranteed to be orthogonal would be fine with me (provided it is > not abused). > This concept exists already in other languages, the orthogonal mixins > are called "traits". I must correct myself here. Even if for practical purposes traits look like a restricted multiple inheritance, in principle it is better to think of them as of an enhanced single inheritance. With traits there is always a single superclass: traits are just single inheritance with a nice syntax to include methods (like in Ruby) and a guarantee that methods will not be overridden silently (this one is missing in Ruby). M.S. ___ 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] Things to Know About Super
On Wed, Aug 27, 2008 at 5:15 AM, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > ISTR pointing out on more than one occasion that a major use case for > co-operative super() is in the implementation of metaclasses. The __init__ > and __new__ signatures are fixed, multiple inheritance is possible, and > co-operativeness is a must (as the base class methods *must* be called). > I'm hard-pressed to think of a metaclass constructor or initializer that > I've written in the last half-decade or more where I didn't use super() to > make it co-operative. > > That, IMO, is a compelling use case even if there were not a single other > example of the need for super. I have been giving a lot of thought to this use case, at least from the time of the metaclass conflict recipe. I have always wondered why the recipe had to be so complicated. At the end, I have come to the conclusion that the problem was not with the recipe but with multiple inheritance itself. Let me explain the argument. A possible use case for multiple inheritance of metaclasses is the following: suppose I have a DebugMeta metaclass which adds some debugging support to classes; now I want to apply it to a third party framework which uses a FrameworkMeta metaclass internally. Let us suppose the framework author wrote its metaclass correctly, by supporting cooperation: .. code-block:: python class FrameworkMeta(type): def __new__(mcl, name, bases, dic): print "Adding framework features to %s" % name return super(FrameworkMeta, mcl).__new__(mcl, name, bases, dic) >>> class FrameworkClass(object): ...__metaclass__ = FrameworkMeta Adding framework features to FrameworkClass Moreover, suppose I wrote my DebugMeta to support cooperation correctly: .. code-block:: python class DebugMeta(type): def __new__(mcl, name, bases, dic): print "Adding debugging features to %s" % name return super(DebugMeta, mcl).__new__(mcl, name, bases, dic) Now I can add the debugging features to a class in this way: .. code-block:: python class DebugFrameworkMeta(DebugMeta, FrameworkMeta): pass >>> class DebugFrameworkClass(FrameworkClass): ... __metaclass__ = DebugFrameworkMeta Adding debugging features to DebugFrameworkClass Adding framework features to DebugFrameworkClass As you see everything works fine. Now, lets travel in the fictional world of a fictional language called T-Python which is just like Python, except it lacks multiple inheritance but has some support for traits. By this I mean that there is an ``include_mixin`` function working more or less like this (it could be enhanced but I am keeping it dead simple here for the sake of the argument): .. code-block:: python def include_mixin(mixin, cls): # could be extended to use more mixins # traits as in Squeak take the precedence over the base class dic = vars(mixin).copy() # could be extended to walk the ancestors return type(mixin.__name__ + cls.__name__, (cls,), dic) I will argue that T-Python is not worse than Python for this use case (composition of metaclasses). In the fictional world there is not need for super since all hierarchies are linear and you can just call the base class; FrameworkMeta could have been written as .. code-block:: python class FrameworkMeta2(type): def __new__(mcl, name, bases, dic): print "Adding framework features to %s" % name return type.__new__(mcl, name, bases, dic) and DebugMetas as .. code-block:: python class DebugMeta2(type): def __new__(mcl, name, bases, dic): print "Adding debugging features to %s" % name return mcl.__base__.__new__(mcl, name, bases, dic) Notice that DebugMeta2 is performing a sort of cooperative call here (``mcl.__base__.__new__``) but dead simple since there is just one base class. The analogous of FrameworkClass can be defined as >>> class FrameworkClass2(object): ... __metaclass__ = FrameworkMeta2 Adding framework features to FrameworkClass2 and the analogous of DebugFrameworkClass as >>> class DebugFrameworkClass2(FrameworkClass2): ... __metaclass__ = DebugFrameworkMeta2 Adding debugging features to DebugFrameworkClass2 Adding framework features to DebugFrameworkClass2 So, as you see, it works. Checks of the kind ``isinstance(DebugFrameworkClass2, DebugMeta2)`` would fail, but this is not a big issue (isinstance should not be used, or you could register DebugMeta2 as a base class even if it is not by using Python 2.6 ABC's). Now, I am not claiming that I have thought of all possible usages of multiple inheritance and metaclasses: however I have not found yet a use case that I could not rewrite by using single-inheritance + traits as the one I have just shown. Possibly there are cases which are difficult to rewrite: but how common are they? Notice that I am not advocating rewriting Python. The argument here is purely hyphotetic and concerning a fictional language: I just want to understand if full multiple
Re: [Python-Dev] Things to Know About Super
On Tue, Aug 26, 2008 at 11:10 PM, Steve Holden <[EMAIL PROTECTED]> wrote: > If you aren't aware of it you should take a look at Enthought's traits > package. It's part of the Enthought Tool Suite (ETS). I know of the existence of that framework, however it is quite large and I don't see the relation with the concept of traits I have in mind, which is more or less the one described here: http://www.iam.unibe.ch/%7Escg/Archive/Papers/Scha03aTraits.pdf Basically, these are the properties of traits: 1. the methods/attributes in a trait go logically together; 2. if a trait enhances a class, then all subclasses are enhanced too; 3. if a trait has methods in common with the class, then the methods defined in the class have the precedence; 4. the ordering of traits is not important, i.e. enhancing a class first with trait T1 and then with trait T2 or viceversa is the same; 5. if traits T1 and T2 have names in common, enhancing a class both with T1 and T2 raises an error unless there is an explicitoverriding; 6. if a trait has methods in common with the base class, then the trait methods have the precedence; Properties from 4 to 6 are the distinguishing properties of traits with respect to multiple inheritance and mixins. ___ 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] the explicit self
Hello, i know this has been discusses very much, i'm sorry, but i can't help it. In a nutshell, the proposal is as follows: 1. Self remains explicit (like it is now). 2. if a class is a subclass of a special class, e.g. named 'selfless', the self parameter is not required and a special variable, named 'this' is provided. For example: class Foo (selfless): def __init__ (x, y): this.x = x ... A patch for 3.0b3 implementing this can be found at http://www-lehre.inf.uos.de/~kklimek/misc/python_slp_8.diff regards, Kilian Klimek ___ 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
