On 12/23/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> If I left your specific suggestion or question unaddressed or
> unanswered, please send it again (after re-reading the PEP, of
> course).
Shouldn't there be a motivation section ? If nothing else, it should
discuss (or at least link to a
Or for less barebones solution, WebFaction offers free Trac and
Subversion hosting for open-source python projects:
http://www.webfaction.com/freetrac.
George
On 12/5/06, Brett Cannon <[EMAIL PROTECTED]> wrote:
> There is Google Code Hosting: http://code.google.com/hosting/ .
>
> -Brett
>
>
> On
On 11/27/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> Bill Janssen wrote:
>
> > Now, I don't see why the connection to the
> > underlying VM implementation needs name-mangling -- it would be
> > reasonable just to define a distinguished module (call it, say, for
> > tradition's sake, "__VM__" :-)
On 11/23/06, Aahz <[EMAIL PROTECTED]> wrote:
> On Wed, Nov 22, 2006, Talin wrote:
> >
> > While I wouldn't say it quite so strongly, I do think that there is a
> > great deal of subjectivity in HCI discussions. One person's 'intuitive'
> > may be another person's 'orange smoke', as we've seen in t
On 11/23/06, Talin <[EMAIL PROTECTED]> wrote:
> Fredrik Lundh wrote:
> > George Sakkis wrote:
> >
> >> First off, I never implied someone's stupid just because we don't
> >> happen to agree on everything.
> >
> > brushing off a caref
Feel free to ignore it if you find it trivial/stupid/irrelevant; many
other apparently didn't.
On 11/22/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> It could have been a much shorter thread without you.
>
> On 11/22/06, George Sakkis <[EMAIL PROTECTED]> wrote:
>
here has been entirely a distraction. That's a troll to me.
>
> On 11/22/06, George Sakkis <[EMAIL PROTECTED]> wrote:
> > On 11/22/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > > On 11/22/06, George Sakkis <[EMAIL PROTECTED]> wrote:
> > > >
On 11/22/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 11/22/06, George Sakkis <[EMAIL PROTECTED]> wrote:
> > Although I don't necessarily agree with the arguments from a puristic
> > point of view ("then why not make keys(), values(), items(), read(),
&
On 11/22/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> George Sakkis wrote:
>
> > After all, HCI-based arguments are usually a fancier way of
> > saying "it's a matter of taste"
>
> It would be easier to take you seriously if you gave up that "I
On 11/22/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
>
> > Ivan Krstić explained this more concise in his message, which arrived
> > after I'd written all this up.
>
> which is a good thing, because your post is a much better version of
> the corresponding FAQ entry tha
On 11/22/06, Andrew Koenig <[EMAIL PROTECTED]> wrote:
> > Both 'ability' and 'interface' imply (to me, anyway) that the class
> > being inspected is an actor, that it 'does something' rather than being
> > operated on.
>
> I chose 'ability' because to me it doesn't require that the class being
> in
On 11/19/06, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
> I had the problem recently when I wrote a decorator which took an
> optional number as an argument. The decorator declaration goes like
> this:
>
> def deferred(timeout=None):
> def decorate(func):
> blah blah...
> return dec
On 11/17/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Bill Janssen wrote:
> > Checking for some textual attributes of a
> > type
>
> Now you're talking about LYBL, which is generally
> considered an anti-pattern in Python. APIs should
> be designed so that you don't need to test for the
> presence o
On 11/16/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> If you want anonymous blocks, by all means use Ruby. Python has
> first-class callables, Ruby has anonymous blocks. Pick your favorite,
> but don't whine that neither language has both. It ain't gonna happen.
Should there be a new additio
On 11/16/06, Jason Orendorff <[EMAIL PROTECTED]> wrote:
> (Actually, even if you *can* say something nice, this conversation
> might be worth dropping. Just a thought.)
I agree. For me, the bottom line and the main argument for dropping
the proposal is "itertools is not as big as you think it is
On 11/16/06, Talin <[EMAIL PROTECTED]> wrote:
> As far as multiple dispatch goes: I would agree here as well, especially
> when we talk about binary operations. For example, suppose we have two
> objects, a and b, which are of types A and B respectively. And suppose
> each of those types overloads
On 11/15/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> George Sakkis wrote:
>
> > class Container(object):
> >
> > class Sequence(Container):
>
> > class Mapping(Container):
> >
> > Note that this does _not_ disallow duck typing; anyone is perfectl
tomer filiba wrote:
> i'm not saying this particular example is useful, but i have
> had many times when i thought "argh, i wish i had class
> decorators for that".
Same here, but like Steve, I'm not very optimistic this will be
greeted with open arms.
> sadly though, i don't remember many of t
On 11/15/06, Iain Lowe <[EMAIL PROTECTED]> wrote:
> Hi George,
>
> I've been reading this thread with some interest since you seem to be
> really adamant about the "features" you are requesting. I went back into
> the c.l.p thread and did a little more searching before finding this
> thread: http:
On 11/15/06, Jim Jewett <[EMAIL PROTECTED]> wrote:
> (list clipped)
Sorry, I'd rather not get into private conversations.
> On 11/15/06, George Sakkis <[EMAIL PROTECTED]> wrote:
> > Note that this does _not_ disallow duck typing; anyone is perfectly
> > free
On 11/15/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
>
> "George Sakkis" <[EMAIL PROTECTED]> wrote:
> > You missed my point; I wasn't seriously suggesting that there should
> > be more checks (hence the quotes), but rather the contrary, that
>
On 11/15/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
>
> "George Sakkis" <[EMAIL PROTECTED]> wrote:
> > As I wrote in my last reply to Nick though, I question Python's right to
> > perform
> > such limited forms of design-by-contract-like
On 11/15/06, Bill Janssen <[EMAIL PROTECTED]> wrote:
> > Fredrik Lundh wrote:
> >
> > > George Sakkis wrote:
> > >
> > > > 1) why having a "generic operation" len() that ends up looking for an
> > > > ugly special *method*
Fredrik Lundh wrote:
> > Thank you for your explanation; I'd rather read this in the FAQ rather than
> > a
> > moot comparison with Java's inconsistent design.
>
> if you have comments on the FAQ entries, post them over there.
>
> note that the FAQ entry isn't about len(), though; it's about gen
Michael Urman wrote:
> On 11/15/06, George Sakkis wrote:
> > Why not require len() as a method instead and forget about __len__ ?
> > Does len() (the function) do anything smarter behind the scenes than
> > just passing the ball to __len__ ? That could justify its role but
On 11/15/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> As far as the 'flexible iterator' idea goes, I've had a rough implementation
> of such a beast sitting on my hard drive for the last year and a half (since
> shortly after that January '05 thread I linked to earlier in this discussion).
> My c
On 11/15/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> George Sakkis wrote:
> > Fredrik Lundh wrote:
> >
> >> George Sakkis wrote:
> >>
> >>> 1) why having a "generic operation" len() that ends up looking for an
> >&g
Fredrik Lundh wrote:
> George Sakkis wrote:
>
> > 1) why having a "generic operation" len() that ends up looking for an
> > ugly special *method* called __len__() makes sense, while calling
> > directly a method len() doesn't
>
> for the very
Fredrik Lundh wrote:
> George Sakkis wrote:
>
> > I won't open another can of worms here, but I'll just say that as much
> > as I hate Java's stubborn insistence on OO purity, I am equally
> > disturbed by Python's arbitrary-looking choices on wheth
On 11/14/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> George Sakkis wrote:
>
> > I think I do, though I can't tell the same about the reasons of your
> > objections to it.
>
> Perhaps I can fill in some of the things that Guido
> is not explicitly sayin
On 11/14/06, Mike Klaas <[EMAIL PROTECTED]> wrote:
> On 11/14/06, George Sakkis <[EMAIL PROTECTED]> wrote:
> > On 11/14/06, Mike Klaas <[EMAIL PROTECTED]> wrote:
>
> > > I don't see the problem of importing important language functionality.
> >
On 11/14/06, Mike Klaas <[EMAIL PROTECTED]> wrote:
> On 11/14/06, George Sakkis <[EMAIL PROTECTED]> wrote:
>
> > And for those objecting to touching the existing iter() or bloating
> > the builtin namespace with yet another builtin, let me mention that we
>
On 11/14/06, George Sakkis <[EMAIL PROTECTED]> wrote:
> On 11/14/06, Jim Jewett <[EMAIL PROTECTED]> wrote:
> > (3) IterMixin would be the only mixin exposed as a builtin -- the
> > other mixins must be imported. The builtin type factories are
> > typically the
On 11/14/06, Fred L. Drake, Jr. <[EMAIL PROTECTED]> wrote:
> On Tuesday 14 November 2006 13:06, George Sakkis wrote:
> > I understand you are exaggerating (can't believe you are seriously
> > claiming that cmath or traceback are more frequently used than
> >
On 11/14/06, Jim Jewett <[EMAIL PROTECTED]> wrote:
> Yes, and at first glance, an IterMixin would be nice. But only at first
> glance.
>
> (1) Things that are already iterators won't implement the entire
> newly expanded iteration API. I don't want people to start
> mechanically replacing
>
>
On 11/14/06, Fredrik Lundh wrote:
> Uhuh. And why would this more important than adding, say, Array,
> AtExit, Bz2, Cgi, CgiTB, Cmath, Code, Codecs, Collections, Copy, Csv,
> DateTime, Decimal, ElementTree, ErrNo, Ftplib, Gc, GetOpt, GetText,
> Glob, Gzip, HashLib, HMac, Inspect, Locale, Logging
On 11/14/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
>
> "George Sakkis" <[EMAIL PROTECTED]> wrote:
> >
> > On 11/14/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> >
> > > George Sakkis wrote:
> > > > On 11/14/06, Fredri
On 11/14/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> George Sakkis wrote:
> > Understood. Any _technical_ reasons then why shouldn't all iterators
> > inherit from it, or "duck typing is The Right Way" should be taken as
> > an axiom ? Why do we s
On 11/14/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> BJ?rn Lindqvist wrote:
>
> > But why is both the dict and list protocol so fat then? Is it hard to
> > create your own dict or list-derived types in Python?
>
> don't confuse things like lists and dictionaries with things like
> sequences and
On 11/14/06, Aahz <[EMAIL PROTECTED]> wrote:
> [off-list to avoid more CLUTTER]
Sorry, I don't consider a well-intentioned discussion to understand
how things work at the design level of python CLUTTER.
> On Mon, Nov 13, 2006, George Sakkis wrote:
> >
> > Excuse my
On 11/14/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> George Sakkis wrote:
> > On 11/14/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> >
> >> BJ?rn Lindqvist wrote:
> >>
> >>> But why is both the dict and list protocol so fat then? Is it
On 11/13/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 11/13/06, George Sakkis <[EMAIL PROTECTED]> wrote:
> > On 11/13/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> >
> > > As my final word, I think this is a seriously bad idea, and as you'
On 11/13/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 11/13/06, George Sakkis <[EMAIL PROTECTED]> wrote:
> > I honestly fail to understand your current objections. Is my analogy
> > with dictmixin flawed ? Would anything change if I named it
> > "it
On 11/14/06, Ronald Oussoren <[EMAIL PROTECTED]> wrote:
>
> On 14 Nov 2006, at 4:26 AM, George Sakkis wrote:
>
> >
> > I honestly fail to understand your current objections. Is my analogy
> > with dictmixin flawed ? Would anything change if I named it
> > &q
On 11/13/06, Brian Harring <[EMAIL PROTECTED]> wrote:
> Tend to think __getitem__ on base iter is a rather bad idea due to the
> fact it implies the underlying iter is a mapping; it's not.
Only mappings define __getitem__ ?!? Now that's a new one.
> Additionally... islice *does* have issues when
On 11/13/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> As my final word, I think this is a seriously bad idea, and as you're
> not answering my challenge about duck typing I don't think you
> understand your own proposal.
I think I do, though I can't tell the same about the reasons of your
ob
nge.
> On 11/13/06, George Sakkis <[EMAIL PROTECTED]> wrote:
> > On 11/13/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> >
> > > Hm. Without knowing much of the background, this appears to be a
> > > worrysome trend away from duck typing. Why would
/or syntax instead of imported functions, the parallel
becomes apparent.
George
> On 11/13/06, George Sakkis <[EMAIL PROTECTED]> wrote:
> > Following up on a recent c.l.py thread
> > (http://groups.google.com/group/comp.lang.python/browse_frm/thread/42818717b400bcd4/#),
>
Following up on a recent c.l.py thread
(http://groups.google.com/group/comp.lang.python/browse_frm/thread/42818717b400bcd4/#),
I'd like to get an idea from python-dev folks on how much of a chance
is there for a builtin iterator type. Although there might be a slight
possibility to make this propos
49 matches
Mail list logo
