Re: [Python-ideas] A comprehension scope issue in PEP 572

> Implementation details - even just partial sketches - are always > "busy". Think of it this way instead: it's _currently_ the case that > listcomps & genexps run in a scope S that's the same as the scope C > that contains them, _except_ that names appearing as `for` targets are > local to S.

Re: [Python-ideas] Runtime assertion with no overhead when not active

My choice of words might not be the best, yes. I do see to different meanings and/or context for the historical assert and the one I propose: 1/ the first one would be something saying that, as a developer, when writing >>> assert (expr) in my python code, I mean that all my unit tests and

Re: [Python-ideas] Runtime assertion with no overhead when not active

On Wed, May 9, 2018 at 5:27 AM, Eloi Gaudry wrote: > My choice of words might not be the best, yes. > I do see to different meanings and/or context for the historical assert and > the one I propose: > > 1/ > the first one would be something saying that, as a developer, when

Re: [Python-ideas] A comprehension scope issue in PEP 572

[Guido] >> So the way I envision it is that *in the absence of a nonlocal or global >> declaration in the containing scope*, := inside a comprehension or genexpr >> causes the compiler to assign to a local in the containing scope, which is >> elevated to a cell (if it isn't already). If there is

Re: [Python-ideas] A comprehension scope issue in PEP 572

On Tue, May 08, 2018 at 01:28:59PM -0400, Juancarlo Añez wrote: > So the way I envision it is that *in the absence of a nonlocal or global > > declaration in the containing scope*, := inside a comprehension or genexpr > > causes the compiler to assign to a local in the containing scope, which is >

Re: [Python-ideas] A comprehension scope issue in PEP 572

These all match my expectations. Some glosses: [Guido] > So the way I envision it is that *in the absence of a nonlocal or global > declaration in the containing scope*, := inside a comprehension or genexpr > causes the compiler to assign to a local in the containing scope, which is > elevated

Re: [Python-ideas] Runtime assertion with no overhead when not active

On Wed, May 9, 2018 at 1:51 AM, Eloi Gaudry wrote: > I think that is a difference between: > - the current 'assert' which usage seems (to me) to focus on > development correctness (I think of it as the C-assert enabled in any C > program in debug build ) > - the runtime_assert

Re: [Python-ideas] A comprehension scope issue in PEP 572

So the way I envision it is that *in the absence of a nonlocal or global > declaration in the containing scope*, := inside a comprehension or genexpr > causes the compiler to assign to a local in the containing scope, which is > elevated to a cell (if it isn't already). If there is an explicit

Re: [Python-ideas] A comprehension scope issue in PEP 572

So the way I envision it is that *in the absence of a nonlocal or global declaration in the containing scope*, := inside a comprehension or genexpr causes the compiler to assign to a local in the containing scope, which is elevated to a cell (if it isn't already). If there is an explicit nonlocal

Re: [Python-ideas] Runtime assertion with no overhead when not active

On Wed, 2018-05-09 at 01:34 +1000, Steven D'Aprano wrote: > On Tue, May 08, 2018 at 07:37:55AM +, Eloi Gaudry wrote: > > > * debug assert, for helping developing a new features, used with > > debug- > > builds > > * runtime assert, for ensuring correctness and/or diagnosing issue > > with > >

Re: [Python-ideas] A comprehension scope issue in PEP 572

[Tim] >> (inside a synthetic function created to >> implement a listcomp/genexp, names bound by "=" are local; names bound >> by ":=" are nonlocal; names bound by both are "who cares?"- >> compiler-time error would be fine by me, or the first person to show a >> real use case wins). [Jacco van

Re: [Python-ideas] Runtime assertion with no overhead when not active

08.05.18 18:34, Steven D'Aprano пише: I don't even know which builds of Python I'm running. My *guess* is that the OS-provided Python is probably a non-debug build, and the ones I've compiled from source will be whatever the default build settings are, but I don't know what that is or how to

Re: [Python-ideas] Runtime assertion with no overhead when not active

On Tue, 2018-05-08 at 09:58 -0400, Eric V. Smith wrote: > I think what's confusing to me (and maybe others) is that we haven't  > seen your vision on how this would look in Python code. > > An example that would throw runtime assertions and the same example  > where it wouldn't (after a global

Re: [Python-ideas] Runtime assertion with no overhead when not active

07.05.18 20:52, Guido van Rossum пише: He basically wants a macro so that   runtime_assert() expands to   if and ():   raise AssertionError In Lisp this would be easy. :-) Python is not Lisp (still). But there is the MacroPy project. And at end you always can use an external tool

Re: [Python-ideas] Please consider skipping hidden directories in os.walk, os.fwalk, etc.

On Mon, May 7, 2018, at 02:05, Steve Barnes wrote: > 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: CVS isn't a hidden directory on Linux. Maybe it can be

Re: [Python-ideas] Runtime assertion with no overhead when not active

On Tue, May 08, 2018 at 09:58:51AM -0400, Eric V. Smith wrote: > I think what's confusing to me (and maybe others) is that we haven't > seen your vision on how this would look in Python code. > > An example that would throw runtime assertions and the same example > where it wouldn't (after a

Re: [Python-ideas] Runtime assertion with no overhead when not active

On Tue, May 08, 2018 at 07:37:55AM +, Eloi Gaudry wrote: > * debug assert, for helping developing a new features, used with debug- > builds > * runtime assert, for ensuring correctness and/or diagnosing issue with > production/release-builds on-site. I don't think that is a useful

Re: [Python-ideas] Please consider skipping hidden directories in os.walk, os.fwalk, etc.

On Tue, May 8, 2018 at 2:00 PM, David Mertz wrote: > I like the idea. I think an argument to os.walk() is the simplest option > for most users. But per some comments, "hidden" is actually more subtle > than the filesystem bit sometimes. I.e. dot-files, ~ suffix, maybe .bak, >

Re: [Python-ideas] Runtime assertion with no overhead when not active

On Tue, 2018-05-08 at 07:37 -0700, Guido van Rossum wrote: > > > In Lisp this would be easy. :-) > > > > and he already has a diff ready for review if needed (basically > > very > > similar to the current 'assert' implementation :) > > That seems premature. There is not even a hint of agreement

Re: [Python-ideas] Runtime assertion with no overhead when not active

On Tue, May 8, 2018 at 12:29 AM, Eloi Gaudry wrote: > On Mon, 2018-05-07 at 10:52 -0700, Guido van Rossum wrote: > > 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 > > >

Re: [Python-ideas] Please consider skipping hidden directories in os.walk, os.fwalk, etc.

On Tue, May 8, 2018 at 2:31 AM, Oleg Broytman wrote: >So anyone who wants to filter os.walk() must reimplement os.walk() > themselves instead of passing something like filter_dir and filter_file > (or accept_dir/accept_file) to os.walk()? Kind of painful, no? > ​Not really.

Re: [Python-ideas] Runtime assertion with no overhead when not active

On Tue, 2018-05-08 at 09:35 -0400, Eric V. Smith wrote: > On 5/8/2018 3:37 AM, Eloi Gaudry wrote: > > On Mon, 2018-05-07 at 16:56 +, Brett Cannon wrote: > > > > > > My question is how is this different to running with -O which > > > leaves > > > the assert statement out of the bytecode and so

Re: [Python-ideas] Runtime assertion with no overhead when not active

On 5/8/2018 9:50 AM, Eloi Gaudry wrote: On Tue, 2018-05-08 at 09:35 -0400, Eric V. Smith wrote: On 5/8/2018 3:37 AM, Eloi Gaudry wrote: On Mon, 2018-05-07 at 16:56 +, Brett Cannon wrote: My question is how is this different to running with -O which leaves the assert statement out of the

Re: [Python-ideas] Runtime assertion with no overhead when not active

On 5/8/2018 3:37 AM, Eloi Gaudry wrote: On Mon, 2018-05-07 at 16:56 +, Brett Cannon wrote: My question is how is this different to running with -O which leaves the assert statement out of the bytecode and so you avoid any run- time cost of the statement entirely? Not so much different,

Re: [Python-ideas] Runtime assertion with no overhead when not active

On Mon, 2018-05-07 at 16:56 +, Brett Cannon wrote: > > My question is how is this different to running with -O which leaves > the assert statement out of the bytecode and so you avoid any run- > time cost of the statement entirely?  Not so much different, except that: - the switch won't need

Re: [Python-ideas] Please consider skipping hidden directories in os.walk, os.fwalk, etc.

I like the idea. I think an argument to os.walk() is the simplest option for most users. But per some comments, "hidden" is actually more subtle than the filesystem bit sometimes. I.e. dot-files, ~ suffix, maybe .bak, etc. I'd suggest meeting the ideas slightly and making the new argument

Re: [Python-ideas] Add "default" kw argument to operator.itemgetter and operator.attrgetter

On Tue, May 08, 2018 at 10:13:43AM +0200, Vincent Maillol wrote: > Perhaps something like: > > > > > >>> itemgetter(-1, 0, -2, > > ...default0="first argument default", > > ...default1=["second", "argument", "default"], > > ...default={"global": "default"}, >

Re: [Python-ideas] Please consider skipping hidden directories in os.walk, os.fwalk, etc.

Hi! On Tue, May 08, 2018 at 07:12:35AM +, Yuval Greenfield wrote: > If you > want to avoid duplicate `stat` calls, you'll probably write: > > import os > import stat > def is_hidden(st): > return bool(st.st_file_attributes & stat.FILE_ATTRIBUTE_HIDDEN) > def

Re: [Python-ideas] Allow mutable builtin types (optionally)

On Mon, 2018-05-07 at 15:23 -0400, Petr Viktorin wrote: > On 05/07/18 11:37, Eloi Gaudry wrote: > > I mean, to my knowledge, there is no reason why a type should be > > allocated on the heap (https://docs.python.org/2/c-api/typeobj.html > > ) to > > be able to change its attributes at Python

Re: [Python-ideas] Add "default" kw argument to operator.itemgetter and operator.attrgetter

> > As attrgetter/itemgetter might get heterogeneus data, I would expect a > per-get default, not [just] a global default. > +1 Perhaps something like: > > >>> itemgetter(-1, 0, -2, > ...default0="first argument default", > ...default1=["second", "argument", "default"], >

Re: [Python-ideas] Runtime assertion with no overhead when not active

On Mon, 2018-05-07 at 10:52 -0700, Guido van Rossum wrote: > 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

Re: [Python-ideas] A comprehension scope issue in PEP 572

> [Tim] > (inside a synthetic function created to > implement a listcomp/genexp, names bound by "=" are local; names bound > by ":=" are nonlocal; names bound by both are "who cares?"- > compiler-time error would be fine by me, or the first person to show a > real use case wins). Wait, you can't

Re: [Python-ideas] Please consider skipping hidden directories in os.walk, os.fwalk, etc.

On Mon, May 7, 2018 at 9:44 PM Steve Barnes wrote: > Since the implementation of os.walk has changed to use os.scandir which > exposes the returned file statuses in the os.DirEntry.stat() the > overhead should be minimal. > > An alternative would be to add another new

Re: [Python-ideas] Please consider skipping hidden directories in os.walk, os.fwalk, etc.

On Mon, May 07, 2018 at 06:05:15AM +, Steve Barnes wrote: > 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

Re: [Python-ideas] Delivery Status Notification (Failure)

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