Re: [Python-Dev] Surely "nullable" is a reasonable name?
On 04/24/2015 09:45 PM, Nick Coghlan wrote:
Ah, I misread Tal's suggestion. Using unary + is an even neater approach.
Not exactly. The way I figure it, the best way to achieve this with
unary plus is to ast.parse it (as we currently do) and then modify the
parse tree. That works but it's kind of messy.
My main objection to this notation is that that set objects /don't
support +./ The union operator for sets is |.
I've prototyped a hack allowing
str(accept|={NoneType})
I used the tokenize module to tokenize, modify, and untokenize the
converter invocation. Works fine. And since augmented assignment is
(otherwise) illegal in expressions, it's totally unambiguous. I think
if we do it at all it should be with that notation.
//arry/
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Surely "nullable" is a reasonable name?
On Sat, Apr 25, 2015 at 10:58 AM, Larry Hastings wrote:
>
> On 04/24/2015 09:45 PM, Nick Coghlan wrote:
>
> Ah, I misread Tal's suggestion. Using unary + is an even neater approach.
>
>
> Not exactly. The way I figure it, the best way to achieve this with unary
> plus is to ast.parse it (as we currently do) and then modify the parse tree.
> That works but it's kind of messy.
>
> My main objection to this notation is that that set objects don't support +.
> The union operator for sets is |.
>
> I've prototyped a hack allowing
> str(accept|={NoneType})
> I used the tokenize module to tokenize, modify, and untokenize the converter
> invocation. Works fine. And since augmented assignment is (otherwise)
> illegal in expressions, it's totally unambiguous. I think if we do it at all
> it should be with that notation.
We're deep into bike-shedding territory at this point, but I prefer
Nick's suggestion of using the Ellipses for this. It's the simplest
and most obvious syntax suggested so far.
- Tal
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Surely "nullable" is a reasonable name?
On 25 April 2015 at 17:58, Larry Hastings wrote:
>
> On 04/24/2015 09:45 PM, Nick Coghlan wrote:
>
> Ah, I misread Tal's suggestion. Using unary + is an even neater approach.
>
>
> Not exactly. The way I figure it, the best way to achieve this with unary
> plus is to ast.parse it (as we currently do) and then modify the parse tree.
> That works but it's kind of messy.
>
> My main objection to this notation is that that set objects don't support +.
> The union operator for sets is |.
Good point.
> I've prototyped a hack allowing
> str(accept|={NoneType})
> I used the tokenize module to tokenize, modify, and untokenize the converter
> invocation. Works fine. And since augmented assignment is (otherwise)
> illegal in expressions, it's totally unambiguous. I think if we do it at
> all it should be with that notation.
I'd say start without it, but if it gets annoying, then we have this
in our back pocket as a potential fix.
Cheers,
Nick.
--
Nick Coghlan | [email protected] | Brisbane, Australia
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 492 vs. PEP 3152, new round
Hi Greg, 2015-04-25 7:02 GMT+02:00 Greg Ewing : >> I accept the compromise of creating a coroutine object without wait >> for it (obvious and common bug when learning asyncio). Hopefully, we >> keep the coroutine wrapper feature (ok, maybe I suggested this idea to >> Yury because I suffered so much when I learnt how to use asyncio ;-)), >> so it will still be easy to emit a warning in debug mode. > > > I'm disappointed that there will *still* be no direct and > reliable way to detect and clearly report this kind of > error, and that what there is will only be active in > a special debug mode. It looks like our BDFL, Guido, made a choice. This point was discussed enough and most of us now agree on this point. There is no need to repeat yourself multiple time, we are well aware that you strongly disagree with this compromise ;-) It's probably the major difference between the PEP 492 and PEP 3152, and Guido decided to reject the PEP 3152. It's now time to focus our good energy on discussing remaining questions on the PEP 492 to make it the best PEP ever! Guido did a great great to summarize these questions. Thank you, Victor ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 492 vs. PEP 3152, new round
2015-04-25 8:23 GMT+02:00 Greg Ewing : > But how is an awaitable supposed to raise StopIteration > if it's implemented by a generator or async def[*] function? > Those things use StopIteration to wrap return values. > > I like the idea of allowing StopIteration to be raised > in an async def function and wrapping it somehow. I'd > add that it could also be unwrapped automatically when > it emerges from 'await', so that code manually invoking > __anext__ can catch StopIteration as usual. Hum, wrap and then unwrap is not cheap. Exception handling in CPython is known to be slow (it's one of the favorite topic for microbenchmarks ;-)). I would prefer to not make wrapping/unwrapping a feature and instead use different exceptions. Again, I don't understand the problem, so I'm just sure that my remark makes sense. But please be careful of performances. I already saw microbenchmarks on function call vs consuming a generator to justify that asyncio is way too slow and must not be used... See for example the "2. AsyncIO uses appealing, but relatively inefficient Python paradigms" section of the following article: http://techspot.zzzeek.org/2015/02/15/asynchronous-python-and-databases/ The microbenchmark shows that yield from is 6x as slow as function calls (and function calls are also known to be slow in CPython). (I don't think that it makes sense to compare function calls versus consuming a generator to benchmark asyncio, but other developers have a different opinion of that.) Victor ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] async/await in Python; v2
I used to think in the same way but found the result looks like Perl (or Haskell), not Python. On Sat, Apr 25, 2015 at 7:47 AM, Greg Ewing wrote: > Wild idea: > > Let "@" mean "async" when it's directly in front > of a keyword. > > Then we would have: > > @def f(): > ... > > @for x in iter: > ... > > @with context as thing: > ... > > -- > Greg > > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/andrew.svetlov%40gmail.com -- Thanks, Andrew Svetlov ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 492 vs. PEP 3152, new round
Victor Stinner wrote: It's now time to focus our good energy on discussing remaining questions on the PEP 492 to make it the best PEP ever! That's what I'm trying to do. I just think it would be even better if it could be made to address that issue somehow. I haven't thought of a way to do that yet, though. -- Greg ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Type hints -- a mediocre programmer's reaction
Le 25/04/15 04:07, Steven D'Aprano a écrit : On Sat, Apr 25, 2015 at 02:05:15AM +0100, Ronan Lamy wrote: * Hints have no run-time effect. The interpreter cannot assume that they are obeyed. I know what you mean, but just for the record, annotations are runtime inspectable, so people can (and probably have already started) to write runtime argument checking decorators or frameworks which rely on the type hints. * PEP484 hints are too high-level. Replacing an 'int' object with a single machine word would be useful, but an 'int' annotation gives no guarantee that it's correct (because Python 3 ints can have arbitrary size and because subclasses of 'int' can override any operation to invoke arbitrary code). Then create your own int16, uint64 etc types. The PEP doesn't explain how to do that. And even if it's possible, such types wouldn't be very useful as they're not stable under any arithmetic operation (e.g. + doesn't necessarily fit in int16). * A lot more information is needed to produce good code (e.g. “this f() called here really means this function there, and will never be monkey-patched” – same with len() or list(), btw). * Most of this information cannot easily be expressed as a type * If the interpreter gathers all that information, it'll probably have gathered a superset of what PEP484 can provide anyway. All this is a red herring. If type hints are useful to PyPy, that's a bonus. Cython uses its own system of type hints, a future version may be able to use PEP 484 hints instead. But any performance benefit is a bonus. PEP 484 is for increasing correctness, not speed. Yes, talking about performance in the context of PEP 484 is a red herring, that's what I'm saying. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 492 vs. PEP 3152, new round
Hi Guido, On 2015-04-24 1:03 PM, Guido van Rossum wrote: *3. syntactic priority of `await`* Yury, could you tweak the syntax for `await` so that we can write the most common usages without parentheses? In particular I'd like to be able to write ``` return await foo() with await foo() as bar: ... foo(await bar(), await bletch()) ``` (I don't care about `await foo() + await bar()` but it would be okay.) ``` I think this is reasonable with some tweaks of the grammar (similar to what Greg did for cocall, but without requiring call syntax at the end). I've done some experiments with grammar, and it looks like we indeed can parse await quite differently from yield. Three different options: Option #1. Parse 'await' exactly like we parse 'yield'. This how we parse 'await' in the latest version of reference implementation. Required grammar changes: https://gist.github.com/1st1/cb0bd257b04adb87e167#file-option-1-patch Repo to play with: https://github.com/1st1/cpython/tree/await Syntax: await a() res = (await a()) + (await b()) res = (await (await a())) if (await a()): pass return (await a()) print((await a())) func(arg=(await a())) await a() * b() Option #2. Keep 'await_expr' in 'atom' terminal, but don't require parentheses. Required grammar changes: https://gist.github.com/1st1/cb0bd257b04adb87e167#file-option-2-patch Repo to play with (parser module is broken atm): https://github.com/1st1/cpython/tree/await_noparens Syntax: await a() res = (await a()) + await b() # w/o parens (a() + await b()) res = await await a() if await a(): pass return await a() print(await a()) func(arg=await a()) await a() * b() Option #3. Create a new terminal for await expression between 'atom' and 'power'. Required grammar changes: https://gist.github.com/1st1/cb0bd257b04adb87e167#file-option-3-patch Repo to play with (parser module is broken atm): https://github.com/1st1/cpython/tree/await_noparens2 Syntax: await a() res = await a() + await b() res = await (await a()) # invalid syntax w/o parens if await a(): pass return await a() print(await a()) func(arg=await a()) await (a() * b()) # w/o parens '(await a() * b()) I think that Option #3 is a clear winner. Thanks, Yury ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] async/await in Python; v2
On Tue, 21 Apr 2015 at 18:27 Yury Selivanov wrote: > > Hi python-dev, > > I'm moving the discussion from python-ideas to here. > > The updated version of the PEP should be available shortly > at https://www.python.org/dev/peps/pep-0492 > and is also pasted in this email. > Hi Yury, Having read this very interesting PEP I would like to make two remarks. I apologise in advance if they are points which have already been discussed. 1. About the 'async for' construct. Each iteration will create a new coroutine object (the one returned by Cursor.__anext__()) and it seems to me that it can be wasteful. In the example given of an 'aiterable' Cursor class, probably a large number of rows will fill the cursor buffer in one call of cursor._prefetch(). However each row that is iterated over will involve the creation execution of a new coroutine object. It seems to me that what is desirable in that case is that all the buffered rows will be iterated over as in a plain for loop. 2. I think the semantics of the new coroutine objects could be defined more clearly in the PEP. Of course they are pretty obvious when you know that the coroutines are meant to replace asyncio.coroutine as described in [1]. I understand that this PEP is mostly for the benefit of asyncio, hence mainly of interest of people who know it. However I think it would be good for it to be more self-contained. I have often read a PEP as an introduction to a new feature of Python. I feel that if I was not familiar with yield from and asyncio I would not be able to understand this PEP, even though potentially one could use the new constructs without knowing anything about them. Cheers, -- Arnaud Delobelle [1] https://docs.python.org/3/library/asyncio-task.html#coroutines ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] async/await in Python; v2
Hi Arnaud, On 2015-04-25 4:47 PM, Arnaud Delobelle wrote: On Tue, 21 Apr 2015 at 18:27 Yury Selivanov wrote: Hi python-dev, I'm moving the discussion from python-ideas to here. The updated version of the PEP should be available shortly at https://www.python.org/dev/peps/pep-0492 and is also pasted in this email. Hi Yury, Having read this very interesting PEP I would like to make two remarks. I apologise in advance if they are points which have already been discussed. 1. About the 'async for' construct. Each iteration will create a new coroutine object (the one returned by Cursor.__anext__()) and it seems to me that it can be wasteful. In the example given of an 'aiterable' Cursor class, probably a large number of rows will fill the cursor buffer in one call of cursor._prefetch(). However each row that is iterated over will involve the creation execution of a new coroutine object. It seems to me that what is desirable in that case is that all the buffered rows will be iterated over as in a plain for loop. I agree that creating a new coroutine object is a little bit wasteful. However, the proposed iteration protocol was designed to: 1. Resemble already existing __iter__/__next__/StopIteration protocol; 2. Pave the road to introduce coroutine-generators in the future. We could, in theory, design the protocol to make __anext__ awaitable return a regular iterators (and raise StopAsyncIteration at the end) to make things more efficient, but that would complicate the protocol tremendously, and make it very hard to program and debug. My opinion is that this has to be addressed in 3.6 with coroutine-generators if there is enough interest from Python users. 2. I think the semantics of the new coroutine objects could be defined more clearly in the PEP. Of course they are pretty obvious when you know that the coroutines are meant to replace asyncio.coroutine as described in [1]. I understand that this PEP is mostly for the benefit of asyncio, hence mainly of interest of people who know it. However I think it would be good for it to be more self-contained. I have often read a PEP as an introduction to a new feature of Python. I feel that if I was not familiar with yield from and asyncio I would not be able to understand this PEP, even though potentially one could use the new constructs without knowing anything about them. I agree. I plan to update the PEP with some new semantics (prohibit passing coroutine-objects to iter(), tuple() and other builtins, as well as using them in 'for .. in coro()' loops). I'll add a section with a more detailed explanation of coroutine-objects. Best, Yury ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Type hints -- a mediocre programmer's reaction
On Sun, Apr 26, 2015 at 2:01 AM, Ronan Lamy wrote: >>> * PEP484 hints are too high-level. Replacing an 'int' object with a >>> single machine word would be useful, but an 'int' annotation gives no >>> guarantee that it's correct (because Python 3 ints can have arbitrary >>> size and because subclasses of 'int' can override any operation to >>> invoke arbitrary code). >> >> >> Then create your own int16, uint64 etc types. > > > The PEP doesn't explain how to do that. And even if it's possible, such > types wouldn't be very useful as they're not stable under any arithmetic > operation (e.g. + doesn't necessarily fit in int16). If you define a function that adds two integers and want it to be optimized, it's going to have to check for overflow anyway. That said, though, I'd much rather a machine-word optimization be a feature of "int" than a special adornment that you give to some of your data. CPython 3.x doesn't do it, CPython 2.x kinda did it (an int would turn into a long if it got too big, but a long would never turn into an int), but MicroPython would be most welcome to do the job fully. (I would guess that PyPy already does this kind of thing.) Yes, that means integer addition can't become a single machine language instruction, but on the other hand, it means the Python code doesn't need to concern itself with any boundaries. ChrisA ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 492 vs. PEP 3152, new round
+1 for option 3. On Sat, Apr 25, 2015 at 1:18 PM, Yury Selivanov wrote: > Hi Guido, > > On 2015-04-24 1:03 PM, Guido van Rossum wrote: > >> *3. syntactic priority of `await`* >> >> Yury, could you tweak the syntax for `await` so that we can write the most >> common usages without parentheses? In particular I'd like to be able to >> write >> ``` >> return await foo() >> with await foo() as bar: ... >> foo(await bar(), await bletch()) >> ``` >> (I don't care about `await foo() + await bar()` but it would be okay.) >> ``` >> I think this is reasonable with some tweaks of the grammar (similar to >> what >> Greg did for cocall, but without requiring call syntax at the end). >> > > I've done some experiments with grammar, and it looks like > we indeed can parse await quite differently from yield. Three > different options: > > > Option #1. Parse 'await' exactly like we parse 'yield'. > This how we parse 'await' in the latest version of reference > implementation. > > Required grammar changes: > https://gist.github.com/1st1/cb0bd257b04adb87e167#file-option-1-patch > > Repo to play with: > https://github.com/1st1/cpython/tree/await > > Syntax: > > await a() > res = (await a()) + (await b()) > res = (await (await a())) > if (await a()): pass > return (await a()) > print((await a())) > func(arg=(await a())) > await a() * b() > > > Option #2. Keep 'await_expr' in 'atom' terminal, but don't > require parentheses. > > Required grammar changes: > https://gist.github.com/1st1/cb0bd257b04adb87e167#file-option-2-patch > > Repo to play with (parser module is broken atm): > https://github.com/1st1/cpython/tree/await_noparens > > Syntax: > > await a() > res = (await a()) + await b() # w/o parens (a() + await b()) > res = await await a() > if await a(): pass > return await a() > print(await a()) > func(arg=await a()) > await a() * b() > > > Option #3. Create a new terminal for await expression between > 'atom' and 'power'. > > Required grammar changes: > https://gist.github.com/1st1/cb0bd257b04adb87e167#file-option-3-patch > > Repo to play with (parser module is broken atm): > https://github.com/1st1/cpython/tree/await_noparens2 > > Syntax: > > await a() > res = await a() + await b() > res = await (await a()) # invalid syntax w/o parens > if await a(): pass > return await a() > print(await a()) > func(arg=await a()) > await (a() * b()) # w/o parens '(await a() * b()) > > > I think that Option #3 is a clear winner. > > Thanks, > Yury > > -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 492 vs. PEP 3152, new round
On 26 April 2015 at 06:18, Yury Selivanov wrote: > Option #3. Create a new terminal for await expression between > 'atom' and 'power'. > > Required grammar changes: > https://gist.github.com/1st1/cb0bd257b04adb87e167#file-option-3-patch > > Repo to play with (parser module is broken atm): > https://github.com/1st1/cpython/tree/await_noparens2 > > Syntax: > > await a() > res = await a() + await b() > res = await (await a()) # invalid syntax w/o parens > if await a(): pass > return await a() > print(await a()) > func(arg=await a()) > await (a() * b()) # w/o parens '(await a() * b()) > > I think that Option #3 is a clear winner. Very nice! How would the following statements parse with this option? res = await a(), b() res = [await a(), b()] with await a(), b: pass f(await a(), b) I think it's OK if these end up requiring parentheses in order to do the right thing (as that will be helpful for humans regardless), but the PEP should be clear as to whether or not they do: res = (await a()), b() res = [(await a()), b()] with (await a()), b: pass f((await a()), b) Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
