Future division patch available (PEP 238)

[Stephen Horne]

On 22 Jul 2001 07:14:25 GMT, Marcin 'Qrczak' Kowalczyk
<qrczak at knm.org.pl> wrote:

>Sun, 22 Jul 2001 00:36:38 -0400, Guido van Rossum <guido at digicool.com> pisze:
>
>> I thought again about the merits of the '//' operator vs. 'div'
>> (either as a function or as a keyword binary operator), and figured
>> that '//' is the best choice: it doesn't introduce a new keyword
>> (which would cause more pain), and it works as an augmented assignment
>> (//=) as well.
>
>Why div= wouldn't work? (Lexed as two tokens.)

Because div doesn't exist as a keyword, and therefore has probably
been used by many people as an identifier name. div= is therefore
something that many people probably have to start a simple assignment.

An assignment such as...

  div="Premier"

might exist in many football fans programs, for instance.


Guido - here's a thought...

How about using some symbol that the Python doesn't use at present,
and using it as a 'this is a keyword' prefix. '$' seems a good
candidate for the prefix. Once the scanner spots the prefix, it should
continue scanning using the rules for identifiers but specifically
identify the result as a keyword.

That way, any new keyword could be created at will without breaking
old code - the prefix might be a little annoying, but most important
keywords must already exist by now so the irritation would be kept to
a minimum.

Any use of a name prefixed by $ (or whatever) which is not recognised
should generate an error - unknown keyword or something - to prevent
anyone trying to use it in an identifier.

Using the prefix in front of existing keywords should be valid but
unnecessary - $while should be a synonym of while, for instance - so
anyone who is unsure whether a particular keyword needs a prefix can
just bung one in to play it safe.

If you do add a capability like that, I'd propose $mod and $rem as new
operators - modulo and remainder. $rem would do the same as %, but
$mod would always give a positive result according to the rules of
modulo arithmetic. These wouldn't be worth adding at the expense of
breaking existing code, but if that wasn't an issue they should be
more readable than '%'.

I know that incomprehensible prefixes seem a bit Perl-ish, but I think
this would be a good idea anyway - allowing considerable freedom to
update Python without the risk of breaking existing code.