On 22Apr2019 2119, Glenn Linderman wrote:
While Inada's suggested DictBuilder interface was immediately obvious, I
don't get how either copy or update would achieve the goal. Perhaps you
could explain? Particularly, what would be the trigger that would make
dict() choose to create a shared key
On 22Apr2019 2143, Inada Naoki wrote:
On Tue, Apr 23, 2019 at 11:30 AM Steve Dower wrote:
Or possibly just "dict(existing_dict).update(new_items)".
Do you mean .update accepts values tuple?
I can't think it's
Not sure what you were going to go on to say here, but why not?
If it's a key-s
On Tue, Apr 23, 2019 at 11:30 AM Steve Dower wrote:
>
> Or possibly just "dict(existing_dict).update(new_items)".
>
Do you mean .update accepts values tuple?
I can't think it's
> My primary concern is still to avoid making CPython performance
> characteristics part of the Python language definit
On 4/22/2019 7:27 PM, Steve Dower wrote:
On 22Apr2019 1921, Steve Dower wrote:
On 22Apr2019 1822, Glenn Linderman wrote:
Inada is now proposing a way to allow the coder to suggest a group
of dictionaries that might benefit from the same gains, by
preclassifying non-__dict__ slot dictionaries t
On 4/22/2019 7:27 PM, Steve Dower wrote:
On 22Apr2019 1921, Steve Dower wrote:
On 22Apr2019 1822, Glenn Linderman wrote:
Inada is now proposing a way to allow the coder to suggest a group
of dictionaries that might benefit from the same gains, by
preclassifying non-__dict__ slot dictionaries t
On 22Apr2019 1921, Steve Dower wrote:
On 22Apr2019 1822, Glenn Linderman wrote:
Inada is now proposing a way to allow the coder to suggest a group of
dictionaries that might benefit from the same gains, by preclassifying
non-__dict__ slot dictionaries to do similar sharing.
CSV reader is an e
On 22Apr2019 1822, Glenn Linderman wrote:
Inada is now proposing a way to allow the coder to suggest a group of
dictionaries that might benefit from the same gains, by preclassifying
non-__dict__ slot dictionaries to do similar sharing.
CSV reader is an exemplary candidate, because it creates
On 4/22/2019 5:19 PM, Steven D'Aprano wrote:
Oh, you mean just like regular dicts with shared keys already do:-)
https://www.python.org/dev/peps/pep-0412/
Perhaps I've missed something in this discussion, but isn't this a
matter of just making the existing shared-keys functionality explicitly
u
On Mon, Apr 22, 2019 at 10:06:20AM -0700, Chris Barker via Python-Dev wrote:
> maybe a new dict mapping type -- "shared_dict" -- it would be used in
> places like the csv reader where it makes sense, but wouldn't impact the
> regular dict at all.
>
> you could get really clever an have it auto-co
On 4/22/2019 4:03 PM, Inada Naoki wrote:
On Tue, Apr 23, 2019 at 2:18 AM Chris Barker via Python-Dev
wrote:
On Fri, Apr 12, 2019 at 10:20 AM Brett Cannon wrote:
This doesn't strike me as needing an optimization through a dedicated method.
maybe a new dict mapping type -- "shared_dict" -- i
On Tue, Apr 23, 2019 at 2:18 AM Chris Barker via Python-Dev
wrote:
>
> On Fri, Apr 12, 2019 at 10:20 AM Brett Cannon wrote:
>>>
>>>
>> This doesn't strike me as needing an optimization through a dedicated method.
>
> maybe a new dict mapping type -- "shared_dict" -- it would be used in places
>
On Tue, Apr 23, 2019 at 4:40 AM Brett Cannon wrote:
>
> On Sat, Apr 20, 2019 at 2:10 PM Inada Naoki wrote:
>>
>> "import typing" is slow too.
>
> But is it so slow as to not do the right thing here and use the 'typing'
> module as expected?
I don't know it is not a "right thing" yet. It feel i
On 22Apr2019 1521, Andrew Svetlov wrote:
I see the chicken and egg problem here.
If we are talking about typing module usage -- typeshed is the type
hints provider.
If PyCharm doesn't want to use it -- it is not CPython problem.
I think there is no need to change python code itself but used tool
I see the chicken and egg problem here.
If we are talking about typing module usage -- typeshed is the type
hints provider.
If PyCharm doesn't want to use it -- it is not CPython problem.
I think there is no need to change python code itself but used tooling.
On Mon, Apr 22, 2019 at 11:06 PM Bret
On Sat, Apr 20, 2019 at 2:10 PM Inada Naoki wrote:
> "import typing" is slow too.
>
But is it so slow as to not do the right thing here and use the 'typing'
module as expected? If you have so much work you need to launch some
threads or processes to deal with it then a single import isn't going
On Fri, Apr 12, 2019 at 10:20 AM Brett Cannon wrote:
>
>> This doesn't strike me as needing an optimization through a dedicated
> method.
>
maybe a new dict mapping type -- "shared_dict" -- it would be used in
places like the csv reader where it makes sense, but wouldn't impact the
regular dict
16 matches
Mail list logo
