Re: [Python-Dev] Exposing the Android platform existence to Python modules

Shiz wrote: I'm not sure a check to see if e.g. /system exists is really enough to conclude Python is running on Android on its own. Since MacOSX has /System and typically a case-insensitive file system, it certainly wouldn't. :-) -- Greg ___ Python-

Re: [Python-Dev] sum(...) limitation

Steven D'Aprano wrote: I've long believed that + is the wrong operator for concatenating strings, and that & makes a much better operator. Do you have a reason for preferring '&' in particular, or do you just want something different from '+'? Personally I can't see why "bitwise and" on string

Re: [Python-Dev] Bytes path support

Ben Hoyt wrote: Does that mean that new APIs should explicitly not support bytes? > ... Bytes paths are essentially broken on Windows. But on Unix, paths are essentially bytes. What's the official policy for dealing with that? -- Greg ___ Python-Dev

Re: [Python-Dev] Bytes path support

Stephen J. Turnbull wrote: This case can be handled now using the surrogateescape error handler, So maybe the way to make bytes paths go away is to always use surrogateescape for paths on unix? -- Greg ___ Python-Dev mailing list Python-Dev@python.o

Re: [Python-Dev] Bytes path support

Antoine Pitrou wrote: I think if you want low-level features (such as unconverted bytes paths under POSIX), it is reasonable to point you to low-level APIs. The problem with scandir() in particular is that there is currently *no* low-level API exposed that gives the same functionality. If scan

Re: [Python-Dev] Bytes path support

Isaac Morland wrote: In HTML 5 it allows non-ASCII-compatible encodings as long as U+FEFF (byte order mark) is used: http://www.w3.org/TR/html-markup/syntax.html#encoding-declaration Not sure about XML. According to Appendix F here: http://www.w3.org/TR/xml/#sec-guessing an XML parser need

Re: [Python-Dev] surrogatepass - she's a witch, burn 'er! [was: Cleaning up ...]

M.-A. Lemburg wrote: we needed a way to make sure that Python 3 also optionally supports working with lone surrogates in such UTF-8 streams (nowadays called CESU-8: http://en.wikipedia.org/wiki/CESU-8). I don't think CESU-8 is the same thing. According to the wiki page, CESU-8 *requires* all co

Re: [Python-Dev] RFC: PEP 475, Retry system calls failing with EINTR

Victor Stinner wrote: As written in the PEP, if you want to be notified of the signal, set a signal handler which raises an exception. I'm not convinced that this covers all possible use cases. It might be all right if you have control over the signal handler, but what if you don't? I think it

Re: [Python-Dev] RFC: PEP 475, Retry system calls failing with EINTR

Victor Stinner wrote: Le 1 sept. 2014 00:17, "Marko Rauhamaa" > a écrit : > If a signal is received when read() or write() has completed its task > partially (> 0 bytes), no EINTR is returned but the partial count. > Obviously, Python should take that possibility int

Re: [Python-Dev] PEP 394 - Clarification of what "python" command should invoke

Donald Stufft wrote: My biggest problem with ``python3``, is what happens after 3.9. Python2 technically includes 1.x versions as well, so it wouldn't be unprecedented for python3 to imply versions beyond 3.x. It would be a bit confusing, though. -- Greg __

Re: [Python-Dev] PEP 394 - Clarification of what "python" command should invoke

Barry Warsaw wrote: On Sep 19, 2014, at 08:40 AM, Guido van Rossum wrote: Until I say so. Which will happen in the distant future. I'm gonna hid your time machine keys so you didn't find them. Hiding someone's time machine keys never works. Chances are he's already taken a trip to the futur

Re: [Python-Dev] bytes-like objects

anatoly techtonik wrote: That's a cool stuff. `bytes-like object` is really a much better name for users. I'm not so sure. Usually when we talk about an "xxx-like object" we mean one that supports a certain Python interface, e.g. a "file-like object" is one that has read() and/or write() method

Re: [Python-Dev] bytes-like objects

I wrote: But you can't create an object that supports the buffer protocol by implementing Python methods. Another thing is that an object implementing the buffer interface doesn't have to look anything at all like a bytes object from Python, so calling it "bytes-like" could be rather confusing

Re: [Python-Dev] Status of C compilers for Python on Windows

Nick Coghlan wrote: That assumption will allow MinGW-w64 to link with the appropriate MSVCRT versions for extention building without anything breaking. If that works, then the same technique should allow CPython itself to be built in a VS-compatible way with mingw, shouldn't it? Those objectin

Re: [Python-Dev] Real-world use of Counter

Ethan Furman wrote: Actually, it's asking, "Most other duck-typed methods will still raise a TypeError, but these few don't. Has that ever been a problem for you?" I don't think I've *ever* been bothered by getting an AttributeError instead of a TypeError or vice versa. Both indicate bugs in m

Re: [Python-Dev] Please reconsider PEP 479.

Guido van Rossum wrote: Hm, that sounds like you're either being contrarian or Chris and I have explained it even worse than I thought. I'm not trying to be contrary, I just think the PEP could explain more clearly what you're trying to achieve. The rationale is too vague and waffly at the mome

Re: [Python-Dev] PEP 479 and asyncio

Guido van Rossum wrote: The issue here is that asyncio only interprets StopIteration as returning from the generator (with a possible value), while a Trollius coroutine must use "raise Return()" to specify a return value; this works as long as Return is a subclass of StopIteration, but PEP 479

Re: [Python-Dev] advice needed: best approach to enabling "metamodules"?

Nathaniel Smith wrote: Option 4: Add a new function sys.swap_module_internals, which takes two module objects and swaps their __dict__ and other attributes. By making the operation a swap instead of an assignment, we avoid the lifecycle pitfalls from Option 3. Didn't I see somewhere that modul

Re: [Python-Dev] advice needed: best approach to enabling "metamodules"?

Guido van Rossum wrote: Are these really all our options? All of them sound like hacks, none of them sound like anything the language (or even the CPython implementation) should sanction. If assignment to the __class__ of a module were permitted (by whatever means) then you could put this in a

Re: [Python-Dev] advice needed: best approach to enabling "metamodules"?

Nathaniel Smith wrote: So pkgname/__new__.py might look like: import sys from pkgname._metamodule import MyModuleSubtype sys.modules[__name__] = MyModuleSubtype(__name__, docstring) To start with, the 'from pkgname._metamodule ...' line is an infinite loop, Why does MyModuleSubtyp

Re: [Python-Dev] advice needed: best approach to enabling "metamodules"?

Steven D'Aprano wrote: If this feature is going to be used, I would expect to be able to re-use pre-written module types. E.g. having written "module with properties" (so to speak) once, I can just import it and use it in my next project. There would be nothing to stop __new__.py importing it

Re: [Python-Dev] datetime nanosecond support (ctd?)

MRAB wrote: Maybe, also, strptime could support "%*f" to gobble as many digits as are available. The * would suggest that the number of digits is being supplied as a parameter. Maybe "%?f". -- Greg ___ Python-Dev mailing list Python-Dev@python.org ht

Re: [Python-Dev] bytes & bytearray

Guido van Rossum wrote: On Mon, Jan 19, 2015 at 11:43 AM, Paul Sokolovsky > wrote: b.lower_inplace() b.lower_i() Please don't go there. The use cases are too rare. And if you have such a use case, it's not too hard to do b[:] = b.lower() -- Greg _

Re: [Python-Dev] Why does STORE_MAP not take a parameter?

On 01/21/2015 11:16 PM, Neil Girdhar wrote: Why not have BUILD_MAP work like BUILD_LIST? I.e., STORE_MAP takes a parameter n and adds the last n pairs of stack elements into the n-1 stack element (the dictionary). It probably wouldn't make much difference. Building a list is substantially che

Re: [Python-Dev] Disassembly of generated comprehensions

Petr Viktorin wrote: On Sun, Jan 25, 2015 at 12:55 PM, Neil Girdhar wrote: How do I disassemble a generated comprehension? Put it in a function, then get it from the function's code's constants. It would be handy if dis had an option to disassemble nested functions like this automatically.

Re: [Python-Dev] Why co_names? Wouldn't be simpler to just use co_consts?

Andrea Griffini wrote: Sorry if the question is naive, but why is co_names needed? Wouldn't be simpler to just use co_consts? One reason might be that keeping them separate means you can have up to 256 names and 256 consts using 1-byte opcode arguments. Otherwise, you'd be limited to a total of

Re: [Python-Dev] Encoding of PyFrameObject members

Maciej Fijalkowski wrote: However, you can't access thread locals from signal handlers (since in some cases it mallocs, thread locals are built lazily if you're inside the .so, e.g. if python is built with --shared) You might be able to use Py_AddPendingCall to schedule what you want done outsi

Re: [Python-Dev] (no subject)

Donald Stufft wrote: why is: print(*[1], *[2], 3) better than print(*[1] + [2] + [3])? It could potentially be a little more efficient by eliminating the construction of an intermediate list. defining + or | or some other symbol for something similar to [1] + [2] but for dictionaries. This

Re: [Python-Dev] (no subject)

Donald Stufft wrote: However [*item for item in ranges] is mapped more to something like this: result = [] for item in iterable: result.extend(*item) Actually it would be result.extend(item) But if that bothers you, you could consider the expansion to be result = [] for item in itera

Re: [Python-Dev] (no subject)

Donald Stufft wrote: perhaps a better solution is to simply make it so that something like ``a_list + an_iterable`` is valid and the iterable would just be consumed and +’d onto the list. I don't think I like the asymmetry that this would introduce into + on lists. Currently [1, 2, 3] +

Re: [Python-Dev] (no subject)

Donald Stufft wrote: 1. The statement *item is roughly the same thing as (item[0], item[1], item[n]) No, it's not -- that would make it equivalent to tuple(item), which is not what it means in any of its existing usages. What it *is* roughly equivalent to is item[0], item[1], item[n] i.e

Re: [Python-Dev] (no subject)

Victor Stinner wrote: Le 10 févr. 2015 06:48, "Greg Ewing" <mailto:greg.ew...@canterbury.ac.nz>> a écrit : > It could potentially be a little more efficient by > eliminating the construction of an intermediate list. Is it the case in the implementation? If it has to

Re: [Python-Dev] (no subject)

Antoine Pitrou wrote: bytearray(b"a") + b"bc" bytearray(b'abc') b"a" + bytearray(b"bc") b'abc' It's quite convenient. It's a bit disconcerting that the left operand wins, rather than one of them being designated as the "wider" type, as occurs with many other operations on mixed types, e.

Re: [Python-Dev] (no subject)

John Wong wrote: I am actually amazed to remember dict + dict is not possible... there must be a reason (performance??) for this... I think it's mainly because there is no obviously correct answer to the question of what to do about duplicate keys. -- Greg __

Re: [Python-Dev] (no subject)

Georg Brandl wrote: The call syntax part is a mixed bag: on the one hand it is nice to be consistent with the extended possibilities in literals (flattening), but on the other hand there would be small but annoying inconsistencies anyways (e.g. the duplicate kwarg case above). That inconsistenc

Re: [Python-Dev] subclassing builtin data structures

Isaac Schwabacher wrote: IIUC, the argument is that the Liskov Substitution Principle is a statement about how objects of a subtype behave relative to objects of a supertype, and it doesn't apply to constructors because they aren't behaviors of existing objects. Another way to say that is that

Re: [Python-Dev] PEP 441 - Improving Python ZIP Application Support

Paul Moore wrote: The alternative, I guess, is to have *no* default and write no shebang unless -p is specified. +1. That sounds like a very good idea to me. -- Greg ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/li

Re: [Python-Dev] Emit SyntaxWarning on unrecognized backslash escapes?

Chris Angelico wrote: Then he changed the code over to use his own file instead of the provided sample, and at the same time, switched from using open() to using csv.reader(open()), and moved all the code into a function, and fixed three other bugs, and now it isn't working. And he can't figure o

Re: [Python-Dev] Emit SyntaxWarning on unrecognized backslash escapes?

Thomas Wouters wrote: Trying to make the error messages more similar, or more identifying, may be a good idea (as long as they aren't misleading when people *meant* to use escape sequences in a string) It seems that Windows won't let you use control characters in filenames, so there is room f

Re: [Python-Dev] super() does not work during class initialization

Martin Teichmann wrote: maybe we could just change the compiler to leave the order in which things are defined in a class in the class namespace, say as a member __order__? Then we could use plain-old dicts for the class namespace, and we would not slow down class creation (not that it matters mu

Re: [Python-Dev] PEP 487 vs 422 (dynamic class decoration)

On 04/03/2015 02:31 PM, Nick Coghlan wrote: If I'm understanding PJE's main concern correctly it's that this approach requires explicitly testing that the decorator has been applied correctly in your automated tests every time you use it, as otherwise there's a risk of a silent failure when you u

Re: [Python-Dev] PEP 487 vs 422 (dynamic class decoration)

Eric Snow wrote: I've felt for a long time that it would be helpful in some situations to have a reverse descriptor protocol. Can you elaborate on what you mean by that? -- Greg ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.or

Re: [Python-Dev] async/await in Python; v2

Yury Selivanov wrote: 1. CO_ASYNC flag was renamed to CO_COROUTINE; 2. sys.set_async_wrapper() was renamed to sys.set_coroutine_wrapper(); 3. New function: sys.get_coroutine_wrapper(); 4. types.async_def() renamed to types.coroutine(); I still don't like the idea of hijacking the generic

Re: [Python-Dev] async/await in Python; v2

Yury Selivanov wrote: On the other hand, I hate the idea of grammatically requiring parentheses for 'await' expressions. That feels non-pytonic to me. How is it any different from grammatically requiring parens in an ordinary function call? Nobody ever complained about that. In the PEP 3152

Re: [Python-Dev] async/await in Python; v2

Guido van Rossum wrote: On Wed, Apr 22, > OTOH I'm still struggling with what you have to do to wrap a coroutine in a Task, the way its done in asyncio by the Task() constructor, the loop.create_task() method, and the async() function That's easy. You can always use costart() to adapt a cofunc

Re: [Python-Dev] async/await in Python; v2

On 04/23/2015 04:18 AM, Yury Selivanov wrote: 2. We'll hack Gen(/ceval.c?) objects to raise an error if they are called directly and have a 'CO_COROUTINE' flag. By "Gen", do you mean the generator-function or the generator-iterator? That flag has to be on the generator-function, not the gener

Re: [Python-Dev] async/await in Python; v2

Yury Selivanov wrote: I think there is another way... instead of pushing GET_ITER ... YIELD_FROM opcodes, we'll need to replace GET_ITER with another one: GET_ITER_SPECIAL ... YIELD_FROM I'm lost. What Python code are you suggesting this would be generated from? -- Greg

Re: [Python-Dev] async/await in Python; v2

PJ Eby wrote: I find this a little weird. Why not just have `with` and `for` inside a coroutine dynamically check the iterator or context manager, and either behave sync or async accordingly? Why must there be a *syntactic* difference? It depends on whether you think it's important to have a

Re: [Python-Dev] async/await in Python; v2

Yury Selivanov wrote: - If it's an object with __await__, return iter(object.__await__()) Is the iter() really needed? Couldn't the contract of __await__ be that it always returns an iterator? -- Greg ___ Python-Dev mailing list Python-Dev@python.org

Re: [Python-Dev] async/await in Python; v2

Victor Stinner wrote: A huge part of the asyncio module is based on "yield from fut" where fut is a Future object. How do you write this using the PEP 3152? Do you need to call an artifical method like "cocall fut.return_self()" where the return_self() method simply returns fut? In a PEP 3152

Re: [Python-Dev] async/await in Python; v2

Victor Stinner wrote: Using a custom name like "cofunction" may confuse users coming from other programming languages. I prefer to keep "coroutine", but I agree that we should make some effort to define the different categories of "Python coroutines". I should perhaps point out that "cofunctio

Re: [Python-Dev] async/await in Python; v2

Ludovic Gasc wrote: Not related, but one of my coworkers asked me if with the new syntax it will be possible to write an async decorator for coroutines. This is certainly possible with PEP 3152. The decorator just needs to be an ordinary function whose return value is a cofunction. -- Greg __

Re: [Python-Dev] async/await in Python; v2

Paul Sokolovsky wrote: And having both asymmetric and symmetric would quite confusing, especially that symmetric are more powerful and asymmetric can be easily implemented in terms of symmetric using continuation-passing style. You can also use a trampoline of some kind to relay values back and

Re: [Python-Dev] async/await in Python; v2

Yury Selivanov wrote: So how would we do "await fut" if await requires parentheses? I've answered this with respect to PEP 3152 -- futures would implement __cocall__, so you would write 'cocall fut()'. I'm not sure what to say about PEP 492 here, because it depends on exactly what a version o

Re: [Python-Dev] async/await in Python; v2

Yury Selivanov wrote: I think that the problem of forgetting 'yield from' is a bit exaggerated. Yes, I myself forgot 'yield from' once or twice. But that's it, it has never happened since. I think it's more likely to happen when you start with an ordinary function, then discover that it needs

Re: [Python-Dev] async/await in Python; v2

Yury Selivanov wrote: So you would have to write 'await fut()'? This is non-intuitive. That's because PEP 492 and its terminology encourage you to think of 'await f()' as a two-step process: evaluate f(), and then wait for the thing it returns to produce a result. PEP 3152 has a different ph

Re: [Python-Dev] async/await in Python; v2

Andrew Svetlov wrote: From my understanding to use cofunctions I must wrap it with costart call: yield from gather(costart(coro1, a1, a2), costart(coro2), fut3) There are other places in asyncio API those accept coroutines or futures as parameters, not only Task() and async(). In a PEP 3152 a

Re: [Python-Dev] async/await in Python; v2

Paul Sokolovsky wrote: Greg Ewing wrote: You can also use a trampoline of some kind to relay values back and forth between generators, to get something symmetric. Yes, that's of course how coroutine frameworks were done long before "yield from" appeared and how Trollius

Re: [Python-Dev] PEP 3152 and yield from Future()

Victor Stinner wrote: I'm still trying to understand how the PEP 3152 would impact asyncio. Guido suggests to replace "yield from fut" with "cocall fut()" (add parenthesis) and so add a __cocall__() method to asyncio.Future. Problem: PEP 3152 says "A cofunction (...) does not contain any yield or

Re: [Python-Dev] async/await in Python; v2

Andrew Svetlov wrote: But we already have asyncio and code based on asyncio coroutines. To make it work I should always use costart() in places where asyncio requires coroutine. As I understand it, asyncio would require changes to make it work seamlessly with PEP 492 as well, since an object n

Re: [Python-Dev] PEP 3152 and yield from Future()

andrew.svet...@gmail.com wrote: I can live with `cocall fut()` but the difference between `data = yield from loop.sock_recv(sock, 1024)` and `data = cocall (loop.sock_recv(sock, 1024))()` frustrates me very much. That's not the way it would be done. In a PEP-3152-ified version of asyncio, sock

Re: [Python-Dev] PEP 3152 and yield from Future()

Victor Stinner wrote: You didn't answer to my question. My question is: is it possible to implement Future.__cocall__() since yield is defined in cofunctions. If it's possible, can you please show how? (Show me the code!) The implementation of a __cocall__ method is *not* a cofunction, it's an

Re: [Python-Dev] PEP 3152 and yield from Future()

Yury Selivanov wrote: Another problem is functions that return future: def do_something(): ... return fut With Greg's idea to call it you would do: cocall (do_something())() That means that you can't refactor your "do_something" function and make it a coroutine. There's no fundam

Re: [Python-Dev] async/await in Python; v2

Barry Warsaw wrote: Sure, tools can be updated but it is it *necessary* to choose a syntax that breaks tools? def async useful(): seems okay to me. That will break any tool that assumes the word following 'def' is the name of the function being defined. Putting it at the end would seem l

Re: [Python-Dev] async/await in Python; v2

Yury Selivanov wrote: If you have a future object 'fut', it's not intuitive or pythonic to write 'cocall fut()'. Another way to approach that would be to provide a cofunction await() used like this: cocall await(fut) That would read more naturally and wouldn't require modifying fut at all

Re: [Python-Dev] async/await in Python; v2

Yury Selivanov wrote: In a PEP 3152 aware version of asyncio, it's just *not possible to write* cocall gather(coro1(1,2), coro(2,3)) you just have to use your 'costart' built-in: cocall gather(costart(coro1, 1, 2), costart(coro, 2,3)). Another way to write that would be cocall gather(Task

Re: [Python-Dev] PEP 3152 and yield from Future()

Guido van Rossum wrote: I think this is the nail in PEP 3152's coffin. Seems more like a small tack to me. :-) I've addressed all the issues raised there in earlier posts. -- Greg ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.

Re: [Python-Dev] PEP 3152 and yield from Future()

Victor Stinner wrote: Oh, I missed something in the PEP 3152: a obj__cocall__() method can be an iterator/generator, it can be something different than a cofunction. In fact, it *can't* be cofunction. It's part of the machinery for implementing cofunctions. It's not easy to understand the who

Re: [Python-Dev] PEP 3152 and yield from Future()

Yury Selivanov wrote: It's a common pattern in asyncio when functions return futures. It's OK later to refactor those functions to coroutines *and* vice-versa. This is a fundamental problem for PEP 3152 approach. Hmmm. So you have an ordinary function that returns a future, and you want to t

Re: [Python-Dev] async/await in Python; v2

Stephen J. Turnbull wrote: Yury Selivanov writes: > I also read "for async item in iter:" as "I'm iterating iter > with async item". I thought that was precisely the intended semantics: item is available asynchronously. The async-at-the-end idea could be used here as well. for item in i

Re: [Python-Dev] PEP 3152 and yield from Future()

Paul Moore wrote: On 24 April 2015 at 09:34, Greg Ewing wrote: cocall await(cocall f(x)) That doesn't look so bad to me. I've not been following this discussion (and coroutines make my head hurt) but this idiom looks like it's bound to result in people getting the idea t

Re: [Python-Dev] PEP 492 vs. PEP 3152, new round

Guido van Rossum wrote: 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()) ``` Making 'await' a prefix ope

Re: [Python-Dev] async/await in Python; v2

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 Python-Dev@python.org https://mail.

Re: [Python-Dev] PEP 492 vs. PEP 3152, new round

Victor Stinner wrote: That's why I suggest to reconsider the idea of supporting an *optional* "from __future__ import async" to get async and await as keywords in the current file. This import would allow all crazy syntax. The parser might suggest to use the import when it fails to parse an asyn

Re: [Python-Dev] PEP 492 vs. PEP 3152, new round

Guido van Rossum wrote: Sorry, when I wrote "future" (lower-case 'f') I really meant what Yury calls *awaitable*. That's either a coroutine or something with an __await__ emthod. But how is an awaitable supposed to raise StopIteration if it's implemented by a generator or async def[*] function

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

Re: [Python-Dev] PEP 492 vs. PEP 3152, new round

Yury Selivanov wrote: I've done some experiments with grammar, and it looks like we indeed can parse await quite differently from yield. Three different options: You don't seem to have tried what I suggested, which is to make 'await' a unary operator with the same precedence as '-', i.e. replac

Re: [Python-Dev] PEP 492 vs. PEP 3152, new round

Yury Selivanov wrote: I don't want this: "await a() * b()" to be parsed, it's not meaningful. Why not? If a() is a coroutine that returns a number, why shouldn't I be able to multiply it by something? I don't think your currently proposed grammar prevents that anyway. We can have --> '*'

Re: [Python-Dev] PEP 492 vs. PEP 3152, new round

Yury Selivanov wrote: Looking at the grammar -- the only downside of the current approach is that you can't do 'await await fut'. I still think that it reads better with parens. If we put 'await' to 'factor' terminal we would allow await -fut # await (-fut) Is there really a need to dis

Re: [Python-Dev] PEP 492: async/await in Python; v3

Yury Selivanov wrote: It's important to at least have 'iscoroutine' -- to check that the object is a coroutine function. A typical use-case would be a web framework that lets you to bind coroutines to specific http methods/paths: @http.get('/spam') async def handle_spam(request):

Re: [Python-Dev] PEP 492: async/await in Python; v3

Guido van Rossum wrote: There's a cost to __future__ imports too. The current proposal is a pretty clever hack -- and we've done similar hacks in the past There's a benefit to having a __future__ import beyond avoiding hackery: by turning on the __future__ you can find out what will break when

Re: [Python-Dev] PEP 492 vs. PEP 3152, new round

Guido van Rossum wrote: I don't care for await await x. But do you dislike it enough to go out of your way to disallow it? -- Greg ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: htt

Re: [Python-Dev] PEP 492: async/await in Python; v3

Yury Selivanov wrote: I also like Guido's suggestion to use "native coroutine" term. I'll update the PEP (I have several branches of it in the repo that I need to merge before the rename). I'd still prefer to avoid use of the word "coroutine" altogether as being far too overloaded. I think eve

Re: [Python-Dev] PEP 492: async/await in Python; v3

Guido van Rossum wrote: On Mon, Apr 27, 2015 at 8:07 PM, Yury Selivanov > wrote: > Why StopAsyncIteration? ''' I keep wanting to propose to rename this to AsyncStopIteration. +1, that seems more consistent to me too. And since

Re: [Python-Dev] PEP 492: async/await in Python; v3

Yury Selivanov wrote: On 2015-04-28 11:59 PM, Greg wrote: On 29/04/2015 9:49 a.m., Guido van Rossum wrote: *But* every generator-based coroutine *must* be decorated with `asyncio.coroutine()`. This is potentially a backwards incompatible change. See below. I worry about backwar

Re: [Python-Dev] PEP 492: async/await in Python; v3

Yury Selivanov wrote: 3. GenObject __iter__ and __next__ raise error *only* if it has CO_NATIVE_COROUTINE flag. So iter(), next(), for..in aren't supported only for 'async def' functions (but will work ok on asyncio generator-based coroutines) What about new 'async def' code called by existin

Re: [Python-Dev] PEP 492 vs. PEP 3152, new round

Yury Selivanov wrote: It's just like unary minus ;) I'm confused. I thought you were arguing that your grammar is better because it's *not* just like unary minus? If being just like unary minus is okay, then why not just make it so? -- Greg ___ Pyt

Re: [Python-Dev] PEP 492: async/await in Python; v3

Yury Selivanov wrote: Won't that prevent some existing generator-based coroutines (ones not decorated with @coroutine) from calling ones implemented with 'async def'? It would. But that's not a backwards compatibility issue. It seems to go against Guido's desire for the new way to be a 100%

Re: [Python-Dev] PEP 492 vs. PEP 3152, new round

Yury Selivanov wrote: I'm not sure why Greg is pushing his Grammar idea so aggressively. Because I believe that any extra complexity in the grammar needs a very strong justification. It's complexity in the core language, like a new keyword, so it puts a burden on everyone's brain. Saying "I do

Re: [Python-Dev] PEP 492: What is the real goal?

Paul Moore wrote: I agree. While I don't use coroutines/asyncio, and I may never do so, I will say that I find Python's approach very difficult to understand. Well, I tried to offer something easier to understand. The idea behind PEP 3152 is that writing async code should be just like writing t

Re: [Python-Dev] PEP 492 vs. PEP 3152, new round

Nathaniel Smith wrote: (I suspect this may also be the impetus behind Greg's request that it just be treated the same as unary minus. IMHO it matters much more that the rules be predictable and teachable than that they allow or disallow every weird edge case in exactly the right way.) Exactly

Re: [Python-Dev] PEP 492: What is the real goal?

Yury Selivanov wrote: Everybody is pulling me in a different direction :) Guido proposed to call them "native coroutines". Some people think that "async functions" is a better name. Greg loves his "cofunction" term. Not the term, the *idea*. But PEP 492 is not based on that idea, so I don't a

Re: [Python-Dev] PEP 492: What is the real goal?

Skip Montanaro wrote: According to Wikipedia , term "coroutine" was first coined in 1958, so several generations of computer science graduates will be familiar with the textbook definition. If your use of "coroutine" matches the textbook definition of the

Re: [Python-Dev] PEP 492 vs. PEP 3152, new round

Yury Selivanov wrote: Sorry, but I'm not sure where & when I had any troubles predicting the consequences.. You said you wanted 'await a() * b()' to be a syntax error, but your grammar allows it. -- Greg ___ Python-Dev mailing list Python-Dev@python.

Re: [Python-Dev] PEP 492 vs. PEP 3152, new round

Nathaniel Smith wrote: Even if we put aside our trained intuitions about arithmetic, I think it's correct to say that the way unary minus is parsed is: everything to the right of it that has a tighter precedence gets collected up and parsed as an expression, and then it takes that expression as i

Re: [Python-Dev] PEP 492 quibble and request

Ethan Furman wrote: Having gone through the PEP again, I am still no closer to understanding what happens here: data = await reader.read(8192) What does the flow of control look like at the interpreter level? Are you sure you *really* want to know? For the sake of sanity, I recommend ignori

Re: [Python-Dev] PEP 492: async/await in Python; version 4

Yury Selivanov wrote: 3. CO_NATIVE_COROUTINE flag. This enables us to disable __iter__ and __next__ on native coroutines while maintaining full backwards compatibility. I don't think you can honestly claim "full backwards compatibility" as long as there are some combinations of old-style and n

Re: [Python-Dev] PEP 492: What is the real goal?

Paul Moore wrote: Also, can I run the produce/consume just by calling produce()? My impression is that with asyncio I need an event loop - which "traditional" coroutines don't need. The Pythonic way to do things like that is to write the producer as a generator, and the consumer as a loop that

Re: [Python-Dev] PEP 492: async/await in Python; version 4

Yury Selivanov wrote: Well, using next() and iter() on coroutines in asyncio code is something esoteric. I can't even imagine why you would want to do that. I'm talking about the fact that existing generator- based coroutines that aren't decorated with @coroutine won't be able to call new ones

Re: [Python-Dev] PEP 492 vs. PEP 3152, new round

Nathaniel Smith wrote: If await acted like -, then this would be await (x ** 2) But with the proposed grammar, it's instead (await x) ** 2 Ah, I had missed that! This is a *good* argument for Yuri's grammar. I withdraw my objection now. -- Greg ___

  1   2   3   4   5   6   7   8   9   10   >