> The difference in allocated memory is over 22 MB.
> The import time with annotations is over 2s longer.
> The problem with those numbers that we still have 80% functions to cover.
This will not be a problem with PEP 560 (I could imagine that string objects
may take actually more memory than rela
On Wed, Sep 13, 2017 at 6:14 AM, Nick Coghlan wrote:
> On 13 September 2017 at 00:35, 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
Hi,
tl; dr How can we extend unittest module to plug new checks
before/after running tests?
The CPython project has a big test suite in the Lib/test/ directory.
While all tests are written with the unittest module and the
unittest.TestCase class, tests are not run directly by unittest, but
run b
Hi everybody
> I chose it because it's easy to write. Maybe math.pi is a better example :-)
>>
> math.pi.hex()
>> '0x1.921fb54442d18p+1'
>
> 3.141592653589793 is four fewer characters to type, just as accurate,
> and far more recognizable.
Of course, for a lost of numbers, the decimal repr
The format of map seems off. Coming from JS, all the functions come second. I
think this approach is superior.
Currently:
map(lambda x: chr(ord('a')+x), range(26)) # ['a', 'b', 'c', 'd', 'e', 'f', 'g',
'h', 'i', 'j', 'k', 'l', 'm', 'n', 'o', 'p', 'q', 'r', 's', 't', 'u', 'v', 'w',
'x', 'y', 'z'
We're not going to break every version of Python since 0.9 because
Javascript does something a certain way. Whatever might be better
abstractly, this is well established.
As to adding a `.map()` method to *every* iterable... just how would you
propose to do that given that it's really easy and co
While I agree that the method calling syntax is nicer, I disagree with flipping
the argument error for three main reasons.
First: it violates the signature entirely
The signature to map is map(function, *iterables). Python’s map is more like
Haskell’s zipWith. Making the function last would eith
> Sent: Wednesday, September 13, 2017 at 11:23 AM
> From: "Edward Minnix"
> To: "Jason H"
> Cc: Python-Ideas
> Subject: Re: [Python-ideas] Make map() better
>
> While I agree that the method calling syntax is nicer, I disagree with
> flipping the argument error for three main reasons.
>
> Fi
On Wed, Sep 13, 2017 at 10:54 AM, Jason H wrote:
>
> Thanks for the insights.
> I don't think it would be that breaking:
>
> def remap_map(a1, a2):
> if hasattr(a1, '__call__'):
> return map(a1, a2)
> elif hasattr(a2, '__call__'):
> return map(a2,a1)
> else:
> raise NotCallable #
12.09.17 19:17, Neil Schemenauer пише:
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
I am generally supportive of leaving the type annotations unprocessed
by default, but there are use cases where they should be processed
(and even cases where doing it at the right time matters, because of a
side effect).
I am concerned that the backwards compatibility story for non-typing
cases b
On Wed, Sep 13, 2017 at 11:56 AM, Jim J. Jewett
wrote:
> It should be possible to opt out for an entire module, and it should
> be possible to do so *without* first importing typing.
>
PEP 484 has a notation for this -- put
# type: ignore
at the top of your file and the file won't be type-ch
I know there's a lot of excitement around lots of new ideas. And the 3.7
feature freeze is looming (January is in a few months). But someone has to
review and accept all those PEPs, and I can't do it all by myself.
If you want your proposal to be taken seriously, you need to include a
summary of t
> On Sep 13, 2017, at 2:56 PM, Jim J. Jewett wrote:
>
> I am generally supportive of leaving the type annotations unprocessed
> by default, but there are use cases where they should be processed
> (and even cases where doing it at the right time matters, because of a
> side effect).
What is the
Jason H schrieb am 13.09.2017 um 17:54:
> I'm rather surprised that there isn't a Iterable class which dict and list
> derive from.
> If that were added to just dict and list, I think it would cover 98% of
> cases, and adding Iterable would be reasonable in the remaining scenarios.
Would you the
On Wed, Sep 13, 2017 at 3:12 PM, Lukasz Langa wrote:
> On Sep 13, 2017, at 2:56 PM, Jim J. Jewett wrote:
>> I am generally supportive of leaving the type annotations
>> unprocessed by default, but there are use cases where
>> they should be processed (and even cases where doing it
>> at the righ
On Wed, Sep 13, 2017 at 11:55 AM, Serhiy Storchaka
wrote:
> [...] Calling __getattr__() will slow down the access to builtins. And
> there is a recursion problem if module's __getattr__() uses builtins.
>
The first point is totally valid, but the recursion problem doesn't seem
like a strong arg
2017-09-13 13:01 GMT-07:00 Jim J. Jewett :
> On Wed, Sep 13, 2017 at 3:12 PM, Lukasz Langa wrote:
> > On Sep 13, 2017, at 2:56 PM, Jim J. Jewett wrote:
>
> >> I am generally supportive of leaving the type annotations
> >> unprocessed by default, but there are use cases where
> >> they should be
> But someone has to
> review and accept all those PEPs, and I can't do it all by myself.
An alternate definition for BDFL is "Benevolent Delegator For Life." :-)
Skip
___
Python-ideas mailing list
[email protected]
https://mail.python.org/mailman
> Sent: Wednesday, September 13, 2017 at 3:57 PM
> From: "Stefan Behnel"
> To: [email protected]
> Subject: Re: [Python-ideas] Make map() better
>
> Jason H schrieb am 13.09.2017 um 17:54:
> > I'm rather surprised that there isn't a Iterable class which dict and list
> > derive from.
> >
On 13 September 2017 at 14:33, Ethan Smith wrote:
> On Tue, Sep 12, 2017 at 8:30 PM, Nick Coghlan wrote:
>> There are a lot of packaging tools in use other than distutils, so I
>> don't think the distutils update proposal belongs in the PEP. Rather,
>> the PEP should focus on defining how type an
On 13 September 2017 at 20:45, Koos Zevenhoven wrote:
> On Wed, Sep 13, 2017 at 6:14 AM, Nick Coghlan wrote:
>>
>> On 13 September 2017 at 00:35, Koos Zevenhoven wrote:>
>>
>> > I don't see how the situation benefits from calling something the "main
>> > interpreter". Subinterpreters can be a wa
On 14 September 2017 at 06:01, Jim J. Jewett wrote:
> The "right time" is whenever they are currently evaluated.
> (Definition time, I think, but won't swear.)
>
> For example, the "annotation" might really be a call to a logger,
> showing the current environment, including names that will be rebo
On 13 September 2017 at 14:10, Nathaniel Smith wrote:
> Subinterpreters are basically an attempt to reimplement the OS's
> process isolation in user-space, right?
Not really, they're more an attempt to make something resembling
Rust's memory model available to Python programs - having the default
On 14 September 2017 at 08:46, Nick Coghlan wrote:
> On 13 September 2017 at 14:10, Nathaniel Smith wrote:
>> Subinterpreters are basically an attempt to reimplement the OS's
>> process isolation in user-space, right?
>
> Not really, they're more an attempt to make something resembling
> Rust's m
On Tue, Sep 12, 2017 at 9:30 PM, Guido van Rossum wrote:
> I find this a disturbing trend.
Which trend? Moving away from "consenting adults"? In the case of
sys.modules, the problem is that assigning a bogus value (e.g. []) can
cause the interpreter to crash. It wasn't a problem until recently
My preference is (1), revert. You have to understand how sys.modules works
before you can change it, and if you waste time debugging your mistake, so
be it. I think the sys.py proposal is the wrong way to fix the mistake you
made there.
On Wed, Sep 13, 2017 at 4:00 PM, Eric Snow
wrote:
> On Tue,
> On Sep 13, 2017, at 6:37 PM, Nick Coghlan wrote:
>
> I think it would be useful for the PEP to include a definition of an
> "eager annotations" decorator that did something like:
>
>def eager_annotations(f):
>ns = f.__globals__
>annotations = f.__annotations__
>for
On 14 September 2017 at 09:43, Lukasz Langa wrote:
>> On Sep 13, 2017, at 6:37 PM, Nick Coghlan wrote:
>> That way, during the "from __future__ import lazy_annotations" period,
>> folks will have clearer guidance on how to explicitly opt-in to eager
>> evaluation via function and class decorators
> On Sep 13, 2017, at 9:44 PM, Nick Coghlan wrote:
>
> On 14 September 2017 at 09:43, Lukasz Langa wrote:
>>> On Sep 13, 2017, at 6:37 PM, Nick Coghlan wrote:
>>> That way, during the "from __future__ import lazy_annotations" period,
>>> folks will have clearer guidance on how to explicitly op
On Wed, Sep 13, 2017 at 05:09:37PM +0200, Jason H wrote:
> The format of map seems off. Coming from JS, all the functions come
> second. I think this approach is superior.
Obviously Javascript has got it wrong. map() applies the function to
the given values, so the function comes first. That ma
On Wed, Sep 13, 2017 at 11:05:26PM +0200, Jason H wrote:
> > And look, map() even works with all of them, without inheritance,
> > registration, and whatnot. It's so easy!
>
> Define easy.
Opposite of hard or difficult.
You want to map a function?
map(function, values)
is all it takes. You
32 matches
Mail list logo
