[prev in list] [next in list] [prev in thread] [next in thread] 

List:       python-ideas
Subject:    Re: [Python-ideas] Make MappingProxyType picklable
From:       Antony Lee <antony.lee () berkeley ! edu>
Date:       2014-02-22 6:03:50
Message-ID: CAGRr6BFQvydwhCvbceaQ3-3rtpvWDgEOanmjjMS_zKwTh-fjPQ () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


Not really, although if there is no technical limitation (and if there is
one, what is it?), it seems preferable to make mappingproxies picklable
rather than use ad-hoc fixes for Signature.
Thanks for the quick reply.


2014-02-21 19:26 GMT-08:00 Yury Selivanov <yselivanov.ml@gmail.com>:

> Antony,
>
>
> On 2/21/2014, 9:13 PM, Antony Lee wrote:
>
>> Currently, mappingproxies are not picklable, which (among other things)
>> lead to signature objects being non picklable.  Could this be easily
>> fixed,
>> or is there a stronger reason for not allowing that pickling?
>> If mappingproxies cannot be made picklable, perhaps signatures can
>> implement __getnewargs__ to allow pickling?
>> Antony
>>
>>  Good catch. I think we'll make Signatures picklable in 3.5
> (http://bugs.python.org/issue20726)  It can be implemented
> using __reduce__ and __setstate__ methods. We can't use
> __getnewargs__ as we have keyword-only arguments in
> Parameter and Signature classes (but maybe we'll be able
> to use __getnewargs_ex__ in 3.5)
>
> Do you have any other reasons to make mappingproxies
> picklable?
>
> Yury
> _______________________________________________
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>

[Attachment #5 (text/html)]

<div dir="ltr">Not really, although if there is no technical limitation (and if there \
is one, what is it?), it seems preferable to make mappingproxies picklable rather \
than use ad-hoc fixes for Signature.<div>Thanks for the quick reply.</div> </div><div \
class="gmail_extra"><br><br><div class="gmail_quote">2014-02-21 19:26 GMT-08:00 Yury \
Selivanov <span dir="ltr">&lt;<a href="mailto:yselivanov.ml@gmail.com" \
target="_blank">yselivanov.ml@gmail.com</a>&gt;</span>:<br> <blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">Antony,<div><div class="h5"><br> <br>
On 2/21/2014, 9:13 PM, Antony Lee wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"> Currently, mappingproxies are not picklable, which (among \
other things)<br> lead to signature objects being non picklable.   Could this be \
easily fixed,<br> or is there a stronger reason for not allowing that pickling?<br>
If mappingproxies cannot be made picklable, perhaps signatures can<br>
implement __getnewargs__ to allow pickling?<br>
Antony<br>
<br>
</blockquote></div></div>
Good catch. I think we&#39;ll make Signatures picklable in 3.5<br>
(<a href="http://bugs.python.org/issue20726" \
target="_blank">http://bugs.python.org/<u></u>issue20726</a>)   It can be \
implemented<br> using __reduce__ and __setstate__ methods. We can&#39;t use<br>
__getnewargs__ as we have keyword-only arguments in<br>
Parameter and Signature classes (but maybe we&#39;ll be able<br>
to use __getnewargs_ex__ in 3.5)<br>
<br>
Do you have any other reasons to make mappingproxies<br>
picklable?<br>
<br>
Yury<br>
______________________________<u></u>_________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org" \
target="_blank">Python-ideas@python.org</a><br> <a \
href="https://mail.python.org/mailman/listinfo/python-ideas" \
target="_blank">https://mail.python.org/<u></u>mailman/listinfo/python-ideas</a><br> \
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" \
target="_blank">http://python.org/psf/<u></u>codeofconduct/</a><br> \
</blockquote></div><br></div>



_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/

[prev in list] [next in list] [prev in thread] [next in thread]