Hi Ideas,
I often need to reference a script's current directory. I end up writing:
import os
SRC_DIR = os.path.dirname(__file__)
But I would prefer to have a new dunder for that. I propose: "__dir__". I
was wondering if others would find it convenient to include such a shortcut.
Here are so
[Nick]
>...
> There were a couple key reasons I left the "for x in y" case out of the
> initial proposal:
>
> 1. The "for x in y" header is already quite busy, especially when tuple
> unpacking is used in the assignment target
> 2. Putting the "given" clause at the end would make it ambiguous as to
Hi Vincent,
Your idea is interesting but we are worried that there are not enough real
use cases where it would be useful. Have you encountered situations
yourself where this would make a difference? I am asking not for clarifying
examples (you already provided one and from that it's perfectly cle
On 6 May 2018 at 07:59, Angus Hollands wrote:
> If, however, the motivation for the PEP was deemed significant enough that
> warrant its inclusion in a future release, then I would like to suggest
> that the keyword approach is superior to the operator variant. In
> particular, I prefer the `wher
On 6 May 2018 at 02:06, Nick Coghlan wrote:
> On 4 May 2018 at 22:06, Nick Coghlan wrote:
>
>> (Note: Guido's already told me off-list that he doesn't like the way this
>> spelling reads, but I wanted to share it anyway since it addresses one of
>> the recurring requests in the PEP 572 discussio
At some point, we're really better off just using a lambda.
Maybe I'm slow today, but I'm having trouble seeing how to write this as
a lambda.
>>> values = {'x': 43, 'y': 55}
>>> x, y, z = (lambda *args : tuple(values.get(arg,0) for arg in
args))('x','y','z')
>>> print(x, y, z)
(43, 55, 0)
>
Hi all!
Really interesting discussion on here.
Personally I feel that PEP 572, as it stands, undermines the readability of
the language, in particular for those new to the language, programming.
I have issue with both the in-expression assignment, and the current
proposed operator approach.
Below
[Tim]
... I liked the way he _reached_ that conclusion: by looking at real-
life Python code that may have been written instead to use constructs
"like this". I find such examination far more persuasive than abstract
arguments or made-up examples.
[Serhiy]
>>> I would like to
On 4 May 2018 at 22:06, Nick Coghlan wrote:
> (Note: Guido's already told me off-list that he doesn't like the way this
> spelling reads, but I wanted to share it anyway since it addresses one of
> the recurring requests in the PEP 572 discussions for a more targeted
> proposal that focused speci
On 5 May 2018 at 13:36, Tim Peters wrote:
> [Nick Coghlan ]
> > ...
> > The essence of the given clause concept would be to modify *these
> specific
> > cases* (at least initially) to allow the condition expression to be
> followed
> > by an inline assignment, of the form "given TARGET = EXPR".
>
05.05.18 18:04, Eloi Gaudry пише:
By 'self-contained', I meant that using the assert keyword and its
expression is sufficient. An inline assertive expression as the one you
describe does not fulfill this assert requirement.
Sufficient for what? And why writing with using the existing syntax is
05.05.18 18:26, Nick Coghlan пише:
3. writing back to the local namespace via exec doesn't work
consistently at function scope (and assuming PEP 558 is eventually
accepted, will some day reliably *never* work)
At end you can convert the source of the whole script to a string
literal and write
On Sat, May 05, 2018 at 08:04:45AM +, Eloi Gaudry wrote:
> Hi folks,
> I intend to add a runtime assertion feature in python.
I'm very interested in this idea, but I'm afraid your draft PEP isn't
very clear about this feature. Comments below.
> Rationale
> There is no runtime assert relyin
On 6 May 2018 at 00:33, Mikhail V wrote:
> recently I have discovered interesting fact: it seems one
> can already use 'inline assignment' with current syntax. E.g.:
>
> if exec("m = input()") or m:
> print (m)
>
> It seem to work as inline assignment correctly.
> Yes it is just coincidence,
By 'self-contained', I meant that using the assert keyword and its expression
is sufficient. An inline assertive expression as the one you describe does not
fulfill this assert requirement.
My proposal is simply to extend the current assert to non-debug builds and
allow to switch it off/on at r
On Fri, May 4, 2018 at 3:06 PM, Nick Coghlan wrote:
>
> With that spelling, the three examples above would become:
>
> # Exactly one branch is executed here
> if m given m = pattern.search(data):
> ...
> elif m given m = other_pattern.search(data)):
> ...
> else:
>
05.05.18 15:54, Eloi Gaudry пише:
I meant avoiding the overhead of the expression evaluation enclosed in the
assert itself, not the active/disabled state (that comes at virtually no cost).
ex:
runtime_assert( { i:None for i in range( 1000 ) } )
By using the syntax you describe ('boolean a
I meant avoiding the overhead of the expression evaluation enclosed in the
assert itself, not the active/disabled state (that comes at virtually no cost).
ex:
>>> runtime_assert( { i:None for i in range( 1000 ) } )
By using the syntax you describe ('boolean and not expr'), you loose all the
05.05.18 11:04, Eloi Gaudry пише:
Briefly, the idea is to add a new assert that can be switch on/off
depending on some variable/mechanism at runtime. The whole point of
this assert is that it should not bring any overhead when off, i.e.
by avoiding evaluating the expression enclos
Hi folks,
I intend to add a runtime assertion feature in python. Before submitting a PEP,
I am sending a draft to this mailing list to discuss whether it would make
sense (above this message). I have actually been using it for the last 2 years
and it has proven to be robust and has achieved its
I think that "expr as y" was discarded too quickly.
It would be a syntax completely familiar to Python programmers, and the new
semantics would be obvious. That choice would also be in line with the Zen
of Python.
The special cases that may arise over "except" and "with" can be worked
out and
I agree it would be useful to have new keywords without being reserved, and
we could even go with mechanism like infix operators created by user.
It would allow things like [given for x in range(5) given given = x+1] or
even [given for given in range(given) given given = given + 1] haha, but as
ot
Tim Peters wrote:
"async def", "async for", and "async with" statements were added
_without_ making "async" a new reserved word. It may require pain in
the parser, but it's often doable anyway.
There would be less pain if the parser generator could
deal with non-reserved keywords more directly
23 matches
Mail list logo
