will make comprehensions
and generators behave identically.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
lable using either yield from f() or await f().
That would water down the error catching ability a bit, but
it would allow interoperability with existing asyncio code.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/ma
That seems unavoidable if the goal is for 'await' to only
work on generators that are intended to implement coroutines,
and not on generators that are intended to implement
iterators. Because there's no way to tell them apart
wi
mediately obvious that this is parsed as
'not (a + b)' rather than '(not a) + b'.
The presence of one arbitrary and unintuitive thing in the
grammar is not by itself a justification for adding another one.
--
Greg
___
P
essary to be able to write the
things we *do* want also happens to allow those. I don't see
that as a problem worth worrying about.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
emantics*. You can't view
it as simply a translation of the Python expression into a
different language.
I still think this is really a macro facility by a different
name. I'm not saying that's a bad thing, just pointing it out.
On 3/12/2015 5:41 a.m., Random832 wrote:
Why bother with the dot? Why not rename 3.5 to Python 5, and then go to
Python 6, etc, and then your "4.0" would be 10.
Then we could call it Python X!
Everything is better with an X in the name
nternal details of that
debate make sense to the rest of us. The main thing is that
a consensus seems to have been reached on bytes formatting
being basically a good thing.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/m
ut 15
being less than 42 .
When we do that, we're using cardinal numbers (how many), not ordinal
numbers (what order).
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscr
3
orange = 4
class __methods__:
def wave(self, n=1):
for _ in range(n):
print('Waving', self)
and have the metaclass pull the functions out of the __methods__
sub-object.
--
Greg
___
Python-Dev mailing list
P
y are just to establish the relative ordering.
They wouldn't be directly accessible once the values are
created. To get an integer value corresponding to a Day value,
you would have to do arithmetic:
Day.wednesday - Day.sunday --> 3
--
Greg
_
ase for the recently advertised
macro system?
("One, two, five..." runs for cover...)
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/opt
l, I think.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
On 9/09/2013 5:52 a.m., Guido van Rossum wrote:
Well, to me zip(*x) is unnatural, and it's inefficient when the arrays are long.
Would it be worth having a transpose() function in the stdlib
somewhere, that returns a view instead of copying the data?
--
all over the place, from the lowest to the highest levels.
But that doesn't mean you need a correspondingly large
number of locks. You can't look at a 'yield' and conclude
that you need a lock there or tell what needs to be locked.
There's no substi
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
nally I can't see why "bitwise and" on strings should
be a better metaphor for concatenation that "addition". :-)
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscri
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
__
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
scandir() is not to support bytes paths, I'd suggest
exposing the opendir() and readdir() system calls with
bytes path support.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
needs to be prepared to try all the encodings it
supports until it finds one that works well enough to decode
the XML declaration, then it can find out the exact encoding
used.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org
-8
sequences of more than three bytes, so it's definitely not
"UTF-8 plus lone surrogates".
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.
?
I think it's best if the functions in the os module remain
thin wrappers that expose the OS functionality as fully and
directly as possible. Anything else should be provided
by higher-level facilities.
--
Greg
___
Python-Dev mailing list
Python
n out of in the EINTR case.
But what happens if the read returns *without* an EINTR?
The signal handler will still raise an exception, which is
either going to clobber the partial return value or mess
up the code that does something with it.
--
Greg
___
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.
--
taken a trip to the future in which you get
kidnapped and tortured until you reveal where you hid them,
and then nipped over there to take them back. Which means
he *might* be able to avoid carrying out the actual torture
now, as long as it doesn't create too big a t
e that has read() and/or write() methods. But you can't
create an object that supports the buffer protocol by implementing
Python methods.
I'm worried that using the term "bytes-like object" will lead
people to ask "What methods do I have to implement to make my
obj
uot;
could be rather confusing.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Those objecting to a mingw-built python seem to be assuming
that such a thing will necessarily be incompatible with
VS builds, but I don't see why that has to be the case.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.o
at is worth whatever small benefit
there might be, if any.
Summary: Looks fine to me as it is.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
d waffly at the moment.
Currently, there are cases where list(x for x in xs if P(x)) works while
[x for x in xs if P(x)] fails (when P(x) raises StopIteration). With the
PEP, both cases will raise some exception
That's a better explanation, I think.
--
Greg
__
ub-iteration as usual and its value attribute gets assigned to x.
As long as a Trollius coroutine behaves like something implementing
the iterator protocol, it should continue to work fine with
Return as a subclass of StopIteration.
Or is there something non-obvious about
that module dicts are not being
cleared on shutdown any more? If so, then the lifetime
problem mentioned here no longer exists.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
features -- just removing a restriction that prevents an
existing language mechanism from working in this case.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https
Why does MyModuleSubtype have to be imported from pkgname?
It would make more sense for it to be defined directly in
__new__.py, wouldn't it? Isn't the purpose of separating
stuff out into __new__.py precisely to avoid circularities
like that?
--
Greg
__
py importing it
from another module, as long as it's not any of the
modules that are going to be using it.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mai
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
P
Guido van Rossum wrote:
On Mon, Jan 19, 2015 at 11:43 AM, Paul Sokolovsky <mailto:pmis...@gmail.com>> 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[:] =
ation, evaluating the items one at a time requires less
stack space, so the stack frame can be smaller.
But as always, you can't be sure without measuring it, and
this would be a good thing for someone interested to try out.
--
Greg
___
Python-Dev ma
omatically.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
to a total of 256 of both.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
nvolved
in doing that.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
would mean that you could simply do:
func(**dict1 | dict(y=1) | dict2)
Same again, multiple ** avoids construction of an
itermediate dict.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
call to
me.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
2, 3] + (4, 5, 6)
is an error because it's not clear whether the
programmer intended the result to be a list or
a tuple. I think that's a good thing.
Also, it would mean that
[1, 2, 3] + foo == [1, 2, 3, "f", "o", "o"]
which would be surprising
in a comprehension, i.e. this
is a syntax error:
[item[0], item[1], item[n] for item in items]
So we would be giving a meaning to something that
doesn't currently have a meaning, rather than changing
an existing meaning, if you see what I mean
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
:
File "", line 1, in
TypeError: can't concat bytes to list
>>> [1,2,3] + b"a"
Traceback (most recent call last):
File "", line 1, in
TypeError: can only concatenate list (not "bytes") to list
--
Greg
_
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.
--
inconsistency already exists -- duplicate keys are
allowed in dict literals but not calls:
>>> {'a':1, 'a':2}
{'a': 2}
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/
at is that constructors are class
methods, not instance methods.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/arch
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
7;t figure out why.
There's probably a useful meta-lesson in there:
test after making every change!
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/
re is room for a
more pointed error message from functions that
take pathnames on Windows.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/
much), as determining the order would happen at
compile time.
I don't think the compiler can determine the order in
all cases. Consider:
class Spam:
if moon_is_full:
alpha = 1
beta = 2
else:
beta = 2
alpha = 1
--
ent failure when you use the
decorator but omit the mandatory base class that makes the decorator
work correctly.
Could the decorator be designed to detect that situation
somehow? E.g. the first time the decorated method is called,
check that the required base class
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
this automatically from the fact
that you can't make an ordinary call to a cofunction,
and cocall combines a call and a yield-from. You have
to go out of your way to get hold of the underlying
iterator to use in a for-loop, etc.
--
Greg
___
Python-
making this the *actual*
interpretation of "cocall f(x)".
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
() to adapt a cofunction
for use with something expecting a generator-based coroutine,
e.g.
codef my_task_func(arg):
...
my_task = Task(costart(my_task_func, arg))
If you're willing to make changes, Task() et al could be made to
recognise cofunctions and apply costart() wher
await coro_gen()'.
Maybe. I haven't thought that idea through properly yet.
Possibly the answer is that you define such a function
using an ordinary "def", to match the way it's called.
The fact that it's an async generator is then indicated
by the fact that it cont
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
lly, highlights one of the things that's been
bothering me about all this "async foo" stuff: "async def" looks like
it *defines the function* asynchronously
That bothers me a bit, too, but my main problem with it
is the way it displaces the function na
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
w)
if isinstance(res, futures.Future) or inspect.isgenerator(res):
res = yield from res
To accommodate the possibility of func being a cofunction,
you would need to add something like
if is_cofunction(func):
res = yield from costart(func, *args, **kw)
else:
is
something they need to look up and learn about.
Whereas they may think they already know what a
"coroutine" is and not bother to look further.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/pyth
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
and forth between generators,
to get something symmetric.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail
bles a
PEP 3152 cocall. That misses the point, which is that a
cocall is a special kind of function call, not a special
kind of yield-from.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscri
n, then discover that it needs to
be suspendable, so you need to track down all the
places that call it, and all the places that call
those, etc. PEP 3152 ensures that you get clear
diagnostics if you miss any.
--
Greg
___
Python-Dev mailing li
ter is clearer, because it makes it
very obvious that the body of func is *not* executed
before the Task is constructed. The former makes it
look as though the *result* of executing func with
args is being passed to Task, rather than func itself.
--
Greg
__
aware version of asyncio, they would all
know about cofunctions and what to do with them.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options
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
ible to suspend a cofunction if it's not possible to use yield?
The currently published version of PEP 3152 is not
really complete. A few things would need to be added
to it, one of them being a suspend() builtin that
has the same effect as y
needs to have either a special flag or
an __await__ method before it can have 'await'
applied to it.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.
yncio, sock_recv would be a cofunction, so
that would be just
data = cocall loop.sock_recv(sock, 1024)
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/ma
tion, it's an *ordinary* function that returns
an iterator. In the case of Future, what it needs to
do is identical to Future.__iter__. So the code can
be just
def __cocall__(self):
return iter(self)
or equivalent.
--
Greg
___
Python-D
ng you're going to be doing
much in practice. If you're just going to
immediately call the result, there's no point
in returning a future -- just do it all in
do_something().
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
h
would seem least likely to
cause breakage:
def useful() async:
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/arch
x27;t require
modifying fut at all.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
that. It adds some things and
changes some things, but it doesn't simplify anything.
Your idea of syntaticaly forcing to use 'cocall' with
parens is cute,
You say that as though "forcing" the use of parens were
a goal in itself. It's not -- it's a *consequence* o
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
understand the whole puzzle. IMO the PEP 492 better
explains how pieces are put together ;-)
Yes, it's written in a rather minimal style, sorry
about that.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman
dvantage there is in keeping the future-
returning part of the API.
However, if we use the await()-cofunction idea,
then a call to the initial version looks like
cocall await(f(x))
and after the refactoring it becomes
cocall await(cocall f(x))
That doesn't lo
d here as well.
for item in iter async:
...
with something as x async:
...
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/op
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
' a prefix operator with the same precedence
as unary minus would allow most reasonable usages, I think.
The only reason "yield from" has such a constrained syntax
is that it starts with "yield", which is similarly constrained.
Since 'await' is a brand new keywo
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
Py
d of
error, and that what there is will only be active in
a special debug mode.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/pytho
utines" seems far too ambiguous.
(There should be a Zen item something along the lines
of "If you can't think of a concise and unambiguous name
for it, it's probably a bad idea".)
--
Greg
___
Python-Dev mailing list
Python-D
ought of a way to do that
yet, though.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
ecedence
as '-', i.e. replace
factor: ('+'|'-'|'~') factor | power
with
factor: ('+'|'-'|'~'|'await') factor | power
That would allow
await a()
res = await a() + await b()
res = await await a()
if aw
nd, seem to prevent
x = - await a()
which looks perfectly sensible to me.
I don't like the idea of introducing another level
of precedence. Python already has too many of those
to keep in my brain. Being able to tell people "it's
just like unary minus" makes it easy to explai
(-fut)
Is there really a need to disallow that? It would take
a fairly bizarre API to make it meaningful in the first
place, but in any case, it's fairly clear what order
of operations is intended without the parens.
--
Greg
___
Python-Dev
sallow *this*:
# *Not* decorated with @coroutine
def some_algorithm_impl():
yield 1
yield from iterator_implemented_by_generator()
I hope to agree that this is a perfectly legitimate
thing to do, and should remain so?
--
Greg
___
Pyth
what will break when they become real keywords.
But I suppose that could be achieved by having both the
hack *and* the __future__ import available.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-
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
Unsubs
on" seems like a clear and
unabmigious way to refer to the former. I'm not sure
what to call the latter.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
--
There is a proposal to add similar mechanism to ECMAScript 7 [2]_. A
key difference is that JavaScript "async functions" always return a
Promise. While this approach has some advantages, it also implies that
a new Promise object is created on e
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
1 - 100 of 2499 matches
Mail list logo
