ijson.common.items removed in 3.0 [was: Unable to use items with event generator] about ijson HOT 12 CLOSED

On the contrary, I had never thought myself of such a use case, but can definitely see the appeal of it (and supporting it only makes the package better). I already have a solution, so if you give me a couple of minutes I'll please ask you to try it out for me, thanks.

from ijson.

Great, I'll be making a new release tomorrow or the day after then; I'll be closing this issue for now.

from ijson.

3.0.1 released; I also realised the MacOS wheels were incorrect for 3.0, they should be correct now.

from ijson.

Ah neat, lemme see if I can check this before lunch (CEST / +0200 here :)). Should be doable today at least, will post results!

from ijson.

Could I just confirm you are not talking about ijson.items but actually about ijson.common.items? The former is what each backend, and the top-level ijson package offers, and has always taken a file-like object, while the latter was a building block used by most backends to implement their items function. In fact I'd suspect the code example you posted above might not actually work as you expect even in 2.6.1, the latest stable release.

With the redesign of ijson in 3.0 the behaviour of ijson.items has been fully maintained, while ijson.common.items was removed (but it was never properly documented, so I didn't think people were using it). The use case you expose is pretty valid though so it would make sense to re-enable it. Let me have a think about it and will post back.

from ijson.

Ah, my bad, I'm using ijson.common.items indeed. Not sure how I found that way back, but it fit(s) the data and what I wanted with it very well :)

Thanks for getting back so quickly, and thanks for acknowledging my use case, guess I'm not doing something thoroughly out of ijson's scope :)

from ijson.

OK, that was more than a few minutes, I was just making sure tests were properly added.

Please have a look at the common_functions branch and let me know if that works. The branch re-introduces the common.items, commons.kvitems and common.parse functions like they were in previous ijson versions. In principle I'd like to move these into backend-specific functions (otherwise there's some performance penalty depending on your backend), but for the time being this should be OK, and should reproduce exactly what we had in the 2.X series.

from ijson.

Neat, I can confirm this works in both all of my unit tests and a small practise run in the real world without changing a single line of code; awesome :D

from ijson.

@akaIDIOT I can't think of other way of contacting, so it goes here...

I'm ready to cut a new version 3.1 of ijson, where the ijson.common.* functions are now marked as deprecated, as you can now use the ijson.* functions directly to handle your use case (i.e., you should be able to do ijson.items(events, ....) instead of ijson.common.items(events, ....)). Would you mind giving this a quick try when possible? All changes are in the latest master branch. Performance should remain as usual, if not actually faster. Thanks in advance, and hopefully everything will work as expected!

from ijson.

Seems that still works fine after from ijson import items. Figuring out exactly what "items" has been imported is a bit tricky with the way it's being patched into the module, but the unmodified code throws deprecation warnings now, so I'm guessing that proves what we needed to know ;)

I'd be happy to test things in the future should you want me to. Mentions on GitHub work, though other routes may be better without reusing a related issue :D

from ijson.

Seems that still works fine after from ijson import items [...]

Awesome! I have unit tests checking that this worked, but I wanted to make sure with the real-world usage you have. I'll prepare a new 3.1 release then.

[...] the unmodified code throws deprecation warnings now, so I'm guessing that proves what we needed to know ;)

yeap, that sounds about right

Mentions on GitHub work, though other routes may be better without reusing a related issue :D

Yeah, sorry about that, I tried a bit but couldn't find any other way of contacting you really (GitHub doesn't have a direct message mechanism). Next time maybe I'll open an issue in one of your repos ;)

from ijson.

Mentions on GitHub work, though other routes may be better without reusing a related issue :D

Yeah, sorry about that, I tried a bit but couldn't find any other way of contacting you really (GitHub doesn't have a direct message mechanism). Next time maybe I'll open an issue in one of your repos ;)

Nah that's alright, I appreciate the effort :) I use the same nickname on freenode IRC, and an email could work too. The project I'm ijson for isn't on github, sadly, we'll find ways to make it all work :) Thanks for checking in any case ;)

from ijson.