Choosing a name for simplejson
So simplejson is going to be added to the stdlib (this came down from up high, which is why there has not been more of a discussion here). That means we need to choose a name. Obviously 'json' would work, but I am not sure if there is something better. Remember, we want simple so that if someone goes, "I wonder if Python has a JSON module", they can easily find it (which means no crazy package names).
We might also act as quality control on the source code to make sure it is up to snuff based on PEP 8.
-Brett
On Thu, Apr 10, 2008 at 4:03 PM, Brett Cannon brett@python.org wrote:
So simplejson is going to be added to the stdlib (this came down from up high, which is why there has not been more of a discussion here). That means we need to choose a name. Obviously 'json' would work, but I am not sure if there is something better. Remember, we want simple so that if someone goes, "I wonder if Python has a JSON module", they can easily find it (which means no crazy package names).
+1 for "json" or "jsonlib". Simple is better.
We might also act as quality control on the source code to make sure it is up to snuff based on PEP 8.
I'll have a look.
-Brett _______________________________________________ stdlib-sig mailing list stdlib-sig@python.org http://mail.python.org/mailman/listinfo/stdlib-sig
On 10/04/2008, Benjamin Peterson musiccomposition@gmail.com wrote:
On Thu, Apr 10, 2008 at 4:03 PM, Brett Cannon brett@python.org wrote:
So simplejson is going to be added to the stdlib (this came down from up high, which is why there has not been more of a discussion here). That means we need to choose a name. Obviously 'json' would work, but I am not sure if there is something better. Remember, we want simple so that if someone goes, "I wonder if Python has a JSON module", they can easily find it (which means no crazy package names).
+1 for "json" or "jsonlib". Simple is better.
+1 for json. Let's not have yet another xxxlib format name...
Paul.
On 2008-04-10 23:09, Paul Moore wrote:
On 10/04/2008, Benjamin Peterson musiccomposition@gmail.com wrote:
On Thu, Apr 10, 2008 at 4:03 PM, Brett Cannon brett@python.org wrote:
So simplejson is going to be added to the stdlib (this came down from up high, which is why there has not been more of a discussion here). That means we need to choose a name. Obviously 'json' would work, but I am not sure if there is something better. Remember, we want simple so that if someone goes, "I wonder if Python has a JSON module", they can easily find it (which means no crazy package names).
+1 for "json" or "jsonlib". Simple is better.
+1 for json. Let's not have yet another xxxlib format name...
While that would be nice, I'm sure there a quite a few apps out there that already ship their own little version of a JSON library using that name. "jsonlib" already has an implementation:
http://pypi.python.org/pypi/jsonlib/
BTW: What's bad about "simplejson" ?
Oh, how I wished Python would finally get to use single package name for its std lib and put everything else under that name, e.g. "py". Then we could just name it "py.json" and be done with these issues once and for all.
On Thu, Apr 10, 2008 at 2:31 PM, M.-A. Lemburg mal@egenix.com wrote:
On 2008-04-10 23:09, Paul Moore wrote:
On 10/04/2008, Benjamin Peterson musiccomposition@gmail.com wrote:
On Thu, Apr 10, 2008 at 4:03 PM, Brett Cannon brett@python.org wrote:
So simplejson is going to be added to the stdlib (this came down from up high, which is why there has not been more of a discussion here). That means we need to choose a name. Obviously 'json' would work, but I am not sure if there is something better. Remember, we want simple so that if someone goes, "I wonder if Python has a JSON module", they can easily find it (which means no crazy package names).
+1 for "json" or "jsonlib". Simple is better.
+1 for json. Let's not have yet another xxxlib format name...
While that would be nice, I'm sure there a quite a few apps out there that already ship their own little version of a JSON library using that name. "jsonlib" already has an implementation:
http://pypi.python.org/pypi/jsonlib/
BTW: What's bad about "simplejson" ?
Longer than it needs to be.
Oh, how I wished Python would finally get to use single package name for its std lib and put everything else under that name, e.g. "py". Then we could just name it "py.json" and be done with these issues once and for all.
If you want to convince Guido to allow this then that's fine; I'm +0 on the idea myself.
-Brett
On 2008-04-10 23:52, Brett Cannon wrote:
On Thu, Apr 10, 2008 at 2:31 PM, M.-A. Lemburg mal@egenix.com wrote:
On 2008-04-10 23:09, Paul Moore wrote:
On 10/04/2008, Benjamin Peterson musiccomposition@gmail.com wrote:
On Thu, Apr 10, 2008 at 4:03 PM, Brett Cannon brett@python.org wrote:
So simplejson is going to be added to the stdlib (this came down from up high, which is why there has not been more of a discussion here). That means we need to choose a name. Obviously 'json' would work, but I am not sure if there is something better. Remember, we want simple so that if someone goes, "I wonder if Python has a JSON module", they can easily find it (which means no crazy package names).
+1 for "json" or "jsonlib". Simple is better.
+1 for json. Let's not have yet another xxxlib format name...
While that would be nice, I'm sure there a quite a few apps out there that already ship their own little version of a JSON library using that name. "jsonlib" already has an implementation:
http://pypi.python.org/pypi/jsonlib/
BTW: What's bad about "simplejson" ?
Longer than it needs to be.
Oh, how I wished Python would finally get to use single package name for its std lib and put everything else under that name, e.g. "py". Then we could just name it "py.json" and be done with these issues once and for all.
If you want to convince Guido to allow this then that's fine; I'm +0 on the idea myself.
In my experience, Guido has shown that he doesn't get convinced by someone pointing him at a problem - he has to run into the problem himself.
Now, Python is a community project and its user set is very diverse, so I'd like to see what the community thinks. If there's a tie, Guido can break it, but I don't really see why he should be the only one who's being asked.
M.-A. Lemburg schrieb:
In my experience, Guido has shown that he doesn't get convinced by someone pointing him at a problem - he has to run into the problem himself.
Now, Python is a community project and its user set is very diverse, so I'd like to see what the community thinks. If there's a tie, Guido can break it, but I don't really see why he should be the only one who's being asked.
We had the discussion on the Python general list a while ago. Guido and several other developers were against Java-like namespace packages for the stdlib.
Christian
On 2008-04-11 11:56, Christian Heimes wrote:
M.-A. Lemburg schrieb:
In my experience, Guido has shown that he doesn't get convinced by someone pointing him at a problem - he has to run into the problem himself.
Now, Python is a community project and its user set is very diverse, so I'd like to see what the community thinks. If there's a tie, Guido can break it, but I don't really see why he should be the only one who's being asked.
We had the discussion on the Python general list a while ago. Guido and several other developers were against Java-like namespace packages for the stdlib.
We've had such discussions on and off several times during the past 8-10 years. So far, the only arguments against moving the whole Python std lib under a single package (without deeper nesting) were the following:
* too much to write
* hard to change all the code out there
Now that we're going for a transition from 2.x to 3.x, the second argument no longer applies. 2to3.py can easily change the imports as necessary (just like it will for the stdlib reorg in general).
The first argument is not really a strong one, but more a personal preference. Using a Python package will make it easier for IDEs to provide auto-complete, so over time
On the plus side, we would finally have the freedom to choose any generic name we like for Python modules - without causing problems with existing code outside the std lib, e.g. all the *lib modules could have the "lib" removed.
And you can finally see whether a module came from the Python std lib or some other source right in the source file. Accidental sys.path overrides will no longer happen.
If I've missed any arguments against the py-package idea, please let me know.
Thanks,
On 11/04/2008, M.-A. Lemburg mal@egenix.com wrote:
If I've missed any arguments against the py-package idea, please let me know.
Nobody has the energy or enthusiasm to push it - write a PEP, create a 2to3 fixer, propose specific renames (ftplib -> py.ftp for example), gather opinions, summarise arguments, convince Guido, etc etc.
That's the killer.
Paul.
On 11/04/2008, at 07:42, Paul Moore wrote:
On 11/04/2008, M.-A. Lemburg mal@egenix.com wrote:
If I've missed any arguments against the py-package idea, please let me know.
Nobody has the energy or enthusiasm to push it - write a PEP, create a 2to3 fixer, propose specific renames (ftplib -> py.ftp for example), gather opinions, summarise arguments, convince Guido, etc etc.
If you do that I think most people would be +1 or at least +0 on it. If you think about it it is just a "py." more.
But please take a look at http://codespeak.net/py/dist/misc.html#the-py-std-hook if you are going to change that maybe this should go in also. Then you dont need import py.sys to just get py.sys.args in a simple script for example. And even in really big python project you get a lot of imports to just get one function that is going to be used once in the file.
-- Leonardo Santagada
On Fri, Apr 11, 2008 at 5:19 AM, Leonardo Santagada santagada@gmail.com wrote:
On 11/04/2008, at 07:42, Paul Moore wrote:
On 11/04/2008, M.-A. Lemburg mal@egenix.com wrote:
If I've missed any arguments against the py-package idea, please let me know.
Nobody has the energy or enthusiasm to push it - write a PEP, create a 2to3 fixer, propose specific renames (ftplib -> py.ftp for example), gather opinions, summarise arguments, convince Guido, etc etc.
If you do that I think most people would be +1 or at least +0 on it. If you think about it it is just a "py." more.
But please take a look at http://codespeak.net/py/dist/misc.html#the-py-std-hook if you are going to change that maybe this should go in also.
If you really want a "py." prefix, then trying to add anything else to the proposal is a bad idea. It's going to be an uphill battle as it is. Changing semantics at the same time will almost certainly make that battle impossible to win.
FWIW, -0 on the "py." prefix. I guess I'm in Guido's situation -- I haven't ever personally run into the situation where I needed it. I've never had the desire to name something similar to a stdlib module name -- probably because at the point when I might, I realize that the stdlib already has the module I want, named what I expected.
Steve
With the stricter distinction between absolute and relative imports, isn't all this discussion a bit obsolete ?
If you want to import the builtin "types" module: import types If you want to import the local "types" module: from . import types
I don't see the need for a "py" prefix.
On Fri, Apr 11, 2008 at 9:50 AM, Antoine Pitrou solipsis@pitrou.net wrote:
With the stricter distinction between absolute and relative imports, isn't all this discussion a bit obsolete ?
If you want to import the builtin "types" module: import types If you want to import the local "types" module: from . import types
I don't see the need for a "py" prefix.
But what if you want to install a third-party library that is named 'types'? ``import types`` will import either from the stdlib or the third-party library based on sys.path. The thinking for the top-level 'py' namespace is that this situation becomes (basically) impossible.
-Brett
On 2008-04-11 20:41, Brett Cannon wrote:
On Fri, Apr 11, 2008 at 9:50 AM, Antoine Pitrou solipsis@pitrou.net wrote:
With the stricter distinction between absolute and relative imports, isn't all this discussion a bit obsolete ?
If you want to import the builtin "types" module: import types If you want to import the local "types" module: from . import types
I don't see the need for a "py" prefix.
But what if you want to install a third-party library that is named 'types'? ``import types`` will import either from the stdlib or the third-party library based on sys.path. The thinking for the top-level 'py' namespace is that this situation becomes (basically) impossible.
Exactly.
The problem is not related to relative vs. absolute imports, it's all about sys.path.
Detecting such situations gets even harder once you start to use eggs, since they hide away the module names they use insider their ZIP archives.
Also note that this is not so much a problem for the existing set of std lib modules since 3rd party packages will of course try to not conflict with these known names.
However, it becomes an issue as soon as new modules get added to the std lib or existing ones are renamed.
In such a situation, you have the case that a conflicting module will already be in use (possibly buried inside some egg on sys.path) and changing all the code that relies on this conflicting module will not necessarily be easy.
The "py." prefix would solve these issues once and for all.
Note that these situations are not made up. You can run into such situations quite easily, e.g. if you run python in a directory that happens to have a package called "test" with an __init__.py in it, you suddenly cannot access the Python stdlib test package anymore.
Le vendredi 11 avril 2008 à 22:01 +0200, M.-A. Lemburg a écrit :
In such a situation, you have the case that a conflicting module will already be in use (possibly buried inside some egg on sys.path) and changing all the code that relies on this conflicting module will not necessarily be easy.
Ok, I understand. Sorry for the noise.
Regards
Antoine.
On 11/04/2008, at 12:26, Steven Bethard wrote:
On Fri, Apr 11, 2008 at 5:19 AM, Leonardo Santagada <santagada@gmail.com
wrote: But please take a look at http://codespeak.net/py/dist/misc.html#the-py-std-hook if you are going to change that maybe this should go in also.
If you really want a "py." prefix, then trying to add anything else to the proposal is a bad idea. It's going to be an uphill battle as it is. Changing semantics at the same time will almost certainly make that battle impossible to win.
Yes yes you are right sorry to propose that... But probably between the two I prefer the py.std hack than to have a "py." for the stdlib.
[] -- Leonardo Santagada
On Thu, Apr 10, 2008 at 7:09 PM, Paul Moore p.f.moore@gmail.com wrote:
On 10/04/2008, Benjamin Peterson musiccomposition@gmail.com wrote:
On Thu, Apr 10, 2008 at 4:03 PM, Brett Cannon brett@python.org wrote:
So simplejson is going to be added to the stdlib (this came down from up high, which is why there has not been more of a discussion here). That means we need to choose a name. Obviously 'json' would work,
but
I am not sure if there is something better. Remember, we want simple so that if someone goes, "I wonder if Python has a JSON module",
they
can easily find it (which means no crazy package names).
+1 for "json" or "jsonlib". Simple is better.
+1 for json. Let's not have yet another xxxlib format name...
+1 for json as well. I agree the lib suffix should be avoided whenever possible.
Paul. _______________________________________________ stdlib-sig mailing list stdlib-sig@python.org http://mail.python.org/mailman/listinfo/stdlib-sig
On Thu, Apr 10, 2008 at 2:03 PM, Brett Cannon brett@python.org wrote:
So simplejson is going to be added to the stdlib (this came down from up high, which is why there has not been more of a discussion here).
Do you have a link for this? Last I knew, discussion on which JSON library to include were still ongoing in python-web-sig.
participants (10)
-
Antoine Pitrou -
Benjamin Peterson -
Brett Cannon -
Christian Heimes -
John Millikin -
Leonardo Santagada -
M.-A. Lemburg -
Paul Moore -
Quentin Gallet-Gilles -
Steven Bethard