On Thu, Mar 02, 2006, Guido van Rossum wrote:
> On 3/2/06, Barry Warsaw <[EMAIL PROTECTED]> wrote:
>> On Thu, 2006-03-02 at 07:26 -0800, Aahz wrote:
>>>
>>> OTOH, my personal style is to always use re.compile() because I can
>>> never remember the order of arguments for re.match()/re.search().
>>
>
> For an example of methods gone horribly wrong, look at Java, where you
> have .length, String.length(), and Collection.size().
> Give me len() any day. I believe Ruby has similar confusing diversity
> for looping (each/forEach).
But Java is plagued with the same disease that hit Modula-3, distru
On 3/2/06, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> On Thu, 2006-03-02 at 07:26 -0800, Aahz wrote:
> > OTOH, my personal style is to always use re.compile() because I can
> > never remember the order of arguments for re.match()/re.search().
>
> Agreed.
I don't have that problem, because the order
On Thu, 2006-03-02 at 07:26 -0800, Aahz wrote:
> On Wed, Mar 01, 2006, Guido van Rossum wrote:
> >
> > Operations with two or more arguments are often better expressed as
> > function calls -- for example, map() and filter() don't make much
> > sense as methods on callables or sequences.
>
> OTOH,
On Wed, Mar 01, 2006, Guido van Rossum wrote:
>
> Operations with two or more arguments are often better expressed as
> function calls -- for example, map() and filter() don't make much
> sense as methods on callables or sequences.
OTOH, my personal style is to always use re.compile() because I ca
Guido van Rossum wrote:
> str.join() is an interesting case...
> Making it a
> string method is arguably the right thing to do, since this operation
> only makes sense for strings.
> The type of such a polymorphic function is easily specified:
> join(sequence[T], T) -> T, where T is a string-
On 3/1/06, Brett Cannon <[EMAIL PROTECTED]> wrote:
> But moving over to more attributes for how we access basic interfaces
> seems great to me.
We shouldn't approach this as "methods good, functions bad" -- nor the
opposite, for that matter.
When all things are equal, I'd much rather do usability
On 2/28/06, Terry Reedy <[EMAIL PROTECTED]> wrote:
>
> "Greg Ewing" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> > And you don't think there are many different
> > types of iterables? You might as well argue
> > that we don't need len() because it "only
> > applies to sequences".
"Greg Ewing" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> And you don't think there are many different
> types of iterables? You might as well argue
> that we don't need len() because it "only
> applies to sequences".
Since you mention it..., many people *have* asked on c.l.p wh
Raymond Hettinger wrote:
> -1 on the silly renaming to __next__ and adding __builtin__.next().
> We have len() because it applies to many different object types.
> In contrast, next() would apply only to iterables.
And you don't think there are many different
types of iterables? You might as well
[Greg Ewing]
> I'd still like to see next(x) / x.__next__() in
> some form in 3.0 for the sake of consistency,
> though.
+1 on modifying next() in Py3.0 to accept the send argument.
-1 on the silly renaming to __next__ and adding __builtin__.next().
We have len() because it applies to many differ
Guido van Rossum wrote:
> On 2/28/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>
> > PEP 342 opted to extend the generator API instead (using "send") and leave
> > the
> > iterator protocol alone for the time being.
>
> One of the main reasons for this was the backwards compatibility
> problems at
On 2/28/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Greg Ewing wrote:
> > Nick Coghlan wrote:
> >
> >> I wouldn't mind seeing one of the early ideas from PEP 340 being
> >> resurrected some day, such that the signature for the special method
> >> was "__next__(self, input)" and for the builtin "n
Greg Ewing wrote:
> Nick Coghlan wrote:
>
>> I wouldn't mind seeing one of the early ideas from PEP 340 being
>> resurrected some day, such that the signature for the special method
>> was "__next__(self, input)" and for the builtin "next(iterator,
>> input=None)"
>
> Aren't we getting an argu
Nick Coghlan wrote:
> I wouldn't mind seeing one of the early ideas from PEP 340 being resurrected
> some day, such that the signature for the special method was "__next__(self,
> input)" and for the builtin "next(iterator, input=None)"
Aren't we getting an argument to next() anyway?
Or was tha
On 2/27/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> I wouldn't mind seeing one of the early ideas from PEP 340 being resurrected
> some day, such that the signature for the special method was "__next__(self,
> input)" and for the builtin "next(iterator, input=None)"
>
> That would go hand in hand
Greg Ewing wrote:
> Raymond Hettinger wrote:
>> Code that
>> uses next() is more understandable, friendly, and readable without the
>> walls of underscores.
>
> There wouldn't be any walls of underscores, because
>
>y = x.next()
>
> would become
>
>y = next(x)
>
> The only time you w
FWIW this has now been checked in. Enjoy!
--Guido
On 2/23/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 2/22/06, Michael Chermside <[EMAIL PROTECTED]> wrote:
> > A minor related point about on_missing():
> >
> > Haven't we learned from regrets over the .next() method of iterators
> > that
Raymond Hettinger wrote:
> Code that
> uses next() is more understandable, friendly, and readable without the
> walls of underscores.
There wouldn't be any walls of underscores, because
y = x.next()
would become
y = next(x)
The only time you would need to write underscores is
when defi
On 2/24/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> > Michael Chermside wrote:
> >> The next() method of iterators was an interesting
> >> object lesson. ... Since it was sometimes invoked by name
> >> and sometimes by special mechanism, the choice was to use the
> >> unadorned name, but lat
> Michael Chermside wrote:
>> The next() method of iterators was an interesting
>> object lesson. ... Since it was sometimes invoked by name
>> and sometimes by special mechanism, the choice was to use the
>> unadorned name, but later experience showed that it would have been
>> better the other wa
Thomas Wouters wrote:
> __methods__ are methods that should only be
> called 'magically', or by the object itself.
> 'next' has quite a few usecases where it's
> desireable to call it directly
That's why the proposal to replace .next() with
.__next__() comes along with a function next(obj)
whic
Michael Chermside wrote:
> The next() method of iterators was an interesting
> object lesson. ... Since it was sometimes invoked by name
> and sometimes by special mechanism, the choice was to use the
> unadorned name, but later experience showed that it would have been
> better the other way.
Any
Walter Dörwald writes:
> I always thought that __magic__ method calls are done by Python on
> objects it doesn't know about. The special method name ensures that it
> is indeed the protocol Python is talking about, not some random method
> (with next() being the exception). In the defaultdict case
Guido van Rossum wrote:
> On 2/22/06, Michael Chermside <[EMAIL PROTECTED]> wrote:
>> A minor related point about on_missing():
>>
>> Haven't we learned from regrets over the .next() method of iterators
>> that all "magically" invoked methods should be named using the __xxx__
>> pattern? Shouldn't
On Wed, Feb 22, 2006 at 01:13:28PM -0800, Michael Chermside wrote:
> Haven't we learned from regrets over the .next() method of iterators
> that all "magically" invoked methods should be named using the __xxx__
> pattern? Shouldn't it be named __on_missing__() instead?
I agree that on_missing sho
On 2/22/06, Michael Chermside <[EMAIL PROTECTED]> wrote:
> A minor related point about on_missing():
>
> Haven't we learned from regrets over the .next() method of iterators
> that all "magically" invoked methods should be named using the __xxx__
> pattern? Shouldn't it be named __on_missing__() in
A minor related point about on_missing():
Haven't we learned from regrets over the .next() method of iterators
that all "magically" invoked methods should be named using the __xxx__
pattern? Shouldn't it be named __on_missing__() instead?
-- Michael Chermside
Guido van Rossen wrote:
> I think the pattern hasn't been commonly known; people have been
> struggling with setdefault() all these years.
I use setdefault _only_ to speed up the following code pattern:
if akey not in somedict:
somedict[akey] = list()
somedict[akey].append(avalue)
These lin
On 2/22/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> [Guido van Rossum"]
> > If we removed on_missing() from dict, we'd have to override
> > __getitem__ in defaultdict (regardless of whether we give
> >defaultdict an on_missing() hook or in-line it).
>
> You have another option. Keep your cu
[Guido van Rossum"]
> If we removed on_missing() from dict, we'd have to override
> __getitem__ in defaultdict (regardless of whether we give
>defaultdict an on_missing() hook or in-line it).
You have another option. Keep your current modifications to
dict.__getitem__ but do not include dict.on_m
On 2/22/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> I'm concerned that the on_missing() part of the proposal is gratuitous. The
> main use cases for defaultdict have a simple factory that supplies a zero,
> empty list, or empty set. The on_missing() hook is only there to support
> the rare
Raymond Hettinger wrote:
> I'm concerned that the on_missing() part of the proposal is gratuitous.
I second all that. A clear case of YAGNI.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
U
Raymond Hettinger wrote:
> Aside: Why on_missing() is an oddball among dict methods. When
> teaching dicts to beginner, all the methods are easily explainable ex-
> cept this one. You don't call this method directly, you only use it
> when subclassing, you have to override it to do anything use
I'm concerned that the on_missing() part of the
proposal is gratuitous. The main use cases for defaultdict have a simple
factory that supplies a zero, empty list, or empty set. The on_missing()
hook is only there to support the rarer case of needing a key to
compute a default value. The h
35 matches
Mail list logo
