-
-
Notifications
You must be signed in to change notification settings - Fork 30.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
json C vs pure-python implementation difference #59091
Comments
Pure-python implementation: C implementation: This make real difference (!) in my code. So, please change pure-python implementation to: |
What difference does it make? Are you using __instancecheck__ perhaps? |
#!/usr/bin/python2.7 import json
class pseudo_list(object):
__class__ = list # fake isinstance
def __init__(self, iterator):
self._saved_iterator = iterator
def __iter__(self):
return self._saved_iterator
class myenc(json.JSONEncoder):
def default(self, o):
try:
return pseudo_list(iter(o))
except TypeError:
return super(myenc, self).default(o) # works (pure-python implementation) # does not work (C implementation) |
Why not inherit from list directly? |
Well, __class_ = list is my problem, but python's problem is that it uses different approaches in C and python implementation. P.S. |
Well, by construction a C accelerator will use the fastest method |
Inconsistency is bother me. If I specify indent in dumps(), I will have one semantics, else other ones. Why not to fix pure-python implementation using "type(o) in (list, tuple)" ? This is faster too (as I think). |
FWIW, I think Mark's right here. I'm +1 on the implementations being consistent. Seems like a potentially nasty surprise if you move from one implementation to the other and, lacking awareness of this quirk, design your algorithm around semantics. I think this was Mark's original point. If the json API doesn't care how the type check is performed, then we get a (probably very small :)) win from the type(o) in (list, tuple) for the Python impl in addition to bringing consistency to the two implementations. |
We have received a notification about this bug for 3.5 |
FWIW, the C implementation of the sequence encoder uses PySequence_Fast(), so adding a lower priority instance check that calls the same encoding function would solve this. Line 1730 in cfa797c
Probably not something to fix in Py3.5/6 anymore, though. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: