For what it's worth, i'm totally +1 on inline uses of global and nonlocal.
As a related improvement, i'd also like it if "global x = 5" would be
a legal statement. As a noob learning python, I was suprised to find
out I couldn't and had to split it on two lines.(aside from a 9-hour
course of C and
I didn't mean to replace the current (debug) assert but I wanted to add another
one that would allow to be switch on or off on production builds.
The need for a new keyword (not syntax) comes from this difference.
I cannot think of another example that would convince you of the benefit of
hav
On Sun, May 06, 2018 at 09:33:03PM -0700, Nathaniel Smith wrote:
> How is
>
> data_path = __filepath__.parent / "foo.txt"
>
> more distracting than
>
> data_path = joinpath(dirname(__file__), "foo.txt")
Why are you dividing by a string? That's weird.
[looks up the pathlib docs]
Oh, that's w
On Mon, May 7, 2018, 03:45 Steven D'Aprano wrote:
> On Sun, May 06, 2018 at 09:33:03PM -0700, Nathaniel Smith wrote:
>
> > How is
> >
> > data_path = __filepath__.parent / "foo.txt"
> >
> > more distracting than
> >
> > data_path = joinpath(dirname(__file__), "foo.txt")
>
>
> Why are you dividing
On Mon, May 07, 2018 at 12:48:53PM +1000, Chris Angelico wrote:
> On Mon, May 7, 2018 at 12:34 PM, Tim Peters wrote:
> > There's a difference, though: if `y` "leaks", BFD. Who cares? ;-)
> > If `y` remains inaccessible, there's no way around that.
>
> That's Steve D'Aprano's view - why not jus
On 7 May 2018 at 20:44, Steven D'Aprano wrote:
> First I have to work out what __filepath__ is, then I have to remember
> the differences between all the various flavours of pathlib.Path
> and suffer a moment or two of existential dread as I try to work out
> whether or not *this* specific flavou
On 7 May 2018 at 21:42, Nathaniel Smith wrote:
> On Mon, May 7, 2018, 03:45 Steven D'Aprano wrote:
>
>> On Sun, May 06, 2018 at 09:33:03PM -0700, Nathaniel Smith wrote:
>>
>> > How is
>> >
>> > data_path = __filepath__.parent / "foo.txt"
>> >
>> > more distracting than
>> >
>> > data_path = join
On Mon, May 7, 2018 at 9:42 PM, Steven D'Aprano wrote:
> On Mon, May 07, 2018 at 12:48:53PM +1000, Chris Angelico wrote:
>> On Mon, May 7, 2018 at 12:34 PM, Tim Peters wrote:
>
>> > There's a difference, though: if `y` "leaks", BFD. Who cares? ;-)
>> > If `y` remains inaccessible, there's no wa
On Mon, May 7, 2018 at 8:44 PM, Steven D'Aprano wrote:
> On Sun, May 06, 2018 at 09:33:03PM -0700, Nathaniel Smith wrote:
>
>> How is
>>
>> data_path = __filepath__.parent / "foo.txt"
>>
>> more distracting than
>>
>> data_path = joinpath(dirname(__file__), "foo.txt")
>
>
> Why are you dividing by
06.05.18 09:53, Yuval Greenfield пише:
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
On Sun, 2018-05-06 at 01:30 +1000, Steven D'Aprano wrote:
> 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
07.05.18 12:58, Eloi Gaudry пише:
I didn't mean to replace the current (debug) assert but I wanted to add
another one that would allow to be switch on or off on production builds.
The need for a new keyword (not syntax) comes from this difference.
I cannot think of another example that woul
On Mon, May 07, 2018 at 10:38:51PM +1000, Chris Angelico wrote:
> On Mon, May 7, 2018 at 9:42 PM, Steven D'Aprano wrote:
[...]
> > (3) A compromise: binding assignments are scoped local to the
> > comprehension, but they are initialised from their surrounding scope.
[...]
> Does it HAVE to be init
On Mon, May 7, 2018 at 7:14 AM, Serhiy Storchaka wrote:
> * Additional burden on maintainers of import machinery. It is already too
> complex, and __file__ is set in multiple places. Don't forgot about
> third-party implementations.
>
> See also issue33277: "Deprecate __loader__, __package__, __fi
07.05.18 17:42, Eric Snow пише:
I'm not necessarily saying we should add ModuleSpec.dirname(), but it
(or something like it) is what I'd advocate for *if* we were to add a
convenient shortcut to the directory a module is in. FWIW, I'd
probably use it.
The question is *why* you need the absolut
Hi,
I'd like to bring back this discussion (from 2005, by Greg):
https://bugs.python.org/issue1229239
Briefly, non-heap types cannot have their
attributes changed by Python code. This makes sense for python builtin
types, but not for the types defined in extension/modules.
As we have been using
On Mon, May 07, 2018 at 11:42:00AM +, Nathaniel Smith wrote:
> On Mon, May 7, 2018, 03:45 Steven D'Aprano wrote:
[...]
> > So yes, its very distracting.
>
> Well, yes, you do have to know the API to use it, and if you happen to have
> learned the os.path API but not the pathlib API then of c
On Tue, May 8, 2018 at 12:26 AM, Steven D'Aprano wrote:
> Here's a sketch of how I think locals are currently handled:
>
> 1. When a function is compiled, the compiler does a pass over the
>source and determines which locals are needed.
>
> 2. The compiler builds an array of slots, one for eac
On Mon, 7 May 2018 at 08:17 Serhiy Storchaka wrote:
> 07.05.18 17:42, Eric Snow пише:
> > I'm not necessarily saying we should add ModuleSpec.dirname(), but it
> > (or something like it) is what I'd advocate for *if* we were to add a
> > convenient shortcut to the directory a module is in. FWIW,
On Sun, May 6, 2018 at 9:30 PM, Mike Miller
wrote:
> On 2018-05-06 19:13, Nick Coghlan wrote:
>
>> Specifically, the ones I'd have in mind would be:
>>
>> - dirname (aka os.path.dirname)
>> - joinpath (aka os.path.join)
>> - abspath (aka os.path.abspath)
>>
> Yes, I end up importing those in most
On Mon, 7 May 2018 at 06:28 Serhiy Storchaka wrote:
> 07.05.18 12:58, Eloi Gaudry пише:
> > I didn't mean to replace the current (debug) assert but I wanted to add
> > another one that would allow to be switch on or off on production builds.
> >
> > The need for a new keyword (not syntax) comes f
I am convinced by Tim's motivation. I hadn't thought of this use case
before -- I had mostly thought "local scope in a comprehension or generator
expression is the locals of the synthetic function". But Tim's reasoning
feels right.
The only solution that makes sense to me is Steven's (2). (1) is w
On Mon, May 7, 2018 at 6:24 AM, Serhiy Storchaka
wrote:
> I just don't understand why you need a new keyword for writing runtime
> checks.
>
Oh, that's pretty clear. The OP wants to be able to turn these checks off
with some flag he can set/clear at runtime, and when it's off he doesn't
want to
On Fri, 4 May 2018 at 05:07 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 s
On 2018-05-07 09:17, Steven D'Aprano wrote:
I'm arguing that for some people, your preferred syntax*is* more
distracting and hard to comprehend than the more self-descriptive
version with named functions. And its not just a matter of*learning*
the API, it is a matter of using it so often that it
On 2018-05-06 18:32, Tim Peters wrote:
In a different thread I noted that I sometimes want to write code like this:
while any(n % p == 0 for p in small_primes):
# divide p out - but what's p?
But generator expressions hide the value of `p` that succeeded, so I
can't. `any()` and
Hi everybody,
> Have you encountered situations yourself where this would make a difference ?
I need to get multiple objects in several dicts using the same set of keys.
I wanted to use itemgetter to reduce the number of lines of code but I
have mixed up getattr/dict.get
that have default paramet
[Guido]
> I am convinced by Tim's motivation. I hadn't thought of this use case before
> -- I had mostly thought "local scope in a comprehension or generator
> expression is the locals of the synthetic function". But Tim's reasoning
> feels right.
I'm trying very hard _not_ to reason. That is, I'
[Tim]
>> In a different thread I noted that I sometimes want to write code like
>> this:
>>
>> while any(n % p == 0 for p in small_primes):
>> # divide p out - but what's p?
>>
>> But generator expressions hide the value of `p` that succeeded, so I
>> can't. `any()` and `all()` can't
[Tim]
> While I don't have real use cases beyond that, given that much,
> "consistency" kicks in to suggest that:
>
> def f():
> [x := 42 for x in range(1)]
>
> makes `x` local to `f` despite that x wasn't bound elsewhere in f's body.
>
> def f():
> global x
> [x :
On 05/07/18 11:37, Eloi Gaudry wrote:
Hi,
I'd like to bring back this discussion (from 2005, by Greg):
https://bugs.python.org/issue1229239
Briefly, non-heap types cannot have their
attributes changed by Python code. This makes sense for python builtin
types, but not for the types defined in ex
Regular expressions are not just "an order of magnitude better"—they're
asymptotically faster.
See https://en.wikipedia.org/wiki/Knuth%E2%80%93Morris%E2%80%93Pratt_algorithm
for a non-regular-expression algorithm.
On Thursday, April 26, 2018 at 5:45:20 AM UTC-4, Jacco van Dorp wrote:
>
> or bu
On 5/7/2018 1:38 PM, Guido van Rossum wrote:
I am convinced by Tim's motivation. I hadn't thought of this use case
before -- I had mostly thought "local scope in a comprehension or
generator expression is the locals of the synthetic function". But Tim's
reasoning feels right.
The only solutio
[Terry Reedy ]
> ...
> If I am understanding correctly, this would also let one *intentionally
> 'leak' (export) the last value of the loop variable when wanted.
>
> [math.log(xlast:=x) for x in it if x > 0]
> print(xlast)
Yup! You can do that today by emulating a nonlocal "cell" reference,
but I
(1)
On 7 May 2018 at 01:07, Raymond Hettinger
wrote:
> He could've written:
>
> get = rpartial(getattr, 'foo', None)
> return get(args) or get(config) or get(env)
>
That's somewhat hybrid, it would behave like:
lambda obj: getattr(obj, "foo", None),
but one might expect a "reversed pa
On Mon, May 07, 2018 at 10:38:09AM -0700, Guido van Rossum wrote:
> The only solution that makes sense to me is Steven's (2). (1) is what the
> PEP currently says and what Tim doesn't want; (3) has no precedent
> (function defaults don't really work like this) and just gets my hackles
> all up. (I
I posted this several weeks ago, just for fun - an obscure but
surprisingly brief Python implementation of itertools.tee, sharing a
single stream (as a singly linked list) among all the returned
iterables.
Didn't think about it again until today, when recent discussions of
lexical scoping made me
[Tim]
> ... The ":= is treated specially in comprehensions" idea is aimed
> more at them than at people who think invoking a synthetic
> anonymous lambda "is obvious".
It occurs to me that, while suggestive, this is an unhelpful way to
express it. It's not at all that the semantics of ":=" change
Yuval Greenfield wrote:
I often need to reference a script's current directory. I end up writing:
import os
SRC_DIR = os.path.dirname(__file__)
The question I have is, why do you want to reference the script's
current directory?
If the answer is to access other files in that directory, the
In a lot of uses of os.walk it is desirable to skip version control
directories, (which are usually hidden directories), to the point that
almost all of the examples given look like:
import os
for root, dirs, files in os.walk(some_dir):
if 'CVS' in dirs:
dirs.remove('CVS') # or .s
2018-05-07 21:56 GMT+02:00 Neil Girdhar :
> Regular expressions are not just "an order of magnitude better"—they're
> asymptotically faster. See
> https://en.wikipedia.org/wiki/Knuth%E2%80%93Morris%E2%80%93Pratt_algorithm
> for a non-regular-expression algorithm.
Hence my
>> [Jacco wrote, capita
41 matches
Mail list logo