Some notes

[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')