ased
coroutines (ones not decorated with @coroutine)
from calling ones implemented with 'async def'?
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.py
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
code to the
new style as well. The new style will thus be
"infectious" in a sense.
I suppose it's up to Guido to decide whether it's
a good or bad infection. But the same kind of
reasoning seemed to be at least partly behind
the rejection of PEP 3152.
--
Greg
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 br
l data
becomes available.
You would only need to yield if you were implementing
some new synchronisation primitive. Yury's answer to
that appears to be that you don't do it with an async
def function, you create an object that implements
the awaitable-object protocol directly.
--
Greg
_
t way.)
Exactly.
--
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
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
hat page calls a "generator" or "semicoroutine":
they differ in that coroutines can control where execution
continues after they yield, while generators cannot, instead
transferring control back to the generator's caller.
--
Greg
___
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 mail
;, we think we already know
what it means. There is only one possible order for
the operations, so it doesn't look as though precedence
comes into it at all, and we don't consider it when
judging whether it's a valid expression.
What's the conclusion from all this? I think it's
t
ignoring the actual control
flow and pretending that it's just like
data = reader.read(8192)
with the reader.read() method somehow able to be
magically suspended.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/ma
f old-style and new-style code that won't work
together. You seem to be using your own personal
definition of "full" here.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubsc
as a
loop that iterates over it. Or the consumer as a
generator, and the producer as a loop that send()s
things into it.
To do it symmetrically, you would need to write them
both as generators (or async def functions or whatever)
plus a mini event loop to tie the two tog
be able to call new ones that use
async def.
This means that converting one body of code to the
new style can force changes in other code that
interacts with it.
Maybe this is not considered a problem, but as long
as it's true, I don't think it's accurate to claim
"
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
yielding.
But even if x yields, there is no guarantee that the
scheduler will run something else -- it might just
resume the same task, even if there is another one that
could run. It's up to the scheduler whether it
implements any kind of "
) or
poll() or I/O completion queues, and build that
into the heart of your event loop. At that point
it's no longer something with a simple core.
--
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
Paul Moore wrote:
What about Greg Ewing's example?
http://www.cosc.canterbury.ac.nz/greg.ewing/python/yield-from/yf_current/Examples/Scheduler/scheduler.txt
That doesn't cover any of the higher level abstractions like tasks or
futures (at least not by those names or with those
x27;s quit accurate. Yield-from treats
any object having send() and throw() methods the same
way it treats a generator -- there's nothing special
about the generator *type*. Presumably 'await' is the
same.
--
Greg
___
Python-Dev mailing list
Py
Paul Moore wrote:
I can't see how you can meaningfully talk about event
loops in a Python context without having *some* term for "things you
wait for".
PEP 3152 was my attempt at showing how you could do that.
--
Greg
___
Python-D
while-waiting-for-i-o.htm
That's probably enough of a hook to be able to get
asyncio-style file I/O working on top of Tkinter.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscri
t rule: If you want
a context change encapsulated, use a with-statement. If
you don't, don't.
Not only is this rule simpler than yours, it's the
*same* rule that we have now, so there is less for
users to learn.
--
Greg
___
Python-De
an improvement,
but it's orthogonal to what we're talking about here
and would be best discussed separately.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.py
push, and it has some disadvantages,
such as yield-from not quite working as expected in
some situations.
Also, it seems that every generator is going to incur
the overhead of allocating a logical_context even when
it doesn't actually change any context vars, which most
generators won'
text" totally
fails to do.
It might also serve as a source for some better
terminology for parts of the implementation, such as
TaskLocalStorage and TaskLocalStorageStack instead
of logical_context and execution_context. I found
the latter terms almost
tance, why can't it be updated in-place?
--
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
ext__ = contextvars.LogicalContext()
looks like it's creating a new one.
However, there's another thing: it looks like every
time a generator is resumed/suspended, an execution
context node is created/discarded.
--
Greg
___
Python-Dev mailing list
Python-Dev@p
somewhere
else?
--
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
.
--
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
ey're only there to provide a level of lazy evaluation.
You would evaluate them and then introspect the returned
data structure.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscri
ts of a pyc. So enabling deprecation
warnings for __main__ only wouldn't result in me seeing any
more warnings.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.
for __main__?
--
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
Ethan Furman wrote:
Contriwise, "annotation_strings" sounds like a different type of
annotation -- they are now being stored as strings, instead of something
else.
How about "annotations_as_strings"?
--
Greg
___
Python-Dev mai
rd way to represent Python programs using Python
data structures.
--
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
complicated set of Python objects, that
isn't needed by the compiler and exists purely for
the convenience of Python code.
I can't see much complexity being added if we were
to decide to standardise the Python representation.
--
Greg
___
Python-Dev
t with the module object goes ahead, maybe it would enable
using this idiom to reassign the module class:
class __class__(__class__):
# module methods here
Badger-badger-badger-ly,
Greg
___
Python-Dev mailing list
Python-Dev@python
m the enclosing
generator function.
Fixing that would require adding another whole layer of complexity
similar to what Yuri did to support async generators, and I can't
see that being worth the effort.
--
Greg
___
Python-Dev mailing list
Python-
2 was rejected, because I think
it would have helped people like you by providing a mental
model for async stuff that's much easier to reason about.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/
ences have never been intended
as exact descriptions of the semantics, but just a way
of quickly getting across the general idea. Further
words are needed to pin down all the fine details.
--
Greg
___
Python-Dev mailing list
Python-Dev@python
yield in a generator expression do anything
sensible.
Consider this:
def g():
return ((yield i) for i in range(10))
Presumably the yield should turn g into a generator, but...
then what? My brain is hurting trying to figure out what
it should do
list comprehension won't be equivalent
to list(generator_expression) in all cases, but I
don't think there's any great need for it to be.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman
Ivan Levkivskyi wrote:
On 23 November 2017 at 05:44, Greg Ewing <mailto:greg.ew...@canterbury.ac.nz>> wrote:
def g():
return ((yield i) for i in range(10))
I think this code should be just equivalent to this code
def g():
temp = [(yield i) for i in
Ivan Levkivskyi wrote:
"People sometimes want to refactor for-loops containing `yield` into a
comprehension
By the way, do we have any real-life examples of people wanting to
do this? It might help us decide what the semantics should be.
--
hat's changed is that we now have someone
offering to do 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
nt in using a generator expression.
--
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
t;a" is the original
name, mapping it back would be easy. It would also be easily
understood even if it weren't mapped back.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscrib
ld notice if it were changed back.
--
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
by a very clear piece of syntax, but with comprehensions
you have to notice a combination of things that don't
have anything to do with function scopes by themselves.
So I think I've just talked myself into the opinion that
anything that would allow you to tell whether comprehensions
, though.
I take it you're saying the semantics should be "like the
above except that the returned iterator is lazy". But that
seems impossible, because f() can't return anything until it
finishes having all its values sent to it.
--
Greg
__
y: float
z: float
@dataclass
class Vector3d:
x: float
y: float
z: float
Points and vectors are different things, and they should never
compare equal, even if they have the same field names and values.
--
Greg
___
Python-Dev mailing list
ter is that you can't accidentally
apply the wrong operation, e.g. transform_point on something
that's actually a vector.
(There's actually a third way -- use homogeneous coordinates
and represent points as (x, y, z, 1) and vectors as
(x, y, z, 0). But t
Guido van Rossum wrote:
The source for sleep() isn't very helpful -- e.g. @coroutine is mostly a
backwards compatibility thing.
So how are you supposed to write that *without* using @coroutine?
--
Greg
___
Python-Dev mailing list
Pytho
g called is determined by some computation,
that computation may be performed before its arguments are
evaluated (and is probably required to be, by the "left to
right" rule). But the arguments will always be evaluated
before the actual call happens.
--
Greg
___
Mode?
UTF8-Yeah-I'm-Fine-With-That 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/python-dev/archive%40mail-archive.com
ng used by default?
I.e.
open("foo", "rt") --> surrogateescape
open("foo") --> strict
That way you can easily open a file in a way that's
compatible with the way stdin/stdout behave, but you
will get bi
Guido van Rossum wrote:
There needs to be some way to introspect a
Context, for debugging.
It could have a read-only introspection interface without
having to be a full Mapping.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https
Guido van Rossum wrote:
contextvars.copy_context().run(func, )
If contexts are immutable, why is there something
called copy_context?
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
got).
In that case it seems clear to me that "the context" is
conceptually a mutable mapping. The fact that it happens
to be built out of immutable components is an implementation
detail that user-level docs should not be talking about
"collection of associations between keys
and values that can be changed somehow" then by all means
use it.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://ma
"unhashable" boolean
flag for the third option.
--
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
thon 3?
Guido has repeatedly promised that there will never be another
upheaval as big as the 2-to-3 one, and that the change from
Python 3.9 to 4.0 won't be anything special. Hopefully we can
trust him on that.
--
Greg
___
Python-Dev mailing list
Pyt
tance attribute. And I don't even want to think what
multiple inheritance would do to all this.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailm
ck door, it might as well be used for all
initialisation, maing the freeze method unnecessary.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/option
Tim Peters wrote:
An obvious way to extend it is for Fraction() to look for a special
method too, say "_as_integer_ratio()".
Why not __as_integer_ratio__?
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.o
Tim Peters wrote:
from trig functions doing argument reduction as if pi were represented
with infinite precision,
That sounds like an interesting trick! Can you provide
pointers to any literature describing how it's done?
Not doubting it's possible, just curious
Paul Moore wrote:
the next question will likely be "so why does = exist at all?"
And if we decide to make ':=' the official assigment operator and
deprectate '=', the next question will be "Why do we have '=='
instead of '='?"
--
already using "=" for something else.
So maybe we should just implement "from __future__ import pascal"
and be done with. :-)
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Un
makes more sense when you read it as an
English sentence:
if ((x - x_base) as diff) and ...
"If x - x_base (and by the way, I'm going to call that
diff so I can refer to it later) is not zero ..."
--
Greg
___
Python-Dev mai
re being
relied on.
--
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
" or
"if diff, which we define as x - x_base, and g, which ." etc.
How about "being" as a keyword:
if (diff being x - x_base) and (g being gcd(diff, n)) > 1:
return g
An advantage is that you're not likely to be tempted to write
bound names to be all-uppercase. :-)
if (x - x_base) {DIFF} and gcd(DIFF, n) {G} > 1:
return G
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/
Nick Coghlan wrote:
I'd be +0 on an "is=" spelling
But "is=' looks like some kind of comparison
operator. This seems even more conusing to me.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.or
require more mental effort to understand.
Hmmm, maybe they should be called "spaghetti expressions". :-)
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.
(buffer))
--
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
* one (two different assignment
operators with overlapping use cases) that we won't be
able to get rid of without a Python 4000 (that Guido has
promised won't happen).
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.pyt
:= were the one
and only assignment symbol, the compiler could easily optimise
away the extra DUP_TOP or whatever is involved.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https:
rebound to something that depends on its previous value.
2. Order of evaluation is being relied on to ensure that
the new value of total is compared to its old value.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailma
ffhand, but here's a possible solution:
x := expr # doesn't print anything
(x := expr) # prints the result
I.e. special-case a stand-alone assignment, but
allow overriding that with parens if needed.
--
Greg
___
Python-Dev mailing li
from the previous values of the
names.
--
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
cated just
to forbid something that some peple think is bad style.
--
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 way from the start.
I'm not aware of any that began by forbidding assignment in
expressions and then added it later.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
using change. It's a fine idea
for a new language, but I can't see a smooth way to get there
from existing Python.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://
the style of the
language, bigger even than making "print" no longer a
statement. It seems like there should be more justification
for it than "well, it became redundant with :=".
How would you complete the following sentence? "The ':='
symbol is a much
Is it a failure if we don't succeed in doing the impossible?
--
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
Alex Walters wrote:
PEP 3099 is the big list of things that will not happen in Python 3.
"There will be no alternative binding operators such as :=."
The thread referenced by that is taling about a different issue,
i.e. using a different symbol to rebind names in an outer scope
available to them, so
FORTRAN used ".EQ.", ".LT.", ".GT." etc. instead. We're
actually quite spoiled with our "==" operator!
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org
Nick Coghlan wrote:
On 29 April 2018 at 12:52, Greg Ewing <mailto:greg.ew...@canterbury.ac.nz>> wrote:
Alex Walters wrote:
PEP 3099 is the big list of things that will not happen in Python 3.
"There will be no alternative binding operators such as :=.&qu
oubt about when it's appropriate to use them.
The proposed :=, on the other hand, would overlap a lot with
the functionality of =. It's not a case of "Python already
has seven ways of assigning, so one more can't hurt."
--
Greg
_
t;maybe we should talk about that again".
--
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
keywords.
--
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
s. Storing
them in a database sounds like a really bad idea.
--
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
Eric V. Smith wrote:
I assume the intent is to not throw away any information in the lexer,
and give the parser full access to the original string. But that's just
a guess.
More likely it's because the lexer is fairly dumb and can
basically just recognise regular expressions
magically know about
anything that's not passed into it.
--
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
s? The best tools do just one thing and do
it well. These proposals seem to be trying to turn
comprehensions into swiss army knives.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
h
en__, etc. It also made it impossible to
distinguish reliably between a sequence and a mapping.
So it seems to me that PySequence_Check and related
functions are not very useful any more, since it's not
possible for them to really do what they claim to do.
--
Greg
_
over it, not
picking things out at arbitrary positions. And usually
its items are generated by an algorithm that works
sequentially, so random access would be difficult to
implement.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.pyt
Guido van Rossum wrote:
Greg seem to be +0 or better for (a)
Actually, I'm closer to -1 on (a) as well. I don't like := as a
way of getting assignment in an expression. The only thing I would
give a non-negative rating is some form of "where" or "given".
Brief su
27;s easy to reason
about.
"Comprehensions run in their own scope, like a def or
lambda" is a clear and simple mental model. It's easy to
explain and keep in your head.
The proposed semantics are much more complicated, and as
far as I can see, are only motivated by use cases that
you shouldn't
Ivan Pozdeev via Python-Dev wrote:
"as" was suggested even before is became a keyword in `with'. ( if
(re.match(regex,line) as m) is not None: )
That's not equivalent where/given, though, since it still
has the asymmetry problem.
--
Greg
__
y not do the same mangling for names
assigned within the comprehension.
A decision still needs to be made about whether we *want*
semantics that leak some things but not others.
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
101 - 200 of 2499 matches
Mail list logo
