Re: [Python-ideas] PEP 572: Statement-Local Name Bindings, take three!

On Sat, Mar 24, 2018 at 3:41 PM, Steven D'Aprano <st...@pearwood.info> wrote: > To keep this a manageable length, I've trimmed vigourously. Apologies in > advance if I've been too enthusiastic with the trimming :-) > > On Sat, Mar 24, 2018 at 05:09:54AM +1100, Chris Angelico

Re: [Python-ideas] PEP 572 version 2: Statement-Local Name Bindings

On Sat, Mar 24, 2018 at 8:07 PM, Christoph Groth <christ...@grothesque.org> wrote: > Chris Angelico wrote: > >> Thank you; both of these have now been incorporated into the document. > > Thanks! Just a small comment. You wrote in the PEP draft: > >> # Name bi

Re: [Python-ideas] PEP 572 version 2: Statement-Local Name Bindings

On Sat, Mar 24, 2018 at 10:49 PM, Paul Moore <p.f.mo...@gmail.com> wrote: > On 24 March 2018 at 09:18, Chris Angelico <ros...@gmail.com> wrote: >> Except that a list comprehension is implemented using an inner >> function. Very approximately: >> >> x = [n

Re: [Python-ideas] PEP 572 version 2: Statement-Local Name Bindings

On Sat, Mar 24, 2018 at 11:06 PM, Paul Moore <p.f.mo...@gmail.com> wrote: > On 24 March 2018 at 11:55, Chris Angelico <ros...@gmail.com> wrote: >> On Sat, Mar 24, 2018 at 10:49 PM, Paul Moore <p.f.mo...@gmail.com> wrote: >>> On 24 March 2018 at 09:18, Chr

Re: [Python-ideas] PEP 572 version 2: Statement-Local Name Bindings

On Sat, Mar 24, 2018 at 3:16 PM, Masayuki YAMAMOTO wrote: > FWIW, I thought another way which provides cache object library, it seems to > just work in some cases. But it doesn't create statement local scope and > might be difficult to read because looks ordinary

Re: [Python-ideas] Class autoload

On Sun, Mar 4, 2018 at 4:12 AM, Jamesie Pic wrote: > > Hello everybody, > > I thought perhaps we could allow the usage of a "new" keyword to instanciate > an object, ie: > >obj = new yourmodule.YourClass() > > In this case, it would behave the same as from yourmodule import

Re: [Python-ideas] An alternative to PEP 572's Statement-Local Name Bindings

On Mon, Mar 5, 2018 at 2:39 PM, Mike Miller wrote: > > On 2018-03-03 16:51, Greg Ewing wrote: >>> >>> 2018-03-03 8:40 GMT+01:00 Nick Coghlan : pairs = [(f(y), g(y)) for x in things with bind(h(x)) as y] >> >> >> I don't mucn like "with

Re: [Python-ideas] An alternative to PEP 572's Statement-Local Name Bindings

On Mon, Mar 5, 2018 at 2:49 PM, Mike Miller wrote: > Yes, thanks: > > [ f(y), g(y) for x, h(x) as y in things ] > > > Dyslexics untie! :) Hmm. The trouble here is that a 'for' loop is basically doing assignment. When you say "for x, h(x) as y in things", what

Re: [Python-ideas] PEP 572 version 2: Statement-Local Name Bindings

On Sat, Mar 3, 2018 at 1:53 AM, Rhodri James <rho...@kynesim.co.uk> wrote: > On 02/03/18 11:43, Chris Angelico wrote: >> >> After dozens of posts and a wide variety of useful opinions and >> concerns being raised, here is the newest version of PEP 572 for your >> d

Re: [Python-ideas] PEP 572 version 2: Statement-Local Name Bindings

On Sat, Mar 3, 2018 at 5:27 AM, Jelle Zijlstra wrote: > > > 2018-03-02 7:03 GMT-08:00 Robert Vanden Eynde : >> >> +1 on extracting the big win for "if" and "while" (the regex case is >> wonderul). It would be see as an "extended if/while" rather

Re: [Python-ideas] PEP 572 version 2: Statement-Local Name Bindings

On Sat, Mar 3, 2018 at 5:30 AM, Brendan Barnwell wrote: > But if that's the case, maybe what we want is actually another thing > that's been discussed many times on this list, namely something like a > with-block that can define "super-local" variables that

Re: [Python-ideas] PEP 572 version 2: Statement-Local Name Bindings

On Sat, Mar 3, 2018 at 7:04 AM, Eric Fahlgren wrote: > > On Fri, Mar 2, 2018 at 10:27 AM, Jelle Zijlstra > wrote: >> >> >> I wonder if we could have a more limited change to the language that would >> allow only the as/while use cases.

Re: [Python-ideas] PEP 572 version 2: Statement-Local Name Bindings

On Sat, Mar 3, 2018 at 6:55 AM, Robert Vanden Eynde wrote: > @Rhodri, this is what Everybody does because you hit the "reply to all" > button, but, we don't receive two copies on the mail, I don't know why (but > that's a good thing). > > Le 2 mars 2018 20:48, "Rhodri James"

Re: [Python-ideas] PEP 572 version 2: Statement-Local Name Bindings

On Sat, Mar 3, 2018 at 7:31 AM, Brendan Barnwell <brenb...@brenbarn.net> wrote: > On 2018-03-02 12:20, Chris Angelico wrote: >> >> On Sat, Mar 3, 2018 at 7:04 AM, Eric Fahlgren <ericfahlg...@gmail.com> >> wrote: >>> >>> >>> On F

Re: [Python-ideas] PEP 572 version 2: Statement-Local Name Bindings

On Sat, Mar 3, 2018 at 7:23 PM, Ethan Furman <et...@stoneleaf.us> wrote: > On 03/02/2018 07:30 PM, Chris Angelico wrote: >> >> On Sat, Mar 3, 2018 at 12:48 PM, Greg Ewing wrote: >>> >>> Chris Angelico wrote: >>>> >>>> >>>>

Re: [Python-ideas] PEP 572 version 2: Statement-Local Name Bindings

On Sat, Mar 3, 2018 at 7:47 AM, Robert Vanden Eynde wrote: >> And please, don't top-post. Again, if your mail client encourages top >> posting, either override it, or get a better one. > > @Chris @Rohdri (@Jonathan below) > > For morons like me who didn't know what

Re: [Python-ideas] PEP 572 version 2: Statement-Local Name Bindings

On Sat, Mar 3, 2018 at 12:48 PM, Greg Ewing <greg.ew...@canterbury.ac.nz> wrote: > Chris Angelico wrote: >> >> It would NOT work for anything where the bool() of >> the desired object doesn't exactly match the loop's condition. > > >wh

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings

t; useful Python enhancement (and reduce the newsgroup churn :-)). Thanks :) It's one of those PEPs that can be immensely useful even if it's rejected. > On 27/02/2018 22:27, Chris Angelico wrote: > Programming is all about reusing code rather than duplicating it. When > an expression needs

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings

On Wed, Feb 28, 2018 at 3:38 PM, Rob Cliffe via Python-ideas wrote: > > Hm, apologies. This is in complete contrast to my previous post, where I > was pretty enthusiastic about Chris's PEP. But I can't resist sharing these > thoughts ... > > There was some vague

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings

On Wed, Feb 28, 2018 at 4:52 PM, Robert Vanden Eynde wrote: > Hello Chris and Rob, > > did you compare your proposal tothe subject called "[Python-ideas] Temporary > variables in comprehensions" on this month list ? Yes, I did; that's one of many threads on the subject, and

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings

On Thu, Mar 1, 2018 at 12:49 AM, Serhiy Storchaka <storch...@gmail.com> wrote: > 28.02.18 00:27, Chris Angelico пише: >> >> Example usage >> = >> >> These list comprehensions are all approximately equivalent:: >> >> # Calling the

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings

On Wed, Feb 28, 2018 at 10:49 PM, Paul Moore <p.f.mo...@gmail.com> wrote: > On 27 February 2018 at 22:27, Chris Angelico <ros...@gmail.com> wrote: >> This is a suggestion that comes up periodically here or on python-dev. >> This proposal introduces a way to bind a

[Python-ideas] PEP 572: Statement-Local Name Bindings

://www.python.org/dev/peps/pep-0572/ ChrisA PEP: 572 Title: Syntax for Statement-Local Name Bindings Author: Chris Angelico <ros...@gmail.com> Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 28-Feb-2018 Python-Version: 3.8 Post-History: 28-Feb-2018 Abstract Programming

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings

On Thu, Mar 1, 2018 at 1:51 AM, Serhiy Storchaka <storch...@gmail.com> wrote: > 28.02.18 16:06, Chris Angelico пише: >> >> On Thu, Mar 1, 2018 at 12:49 AM, Serhiy Storchaka <storch...@gmail.com> >> wrote: >>> >>> Other options: >>> &

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings

On Thu, Mar 1, 2018 at 2:20 AM, Serhiy Storchaka <storch...@gmail.com> wrote: > 28.02.18 08:52, Chris Angelico пише: >> >> A new version of the PEP has been pushed, and should be live within a >> few minutes. >> >> https://www.python.org/dev/peps/pep-0572/ &g

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings

On Thu, Mar 1, 2018 at 2:46 AM, Paul Moore <p.f.mo...@gmail.com> wrote: > On 28 February 2018 at 15:18, Chris Angelico <ros...@gmail.com> wrote: > >>> a = (2 as a) >>> >>> there is a temporary variable 'a', which gets assigned 2, and the SLNB

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings

On Thu, Mar 1, 2018 at 2:16 AM, Serhiy Storchaka <storch...@gmail.com> wrote: > 28.02.18 16:56, Chris Angelico пише: >>>>> >>>>> def g(): >>>>> for x in range(5): >>>>> y = f(x) >>>>&g

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings

On Thu, Mar 1, 2018 at 2:10 AM, Ethan Furman wrote: > dis.dis may be great, but so is running the function so everyone can see the > output. ;) Oh, sorry. >>> f() 1 > If I understood your explanation, `print(a)` produces `1` ? That seems > wrong -- the point of

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings

On Thu, Mar 1, 2018 at 2:25 AM, Ethan Furman <et...@stoneleaf.us> wrote: > On 02/28/2018 02:43 AM, Chris Angelico wrote: >> >> On Wed, Feb 28, 2018 at 8:04 PM, Robert Vanden Eynde wrote: > > >>> 3) "C problem that an equals sign in an expression can n

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings

On Wed, Feb 28, 2018 at 6:46 PM, Matt Arcidy wrote: > I have been struggling to justify the need based on what I have read. I > hope this isn't a dupe, I only saw caching mentioned in passing. > > Also please excuse some of the naive generalizations below for illustrative >

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings

On Fri, Mar 2, 2018 at 5:39 PM, Ethan Furman wrote: > Seems like it would far easier and (IMHO) more useful to scale the proposal > back from a statement scope to simple expression assignment, and the > variable is whatever scope it would have been if assigned to outside the >

Re: [Python-ideas] PEP 572 version 2: Statement-Local Name Bindings

On Fri, Mar 2, 2018 at 10:56 PM, Paul Moore <p.f.mo...@gmail.com> wrote: > On 2 March 2018 at 11:43, Chris Angelico <ros...@gmail.com> wrote: >> After dozens of posts and a wide variety of useful opinions and >> concerns being raised, here is the newest version of P

[Python-ideas] PEP 572 version 2: Statement-Local Name Bindings

wording of the actual proposal and specifications. Also, the reference implementation has been significantly enhanced, for those who wish to try this themselves. ChrisA PEP: 572 Title: Syntax for Statement-Local Name Bindings Author: Chris Angelico <ros...@gmail.com> Status: Draft Type: Sta

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings

On Wed, Feb 28, 2018 at 8:55 PM, Matt Arcidy wrote: > I appreciate that point as it is what I must be misunderstanding. > > I believe the performance speed up of [((f(x) as h), g(h)) for x > range(10)] is that there are 10 calls to compute f, not 20. > > You can do this with a

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings

On Wed, Feb 28, 2018 at 8:04 PM, Robert Vanden Eynde wrote: > Considering the 3rd syntax : > '(' EXPR 'with' NAME '=' EXPR ')' > > Wouldn't have the problem of "execution being middle first and would clearly > differenciate the "with NAME = CONTEXT" from the "with CONTEXT as

Re: [Python-ideas] PEP 572: Statement-Local Name Bindings

On Wed, Feb 28, 2018 at 5:53 PM, Gregory P. Smith wrote: > > My first concern for this proposal is that it gives parenthesis a > non-intuitive meaning. ()s used to be innocuous. A way to group things, > make explicit the desired order of operations, and allow spanning across >

Re: [Python-ideas] Add .= as a method return value assignment operator

On Wed, Sep 26, 2018 at 9:14 PM Jasper Rebane wrote: > When using Python, I find myself often using assignment operators, like 'a += > 1' instead of 'a = a + 1', which saves me a lot of time and hassle > > Unfortunately, this doesn't apply to methods, thus we have to write code like > this: >

Re: [Python-ideas] Why is design-by-contracts not widely adopted?

On Mon, Oct 8, 2018 at 4:26 PM Marko Ristin-Kaufmann wrote: >> Not true for good docstrings. We very seldom change the essential >> meaning of public functions. > > In my team, we have a stale docstring once every two weeks or even more > often. If it weren't for doctests and contracts, I could

Re: [Python-ideas] Why is design-by-contracts not widely adopted?

On Mon, Oct 8, 2018 at 9:26 PM Steven D'Aprano wrote: > > In other words, you change the *public interface* of your functions > > all the time? How do you not have massive breakage all the time? > > I can't comment about Marko's actual use-case, but *in general* > contracts are aimed at

Re: [Python-ideas] Why is design-by-contracts not widely adopted?

On Mon, Oct 8, 2018 at 11:11 PM Steven D'Aprano wrote: > > On Mon, Oct 08, 2018 at 09:32:23PM +1100, Chris Angelico wrote: > > On Mon, Oct 8, 2018 at 9:26 PM Steven D'Aprano wrote: > > > > In other words, you change the *public interface* of your functions > >

Re: [Python-ideas] Revisiting Immutable Mappings

On Fri, Oct 12, 2018 at 2:41 AM Chris Barker - NOAA Federal via Python-ideas wrote: > > > This violates the Liskov Substitution Principle. > > If we REALLY had a time machine, then dict would subclass frozendict, > and we’d be all set. Thanks to virtual subclassing, we can still do this. The

Re: [Python-ideas] Revisiting Immutable Mappings

On Fri, Oct 12, 2018 at 9:16 AM Steven D'Aprano wrote: > > On Fri, Oct 12, 2018 at 02:45:30AM +1100, Chris Angelico wrote: > > On Fri, Oct 12, 2018 at 2:41 AM Chris Barker - NOAA Federal via > > Python-ideas wrote: > > > > > > > This violates the Liskov Su

Re: [Python-ideas] Revisiting Immutable Mappings

On Tue, Oct 16, 2018 at 7:02 PM George Leslie-Waksman wrote: > > Would a frozendict require that keys and values be hashable? Keys would already have to be hashable - regular dicts demand this, and there's no reason not to for frozendict. Values? Not so sure. Personally I would say that no,

Re: [Python-ideas] Multi Statement Lambdas

On Mon, Oct 22, 2018 at 11:40 AM Steven D'Aprano wrote: > > On Mon, Oct 22, 2018 at 10:25:19AM +1100, Chris Angelico wrote: > > On Mon, Oct 22, 2018 at 10:16 AM Terry Reedy wrote: > > > > Except for relatively trivial expressions, this is a bad thing. All > > &

Re: [Python-ideas] Multi Statement Lambdas

On Mon, Oct 22, 2018 at 3:07 AM Andreas Winschu wrote: > Guido had a hard opinion on this, but i hope the python community does not. A > powerful general purpose language should not limit itself to one statement in > a closure. > Lets add mutli-statement lambdas to python either with just curly

Re: [Python-ideas] Multi Statement Lambdas

On Mon, Oct 22, 2018 at 10:16 AM Terry Reedy wrote: > > On 10/21/2018 12:28 PM, Andreas Winschu wrote > > > A def function has to be named. > > In general, this is a good thing. It often improves tracebacks. > Perhaps more importantly, name facilitate testing and mocking. > > > Wheres a lambda

Re: [Python-ideas] Python Enhancement Proposal for List methods

On Mon, Oct 22, 2018 at 7:58 AM Terry Reedy wrote: > > An indefinite number of in-place removes is a generally a bad idea > unless done carefully. > alist.remove is inherently O(n). > alist.removeall implemented naively would be O(n*n)/ > alist = [x for x in alist if x == old] or > alist = list(x

Re: [Python-ideas] Multi Statement Lambdas

On Mon, Oct 22, 2018 at 8:05 AM Vladimir Filipović wrote: > From one popular library: > > ws = websocket.WebSocketApp( > url, > on_open = (lambda ws: ws.send('subscribe'); conn_counter += 1), > on_message = (lambda ws, msg: print(msg); msg_counter += 1)) > > Because they include

Re: [Python-ideas] Contracts in python -- a report & next steps

On Wed, Oct 24, 2018 at 9:08 PM Marko Ristin-Kaufmann wrote: > > Hi Chris, > >> For the sake of those of us who REALLY don't feel like diving back >> into the extensive threads on this subject, can you please summarize >> the benefits of having this in the stdlib rather than as a third-party >>

Re: [Python-ideas] gevent-like Coroutines in Python

On Tue, Oct 30, 2018 at 6:01 PM Ron Reiter wrote: > > ... most developers would always mean they prefer to do this: > > result = [await fun(x) for fun in funcs] > > versus: > > result = [fun(x) for fun in funcs] > await asyncio.gather(*result) > > Moreso, having it become the default makes

Re: [Python-ideas] Add "default" kwarg to list.pop()

On Thu, Nov 1, 2018 at 6:25 AM Robert Vanden Eynde wrote: > > Oooh, PEP463, you're reason with I switch to LBYL or write studpid try except > functions so much times. > > Oh and also the local assignement "let/where/statement" :D > > x = (y+1 where y = 3.14) because x = [y+1 for y in [3.14]][0]

Re: [Python-ideas] gevent-like Coroutines in Python

On Tue, Oct 30, 2018 at 11:36 PM Ron Reiter wrote: > > You are right that they are different, I was actually assuming that > developers by default don't try to parallelize and would rather go ahead and > write code to yield one function at a time, which is fine. The need to > separate "await"

Re: [Python-ideas] Add "default" kwarg to list.pop()

On Wed, Oct 31, 2018 at 8:24 PM Nicolas Rolin wrote: > > > As a user I always found a bit disurbing that dict pop method have a default > while list and set doesn't. > While it is way more computationally easy to check wether a list or a set is > empty that to check if a key is in a dict, it

Re: [Python-ideas] Add "default" kwarg to list.pop()

On Wed, Oct 31, 2018 at 9:14 PM Steven D'Aprano wrote: > > On Wed, Oct 31, 2018 at 08:41:28PM +1100, Chris Angelico wrote: > > On Wed, Oct 31, 2018 at 8:24 PM Nicolas Rolin > > wrote: > > > > > > > > > As a user I always found a bit disurbing tha

Re: [Python-ideas] Fix documentation for __instancecheck__

On Sun, Oct 28, 2018 at 5:03 AM Joy Diamond wrote: > > Greetings, > > This is a request to fix the documentation for __instancecheck__. > > Please add the following (please rewrite better than I can -- I am not good > at explaining concepts in short sentences): > > NOTE: As an optimization,

Re: [Python-ideas] Fix documentation for __instancecheck__

On Sun, Oct 28, 2018 at 11:02 AM Steven D'Aprano wrote: > > """ > > (Note that any object `x` is always considered to be an instance of > > `x.__class__`, and this cannot be overridden.) > > """ > > I would rather be precise about what is going on, and state that > X.__instancecheck__(x) is not

Re: [Python-ideas] Fix documentation for __instancecheck__

On Sun, Oct 28, 2018 at 12:53 PM Joy Diamond wrote: >> - type(x) and x.__class__ don't necessarily agree; under what >> circumstances are each used? >> >> (I've asked this before, and either never got a good answer, or I can't >> keep it straight in my head.) >> >> - what precisely does type(x)

Re: [Python-ideas] Serialization of CSV vs. JSON

On Sun, Nov 4, 2018 at 12:02 AM David Shawley wrote: > > On Nov 2, 2018, at 12:28 PM, Calvin Spealman wrote: > > > Second, JSON is a specific serialization format that explicitly rejects > > datetime objects in *all* the languages with JSON libraries. You can only > > use date objects in JSON if

Re: [Python-ideas] Make fnmatch.filter accept a tuple of patterns

On Sun, Nov 4, 2018 at 4:29 AM Stephen J. Turnbull wrote: > > Chris Angelico writes: > > On Sat, Nov 3, 2018 at 4:49 AM Stephen J. Turnbull > > wrote: > > > Andre Delfino writes: > > > > > Frequently, while globbing, one needs to work with multiple

Re: [Python-ideas] Serialization of CSV vs. JSON

On Sun, Nov 4, 2018 at 1:00 AM David Shawley wrote: > Very good point. The JSON document type only supports object literals, > numbers, strings, and Boolean literals. My suggestion was specifically to > provide an extensible mechanism for encoding arbitrary objects into the > supported

Re: [Python-ideas] Add "default" kwarg to list.pop()

On Fri, Nov 2, 2018 at 11:12 AM Ethan Furman wrote: > > On 10/31/2018 02:29 PM, Chris Angelico wrote: > > > Exactly how a team of core devs can make unified > > decisions is a little up in the air at the moment > > I wouldn't worry too much about it. I don't think w

Re: [Python-ideas] Add "default" kwarg to list.pop()

On Fri, Nov 2, 2018 at 11:19 AM Robert Vanden Eynde wrote: > > Just English Vocabulary, what do you mean by "being in the air at the moment" > ? > Like, that's a subject that a lot of people in here like to talk ? "Up in the air" means uncertain, subject to change.

Re: [Python-ideas] Add "default" kwarg to list.pop()

On Fri, Nov 2, 2018 at 11:26 AM Robert Vanden Eynde wrote: >> >> In this case, the governance model for the Python language is being >> discussed. > > > This was the info I was missing, where is it discussed ? Not only on this > list I assume ^^ There are a number of PEPs in the 8000s that

Re: [Python-ideas] dict.setdefault_call(), or API variations thereupon

On Fri, Nov 2, 2018 at 12:07 PM Alex Shafer wrote: > Other APIs I've considered for this are a new keyword argument to the > existing `setdefault()`, or perhaps more radically for Python, a new keyword > argument to the `dict()` constructor that would get called as an implicit > default for

Re: [Python-ideas] Make fnmatch.filter accept a tuple of patterns

On Sat, Nov 3, 2018 at 4:49 AM Stephen J. Turnbull wrote: > > Andre Delfino writes: > > > Frequently, while globbing, one needs to work with multiple extensions. I’d > > like to propose for fnmatch.filter to handle a tuple of patterns (while > > preserving the single str argument

Re: [Python-ideas] Contracts in python -- a report & next steps

On Wed, Oct 24, 2018 at 6:41 PM Marko Ristin-Kaufmann wrote: > Next Steps? > I personally doubt that we are enough people to form a party to push for a > change in the language. A standardized library seems to me like a realizable > compromise given the state of the discussion on this mail

Re: [Python-ideas] Python octal escape character encoding "wats"

On Sat, Nov 10, 2018 at 12:42 PM Joao S. O. Bueno wrote: > > I just saw some document which reminded me that strings with a > backslash followed by 3 octal digits. When a backslash is followed by > 3 octal digits, that means a character with the corresponding > codepoint and all is well. > > The

Re: [Python-ideas] Python octal escape character encoding "wats"

On Sat, Nov 10, 2018 at 3:19 PM Steven D'Aprano wrote: > > On Sat, Nov 10, 2018 at 12:56:07PM +1100, Chris Angelico wrote: > > > Not ambiguous. It takes as many valid octal digits as it can. > > What is the rationale for that? Hex escapes don't. Irrelevant to w

Re: [Python-ideas] Relative Imports

On Sat, Nov 10, 2018 at 10:52 AM danish bluecheese wrote: > > └── src > ├── __init__.py > ├── main.py > └── test > ├── __init__.py > └── test_main.py > > assume the structure above. To be able to use relative imports with such > fundamental structure either i can go

Re: [Python-ideas] Range and slice syntax

On Sun, Nov 11, 2018 at 4:59 PM Nicholas Harrison wrote: > It has a couple of siblings that should be obvious (think list or set > comprehension): > > [start:stop:step] # gives a list > {start:stop:step} # gives a set > Be careful of this last one. If you omit the step, it looks like this:

Re: [Python-ideas] Range and slice syntax

On Wed, Nov 14, 2018 at 5:14 AM David Allemang wrote: > > That is not what slice.indices does. Per help(slice.indices) - > > "S.indices(len) -> (start, stop, stride) > > "Assuming a sequence of length len, calculate the start and stop indices, and > the stride length of the extended slice

Re: [Python-ideas] Add "default" kwarg to list.pop()

On Wed, Nov 7, 2018 at 6:04 AM Abe Dillon wrote: > > Which brings me to the question: What happens when a PEP gets rejected? Is it > final? Is there a process for reviving a PEP? It remains as a permanent document. No, that isn't final; and the process for reviving a PEP basically consists of

Re: [Python-ideas] Relative Imports

On Wed, Nov 14, 2018 at 5:15 PM Steven D'Aprano wrote: > Beware of "obvious" solutions, because so often they lead to not so > obvious problems. Like Javascript's "relative import hell": > > Quote: > > // what we want > import reducer from 'reducer'; > // what we don't want >

Re: [Python-ideas] Debugging: some problems and possible solutions

On Thu, Oct 4, 2018 at 1:30 AM Jonathan Fine wrote: > > Chris Angelico wrote: > > > Why not just discuss each proposal on its own merits, independently of > > any other proposals? Do they interact with each other? > > Good question. I think they will interact. Not i

[Python-ideas] Dictionary initialization to capture syntax and value (was Re: Debugging: some problems and possible solutions)

On Thu, Oct 4, 2018 at 4:12 AM Jonathan Fine wrote: > > Anders Hovmöller suggested > > Short form of keyword arguments where > > foo(=a, =1+bar) > > Is expanded at compile time to > > foo(**{'a': a, '1+bar': 1+bar}) > > Chris Angelico wrote: > > That is

Re: [Python-ideas] Debugging: some problems and possible solutions

On Thu, Oct 4, 2018 at 12:52 AM Jonathan Fine wrote: > > This thread is about debugging. I suggest we start by collecting > problems and possible solutions. And that after about a week of that, > we start discussing what we've gathered. > Why not just discuss each proposal on its own merits,

Re: [Python-ideas] Debugging: some problems and possible solutions

On Thu, Oct 4, 2018 at 4:54 AM Anders Hovmöller wrote: > > > > >> Then I'm strongly -1 on it. Happy? :) > > > > And In case it's not clear why I said that, btw: It's not mere > > pedantry. > > Good to see you understood yourself why that mail wasn't so good. > > > By restating your proposal in

Re: [Python-ideas] Debugging: some problems and possible solutions

On Thu, Oct 4, 2018 at 4:36 AM Anders Hovmöller wrote: > > > >> It's a very simple textual transformation. > >> > > > > That is not guaranteed to work. In another thread it was pointed out > > that this is merely a CPython implementation detail, NOT a language > > feature. > > Pedantry. Ok. Let's

Re: [Python-ideas] Debugging: some problems and possible solutions

On Thu, Oct 4, 2018 at 4:38 AM Chris Angelico wrote: > > On Thu, Oct 4, 2018 at 4:36 AM Anders Hovmöller wrote: > > > > > > >> It's a very simple textual transformation. > > >> > > > > > > That is not guaranteed to work. In another t

Re: [Python-ideas] Support parsing stream with `re`

On Tue, Oct 9, 2018 at 10:05 PM Greg Ewing wrote: > > Chris Angelico wrote: > > In contrast, a mmap'd file is memory that you do indeed own. > > Although it's not really accurate to say that it's owned by > a particular process. If two processes mmap the same file, > t

Re: [Python-ideas] Support parsing stream with `re`

On Wed, Oct 10, 2018 at 2:42 AM Stephen J. Turnbull wrote: > > Chris Angelico writes: > > On Tue, Oct 9, 2018 at 10:05 PM Greg Ewing > wrote: > > > > > > Chris Angelico wrote: > > > > In contrast, a mmap'd file is memory that you do indee

Re: [Python-ideas] Suggestion: Extend integers to include iNaN

On Mon, Oct 1, 2018 at 8:53 AM Oscar Benjamin wrote: > > On Sun, 30 Sep 2018 at 02:01, Steven D'Aprano wrote: > > > > On Sat, Sep 29, 2018 at 09:43:42PM +0100, Oscar Benjamin wrote: > > > On Sat, 29 Sep 2018 at 19:38, Steve Barnes wrote: > > > > > > > I converted to int because I needed a whole

Re: [Python-ideas] f-string "debug" conversion

On Wed, Oct 3, 2018 at 1:45 PM David Teresi wrote: > > print(f'{value!d}') is a lot of symbols and boilerplate to type out just for > a debugging statement that will be deleted later. Especially now that > breakpoint() exists, I can't really see myself using this. > What about when you want to

Re: [Python-ideas] f-string "debug" conversion

On Wed, Oct 3, 2018 at 2:11 PM Anders Hovmöller wrote: > > > > This would be used in debugging print statements, that currently end up > > looking like: > > > > print(f'value={value!r}') > > > > and would now be: > > > > print(f'{value!d}') > > It seems to me that a short form for keyword

Re: [Python-ideas] Why is design-by-contracts not widely adopted?

On Sat, Sep 29, 2018 at 7:19 AM Greg Ewing wrote: > > Chris Angelico wrote: > > It is still fundamentally difficult to make assertions about the file > > system as pre/post contracts. > > When you consider race conditions, I'd say it's impossible. > A postcondition chec

Re: [Python-ideas] Why is design-by-contracts not widely

On Sat, Sep 29, 2018 at 10:22 AM Dan Sommers <2qdxy4rzwzuui...@potatochowder.com> wrote: > > On 9/28/18 7:39 PM, Steven D'Aprano wrote: > > But none of that compares to C undefined behaviour. People who think > > that they are equivalent, don't understand C undefined behaviour. > > Well, yes:

Re: [Python-ideas] Add .= as a method return value assignment operator

On Fri, Sep 28, 2018 at 6:56 PM Jonathan Fine wrote: > Finally, I note > > >>> a = 2 > >>> a **= 3 > >>> a > 8 > ? Yes? That's what 2 ** 3 is, so that's what I would expect. All other augmented assignment operators take an assignment target on the left and a (single) value on the right. ChrisA

Re: [Python-ideas] Why is design-by-contracts not widely adopted?

On Fri, Sep 28, 2018 at 11:25 AM Marko Ristin-Kaufmann wrote: > > Hi, > > I annotated pathlib with > contracts:https://github.com/mristin/icontract-pathlib-poc. I zipped the HTML > docs into > https://github.com/mristin/icontract-pathlib-poc/blob/master/contracts-pathlib-poc.zip, > you can

Re: [Python-ideas] Why is design-by-contracts not widely adopted?

On Fri, Sep 28, 2018 at 7:29 PM Jonathan Fine wrote: > > I like this discussion. I'd like to add another theme, namely what > should happen when there is an error. (This is prompted by race > hazards when performing file system operations.) > > Suppose fn_a() calls fn_b(), and fn_b() raises an

Re: [Python-ideas] Why is design-by-contracts not widely

On Sun, Sep 30, 2018 at 12:43 AM Steven D'Aprano wrote: > > On Sat, Sep 29, 2018 at 10:15:42PM +1000, Chris Angelico wrote: > > [...] > > As are all the things that are "undefined behaviour" in C, like the > > result of integer overflow in a signed varia

Re: [Python-ideas] Simplicity of C (was why is design-by-contracts not widely)

On Sun, Sep 30, 2018 at 11:54 AM Steven D'Aprano wrote: > This discussion is for those of us who would like to include DbC in our > projects but don't like existing solutions. C++ being designed with a > shovel is not relevant. > > (Except in the sense that we should always be careful about

Re: [Python-ideas] Simplicity of C (was why is design-by-contracts not widely)

On Sun, Sep 30, 2018 at 6:03 PM Steven D'Aprano wrote: > > On Sun, Sep 30, 2018 at 02:50:28PM +1000, Chris Angelico wrote: > > > And yet all the examples I've seen have just been poor substitutes for > > unit tests. Can we get some examples that actually do a better job of

Re: [Python-ideas] Simplicity of C (was why is design-by-contracts not widely)

On Sun, Sep 30, 2018 at 2:27 PM Steven D'Aprano wrote: > > On Sun, Sep 30, 2018 at 12:17:25PM +1000, Chris Angelico wrote: > > On Sun, Sep 30, 2018 at 11:54 AM Steven D'Aprano > > wrote: > > > This discussion is for those of us who would like to include DbC in our &g

Re: [Python-ideas] Why is design-by-contracts not widely

On Sat, Sep 29, 2018 at 9:43 PM Steven D'Aprano wrote: > > On Sat, Sep 29, 2018 at 10:32:16AM +1000, Chris Angelico wrote: > > > What should happen here? > > > > >>> import ctypes > > >>> ctypes.cast(id(1), ctypes.POINTER(ctypes.c_int))[6] = 0 &

Re: [Python-ideas] Suggestion: Extend integers to include iNaN

On Mon, Oct 1, 2018 at 12:18 AM David Mertz wrote: > > For similar reasons, I'd like an iInf too, FWIW. It's good for an overflow > value, although it's hard to get there in Python ints (would > 'NaNAwareInt(1)/0' be an exception or iInf?). Bonus points for anyone who > knows the actual

Re: [Python-ideas] Revisiting Immutable Mappings

On Thu, Oct 11, 2018 at 1:02 PM Cameron Simpson wrote: > > On 10Oct2018 20:25, Philip Martin wrote: > >Steven, that's a great idea, and I would be 100% up for your suggestion to > >have types.MappingProxyType renamed to frozendict. > > I'm not for the rename, myself. Though I'd not be against a

Re: [Python-ideas] Suggestion: Extend integers to include iNaN

On Mon, Oct 1, 2018 at 12:45 AM Anders Hovmöller wrote: > But making any change to the basic types truth table is a big -1 from me. > This seems like a Python 2-3 transition to me. > Far FAR worse than anything that changed in Py2->Py3. ChrisA ___

Re: [Python-ideas] Suggestion: Extend integers to include iNaN

On Mon, Oct 1, 2018 at 12:44 AM David Mertz wrote: > > On Sun, Sep 30, 2018 at 10:23 AM Chris Angelico wrote: >> >> On Mon, Oct 1, 2018 at 12:18 AM David Mertz wrote: >> > Bonus points for anyone who knows the actual maximum size of Python ints >> > :-).

Re: [Python-ideas] Suggestion: Extend integers to include iNaN

On Mon, Oct 1, 2018 at 12:58 AM David Mertz wrote: >> I'm not sure what's going on. I have a Py3 busily calculating >> 2**(2**65) and it's pegging a CPU core while progressively consuming >> memory, but it responds to Ctrl-C, which suggests that Python bytecode >> is still being executed. > > >

Re: [Python-ideas] Suggestion: Extend integers to include iNaN

On Mon, Oct 1, 2018 at 1:32 AM Steve Barnes wrote: > > No complex can be converted to float without accessing either the real > or imag component. > Or taking its absolute value, which will return nan if either part is nan. ChrisA ___ Python-ideas

<    2   3   4   5   6   7   8   9   10   11   >