On Sep 4, 2019, at 20:51, Inada Naoki wrote:
>> And you’re right, because int|str _looks_ better than (int, str) here, many
>> people will be encouraged to use it even though it’s slower, which could
>> potentially be a bad thing for some programs.
>
> That's exactly my point. If we say "you
On Sep 4, 2019, at 21:53, Anders Hovmöller wrote:
>
>
>>> On 4 Sep 2019, at 22:58, Andrew Barnert wrote:
>>>
On Sep 4, 2019, at 10:17, Anders Hovmöller wrote:
.
>>>
>>> Doesn't all that imply that it'd be good if you could just pass it the
>>> queue object you want?
>>
>> P
On Thu, Sep 5, 2019 at 7:08 PM Andrew Barnert via Python-ideas
wrote:
>
> On Sep 4, 2019, at 20:51, Inada Naoki wrote:
>
> >> And you’re right, because int|str _looks_ better than (int, str) here,
> >> many people will be encouraged to use it even though it’s slower, which
> >> could potentiall
Hi list
I have a proposal for a minor (improvement?) to dict declarations.
I find a common requirement I have is to include one or more entries in a dict
only if some condition is met. Currently, the usual way of doing that is to add
one or more if statements.
Simple (but hopefully relatable-t
On 9/4/19 5:38 PM, Andrew Barnert via Python-ideas wrote:
> On Sep 4, 2019, at 08:54, Dan Sommers
<2qdxy4rzwzuui...@potatochowder.com> wrote:
>> How does blocking the submit call differ from setting max_workers in
>> the call to ThreadPoolExecutor?
> Here’s a concrete example from my own code
On Thu, Sep 05, 2019 at 07:15:27PM +1000, Chris Angelico wrote:
> Hang on hang on what's this situation where you're checking types
> of a zillion objects?
An earlier version of the statistics module used lots of isinstance
checks in order to support arbitrary numeric types, and was a lot
s
On Thu, 5 Sep 2019 at 11:19, wrote:
> I find a common requirement I have is to include one or more entries in a
> dict only if some condition is met. Currently, the usual way of doing that is
> to add one or more if statements.
>
> Simple (but hopefully relatable-to-real-world-code) example.
[..
On Thu, Sep 5, 2019 at 9:31 PM Steven D'Aprano wrote:
>
> On Thu, Sep 05, 2019 at 07:15:27PM +1000, Chris Angelico wrote:
>
> > Hang on hang on what's this situation where you're checking types
> > of a zillion objects?
>
> An earlier version of the statistics module used lots of isinstance
>
I was thinking more in this direction:
d = dict()
d[action in not None and 'action'] = action
d[minval > 0 and 'minval'] = minval
...
del d[False]
There are few things I do not particularly like about this (assigning to
dict, even when value is discarded later, or necessity of the del
d[False]),
I thought of something similar, but where the dict-literal construction is
desired:
>>> foo = True
>>> bar = False
>>> baz = False
>>> d = {
... 'foo' if foo else None: 1,
... 'bar' if bar else None: 2,
... 'baz' if baz else None: 3,
... }
>>> d
{'foo': 1, None: 3}
>>> d.pop(None)
3
>>> d
{
Okie, looks like my code got munched in the web view -- how do I make it
not do that?
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python
How is this different to the discussion
https://mail.python.org/archives/list/python-ideas@python.org/thread/MFSL3U6V74PZN4AT4JFQMQXSMGOJ6F27/#MFSL3U6V74PZN4AT4JFQMQXSMGOJ6F27
?
On Thu, Sep 5, 2019 at 9:24 AM wrote:
> Okie, looks like my code got munched in the web view -- how do I make
> i
On Sep 4, 2019, at 15:25, r...@hwyl.org wrote:
>
> ..."skip" being a unique object defined in and accessible from dict (there
> may be better places to make it available). The dict insertion code then
> simply ignores those entries when creating the dict.
I’m a bit confused about exactly when t
Also worth noting is that dict.skip would live in dict.__dict__... which is a
dict.
Brandt
> On Sep 5, 2019, at 08:51, Andrew Barnert via Python-ideas
> wrote:
>
>> On Sep 4, 2019, at 15:25, r...@hwyl.org wrote:
>>
>> ..."skip" being a unique object defined in and accessible from dict (there
A problem with `(int, str)` that I believe hasn't been brought up yet is that
it interferes with the existing use of subscription syntax, particularly by
`Tuple`.
`Tuple[int, str]` is equivalent to `Tuple[(int, str)]` but not to
`Tuple[Union[int, str]]`, because `__getitem__` receives a single
> On Sep 5, 2019, at 07:46, Sebastian Kreft wrote:
>
> How is this different to the discussion
> https://mail.python.org/archives/list/python-ideas@python.org/thread/MFSL3U6V74PZN4AT4JFQMQXSMGOJ6F27/#MFSL3U6V74PZN4AT4JFQMQXSMGOJ6F27
> ?
Well, that discussion started with an unworkable proposal
On Sep 5, 2019, at 02:15, Chris Angelico wrote:
>
> On Thu, Sep 5, 2019 at 7:08 PM Andrew Barnert via Python-ideas
> wrote:
>>
>> On Sep 4, 2019, at 20:51, Inada Naoki wrote:
>>
And you’re right, because int|str _looks_ better than (int, str) here,
many people will be encouraged to
> On 5 Sep 2019, at 12:06, Dan Sommers <2qdxy4rzwzuui...@potatochowder.com>
> wrote:
>
> Yes, you need some way to produce "back pressure" from downstream to
> upstream, and to stop making new work (with new memory consumption)
> until there's a place to put it.
It seems that this is the impor
On Fri, Sep 6, 2019 at 4:12 AM Andrew Barnert wrote:
>
> On Sep 5, 2019, at 02:15, Chris Angelico wrote:
> >
> > On Thu, Sep 5, 2019 at 7:08 PM Andrew Barnert via Python-ideas
> > wrote:
> >>
> >> Which means if they run into a situation where they’re checking types of a
> >> zillion objects, t
On Sep 5, 2019, at 04:24, Steven D'Aprano wrote:
>
> But having said all that, I'm not sure that we should be rejecting this
> proposal on the basis of performance when we haven't got any working
> code to measure performance of :)
Good point. But then if we never get any realistic use cases,
On Sep 5, 2019, at 11:13, Barry Scott wrote:
>
>
>
>> On 5 Sep 2019, at 12:06, Dan Sommers <2qdxy4rzwzuui...@potatochowder.com>
>> wrote:
>>
>> Yes, you need some way to produce "back pressure" from downstream to
>> upstream, and to stop making new work (with new memory consumption)
>> until
One thing I think is worth raising here: If my experience with
concurrent.futures is far from universal, my expectations for this change may
not be helpful, so let me lay that all out explicitly.
In my experience, concurrent.futures has two very good, but very different,
uses.
First, there’s t
On Thu, Sep 05, 2019 at 12:12:05PM -0700, Andrew Barnert wrote:
> On Sep 5, 2019, at 04:24, Steven D'Aprano wrote:
> >
> > But having said all that, I'm not sure that we should be rejecting this
> > proposal on the basis of performance when we haven't got any working
> > code to measure perform
On Tue, Sep 03, 2019 at 12:19:15PM -0700, Andrew Barnert via Python-ideas wrote:
> On Sep 2, 2019, at 23:50, Philippe Prados wrote:
> >
> > Add a new operator for `Union[type1|type2]` ?
>
> Hold on. Are you proposing `Union[t1 | t2]` as a new spelling for
> `Union[t1, t2]`? That seems pointless
Two more bits of bikeshedding…
On Sep 5, 2019, at 12:12, Andrew Barnert via Python-ideas
wrote:
>
>> On Sep 5, 2019, at 04:24, Steven D'Aprano wrote:
>>
>> If Union is a built-in, we could have something like this:
>>
>> def isinstance(obj, class_or_tuple):
>> if type(class_or_tuple)
Also, if one have in mind that dict addition with the `+` operator had been
recelently approved, as of Python 3.9 it will be ok to write:
```
return ({
'user_id': user_id,} +
({'max_results': max_results} if max_results else {}) +
({'active': active} if active is not None
On Thu, Sep 5, 2019 at 8:37 PM Joao S. O. Bueno
wrote:
> Also, if one have in mind that dict addition with the `+` operator had been
> recelently approved
>
Where did you hear this? I am not aware that this was even made into a PEP
let alone that such a PEP was approved.
--
--Guido van Rossum
27 matches
Mail list logo
