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
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 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 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 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
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 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
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 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 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 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 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
> Sent: Wednesday, September 13, 2017 at 3:57 PM
> From: "Stefan Behnel"
> To: python-ideas@python.org
> 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.
> >
> 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
Python-ideas@python.org
https://mail.python.org/mailman
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
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
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
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 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
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 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 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
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
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 #
> 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
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
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
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'
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
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
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
> 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
32 matches
Mail list logo
