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

2016-11-06 Thread Nathaniel Smith
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: >>

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

2016-11-06 Thread Steven D'Aprano
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.

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

2016-11-06 Thread Steven D'Aprano
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.

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

2016-11-06 Thread Greg Ewing
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

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

2016-11-06 Thread Matthias Bussonnier
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,

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

2016-11-06 Thread Danilo J. S. Bellini
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

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

2016-11-06 Thread Ethan Furman
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.

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

2016-11-06 Thread Nick Coghlan
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

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

2016-11-06 Thread Mikhail V
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

Re: [Python-ideas] PythonOS

2016-11-06 Thread Nick Coghlan
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

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

2016-11-06 Thread Ethan Furman
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

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

2016-11-06 Thread Ethan Furman
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] Method signature syntactic sugar (especially for dunder methods)

2016-11-06 Thread Steven D'Aprano
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

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

2016-11-06 Thread Nathaniel Smith
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

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

2016-11-06 Thread Wes Turner
- 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

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

2016-11-06 Thread Greg Ewing
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

Re: [Python-ideas] PythonOS

2016-11-06 Thread Bernardo Sulzbach
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

[Python-ideas] PythonOS

2016-11-06 Thread victor rajewski
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

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

2016-11-06 Thread Danilo J. S. Bellini
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

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

2016-11-06 Thread Stephen J. Turnbull
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 Thread Danilo J. S. Bellini
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.

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

2016-11-06 Thread Terry Reedy
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] Alternative to PEP 532: delayed evaluation of expressions

2016-11-06 Thread Eric V. Smith
[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

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

2016-11-06 Thread Eric V. Smith
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

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

2016-11-06 Thread Nick Coghlan
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 >

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

2016-11-06 Thread Steven D'Aprano
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__

2016-11-06 Thread Ram Rachum
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 > >>

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

2016-11-06 Thread Nick Coghlan
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

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

2016-11-06 Thread Brendan Barnwell
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

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

2016-11-06 Thread Nick Coghlan
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 >

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

2016-11-06 Thread Ram Rachum
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

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

2016-11-06 Thread Nick Coghlan
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 finishes, and the cleanup won't > happen, which is what I

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

2016-11-06 Thread Nathan Dunn
Python has very intuitive and clear syntax, except when it comes to method definitions, particularly dunder methods. class Vec(object): def __init__(self, x, y): self.x, self.y = x, y def __add__(self, other): return Vec(self.x + other.x, self.y + other.y) def

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

2016-11-06 Thread Ram Rachum
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 finishes, and the cleanup won't happen, which is what I want. This is still a bit ugly but now it's something I can do automatically

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

2016-11-06 Thread Ram Rachum
Sorry, I was wrong at quoting the workaround I do, it's actually this: try: yield except GeneratorExit: raise except: cleanup() raise else: cleanup() This works, but