Talin wrote:
> Javascript, for example, doesn't need special syntactical sugar for
> generator expressions:
>
> /* Return a list of the square of numbers.
> ('map' appears courtesy of Mochikit.js) */
>
> result = map( [1, 2, 3, 4], function (a) {
>return a * a;
> })
>
On Thu, Nov 16, 2006 at 01:06:04AM +0200, tomer filiba wrote:
[tomer filiba wrote stuff]
I was hoping this thread would go unremarked but it looks like
it is picking up some steam. So I'll throw in my two bits:
Please for the love of god abandon this thread. It has been done.
You weren't there
From the beat-that-dead-horse department: I've never really been
satisfied with the outcome of the discussion on lambda and anonymous
functions.
As much as I love the use of syntactic indentation in Python, it does
have one serious drawback, which is that it creates a wall between the
realms
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
Fredrik Lundh wrote:
> I'm convinced that it's better for people to get over that silly notion
> that writing x.foo() is somehow always "better" than writing foo(x), in
> a language that actually supports both forms.
>
> (if I'd have to chose between foo(x) and x.foo(), I'd rather get foo(x)
>
tomer filiba wrote:
> here are some usecases to class decorators:
What I would like is a way to use class decorators, combined with
ctypes, to effectively 'declare' a C structure using Python syntax.
Right now you can use ctypes to declare a C struct, but the syntax isn't
very Python-like:
"Steven Bethard" <[EMAIL PROTECTED]> wrote:
> On 11/15/06, tomer filiba <[EMAIL PROTECTED]> wrote:
> > i understand there's a green light for class decorators in py3k,
> > so i wanted to give the issue a slight push.
>
> "Steven Bethard" <[EMAIL PROTECTED]> wrote:
> > FWIW, most of the arguments
On 11/15/06, tomer filiba <[EMAIL PROTECTED]> wrote:
> i understand there's a green light for class decorators in py3k,
> so i wanted to give the issue a slight push.
"Steven Bethard" <[EMAIL PROTECTED]> wrote:
> FWIW, most of the arguments against PEP 359 were along the lines of,
> "well you can
"Steven Bethard" <[EMAIL PROTECTED]> wrote:
> On 11/15/06, tomer filiba <[EMAIL PROTECTED]> wrote:
> > i understand there's a green light for class decorators in py3k,
> > so i wanted to give the issue a slight push.
> FWIW, most of the arguments against PEP 359 were along the lines of,
> "well yo
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 perfectly
> > free to define a method len() in a class that
George Sakkis wrote:
> class Container(object):
>
> class Sequence(Container):
> class Mapping(Container):
>
> Note that this does _not_ disallow duck typing; anyone is perfectly
> free to define a method len() in a class that does not extend any of
> the above so that a client can call x.len() s
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, tomer filiba <[EMAIL PROTECTED]> wrote:
> i understand there's a green light for class decorators in py3k,
> so i wanted to give the issue a slight push.
If you haven't already, you should look at PEP 359, which tried to
address many of the same use-cases and was withdrawn after feedb
i understand there's a green light for class decorators in py3k,
so i wanted to give the issue a slight push.
one problem with metaclasses is they are non-nestable, i.e., a
function can be wrapped by a number of decorators, while
classes can have only one metaclass.
not only that, but metaclasses
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 to define a method len() in a class t
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
> > checking whether len() returns a non-negative integ
"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
> checking whether len() returns a non-negative integer does very little
> to the overall consistency scheme of thing
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 assertions ("why not add
> > a precondition
> > on __add_
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* called __len__() makes sense, while calling
> > > > directly a method len
> 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 reason Mike explained: keeping impl
George Sakkis wrote:
>> (and I completely disagree that Mike's observation is moot: consistency
>> is a fundamental part of Python's design, and mechanisms that helps
>> people keep their code consistent without even noticing is an important
>> part of why things are that way.)
>
> Striving for c
"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 assertions ("why not add
> a precondition
> on __add__(self,other) to enforce isinstance(other, self.__class__)
> ?") whe
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
George Sakkis 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 generic
functions
> Static != non-duck.
> One could imagine static duck typing (is it the same as structural
> typing?) with type inference. I wonder if some existing languages have
> static duck typing (boo? haskell?).
C++ (using templates).
___
Python-3000 mailing lis
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
> > AFAIK it doesn't.
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
> >>> ugly special *method* called __len__() makes sense, while calling
> >>> directl
On 11/15/06, George Sakkis <[EMAIL PROTECTED]> 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
> AFAIK it doesn't.
It most certa
George Sakkis wrote:
> And for those objecting to touching the existing iter() or bloating
> the builtin namespace with yet another builtin, let me mention that we
> can get rid of *two* existing functions which for some reason were
> promoted to builtin status, although they conceptually belong in
George Sakkis wrote:
> 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 reason Mike explained: keep
George Sakkis wrote:
> Fredrik, I am not arguing for the argument's sake, I just don't get
> it: Python requires my class to define __len__, otherwise len() fails.
> Why not require len() as a method instead and forget about __len__ ?
and have people complain about a len/__getitem__ naming incons
> Non-duck typing is a seriously bad idea, forced
> on some other languages by static typing.
Static != non-duck.
One could imagine static duck typing (is it the same as structural
typing?) with type inference. I wonder if some existing languages have
static duck typing (boo? haskell?).
__
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 reason Mike explained: keeping implementation interfa
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 reason Mike explained: keeping implementation interfaces
separate from public interface
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 whether some
> > callable ends up a function or a met
Mike Orr wrote:
> len() here is a unifier: it says "thou shalt do this, .__len__ method,
> or users will be pissed that len() doesn't work on your type".
that's an excellent observation. mind if I borrow it for the related
FAQ entry?
http://tinyurl.com/y6vavp
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 whether some
> callable ends up a function or a method. When I talk about or
> introd
39 matches
Mail list logo
