You're changing the behavior of import. So if somebody else were to remove the seemingly unused `from jsonsempai import magic` the file would stop working as expected.

Non obvious "magic" code like that tends to be frowned on in general, and especially in the python community

Is it be useful? Or there are some alternatives to import JSON as a module as easy as this one does?

For files:

    import json
    with open("foo.json") as f:
        foo = json.load(f)

For strings:

    import json
    bar = '{"foo": "bar"}'
    foo = json.loads(bar)

Does that respect import search paths? Does the original?

There is no good reason to load json from import paths. Your import paths should contain code, assets, not configuration.

A JSON document might be an asset, such as static data. In fact, I'd much rather have a Python file as configuration and JSON as data than the opposite.

Does it respect import paths: no.

As for whether or not json-sempai does, I looked through the code and I am pretty sure the answer is yes.

Declaring pkg_resources is probably a better way to include static data files in your package but hey radical freedom and all that.

Do you have any good tutorial on how to use pkg_resources ? I use pathlib.Path(__file__).absolute().parent but it's not zip safe. Problem is, I can't wrap my head around pkg_resources and the docs don't help.

Yeah, docs are a bit fuzzy and I'm not exactly sure what the right answer is.

So there are actually two ways to go about it AFAIK and I'm not entirely sure which one is the best. One is to list files in MANIFEST.in and then access it via __file__, but I think this doesn't work if your module gets turned into an egg/wheel (it's for source dists).

On the other hand is using pkg_resources, where you declare the list of files in the package_data argument to setup in your setup.py. You can then get the contents of that file (not its path) by importing the pkg_resources package, which provides a lookup table of loaded resources. This [apparently] works for binary dists but not source dists (the opposite of MANIFEST).

I've used pkg_resources without issue myself, but it's possible I just have been lucky. In any event, here's a few links discussing the differences and also how to use pkg_resources:

http://stackoverflow.com/questions/7522250/how-to-include-pa...

http://blog.codekills.net/2011/07/15/lies,-more-lies-and-pyt...

http://peak.telecommunity.com/DevCenter/PythonEggs#accessing...

If you want an example, here's a package I made that uses pkg_resources (I make no promises that this is the right way to do it, but it works for me):

(setup.py, see line 10) https://github.com/jasonmhite/gefry2/blob/master/setup.py

(the data file I want to include) https://github.com/jasonmhite/gefry2/tree/master/gefry2/data

(where the code loads the data file, see line 67) https://github.com/jasonmhite/gefry2/blob/master/gefry2/mate...

Thanks

Cython does the same thing for ".pyx" files and I have to say it is very handy and works well.

Because it monkey patches the way imports work. The context manager isn't bad really, although there are probably more natural ways to create a python object with the same structure as a JSON file without abusing the import system.

Right. JSON is almost valid Python to begin with. Off the top of my head, the main differences are that JSON true needs to be True in Python (likewise with false/False, null/None). It's not that difficult.

It's also slightly stricter with syntax; you can't have extra ending commas. {'foo' : 1, 'bar' : 2,} is valid Python but not valid json.

Yes, I keep running into this. I leave trailing commas in my JSON as it evals fine in Python. Then my C++ code, using boost::property_tree chokes on it. property_tree also needs double quotes, not the single quotes in this example.

There's a module for this: json. The error messages might not be very good, but it does check for trailing commas.

To note: Python 3, due to the whole string vs unicode literals thing (\u)