Re: [Python-Dev] Draft PEP on RSON configuration file format
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 slightly different, and using True instead of true, False instead of false, and None instead of null. YMMV, but I find it possible, even probable, to write Python that is far easier to edit than JSON, and in fact, I have used Python for configuration files that are only to be edited by programmers or other technical types. Regards, Pat ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Draft PEP on RSON configuration file format
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. I would love for it to be considered valuable enough to be a part of the standard library, but even if that does not come to pass, I would be very interested in feedback to help me polish the specification, and then possibly help for implementation and testing. The documentation is in rst PEP form, at: http://rson.googlecode.com/svn/trunk/doc/draftpep.txt Thanks and best regards, Pat ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Draft PEP on RSON configuration file format
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 too many things which became de facto standards without community input this way. PEP 1 itself says: Reference Implementation -- The reference implementation must be completed before any PEP is given status Final, but it need not be completed before the PEP is accepted. It is better to finish the specification and rationale first and reach consensus on it before writing code. So, I do not mind the code sitting outside the standard library, and the PEP not reaching Final for several years, but I do believe that the PEP process is itself a really good way to build a better mousetrap by consensus. If you do not care to participate in the building of this particular mousetrap, that is OK, too. Regards, Pat ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Draft PEP on RSON configuration file format
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 when giving the PEP a glance was yet another configuration file format - yawn. I suppose I have that sort of reaction about areas I am not interested in, as well, but currently I am deeply interested in configuration files due to my circumstances. In any case, the observation that there are already several preexisting file formats used for configuration is certainly covered in the PEP draft, but if you have anything constructive to add *about* configuration file formats, I would certainly welcome the input. Best regards, Pat ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Draft PEP on RSON configuration file format
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 which have configuration files may or may not be a constructive approach. Most projects which have predefined formats are unlikely to change, unless there is standardization on a new format. It is very much a chicken and egg problem, although I agree with (and have implemented) the suggestion that I discuss this on python-list. Having said that, one of the reasons I wrote the PEP and am working on a parser is because of a few projects I use and/or am personally involved in. For example, rst2pdf stylesheets are in JSON, e.g. http://rst2pdf.googlecode.com/svn/trunk/rst2pdf/styles/styles.json Now, we're all programmers here, and we can read this, and can even modify it, but it is easy to get wrong, and very verbose with lots of syntax gotchas. For example, unlike Python, JSON won't even let you have a trailing comma. But JSON *is* a great format, and RSON (like YAML) is designed to parse properly formatted JSON, so the goal is that any project which uses JSON could use RSON as a drop-in replacement, and then update its configuration data. Of course, it is extremely easy (hence your yawn) to create a new configuration format, even if it is specified that it is upwards compatible with JSON. The trick is to create the *correct* new format, that at least some people can agree on. In order to do this, I have chosen to poll, not preexisting projects, which have entrenched configuration data and a reluctance to change, but brand new projects which haven't been invented yet. Many of the inventors of those projects hang out on python-dev, so this seemed like a reasonable place to do polling. As I tried to make clear, I will not be too disappointed if I do not come up with something worthy of the standard library for a long time (if ever), but the PEP process is very valuable, and I would like to start off on the right foot by soliciting feedback before I do too much coding. Sorry if it feels like spam; this is my last message on the matter until and unless somebody wants to constructively discuss the actual contents of the PEP. Please feel free to email me privately if you don't want to clutter up this list. Thanks and best regards, Pat ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] eval() accepts compiled 'exec' statements
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 eval(compile('print It works\n', '', 'exec'))
It works
None
Personally, I'm absolutely fine with this (because I have a use case,
naturally), but eval() does work differently for compiled vs
non-compiled objects, and this behavior doesn't match what the doc at
http://docs.python.org/lib/built-in-funcs.html says, namely This
function can also be used to execute arbitrary code objects (such as
those created by compile()). In this case pass a code object instead
of a string. The code object must have been compiled passing 'eval' as
the kind argument.
That doc statement is, itself, contradictory. How can it be an
arbitrary code object if it must have been compiled using 'eval'?
Perhaps all that is meant is In order to return a result other than
None to eval's caller, the code object must have been compiled
passing 'eval' as the kind argument.
So, either the code or the doc should be fixed. I would vote +1 for
fixing the doc to match the code, but then I'm the sort of
dysfunctional programmer who sometimes has a use-case for expressions
with side-effects.
Thanks,
Pat
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal to revert r54204 (splitext change)
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 don't use the flags approach, your code will silently fail on the old versions. Pat ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal to revert r54204 (splitext change)
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 of backward compatibility: 1) If you are absolutely sure that the code in your program will never be used to work with filenames with leading dots, you are already finished! (Note that this goal is much easier to achieve if you don't release the source, or at least write it so badly that nobody will want to reuse the code.) 2) If you think that most users of your program won't use filenames with leading dots, and you don't plan on supporting it after a year or so, just make sure it works with 2.5. 3) Conversely, if you're not that bothered about leading dots, and don't think you'll have all the bugs out of your program for a year or so anyway, just wait for 2.6. (All the cool potential users of your program will be on the bleeding edge, anyway.) 4) Finally, if you're one of those Luddite sticklers who wants to try to ruin everybody's job security by writing code that works right now and doesn't need to be touched later, just write your own version of this function. I would have suggested that you could reuse the underlying functionality in conjunction with a version check, but it has been pointed out that the existence of tests and docstrings which perfectly match the code is no impediment to change, so Philip might get mad enough to change it back for 3.1, and then your version check would be obsolete. Then I can stop wasting everyone's time. Even though I am no fonder of code breakage than I was. Fortunately, for new code (at least for this particular change!), you don't have to worry about breakage. I'm sure this discussion has been so indelibly etched into your brain that you won't forget to check your filename management functions very carefully. Sorry, were you being sarcastic? I didn't realize that. Or am I prevaricating again? Regards, Pat ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal to revert r54204 (splitext change)
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 relying on that specific behavior and have to rely on the new specific behavior, and want to support old and new versions of Python, they are potentially left with some very unattractive options -- check the Python version to figure out how splitext works, or just roll their own and stop calling splitext entirely, because its behavior is not consistent across versions. Because some immoderate language has been used in this thread I would like to underline that these remarks are not directed personally at Martin, for whom I have the utmost respect as a developer, but at the lack of process that allows circumstances like this to arise. I second this sentiment. Regards, Pat ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Proposal to revert r54204 (splitext change)
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 behavior is simpler, thus easier to document and understand, but even if we want to change the behavior, the fact is that the new behavior can break some old code. As I mentioned in an earlier email, I don't think this is a corner case -- I bet there is a ton of Python code out there which deals with hidden files and directories. Pat ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Backports of standard library modules
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 for the standard library, and others are preexisting modules that, by community consensus, are added to the library. It seems that once a new library module is added, if it doesn't rely heavily on new core language features, it should also be added for previous versions. Obviously, it doesn't make sense to re-release an old version of Python just because a new library is available (or even to include the new library in the old version), but it might make sense to have a separate package of extras or backported modules that is re-released for prior versions whenever a new (compatible) module is added to the standard library. Although it is often quite easy to find and download a module for use with a prior version of Python, it would be really convenient if all of these modules were bundled up together and available as a single download, especially when it comes to Windows users and extension modules. If this seems useful to others, I could try to start a PEP on how the process would work (but since I'm fairly new, it would be great if someone could help out a bit by validating my verbiage against some of the process requirements). Regards, Pat ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Backports of standard library modules
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 necessary part of what I am suggesting, but the meat of my proposal (which Brett correctly discerned would require ongoing effort :) is that, when I go to the downloads page for Python 2.3, in addition to downloading Python, I could download all the compatible libraries which were included in later versions as a single installable file. When 2.6 comes out, this extras package would be upgraded to include any new modules in 2.6. Not a lot of fun for people who live on the bleeding edge, but very useful for people who are stuck with an older version for political or other reasons. Regards, Pat ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] splitext('.cshrc')
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 and other dotfiles that might appear in a web directory tree -- e.g. .htpasswd. The proposed change of splitext() would break that determination, because .htpasswd and .htaccess would both be considered files with empty extensions, and would be handled by the empty extension handler. So, .htaccess and foo.htaccess should be treated the same way? Is that what Apache does? I've never personally used foo.htaccess, but I have had files named, e.g. test1.htaccess, or backup.htaccess. And I don't know, but I assume a foo.htaccess would be an older or test version of a .htaccess file. So, my usecases say, yes, they should be treated the same. Regards, Pat ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
