> Guido van Rossum:
> > No, we *could* use the 'import as' trick: define the syntax as
> >
> > term: factor (('*'|'/'|'%'|NAME) factor)*
> >
> > and add a check that NAME is "div" in the compiler.
> >
> > But I don't know how comfy I am with a proliferation of hacks like
> > this -- and it's likely to cause more confusing error messages.
And what is the compelling reason for going through all this instead
of just using the '//' symbol? Because it might be confused for a C++
comment? This is a weak argument AFAIAC. Python is not C++ and
everybody knows that.
I think that making "div" an infix operator would be setting a
horrible precedent. Currently, all infix operators "look like"
operators, i.e. they are non-alphabetic characters, and things that
look like words are either functions or reserved words.
There's already a "divmod" builtin which is a function, not an infix
operator. I think it would be rather inconsistent to write, on the
one hand:
divmod(10, 2)
and on the other:
10 div 2
Long before the creation of python-dev, this issue had been discussed
numerous times on c.l.py, and the '//' operator was suggested several
times, and I don't think anybody ever had a problem with it...
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4