Please respect Reply-To, set to python-ideas.
Greg Ewing writes:
> Chris Angelico wrote:
> > Forcing people to write 1.0 just to be compatible with 1.5 will cause
> > a lot of annoyance.
>
> Indeed, this would be unacceptable IMO.
But "forcing" won't happen. Just ignore the warning. *All*
Guido van Rossum writes:
> But that's not what type comments mean! They don't annotate the
> expression. They annotate the variable.
In PEP 484. But syntactically, AFAICS in an initialization that's a
distinction without a difference. It would be perfectly possible to
write a checker that all
What's up with the weird subthreads, Stephen?!
On Guido's suggestion, I'm working on posting those type-checking thoughts here.
-- Koos
On Sat, Sep 3, 2016 at 6:17 PM, Stephen J. Turnbull
wrote:
> Please respect Reply-To, set to python-ideas.
>
> Greg Ewing writes:
> > Chris Angelico wrote:
>
On Sat, Sep 3, 2016 at 8:28 AM, Stephen J. Turnbull
wrote:
> Guido van Rossum writes:
>
> > But that's not what type comments mean! They don't annotate the
> > expression. They annotate the variable.
>
> In PEP 484. But syntactically, AFAICS in an initialization that's a
> distinction without a
On Sat, Sep 3, 2016 at 6:44 PM, Koos Zevenhoven wrote:
> On Guido's suggestion, I'm working on posting those type-checking thoughts
> here.
>
Except that I just realized I can still make it to the store before it
closes, so a little later. But anyone can read my posts on python-dev
from yesterda
On Friday, while replying to a post on python-dev about PEP 526
(variable annotations), I ended up mentioning things that I think a
good type checker should do, which seem to differ from the general
understanding. The discussion should continue here, though, because
the aim of PEP 526 is not to def
Below I respond to Chris Angelico's post in the python-dev thread.
On Sat, Sep 3, 2016 at 2:01 AM, Chris Angelico wrote:
def eggs(cond:bool):
if cond:
x = 1
else:
x = 1.5
spam(x) # a good type checker infers that x is of type Union[
On Sun, Sep 4, 2016 at 7:44 AM, Koos Zevenhoven wrote:
>> I wonder if it would be different if you wrote that as a single expression:
>>
>> x = 1 if cond else 1.5
>>
>> x = sum([1] + [0.5] * cond)
>>
>> What should type inference decide x is in these cases? Assume an
>> arbitrarily smart type chec
Hi,
Below is a proposal to add support for asynchronous comprehensions and
asynchronous generator expressions in Python 3.6.
I have a half-working implementation of the proposal which fully
implements all required grammar and AST changes. What's left is to
update the compiler to emit correct op
On Sun, Sep 4, 2016 at 2:22 AM, Chris Angelico wrote:
> On Sun, Sep 4, 2016 at 7:44 AM, Koos Zevenhoven wrote:
>>> I wonder if it would be different if you wrote that as a single expression:
>>>
>>> x = 1 if cond else 1.5
>>>
>>> x = sum([1] + [0.5] * cond)
>>>
>>> What should type inference deci
Koos Zevenhoven writes:
> What's up with the weird subthreads, Stephen?!
Moving to Python-ideas? Doing what should have been done earlier, and
which Guido explicitly requested.
If you're referring to the cross-post to python-dev, I was hoping to
encourage motion of the thread by setting reply-
On Sun, Sep 4, 2016 at 9:31 AM, Yury Selivanov wrote:
> Below is a proposal to add support for asynchronous comprehensions and
> basynchronous generator expressions in Python 3.6.
Looks good to me! No content comments, and +1 on the proposal. One
copyedit suggestion:
> In principle, asynchronous
Hi Chris,
On 2016-09-03 5:34 PM, Chris Angelico wrote:
On Sun, Sep 4, 2016 at 9:31 AM, Yury Selivanov wrote:
Below is a proposal to add support for asynchronous comprehensions and
basynchronous generator expressions in Python 3.6.
Looks good to me! No content comments, and +1 on the proposal
Stephen J. Turnbull wrote:
But "forcing" won't happen. Just ignore the warning.
If I'm using a static type checker at all, I'm going
to be treating its warnings as errors and doing something
to make them go away. So effectively it would force me
to deal explicitly with every instance of int-fl
> In principle, asynchronous generator expressions are allowed in
> any context. However, in Python 3.6, due to ``async`` and ``await``
> soft-keyword status, asynchronous generator expressions are only
> allowed in an ``async def`` function. Once ``async`` and ``await``
> become reserved keyword
Hi Matthias,
On 2016-09-03 5:55 PM, Matthias welp wrote:
> In principle, asynchronous generator expressions are allowed in
> any context. However, in Python 3.6, due to ``async`` and ``await``
> soft-keyword status, asynchronous generator expressions are only
> allowed in an ``async def`` func
On Sun, Sep 04, 2016 at 12:26:58AM +0300, Koos Zevenhoven wrote:
> On Friday, while replying to a post on python-dev about PEP 526
> (variable annotations), I ended up mentioning things that I think a
> good type checker should do, which seem to differ from the general
> understanding. The discussi
17 matches
Mail list logo
