Re: [Python-ideas] Hexadecimal floating literals

2017-09-12 1:27 GMT+02:00 Neil Schemenauer : >> k = float("0x1.2492492492492p-3") # 1/7 > > Making it a different function from float() would avoid backwards > compatibility issues. I.e. float() no longer returns errors on some > inputs. In that case, I suggest float.fromhex() to

Re: [Python-ideas] PEP 562

@Anthony > module.__getattr__ works pretty well for normal access, after being > imported by another module, but it doesn't properly trigger loading by > functions defined in the module's own namespace. The idea of my PEP is to be very simple (both semantically and in terms of implementation).

Re: [Python-ideas] Hexadecimal floating literals

2017-09-12 3:48 GMT+02:00 Steven D'Aprano : >> k = float("0x1.2492492492492p-3") # 1/7 > > Why wouldn't you just write 1/7? 1/7 is irrational, so it's not easy to get the "exact value" for a 64-bit IEEE 754 double float. I chose it because it's easy to write. Maybe math.pi

Re: [Python-ideas] PEP 563: Postponed Evaluation of Annotations, first draft

In principle, I like this idea, this will save some keystrokes and will make annotated code more "beautiful". But I am quite worried about the backwards compatibility. One possible idea would be to use __future__ import without a definite deprecation plan. If people will be fine with using

Re: [Python-ideas] PEP 563: Postponed Evaluation of Annotations, first draft

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,

[Python-ideas] PEP 561 v2 - Packaging Static Type Information

Hello, V2 of my PEP on packaging type information is available at https://www.python.org/dev/peps/pep-0561/. It is also replicated below. I look forward to any suggestions or comments that people may have! Thanks Ethan ---

Re: [Python-ideas] PEP 561 v2 - Packaging Static Type Information

On 13 September 2017 at 09:43, Ethan Smith wrote: > The two major parts of this specification are the packaging specifications > and the resolution order for resolving module type information. This spec > is meant to replace the ``shared/typehints/pythonX.Y/`` spec of PEP 484 >

Re: [Python-ideas] LOAD_NAME/LOAD_GLOBAL should be use getattr()

I'm worring about performance much. Dict has ma_version from Python 3.6 to be used for future optimization including global caching. Adding more abstraction layer may make it difficult. When considering lazy loading, big problem is backward compatibility. For example, see

Re: [Python-ideas] PEP 554: Stdlib Module to Support Multiple Interpreters in Python Code

On Tue, Sep 12, 2017 at 1:46 PM, Eric Snow wrote: > On Thu, Sep 7, 2017 at 11:19 PM, Nathaniel Smith wrote: >> On Thu, Sep 7, 2017 at 8:11 PM, Eric Snow >> wrote: >>> My concern is that this is a chicken-and-egg problem.

Re: [Python-ideas] PEP 554: Stdlib Module to Support Multiple Interpreters in Python Code

On 13 September 2017 at 00:35, Koos Zevenhoven wrote: > On Tue, Sep 12, 2017 at 1:40 PM, Nick Coghlan wrote: >> >> On 11 September 2017 at 18:02, Koos Zevenhoven wrote: >> > On Mon, Sep 11, 2017 at 8:32 AM, Nick Coghlan

Re: [Python-ideas] LOAD_NAME/LOAD_GLOBAL should be use getattr()

On 2017-09-12, Eric Snow wrote: > Yeah, good luck! :). If I weren't otherwise occupied with my own crazy > endeavor I'd lend a hand. No problem. It makes sense to have a proof of concept before spending time on a PEP. If the idea breaks too much old code it is not going to happen. So, I will

Re: [Python-ideas] PEP 561 v2 - Packaging Static Type Information

On Tue, Sep 12, 2017 at 8:30 PM, Nick Coghlan wrote: > On 13 September 2017 at 09:43, Ethan Smith wrote: > > The two major parts of this specification are the packaging > specifications > > and the resolution order for resolving module type information.

Re: [Python-ideas] sys.py

I find this a disturbing trend. I think we have bigger fish to fry and this sounds like it could slow down startup. On Tue, Sep 12, 2017 at 8:35 PM, Nick Coghlan wrote: > On 13 September 2017 at 09:46, Eric Snow > wrote: > > The sys module is a

Re: [Python-ideas] PEP 563: Postponed Evaluation of Annotations, first draft

Thanks for your detailed review! > On Sep 11, 2017, at 9:45 PM, Steven D'Aprano wrote: > > Regarding forward references: I see no problem with quoting forward > references. Some people complain about the quotation marks, but frankly > I don't think that's a major

Re: [Python-ideas] lazy import via __future__ or compiler analysis

On Sep 11, 2017 2:32 PM, "Neil Schemenauer" wrote: 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.

Re: [Python-ideas] LOAD_NAME/LOAD_GLOBAL should be use getattr()

On Sep 12, 2017 10:17 AM, "Neil Schemenauer" wrote: Introducing another special feature of modules to make this work is not the solution, IMHO. We should make module namespaces be more like instance namespaces. We already have a mechanism and it is getattr on

Re: [Python-ideas] PEP 562

On Tue, Sep 12, 2017 at 10:32 PM Nathaniel Smith wrote: > If you're ok with replacing the object in sys.modules then the ability to > totally customize your module's type has existed since the dawn era. > I'm down with that. Just make it easier, mucking with sys.modules ain't a

Re: [Python-ideas] sys.py

On 13 September 2017 at 09:46, Eric Snow wrote: > The sys module is a rather special case as far as modules go. It is > effectively a "console" into the interpreter's internal state and that > includes some mutable state. Since it is a module, we don't have much >

Re: [Python-ideas] LOAD_NAME/LOAD_GLOBAL should be use getattr()

On 13 September 2017 at 02:17, Neil Schemenauer wrote: > Introducing another special feature of modules to make this work is > not the solution, IMHO. We should make module namespaces be more > like instance namespaces. We already have a mechanism and it is >

[Python-ideas] sys.py

The sys module is a rather special case as far as modules go. It is effectively a "console" into the interpreter's internal state and that includes some mutable state. Since it is a module, we don't have much of an opportunity to: * validate values assigned to its attributes [1] * issue

Re: [Python-ideas] PEP 562

Wouldn't a better approach be a way to customize the type of the module? That would allow people to define behavior for almost anything (__call__, __getattr__, __setattr__, __dir__, various operators etc). This question shouldn't exist "why can't I customize behavior X in a module when I can do it

Re: [Python-ideas] PEP 562

If I recall there was a proposal a few months for a "lazy" keyword that would render anything lazy, including imports. Instead of just adding laziness on generators, the on imports, then who knows where, maybe it's time to consider laziness is a hell of a good general concept and try to

Re: [Python-ideas] PEP 563: Postponed Evaluation of Annotations, first draft

On 12 September 2017 at 11:45, Steven D'Aprano wrote: >> Rejected Ideas >> == >> >> Keep the ability to use local state when defining annotations >> - >> >> With postponed evaluation, this is impossible

Re: [Python-ideas] PEP 563: Postponed Evaluation of Annotations, first draft

On Tue, Sep 12, 2017 at 09:17:23PM +1000, Nick Coghlan wrote: > Unfortunately, this idea has the downside that for trivial > annotations, defining a lambda expression is likely to be *slower* > than evaluating the expression, whereas referencing a string constant > is faster: Is it time to

Re: [Python-ideas] Give nonlocal the same creating power as global

On Tue, Sep 12, 2017 at 8:54 PM, Nick Coghlan wrote: > On 12 September 2017 at 03:32, João Matos wrote: >> Hello, >> >> You're correct. The idea is to give nonlocal the same ability, redirect >> subsequent bindings if the variable doesn't exist. > > The

Re: [Python-ideas] Hexadecimal floating literals

On Tue, Sep 12, 2017 at 09:23:04AM +0200, Victor Stinner wrote: > 2017-09-12 3:48 GMT+02:00 Steven D'Aprano : > >> k = float("0x1.2492492492492p-3") # 1/7 > > > > Why wouldn't you just write 1/7? > > 1/7 is irrational, so it's not easy to get the "exact value" for a > 64-bit

Re: [Python-ideas] Give nonlocal the same creating power as global

On 12 September 2017 at 03:32, João Matos wrote: > Hello, > > You're correct. The idea is to give nonlocal the same ability, redirect > subsequent bindings if the variable doesn't exist. The issue you're facing is that optimised local variables still need to be defined in the

Re: [Python-ideas] Hexadecimal floating literals

On Mon, Sep 11, 2017 at 06:26:16PM -0600, Neil Schemenauer wrote: > 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

Re: [Python-ideas] PEP 554: Stdlib Module to Support Multiple Interpreters in Python Code

On 11 September 2017 at 18:02, Koos Zevenhoven wrote: > On Mon, Sep 11, 2017 at 8:32 AM, Nick Coghlan wrote: >> The line between it and the "CPython Runtime" is fuzzy for both >> practical and historical reasons, but the regular Python CLI will >> always

Re: [Python-ideas] Hexadecimal floating literals

On Tue, Sep 12, 2017 at 9:20 PM, Steven D'Aprano wrote: > On Mon, Sep 11, 2017 at 06:26:16PM -0600, Neil Schemenauer wrote: >> On 2017-09-12, Victor Stinner wrote: >> > Instead of modifying the Python grammar, the alternative is to enhance >> > float(str) to support it: >> >

Re: [Python-ideas] PEP 554: Stdlib Module to Support Multiple Interpreters in Python Code

On Thu, Sep 7, 2017 at 11:19 PM, Nathaniel Smith wrote: > On Thu, Sep 7, 2017 at 8:11 PM, Eric Snow wrote: >> My concern is that this is a chicken-and-egg problem. The situation >> won't improve until subinterpreters are more readily available. > >

Re: [Python-ideas] PEP 554: Stdlib Module to Support Multiple Interpreters in Python Code

Yep. See http://bugs.python.org/issue10915 and http://bugs.python.org/issue15751. The issue of C-extension support for subinterpreters is, of course, a critical one here. At the very least, incompatible modules should be able to opt out of subinterpreter support. I've updated the PEP to

Re: [Python-ideas] PEP 554: Stdlib Module to Support Multiple Interpreters in Python Code

On Sun, Sep 10, 2017 at 7:52 AM, Koos Zevenhoven wrote: > I assume the concept of a main interpreter is inherited from the previous > levels of support in the C API, but what exactly is the significance of > being "the main interpreter"? Instead, could they just all be >

Re: [Python-ideas] PEP 554: Stdlib Module to Support Multiple Interpreters in Python Code

On Sun, Sep 10, 2017 at 12:14 PM, Antoine Pitrou wrote: > What could improve performance significantly would be to share objects > without any form of marshalling; but it's not obvious it's possible in > the subinterpreters model *if* it also tries to remove the GIL. Yep.

Re: [Python-ideas] PEP 563: Postponed Evaluation of Annotations, first draft

> On Sep 11, 2017, at 4:21 PM, Yury Selivanov wrote: > > I'm one of those who used annotations for other purposes than type > hints. And even if annotations became strings in Python 3.7 *without > future import*, fixing my libraries would be easy -- just add an >

Re: [Python-ideas] PEP 563: Postponed Evaluation of Annotations, first draft

> On Sep 12, 2017, at 5:38 AM, Ivan Levkivskyi wrote: > > In principle, I like this idea, this will save some keystrokes > and will make annotated code more "beautiful". But I am quite worried about > the backwards > compatibility. One possible idea would be to use

Re: [Python-ideas] PEP 562

On Sep 12, 2017 7:08 AM, "Ionel Cristian Mărieș via Python-ideas" < python-ideas@python.org> wrote: Wouldn't a better approach be a way to customize the type of the module? That would allow people to define behavior for almost anything (__call__, __getattr__, __setattr__, __dir__, various

Re: [Python-ideas] PEP 554: Stdlib Module to Support Multiple Interpreters in Python Code

On Tue, Sep 12, 2017 at 6:30 PM, Koos Zevenhoven wrote: > On Tue, Sep 12, 2017 at 5:53 PM, Stefan Krah wrote: > >> On Tue, Sep 12, 2017 at 05:35:34PM +0300, Koos Zevenhoven wrote: >> > I don't see how the situation benefits from calling something the

[Python-ideas] LOAD_NAME/LOAD_GLOBAL should be use getattr()

This is my idea of making module properties work. It is necessary for various lazy-loading module ideas and it cleans up the language IMHO. I think it may be possible to do it with minimal backwards compatibility problems and performance regression. To me, the main issue with module properties