Arithmetic sequences in Python

[Gregory Petrosyan]

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.

[Christoph Zwerschke]

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("som e pattern", re.I|re.S|re.X)
would become
pat = re.compile("som e pattern", {re.I, re.S, re.X})
I don't agree that <typename>(<arg uments>) 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

[Steven D'Aprano]

On Sun, 22 Jan 2006 16:40:48 -0800, Paul Rubin wrote:

Steve Holden <st***@holdenwe b.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.

[Bengt Richter]

On Mon, 23 Jan 2006 21:43:16 +1100, Steven D'Aprano <st***@REMOVETH IScyber.com.au> wrote:

On Sun, 22 Jan 2006 16:40:48 -0800, Paul Rubin wrote:

Steve Holden <st***@holdenwe b.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).mr o() [<type 'classobj'>, <type 'object'>] type(Parrot).mr o()[0].__call__ <slot wrapper '__call__' of 'classobj' objects>
Or, showing more explicitly where it comes from: type(Parrot).mr o()[0].__dict__['__call__'] <slot wrapper '__call__' of 'classobj' objects>

Invoked: type(Parrot).mr o()[0].__dict__['__call__'](Parrot) <__main__.Parro t 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).mr o()[0].__dict__['__call__'].__get__(Parrot , type(Parrot))() <__main__.Parro t 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