PEP0238 lament

Steve Horne sh at ttsoftware.co.uk
Mon Jul 23 12:05:26 CEST 2001


On 23 Jul 2001 02:18:29 -0700, paul at boddie.net (Paul Boddie) wrote:

>I can see people seriously suggesting a "pythonfork" project if the
>debate gets any more intense. :-O

I've had idle thoughts for some time about a language that would allow
you to define - within the language itself - the syntax and semantics
for sublanguages. Only the lexical rules would be fixed, though there
would need to be several built-in sublanguages - grammar and
translation definition, simple compile-time imperative and simple
run-time imperative being the obvious ones. The thought was originally
provoked by wanting to support many different paradigms efficiently
and concisely in the same language - if anyone comes up with a new
paradigm, they just create a library that defines a suitable grammar
and translation and, hey presto, anyone can use it without changing
languages, and without discarding code written for other paradigms.

It suddenly seems so much more like a practical idea.

>> Guys, if you really need something returning floats for division, make it
>> new operator, I guess everyone could be made happy with 1/2 == 0 and 1//2 ==
>> 0.5.
>
>The most sensible suggestion yet! I was reading the previous messages
>in this thread waiting for someone to suggest this, and it's about
>time someone did! There's a lot of weight behind adding a new
>operator, yet most people seem to advocate adding the // operator and
>then *changing* the / operator... which is madness!

Agreed - I already made the same suggestion in the 'Future division
patch available (PEP 238) thread.

>If beginners want an operator which behaves as they expect, they
>certainly aren't going to have any preconceptions about what it's
>going to look like - they are beginners, after all. Therefore, why
>even bother suggesting changing the / operator? Just introduce // and
>be done with it! Nothing gets broken, the beginners get their new
>operator, and those wanting the C++ comment syntax in Python will just
>have to be disappointed. ;-)

I'll live ;-)

-- 
Steve Horne
Home : steve at lurking.demon.co.uk
Work : sh at ttsoftware.co.uk



More information about the Python-list mailing list