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
[email protected]
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
[email protected]
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
On 2018-05-15 04:32, Tim Peters wrote:
Just noting some real code I typed today where `given` works great if
it allows unpacking syntax, and assignment expressions don't:
while True:
head, matched, s = s.partition(sep)
if not matched:
break
Using `given`:
[Tim]
>> Just noting some real code I typed today where `given` works great if
>> it allows unpacking syntax, and assignment expressions don't:
>>
>> while True:
>> head, matched, s = s.partition(sep)
>> if not matched:
>> break
>>
>> Using `given`:
>>
>> w
While importlib.resources looks very good, I'm certain that it can't
replace every use of __file__ for accessing files relative to your Python
code.
Consider a mini-Web-server written in Python (there are, of course, lots of
these) that needs to serve static files. Users of the Web server will
exp
On Mon, 14 May 2018 at 12:17 Chris Angelico wrote:
> On Tue, May 15, 2018 at 2:05 AM, Chris Barker via Python-ideas
> wrote:
> > But my question is whether high precision timedeltas belongs with
> "calendar
> > time" at all.
> >
> > What with UTC and leap seconds, and all that, it gets pretty ug
I'm busy at the sprints, so I don't have a lot of time to think about this.
However, let me just say that recursive format specs are supported, to a
depth of 1.
>>> width=10
>>> f'{"test":{width}}'
'test '
So first the string is basically expanded to:
f'{"test":10}'
Then the string is fo
On May 15, 2018, at 14:03, Rob Speer wrote:
> Consider a mini-Web-server written in Python (there are, of course, lots of
> these) that needs to serve static files. Users of the Web server will expect
> to be able to place these static files somewhere relative to the directory
> their code is
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
Inspired by Alex Brault's post:
https://mail.python.org/pipermail/python-ideas/2018-May/050750.html
I'd like to suggest we copy C#'s idea of verbatim identifiers, but using
a backslash rather than @ sign:
\name
would allow "name" to be used as an identifier, even if it clashes with
a key
On Wed, 16 May 2018 at 10:42, Steven D'Aprano wrote:
> Inspired by Alex Brault's post:
>
> https://mail.python.org/pipermail/python-ideas/2018-May/050750.html
>
> I'd like to suggest we copy C#'s idea of verbatim identifiers, but using
> a backslash rather than @ sign:
>
> \name
>
Personal
I like it. I much prefer \ to $ since in most languages that use $ that I
know of (Perl, shell) there's a world of difference between $foo and foo
whenever they occur (basically they never mean the same thing), whereas at
least in shell, \foo means the same thing as foo *unless* foo would
otherwise
I assume there can't be space between the backslash and the name, to
prevent ambiguity like in the following:
# Is this `foo = not [1]` or `foo = \not[1]`?
foo = (\
not[1])
A sampling of \ in other languages, for consideration:
- Haskell: A lambda. E.g. `\x -> x+1`
- TeX: A comma
> On Tue, May 15, 2018 at 8:41 PM, Steven D'Aprano
> wrote:
>
>> Inspired by Alex Brault's post:
>>
>> https://mail.python.org/pipermail/python-ideas/2018-May/050750.html
>>
>> I'd like to suggest we copy C#'s idea of verbatim identifiers, but using
>> a backslash rather than @ sign:
>>
>> \n
On 5/15/2018 8:41 PM, Steven D'Aprano wrote:
Inspired by Alex Brault's post:
https://mail.python.org/pipermail/python-ideas/2018-May/050750.html
I'd like to suggest we copy C#'s idea of verbatim identifiers, but using
a backslash rather than @ sign:
Not quite as heavy.
\name
would al
[Terry Reedy]
> ...
> I believe avoiding tagging raw names as keywords could be done by adjusting
> the re for keywords
Yup - it should just require adding a negative lookbehind assertion; e.g.,
>>> import re
>>> keypat = r"(?>> re.search(keypat, r"yup! while")
<_sre.SRE_Match object; span=(5, 10
On 05/15/2018 08:03 PM, Carl Smith wrote:
On Tue, May 15, 2018 at 8:41 PM, Steven D'Aprano wrote:
I'd like to suggest we copy C#'s idea of verbatim identifiers, but using
a backslash rather than @ sign:
\name
would allow "name" to be used as an identifier, even if it clashes with
a keyw
> Are you saying that servers like Nginx or whatever your mini-server uses
don’t have a way to blanket ignore files? That would surprise me, and it
seems like a lurking security vulnerability regardless of
importlib.resources or __init__.py files. I would think that you’d want to
whitelist file e
22 matches
Mail list logo
