On Mon, Mar 1, 2010 at 3:02 AM, Daniel Fetchinson fetchin...@googlemail.com
wrote:
Quick question: if JSON is too hard to manually edit, how can RSON be
any easier when it is a *superset* of JSON?
Well, Python is essentially a superset of JSON, with string escape handling
being ever so
All:
Finding .ini configuration files too limiting, JSON and XML to hard to
manually edit, and YAML too complex to parse quickly, I have started
work on a new configuration file parser.
I call the new format RSON (for Readable Serial Object Notation),
and it is designed to be a superset of JSON.
On Sun, Feb 28, 2010 at 6:29 PM, Benjamin Peterson benja...@python.org wrote:
In that case, it should live in the user space for several years. If
the community decides that it is an excellent format, then it should
be considered for inclusion in the stand library.
Agreed.
However, there are
On Sun, Feb 28, 2010 at 7:39 PM, Antoine Pitrou solip...@pitrou.net wrote:
In this case it is *at best* python-ideas material, or even
preferably comp.lang.python.
I was thinking about comp.lang.python at some point, but thought I
would try here first.
Just for the record, my only reaction
On Sun, Feb 28, 2010 at 7:51 PM, Antoine Pitrou solip...@pitrou.net wrote:
Well, a constructive approach would involve approaching projects
which have devised their own formats, so as to know what kind of
unified format they would be likely to accept (or not).
Trying to poll selected projects
This may or may not be relevant to 2.6 or 3.0 (because I don't have
those handy at the moment), but on 2.5 and earlier:
Python 2.5.2 (r252:60911, May 7 2008, 15:19:09)
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2
Type help, copyright, credits or license for more information.
print
On 3/16/07, Martin v. Löwis [EMAIL PROTECTED] wrote:
Assuming the current behavior is a bug (which I still believe to be
the case), in order to actually make use of the bug fix, you have to
pass the parameter. This will make your code break on old versions.
But, that's a GOOD thing. If you
On 3/16/07, Steve Holden [EMAIL PROTECTED] wrote:
Perhaps you'd like to remind me that backward compatibilty includes
the necessity to run new programs on old versions of Python, too?
Ahh, but you see, new programs are the easy part. You actually have
at least four choices of different levels
On 3/15/07, Steve Holden [EMAIL PROTECTED] wrote:
The fact remains that those who have used the existing functionality as
it is implemented and documented will, of this change isn't reverted,
have to make a gratuitous change to their currently working programs.
The worst part is, if they are
On 3/14/07, Phillip J. Eby [EMAIL PROTECTED] wrote:
This backwards-incompatible change is therefore contrary to policy and
should be reverted, pending a proper transition plan for the change (such
as introduction of an alternative API and deprecation of the existing one.)
I think the original
Please forgive me if this has already been discussed -- I only
recently started paying any attention to this list.
Many versions of python include new standard library modules that
could (or often do already) work fine with previous versions. Some of
the modules are brand-new, written explicitly
On 3/11/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Isn't this PEP 297?
Thanks for pointing that out. I looked for a relevant PEP, but didn't
notice this one. I think this is complementary, but (if I am reading
it correctly) it is not exactly the same. The alternate search path
is a
On 3/8/07, Tony Nelson [EMAIL PROTECTED] wrote:
At 2:16 PM -0500 3/8/07, Phillip J. Eby wrote:
The code in question was a type association handler that looked up loader
functions based on file extension. This was specifically convenient for
recognizing the difference between .htaccess files
13 matches
Mail list logo
