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
<
I like it! The obvious question, though: How would "*from package import
keyword*" be handled, if not simply by SyntaxError? Would *from package
import keyword as keyword_* be allowed?
In a similar vein, what would happen with stdlib functions like
operator.not_? The thought of writing "operator.n
On Sun, May 13, 2018 at 11:20 AM Guido van Rossum wrote:
> For example, we could allow keywords after 'def' and after a period, and
> then the following would become legal:
>
Our modeling database overloads getattr/setattr (think SQLAlchemy) to
allow us to access to database fields as if they w
On Mon, May 14, 2018 at 4:19 AM, Guido van Rossum wrote:
> 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.
> ...
> I should also mention that this was inspired from some messages where
Note that Javascript does something similar,
in that reserved keywords are allowed in member access.
var x = {if : 42};
console.log(x.if);
Stephan
2018-05-13 20:42 GMT+02:00 Eric Fahlgren :
> On Sun, May 13, 2018 at 11:20 AM Guido van Rossum
> wrote:
>
>> For example, we could allow keywords
On 2018-05-13 11:19, Guido van Rossum wrote:
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
Apologies for my initial response. Looks like I failed to expand the
initial email fully, which would have shown me the following :)
> Of course this would still not help for names of functions that might be
imported directly (do people write 'from numpy import where'?).
-- I do think the *import
On 13/05/2018 19:19, Guido van Rossum wrote:
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. w
Care would have to be taken in the grammar to avoid syntactic ambiguity.
For example:
x = 1
def not(x):
...
if not - x: # Is this 'not' the keyword or the identifier? not (-x), or not
minus x?
...
Nathan
On Sun, May 13, 2018 at 2:20 PM Guido van Rossum wrote:
> As anyone still followi
[Guido]
> ...
> 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,
On 13/05/2018 19:19, Guido van Rossum wrote:
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.
Guido van Rossum wrote:
Of course this would still not help for names of functions that might be
imported directly (do people write 'from numpy import where'?).
Maybe things could be rigged so that if you use a reserved word
as a name in an import statement, it's treated as a name everywhere
el
Elias Tarhini wrote:
The thought of writing "operator.not" is appealing, but
being forced to use *that* (with *from operator import not* being
non-allowable) may not be.
Under the proposal I made in my last post, "from operator import not"
would be fine -- you just wouldn't be able to use the
Rob Cliffe via Python-ideas wrote:
def and(x, y):
return ...
# and(1,2) # Oops, SyntaxError. Oh, I know:
globals()['and'](1,2)# Works!
If the rule I proposed for "import" were extended to "def"
then and(1,2) would work. The usual way of using "and" would
no lo
New Python versions already use backwards incompatible syntax, but it has
to be a strict superset so the new parser still parses old code. If a new
Python version introduced syntax that would break old code, it would still
work, so long as the parser knew which syntax the file contained, and was
ab
On Sun, May 13, 2018 at 9:00 PM, Greg Ewing wrote:
> Guido van Rossum wrote:
>>
>> Of course this would still not help for names of functions that might be
>> imported directly (do people write 'from numpy import where'?).
>
>
> Maybe things could be rigged so that if you use a reserved word
> as
On 13/05/2018 19:19, Guido van Rossum wrote:
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.
On 14/05/2018 02:28, Greg Ewing wrote:
Rob Cliffe via Python-ideas wrote:
def and(x, y):
return ...
# and(1,2) # Oops, SyntaxError. Oh, I know:
globals()['and'](1,2) # Works!
If the rule I proposed for "import" were extended to "def"
then and(1,2) would work
As long as any new syntax allowed us to still reference the occassional
thing in the older libraries that used newly reserved names, it would
not come up that often, and would avoid the biggest cost of a whole
new version.
If `foo` was a reserved word, then this could be allowed...
import foo
On 13 May 2018 at 14:19, Guido van Rossum wrote:
> 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 package
Rob Cliffe via Python-ideas wrote:
If you forbid redefining keywords, you remove the whole point of this
proposal:
I mean the keywords that are in the language as of now.
There will never be a need to redefine those, since no
current code uses them as names.
--
Greg
___
On 13/05/18 19:19, Guido van Rossum wrote:
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.
I'm not familiar with the innards of the parser and it's wy too long
since I sat through a
On 2018-05-14 12:35, Rhodri James wrote:
> On 13/05/18 19:19, Guido van Rossum wrote:
>> 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.
>
> I'm not familiar with the innards of the p
On 5/13/2018 2:19 PM, Guido van Rossum wrote:
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.
This trades the simplicity of 'using a keyword as an identifier always
fails immediately'
[Terry Reedy ]
> ...
> The impact on real-time syntax coloring should be considered. An re-based
> colorizer, like IDLE's, tags every appearance of keywords outside of strings
> and comments, syntactically correct or not. For instance, the first two
> 'and's in "a and b.and # and error" are tagged
On 05/13/2018 10:57 PM, Greg Ewing wrote:
Rob Cliffe via Python-ideas wrote:
If you forbid redefining keywords, you remove the whole point of this proposal:
I mean the keywords that are in the language as of now.
There will never be a need to redefine those, since no
current code uses them a
Terry Reedy wrote:
the first two 'and's in "a and b.and # and error" are tagged.
To not tag the second would require full parsing,
That particular case could be handled by just not colouring
any word following a dot.
Some other situations might result in false positives, but
there are cases li
On 5/14/2018 6:58 PM, Greg Ewing wrote:
Terry Reedy wrote:
the first two 'and's in "a and b.and # and error" are tagged. To not
tag the second would require full parsing,
That particular case could be handled by just not colouring
any word following a dot.
OK, more parsing, even if not compl
Ethan Furman wrote:
Part of the point of the proposal is to be able to use existing keywords
(at least, I thought it was).
Mainly it's so that *new* keywords can be added to the language
without breaking old code. Nobody is going to want to turn one
of the currently existing keywords into a nam
On Tue, 15 May 2018 21:51:20 +1200
Greg Ewing wrote:
> Ethan Furman wrote:
> > Part of the point of the proposal is to be able to use existing keywords
> > (at least, I thought it was).
>
> Mainly it's so that *new* keywords can be added to the language
> without breaking old code. Nobody is g
On 15 May 2018 at 11:07, Antoine Pitrou wrote:
> On Tue, 15 May 2018 21:51:20 +1200
> Greg Ewing wrote:
>> Ethan Furman wrote:
>> > Part of the point of the proposal is to be able to use existing keywords
>> > (at least, I thought it was).
>>
>> Mainly it's so that *new* keywords can be added to
While I understand the attraction, I think the clarity cost might be to high.
If it's a pain to explain it to an IDE, it's an even bigger pain to
explain it to people new to the language.
___
Python-ideas mailing list
Python-ideas@python.org
https://mail
On Mon, May 14, 2018 at 01:28:51PM +1200, Greg Ewing wrote:
> Redefining the existing keywords could perhaps be forbidden
> if you really want to protect people from shooting themselves
> in the kidneys this particular way.
So instead of having two classes of identifiers
- those that can be used
I hereby withdraw the idea.
--
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Steven D'Aprano wrote:
So instead of having two classes of identifiers
- those that can be used anywhere;
- those that can only be used as dotted names;
you would have two classes of keywords:
- those that cannot be shadowed;
- those that can be shadowed.
Yes. But we would always recommend t
35 matches
Mail list logo
