On Wed, Apr 24, 2019 at 6:17 AM Mark Shannon wrote:
>
> Hi,
>
> On 12/04/2019 2:44 pm, Inada Naoki wrote:
> > Hi, all.
> >
> > I propose adding new method: dict.with_values(iterable)
>
> You can already do something like this, if memory saving is the main
> concern. This should work on all
Hi,
On 12/04/2019 2:44 pm, Inada Naoki wrote:
Hi, all.
I propose adding new method: dict.with_values(iterable)
You can already do something like this, if memory saving is the main
concern. This should work on all versions from 3.3.
def shared_keys_dict_maker(keys):
class C: pass
12.04.19 19:17, Inada Naoki пише:
Maybe, collections.DictBuilder may be another option. e.g.
from collections import DictBuilder
builder = DictBuilder(tuple("abc"))
builder.build(range(3))
{"a": 0, "b": 1, "c": 2}
Nitpicking: this is rather a factory than a builder. The difference
between
On Wed, Apr 24, 2019 at 12:34 AM Steve Dower wrote:
>
> >> If it's a key-sharing dict, then all the keys are strings. We know that
> >> when we go to do the update, so we can intern all the strings (going to
> >> do that anyway) and then it's a quick check if it already exists. If
> >> it's a
On Wed, Apr 24, 2019 at 12:28 AM Steve Dower wrote:
>
> >
> > But if the original dictionary wasn't created with shared keys... the
> > copy can't share them either. Or are you suggesting adding new code to
> > create a shared key dictionary from one that isn't?
>
> This is a good point. Maybe
On 23Apr2019 0008, Inada Naoki wrote:
On Tue, Apr 23, 2019 at 2:54 PM Steve Dower wrote:
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
On 23Apr2019 0034, Glenn Linderman wrote:
On 4/22/2019 10:59 PM, Steve Dower wrote:
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?
On 4/22/2019 10:59 PM, Steve Dower wrote:
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
On Tue, Apr 23, 2019 at 2:54 PM Steve Dower wrote:
>
> 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
>
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
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
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
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
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
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
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
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" --
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 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
On Fri, Apr 12, 2019 at 8:35 AM Serhiy Storchaka
wrote:
> 12.04.19 16:44, Inada Naoki пише:
> > When creating many dicts with same keys, dict need to
> > lookup internal hash table while inserting each keys.
> >
> > It is costful operation. If we can reuse existing keys of dict,
> > we can skip
On Sat, Apr 13, 2019 at 12:38 AM Serhiy Storchaka wrote:
>
> It looks contrary to simplification made in Python 3 when we get rid of
> some more efficient lists in favor of more general iterators.
>
Yes. This is API for special use case creates many dict having
same keys, like csv.DictReader.
On Fri, Apr 12, 2019 at 11:31 PM Victor Stinner wrote:
>
> Nice optimization! I have questions on the proposed API.
>
> > with_values(self, iterable, /)
> > Create a new dictionary with keys from this dict and values from
> > iterable.
> >
> > When length of iterable is different from
12.04.19 16:44, Inada Naoki пише:
When creating many dicts with same keys, dict need to
lookup internal hash table while inserting each keys.
It is costful operation. If we can reuse existing keys of dict,
we can skip this inserting cost.
Additionally, we have "Key-Sharing Dictionary (PEP
Nice optimization! I have questions on the proposed API.
> with_values(self, iterable, /)
> Create a new dictionary with keys from this dict and values from iterable.
>
> When length of iterable is different from len(self), ValueError is raised.
> This method does not support dict
Hi, all.
I propose adding new method: dict.with_values(iterable)
# Motivation
Python is used to handle data.
While dict is not efficient way to handle may records, it is still
convenient way.
When creating many dicts with same keys, dict need to
lookup internal hash table while inserting each
27 matches
Mail list logo
