A rule for your twitlist/mailing list
Where path includes "google.com" and subject includes "solutions" or "test", delete. 99 percent of the junk just . gone . feels so good I wish Google would still let you subscribe to the newsgroup and recieve updates in your inbox - that way I can mark the testbanks as "spam" Is the mailing list for comp.lang.python still open? -- https://mail.python.org/mailman/listinfo/python-list
Re: frozendict: an experiment
On Mon, 13 Jul 2020 at 19:28, Barry Scott wrote:
> > On 13 Jul 2020, at 03:20, Marco Sulla wrote:
> > So why did I try to implement it? IMO, apart the considerations in PEP
> > 416, a frozendict can be useful:
> >
> > - as a faster base for types.MutableMappingProxy
> > - as a substitute of namedtuple
> > - as set values
> > - as a faster dict. Indeed a frozendict does not need views. Keys,
> > values and items can be cached and could be a subclass of frozendict
> > that implements also the set API (values apart).
>
>
> Why is it faster? Have you benchmarked that claim?
It's not faster now, but it can. And yes, I've done a bench. I explain
it better in the mail.
> Why do you think I do not need views to use the frozendict?
> I thought that is what make d.key(), d.items() etc work?
Views for dict exist because dict is mutable. See this example:
>>> d = {1: 2}
>>> keys = d.keys()
>>> d[2] = 3
>>> keys
dict_keys([1, 2])
As you see, even if you modified the dict __after__ you created the
keys view, the view returns also the new key, 2.
This is desirable for a mutable object, but it's not needed for an
immutable one. frozendict could create lazily an object that contains
all its keys and cache it.
It *seems* that this is already done, because PyDictObject struct has
ma_keys and ma_values. But this is not always true. If you read the
documentation in the comments of Object/dictobject.c, it's stated
that, if the keys are not strings, there's actually not two separate
objects for keys and values. On the contrary, key and value are stored
together in ma_keys.
This seems to be done because it's easier to preserve order when you
modify the dict. But since frozendict cannot be modified, it could be
a split dict every time.
> > A possible problem is that frozendict requires more memory, since the
> > hash is cached.
>
> The hash is tiny 64 bits?
Well, it's the sum that makes the total. If, and only if, frozendict
is really faster than dict, using always a split dict and cached
"views", it could be used for a bunch of cases. kwargs for example.
About bench, yes, as I wrote I've done a simple bench:
Dictionary size:8; Type: dict; Statement: `d.get(key)`;
total time: 0.389; iterations: 1300; time: 2.990e-08
Dictionary size:8; Type: frozendict; Statement: `d.get(key)`;
total time: 0.416; iterations: 1300; time: 3.202e-08
Dictionary size:8; Type:Map; Statement: `d.get(key)`;
total time: 0.559; iterations: 1300; time: 4.302e-08
Dictionary size:8; Type: dict; Statement: `d[key]`;
total time: 0.375; iterations: 1000; time: 3.753e-08
Dictionary size:8; Type: frozendict; Statement: `d[key]`;
total time: 0.338; iterations: 1000; time: 3.384e-08
Dictionary size:8; Type:Map; Statement: `d[key]`;
total time: 0.502; iterations: 1000; time: 5.021e-08
Dictionary size:8; Type: dict; Statement: `key in d`;
total time: 0.600; iterations: 2000; time: 3.000e-08
Dictionary size:8; Type: frozendict; Statement: `key in d`;
total time: 0.541; iterations: 2000; time: 2.703e-08
Dictionary size:8; Type:Map; Statement: `key in d`;
total time: 0.545; iterations: 2000; time: 2.723e-08
Dictionary size:8; Type: dict; Statement: `key not in d`;
total time: 0.607; iterations: 2000; time: 3.033e-08
Dictionary size:8; Type: frozendict; Statement: `key not in d`;
total time: 0.548; iterations: 2000; time: 2.738e-08
Dictionary size:8; Type:Map; Statement: `key not in d`;
total time: 0.548; iterations: 2000; time: 2.738e-08
Dictionary size:8; Type: dict; Statement: `pickle.dumps(d)`;
total time: 0.554; iterations: 625000; time: 8.869e-07
Dictionary size:8; Type: frozendict; Statement: `pickle.dumps(d)`;
total time: 0.545; iterations: 625000; time: 8.720e-07
Dictionary size:8; Type:Map; Statement: `pickle.dumps(d)`;
total time: 1.562; iterations: 625000; time: 2.499e-06
Dictionary size:8; Type: dict; Statement:
`pickle.loads(dump)`; total time: 0.685; iterations: 50;
time: 1.371e-06
Dictionary size:8; Type: frozendict; Statement:
`pickle.loads(dump)`; total time: 0.816; iterations: 50;
time: 1.633e-06
Dictionary size:8; Type:Map; Statement:
`pickle.loads(dump)`;
Re: A rule for your twitlist/mailing list
On 14Jul2020 08:49, Nomen Nescio wrote: >Where path includes "google.com" and subject includes "solutions" or >"test", delete. > >99 percent of the junk just . gone . feels so good > >I wish Google would still let you subscribe to the newsgroup and >recieve updates in your inbox - that way I can mark the testbanks as >"spam" > >Is the mailing list for comp.lang.python still open? If you mean the python-list mailing list, yes. It is what I use, and it does not suffer from the spam you describe. Here: https://mail.python.org/mailman/listinfo/python-list It gateways with the newsgroup, but has much better spam qualities. Cheers, Cameron Simpson -- https://mail.python.org/mailman/listinfo/python-list
ANN: Wing Python IDE 7.2.3 has been released
Wing 7.2.3 has been released. This update introduces a How-To for using Wing with PyXLL, adds folding in .pyi and .pi files, fixes opening files from the macOS Catalina Finder, and makes many usability improvements.For details see the change log: https://wingware.com/pub/wingpro/7.2.3.0/CHANGELOG.txt == New features in Wing 7.2 include == * Auto-Reformatting with Black and YAPF (Wing Pro) Wing 7.2 adds support for Black and YAPF for code reformatting, in addition to the previously available built-in autopep8 reformatting. To use Black or YAPF, they must first be installed into your Python with pip, conda, or other package manager. Reformatting options are available from the Source > Reformatting menu group, and automatic reformatting may be configured in the Editor > Auto-reformatting preferences group. Details: https://wingware.com/doc/edit/auto-reformatting * Improved Support for Virtualenv Wing 7.2 improves support for virtualenv by allowing the command that activates the environment to be entered in the Python Executable in Project Properties, Launch Configurations, and when creating new projects. The New Project dialog now also includes the option to create a new virtualenv along with the new project, optionally specifying packages to install. Details: https://wingware.com/doc/howtos/virtualenv * Support for Anaconda Environments Similarly, Wing 7.2 adds support for Anaconda environments, so the conda activate command can be entered when configuring the Python Executable and the New Project dialog supports using an existing Anaconda environment or creating a new one along with the project. Details: https://wingware.com/doc/howtos/anaconda * And More Wing 7.2 also introduces How-Tos for using Wing with AWS and PyXLL, makes it easier to debug modules with python -m, adds support for Python 3 enums, simplifies manual configuration of remote debugging, allows using a command line for the configured Python Executable, supports constraining Find Uses of imported symbols to only the current file, allows folding .pyi and .pi files, and makes a number of usability and stability improvements. For a complete list of new features in Wing 7, see What's New in Wing 7: https://wingware.com/wingide/whatsnew == Downloads == Wing Pro: https://wingware.com/downloads/wing-pro/7.2/binaries Wing Personal: https://wingware.com/downloads/wing-personal/7.2/binaries Wing 101: https://wingware.com/downloads/wing-101/7.2/binaries Compare products: https://wingware.com/downloads See https://wingware.com/doc/install/upgrading for details on upgrading from Wing 6 and earlier, and https://wingware.com/doc/install/migrating for a list of compatibility notes. -- https://mail.python.org/mailman/listinfo/python-list
Re: frozendict: an experiment
On Wed, Jul 15, 2020 at 2:01 AM Marco Sulla
wrote:
>
> > Why do you think I do not need views to use the frozendict?
> > I thought that is what make d.key(), d.items() etc work?
>
> Views for dict exist because dict is mutable. See this example:
>
> >>> d = {1: 2}
> >>> keys = d.keys()
> >>> d[2] = 3
> >>> keys
> dict_keys([1, 2])
>
> As you see, even if you modified the dict __after__ you created the
> keys view, the view returns also the new key, 2.
> This is desirable for a mutable object, but it's not needed for an
> immutable one. frozendict could create lazily an object that contains
> all its keys and cache it.
I don't think so. The view objects are useful when we need a set-like
operation. (e.g. `assert d.keys() == {"spam", "egg"}`)
There is no difference between mutable and immutable dicts.
--
Inada Naoki
--
https://mail.python.org/mailman/listinfo/python-list
