469,291 Members | 1,767 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,291 developers. It's quick & easy.

Arithmetic sequences in Python

Please visit http://www.python.org/peps/pep-0204.html first.

As you can see, PEP 204 was rejected, mostly because of not-so-obvious
syntax. But IMO the idea behind this pep is very nice. So, maybe
there's a reason to adopt slightly modified Haskell's syntax? Something
like

[1,3..10] --> [1,3,5,7,9]
(1,3..10) --> same values as above, but return generator instead of
list
[1..10] --> [1,2,3,4,5,6,7,8,9,10]
(1 ..) --> 'infinite' generator that yield 1,2,3 and so on
(-3,-5 ..) --> 'infinite' generator that yield -3,-5,-7 and so on

So,
1) "[]" means list, "()" means generator
2) the "start" is required, "step" and "end" are optional.

Also, this can be nicely integrated with enumerations (if they will
appear in python). Haskell is also example of such integration.

Jan 16 '06
72 5108
al***@mail.comcast.net (Alex Martelli) writes:
Well, [...] notation for regular lists (as opposed to list
comprehensions) is also unnecessary since we could use "list((a,b,c))".
Indeed, there's no reason list couldn't accept multiple arguments as an
alternative to one sequence argument, just like min and max. This would
make list(a, b, c) work just perfectly.


What should the output of "print list(1,2,3)" be? Is there a really
good reason to make it different from the input syntax?

What should list(list(1,2,3)) be? Should "list" really work
completely differently depending on whether it has a single arg or
multiple args?

How would you make a one-element list, which we'd currently write as [3]?
Would you have to say list((3,))?
I see no credibly simple and readable alternative to {a:b, c:d}
dictionary display syntax, for example; dict(((a,b),(c,d))) just
wouldn't cut it, because of the "parentheses overload" (double
entendre intended).
dict(a=b,c=d)

I don't really see why keyword arg names have to be identifiers
either. foo(3=4) can pass a **kwargs containing {3:4}.
But list has no such problem, and there's really no added value of
clarity and readability in [a,b,c] vs list(a,b,c).
That's subjective at best. Even Scheme doesn't make you use
extra keywords to write something as fundamental as a list. ;-)
So the only reason they may "suggest lists" is that you're used to
that display form in Python, but there's no real reason to HAVE a
display form for lists at all, IMHO.


Well, what's supposed to happen when you print a list then?
Jan 19 '06 #51
Paul Rubin <http://ph****@NOSPAM.invalid> wrote:
...
What should the output of "print list(1,2,3)" be? Is there a really
good reason to make it different from the input syntax?
If we assume that str and repr must keep coinciding for lists (and why
not), no reason -- just like, say, today:
print set([1,2,3])
set([1, 2, 3])

input and output could be identical. Do YOU have any good reason why
sets should print out as set(...) and lists should NOT print out as
list(...)? Is 'list' somehow "deeper" than 'set', to deserve a special
display-form syntax which 'set' doesn't get? Or are you enshrining a
historical accident to the level of an erroneously assumed principle?
What should list(list(1,2,3)) be? Should "list" really work
completely differently depending on whether it has a single arg or
multiple args?
It works just fine for max and min, why should list be different?
How would you make a one-element list, which we'd currently write as [3]?
Would you have to say list((3,))?


Yep. I don't particularly like the "mandatory trailing comma" in the
tuple's display form, mind you, but, if it's good enough for tuples, and
good enough for sets (how else would you make a one-element set?), it's
good enough for lists too. If we can find a nicer singleton-form, let's
apply it uniformly to all genexps, and list(<niceform>) will be fine!-)

I see no credibly simple and readable alternative to {a:b, c:d}
dictionary display syntax, for example; dict(((a,b),(c,d))) just
wouldn't cut it, because of the "parentheses overload" (double
entendre intended).


dict(a=b,c=d)

I don't really see why keyword arg names have to be identifiers
either. foo(3=4) can pass a **kwargs containing {3:4}.


I much prefer the current arrangement where dict(a=b,c=d) means {'a':b,
'c':d} -- it's much more congruent to how named arguments work for every
other case. Would you force us to quote argument names in EVERY
functioncall...?!

But list has no such problem, and there's really no added value of
clarity and readability in [a,b,c] vs list(a,b,c).


That's subjective at best. Even Scheme doesn't make you use
extra keywords to write something as fundamental as a list. ;-)


In Python, a list is no more fundamental than a dict or a set (in maths,
I guess a set IS more fundamental, of course, but Python's not
necessarily congruent to maths). Only tuples deserve special treatment
on semantical grounds (as they're used to pass multiple arguments to
functions or return multiple values for function). Of course "it's
subjective" -- obviously, some people prize conciseness above everything
else (otherwise APL and its successors would have been stillborn),
others prize verbosity (or else Cobol would never have been coinceived);
but Python's "Middle Way" tends to strike a good balance. IMHO, the
balance would be better served by spelling list(1,2,3) rather than
[1,2,3] (but the BDFL disagrees, so my opinion doesn't matter much).

So the only reason they may "suggest lists" is that you're used to
that display form in Python, but there's no real reason to HAVE a
display form for lists at all, IMHO.


Well, what's supposed to happen when you print a list then?


Just the same as when you print a set: <typename>(<args>).
Alex
Jan 19 '06 #52
Op 2006-01-19, Alex Martelli schreef <al***@mail.comcast.net>:
What should list(list(1,2,3)) be? Should "list" really work
completely differently depending on whether it has a single arg or
multiple args?


It works just fine for max and min, why should list be different?


Well IMO it works fine for max and min because people rarely want
the minimum or maximum over a sequence of tuples or lists.

But how would you make the following list: [(1,3)]

As far as I understand that would have to become:

list(((1,3),))

And [[3]] would have to become:

list((list((3,)),))
In my opinion the bracket notation wins the clarity contest
handsdown in this case and IMO these cases occure frequently
enough.

--
Antoon Pardon
Jan 19 '06 #53
Antoon Pardon <ap*****@forel.vub.ac.be> writes:
And [[3]] would have to become:
list((list((3,)),))
In my opinion the bracket notation wins the clarity contest
handsdown in this case and IMO these cases occure frequently
enough.


I'm convinced now. Until that, I could have gone either way.
Jan 19 '06 #54
Alex Martelli wrote:
I much prefer the current arrangement where dict(a=b,c=d) means {'a':b,
'c':d} -- it's much more congruent to how named arguments work for every
other case. Would you force us to quote argument names in EVERY
functioncall...?!

Hmmm... should these two forms give different results?
a = 0
b = 1
A = {a: b}
B = dict(a=b)
A, B

({0: 1}, {'a': 1})

I feel very uncomfortable about that. Am I alone?
--
Steven.

Jan 19 '06 #55
Steven D'Aprano wrote:
I much prefer the current arrangement where dict(a=b,c=d) means {'a':b,
'c':d} -- it's much more congruent to how named arguments work for every
other case. Would you force us to quote argument names in EVERY
functioncall...?!


Hmmm... should these two forms give different results?
>>> a = 0
>>> b = 1
>>> A = {a: b}
>>> B = dict(a=b)
>>> A, B

({0: 1}, {'a': 1})

I feel very uncomfortable about that. Am I alone?


yes.

</F>

Jan 19 '06 #56
Paul Rubin wrote:
al***@mail.comcast.net (Alex Martelli) writes:
I see no credibly simple and readable alternative to {a:b, c:d}
dictionary display syntax, for example; dict(((a,b),(c,d))) just
wouldn't cut it, because of the "parentheses overload" (double
entendre intended).

dict(a=b,c=d)

I don't really see why keyword arg names have to be identifiers
either. foo(3=4) can pass a **kwargs containing {3:4}.


The keywords need to be parseable; what would be the keyword form of
{ '3=4, 5=' : 6 }
or
{ '3=4); print "gotcha"; dict(6=' : 7 }
?

Kent
Jan 19 '06 #57
Alex Martelli wrote:
Do YOU have any good reason why
sets should print out as set(...) and lists should NOT print out as
list(...)? Is 'list' somehow "deeper" than 'set', to deserve a special
display-form syntax which 'set' doesn't get? Or are you enshrining a
historical accident to the level of an erroneously assumed principle?


(I haven't been following this thread much, so I can't tell if you're
actually arguing for this change, or that you are just playing devil's
advocate...)

I would have liked to say that lists are a fundamental data type, much
more so than a set... but in reality that seems to be a matter of taste
and priorities. Pascal, for example, has a set literal, but no list
literal; in fact, it doesn't even have a built-in list type.

--
Hans Nowak
http://zephyrfalcon.org/
Jan 19 '06 #58
Steven D'Aprano wrote:
Steven Bethard wrote:
I'm not sure I find it truly hateful, but definitely unnecessary.
TOOWTDI and all...

[snip]
Even when people mean One Obvious and not Only One, it is still harmful
because the emphasis is wrong. The emphasis is on the *restrictive
nature* of a language which merely gives one obvious way of doing things.


Perhaps just the *perceived* emphasis is wrong? Let me elaborate...

My intent was only to indicate that I don't think we *gain* anything by
having two forms that are quite similar both syntactically and
semantically. Both [...] and list(...) use exactly the same syntax for
the inner expression[1]. Both use parentheses/brackets, so the inner
expression can be broken across multiple lines in the same ways. Both
produce the same result, a list created in the appropriate manner.

So why have both? That's all I meant by TOOWTDI.

FWIW, I've posted my arguments for removing the redundant [...]
expression in Python 3.0 at:

http://wiki.python.org/moin/Python3%...stions#preview

STeVe

[1] Reminder: I'm *not* arguing for list literals to look like
list(...), only for list comprehensions to look that way.
Jan 19 '06 #59
How about this hack:
import types
class lazy_range(object): .... def __getitem__(self, l):
.... start = l[0]
....
.... if isinstance(l[1], types.EllipsisType):
.... step = 1
.... if len(l) > 2:
.... stop = l[2]
.... else:
.... stop = None
.... else:
.... step = l[1] - l[0]
.... if len(l) > 3:
.... stop = l[3]
.... else:
.... stop = None
....
.... for i in xrange(start, stop+1, step):
.... yield i
l = lazy_range()
print [i for i in l[1,3,...,10]] [1, 3, 5, 7, 9] print [i for i in l[1,...,10]]

[1, 2, 3, 4, 5, 6, 7, 8, 9, 10]

Jan 19 '06 #60
al***@mail.comcast.net (Alex Martelli) writes:
I much prefer the current arrangement where dict(a=b,c=d) means {'a':b,
'c':d} -- it's much more congruent to how named arguments work for every
other case. Would you force us to quote argument names in EVERY
functioncall...?!


Ehh, ok. There could be some special marker to evaluate the lhs, but
the present method is fine too.
Jan 20 '06 #61
al***@mail.comcast.net (Alex Martelli) writes:
How would you make a one-element list, which we'd currently write as [3]?
Would you have to say list((3,))?


Yep. I don't particularly like the "mandatory trailing comma" in the
tuple's display form, mind you, but, if it's good enough for tuples, and
good enough for sets (how else would you make a one-element set?),


If you really want to get rid of container literals, maybe the best
way is with constructor functions whose interfaces are slightly
different from the existing type-coercion functions:

listx(1,2,3) => [1, 2, 3]
listx(3) => [3]
listx(listx(3)) => [[3]]
dictx((a,b), (c,d)) => {a:b, c:d}
setx(a,b,c) => Set((a,b,c))

listx/dictx/setx would be the display forms as well as the constructor forms.
Jan 20 '06 #62
On Fri, 20 Jan 2006, it was written:
al***@mail.comcast.net (Alex Martelli) writes:
How would you make a one-element list, which we'd currently write as
[3]? Would you have to say list((3,))?


Yep. I don't particularly like the "mandatory trailing comma" in the
tuple's display form, mind you, but, if it's good enough for tuples,
and good enough for sets (how else would you make a one-element set?),


If you really want to get rid of container literals, maybe the best way
is with constructor functions whose interfaces are slightly different
from the existing type-coercion functions:

listx(1,2,3) => [1, 2, 3]
listx(3) => [3]
listx(listx(3)) => [[3]]
dictx((a,b), (c,d)) => {a:b, c:d}
setx(a,b,c) => Set((a,b,c))

listx/dictx/setx would be the display forms as well as the constructor forms.


Could these even replace the current forms? If you want the equivalent of
list(sometuple), write list(*sometuple). With a bit of cleverness down in
the worky bits, this could be implemented to avoid the apparent overhead
of unpacking and then repacking the tuple. In fact, in general, it would
be nice if code like:

def f(*args):
fondle(args)

foo = (1, 2, 3)
f(*foo)

Would avoid the unpack/repack.

The problem is that you then can't easily do something like:

mytable = ((1, 2, 3), ("a", "b", "c"), (Tone.do, Tone.re, Tone.mi))
mysecondtable = map(list, mytable)

Although that's moderately easy to work around with possibly the most
abstract higher-order-function i've ever written:

def star(f):
def starred_f(args):
return f(*args)
return starred_f

Which lets us write:

mysecondtable = map(star(list), mytable)

While we're here, we should also have the natural complement of star, its
evil mirror universe twin:

def bearded_star(f):
def bearded_starred_f(*args):
return f(args)
return bearded_starred_f

Better names (eg "unpacking" and "packing") would obviously be needed.

tom

--
I might feel irresponsible if you couldn't go almost anywhere and see
naked, aggressive political maneuvers in iteration, marinating in your
ideology of choice. That's simply not the case. -- Tycho Brahae
Jan 21 '06 #63
Tom Anderson <tw**@urchin.earth.li> writes:
listx/dictx/setx would be the display forms as well as the constructor forms.


Could these even replace the current forms? If you want the equivalent
of list(sometuple), write list(*sometuple).


The current list function is supposed to be something like a typecast:

list() = []
xlist() = [] # ok

list(list()) = [] # casting a list to a list does nothing
xlist(xlist()) = [[]] # make a new list, not the same

list(xrange(4)) = [0,1,2,3]
xlist(xrange(4)) = [xrange(4)] # not the same

list((1,2)) = [1,2]
xlist((1,2)) = [(1,2)]

etc.
Jan 21 '06 #64
On Sat, 21 Jan 2006, it was written:
Tom Anderson <tw**@urchin.earth.li> writes:
listx/dictx/setx would be the display forms as well as the constructor
forms.
Could these even replace the current forms? If you want the equivalent
of list(sometuple), write list(*sometuple).


The current list function is supposed to be something like a typecast:


A what?

;-|
list() = []
xlist() = [] # ok

list(list()) = [] # casting a list to a list does nothing
xlist(xlist()) = [[]] # make a new list, not the same

list(xrange(4)) = [0,1,2,3]
xlist(xrange(4)) = [xrange(4)] # not the same

list((1,2)) = [1,2]
xlist((1,2)) = [(1,2)]


True, but so what? Is it that it has to be that way, or is it just that it
happens to be that way now?

tom

--
It's the 21st century, man - we rue _minutes_. -- Benjamin Rosenbaum
Jan 21 '06 #65
Paul Rubin wrote:
Tom Anderson <tw**@urchin.earth.li> writes:
listx/dictx/setx would be the display forms as well as the constructor forms.
Could these even replace the current forms? If you want the equivalent
of list(sometuple), write list(*sometuple).

The current list function is supposed to be something like a typecast:

list() isn't a function, it's a type.
type(list)

<type 'type'>

I'm not happy about the way the documentation represents types as
functions, as this obscures the whole essence of Python's object
orientation.

list() = []
xlist() = [] # ok

list(list()) = [] # casting a list to a list does nothing
xlist(xlist()) = [[]] # make a new list, not the same

list(xrange(4)) = [0,1,2,3]
xlist(xrange(4)) = [xrange(4)] # not the same

list((1,2)) = [1,2]
xlist((1,2)) = [(1,2)]

etc.


I presume that here "=" means "evaluates to"?

regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC www.holdenweb.com
PyCon TX 2006 www.python.org/pycon/

Jan 22 '06 #66
Alex Martelli wrote:
print set([1,2,3])

set([1, 2, 3])

input and output could be identical. Do YOU have any good reason why
sets should print out as set(...) and lists should NOT print out as
list(...)? Is 'list' somehow "deeper" than 'set', to deserve a special
display-form syntax which 'set' doesn't get? Or are you enshrining a
historical accident to the level of an erroneously assumed principle?


These are valid points, but they lead me to the opposite conclusion: Why
not let {a,b,c} stand for set([a,b,c])? That would be very intuitive
since it is the mathematical notation already and since it resembles the
notation of dictionaries which are similar to sets.

(This has been probably discussed already. One problem I'm already
seeing is that {} would be ambiguous.)

Anyway, I think the fact that the notation for a set is clumsy is no
good reason to make the notation for a list clumsy as well.

-- Christoph
Jan 23 '06 #67
Steve Holden <st***@holdenweb.com> writes:
The current list function is supposed to be something like a
typecast:

list() isn't a function, it's a type.


I'm not sure what the distinction is supposed to be. "list" is anyway
callable, and lambda a:list(a) is certainly a function.
xlist((1,2)) = [(1,2)]
etc.


I presume that here "=" means "evaluates to"?


Yeah, although I meant something more informal, like mathematical
equivalence.

Maybe the preferred spellings for the constructors would use capital
letters: List, Dict, Set, instead of listx or xlist or whatever. That
would break the current meaning of Set but I hope not much depends on
that yet.
Jan 23 '06 #68
Paul Rubin <http://ph****@NOSPAM.invalid> wrote:
Steve Holden <st***@holdenweb.com> writes:
The current list function is supposed to be something like a
typecast:

list() isn't a function, it's a type.


I'm not sure what the distinction is supposed to be. "list" is anyway


You can subclass a type, you can check for it with isinstance, etc, all
things you couldn't do if list was still a factory function as in 2.1
and back.
Alex
Jan 23 '06 #69
Christoph Zwerschke <ci**@online.de> wrote:
...
These are valid points, but they lead me to the opposite conclusion: Why
not let {a,b,c} stand for set([a,b,c])? That would be very intuitive
As syntax sugar goes, that would be on a par with the current "dict
display" notation, at least.
(This has been probably discussed already. One problem I'm already
seeing is that {} would be ambiguous.)
Yep, using {} for both sets and dicts wouldn't be a good idea. I
suspect most core Python developers think of dicts as more fundamental
than sets, so... (I may disagree, but I just don't care enough about
such syntax sugar to consider even starting a debate about it on
python-dev, particularly knowing it would fail anyway).
Anyway, I think the fact that the notation for a set is clumsy is no
good reason to make the notation for a list clumsy as well.


I don't agree that <typename>(<arguments>) is a clumsy notation, in
general; rather, I consider "clumsy" much of the syntax sugar that is
traditional in Python. For example, making a shallow copy of a list L
with L[:] is what strikes me as clumsy -- list(L) is SO much better.
And I vastly prefer dict(a=1,b=2) over the clumsy {'a':1, 'b':2}.

I suspect I'm unusual in that being deeply familiar with some notation
and perfectly used to it does NOT necessarily make me LIKE that
notation, nor does it make me any less disposed to critical reappraisal
of it -- the brains of most people do appear to equate habit with
appreciation. In the light of my continuous and unceasing critical
reappraisal of Python's syntax choices, I am quite convinced that many
of them are really brilliant -- with the "display forms" of some
built-in types being one area where I find an unusually high density of
non-brilliance, AKA clumsiness. But, that's just me.
Alex
Jan 23 '06 #70
Alex Martelli wrote:
Yep, using {} for both sets and dicts wouldn't be a good idea. I
suspect most core Python developers think of dicts as more fundamental
than sets, so... (I may disagree, but I just don't care enough about
such syntax sugar to consider even starting a debate about it on
python-dev, particularly knowing it would fail anyway).
I'm still not convinced. At least I'd prefer {a,b,c} over any other
proposed solutions (http://wiki.python.org/moin/Python3%2e0Suggestions)
such as <a,b,c> or |a,b,c|.

You can argue that the notation for sets can be clumsy because they
aren't used so much as lists or dicts, but you can also argue the other
way around that sets aren't used much because the notation is clumsy
(and because they didn't exist from the beginning).

For instance, if sets had a simple notation, they could be used in more
cases, e.g. replace integer masks (see again
http://wiki.python.org/moin/Python3%2e0Suggestions):

pat = re.compile("some pattern", re.I|re.S|re.X)
would become
pat = re.compile("some pattern", {re.I, re.S, re.X})
I don't agree that <typename>(<arguments>) is a clumsy notation, in
general; rather, I consider "clumsy" much of the syntax sugar that is
traditional in Python.
If you really could write list(a,b,c) instead of list((a,b,c)) I do
somewhat agree.
For example, making a shallow copy of a list L
with L[:] is what strikes me as clumsy -- list(L) is SO much better.
Certainly.
And I vastly prefer dict(a=1,b=2) over the clumsy {'a':1, 'b':2}.
Ok, but only as long as you have decent keys...
I suspect I'm unusual in that being deeply familiar with some notation
and perfectly used to it does NOT necessarily make me LIKE that
notation, nor does it make me any less disposed to critical reappraisal
of it -- the brains of most people do appear to equate habit with
appreciation. In the light of my continuous and unceasing critical
reappraisal of Python's syntax choices, I am quite convinced that many
of them are really brilliant -- with the "display forms" of some
built-in types being one area where I find an unusually high density of
non-brilliance, AKA clumsiness. But, that's just me.


Ordinary people are lazy. If we have learned something and got
accustomed to it, we don't want to relearn. It is inconvenient. And
there is this attitude: "If I had so much trouble learning a clumsy
notation, why should future generations have it easier."

And in programming languages, you also have the downward compatibility
problem. Having to change all your old programs makes people even more
dislike any thoughts about changes...

-- Christoph
Jan 23 '06 #71
On Sun, 22 Jan 2006 16:40:48 -0800, Paul Rubin wrote:
Steve Holden <st***@holdenweb.com> writes:
> The current list function is supposed to be something like a
> typecast:
>

list() isn't a function, it's a type.


I'm not sure what the distinction is supposed to be. "list" is anyway
callable, and lambda a:list(a) is certainly a function.

class Parrot:
def __init__(self):
pass

Parrot is callable. Is it a function?
Types are types, classes are classes, functions are functions.

Admittedly I still confused between the various flavours of functions
(function, bound method, unbound method, class method, static method...)
*wink* but the difference between types and functions is fairly clear.

Just don't ask about the difference between type and class... *wink*

--
Steven.

Jan 23 '06 #72
On Mon, 23 Jan 2006 21:43:16 +1100, Steven D'Aprano <st***@REMOVETHIScyber.com.au> wrote:
On Sun, 22 Jan 2006 16:40:48 -0800, Paul Rubin wrote:
Steve Holden <st***@holdenweb.com> writes:
> The current list function is supposed to be something like a
> typecast:
>
list() isn't a function, it's a type.
I'm not sure what the distinction is supposed to be. "list" is anyway
callable, and lambda a:list(a) is certainly a function.

class Parrot:
def __init__(self):
pass

Parrot is callable. Is it a function?

No. It is an object that inherits a __call__ method that makes it callable with a (<args>) source syntax trailer
in a similar way to an object created with a def (which is a function in python convention, and which
also inherits a __call__ method), but the similarity does not make Parrot a function:
class Parrot: ... def __init__(self):
... pass
...
(BTW you could have inherited a do-nothing __init__ ;-)
type(Parrot).mro() [<type 'classobj'>, <type 'object'>] type(Parrot).mro()[0].__call__ <slot wrapper '__call__' of 'classobj' objects>
Or, showing more explicitly where it comes from: type(Parrot).mro()[0].__dict__['__call__'] <slot wrapper '__call__' of 'classobj' objects>

Invoked: type(Parrot).mro()[0].__dict__['__call__'](Parrot) <__main__.Parrot instance at 0x02EF340C>

Hm, actually that is like calling the im_func of the unbound method of a newstyle class ...
I think maybe actually Parrot() causes
type(Parrot).mro()[0].__dict__['__call__'].__get__(Parrot, type(Parrot))() <__main__.Parrot instance at 0x02EF398C>

A function is also an object with a __call__ method. E.g., compare above the line with
calling foo (after definition just below) the long way:
def foo(): return 'returned by foo' ... type(foo).mro()[0].__dict__['__call__'].__get__(foo, type(foo))() 'returned by foo'

Playing with that a little: type(foo).mro() [<type 'function'>, <type 'object'>] type(foo).mro()[0] <type 'function'> type(foo).mro()[0].__call__ <slot wrapper '__call__' of 'function' objects> type(foo).mro()[0].__call__(foo) 'returned by foo' foo.__call__ <method-wrapper object at 0x02EF340C> foo.__call__() 'returned by foo' type(foo).mro()[0].__call__.__get__ <method-wrapper object at 0x02EF340C> type(foo).mro()[0].__call__.__get__(foo, type(foo)) <method-wrapper object at 0x02EF39AC> type(foo).mro()[0].__call__.__get__(foo, type(foo))() 'returned by foo'
or foo()

'returned by foo'

Types are types, classes are classes, functions are functions. classes seem to be classobjs, designed to implement classic class behavior
but using the new machinery to achieve compatible integration.

Admittedly I still confused between the various flavours of functions
(function, bound method, unbound method, class method, static method...)
*wink* but the difference between types and functions is fairly clear.

Just don't ask about the difference between type and class... *wink*

Why not? ;-)

Regards,
Bengt Richter
Jan 24 '06 #73

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

3 posts views Thread by Generic Usenet Account | last post: by
1 post views Thread by mmm | last post: by
1 post views Thread by CARIGAR | last post: by
reply views Thread by zhoujie | last post: by
reply views Thread by suresh191 | last post: by
1 post views Thread by Geralt96 | last post: by
reply views Thread by harlem98 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.