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 can
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 is the
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().
Agreed.
I
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.
Since you
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
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-ish
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 argument to next()
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 next(iterator,
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 why len()
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 that idea
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 all
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
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__() instead?
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 should
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 it be named
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
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
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)
which
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 thereto support the rarer case of needinga key to
compute a default value. The hook
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
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
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 rarer
[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
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 current
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
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
26 matches
Mail list logo
