On Thu, Apr 9, 2009 at 1:05 PM, "Martin v. Löwis" <mar...@v.loewis.de> wrote: >>> I can understand that you don't want to spend much time on it. How >>> about removing it from 3.1? We could re-add it when long-term support >>> becomes more likely. >> >> I'm speechless. > > It seems that my statement has surprised you, so let me explain: > > I think we should refrain from making design decisions (such as > API decisions) without Bob's explicit consent, unless we assign > a new maintainer for the simplejson module (perhaps just for the > 3k branch, which perhaps would be a fork from Bob's code). > > Antoine suggests that Bob did not comment on the issues at hand, > therefore, we should not proceed with the proposed design. Since > the 3.1 release is only a few weeks ahead, we have the choice of > either shipping with the broken version that is currently in the > 3k branch, or drop the module from the 3k branch. I believe our > users are better served by not having to waste time with a module > that doesn't quite work, or may change.
Most of my time to spend on json/simplejson and these mailing list discussions is on weekends, I try not to bother with it when I'm busy doing Actual Work unless there is a bug or some other issue that needs more immediate attention. I also wasn't aware that I was expected to comment on those issues. I'm CC'ed on the discussion for issue4136 but I don't see any unanswered questions directed at me. I have the issues (issue5723, issue4136) starred in my gmail and I planned to look at it more closely later, hopefully on Friday or Saturday. As far as Python 3 goes, I honestly have not yet familiarized myself with the changes to the IO infrastructure and what the new idioms are. At this time, I can't make any educated decisions with regard to how it should be done because I don't know exactly how bytes are supposed to work and what the common idioms are for other libraries in the stdlib that do similar things. Until I figure that out, someone else is better off making decisions about the Python 3 version. My guess is that it should work the same way as it does in Python 2.x: take bytes or unicode input in loads (which means encoding is still relevant). I also think the output of dumps should also be bytes, since it is a serialization, but I am not sure how other libraries do this in Python 3 because one could argue that it is also text. If other libraries that do text/text encodings (e.g. binascii, mimelib, ...) use str for input and output instead of bytes then maybe Antoine's changes are the right solution and I just don't know better because I'm not up to speed with how people write Python 3 code. I'll do my best to find some time to look into Python 3 more closely soon, but thus far I have not been very motivated to do so because Python 3 isn't useful for us at work and twiddling syntax isn't a very interesting problem for me to solve. -bob _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
