On 16 May 2018 at 01:41, 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
>
> would allow "n
On 5/16/18 4:13 AM, Paul Moore wrote:
On 16 May 2018 at 01:41, 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:
On 5/16/18 4:47 AM, Eric V. Smith wrote:
On 5/16/18 4:13 AM, Paul Moore wrote:
Can you give a worked example of how this would
help if we wanted to introduce a new keyword? For example, if we
intended to make "where" a keyword, what would numpy and its users
need to do to continue using `numpy
On 16 May 2018 at 09:56, Eric V. Smith wrote:
> On 5/16/18 4:47 AM, Eric V. Smith wrote:
>>
>> On 5/16/18 4:13 AM, Paul Moore wrote:
>
>
>>> Can you give a worked example of how this would
>>> help if we wanted to introduce a new keyword? For example, if we
>>> intended to make "where" a keyword,
Hi all,
One problem already alluded to with the \identifier syntax is that it only
works
if the old Python version is sufficiently recent to understand \.
What about using parentheses to allow a keyword to be used as an identifier:
(where)(x, y)
This then in combination with allowing keywords in
On Wed, 16 May 2018 09:13:52 +0100
Paul Moore wrote:
> On 16 May 2018 at 01:41, 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
Is there some interest in the proposal or should I finally close this
thread ?
Thanks for your feedback,
Eloi
> ___
> Python-ideas mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://
On Wed, May 16, 2018 at 08:29:00AM +, Eloi Gaudry wrote:
> Is there some interest in the proposal or should I finally close this
> thread ?
I'm definitely interested in the concept, not the suggested syntax or
semantics.
--
Steve
___
Python-ideas
On 16.05.2018 02:41, Steven D'Aprano wrote:
Some examples:
result = \except + 1
result = something.\except
result = \except.\finally
Maybe that could get combined with Guido's original suggestion by making
the \ optional after a .?
Example:
class A ():
\global = 'Hel
IMHO, it would be much easier to learn and understand if keywords can only
be used by escaping them, instead of depending where they occur.
On Wed, May 16, 2018 at 9:13 AM, Wolfgang Maier <
[email protected]> wrote:
> On 16.05.2018 02:41, Steven D'Aprano wrote:
>
>>
>> Some
On Tue, May 15, 2018, 23:03 Carl Smith wrote:
>
>
>> 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 identifier
On Tue, May 15, 2018 at 10:11 PM Rob Speer wrote:
> From what I can tell, if you wanted to exclude '__init__.py' from Nginx in
> particular, you would have to write an unconventional Nginx configuration,
> where you determine whether a path refers to a static file according to a
> regex that excl
Thanks for the reply Todd.
If `True` was redefined somewhere else, it would still be `True` for you.
You could do `from oldlib import True as true` and have `true` equal `
np.bool_(1)`. You could reference `oldlib.True` or do
`oldlib.function(True=x)` to interact with the name in the old library.
One problem with my proposal is with assignments to properties
(`name.keyword = something`) and regular assignments (including class and
def statements) inside the body of a class that subclasses and externally
defined class would all need to be allowed, so that inherited names can be
reassigned to
On Wed, May 16, 2018 at 10:26 AM, Carl Smith wrote:
> Thanks for the reply Todd.
>
> If `True` was redefined somewhere else, it would still be `True` for you.
> You could do `from oldlib import True as true` and have `true` equal `
> np.bool_(1)`. You could reference `oldlib.True` or do
> `oldlib
On 16.05.2018 16:05, Andrés Delfino wrote:
IMHO, it would be much easier to learn and understand if keywords can only
be used by escaping them, instead of depending where they occur.
There can be 2 escape characters '\' and '.'
Niki
___
Python-idea
On Wed, 2018-05-16 at 21:15 +1000, Steven D'Aprano wrote:
> On Wed, May 16, 2018 at 08:29:00AM +, Eloi Gaudry wrote:
> > Is there some interest in the proposal or should I finally close
> > this
> > thread ?
>
> I'm definitely interested in the concept, not the suggested syntax
> or
> semanti
On Wed, May 16, 2018 at 01:27:50PM +, Eloi Gaudry wrote:
> On Wed, 2018-05-16 at 21:15 +1000, Steven D'Aprano wrote:
> > On Wed, May 16, 2018 at 08:29:00AM +, Eloi Gaudry wrote:
> > > Is there some interest in the proposal or should I finally close
> > > this
> > > thread ?
> >
> > I'm def
Hello,
I have yet another idea regarding the the clashes between new keywords and
already used names. How about introducing two new keywords *wink* that
would serve as lexical keyword/nonkeyword declarations, similarly to
nonlocal and global declarations?
def f():
nonkeyword if
if = 2 # w
> Not if you need to make changes in the same tens of thousands of lines
file.
But what has that got to do with the the syntax of the new code? The old
code is
what it is.
I did think after I replied that `True` wasn't actually reserved until more
recently, but
the point still stands: You would b
> There can be 2 escape characters '\' and '.'
That's clever, but then we have to put a slash in front of names in
imports, assignments and keyword arguments, but not properties.
-- Carl Smith
[email protected]
On 16 May 2018 at 19:17, Carl Smith wrote:
> > Not if you need to make changes
On 5/16/2018 1:24 PM, Adam Bartoš wrote:
Hello,
I have yet another idea regarding the the clashes between new keywords
and already used names. How about introducing two new keywords *wink*
that would serve as lexical keyword/nonkeyword declarations, similarly
to nonlocal and global declaratio
If `def(if=3)...` works implicitly, then why not make `if = 3`, `x.if
= 3`, `import
if`, `def if` and `class if` implicit too?
Another issue is what happens here:
keyword if
import if
f(if=3)
f.if = 3
The keyword will be a valid name in old code, so you need to be able to
reference it as a name
Instead of verbatim identifiers, how about a special comment giving the
Python version in which the file was written?
There could then be a tool similar to 2to3 that converts the file to a
more recent version of Python that might have new reserved words. In
most cases the new file would merely
My proposal assumes we want to be able to reference the name as defined in
external libraries, but never have it be a name and a keyword in the same
namespace. Your proposal (and the others I've seen) seem to be deliberately
aiming to allow that.
Do you want to have keywords that are names in the
On Wed, May 16, 2018 at 2:17 PM, Carl Smith wrote:
> > Not if you need to make changes in the same tens of thousands of lines
> file.
>
> But what has that got to do with the the syntax of the new code? The old
> code is
> what it is.
>
>
Again, because you end up with hard-to-debug issues throug
> We can and do preempt someone sabotaging keywords by not letting anyone
override them.
> That is the whole point of using reserved keywords. Some languages allow
you to change
> important words, some don't. Guido made a conscious decision to make
certain words keywords,
> and to not let anyone c
Todd wrote:
The overall issue is that python has no way of knowing
if the keyword is being used for legitimate backwards-compatibility
purposes or someone intentionally overrode after it was made a keyword
because they somehow thought it was a good idea. That is why being
explicit about overr
On Thu, May 17, 2018 at 10:58:34AM +1200, Greg Ewing wrote:
> The trouble with explicitly overriding keywords is that it
> still requires old code to be changed whenever a new keyword
> is added, which as far as I can see almost competely defeats
> the purpose. If e.g. you need to change all uses
On Wed, May 16, 2018 at 08:02:47PM +0100, MRAB wrote:
> Instead of verbatim identifiers, how about a special comment giving the
> Python version in which the file was written?
>
> There could then be a tool similar to 2to3 that converts the file to a
> more recent version of Python that might ha
On 17May2018 10:33, Steven D'Aprano wrote:
On Wed, May 16, 2018 at 08:02:47PM +0100, MRAB wrote:
Instead of verbatim identifiers, how about a special comment giving the
Python version in which the file was written?
There could then be a tool similar to 2to3 that converts the file to a
more rec
On Wed, May 16, 2018 at 07:24:19PM +0200, Adam Bartoš wrote:
> Hello,
>
> I have yet another idea regarding the the clashes between new keywords and
> already used names. How about introducing two new keywords *wink* that
> would serve as lexical keyword/nonkeyword declarations, similarly to
> non
Steven D'Aprano wrote:
Let's say you're reading from a CSV file, creating an object from each
row, and processing it:
Okay, I can see it could be useful for situations like that.
But this is still a completely different use case from the
one that started this discussion, which was making it le
33 matches
Mail list logo
