Re: [Python-ideas] Generator-based context managers can't skip __exit__

On Sun, Nov 6, 2016 at 8:53 AM, Nick Coghlan wrote: > On 6 November 2016 at 16:07, Ram Rachum wrote: > > Heh, I just played with this, and found a workaround. If I do something > like > > this after creating the generator: > > > > sys.g = g > > > > Then it wouldn't get closed when Python finishe

Re: [Python-ideas] Method signature syntactic sugar (especially for dunder methods)

On 6 November 2016 at 16:28, Nathan Dunn wrote: > There are some immediate problems with this, such as `bool(self)` being > indistinguishable from a regular method signature and `class(x, y)` not > declaring the `self` identifier. These and other problems can be solved to > some extent, but I thou

Re: [Python-ideas] Generator-based context managers can't skip __exit__

On 2016-11-06 00:18, Ram Rachum wrote: Well, you think it's weird that I want a `finally` clause to not be called in some circumstances. Do you think it's equally weird to want an `__exit__` method that is not called in some circumstances? It's weird to not want the __exit__ to be called if it

Re: [Python-ideas] Generator-based context managers can't skip __exit__

On 6 November 2016 at 17:18, Ram Rachum wrote: > On Sun, Nov 6, 2016 at 8:53 AM, Nick Coghlan wrote: >> There's still something seriously odd going in relation to your >> overall resource management architecture if "cleanup, maybe, unless I >> decide to tell you not to" is a behaviour you regular

Re: [Python-ideas] Generator-based context managers can't skip __exit__

On Sun, Nov 6, 2016 at 9:38 AM, Nick Coghlan wrote: > On 6 November 2016 at 17:18, Ram Rachum wrote: > > On Sun, Nov 6, 2016 at 8:53 AM, Nick Coghlan wrote: > >> There's still something seriously odd going in relation to your > >> overall resource management architecture if "cleanup, maybe, unl

Re: [Python-ideas] Generator-based context managers can't skip __exit__

On Sun, Nov 06, 2016 at 06:46:40AM +0200, Ram Rachum wrote: > Hi everyone, > > Here is a simplification of a problem that's been happening in my code: > > import contextlib > > @contextlib.contextmanager > def f(): > print('1') > try: > yield > finally: > print('2') >

Re: [Python-ideas] Generator-based context managers can't skip __exit__

On 6 November 2016 at 17:44, Ram Rachum wrote: > I understand your point of view. I see that Python does allow you to not > call `__exit__` if you don't want to, so I wish it'll have the same approach > to not calling `generator.close()` if you don't want to. (This is what it's > really about, not

[Python-ideas] Alternative to PEP 532: delayed evaluation of expressions

Creating a new thread, instead of hijacking the PEP 532 discussion. From PEP 532: > Abstract > > > Inspired by PEP 335, PEP 505, PEP 531, and the related discussions, this PEP > proposes the addition of a new protocol-driven circuit breaking operator to > Python that allows the left o

Re: [Python-ideas] Alternative to PEP 532: delayed evaluation of expressions

[top posting from my phone] Chris Angelico points out the & part of the idea interacts poorly with *args and **kwargs, so I drop that idea. Re-reading PEP 312, this idea is basically identical, with different spellings. The point remains: do we want to be able to create unevaluated expressio

Re: [Python-ideas] Generator-based context managers can't skip __exit__

On 11/6/2016 2:18 AM, Ram Rachum wrote: Well, you think it's weird that I want a `finally` clause to not be called in some circumstances. Do you think it's equally weird to want an `__exit__` method that is not called in some circumstances? Without a deeper understanding of why you want to do

Re: [Python-ideas] Reduce/fold and scan with generator expressions and comprehensions

2016-11-03 8:10 GMT-02:00 Stephen J. Turnbull : > As for recursion, the syntax you proposed doesn't say "recursion" to > me, it says "let's add more complexity to a syntax that already is > hard to fit on a line so we can turn a sequence into a series." > 1. The "fit on a line" is just another we

Re: [Python-ideas] Reduce/fold and scan with generator expressions and comprehensions

Danilo J. S. Bellini writes: > About the effort, do you really find the examples below with the new > proposed syntax difficult to understand? No. I just don't see how they would become tools I would use. My main interest here was in your claim to have economic applications, but the examples

Re: [Python-ideas] Reduce/fold and scan with generator expressions and comprehensions

2016-11-06 18:00 GMT-02:00 Stephen J. Turnbull < turnbull.stephen...@u.tsukuba.ac.jp>: > Danilo J. S. Bellini writes: > > > About the effort, do you really find the examples below with the new > > proposed syntax difficult to understand? > > No. I just don't see how they would become tools I wo

[Python-ideas] PythonOS

Firstly, apologies if this is the wrong forum for this idea; it's not so much about the language itself, but what surrounds it. If you have any ideas for better forums, please let me know. Also, if there is any work started on anything like this, let me know Now to the idea: PythonOS - a (likely l

Re: [Python-ideas] PythonOS

On 11/06/2016 08:25 PM, victor rajewski wrote: What do you think? I'm not in a state to do all of this myself, but could give it a start if there is interest in the concept. Even though there is nothing wrong with the idea, I think there is not enough motivation for it. Most of the people lear

Re: [Python-ideas] Alternative to PEP 532: delayed evaluation of expressions

Eric V. Smith wrote: I'd rather see the ability to have unevaluated expressions, that can later be evaluated. I'll use backticks here to mean: "parse, but do not execute the enclosed code". This produces an object that can later be evaluated with a new builtin I'll call "evaluate_now". So fa

Re: [Python-ideas] Reduce/fold and scan with generator expressions and comprehensions

- So, IIUC, for recursive list comprehensions - "prev" = x_(n-1) - there is a need to define an initial value - chain([1000], [...]) - sometimes, we actually need window function - __[0] = x_(n-1) - __[1] = x_(n-2) # this - __[-1] = x_(n-2) # or this - this can be accomp

Re: [Python-ideas] Alternative to PEP 532: delayed evaluation of expressions

On Sun, Nov 6, 2016 at 5:06 AM, Eric V. Smith wrote: > Creating a new thread, instead of hijacking the PEP 532 discussion. > > From PEP 532: > >> Abstract >> >> >> Inspired by PEP 335, PEP 505, PEP 531, and the related discussions, this >> PEP >> proposes the addition of a new protocol-dr

Re: [Python-ideas] Method signature syntactic sugar (especially for dunder methods)

On Sun, Nov 06, 2016 at 01:28:34AM -0500, Nathan Dunn wrote: > Python has very intuitive and clear syntax, except when it comes to method > definitions, particularly dunder methods. I disagree with your premise here. Python's method definitions are just as intuitive and clear as the rest of Pyth

Re: [Python-ideas] Reduce/fold and scan with generator expressions and comprehensions

On Sun, Nov 06, 2016 at 04:46:42PM -0200, Danilo J. S. Bellini wrote: > 1.2. Sub-expressions in an expression might be on other statements (e.g. > assignments, other functions). Not in Python it can't be. Assignment is not an expression, you cannot say (x = 2) + 1. > 2. The itertools.accumulat

Re: [Python-ideas] Generator-based context managers can't skip __exit__

On 11/06/2016 12:18 AM, Ram Rachum wrote: Well, you think it's weird that I want a `finally` clause to not be called in some circumstances. Yes I (we) do. Do you think it's equally weird to want an `__exit__` method that is not called in some circumstances? Yes I (we) do. -- ~Ethan~ __

Re: [Python-ideas] Generator-based context managers can't skip __exit__

On 11/06/2016 12:44 AM, Ram Rachum wrote: I see that Python does allow you to not call `__exit__` if you don't want to [...] Um, how? I was unaware of this (mis-)feature. -- ~Ethan~ ___ Python-ideas mailing list Python-ideas@python.org https://mai

Re: [Python-ideas] PythonOS

On 7 November 2016 at 08:25, victor rajewski wrote: > My proposal is a Linux distribution that has the simplicity of micropython, > but the power of full python. Drop a file (let's call it main.py) on an SD > card from your laptop, plug it into the device, and it boots and runs that > file straigh

Re: [Python-ideas] Alternative to PEP 532: delayed evaluation of expressions

On 7 November 2016 at 02:32, Nathaniel Smith wrote: > On Sun, Nov 6, 2016 at 5:06 AM, Eric V. Smith wrote: >> Creating a new thread, instead of hijacking the PEP 532 discussion. >> >> From PEP 532: >> >>> Abstract >>> >>> >>> Inspired by PEP 335, PEP 505, PEP 531, and the related discuss

Re: [Python-ideas] Generator-based context managers can't skip __exit__

On 7 November 2016 at 12:25, Ethan Furman wrote: > On 11/06/2016 12:44 AM, Ram Rachum wrote: > >> I see that Python does allow you to not call `__exit__` if you don't want >> to [...] > > Um, how? I was unaware of this (mis-)feature. It involves wrapping the context manager in another context m

Re: [Python-ideas] Generator-based context managers can't skip __exit__

On 11/06/2016 08:11 PM, Nick Coghlan wrote: On 7 November 2016 at 12:25, Ethan Furman wrote: On 11/06/2016 12:44 AM, Ram Rachum wrote: I see that Python does allow you to not call `__exit__` if you don't want to [...] Um, how? I was unaware of this (mis-)feature. It involves wrapping t

Re: [Python-ideas] Reduce/fold and scan with generator expressions and comprehensions

2016-11-06 23:55 GMT-02:00 Steven D'Aprano : > On Sun, Nov 06, 2016 at 04:46:42PM -0200, Danilo J. S. Bellini wrote: > > > 1.2. Sub-expressions in an expression might be on other statements (e.g. > > assignments, other functions). > > Not in Python it can't be. Assignment is not an expression, you

Re: [Python-ideas] Alternative to PEP 532: delayed evaluation of expressions

On Nov 6, 2016 7:32 PM, "Nathaniel Smith" wrote: > > [...] > > Some other use cases: > > Log some complicated object, but only pay the cost of stringifying the > object if debugging is enabled: > > log.debug!(f"Message: {message_object!r}") Would the log.debug implementation need to fetch the

Re: [Python-ideas] Alternative to PEP 532: delayed evaluation of expressions

On Sun, Nov 6, 2016 at 5:32 PM, Nathaniel Smith wrote: > > If we're considering options along these lines, then I think the local > optimum is actually a "quoted-call" operator, rather than a quote > operator. So something like (borrowing Rust's "!"): > > eval_else!(foo.bar, some_func()) > >

Re: [Python-ideas] Alternative to PEP 532: delayed evaluation of expressions

C Anthony Risinger wrote: On Nov 6, 2016 7:32 PM, "Nathaniel Smith" > wrote: > > log.debug!(f"Message: {message_object!r}") Would the log.debug implementation need to fetch the context to evaluate the delayed expression Not if it expands to log.debug(lambda: f

Re: [Python-ideas] Reduce/fold and scan with generator expressions and comprehensions

On Mon, Nov 07, 2016 at 02:21:04AM -0200, Danilo J. S. Bellini wrote: > 2016-11-06 23:55 GMT-02:00 Steven D'Aprano : > > > On Sun, Nov 06, 2016 at 04:46:42PM -0200, Danilo J. S. Bellini wrote: > > > > > 1.2. Sub-expressions in an expression might be on other statements (e.g. > > > assignments, oth

Re: [Python-ideas] Alternative to PEP 532: delayed evaluation of expressions

On Sun, Nov 06, 2016 at 09:31:06AM -0500, Eric V. Smith wrote: > The point remains: do we want to be able to create unevaluated > expressions that can be evaluated at a different point? I sometimes think that such unevaluated expressions (which I usually call "thunks") would be cool to have. Bu

Re: [Python-ideas] Alternative to PEP 532: delayed evaluation of expressions

On 2016-11-06 21:46, Steven D'Aprano wrote: I sometimes think that such unevaluated expressions (which I usually call "thunks") would be cool to have. But in more realistic moments I think that they're a solution looking for a problem to solve. If your PEP suggests a problem that they will solve

Re: [Python-ideas] Alternative to PEP 532: delayed evaluation of expressions

On Sun, Nov 6, 2016 at 9:08 PM, C Anthony Risinger wrote: > On Nov 6, 2016 7:32 PM, "Nathaniel Smith" wrote: >> >> [...] >> >> Some other use cases: >> >> Log some complicated object, but only pay the cost of stringifying the >> object if debugging is enabled: >> >> log.debug!(f"Message: {mes