On 2015-04-23 18:51, Barry Warsaw wrote: > On Apr 21, 2015, at 01:26 PM, Yury Selivanov wrote: > >>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. > > There's a lot to like about PEP 492. I only want to mildly bikeshed a bit on > the proposed new syntax. > > Why "async def" and not "def async"? > > My concern is about existing tools that already know that "def" as the first > non-whitespace on the line starts a function/method definition. Think of a > regexp in an IDE that searches backwards from the current line to find the > function its defined on. Sure, tools can be updated but it is it *necessary* > to choose a syntax that breaks tools? > > def async useful(): > > seems okay to me. > > Probably the biggest impact on the PEP would be symmetry with asynchronous > with and for. What about: > > with async lock: > > and > > for async data in cursor: > > That would also preserve at least some behavior of existing tools. > > Anyway, since the PEP doesn't explicitly describe this as an alternative, I > want to bring it up. > > (I have mild concerns about __a*__ magic methods, since I think they'll be > harder to visually separate, but here the PEP does describe the __async_*__ > alternatives.) > On the other hand, existing tools might be expecting "def" and "for" to be followed by a name.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4