Attached is the tarball for simplejson 1.9, the proposed version to be
included in the stdlib.

Estimated work remaining:

 * Rename simplejson to json
 * Build simplejson/_speedups.c from Modules/Setup and Windows projects
 * Convert documentation to Python docs
 * Port to Python 3.0

This work might be a good thing to a do on a Bazaar branch.

The most critical steps are to get the code building and to get the tests 
passing. Once that is working the code can be checked in and the other 
steps (docs, PEP 7/8, 3.0 conversion) can happen after the fact.

Yeah, either make a bzr branch or an ordinary svn branch. If you need
some help with the C code I can be of assistance. I'm in #python-dev.
Let's coordinate the next steps there.

On Sat, May 3, 2008 at 3:19 PM, Christian Heimes <report@bugs.python.org> wrote:
>
>  Christian Heimes <lists@cheimes.de> added the comment:
>
>  Yeah, either make a bzr branch or an ordinary svn branch. If you need
>  some help with the C code I can be of assistance. I'm in #python-dev.
>  Let's coordinate the next steps there.

I am about to create a bzr branch in my personal directory named
issue2750-simplejson.

Branch is at http://code.python.org/python/users/brett/issue2750-
simplejson/ .

Just so it is documented, Bob said on IRC that we do not need to keep 
compatibility with any specific version of Python.

I'll do PEP 8 review.

The json package is in brett's branch, integrates with the test suite,
builds the C extension and passes all tests (at least on OS X and Linux
UCS2 and UCS4).

Missing the docs and python 3.0 support still, otherwise things look good.

I'm going to handle the docs, too.

One problem with the way the patch is now is that it will fail on non-
CPython interpreters the way it is currently coded. For instance, 
json/decoder.py completely assumes that importing _json will succeed. Same 
with the test suite.

Will need to tweak the code so that it will run on PyPy, etc., where there 
is no C extensions.

But that does not need to hold up committing the code. If Christian and 
Benjamin think the code is in good shape we can commit now and fix in svn.

It doesn't work on alternate implementations right now anyway, because
it (ab)uses some sre APIs that aren't widely implemented outside of cpython.

Ouch. Well then hopefully either they will get implemented or some way to 
not rely on them can be developed.

it's isolated to json.scanner, if that was re-implemented in more
general terms then it wouldn't be dependent on sre anymore.

BTW, the regression for not executing packages was intented. See #2751.

Well, that's unfortunate. I found it very useful

I've committed the reST docs. Bob, do you want to have a look?

They look good, but is there an easy way to look at them post-formatting
or do I have to install the sphinx toolchain myself?

I moved the command-line stuff to json.tool to get around the package
problem.

On Sun, May 4, 2008 at 12:56 PM, Bob Ippolito <report@bugs.python.org> wrote:
>
>  Bob Ippolito <bob@redivi.com> added the comment:
>
>  They look good, but is there an easy way to look at them post-formatting
>  or do I have to install the sphinx toolchain myself?

in the Doc directory, run make html.

>  I moved the command-line stuff to json.tool to get around the package
>  problem.

Why not json.pp (for pretty-print)?

Benjamin, if you want you can send me the rst file for review. I tried
to checkout the bzr branch, but cancelled it after waiting for 25 minutes.

I don't think that makes sense, "tool" makes it pretty clear that it's
something you use from the command-line rather than a module to import
and call functions from where pp does not.

I'd also rather call it pprint than pp if that were the decision.. EIBTI.

Georg, I'm attaching json.rst.

Bob, I personally would prefer pprint, but it's your choice.

When we're ready, I'll merge this into the trunk and Py3k. (There are no
Py3k warnings on test, so it should only be a matter of running 2to3.)

The ref leak and unit tests are passing on Windows, too. I'm going to
change the import of the C extension and then you can commit the bzr
branch into the trunk.

For 3.0 the C module probably needs some changes. I'll look into it once
the code is merged into the trunk.

Bob, all of the simplejson tests have actually been passing on Jython 
trunk -- at least up until recently when you added a couple tests that 
utilize the 2.4 decimal module.

I can also import simplejson.scanner with a recent build of pypy, so it at 
least has those sre imports you're using.

Please merge the bzr into the svn trunk as soon as possible. I'd like to
get it into the last alpha release.

So there is one failing test because json.dumps() tacks on extraneous 
whitespace. When you run the file through reindent it strips out the 
whitespace from the docstring, causing doctest to fail.

Trying to fix it.

r62734 has it in the trunk. I had to change a doctest to use repr() in 
order to get around the extraneous whitespace that pretty-printing spits 
out, but otherwise I only added a Misc/NEWS entry.

I am leaving this issue open until 'json' is ported to 3.0 (and thus why I 
am assigning this to Christian).

Fixed up the docs in r62736.

The Python 3.0 port is going to be tricky. Can somebody with more
knowledge about the code please annotate which methods accept/return
bytes and/or unicode?

loads will take unicode or str. if it's str then it assumes utf-8,
otherwise the explicitly specified encoding. All of the string instances
generated by loads will be unicode objects (some of them may be str
objects if they're all ASCII as an optimization, I'm not sure if I
implemented that or not).

dumps produces an ASCII str, but if you explicitly specify
ensure_ascii=False then it will return a unicode object.

obviously load and dump will be working on a file-like object so should
be dealing with bytes...

I'm not entirely sure whether semantically dumps should produce bytes or
str in py3k, I guess whatever the other text-based encodings do is
appropriate (e.g. base64, mime).

Since dumps and loads deal with raw data they should accept/return
bytes, too.

I'm re-adding 2.6 as version again because I believe we should clean up
the API in 2.6 first. It's also a good chance to document how to port a
library to Python 2.6 and 3.0. *wink*

Command to merge json into 3.0:

svnmerge.py unblock -r62734,62736,62748,62769; svnmerge.py merge --force
-r62734,62736,62748,62769

On Wed, May 7, 2008 at 7:08 PM, Christian Heimes <report@bugs.python.org> wrote:
>
>  Christian Heimes <lists@cheimes.de> added the comment:
>
>  Command to merge json into 3.0:
>
>  svnmerge.py unblock -r62734,62736,62748,62769; svnmerge.py merge --force
>  -r62734,62736,62748,62769

Why is the --force needed?

Because I haven't committed the result of svnmerge.py unblock yet.
svnmerge.py refuses to work on a sandbox with uncommitted changes.

2to3:

./python Tools/scripts/2to3 -w Lib/json/
./python Tools/scripts/2to3 -w -d Lib/json/

I got the JSON module working under Python 3.0. I'm still not happy with
the mixing of bytes and unicode, though.

The patch contains additional changes to "svnmerge.py unblock
-r62734,62736,62748,62769; svnmerge.py merge --force
-r62734,62736,62748,62769"

When you've merged it, I'll alter the 3.0 docs.

Can this issue be closed?

Let's see:

1. Fix up and add to trunk. Check!
2. Convert docs to reST. Check!
3. Port to 3.0. Check!
4. Fix docs in 3.0. Check!

Yes, we can close this.