On Tue, Sep 12, 2017 at 2:43 PM, Eric Snow
wrote:
> Yeah, in the first version of the PEP it was called "enumerate()". I
> changed it to "list()" at Raymond's recommendation. The reasoning is
> that it's less confusing to most people that way. TBH, I'd rather
> leave it "list()", but could be
On Tue, Sep 12, 2017 at 7:09 PM, Nick Coghlan wrote:
> So in this case, the vagueness of "data class" is considered a feature
> - since it doesn't inherently mean *anything*, folks are more likely
> to realise that they need to look up "Python data class", and if I
> search for that in a private
On 13 September 2017 at 07:43, Eric Snow wrote:
> On Sat, Sep 9, 2017 at 5:05 AM, Antoine Pitrou wrote:
>> On Fri, 8 Sep 2017 16:04:27 -0700, Eric Snow
>> wrote:
>>> ``list()``::
>>
>> It's called ``enumerate()`` in the threading module. Not sure there's
>> a point in choosing a different name
On 13 September 2017 at 02:01, Chris Barker - NOAA Federal
wrote:
> This really does match well with the record concept in databases, and most
> people are familiar with that.
No, most people aren't familiar with that - they only become familiar
with it *after* they've learned to program and lear
There are times when you deal with completely independent input/output
'pipes' - where parallelizing would really help speed things up.
Can't there be a way to capture that idiom and multi thread it in the
language itself?
Example:
loop:
read an XML
produce a JSON like
Regards,
On Sat, Sep 9, 2017 at 11:04 AM, Nathaniel Smith wrote:
> This phrase "bubble up" here is doing a lot of work :-). Can you elaborate
> on what you mean? The text now makes it seem like the exception will just
> pass from one interpreter into another, but that seems impossible
I've updated the PEP
On Sat, Sep 9, 2017 at 5:05 AM, Antoine Pitrou wrote:
> On Fri, 8 Sep 2017 16:04:27 -0700, Eric Snow
> wrote:
>> ``list()``::
>
> It's called ``enumerate()`` in the threading module. Not sure there's
> a point in choosing a different name here.
Yeah, in the first version of the PEP it was call
On Sat, Sep 9, 2017 at 4:45 AM, Antoine Pitrou wrote:
> How does the other interpreter get the FIFO "tied" to it?
> Is it `get_current().get_fifo(name)`? Something else?
Yep, that's it. I've added some examples to the PEP to illustrate.
That said, I'm re-working the method names since they conf
On Fri, Sep 8, 2017 at 8:54 PM, Michel Desmoulin
wrote:
> Le 09/09/2017 à 01:28, Stefan Krah a écrit :
>> Still, the argument "who uses subinterpreters?" of course still remains.
>
> For now, nobody. But if we expose it and web frameworks manage to create
> workers as fast as multiprocessing and a
On Sat, Sep 9, 2017 at 1:04 AM, Paul Moore wrote:
> On 9 September 2017 at 00:04, Eric Snow wrote:
>>add_recv_fifo(name=None):
>>add_send_fifo(name=None):
>
> Personally, I *always* read these names backwards - from the POV of
> the caller. So when I see "add_send_fifo", I then expect to
On Fri, Sep 8, 2017 at 4:28 PM, Stefan Krah wrote:
> The most promising model to me is to put *all* globals in a tls structure
> and cache the whole structure. Extrapolating from my experiences with the
> context, this might have a slowdown of "only" 4%.
Yeah, this is actually something I've bee
On Sep 12, 2017, at 12:18, Larry Hastings wrote:
> On 09/12/2017 02:49 AM, Victor Stinner wrote:
>> Note: The PEP is not yet rejected on python.org, it will be done at
>> the next cron job run.
> My understanding is that the docs are built once a day via cron job, but the
> PEPs are built every t
On 09/12/2017 02:49 AM, Victor Stinner wrote:
Note: The PEP is not yet rejected on python.org, it will be done at
the next cron job run.
My understanding is that the docs are built once a day via cron job, but
the PEPs are built every time the repo changes thanks to Travis CI. So
it should
- record
+1
This really does match well with the record concept in databases, and most
people are familiar with that. Though it will. E a touch confusing until
(if ever) most of the database and cab traders, etc start using them.
It also matches pretty well with numpy "record arrays":
https://
> On Sep 12, 2017, at 9:01 AM, Chris Barker - NOAA Federal
> wrote:
> This really does match well with the record concept in databases, and most
> people are familiar with that. Though it will. E a touch confusing until (if
> ever) most of the database and cab traders, etc start using them.
I
On 12 September 2017 at 11:15, Nathaniel Smith wrote:
> On Mon, Sep 11, 2017 at 5:27 PM, Barry Warsaw wrote:
>> On Sep 10, 2017, at 13:46, Nathaniel Smith wrote:
>>>
>>> On Sun, Sep 10, 2017 at 12:06 PM, Barry Warsaw wrote:
For PEP 553, I think it’s a good idea to support the environment v
Hi,
In March 2015, I proposed the PEP 490 to chain implicitly C exceptions
by default:
https://www.python.org/dev/peps/pep-0490/
The discussion on python-dev was quickly in favor of keeping the
status quo: don't chain C exceptions by default, but only do that
explicitly where it makes sense.
I
@Larry
> "@property" 375 hits
> "def __getattr__" 28 hits
I don't think it is fair to compare occurrences of __getattr__ vs
occurrences of @property,
since in the first case one would use a single __getattr__ per class, while
in the second case
@property is required for every attribute.
@G
On 09/11/2017 07:22 PM, Guido van Rossum wrote:
I still don't follow. How does one use InstanceDescriptor?
If you write a class that inherits from InstanceDescriptor and supports
the descriptor protocol, module objects will call the descriptor
protocol functions when that object is accessed
Hello! And welcome aboard this mailing list ship. :)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
20 matches
Mail list logo
