Some notes

[bearophile]

This is my first post here, I hope this is the right place to talk
about such things. I have few comments and notes on the Python
language. I've just started to learn it; this is negative because I'm
ignorant still, but it's also positive because I can still see details
that later probably I'll start to ignore.

Some of the functions of IPython seem good and simple, and I think
some of them can be integrated into the main Python line.

There are lots of different ways to make GUIs for Python programs, I
think that Gui4Cli (http://users.hol.gr/~dck/g4c/) is nice, and it can
be interesting to see it more integrated with Python. At the moment
there is only this interface, but it's not good:
http://users.hol.gr/~dck/g4c/dll/python.htm

Is Python3000 going to come eventually? It will break a lot of
compatibility, so it will be the right moment to change/fix other
things too. Here are some ideas (probably there are errors, but I hope
to learn from my mistakes):

- TABs can be accepted only inside comments.

- The optional static typing seems a quite nice thing (for compilers
too, they can produce faster code. It can probably allow faster and
smaller arrays, like those of numarray).

- The functional IF seems interesting, like:
if(cond, code1, code2)
(Or maybe a different syntax, that allows elseif too.)

- Functions containing yield can be defined in a different way, like:
generator name(params)
<code>
This idea comes from David Mertz:
http://www-106.ibm.com/developerworks/library/l-pycon.html?n-l-9271

- "mod" can substitute the % operator. This gives cleaner (but a bit
longer) code.

- The string Formatting like %(#)03d can be good for C programs, but
probably can be invented a much simpler and nicer syntax for a high
level language like Python (does string.Template from 2.4 solve
this?). (Python is "based" on C, but putting C syntax inside Python
sometimes seems a bad thing to me.)

Maybe the : at the end of some blocks can be removed or it can become
optional (but then the newline is probably necessary):
for i in <suite>: <code>

for i in <suite>
<code>

if <cond>
<code>
else
<code>

def name(params)
<code>

- Assigns and equal symbols seem wrong/misplaced. So:
== can become =
= can become <-
the <- is probably a more correct symbol, but it can produce problems:
b <- 6
b < -6
So maybe
== can become =
= can become :=
(This reminds me Pascal syntax.)


In time, Python seems to become more similar to the Mathematica (and
in IPython this is even explicit) ^_^

Bear hugs,
(Remove HUGS to mail me)

 

[Josiah Carlson]

ignorant still, but it's also positive because I can still see details
that later probably I'll start to ignore.

Or perhaps later you will understand why some of the things you stated
are not applicable.

Some of the functions of IPython seem good and simple, and I think
some of them can be integrated into the main Python line.

There is a standard way of doing this. One must submit a PEP for
language changes, and usually for modules.

There are lots of different ways to make GUIs for Python programs, I
think that Gui4Cli (http://users.hol.gr/~dck/g4c/) is nice, and it can
be interesting to see it more integrated with Python. At the moment
there is only this interface, but it's not good:
http://users.hol.gr/~dck/g4c/dll/python.htm

Python is, by accident, GUI ambiguous. You can use whatever GUI you
want that has a proper wrapper.

Python has been shipping with tk for quite a while now. If there were
going to be a change in toolkit, Guido has all but declared that
wxPython would be shipped with Python, not some Windows-only toolkit
that doesn't quite have critical mass.

Is Python3000 going to come eventually? It will break a lot of
compatibility, so it will be the right moment to change/fix other
things too. Here are some ideas (probably there are errors, but I hope
to learn from my mistakes):

Yeah, Py3k will eventually come, unless the world ends.

- TABs can be accepted only inside comments.

In Py3k, tabs are not going to be allowed as indentation to Python code.
Keeping them in strings and comments is a non-issue.

- The optional static typing seems a quite nice thing (for compilers
too, they can produce faster code. It can probably allow faster and
smaller arrays, like those of numarray).

Asking for static typing in Python is a pretty big request. It seems
from those responses to similar questions, the answer is simply "static
typing isn't coming to CPython any time soon, probably not even for Py3k".

Keep wishing, but unless you implement it, I wouldn't get my hopes up.

- The functional IF seems interesting, like:
if(cond, code1, code2)
(Or maybe a different syntax, that allows elseif too.)

Many variants have been proposed over the years, but none have ever made
it in.

Don't get your hopes up.

- Functions containing yield can be defined in a different way, like:
generator name(params)
<code>
This idea comes from David Mertz:
http://www-106.ibm.com/developerworks/library/l-pycon.html?n-l-9271

I don't see how that gains anything. The existance of a yield defines a
generator, and that article only mentions that perhaps 'generator' would
have been better. All of the discussion happened on another list, and
(from what I hear), Guido pronounced (before that article was ever
written), that a new name for 'def' didn't make sense.

- "mod" can substitute the % operator. This gives cleaner (but a bit
longer) code.

Don't get your hopes up. There does not exist a 'logical modulo'
operation, where as there does exist a 'binary modulo' operation. The
reason 'and' and '&', 'or' and '|' exist is because they have logical
and binary counterparts, with the ability to short-circuit execution
under certain circumstances.

A much better request would be for a logical xor, though it has the
unfortunate consequence of never being short-circuitable.

- The string Formatting like %(#)03d can be good for C programs, but
probably can be invented a much simpler and nicer syntax for a high
level language like Python (does string.Template from 2.4 solve
this?). (Python is "based" on C, but putting C syntax inside Python
sometimes seems a bad thing to me.)

Read the PEP for Template to find out if it fixes it. Generally, no
matter what kind of string formatting you do, someone is not going to
like it. Me, I like the way things are done, but then again, sometimes
I like C.

Maybe the : at the end of some blocks can be removed or it can become
optional (but then the newline is probably necessary):

Don't get your hopes up. Colons are a very important delimiter for
Python now, and removing them just makes the syntax more ambiguous for
both reading and for interpreting.

In time, Python seems to become more similar to the Mathematica (and
in IPython this is even explicit) ^_^

Becoming more like Mathematica is not something one should hope for.


- Josiah

(I can't believe I am replying to someone with the email address
'bearophile')

 

[Ville Vainio]

Josiah> Asking for static typing in Python is a pretty big
Josiah> request. It seems from those responses to similar
Josiah> questions, the answer is simply "static typing isn't
Josiah> coming to CPython any time soon, probably not even for
Josiah> Py3k".

Guido has repeatedly expressed that Python will probably get optional
type declarations in the future. I am not sure to what extent that
implies static typing, but it's definitely on the map.

Boo already has type declarations, and I imagine the CLR
implementations of python (IronPython, Boo) will benefit most from
type declarations, performancewise. The benefit to CPython might be
more indirect, simplifying the work done by things like Psycho. Still,
I see type declarations opening so many doors that they should be in
the language - even if the performance improvement is zero at the
first stage. Python is not just CPython these days.

Josiah> Keep wishing, but unless you implement it, I wouldn't get
Josiah> my hopes up.

Implementation can be trivial - the interpreter could just assert
isinstance when check_type_declarations is true. The harder part is
coming up with all the semantics.

 

[Ville Vainio]

bearophile> about such things. I have few comments and notes on
bearophile> the Python language. I've just started to learn it;
bearophile> this is negative because I'm ignorant still, but it's
bearophile> also positive because I can still see details that
bearophile> later probably I'll start to ignore.

It's highly typical for the newbies to suggest improvements to the
language. They will usually learn that they are wrong, but the
discussion that ensues can be fruitfull anyway .

bearophile> Some of the functions of IPython seem good and simple,
bearophile> and I think some of them can be integrated into the
bearophile> main Python line.

IPython will be going through a Grand Cleanup Real Soon Now (as
Fernando Perez' time permits). Before that, integration of the
functionality probably isn't the smart thing to do.

As it stands, I'd see IPython as a more likely candidate for some kind
of "extra batteries" edition of python.

 

[Fernando Perez]

bearophile> Some of the functions of IPython seem good and simple,
bearophile> and I think some of them can be integrated into the
bearophile> main Python line.

IPython will be going through a Grand Cleanup Real Soon Now (as
Fernando Perez' time permits). Before that, integration of the
functionality probably isn't the smart thing to do.

Coming, coming Seriously, 0.6.4 is ready, I'm just giving the 2 week break
for the BSD licensing I said I would. I consider 0.6.4 the 'end of the line',
and I've started already rejecting requests for more changes/improvements, so
the Grand Cleanup doesn't get delayed any longer.

As there seems to be interest from various projects in having ipython as a good
interactive shell (which is obviously the kind of use I want to see), the need
for such a cleanup is becoming more pressing. Given the unfortunate reality
that ipython only gets the scraps of my 'free' time, helping hands would be
quite welcome (though be ready to dive into a big code hairball if you sign up
for the job

Best,

f

 

[gabriele renzi]

Ville Vainio ha scritto:

Josiah> Keep wishing, but unless you implement it, I wouldn't get
Josiah> my hopes up.

Implementation can be trivial - the interpreter could just assert
isinstance when check_type_declarations is true. The harder part is
coming up with all the semantics.

On a related note: What is supposed to be a type in python?
Is it a class? is it an interface? is it an implementation detail? is it
an algebraish definition?
I'd like to know what is the current 'mainstream' way of thinking about it.

 

[bearophile]

Or perhaps later you will understand why some of the things you

stated are not applicable.<

Sure, but sometimes outsiders can see some things better.

not some Windows-only toolkit that doesn't quite have critical mass.<

Maybe Gui4cli code will be released, etc. (wxPython is much more
powerful than Gui4cli-like solutions, so they don't compete, they can
be for different purposes).

In Py3k, tabs are not going to be allowed as indentation to Python code.<

Good.


Colons are a very important delimiter for Python now, and removing

them just makes the syntax more ambiguous for both reading and for
interpreting.<

I've heard similar comments about the leading whitespace used to
determine the grouping of statements.
I keep forgetting those colons, I think they are useful mostly for one
liners, like:
if <cond>: <code>

Becoming more like Mathematica is not something one should hope for.<

Mathematica is a good and powerful language, with a good design (older
maybe). I see many similarities between Python and Mathematica, and
such similarities seem to increase with time. (I know, Python is OO
and Mathematica usually isn't. But Mathematica can be used as a
functional language, etc.)

(I can't believe I am replying to someone with the email address

'bearophile')<

I am learning, like everybody else.

Thank you,
a bear hug,
bearophile

 

[Ville Vainio]

bearophile> I am learning, like everybody else.

He probably just thought that your email address is amusing. Which it
is, it the internetish neo-juvenile fashion. Laughing at such a name
is probably not the most mature thing to do, but some of us just can't
help it...

 

[Josiah Carlson]

Sure, but sometimes outsiders can see some things better.

Maybe Gui4cli code will be released, etc. (wxPython is much more
powerful than Gui4cli-like solutions, so they don't compete, they can
be for different purposes).

Because Python already has a standard GUI toolkit (tk), including
Gui4cli would imply that it was a better fit as a replacement than other
GUI toolkits.

Both wxPython and PyGTK seem to be far better candidates for replacement
of tk than Gui4cli, both due to their much larger user base, and their
cross-platform capability.

There have been non-standard distributions of Python, sometimes with
more packages specifically for a particular set of platforms.
Activestate makes one that includes Pythonwin and MFC bindings for GUI
development (you can get Pythonwin and MFC bindings from pywin32 btw).
While I doubt that Gui4cli would make it into standard Python, its
inclusion by a 3rd party Python packager is really just a question of
whether someone is interested enough in doing so.

them just makes the syntax more ambiguous for both reading and for
interpreting.<

I've heard similar comments about the leading whitespace used to
determine the grouping of statements.
I keep forgetting those colons, I think they are useful mostly for one
liners, like:
if <cond>: <code>
for c in string: <code>

It turns out that those one-liners are not considered Pythonic.

While there has been some discussion regarding spacing in Python, I
believe for many/most that use Python, indentation as scope is a very
positive thing.

If you don't like indentation as scope, you are free to download the
source, change the parser for your scope delimiter of choice, and
recompile. Since you can pick up a free copy of Microsoft's compiler
(if you are on Windows), or GCC is freely available, making a working
Python interpreter for your desired syntax is certainly doable.

Mathematica is a good and powerful language, with a good design (older
maybe). I see many similarities between Python and Mathematica, and
such similarities seem to increase with time. (I know, Python is OO
and Mathematica usually isn't. But Mathematica can be used as a
functional language, etc.)

In my opinion, the structure, syntax, readability, etc. of programs
written in Mathematica leaves something to be desired. That is why I
use Python and not Mathematica (that and Mathematica isn't free).

- Josiah

 

[Josiah Carlson]

bearophile> I am learning, like everybody else.

He probably just thought that your email address is amusing. Which it
is, it the internetish neo-juvenile fashion. Laughing at such a name
is probably not the most mature thing to do, but some of us just can't
help it...

I wasn't laughing at the name.

Perhaps the original poster is an animal conservationist, concerned
about humans encroaching on the environments of Black, Brown, Grizzly,
etc., bears. Perhaps it is something else.

I don't know, nor do I really want to know.
- Josiah

 

[Cliff Wells]

I wasn't laughing at the name.

Perhaps the original poster is an animal conservationist, concerned
about humans encroaching on the environments of Black, Brown, Grizzly,
etc., bears. Perhaps it is something else.

I don't know, nor do I really want to know.
- Josiah

Well, I am certainly laughing at

Thank you,
a bear hug,
bearophile

which I sincerely hope was meant in a humorous fashion, otherwise I too
am retreating to the "I don't want to know" camp.


Regards,
Cliff

 

[Alex Martelli]

In Py3k, tabs are not going to be allowed as indentation to Python code.
Keeping them in strings and comments is a non-issue.

While it ain't a biggie, I'd like to see tabs forbidden in string
literals -- using \t when you mean tab is more readable, and the one
obvious way to do it.

Asking for static typing in Python is a pretty big request. It seems
from those responses to similar questions, the answer is simply "static
typing isn't coming to CPython any time soon, probably not even for Py3k".

Unfortunately I suspect you may be wrong (for py3000 only): GvR does
seem to like the idea of optional static typing (perhaps with
interfaces, only, not necessarily with _types_ as such).

Many variants have been proposed over the years, but none have ever made
it in.

I think generators could get us close to this kind of thing (in Py3k).

They'd have to sprout a new method 'skip', similar to 'next' but defined
to not evaluate the argument of the next yield. Then, for some form of
function call, foo(a, b, c), instead of the current equivalent-of
_temp = a, b, c # make args tuple (evaluating all args)
foo(*_temp) # pass the tuple to foo
would compile to the equivalent of
def _temp():
yield a
yield b
yield c
foo(@_temp) # fantasy syntax for 'pass the generator to foo'

We could use braces instead of parentheses for this hypothetical
__call_with_generator__, whatever. Such functions as lisp's cond might
then easily be implemented:

def cond(@_args):
for test in _args:
if test: return _args.next()
else: _args.skip()

Just musing, of course, but it does appear within reach, while, before
generators, it didn't.


Alex

 

[Alex Martelli]

On a related note: What is supposed to be a type in python?

Since 'type' is a Python built-in, just like, say, 'int', I think the
answer is pretty clear: "X is a type" means isinstance(X, type), just
like "X is an int" means isinstance(X, int).


Alex

 

[gabriele renzi]

Alex Martelli ha scritto:

Since 'type' is a Python built-in, just like, say, 'int', I think the
answer is pretty clear: "X is a type" means isinstance(X, type), just
like "X is an int" means isinstance(X, int).

doh! dumb me , thank you for pointing out

 

[bearophile]

Josiah Carlson:

It turns out that those one-liners are not considered Pythonic.<

I agree, and I don't like them.
But the : becomes useful for that situation. Otherwise it seems less
useful to me.

If you don't like indentation as scope,<

I like indentation as scope, and I like Python, I think I've never
said otherwise

In my opinion, the structure, syntax, readability, etc. of programs

written in Mathematica leaves something to be desired.<

I agree again, and the editor is non-standard (on windows).
But I think it's a powerful language, with many built in functions,
well designed, etc.


Alex Martelli:

I'd like to see tabs forbidden in string literals -- using \t when

you mean tab is more readable, and the one obvious way to do it.<

I agree.

Thank you for all your answers,
a bear hug,
bearophile

 

[Scott David Daniels]

[lotsa stuff I like]

- The functional IF seems interesting, like:
if(cond, code1, code2) ... (Or ... a different syntax, [allowing elif])

Many variants have been proposed over the years, but none have ever made
it in.

I think generators could get us close to this kind of thing (in Py3k).

They'd have to sprout a new method 'skip', similar to 'next' but defined
to not evaluate the argument of the next yield.

That seems pretty tough to define. for a generator like:
def agen():
source = open('somedatafile.txt')
for i in range(1000):
source.seek(4 * i**2 + 33 * i + 52)
line = source.readline()
if line.startswith('magic:'):
yield line[6:]
source.close()

What computation would "skip the evaluation of the next yield" avoid?

... Such functions as lisp's cond might then easily be implemented:

def cond(@_args):
for test in _args:
if test: return _args.next()
else: _args.skip()

what would be different between this and:

> def cond(@_args):
> for test in _args:
> if test: return _args.next()
> else: _args.next()

I just don't understand the semantics of .skip().

-Scott David Daniels
(e-mail address removed)

 

[Alex Martelli]

[lotsa stuff I like]

- The functional IF seems interesting, like:
if(cond, code1, code2) ... (Or ... a different syntax, [allowing elif])
Many variants have been proposed over the years, but none have ever made
it in.

I think generators could get us close to this kind of thing (in Py3k).

They'd have to sprout a new method 'skip', similar to 'next' but defined
to not evaluate the argument of the next yield.

That seems pretty tough to define. for a generator like:
def agen():
source = open('somedatafile.txt')
for i in range(1000):
source.seek(4 * i**2 + 33 * i + 52)
line = source.readline()
if line.startswith('magic:'):
yield line[6:]
source.close()

What computation would "skip the evaluation of the next yield" avoid?

Just the 'line[6:]' slicing, for definiteness. I don't see anything
hard to define about it. Just conceptually turn each 'yield XXX' into:
if _must_skip_next_yield: yield None
else: yield XXX
with local flag _must_skip_next_yield being automatically set to False
when .next() is called on the iterator object, set to True when .skip()
is called.

what would be different between this and:

Your alternative evaluates every item in the _args iterator, and thus is
completely useless for cond's "guarding" purposes. E.g.,

inverse = cond(x, 1.0/x, True, None)

would raise a ZeroDivisionError under your alternative, would just set
inverse to None under my proposal.

I just don't understand the semantics of .skip().

Maybe it was too obvious to me so I failed to specify it in detail.

An example iterator that just does selective evaluation in a sequence:

def someof(sequence):
for i in xrange(len(sequence)):
if _must_skip_next_yield: yield None
else: yield sequence

with the same semantics for the special flag _must_skip_next_yield.
Alternatively, if a sequence's iterator also implemented skip:

def someof(iterable):
it = iter(iterable)
assert has_attr(it, 'skip')
while True:
if _must_skip_next_yield: yield it.skip()
else: yield it.next()

this would be essentially a "no-op" wrapper of iterable, essentially
identical to iter(iterable), and I'm just showing it to further
illustrate the intended semantics of 'skip'.

The iterator over arguments, which I propose, could not be implemented
in Python today (Python today has no way to collect yet-unevaluated
arguments). I do believe that the C interpreter would need few changes
to implement it (what syntax to use to signal it being the one
contentious part), and even fewer to accept a .skip method on generators
and use it to set a local variable _must_skip_next_yield in the
generator's frame (not particularly useful, I believe -- not all
iterators would have to be skippable, and, unless strong use cases
emerge, normal generators might well be deemed nonskippable ones).


Alex

 

[Scott David Daniels]

... The iterator over arguments, which I propose, could not be implemented
in Python today (Python today has no way to collect yet-unevaluated
arguments).

Ah -- that was what I didn't get: I hadn't understood f(@_args) to be
more than f(*list(_args)) and so the rest made no sense at all to me.
Sort of an evalquote kind of thing (I think, it has been decades), I
guess. Thanks for taking the time to explain.

-Scott David Daniels
(e-mail address removed)

 

[Alex Martelli]

Ah -- that was what I didn't get: I hadn't understood f(@_args) to be
more than f(*list(_args)) and so the rest made no sense at all to me.
Sort of an evalquote kind of thing (I think, it has been decades), I

Yep, sort of, with "skippable iterators" as the natural way to access
(possibly only some of) the resulting values.

guess. Thanks for taking the time to explain.

You're welcome, and I apologize if my original sketch had been way too,
well, sketchy;-).


Alex

 

[Bengt Richter]

]

The iterator over arguments, which I propose, could not be implemented
in Python today (Python today has no way to collect yet-unevaluated
arguments). I do believe that the C interpreter would need few changes
to implement it (what syntax to use to signal it being the one
contentious part), and even fewer to accept a .skip method on generators
and use it to set a local variable _must_skip_next_yield in the
generator's frame (not particularly useful, I believe -- not all
iterators would have to be skippable, and, unless strong use cases
emerge, normal generators might well be deemed nonskippable ones).

If py3k eliminated current back-ticks in favor of a new use, namely

`expr

being short spelling of

lambda:expr

(Actually, I think 'expr should not just be lambda:expr but capture snapshot
references to the variables in the expr. I.e., if expr was 2*a.x-3 you'd have
lambda a=a:2*a.x-3 -- while making sure that a etc are just bare name references,
but then I couldn't just type in the simplified examples below, which I don't
want to retype ;-)

then you could write stuff like
... if c(): return t()
... else: return f()
...

and call that using

ifelse(`condition, `value_if_true, `value_if_false)

except for now we have to use the long spelling of lambda
(and should use longer yet spelling ;-) :
evaluated True
evaluated 'true value'
'true value' evaluated 0
evaluated 'false value'
'false value'

of course, if you are modifying python, you could make ifelse a special form,
along with cond, and have the back-ticks implied instead of explicit.

if you think of cond as a flat series of (condition, value_expr) pairs,
(was that the intent?)
... cvp = iter(cvp)
... for c in cvp:
... if c(): return cvp.next()()
... cvp.next()
... return False
... evaluated False
evaluated False
evaluated True
evaluated 'true value'
'true value' evaluated False
evaluated False
evaluated False
evaluated False
False evaluated False
evaluated True
evaluated 'true value'
'true value'

Regards,
Bengt Richter