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
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
@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
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
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
> 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
- 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 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
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 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 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 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 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 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 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
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 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
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 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 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
20 matches
Mail list logo
