[Python-ideas] Crazy idea: allow keywords as names in certain positions

[Brice Parent]

I'm not half aware of the way everything works under the hood as the 
vast majority here, but I have an idea. It possibly is technically 
stupid when you really know how things work, but as I'm not sure, I'm 
submitting it anyways:

Why not add the compatibility done at setup.py's level?

Like having something like this:

setup(
     name="LegacyLib",
     version="8.4.1",
     ...
     max_compatibility="3.4"  # Defining here Python's max version for 
which this lib has been upgraded
)

Of course, we may use any other word instead of "max_compatibility", 
like "designed_for", "python_version", or anything a better English 
speaker could think of.

The point is, it would either:

- when you install the library, rename all variables that are now 
keywords (we'd know the exact list thanks to max_compatiblity) by 
suffixing them with "_"

- or set a flag that will do that when creating the *.pyc files.

Possible problems/limitations I can already find:

- There would still be possible errors when using variable names that 
are generated on the fly (I have no clue how this could ever be addressed)
- It might get complicated at some point to know what to do, like when 
we have lib_a in some version depending on lib_b (with or without a 
max_compatibility version number), it is obvious that lib_a will use 
lib_b's original variable names (without the appended "_"), but our code 
which might also want to interact with lib_b would have to.

Is it plain stupid? Are there lots of things I didn't think of? Could it 
be a possibility?

-Brice

Le 13/05/2018 à 20:19, Guido van Rossum a écrit :
> As anyone still following the inline assignment discussion knows, a 
> problem with designing new syntax is that it's hard to introduce new 
> keywords into the language, since all the nice words seem to be used 
> as method names in popular packages. (E.g. we can't use 'where' 
> because there's numpy.where 
> <https://docs.scipy.org/doc/numpy-1.14.0/reference/generated/numpy.where.html>, 
> and we can't use 'given' because it's used in Hypothesis 
> <http://hypothesis.readthedocs.io/en/latest/quickstart.html>.)
>
> The idea I had (not for the first time :-) is that in many syntactic 
> positions we could just treat keywords as names, and that would free 
> up these keywords.
>
> For example, we could allow keywords after 'def' and after a period, 
> and then the following would become legal:
>
> class C:
>     def and(self, other):
>         return ...
>
> a = C()
> b = C()
> print(a.and(b))
>
> This does not create syntactic ambiguities because after 'def' and 
> after a period the grammar *always* requires a NAME.
>
> There are other positions where we could perhaps allow this, e.g. in a 
> decorator, immediately after '@' (the only keyword that's 
> *syntactically* legal here is 'not', though I'm not sure it would ever 
> be useful).
>
> Of course this would still not help for names of functions that might 
> be imported directly (do people write 'from numpy import where'?). And 
> it would probably cause certain typos be harder to diagnose.
>
> I should also mention that this was inspired from some messages where 
> Tim Peters berated the fashion of using "reserved words", waxing 
> nostalgically about the old days of Fortran (sorry, FORTRAN), which 
> doesn't (didn't?) have reserved words at all (nor significant 
> whitespace, apart from the "start in column 7" rule).
>
> Anyway, just throwing this out. Please tear it apart!
>
> -- 
> --Guido van Rossum (python.org/~guido <http://python.org/%7Eguido>)
>
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180516/b783d059/attachment.html>