Bob Ippolito b...@redivi.com added the comment:
For what it's worth, I don't think any of the failures mentioned here are in
the current version of simplejson. There aren't any tests that check the
speedup module name, the speedup tests are skipped when speedups are not
detected
Bob Ippolito b...@redivi.com added the comment:
Well this feature is already in simplejson 2.1.0, it would probably make more
sense to simply merge the latest simplejson back with Python 3.
--
___
Python tracker rep...@bugs.python.org
http
Bob Ippolito b...@redivi.com added the comment:
The test in the patch assumes a specific iteration order for the dict h,
changing the dict to have only one key would fix this problem with the test.
--
___
Python tracker rep...@bugs.python.org
http
Bob Ippolito b...@redivi.com added the comment:
The test also repeats an equivalent dict to h in the check function.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10019
Bob Ippolito b...@redivi.com added the comment:
I just applied a version of this patch with corrections to the tests here:
http://code.google.com/p/simplejson/source/detail?r=234
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Bob Ippolito b...@redivi.com added the comment:
Sorry but I don't think I will be able to. I'd be happy to accept patches into
simplejson that make it easier to merge with Python 3 in the future, but I
simply do not have the time to maintain the Python 3 branch of the code that we
don't use
Bob Ippolito [EMAIL PROTECTED] added the comment:
I applied the changes proposed in _json26.patch to simplejson and they
worked perfectly fine. Again I'm not the best judge of python 3.0 code
because I have not made myself familiar with the API changes so someone
else should review
Bob Ippolito [EMAIL PROTECTED] added the comment:
Sure, but that doesn't port it to Python 3.0 :)
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4136
Bob Ippolito [EMAIL PROTECTED] added the comment:
You're probably right, I don't remember what code I was using as a
template for that.
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4136
Bob Ippolito [EMAIL PROTECTED] added the comment:
I don't recall exactly why they aren't in the struct itself, it may not
have worked with some compiler on some platform.
It's not really a complete rewrite, the encoding path is largely the
same and the tests haven't changed.
Anyway
Bob Ippolito [EMAIL PROTECTED] added the comment:
http://codereview.appspot.com/7311
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4136
___
___
Python-bugs-list
Bob Ippolito [EMAIL PROTECTED] added the comment:
Attached is a new diff, one byte fix to the float parser when parsing JSON
documents that are just a float (also a test and a version bump).
Added file: http://bugs.python.org/file11870/json_issue4136_r67009.diff
Changes by Bob Ippolito [EMAIL PROTECTED]:
--
title: merge json library with simplejson 2.0.3 - merge json library with
simplejson 2.0.4
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4136
Bob Ippolito b...@redivi.com added the comment:
You're the first person to ever raise any of these issues in the slightly
more than 3 years that the package has been around (by other names), so
I'm not sure such a warning needs to be that big.
JSON doesn't really have any framing, so
Bob Ippolito b...@redivi.com added the comment:
Ok, I've added some notes to the trunk of simplejson's documentation. Not
sure when/if that'll hit the Python trunks, I've been having a hard time
getting my other patches to sync up with simplejson through:
http://bugs.python.org/issue4136
Bob Ippolito b...@redivi.com added the comment:
There are some missing colons in the documentation apparently, which
causes reStructuredText to ignore the documentation for those two
functions.
--
nosy: +bob.ippolito
___
Python tracker rep
Bob Ippolito b...@redivi.com added the comment:
By next patch I'm referring to a currently nonexistent patch that
would merge the json library with simplejson 2.0.7 (svn trunk at the
moment). I may have time to create it next weekend.
---
http://codereview.appspot.com/7311/diff/1/8
File Lib
New submission from Bob Ippolito [EMAIL PROTECTED]:
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
Bob Ippolito [EMAIL PROTECTED] added the comment:
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
Bob Ippolito [EMAIL PROTECTED] added the comment:
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.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2750
Bob Ippolito [EMAIL PROTECTED] added the comment:
it's isolated to json.scanner, if that was re-implemented in more
general terms then it wouldn't be dependent on sre anymore.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2750
Bob Ippolito [EMAIL PROTECTED] added the comment:
Well, that's unfortunate. I found it very useful
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2750
__
___
Python-bugs-list
Bob Ippolito [EMAIL PROTECTED] 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?
I moved the command-line stuff to json.tool to get around the package
problem
Bob Ippolito [EMAIL PROTECTED] added the comment:
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
Bob Ippolito [EMAIL PROTECTED] added the comment:
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
Bob Ippolito [EMAIL PROTECTED] added the comment:
Am I to understand that the bug here is that the C extension doesn't
validate input properly if you call into it directly? Without a test I'm
not entirely sure exactly how you could possibly get negative values
into those functions using the json
Bob Ippolito [EMAIL PROTECTED] added the comment:
I've audited the patch, while it does fix the input range it looks like
it regresses other things (at least the error messages). begin was
intentionally used. The patch is not suitable for use, I'll create a
minimal patch that just fixes input
Bob Ippolito [EMAIL PROTECTED] added the comment:
I just committed a fix to trunk in r65147, needs port to py3k?
--
assignee: bob.ippolito - georg.brandl
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3322
Bob Ippolito [EMAIL PROTECTED] added the comment:
That patch looks ok to me, but I'm not at all familiar with the changes in
python 3.0 yet. Is this something that needs to be backported to 2.6?
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org
Bob Ippolito b...@redivi.com added the comment:
JP is correct, this is how JSON works. The behavior of coercing keys to
strings is often desirable, although I agree it could be confusing if you
aren't familiar with the JSON spec.
--
components: +Documentation -Library (Lib
Bob Ippolito b...@redivi.com added the comment:
Did you try the trunk of simplejson? It doesn't work quite the same way as
the current json module in Python 2.6+.
Without the data or a tool to produce data that causes the problem, there
isn't much I can do to help
Bob Ippolito b...@redivi.com added the comment:
If it had JavaScript style Date objects in it, it wasn't a JSON document.
While it may be easy enough to do this in the version that happens to be
included with Python, the optimizations in later versions of simplejson
make this no longer
Changes by Bob Ippolito b...@redivi.com:
--
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7444
___
___
Python-bugs-list
Bob Ippolito b...@redivi.com added the comment:
I applied most of this patch to r206 of simplejson trunk
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7451
Bob Ippolito b...@redivi.com added the comment:
That's not a problem, I'm more than happy to give permission for any patch. If
it's easier I can consider dual-licensing in the simplejson source.
--
___
Python tracker rep...@bugs.python.org
http
Bob Ippolito b...@redivi.com added the comment:
I did this some time ago in simplejson by defining a TestSuite subclass and
instrumenting simplejson so that speedups can be enabled and disabled easily
with a private API.
https://github.com/simplejson/simplejson/blob/master/simplejson/tests
Bob Ippolito added the comment:
To try and make this as painless as possible I have done both things.
simplejson is now explicitly dual-licensed MIT or AFL v2.1 and there is also an
explicit sentence in LICENSE.txt that states This code is also licensed to the
Python Software Foundation (PSF
Bob Ippolito added the comment:
I've applied a very similar patch to simplejson and released 3.0.9
https://github.com/simplejson/simplejson/commit/44d7709a31f3a19f3d465411585ebb7be7fa2295
--
nosy: +bob.ippolito
___
Python tracker rep
Bob Ippolito b...@redivi.com added the comment:
I doubt it, it's more likely that this email came from somewhere else with
my address.
On Thursday, July 5, 2012, Larry Hastings wrote:
Larry Hastings la...@hastings.org javascript:; added the comment:
What fresh hell is this? Bob, do you
Bob Ippolito added the comment:
I tend to agree with Raymond here. While I also don't like the positional
arguments, I don't think the benefit of API churn them is high enough to remove
them. Other than this issue, I have not seen any requests for this change.
I have seen problems because
Bob Ippolito added the comment:
Other than when subclassing (which is actively discouraged), I haven't seen
anyone try and use positional args for these APIs. I simply don't think this is
an issue in practice. If you go far enough back in simplejson history, these
module-global functions were
Bob Ippolito added the comment:
My evidence is only anecdotal. I haven't actively searched for code that uses
json/simplejson to try and find cases that are using positional arguments.
One way to test this assumption would be to release a version of simplejson
that deprecates using positional
Bob Ippolito added the comment:
The patch that I wrote for simplejson is here (it differs a bit from serhiy's
patch):
https://github.com/simplejson/simplejson/commit/35816bfe2d0ddeb5ddcc68239683cbb35b7e3ff2
I discovered another bug along the way in the pure-Python scanstring, int(s,
16
Bob Ippolito b...@redivi.com added the comment:
patch to r69662 is attached as json_issue4136_r69662.diff -- note that
simplejson 2.0.9 isn't released, as of r169 it's just simplejson 2.0.8
with some trivial changes to make this backport easier for me
Changes by Bob Ippolito b...@redivi.com:
Added file: http://bugs.python.org/file13106/json_issue4136_r69662.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4136
Bob Ippolito b...@redivi.com added the comment:
Old-style relative imports and the way that it does join are there because
it's Python 2.4 compatible code that I'm porting. I'll add those to the
list of things that need to be changed when backporting, implement cyclic
GC on the types
Bob Ippolito b...@redivi.com added the comment:
New patch implementing cyclic GC, new-style relative imports, no lines 80
characters in non-test Python code
Added file: http://bugs.python.org/file13152/json_issue4136_r69885.diff
___
Python tracker rep
Bob Ippolito b...@redivi.com added the comment:
Why? According to RFC (emphasis mine):
An object is an *unordered* collection of zero or more name/value
pairs, where a name is a string and a value is a string, number,
boolean, null, object, or array.
--
resolution: - invalid
Bob Ippolito b...@redivi.com added the comment:
Fair enough, but the patch isn't usable because the decoder was rewritten
in a later version of simplejson. There's another issue with patch to
backport those back into Python http://bugs.python.org/issue4136 or you
could just use the simplejson
Bob Ippolito b...@redivi.com added the comment:
Honestly I'm not sure when I'm going to find the time and motivation to
reformat the C source and tests to fit 80 char lines. I don't think this
should hold up the patch, someone who is more obsessive compulsive than
myself can fix that once
Bob Ippolito b...@redivi.com added the comment:
I don't really want to see looser input requirements, making a JSON
parser that is compatible with a subset of Python repr output isn't a
design goal of mine.
This is absolutely false:
Because single quotes are the only way (AFAIK) in which
Bob Ippolito b...@redivi.com added the comment:
Er, sorry, missed (from JSONable combinations of types). It's early.
Anyway, I can change the error message, but I will not make it special-
case single quotes for its own error message. I will have to think about
what the message could say
Bob Ippolito b...@redivi.com added the comment:
Unfortunately this is a patch for the old json lib... the new one has a C
API and an entirely different method of parsing documents (for performance
reasons).
___
Python tracker rep...@bugs.python.org
http
Bob Ippolito b...@redivi.com added the comment:
Whenever someone applies the patch for http://bugs.python.org/issue4136 --
I don't know when that will happen.
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5381
Bob Ippolito b...@redivi.com added the comment:
All of the comments are addressed. I am not going to go through the
trouble of creating a new patch to remove the remaining backwards
compatibility cruft in the C code and struct function. That is easier to
remove later
Bob Ippolito b...@redivi.com added the comment:
r70443 in trunk
--
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4136
Bob Ippolito b...@redivi.com added the comment:
It is common to specify a default function but it would be terrible for
performance if this function was called for every single object passed
through to the decoder.
If you want a serialization different from a primitive type you'll have
Bob Ippolito b...@redivi.com added the comment:
The documentation says If specified, default is a function that gets
called for objects that can’t otherwise be serialized. It should return a
JSON encodable version of the object or raise a TypeError.
*can't otherwise be serialized* means
New submission from Bob Ippolito b...@redivi.com:
http://code.google.com/p/simplejson/issues/detail?id=43
Need a = where there's a in the unicode float scanner. problem only
exists when decoding a unicode float that is not in any sort of container
(e.g. array or object).
--
assignee
Changes by Bob Ippolito b...@redivi.com:
--
components: +Library (Lib)
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5584
___
___
Python-bugs-list
Changes by Bob Ippolito b...@redivi.com:
--
resolution: - accepted
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5584
___
___
Python-bugs-list
Bob Ippolito b...@redivi.com added the comment:
trunk fix for 2.7 is in r70702 -- unsure about how to port this to 3.1
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5584
Bob Ippolito b...@redivi.com added the comment:
I fixed two problems with this that didn't show up in the test suite, this
feature didn't work in load() and there was a problem with the pure python
code path because the Python scanner needed a small change. Unfortunately
I'm not sure how
Bob Ippolito b...@redivi.com added the comment:
Is this high priority? The pure-Python code paths don't even run in
cpython. I test them manually with simplejson by just deleting the
extension and then running the tests again. There doesn't seem to be a
very good way to do this sort of thing
Bob Ippolito b...@redivi.com added the comment:
I don't think the decorator approach would work for the doctests, it looks
like it could be an interesting approach though. I have a feeling that
it's going to have to be done in some kind of ugly subclass though, I'll
dig into unittest deeper
Bob Ippolito b...@redivi.com added the comment:
I believe that struct.error is just how it worked before 2.5
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1530559
Bob Ippolito b...@redivi.com added the comment:
I don't even recall where I had access to a FreeBSD 6.0 Alpha machine,
sorry.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1496032
Bob Ippolito added the comment:
simplejson v3.5.1 is probably a good target, let me know if there's anything
that you'd like me to merge back in from stdlib to make maintenance easier. I
haven't been tracking stdlib except when I've been added to issues
Bob Ippolito added the comment:
I agree with ebfe. It's a case that only comes up if you're writing your own
default handlers, and there's not a reasonable solution to avoid this issue.
You would've gotten a RuntimeError: maximum recursion depth exceeded if it
wasn't for the behavior of repr
Bob Ippolito added the comment:
As Chris Rebert mentioned, the JSON standards have adopted this (unsurprising)
behavior. Ruby hasn't, and I doubt Crockford has, but I think they're in the
minority at this point. JavaScript's own JSON implementation works the same way
json/simplejson does
Bob Ippolito added the comment:
In other words, I would consider this to be fixed by the documentation change
made elsewhere.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13212
Bob Ippolito added the comment:
This patch looks reasonable to me as-is.
With regard to Infinite and NaN number values are accepted and output;
there's an option for that (allow_nan=False in encoding,
parse_constant=some_function_that_raises in decoding). Since an exception can't
be raised
Bob Ippolito added the comment:
Good call, I was just doing a quick review of the patch in isolation. Now I
don't have anything at all to comment on :)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21514
Changes by Bob Ippolito b...@redivi.com:
--
assignee: bob.ippolito - rhettinger
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21514
___
___
Python
Bob Ippolito added the comment:
simplejson has had a use_decimal flag for output since 2.1.0 and has been
enabled by default since 2.2.0. simplejson 3.2.0 introduced a for_json argument
that checks objects for a method of that name for serialization.
https://github.com/simplejson/simplejson
Bob Ippolito added the comment:
I'm sure there's some hack that would allow you to preserve the input. I would
try using parse_float and have it return some object that preserves the string
and will be output in precisely the same way. It may need to be a Decimal
subclass. I'm traveling
Bob Ippolito added the comment:
Subclass Decimal and implement __str__ to return your own representation. Use
parse_float to use your Decimal subclass. Should work with simplejson, a
similar hack may be possible with the json module.
--
___
Python
Bob Ippolito added the comment:
I don't think it's reasonable to expect Decimal to always output precisely the
same string it was given. It's a waste of complexity and space and the only
time you would want this behavior is when you really should've left it
accessible as a string in the first
Bob Ippolito added the comment:
Yeah, that's the hack I was suggesting.
I suppose I don't see the point of having a protocol that normalizes *almost*
everything. Normalization should be all or nothing. Other options would be to
define the signature at the encoded byte level
Bob Ippolito added the comment:
Seems like a good idea to me, I'll make sure this gets in simplejson as well.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24518
Bob Ippolito added the comment:
On further investigation, simplejson has implemented this functionality under a
different name since 2.5.0 (2012-03-29).
If item_sort_key is a callable (not the default), then the output of
dictionaries will be sorted with it. The callable will be used like
Bob Ippolito added the comment:
This seems like a very reasonable proposal. It would be great if we could also
include a path in the error message (e.g. `obj[foo][1][bar]`) as well to
provide enough context to track down the error quickly
Bob Ippolito added the comment:
I would recommend a moratorium on new options until we have a plan to make the
usage of the JSON APIs simpler overall. It's accumulated too many options over
time. The real trouble is figuring out how to do this in a backwards compatible
way that does
Bob Ippolito added the comment:
I agree, in isolation it's a fine proposal, but the interface here is already a
bit too complex and the benefit is pretty minimal. When the size really does
matter, you can take care to set it correctly once and be done
Bob Ippolito added the comment:
Probably the best thing we could do here is to mirror the options available in
similar tools, such as jq: https://stedolan.github.io/jq/manual/#Invokingjq
The relevant options here would be:
--indent
--tab
--compact-output
--sort-keys
Bob Ippolito added the comment:
I agree with that sentiment. If we were to want to support this use case I
would rather put together a coherent way to augment the parsing/encoding of
anything than bolt it on to what we have.
--
___
Python tracker
Bob Ippolito added the comment:
Agreed, this does seem unnecessary. The library has been in active use for over
a decade, and this is the first time I've seen this request. I would recommend
preprocessing the data that you're going to encode if you have a need for this.
--
stage
Bob Ippolito added the comment:
I suppose I'm +0. I don't think this is particularly useful, but this is closer
to the ideal of just having a boolean option. We should probably also plan to
remove the documentation for what the type of separators is to give the
impression that COMPACT
Bob Ippolito added the comment:
That's not a very convincing argument. Python 2 only returns byte strings if
the input is a byte string and the contents of the string are all ASCII.
Facilitating that sort of behavior in 3 would probably cause more issues than
it solves
Bob Ippolito <b...@redivi.com> added the comment:
Generally speaking, parsing some things as decimal or datetime are schema
dependent. It's unlikely that you would want to parse every string that looks
enough like a decimal as a decimal, or that you would want to pay the cost of
ch
Bob Ippolito added the comment:
I think the best start would be to add a bit of documentation with an example
of how you could work with newline delimited json using the existing module
as-is. On the encoding side you need to ensure that it's a compact
representation without embedded
Bob Ippolito added the comment:
I suggested that each module would likely implement its own functions tailored
to that project's IO and error handling requirements. The implementation may
differ slightly depending on the protocol. This is consistent with how JSON is
typically dealt
Bob Ippolito added the comment:
I don't think that this has anything in particular to do with the json module,
at least it certainly shouldn't need any additional functionality from there.
YAML parsing isn't available in the stdlib last I checked, so that is probably
not really up
Bob Ippolito added the comment:
That's what the for_json method is in simplejson, it does not have widespread
usage.
You can implement that when encoding:
```
def json_default(obj):
try:
return obj.__json__()
except AttributeError:
raise TypeError("{} can not be
Bob Ippolito added the comment:
The trouble with having such a hook is that it would take precedence over any
customization you might want or need to do to satisfy the protocol you're
implementing. Other than the limited set of types that are part of the JSON
specification, there's
Bob Ippolito added the comment:
I would certainly reconsider it at this point, I think a bona fide ABC
*specific to JSON encoding* would be a good way to do it. simplejson has two
ways to do this, the `for_json` parameter which will use a `for_json()` method
on any object as the JSON
96 matches
Mail list logo
