Lukasz Langa schrieb am 11.09.2017 um 21:25:
> I remember mostly Stefan Behnel's concerns about Cython's annotations,
I'm currently reimplementing the annotation typing in Cython to be
compatible with PEP-484, so that concern is pretty much out of the way.
This PEP still has an impact on Cython,
On Tue, Sep 12, 2017 at 12:45:37AM +0200, Victor Stinner wrote:
> Instead of modifying the Python grammar, the alternative is to enhance
> float(str) to support it:
>
> k = float("0x1.2492492492492p-3") # 1/7
Why wouldn't you just write 1/7?
--
Steve
__
On Mon, Sep 11, 2017 at 11:58:45AM -0400, Lukasz Langa wrote:
> PEP: 563
> Title: Postponed Evaluation of Annotations
A few comments, following the quoted passages as needed.
> Rationale and Goals
> ===
>
> PEP 3107 added support for arbitrary annotations on parts of a function
On Mon, Sep 11, 2017 at 1:21 PM, Yury Selivanov
wrote:
> On Mon, Sep 11, 2017 at 3:25 PM, Lukasz Langa wrote:
> [..]
> > This PEP is proposing delaying evaluation until annotations are accessed
> but
> > gives user code the power to decide whether the string form is enough, or
> > maybe an AST w
On 2017-09-12, Victor Stinner wrote:
> Instead of modifying the Python grammar, the alternative is to enhance
> float(str) to support it:
>
> k = float("0x1.2492492492492p-3") # 1/7
Making it a different function from float() would avoid backwards
compatibility issues. I.e. float() no longer retu
Instead of modifying the Python grammar, the alternative is to enhance
float(str) to support it:
k = float("0x1.2492492492492p-3") # 1/7
Victor
2017-09-08 8:57 GMT+02:00 Serhiy Storchaka :
> The support of hexadecimal floating literals (like 0xC.68p+2) is included in
> just released C++17 standa
On 2017-09-11, Neil Schemenauer wrote:
> A module can be a singleton instance of a singleton ModuleType
> instance.
Maybe more accurate to say each module would have its own unique
__class__ associated with it. So, you can add properties to the
class without affecting other modules. For backward
On Mon, Sep 11, 2017 at 3:25 PM, Lukasz Langa wrote:
[..]
> This PEP is proposing delaying evaluation until annotations are accessed but
> gives user code the power to decide whether the string form is enough, or
> maybe an AST would be enough, or actual evaluation with get_type_hints() or
> eval(
On 2017-09-11, C Anthony Risinger wrote:
> I'm getting at, is can we find a way to make modules a real type? So dunder
> methods are activated? This would make modules phenomenally powerful
> instead of just a namespace (or resorting to after the fact __class__
> reassignment hacks).
My __namespac
> On Sep 11, 2017, at 3:23 PM, Stefan Behnel wrote:
>
> Ryan Gonzalez schrieb am 11.09.2017 um 19:16:
>> One thing I want to point out: there are a lot of really useful Python
>> libraries that have come to rely on annotations being objects, ranging
>> from plac to fbuild to many others. I could
On Mon, Sep 11, 2017 at 10:16 AM, Ryan Gonzalez wrote:
> One thing I want to point out: there are a lot of really useful Python
> libraries that have come to rely on annotations being objects, ranging
> from plac to fbuild to many others. I could understand something that
> delays the evaluation
> On Sep 11, 2017, at 1:16 PM, Ryan Gonzalez wrote:
>
> One thing I want to point out: there are a lot of really useful Python
> libraries that have come to rely on annotations being objects, ranging
> from plac to fbuild to many others.
Shout out to fbuild which is a project that was built on
Ryan Gonzalez schrieb am 11.09.2017 um 19:16:
> One thing I want to point out: there are a lot of really useful Python
> libraries that have come to rely on annotations being objects, ranging
> from plac to fbuild to many others. I could understand something that
> delays the evaluation of annotati
On Mon, Sep 11, 2017 at 10:07 PM Lukasz Langa wrote:
> This is off topic for discussion of this PEP.
>
> It would require another one (essentially an extension of PEP 484) to get
> passed for your idea to be standardized.
>
I'm not sure whether this is directed to me; so just to make it clear, I
On Mon, Sep 11, 2017 at 1:09 PM, Neil Schemenauer <
nas-python-id...@arctrix.com> wrote:
> On 2017-09-11, C Anthony Risinger wrote:
> > I'm not sure I follow the `exec(code, module)` part from the other
> thread.
> > `exec` needs a dict to exec code into [..]
> [..]
> > How do you handle lazy load
This is off topic for discussion of this PEP.
It would require another one (essentially an extension of PEP 484) to get
passed for your idea to be standardized. For now, I don't want to distract
reviewers from conflating PEP 563 with all the possible wonderful or horrible
ways people can potent
On Mon, Sep 11, 2017 at 8:58 PM Steven D'Aprano wrote:
> On Mon, Sep 11, 2017 at 04:06:14PM +, אלעזר wrote:
> > I like it. For previous discussion of this idea see here:
> >
> https://mail.python.org/pipermail/python-ideas/2016-September/042527.html
> >
> > I don't see this mentioned in the P
On 2017-09-11, C Anthony Risinger wrote:
> I'm not sure I follow the `exec(code, module)` part from the other thread.
> `exec` needs a dict to exec code into [..]
[..]
> How do you handle lazy loading when a defined function requests a global
> via LOAD_NAME? Are you suggesting to change function._
On Mon, Sep 11, 2017 at 04:06:14PM +, אלעזר wrote:
> I like it. For previous discussion of this idea see here:
> https://mail.python.org/pipermail/python-ideas/2016-September/042527.html
>
> I don't see this mentioned in the PEP, but it will also allow (easy)
> description of contracts and dep
Hello,
You're correct. The idea is to give nonlocal the same ability, redirect
subsequent bindings if the variable doesn't exist.
No, what I said is that it would only create the var if it didn't exist.
That means that the current behaviour of nonlocal to check all previous
envs (except globa
On Fri, Sep 8, 2017 at 11:36 AM, Neil Schemenauer <
nas-python-id...@arctrix.com> wrote:
> On 2017-09-09, Chris Angelico wrote:
> > Laziness has to be complete - or, looking the other way, eager
> > importing is infectious. For foo to be lazy, bar also has to be lazy;
>
> Not with the approach I'm
One thing I want to point out: there are a lot of really useful Python
libraries that have come to rely on annotations being objects, ranging
from plac to fbuild to many others. I could understand something that
delays the evaluation of annotations until they are accessed, but this
seems really ext
I like it. For previous discussion of this idea see here:
https://mail.python.org/pipermail/python-ideas/2016-September/042527.html
I don't see this mentioned in the PEP, but it will also allow (easy)
description of contracts and dependent types.
Elazar
On Mon, Sep 11, 2017 at 6:59 PM Lukasz Lan
PEP: 563
Title: Postponed Evaluation of Annotations
Version: $Revision$
Last-Modified: $Date$
Author: Łukasz Langa
Discussions-To: Python-Dev
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 8-Sep-2017
Python-Version: 3.7
Post-History:
Resolution:
Abstract
PEP 310
On 9/11/2017 10:03 AM, João Matos wrote:
Hello,
I would like to suggest that nonlocal should be given the same creating
power as global.
If I do global a_var it creates the global a_var if it doesn't exist.
The global declaration does not create anything, but it redirects
subsequent binding
There's no need for shame! I regularly find out that there are Python
features I didn't know about. It's called perpetual learning. :-)
On Sun, Sep 10, 2017 at 9:02 PM, INADA Naoki wrote:
> Oh, I'm shame myself.
>
> Only when `from email import *` is used, __all__ submodules are imported.
> INAD
> Sent: Monday, September 11, 2017 at 10:03 AM
> From: "João Matos"
> To: python-ideas@python.org
> Subject: [Python-ideas] Give nonlocal the same creating power as global
>
> Hello,
>
> I would like to suggest that nonlocal should be given the same creating
> power as global.
> If I do
> glob
Hello,
I would like to suggest that nonlocal should be given the same creating
power as global.
If I do
global a_var
it creates the global a_var if it doesn't exist.
I think it would be great that nonlocal maintained that power.
This way when I do
nonlocal a_var
it would create a_var in
Hello,
I would like to suggest that nonlocal should be given the same creating
power as global.
If I do
global a_var
it creates the global a_var if it doesn't exist.
I think it would be great that nonlocal maintained that power.
This way when I do
nonlocal a_var
it would create a_var in the i
Am 08.09.2017 um 14:47 schrieb Thomas Güttler:
I curious if there are any plans to update the "Zen of Python".
What could be added to the "Zen of Python"?
What do you think?
I like this one:
"Bad programmers worry about the code. Good programmers worry about data structures and their relati
On Mon, Sep 11, 2017 at 8:32 AM, Nick Coghlan wrote:
> On 11 September 2017 at 00:52, Koos Zevenhoven wrote:
> > On Thu, Sep 7, 2017 at 9:26 PM, Eric Snow
> > wrote:
> > [...]
> >
> >>
> >> get_main():
> >>
> >>Return the main interpreter.
> >>
> >
> > I assume the concept of a main interpr
31 matches
Mail list logo
