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 vari
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 relati
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
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 wi
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
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 instan
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 "
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 c
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
-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
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
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
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
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 happ
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 fix
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)
>
>
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
iterato
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.
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 a
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
>>> ri
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 t
[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
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
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 hint
-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/
Co
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 easi
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
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
[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, ...
Th
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 matt
30 matches
Mail list logo