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 imposition.
Are you a user of
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. This spec
> > is meant to replace the ``sh
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 rather special case as far as modules go. It is
>
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. The situation
>>> won't improve until subinterpreters are more readily av
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
> getattr on objects.
One thing to ke
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
> of an opportunity to:
>
> * val
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
> [2]_.
There are a
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
https://github.com/pyth
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 wo
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
>> > wrote:
>> >> The line between it and the "CPython Runtime" is fuzzy fo
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 objects.
+1
- importlib needs to
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. So, you can add properties to the
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 Deprecat
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
walk in a park, an
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
---
P
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. This is one of the main
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
> subinterpreters of the sam
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 discuss
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.
>
> Okay, but you're assuming that "more libraries
> 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 __future__ import without a
> 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
> eval().
>
> That said, the PEP
On 2017-09-12, 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. And if
> you're not ok with that, then it's still existed since 3.5 via the
> mechanism of assigning to __class__
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 operator
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 (
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 "main
>> > interpreter". Subinterpreters can
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 "main
> > interpreter". Subinterpreters can be a way to take something
> > non-thread-safe and make it threa
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 generaliz
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 "main
> interpreter". Subinterpreters can be a way to take something
> non-thread-safe and make it thread-safe, because in an
> interpreter-per-thread scheme, most of
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
> wrote:
> >> The line between it and the "CPython Runtime" is fuzzy for both
> >> practical and historical reasons, but the regular Pyt
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
On Tue, Sep 12, 2017 at 2:30 PM, Chris Angelico wrote:
>
> Your specific example doesn't work as int() won't accept that by
> default - you have to explicitly say "base=0" to make that acceptable.
> But we have other examples where what used to be an error is now
> acceptable:
I'm surprised t
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 consid
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:
>> >
>> > k = float("0x1.24
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 IEEE 754 double float.
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 from
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 for function locals.
>
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 issue you're facing is that optimised local
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 compilation unit whe
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 have a "first created, last destroyed" mai
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 typing.g
@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). Thi
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 remain consistent
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 is a better example :-)
43 matches
Mail list logo
