Greetings to the people and God(s) of Pythonland,
A few quasi-random thoughts on Python NG...
Bootstrap thought : First of all, the long speculative threads
on Python 2, I found disturbing, because in any case, the
design of Python is Guido's property, and the artist's
prerogative is to remain free to dream up his designs,
without interference.
Second thought : "Python 2 is a contradiction in terms".
Obviously, the Python version numbering scheme is destined
to converge on the value of the golden mean 1.618, therefore,
Python 2 is out of bounds.
Third thought : Still, I can dream up ideas for Python, but
purely as an exercize, in the hope that one of these ideas
will draw a positive smile from Guido's face.
The most recent of these ideas, takes as a pretext of
expression : to have the recurrent debate on Python's braces
by newbies, C-ers, Perl-ers and Tcl-ers, further itself one bit.
I know that one key factor (by no means the only one) of
the beauty of Python to my eyes, is precisely the "effect"
of having braces "replaced" in Python, by the INDENT/DEDENT
scheme.
Reflecting on it, I discovered that this component of my
aesthetic pleasure with Python does not reduce to the idea
that making indentation machine-significant was the right
thing to do, but may well also have to be explained in terms
of a theory of the taste for braces.
It came to me in a flash, that BOTH the general taste for
braces in programming languages AND my distaste with the
way they are used TRACE BACK to an education in mathematics,
that introduced me, as well as the others, to braces AS DELIMITERS
OF THE WRITTEN REPRESENTATION OF SETS.
Now, SETS are not the last word, even in mathematics, and
one does well IMHO to think that what is today known as
"Category Theory" is actually "Sets done right", that is,
Sets done the way they should have been (and were not)
to fit the promises of the "new maths" that conquered the
educative system(s) during the sixties.
This is to say, that although SETS aren't the last word,
even IMHO, I believe today that, besides my love of using
indentation significatively, hides behind my taste for Python
syntax, an aesthetical DISpleasure with HOW braces are used
in "those OTHER languages", namely as block delimiters,
BECAUSE that use doesn't "chord" with set syntax.
And indeed, Python DOES use braces, to delimit dictionary
constructors, which are not sets, but... but are actually
a way to use braces that SMOOTHLY EXTENDS to classical set
syntax. { 1, 2, 3 } is presently illegal syntax in Python.
It could be made natural legal shorthand for { 1:1 , 2:2, 3:3}.
To make it interesting, a corresponding semantics should be
given to the currently illegal :
for item in { 1, 2, 3 } : do_your_thing(item)
I suggest the spec : "for I in M, M mapping", guarantees to loop
varying I, and the set of values I takes is comprised between
filter((lambda x,M=Mapping : M[x] is x),Mapping.keys())
And
M.keys()+filter((lambda x,K=M.keys() : x not in K),M.values())
Which boil down to the same in the case M is a set.
Now I remember that Guido comes from Dijkstra's country,
who, together with Wirth, made "syntactic sugar" a bad name.
And the above sounds ridiculously LIKE a case for a
syntactic sugar addition (MnotsoHO, is that it would be
more precise to speak of semantic sugar, ah, well).
Well, if it is a matter of sugar, why not start by going
full length, and ask for a ridiculously syntactical further
extension. While SETS, in the school where I was thaught,
were delimited by braces, their elements where SEPARATED
BY ";" rather than commas. And this early training burns
me regularly when I am writing dictionnary constructors
in Python. So I would wish Python 1.618 to accept ';' as
item or key-value pair separator in that context, just as
it already accepts ',' in the same role.
But that's not all. As I said in the beginning of this
little diatribe, it's banner is to further the debate
on Python's "bracelessness" quite a bit, in a way that
will incite the evercomplaining C-ers etc... to silence
their "critics"... and the method is to show better the
starring role that braces already have in Python.
This is a motive for my further proposition : ascribe,
as a matter of principle and standard implementation,
to *mappings* the CALL SEMANTICS of an ANONYMOUS CLASS.
So that :
doubler = { '__mul__' : lambda s,y : 2*y }()
does the obvious.
...
To fullfill my promise at the beginning, I shall
come back with completely unrelated, and perhaps
even contradictory, propositions for Python NG aka
1.618 aka 2.001.
As I said, I view myself here, in the role of the
King's fool. Guido is the King. The design contract
of my proposals is no more than trying to bring
a fleeting smile on the King's face.
Boris Borcic
--
"c++ is a contradiction in terms" -- Einstein
A few quasi-random thoughts on Python NG...
Bootstrap thought : First of all, the long speculative threads
on Python 2, I found disturbing, because in any case, the
design of Python is Guido's property, and the artist's
prerogative is to remain free to dream up his designs,
without interference.
Second thought : "Python 2 is a contradiction in terms".
Obviously, the Python version numbering scheme is destined
to converge on the value of the golden mean 1.618, therefore,
Python 2 is out of bounds.
Third thought : Still, I can dream up ideas for Python, but
purely as an exercize, in the hope that one of these ideas
will draw a positive smile from Guido's face.
The most recent of these ideas, takes as a pretext of
expression : to have the recurrent debate on Python's braces
by newbies, C-ers, Perl-ers and Tcl-ers, further itself one bit.
I know that one key factor (by no means the only one) of
the beauty of Python to my eyes, is precisely the "effect"
of having braces "replaced" in Python, by the INDENT/DEDENT
scheme.
Reflecting on it, I discovered that this component of my
aesthetic pleasure with Python does not reduce to the idea
that making indentation machine-significant was the right
thing to do, but may well also have to be explained in terms
of a theory of the taste for braces.
It came to me in a flash, that BOTH the general taste for
braces in programming languages AND my distaste with the
way they are used TRACE BACK to an education in mathematics,
that introduced me, as well as the others, to braces AS DELIMITERS
OF THE WRITTEN REPRESENTATION OF SETS.
Now, SETS are not the last word, even in mathematics, and
one does well IMHO to think that what is today known as
"Category Theory" is actually "Sets done right", that is,
Sets done the way they should have been (and were not)
to fit the promises of the "new maths" that conquered the
educative system(s) during the sixties.
This is to say, that although SETS aren't the last word,
even IMHO, I believe today that, besides my love of using
indentation significatively, hides behind my taste for Python
syntax, an aesthetical DISpleasure with HOW braces are used
in "those OTHER languages", namely as block delimiters,
BECAUSE that use doesn't "chord" with set syntax.
And indeed, Python DOES use braces, to delimit dictionary
constructors, which are not sets, but... but are actually
a way to use braces that SMOOTHLY EXTENDS to classical set
syntax. { 1, 2, 3 } is presently illegal syntax in Python.
It could be made natural legal shorthand for { 1:1 , 2:2, 3:3}.
To make it interesting, a corresponding semantics should be
given to the currently illegal :
for item in { 1, 2, 3 } : do_your_thing(item)
I suggest the spec : "for I in M, M mapping", guarantees to loop
varying I, and the set of values I takes is comprised between
filter((lambda x,M=Mapping : M[x] is x),Mapping.keys())
And
M.keys()+filter((lambda x,K=M.keys() : x not in K),M.values())
Which boil down to the same in the case M is a set.
Now I remember that Guido comes from Dijkstra's country,
who, together with Wirth, made "syntactic sugar" a bad name.
And the above sounds ridiculously LIKE a case for a
syntactic sugar addition (MnotsoHO, is that it would be
more precise to speak of semantic sugar, ah, well).
Well, if it is a matter of sugar, why not start by going
full length, and ask for a ridiculously syntactical further
extension. While SETS, in the school where I was thaught,
were delimited by braces, their elements where SEPARATED
BY ";" rather than commas. And this early training burns
me regularly when I am writing dictionnary constructors
in Python. So I would wish Python 1.618 to accept ';' as
item or key-value pair separator in that context, just as
it already accepts ',' in the same role.
But that's not all. As I said in the beginning of this
little diatribe, it's banner is to further the debate
on Python's "bracelessness" quite a bit, in a way that
will incite the evercomplaining C-ers etc... to silence
their "critics"... and the method is to show better the
starring role that braces already have in Python.
This is a motive for my further proposition : ascribe,
as a matter of principle and standard implementation,
to *mappings* the CALL SEMANTICS of an ANONYMOUS CLASS.
So that :
doubler = { '__mul__' : lambda s,y : 2*y }()
does the obvious.
...
To fullfill my promise at the beginning, I shall
come back with completely unrelated, and perhaps
even contradictory, propositions for Python NG aka
1.618 aka 2.001.
As I said, I view myself here, in the role of the
King's fool. Guido is the King. The design contract
of my proposals is no more than trying to bring
a fleeting smile on the King's face.
Boris Borcic
--
"c++ is a contradiction in terms" -- Einstein