[issue25447] TypeError invoking deepcopy on lru_cache

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Using lru_cache() is an implementation detail. I think that lru_cache wrapper 
should be perfect wrapper, it should support all protocols that are supported 
by wrapped function (at the same extent as original Python implementation).

Proposed simple patch adds support for pickling, copying and deep-copying 
lru_cache wrappers. lru_cache wrapper is serialized as global object, i.e. 
deepcopy() returns the same object, as was in 3.4. Implementing true deep 
copying (with any semantic) is not so easy, especially for Python 
implementation.

--
keywords: +patch
stage:  -> patch review
Added file: http://bugs.python.org/file40845/lru_cache_simple_pickling.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25457] json dump fails for mixed-type keys when sort_keys is specified

[Christian Tanzer]

Christian Tanzer added the comment:

Josh Rosenberg wrote at Fri, 23 Oct 2015 02:45:51 +:

> The Python 2 sort order is a result of the "arbitrary but consistent
> fallback comparison" (omitting details, it's comparing the names of
> the types), thus the "strange" sort order.

Thanks. I knew that.

> Python 3 (justifiably) said that incomparable types should be
> incomparable rather than silently behaving in non-intuitive ways,
> hiding errors.

"justifiably" is debatable. I consider the change ill-conveived.

Displaying a dictionary (or just its keys) in a readable, or just
reproducible, way is useful in many contexts. Python 3 broke that for
very little, INMNSHO, gain.

I consider "hiding errors" a myth, to say it politely!

> Python is being rather generous by allowing non-string keys, because
> the  JSON spec ( http://json.org/ ) only allows the keys ("names" in
> JSON parlance) to be strings. So you're already a bit in the weeds as
> far as compliant JSON goes if you have non-string keys.

There are two possibilities:

1) Accepting non-string keys is intended. Then `sort_keys` shouldn't
   break like it does.

   As far as JSON goes, the output of `json.dump[s]` contains string keys.

2) Accepting non-string keys is a bug. Then `json.dump[s]` should be
   changed to not accept them.

Mixing both approaches is the worst of all worlds.

> Since mixed type keys lack meaningful sort order, I'm not sure it's
> wrong to reject attempts to sort them.

The documentation says:

If sort_keys is True (default False), then the output of dictionaries
will be sorted by key; this is useful for regression tests to ensure
that JSON serializations can be compared on a day-to-day basis.

**Reproducible** is the keyword here.

**Readability** is another one. Even if the sort order is "strange",
it is much better than random order, if you are looking for a specific
key.

For the record, it was a test failing under Python 3.5 that triggered
this bug report.

> > As all they keys are dumped as strings, a simple solution would be to
> > sort after converting to strings.
> Converting to string is as
> arbitrary and full of potential for silently incorrect comparisons as
> the Python 2 behavior, and reintroducing it seems like a bad idea.

json.dumps already does the conversion::

>>> json.dumps({1 : 42, "foo" : "bar", None : "nada"})
'{"foo": "bar", "1": 42, "null": "nada"}'

Another run::

>>> json.dumps({1 : 42, "foo" : "bar", None : "nada"})
'{"1": 42, "foo": "bar", "null": "nada"}'

That difference is exactly the reason for `sort_keys`.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25457] json dump fails for mixed-type keys when sort_keys is specified

[Christian Tanzer]

Christian Tanzer added the comment:

Josh Rosenberg wrote at Fri, 23 Oct 2015 02:56:30 +:

> As a workaround (should you absolutely need to sort keys by some
> arbitrary criteria), you can initialize a collections.OrderedDict from
> the sorted items of your original dict (using whatever key function
> you like), then dump without using sort_keys=True.

Sigh...

I already implemented a workaround but it's not as simple as you
think — the dictionary in question is nested.

The problem is that this is just another unnecessary difficulty when
trying to move to Python 3.x.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24570] IDLE Autocomplete and Call Tips Do Not Pop Up on OS X with ActiveTcl 8.5.18

[Jose M. Alcaide]

Jose M. Alcaide added the comment:

This issue continues unfixed.

After uninstalling ActiveTcl 8.5.18 and then installing ActiveTcl 8.5.17, IDLE 
completion and call tips work again.

Tested with Python 3.5 and 3.4.1.

--
nosy: +jmas

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25465] Pickle uses O(n) memory overhead

[Herbert]

New submission from Herbert:

I very often want to use pickle to store huge objects, such that I do not need 
to recalculate them again.

However, I noticed that pickle uses O(n) (for n the object size in memory) 
amount of memory. That is, using python 3:

data = {'%06d' % i: i for i in range(30 * 1000 ** 2)}
# data consumes a lot of my 8GB ram
import pickle
with open('dict-database.p3', 'wb') as f: pickle.dump(data, f)
# I have to kill the process, in order to not overflow in memory. If I 
don't, the OS crashes. IMHO the OS should never crash due to python.

I don't think pickle should require a O(n) memory overhead.

--
messages: 253371
nosy: prinsherbert
priority: normal
severity: normal
status: open
title: Pickle uses O(n) memory overhead

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25465] Pickle uses O(n) memory overhead

[Herbert]

Changes by Herbert :


--
type:  -> performance
versions: +Python 3.4

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25461] Unclear language (the word ineffective) in the documentation for os.walk

[Bernt Røskar Brenna]

Changes by Bernt Røskar Brenna :


--
keywords: +patch
Added file: 
http://bugs.python.org/file40846/os_walk_docs_change_unclear_language.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25461] Unclear language (the word ineffective) in the documentation for os.walk

[Bernt Røskar Brenna]

Bernt Røskar Brenna added the comment:

I agree your suggestion is better, I did not see it before submitting my first 
patch. I've added another patch.

--
Added file: 
http://bugs.python.org/file40847/os_walk_docs_change_unclear_language_2.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25447] TypeError invoking deepcopy on lru_cache

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Added test cases for nested functions (__qualname__ != __name__).

--
Added file: http://bugs.python.org/file40848/lru_cache_simple_pickling_2.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com