Re: [Python-Dev] "DOS" error codes, WindowsError, and errno
Mark Hammond wrote: > I guess "too late" is purely a judgement call about breaking existing code. > One thing to our advantage is that I believe the most common errno > explicitly checked for will be ENOENT, which happily has the same value as > ERROR_FILE_NOT_FOUND. [Actually, checking 2 *or* 3 (ERROR_PATH_NOT_FOUND) > is also common - but ESRCH==3, which sounds reasonable] The strerror for ESRCH is "No such process", which isn't really that reasonable. Breakage would occur, because people might currently check for ENOENT (or any other specific error code); if they don't see that specific error code, they will assume it is a "real" error. That said: I would actually expect that it is infrequent that people do look at the errno of a WindowsError, so breakage might be small. > Another way forward may be to issue a warning whenever '.errno' or '[0]' is > referenced from WindowsError, noting that the semantics are soon to change, > and to use the new attribute if they really do want a win32 error code. I'm > not sure how practical that is though... It would need to get suppressed when the value is merely displayed, atleast in the default __str__ implementation. Regards, Martin ___ 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] "DOS" error codes, WindowsError, and errno
Guido van Rossum wrote: > WindowsError should have used a different name for the Windows-native > error code, so we could have defined both separately without > confusion. > > Is it too late to change WindowsError in that way? We could define a different exception, say, Win32Error which inherits from OSError, and has a POSIX errno in the errno attribute, and also an additional attribute win32_error. We could then stop raising WindowsError. So code that expects WindowsError will never see it, but will see OSError instead (which it also should handle if it was written portable). Or we could just break the errno value in WindowsError, which would make code that catches WindowsError continue to work, but break code that looks for specific errno values in WindowsError. Code aiming for backwards compatibility should then write except WindowsError, e: try: windows_error = e.windows_error except NameError: # Python 2.4 and earlier windows_error = e.errno As for naming, I would like to avoid naming new things Win32: Microsoft just changed the name of the API to "Windows API" (pointing out that it isn't necessarily 32 bits anymore). Regards, Martin ___ 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] from __future__ syntax changed
[Guido van Rossum] > It looks like the syntax for "from __future__ import ..." changes in > Python 2.5. I was playing around with Cheetah, and it stumbled over a > file with the following structure: > > # comments > """ docstring """ > __author__ = "..." > __version__ = "..." > from __future__ import generators > > Python 2.2 throug 2.4 accept this fine. > > Perhaps the AST tree enforces stricter syntax for what can precede a > future statement? I think this should be fixed. Peculiar. It wasn't intended that be allowed; PEP 236 spelled this out: In addition, all future_statments must appear near the top of the module. The only lines that can appear before a future_statement are: + The module docstring (if any). + Comments. + Blank lines. + Other future_statements. That isn't frivolous, since a __future__ gimmick may affect the legality of binding statements (as in your example) or other import statements, etc -- it was deliberate that only blank lines, comments and (maybe) a docstring could appear before the first future statment. I'd call this a bug in 2.2-2.4. Note too that Tools/scripts/cleanfuture.py in 2.4 doesn't change that example, because it doesn't believe it contains any __future__ statements (cleanfuture.py follows the PEP's syntax). ___ 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] "DOS" error codes, WindowsError, and errno
Guido: > What a mess. :-( > > WindowsError should have used a different name for the Windows-native > error code, so we could have defined both separately without > confusion. > > Is it too late to change WindowsError in that way? I guess "too late" is purely a judgement call about breaking existing code. One thing to our advantage is that I believe the most common errno explicitly checked for will be ENOENT, which happily has the same value as ERROR_FILE_NOT_FOUND. [Actually, checking 2 *or* 3 (ERROR_PATH_NOT_FOUND) is also common - but ESRCH==3, which sounds reasonable] Another way forward may be to issue a warning whenever '.errno' or '[0]' is referenced from WindowsError, noting that the semantics are soon to change, and to use the new attribute if they really do want a win32 error code. I'm not sure how practical that is though... Mark > > Unhelpfully, > > --Guido > > On 1/30/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > > I have a new implementation of stat/fstat/wstat which directly uses > > Win32 API, rather than using msvcrt. This works fine so far, except > > that error handling turns out to be tricky. > > > > mscvcrt maps errors (GetLastError()) into errno.h values, and also > > preserves the original error code in _doserrno. Currently, stat() > > will raise OSError, with errno set to the errno.h value. > > > > Because the Win32 error codes are much more fine-grained, this > > conversion loses information. Python raises WindowsError in > > some cases (e.g. os.listdir); WindowsError inherits from OSError, > > but the errno attribute now must be interpreted as a Win32 error. > > This is unfortunate, because the values overlap, and somebody > > handling OSError might confuse the error codes for errno.h > > (msvcrt) values. > > > > So what should I do in the new stat implementation? Try to map > > error codes also? Raise WindowsErrors instead? Do something else > > entirely? > > ___ 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] from __future__ syntax changed
It looks like the syntax for "from __future__ import ..." changes in Python 2.5. I was playing around with Cheetah, and it stumbled over a file with the following structure: # comments """ docstring """ __author__ = "..." __version__ = "..." from __future__ import generators Python 2.2 throug 2.4 accept this fine. Perhaps the AST tree enforces stricter syntax for what can precede a future statement? I think this should be fixed. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] "DOS" error codes, WindowsError, and errno
What a mess. :-( WindowsError should have used a different name for the Windows-native error code, so we could have defined both separately without confusion. Is it too late to change WindowsError in that way? Unhelpfully, --Guido On 1/30/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > I have a new implementation of stat/fstat/wstat which directly uses > Win32 API, rather than using msvcrt. This works fine so far, except > that error handling turns out to be tricky. > > mscvcrt maps errors (GetLastError()) into errno.h values, and also > preserves the original error code in _doserrno. Currently, stat() > will raise OSError, with errno set to the errno.h value. > > Because the Win32 error codes are much more fine-grained, this > conversion loses information. Python raises WindowsError in > some cases (e.g. os.listdir); WindowsError inherits from OSError, > but the errno attribute now must be interpreted as a Win32 error. > This is unfortunate, because the values overlap, and somebody > handling OSError might confuse the error codes for errno.h > (msvcrt) values. > > So what should I do in the new stat implementation? Try to map > error codes also? Raise WindowsErrors instead? Do something else > entirely? > > Comments appreciated. > > Regards, > Martin > ___ > 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/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] "DOS" error codes, WindowsError, and errno
I have a new implementation of stat/fstat/wstat which directly uses Win32 API, rather than using msvcrt. This works fine so far, except that error handling turns out to be tricky. mscvcrt maps errors (GetLastError()) into errno.h values, and also preserves the original error code in _doserrno. Currently, stat() will raise OSError, with errno set to the errno.h value. Because the Win32 error codes are much more fine-grained, this conversion loses information. Python raises WindowsError in some cases (e.g. os.listdir); WindowsError inherits from OSError, but the errno attribute now must be interpreted as a Win32 error. This is unfortunate, because the values overlap, and somebody handling OSError might confuse the error codes for errno.h (msvcrt) values. So what should I do in the new stat implementation? Try to map error codes also? Raise WindowsErrors instead? Do something else entirely? Comments appreciated. Regards, Martin ___ 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: python-dev Summary for 2006-01-01 through 2006-01-15
Anthony Baxter wrote: > Rather than the back-n-forth about what the FSF might or might not do, > can we just ask them for an official opinion and settle the matter? We can ask, sure. Whether this settles the matter depends on the answer. Regards, Martin ___ 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] Extension to ConfigParser
Guido van Rossum wrote: > On 1/30/06, Michael Foord <[EMAIL PROTECTED]> wrote: > >> I have a feeling that for many complex applications the developer is the >> user. Agreed that giving complex configuration data along with program >> data to the end-user is not good. >> >> Despite this, data storage that needs to be edited by developers and >> system administration is a very common usage. >> >> I'm saying that for this purpose (up to a point) an INI file like syntax >> is much *better* than XML. >> > > Sure. But for the same reasons, arbitrary nesting is probably bad. > > Interesting. It's one of the most frequent complaints (lack of nesting) I hear about ConfigParser. I guess I hang out in different circles. I still think it's a convenient way of grouping related options. Breaking them out into separate files is another way. >> I'm not really sure there is such a clear distinction. Especially for >> programs without a GUI, things like IP addresses, network details, paths >> to data files, plugged in components, device names, (etc) seem to be both. >> > > Just try to keep it simple. > > I still think it's a typical programmer's mistake to assume that > there's no clear distinction. For a user who's looking to change one > of the three simple properties that make sense for him to configure, > having to hunt these down in a file containing hundreds of stuff she > shouldn't tuch is a pain, plus there's the risk that an occasional > slip of the finger causes damage to stuff they don't understand. > > Right, I guess I'm still thinking more of the developer than user. For end-user simpler is definitely better. I still see use cases for ConfigObj where complex editable data (relatively - not database record sets) needs to be stored, and COnfigObj syntax is preferable to XML. > [snip..] >> Anyway - I modify my statement accordingly. For accessing configuration >> type data, the mapping protocol is an intuitive match. Named members >> mapping to values. Whether this is done via subclassing dict is an >> implementation detail. (Although I guess it implies that the full >> dictionary API will be available and you seem to be saying that you >> would rather that *only* relevant methods are available). >> > > I can see several improvements on the dict protocol. For example, a > handy API would be soemthing that produces a default value that is > specific to the key you are requesting. Using dict.get(key, default) > has the problem that if you ever decide to change the default you'll > have to modify every place that references it. If would be nice if you > could use dict.get(key) or even dict[key] and it gave you a default > that was specified once when the the file was read. We do this through the schema. You specify a default value for keys (optionally). This is supplied if the value is missing, but isn't written out again unless modified. For a *simpler* case (no possibility of a write) you can just merge in two config files, user data over the defaults. It doesn't keep a track of which file values come from though (your use case below). > Another idea: have > a list of multiple dict objects representing different config files > (e.g. ./.appconfig, ../appconfig, ../../appconfig, ..., ~/.appconfig, > /etc/appconfig, /opt/app/config). The dict semantics get in the way > when making changes -- which file should be updated? > > Hmmm all in all, I guess this is no. ConfigObj is fine as a separate module, and it's features are well used - so to that extent the status quo is fine. Have we got anywhere on an updated spec for ConfigParser replacement/enhancement ? Suggested features seem to include : * Round tripping (preserving order and possibly comments) (http://python.org/sf/1410680 maybe) * Mapping protocol for access is not a bad idea * List values seem a no brainer good idea to me * Better support for default values * Keeping track of values from multiple files, and writing changed values to the correct file We haven't discussed unicode of course, seems like a good idea for a text format. (It was one of the motivations for an alternative implementation Dict4ini.) I'd also like to see values allowed without a section. Flat config files with a few values are appropriate for many applications. (Maybe section=None to access, this was the approach for ConfigObj 3). Maybe the shooutout needs an update. All the best, Michael Foord > -- > --Guido van Rossum (home page: http://www.python.org/~guido/) > > ___ 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] Extension to ConfigParser
[Guido van Rossum] > What would break if we rewrote the save functionality to produce a > predictable order? As a reminder to anyone interested, there are three patches on SF that provide this (each in a different way): ConfigParser to accept a custom dict to allow ordering http://python.org/sf/1371075 Adds an optional argument to the constructor, the value of which will be the class used to store the configuration data (so that a third- party order-preserving dictionary class can be used). ConfigParser to save with order http://python.org/sf/1399309 Does a sort() of the sections and options before writing them. Add 'surgical editing' to ConfigParser http://python.org/sf/1410680 Adds an update_file method (no other changes) that updates the given file to match the current configuration, preserving blank lines, comments, and order. [Disclaimer: this is my patch] =Tony.Meyer ___ 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] Extension to ConfigParser
On 1/30/06, Michael Foord <[EMAIL PROTECTED]> wrote: > I have a feeling that for many complex applications the developer is the > user. Agreed that giving complex configuration data along with program > data to the end-user is not good. > > Despite this, data storage that needs to be edited by developers and > system administration is a very common usage. > > I'm saying that for this purpose (up to a point) an INI file like syntax > is much *better* than XML. Sure. But for the same reasons, arbitrary nesting is probably bad. > I'm not really sure there is such a clear distinction. Especially for > programs without a GUI, things like IP addresses, network details, paths > to data files, plugged in components, device names, (etc) seem to be both. Just try to keep it simple. I still think it's a typical programmer's mistake to assume that there's no clear distinction. For a user who's looking to change one of the three simple properties that make sense for him to configure, having to hunt these down in a file containing hundreds of stuff she shouldn't tuch is a pain, plus there's the risk that an occasional slip of the finger causes damage to stuff they don't understand. > [snip...] > Mapping protocol is fine. Subclassing dict has the advantage that some > aspects of the API are already implemented in C. And many you don't need. You'll never be able to change the API because it's constrained by all existing uses, which means every dict API you've never heard of. If you're using this so much that speed's an issue perhaps you're overusing it. > Anyway - I modify my statement accordingly. For accessing configuration > type data, the mapping protocol is an intuitive match. Named members > mapping to values. Whether this is done via subclassing dict is an > implementation detail. (Although I guess it implies that the full > dictionary API will be available and you seem to be saying that you > would rather that *only* relevant methods are available). I can see several improvements on the dict protocol. For example, a handy API would be soemthing that produces a default value that is specific to the key you are requesting. Using dict.get(key, default) has the problem that if you ever decide to change the default you'll have to modify every place that references it. If would be nice if you could use dict.get(key) or even dict[key] and it gave you a default that was specified once when the the file was read. Another idea: have a list of multiple dict objects representing different config files (e.g. ./.appconfig, ../appconfig, ../../appconfig, ..., ~/.appconfig, /etc/appconfig, /opt/app/config). The dict semantics get in the way when making changes -- which file should be updated? -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] Extension to ConfigParser
[Guido] >> What's so bad about ConfigParser? [Skip Montanaro] > It's my opinion that ConfigParser should stay pretty much as it is > other > than perhaps adding round trip capability. [...] > If we want more sophisticated functionality a new module should be > written, > or one of the existing shootout candidates on the Wiki should be > chosen and perhaps > enhanced. +1. =Tony.Meyer ___ 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] Extension to ConfigParser
Guido van Rossum wrote: > > On 1/30/06, Michael Foord <[EMAIL PROTECTED]> wrote: > >> But like it or not, configuration files are often used to store data >> about what a program does - not just the UI options. Storing this in a >> human readable and editable format is of great advantage. >> >> Yes, a lot of the entries will never be modified by a user - but many >> will need to be edited and read by a developer. In a production >> environment importing from python modules is not likely to be safe. >> > > Ah. This definitely isn't what ConfigParser was meant to do. I'd think > for this you should use some kind of XML pickle though. That's > horrible if end users must edit it, but great for saving > near-arbitrary persistent data in a readable and occasionally editable > (for the developer) form. > > You should probably not mix the end user config data with the > program's persistent store. > > I have a feeling that for many complex applications the developer is the user. Agreed that giving complex configuration data along with program data to the end-user is not good. Despite this, data storage that needs to be edited by developers and system administration is a very common usage. I'm saying that for this purpose (up to a point) an INI file like syntax is much *better* than XML. >> I don't dislike the INI format. ``key = value`` is intuitive. Nesting of >> sections is a logical extension that provides additional flexibility >> without breaking backwards compatibility. It needn't be added >> complexity, because you don't need to use it. There are plenty of people >> who will though. >> > > And I'm trying to say that (for config files) they probably shouldn't, > because most of their users won't understand it. Of course this > doesn't apply to your use case, so maybe we're just violently agreeing > -- except you seem to be confusing matters by talking about > "configuration" (which suggests end-user-editable) when you really > mean "persistent state" (which is under full program control). > > I'm not really sure there is such a clear distinction. Especially for programs without a GUI, things like IP addresses, network details, paths to data files, plugged in components, device names, (etc) seem to be both. >>> Regarding the claim that dicts are the best kind of API for >>> configuration, I disagree [snip..] >> Hey, since Python 2.2 some folk put a lot of >> work in allowing us to subclass dict. ;-) >> > > Yeah, but that was more as a matter of principle than to encourage that use... > > Narrow APIs are typically better than wide APIs, and the dict API is > the ultimate wide API. (I guess strings are just as bad; I haven't > contributed to that thread yet but I think the new path module should > not inherit from str or unicode either.) > > I am a firm fan of the new path module but agnostic on whether it should inherit from basestring in some way. Wrong thread though. [snip...] > > Anyway, we have a name for this -- we call it the "mapping protocol". > In most cases it's better to implement a protocol than inherit a > standard object. (This is perhaps unique to Python -- other OO > languages often encourage inheritance, so I can understand the > confusion.) > > Mapping protocol is fine. Subclassing dict has the advantage that some aspects of the API are already implemented in C. Anyway - I modify my statement accordingly. For accessing configuration type data, the mapping protocol is an intuitive match. Named members mapping to values. Whether this is done via subclassing dict is an implementation detail. (Although I guess it implies that the full dictionary API will be available and you seem to be saying that you would rather that *only* relevant methods are available). All the best, Uhm... Michael Foord I guess ___ 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] Extension to ConfigParser
Guido van Rossum wrote: > Ah. This definitely isn't what ConfigParser was meant to do. I'd think > for this you should use some kind of XML pickle though. That's > horrible if end users must edit it, but great for saving > near-arbitrary persistent data in a readable and occasionally editable > (for the developer) form. fwiw, I've *never* used INI files to store program state, and I've never used the save support in ConfigParser. on the other hand, earlier today, Firefox messed up my user profile, and I'm not sure I had managed to sort that out if they hadn't used an INI file to keep track of available profiles... (especially not if they'd used Mork ;-) ___ 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] Extension to ConfigParser
> Guido van Rossum wrote: > > Aha. I am beginning to understand. When people say "ConfigParser is > > hopeless" they mean ".INI files are hopeless". I happen to disagree. > > (There's also a meme that says that every aspect of an app should be > > configurable. I disagree with that too. As Joel Spolski points out in > > his book on UI design, most configuration options are signs of > > indecisive developers, and most users never change the defaults.) On 1/30/06, Michael Foord <[EMAIL PROTECTED]> wrote: > But like it or not, configuration files are often used to store data > about what a program does - not just the UI options. Storing this in a > human readable and editable format is of great advantage. > > Yes, a lot of the entries will never be modified by a user - but many > will need to be edited and read by a developer. In a production > environment importing from python modules is not likely to be safe. Ah. This definitely isn't what ConfigParser was meant to do. I'd think for this you should use some kind of XML pickle though. That's horrible if end users must edit it, but great for saving near-arbitrary persistent data in a readable and occasionally editable (for the developer) form. You should probably not mix the end user config data with the program's persistent store. > I don't dislike the INI format. ``key = value`` is intuitive. Nesting of > sections is a logical extension that provides additional flexibility > without breaking backwards compatibility. It needn't be added > complexity, because you don't need to use it. There are plenty of people > who will though. And I'm trying to say that (for config files) they probably shouldn't, because most of their users won't understand it. Of course this doesn't apply to your use case, so maybe we're just violently agreeing -- except you seem to be confusing matters by talking about "configuration" (which suggests end-user-editable) when you really mean "persistent state" (which is under full program control). > > Regarding the claim that dicts are the best kind of API for > > configuration, I disagree -- the dict API doesn't maintain order, and > > doesn't provide access to comments and other metadata. And it has many > > operations that make little sense for configuration option values. > > > An ordered dictionary is a fairly trivial modification of the dictionary > (if you don't mind the performance hit), and yes there is other metadata > also needs to be stored. Hey, since Python 2.2 some folk put a lot of > work in allowing us to subclass dict. ;-) Yeah, but that was more as a matter of principle than to encourage that use... Narrow APIs are typically better than wide APIs, and the dict API is the ultimate wide API. (I guess strings are just as bad; I haven't contributed to that thread yet but I think the new path module should not inherit from str or unicode either.) > Perhaps a better way of saying this is that the dictionary API is an > intuitive way to access config file data (including modifying and > creating). You are mapping values to names, it's a logical match. > > As soon as you generate/manipulate config files programattically a lot > of the dictionary methods become useful. Perhaps not all though. > ``get``, ``update``, ``has_key`` are all useful. has_key is obsolete though -- use 'in'. Anyway, we have a name for this -- we call it the "mapping protocol". In most cases it's better to implement a protocol than inherit a standard object. (This is perhaps unique to Python -- other OO languages often encourage inheritance, so I can understand the confusion.) > Wow, my first rebuke from the BDFL. May it be the first of many. ;-) > > I've changed this client, but I use this account from multiple > locations. Forgive me if I forget to change others (but feel free to > remind me). > > Michael Foord > (Chastened but Fuzzy nonetheless.) Thanks much! -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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: python-dev Summary for 2006-01-01 through 2006-01-15
On Mon, Jan 30, 2006 at 04:44:47PM -0500, Tim Peters wrote: > Python is a high-profile project that hasn't been hiding its readline > module, and if I presume anything here it's that the FSF would have > complained by now if they really didn't want this. In fact, we can be absolutely certain the FSF knows (or people in charge have known, rather) of the readline module, since it was an important reason to get Python's license GPL-compatible. Had they, at that time, considered code-that-wraps-libreadline a problem, they would have made that known. As it is, it was clear that the resulting binary (of non-GPL-compatible source and a GPL library) was a GPL violation, but the source itself was not. Not that they can't change their minds, of course. But I wouldn't go and ask them if they changed their minds yet; it might make them ;P -- Thomas Wouters <[EMAIL PROTECTED]> Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ 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] [Doc-SIG] that library reference, again
On 1/26/06, Robey Pointer <[EMAIL PROTECTED]> wrote: [quoting /F] > > moving all of (or parts of) the reference documentation in to the > > library source code would be an alternative, of course [1], but that > > would basically mean starting over from scratch. Bad idea. Putting the full docs in the source adds more coupling between the files and makes it harder instead of easier to edit the docs, especially for C code. Also, the needs for interactive help are different from those for off-line docs. Also note that several object types (e.g. lists and dicts, like used for sys.path and sys.modules) don't have __doc__ properties so documenting them in the source is problematic. The list goes on; e.g. the source code ordering may not be the same as the ideal documentation ordering; where do you put subsection introductions, etc. > I think that would be a good thing to do no matter what markup is > used. It always irritates me when I do 'help(sys.something)' and get > one line of ASCII art that's probably useful to the module author but > nobody else. Wrong guess. That string was put there by the author specifically so that it shows up in help(sys.whatever), and the author probably (mistakenly) though that whatever he wrote was sufficient. If you ever find a docstring that is IYO insufficient, please submit a patch or bug. Until we have a better mechanism, simply submitting the new text of the docstring, without bothering to make it into a context-diff or to use the proper markup, is fine. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] Extension to ConfigParser
Guido van Rossum wrote: > On 1/30/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > >> Guido> What's so bad about ConfigParser? >> >> My guess is that people find its limited nesting, well, limiting. Python >> containers being the arbitrary nesting little devils that they are, I can >> understand the desire to push the envelope. >> > > To the contrary. Config file syntax should be limited by design so as > to avoid confusing the people who have to edit them without knowing > Python, and if an app is successful, that's most of the app's users. > (If the app is only targeted at Python users, why bother with a config > file? You could just have one designated .py file where all the > configuration code is concentrated, like faqwizard's faqconf.py.) > > >> It's my opinion that ConfigParser should stay pretty much as it is other >> than perhaps adding round trip capability. It is pretty good at reading and >> writing Windows INI files, which was what it was designed to do. My guess >> is there are a fair number of people who wouldn't want to lose that. Mixing >> INI file handling with something more powerful seems doomed. If we want >> more sophisticated functionality a new module should be written, or one of >> the existing shootout candidates on the Wiki should be chosen and perhaps >> enhanced. I have a horse in that race (actually, it's more like a pony). >> > > Aha. I am beginning to understand. When people say "ConfigParser is > hopeless" they mean ".INI files are hopeless". I happen to disagree. > (There's also a meme that says that every aspect of an app should be > configurable. I disagree with that too. As Joel Spolski points out in > his book on UI design, most configuration options are signs of > indecisive developers, and most users never change the defaults.) > > But like it or not, configuration files are often used to store data about what a program does - not just the UI options. Storing this in a human readable and editable format is of great advantage. Yes, a lot of the entries will never be modified by a user - but many will need to be edited and read by a developer. In a production environment importing from python modules is not likely to be safe. I don't dislike the INI format. ``key = value`` is intuitive. Nesting of sections is a logical extension that provides additional flexibility without breaking backwards compatibility. It needn't be added complexity, because you don't need to use it. There are plenty of people who will though. > Regarding the claim that dicts are the best kind of API for > configuration, I disagree -- the dict API doesn't maintain order, and > doesn't provide access to comments and other metadata. And it has many > operations that make little sense for configuration option values. > > An ordered dictionary is a fairly trivial modification of the dictionary (if you don't mind the performance hit), and yes there is other metadata also needs to be stored. Hey, since Python 2.2 some folk put a lot of work in allowing us to subclass dict. ;-) Perhaps a better way of saying this is that the dictionary API is an intuitive way to access config file data (including modifying and creating). You are mapping values to names, it's a logical match. As soon as you generate/manipulate config files programattically a lot of the dictionary methods become useful. Perhaps not all though. ``get``, ``update``, ``has_key`` are all useful. > (And would Michael please start signing with his full name, since he > doesn't seem to care much for true anonymity? It's okay if your email > says > > From: Michael So-and-so <[EMAIL PROTECTED]> > > Michael So-and-so ??? Hey, that's fighting talk. ;-) > It's suboptimal if it says > > From: Fuzzyman <[EMAIL PROTECTED]> > > You might also start signing your posts "Michael So-and-so" rather > than the alias. I don't sign my email "BDFL" either. :-) Since there > are many Michaels, signing just "Michael" doesn't really help. I'm too > old fogey to get used to using IRC handles to refer to people; I can > never keep the mapping in my head.) > Wow, my first rebuke from the BDFL. May it be the first of many. ;-) I've changed this client, but I use this account from multiple locations. Forgive me if I forget to change others (but feel free to remind me). Michael Foord (Chastened but Fuzzy nonetheless.) > -- > --Guido van Rossum (home page: http://www.python.org/~guido/) > ___ > 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/fuzzyman%40voidspace.org.uk > > ___ 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] Extension to ConfigParser
On 1/30/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Guido> What's so bad about ConfigParser? > > My guess is that people find its limited nesting, well, limiting. Python > containers being the arbitrary nesting little devils that they are, I can > understand the desire to push the envelope. To the contrary. Config file syntax should be limited by design so as to avoid confusing the people who have to edit them without knowing Python, and if an app is successful, that's most of the app's users. (If the app is only targeted at Python users, why bother with a config file? You could just have one designated .py file where all the configuration code is concentrated, like faqwizard's faqconf.py.) > It's my opinion that ConfigParser should stay pretty much as it is other > than perhaps adding round trip capability. It is pretty good at reading and > writing Windows INI files, which was what it was designed to do. My guess > is there are a fair number of people who wouldn't want to lose that. Mixing > INI file handling with something more powerful seems doomed. If we want > more sophisticated functionality a new module should be written, or one of > the existing shootout candidates on the Wiki should be chosen and perhaps > enhanced. I have a horse in that race (actually, it's more like a pony). Aha. I am beginning to understand. When people say "ConfigParser is hopeless" they mean ".INI files are hopeless". I happen to disagree. (There's also a meme that says that every aspect of an app should be configurable. I disagree with that too. As Joel Spolski points out in his book on UI design, most configuration options are signs of indecisive developers, and most users never change the defaults.) Regarding the claim that dicts are the best kind of API for configuration, I disagree -- the dict API doesn't maintain order, and doesn't provide access to comments and other metadata. And it has many operations that make little sense for configuration option values. (And would Michael please start signing with his full name, since he doesn't seem to care much for true anonymity? It's okay if your email says From: Michael So-and-so <[EMAIL PROTECTED]> It's suboptimal if it says From: Fuzzyman <[EMAIL PROTECTED]> You might also start signing your posts "Michael So-and-so" rather than the alias. I don't sign my email "BDFL" either. :-) Since there are many Michaels, signing just "Michael" doesn't really help. I'm too old fogey to get used to using IRC handles to refer to people; I can never keep the mapping in my head.) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] Extension to ConfigParser
Guido> What's so bad about ConfigParser? My guess is that people find its limited nesting, well, limiting. Python containers being the arbitrary nesting little devils that they are, I can understand the desire to push the envelope. It's my opinion that ConfigParser should stay pretty much as it is other than perhaps adding round trip capability. It is pretty good at reading and writing Windows INI files, which was what it was designed to do. My guess is there are a fair number of people who wouldn't want to lose that. Mixing INI file handling with something more powerful seems doomed. If we want more sophisticated functionality a new module should be written, or one of the existing shootout candidates on the Wiki should be chosen and perhaps enhanced. I have a horse in that race (actually, it's more like a pony). Skip ___ 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: python-dev Summary for 2006-01-01 through 2006-01-15
[Stephen J. Turnbull] > ... > Aladdin took a position similar to Martin's, and only yanked the > offending Makefile stanza when the FSF called them and said "we're > ready to go to court; are you?" > ... > It's not theoretical; it's almost identical to the Aladdin case. > Legally the PSF is, if anything, in a weaker position than Aladdin > (which did not distribute the module that interfaced to libreadline in > Ghostscript, but merely a makefile stanza that used it if it were > found). I'm not making myself clear. The FSF (like most organizations, including the PSF) has agendas that are more aptly described as political than as legal -- legalities are more of a club to try to force what they want. If the FSF merely _says_ they want to make it difficult, or even impossible, to link Python and/or Python apps with GNU readline, that's fine by me, and they don't have to make up creative license readings or threats to get that. I'm happy to accede to their wishes in the matter regardless of what the license says, or is claimed to say. OTOH, I have no reason to _presume_ that this is their hoped-for outcome wrt Python, neither to presume that the politics shaping their tussle with Aladdin are relevant to the PSF. "The law" is rarely applied uniformly, in large part because it usually is means rather than end. Python is a high-profile project that hasn't been hiding its readline module, and if I presume anything here it's that the FSF would have complained by now if they really didn't want this. In the meantime, I'm satisfied that the people involved with Python's readline module acted on good-faith readings of the licenses involved. If someone cares enough to rip it out, and/or to supply an alternative, fine by me too (but it won't _be_ me). ___ 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] Extension to ConfigParser
Ian Bicking wrote: > Guido van Rossum wrote: > >>> I don't think enhancing ConfigParser significantly is a good way >>> forward. Because of ConfigParser's problems people have made all sorts >>> of workarounds, and so I don't think there's any public interface that >>> we can maintain while changing the internals without breaking lots of >>> code. In practice, everything is a public interface. So I think the >>> implementation as it stands should stay in place, and if anything it >>> should be deprecated instead of being enhanced in-place. >>> >> Somehow that's not my experience. What's so bad about ConfigParser? >> What would break if we rewrote the save functionality to produce a >> predictable order? >> > > That's a fairly minor improvement, and I can't see how that would break > anything. But Michael (aka Fuzzyman -- sorry, I just can't refer to you > as Fuzzyman without feeling absurd ;) Don't worry, absurdity is a common reaction I inspire in people. Actually Fuzzyman is more of a description than a nickname. I understand that I may not be the only one worthy of such a title of course. ;-) > was proposing ConfigObj > specifically (http://www.voidspace.org.uk/python/configobj.html). I > assume the internals of ConfigObj bear no particular resemblence to > ConfigParser, even if ConfigObj can parse the same syntax (plus some, > and with different failure cases) and provide the same public API. > > While ConfigParser is okay for simple configuration, it is (IMHO) not a > very good basis for anyone who wants to build better systems, like > config files that can be changed programmatically, or error messages > that point to file and line numbers. Those aren't necessarily features > we need to expose in the standard library, but it'd be nice if you could > implement that kind of feature without having to ignore the standard > library entirely. > > Can you elaborate on what kinds of programattic changes you envisage ? I'm just wondering if there are classes of usage not covered by ConfigObj. Of course you can pretty much do anything to a ConfigObj instance programattically, but even so... > That said, I'm not particularly enthused about a highly featureful > config file *format* in the standard library, even if I would like a > much more robust implementation. > > I don't see how you can easily separate the format from the parser - unless you just leave raw values. (As I said in the other email, I don't think I fully understand you.) If accessing raw values suits your purposes, why not subclass ConfigParser and do magic in the get* methods ? > From my light reading on ConfigObj, it looks like it satisfies my > personal goals (though I haven't used it), but maybe has too many > features, like nested sections. And it seems like maybe the API can be > I personally think nested sections are very useful and would be sad to not see them included. Grouping additional configuration options as a sub-section can be *very* handy. > reduced in size with a little high-level refactoring -- APIs generally > grow over time so as to preserve backward compatibility, but I think if > it was introduced into the standard library that might be an opportunity > to trim the API back again before it enters the long-term API freeze > that the standard library demands. Hmmm possibly. :-) walk, decode and encode are the obvious extraneous methods. walk can be re-implemented as a recursive function and encode/decode will be unnecessary when unicode support is complete. Additional complexity comes from retaining all comments and supporting validation. I think retaining comments is worthwhile, because it allows a program to modify a config file (e.g. from a GUI) without losing user comments in a handwritten config file. The validation support has several levels to it - but it can be completely ignored with no complexity for the user. Some validation support is integrated into instantiation, but this could *probably* be broken out into a subclass. Anyway, ho hum - possibly. All for future hypothetical discussion I guess... All the best, Fuzzyman http://www.voidspace.org.uk/python/configobj.html ___ 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] Extension to ConfigParser
Ian Bicking wrote: > Fuzzyman wrote: >> The resolution I'm suggesting means that people can continue to use >> ConfigParser, with major feature enhancements. *Or* they can migrate >> to a slightly different API that is easier to use - without needing >> to switch between incompatible modules. > > I don't think enhancing ConfigParser significantly is a good way > forward. Because of ConfigParser's problems people have made all > sorts of workarounds, and so I don't think there's any public > interface that we can maintain while changing the internals without > breaking lots of code. In practice, everything is a public > interface. So I think the implementation as it stands should stay in > place, and if anything it should be deprecated instead of being > enhanced in-place. > > Another class or module could be added that fulfills the documented > interface to ConfigParser. This would provide an easy upgrade path, > without calling it a backward-compatible interface. I personally > would like if any new config system included a parser, and then an > interface to the configuration that was read (ConfigParser is only the > latter). Then people who want to do their own thing can work with just > the parser, without crudely extending and working around the > configuration interface. > But to implement a parser you still need to agree a basic syntax. For example ConfigObj supports list values, handles quotes sanely, uses triple quotes for multiline values, allows inline comments, and has a syntax for nested sections. Once you have agreed these and a *basic* API spec for accessing the data then you've implemented most of your config file handler. In order to implement a write (save) method you also have to agree on how to handle non string values (like lists). There's not an *awful* lot left to do. In ConfigObj if you switch off list handling when parsing and interpolation when fetching values, you have access to the raw values and are free to extend value handling any way you choose. In my opinion dictionary syntax is the most natural way to represent a config file - it is a data structure with named members. This means the API for accessing the data - whether from a subclass that does additional value processing or from code that just accesses the data. I may be misunderstanding you of course (or more likely not fully understanding). :-) All the best, Fuzzyman http://www.voidspace.org.uk/python/index.shtml ___ 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] Extension to ConfigParser
Guido van Rossum wrote: >>I don't think enhancing ConfigParser significantly is a good way >>forward. Because of ConfigParser's problems people have made all sorts >>of workarounds, and so I don't think there's any public interface that >>we can maintain while changing the internals without breaking lots of >>code. In practice, everything is a public interface. So I think the >>implementation as it stands should stay in place, and if anything it >>should be deprecated instead of being enhanced in-place. > > > Somehow that's not my experience. What's so bad about ConfigParser? > What would break if we rewrote the save functionality to produce a > predictable order? That's a fairly minor improvement, and I can't see how that would break anything. But Michael (aka Fuzzyman -- sorry, I just can't refer to you as Fuzzyman without feeling absurd ;) was proposing ConfigObj specifically (http://www.voidspace.org.uk/python/configobj.html). I assume the internals of ConfigObj bear no particular resemblence to ConfigParser, even if ConfigObj can parse the same syntax (plus some, and with different failure cases) and provide the same public API. While ConfigParser is okay for simple configuration, it is (IMHO) not a very good basis for anyone who wants to build better systems, like config files that can be changed programmatically, or error messages that point to file and line numbers. Those aren't necessarily features we need to expose in the standard library, but it'd be nice if you could implement that kind of feature without having to ignore the standard library entirely. That said, I'm not particularly enthused about a highly featureful config file *format* in the standard library, even if I would like a much more robust implementation. From my light reading on ConfigObj, it looks like it satisfies my personal goals (though I haven't used it), but maybe has too many features, like nested sections. And it seems like maybe the API can be reduced in size with a little high-level refactoring -- APIs generally grow over time so as to preserve backward compatibility, but I think if it was introduced into the standard library that might be an opportunity to trim the API back again before it enters the long-term API freeze that the standard library demands. -- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org ___ 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] Extension to ConfigParser
Guido van Rossum wrote: > On 1/30/06, Ian Bicking <[EMAIL PROTECTED]> wrote: > >> I don't think enhancing ConfigParser significantly is a good way >> forward. Because of ConfigParser's problems people have made all sorts >> of workarounds, and so I don't think there's any public interface that >> we can maintain while changing the internals without breaking lots of >> code. In practice, everything is a public interface. So I think the >> implementation as it stands should stay in place, and if anything it >> should be deprecated instead of being enhanced in-place. >> > > Somehow that's not my experience. What's so bad about ConfigParser? > What would break if we rewrote the save functionality to produce a > predictable order? > Well, what I'm suggesting is not merely enhancing ConfigParser in place - but replacing it with the ConfigObj and a compatibility layer to support legacy code. As I mentioned, it would require *some* changes to the parser (ConfigObj) to be fully compatible with the existing syntax, but that is well achievable. The aim would be that no existing code breaks, and few (if any) config files break. I could flesh this out in a PEP if it was likely that it would be accepted. Issues with ConfigParser that ConfigObj *immediately* fixes : * Simpler API - uses dictionary syntax/methods for adding/deleting/accessing keys and sections (Each section - including the ConfigObj itself - is a dictionary subclass with all methods available) * Nested sub-sections to any depth. * Fully integrated (extensible) validation schema system, with type conversion. No complexity overhead for not using it. * List values parsed by default (handling quotes sanely) * Retains order of keys/section for iteration and writing out config file. * Retains *all* comments and allows inline comments The next enhancement will add full unicode support, which for a text based format really makes sense and I should have implemented it earlier. Additionally ConfigObj allows values in the root section - meaning that for simple config files you aren't *forced* to have an arbitrary 'section'. All the best, Fuzzyman http://www.voidspace.org.uk/python/configobj.html > -- > --Guido van Rossum (home page: http://www.python.org/~guido/) > ___ > 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/fuzzyman%40voidspace.org.uk > > ___ 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] Extension to ConfigParser
On 1/30/06, Ian Bicking <[EMAIL PROTECTED]> wrote: > I don't think enhancing ConfigParser significantly is a good way > forward. Because of ConfigParser's problems people have made all sorts > of workarounds, and so I don't think there's any public interface that > we can maintain while changing the internals without breaking lots of > code. In practice, everything is a public interface. So I think the > implementation as it stands should stay in place, and if anything it > should be deprecated instead of being enhanced in-place. Somehow that's not my experience. What's so bad about ConfigParser? What would break if we rewrote the save functionality to produce a predictable order? -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] (libffi) Re: Copyright issue
On 29/01/2006, at 7:00 PM, Martin v. Löwis wrote: > Again: What matters is what ends up in the source distribution, > http://www.python.org/ftp/python/2.4/Python-2.4.tgz No really that is wrong. What matters is what is in the Python executables, but you don't want to know that. So I will bow out of the discussion. Cheers Bill PS Linking with GNU libreadline really is a problem. ___ 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] (libffi) Re: Copyright issue
On 28/01/2006, at 8:04 PM, Martin v. Löwis wrote: >> The compiler needs specific exemptions because parts of the GPLed >> runtime libraries are included in all compiled code. No part of the >> autotools ends up in the finished code. If it did, you would need m4 >> to run Python and you don't. > > It doesn't matter whether it ends up in the finished code: if the > aclocal.m4 is indeed GPL-licensed, then the entire Python source > distribution must be GPL-licensed, because it "contains or > is derived from the Program or any part thereof". The build tools: m4 scripts, the configure shell script and the Makefiles all contain GPL code and are under GPL. However, none of this ends up in the 'finished program' which is the executable versions of Python and its associated libraries. The build tools are just tools not part of the program. The program is not 'derived' from the build tools. Maybe it would help to put it in a another domain: Say I decide to write the great Australian novel. I sit at my computer and type in the words. Those words are my copyright and I am able to restrict their use as provided in copyright legislation. These rights are inherent and exist regardless of whether or not I add a copyright notice. The notice is just a courtesy and a convenience which tells anyone who would like to use the work they need to get my permission. A license is just a set of standard permissions passed on with the work. Now I print out my novel. That printed version is 'derived' from the representation in the computer. So it is covered by the same copyright. If I compress the computer files, those are still derived work. If some American decides to write the great American novel by boiler-plating large chunks of my work with a little of his, then that work is derived and copyright to both of us. His actions are legal unless he tries to publish it, which would require my permission. This is analogous to linking a program with a library provided by another party. That is why one needs the specific concessions in the gcc compiler to cover the linked run time libraries. Of course the computer on which I wrote the book has an operating system which is copyright. The word processing software I used to do the writing is also copyright. However none of either program ends up in my novel. So the novel is not derived from them, and their copyright holders have no rights over the novel. I can happily package appropriately licensed copies of the word processing software with the finished book. So that others can try their hand at the same thing. In no way does such an operation give the software copyright holders any rights over the book. This is exactly analogous to including the GPL tools with your source distribution. You must comply with the GPL in respect of the GPL code. So you must include copyright notices and and make any modifications or improvements freely available. However, if you build a binary from the sources which does not include or link GPL code then the FSF have no rights over it and you are not obliged to acknowledge them or include their copyright notice. A Python binary is no more derived from the autotools than the book is derived from the word processing software. Bill Northcott ___ 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] (libffi) Re: Copyright issue
On 29/01/2006, at 5:48 AM, Martin v. Löwis wrote: > Yes, but your conclusion is wrong. Python uses autoconf, but not > aclocal/automake. The generated configure is explicitly not covered by > the GPL; What makes you think that? I can see no such concession in the autoconf source distribution. A configure script is built up from lots of code fragments out of the autoconf and automake M4 files, and would clearly be covered by GPL. Bill Northcott ___ 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] (libffi) Re: Copyright issue
OTOH this (from python-sig-mac) is a worry if it is correct: > s> Apparently the readline library in MacOSX isn't really > readline. > s> It's a renamed libedit. Not having encountered this deception > s> before, Python's build procedure doesn't know to test the > capability > s> of readline. I suggest you just comment out the readline > checks in > s> setup.py. > > Piet> libedit (editline) is a different library with a similar > function > Piet> as readline, but not compatible with it. It has a BSD > license. It > Piet> is often used instead of readline for non-GPL software. > > True. I believe it was written by Rich Salz several years ago. > Python used > to work with it, but eventually started using some readline > functionality > which libedit doesn't provide. I don't recall what that is. If you distribute Python sources that link the GNU libreadline then all your code will be covered by GPL, because libreadline uses the full GPL not LGPL. That is why Apple and other commercial vendors do not include it in their OS. Bill Northcott ___ 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] (libffi) Re: Copyright issue
On 29/01/2006, at 5:48 AM, Martin v. Löwis wrote: > Yes, but your conclusion is wrong. Python uses autoconf, but not > aclocal/automake. The generated configure is explicitly not covered by > the GPL; What makes you think that? I can see no such concession in the autoconf source distribution. A configure script is built up from lots of code fragments out of the autoconf and automake M4 files, and would clearly be covered by GPL. Bill Northcott ___ 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] (libffi) Re: Copyright issue
On 28/01/2006, at 8:04 PM, Martin v. Löwis wrote: >> The compiler needs specific exemptions because parts of the GPLed >> runtime libraries are included in all compiled code. No part of the >> autotools ends up in the finished code. If it did, you would need m4 >> to run Python and you don't. > > It doesn't matter whether it ends up in the finished code: if the > aclocal.m4 is indeed GPL-licensed, then the entire Python source > distribution must be GPL-licensed, because it "contains or > is derived from the Program or any part thereof". The build tools: m4 scripts, the configure shell script and the Makefiles all contain GPL code and are under GPL. However, none of this ends up in the 'finished program' which is the executable versions of Python and its associated libraries. The build tools are just tools not part of the program. The program is not 'derived' from the build tools. Maybe it would help to put it in a another domain: Say I decide to write the great Australian novel. I sit at my computer and type in the words. Those words are my copyright and I am able to restrict their use as provided in copyright legislation. These rights are inherent and exist regardless of whether or not I add a copyright notice. The notice is just a courtesy and a convenience which tells anyone who would like to use the work they need to get my permission. A license is just a set of standard permissions passed on with the work. Now I print out my novel. That printed version is 'derived' from the representation in the computer. So it is covered by the same copyright. If I compress the computer files, those are still derived work. If some American decides to write the great American novel by boiler-plating large chunks of my work with a little of his, then that work is derived and copyright to both of us. His actions are legal unless he tries to publish it, which would require my permission. This is analogous to linking a program with a library provided by another party. That is why one needs the specific concessions in the gcc compiler to cover the linked run time libraries. Of course the computer on which I wrote the book has an operating system which is copyright. The word processing software I used to do the writing is also copyright. However none of either program ends up in my novel. So the novel is not derived from them, and their copyright holders have no rights over the novel. I can happily package appropriately licensed copies of the word processing software with the finished book. So that others can try their hand at the same thing. In no way does such an operation give the software copyright holders any rights over the book. This is exactly analogous to including the GPL tools with your source distribution. You must comply with the GPL in respect of the GPL code. So you must include copyright notices and and make any modifications or improvements freely available. However, if you build a binary from the sources which does not include or link GPL code then the FSF have no rights over it and you are not obliged to acknowledge them or include their copyright notice. A Python binary is no more derived from the autotools than the book is derived from the word processing software. Bill Northcott ___ 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] / as path join operator
On 1/28/06, Stephen J. Turnbull <[EMAIL PROTECTED]> wrote: > Please note that my point was entirely different from trying to decide > whether to subclass strings. Noted -- sorry I took you out of context there; that was careless. > Jason> Filesystem paths are in fact strings on all operating > Jason> systems I'm aware of. > > I have no idea what you could mean by that. The data structure used > to represent a filesystem on all OS filesystems I've used is a graph > of directories and files. A filesystem object is located by > traversing a path in that graph. You seem to think that because I said "operating systems", I'm talking about kernel algorithms and such. I'm not. By "on all operating systems" I really mean systems, not kernels: system APIs, standard tools, documentation, the conventions everyone follows--that sort of thing. Userspace. Thought experiment: How are filesystem paths used? Well, programs pass them into system calls like open() and chmod(). Programs use them to communicate with other programs. Users pass them to programs. Compare this to how you'd answer the question "How are integers used?": I think paths are used more for communication, less for computation. Their utility for communication is tightly bound to their string-nature. Essentially all APIs involving filesystem paths treat them as strings. It's not just that they take string parameters. The way they're designed, they encourage users to think of paths as strings, not graph-paths. Java's stdlib is the only API that even comes close to distinguishing paths from strings. The .NET class library doesn't bother. Many many people much smarter than I have thought about creating non-string-oriented filesystem APIs. Somehow it hasn't caught on. Essentially all users expect to see a filesystem path as a string of characters in the conventional format. Display it any other way (say, as a sequence of edge-names) and you risk baffling them. My position is (a) the convention that paths are strings really does exist, embedded in the design and culture of the dominant operating systems--in fact it's overwhelming, and I'm surprised anyone can miss it; (b) there might be a reason for it, even aside from momentum. -j ___ 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] Extension to ConfigParser
Fuzzyman wrote: > The resolution I'm suggesting means that people can continue to use > ConfigParser, with major feature enhancements. *Or* they can migrate to > a slightly different API that is easier to use - without needing to > switch between incompatible modules. I don't think enhancing ConfigParser significantly is a good way forward. Because of ConfigParser's problems people have made all sorts of workarounds, and so I don't think there's any public interface that we can maintain while changing the internals without breaking lots of code. In practice, everything is a public interface. So I think the implementation as it stands should stay in place, and if anything it should be deprecated instead of being enhanced in-place. Another class or module could be added that fulfills the documented interface to ConfigParser. This would provide an easy upgrade path, without calling it a backward-compatible interface. I personally would like if any new config system included a parser, and then an interface to the configuration that was read (ConfigParser is only the latter). Then people who want to do their own thing can work with just the parser, without crudely extending and working around the configuration interface. -- Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org ___ 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: python-dev Summary for 2006-01-01 through 2006-01-15
Anthony Baxter wrote: > Rather than the back-n-forth about what the FSF might or might not do, > can we just ask them for an official opinion and settle the matter? > > Who would we need to talk to for a definitive answer? I'm sure there's > various FSF mailing lists where we could get 157 different potential > answers, but I'm talking about an actual, official FSF statement <0.5 > wink> From http://www.fsf.org/licensing/licenses/index_html: "If you want help choosing a license, evaluating a license, or have any other questions about licenses, you can email us at <[EMAIL PROTECTED]>." -Jeff ___ 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: python-dev Summary for 2006-01-01 through 2006-01-15
Rather than the back-n-forth about what the FSF might or might not do, can we just ask them for an official opinion and settle the matter? The Aladdin case makes me think we should do this, probably before 2.5 comes out - because if we do have to yank readline, I'd really not like to see this happen in a bugfix release, for fairly obvious reasons. Who would we need to talk to for a definitive answer? I'm sure there's various FSF mailing lists where we could get 157 different potential answers, but I'm talking about an actual, official FSF statement <0.5 wink> Anthony ___ 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] / as path join operator (was: Re: The path module PEP)
Steven Bethard wrote:
> My only fear with the / operator is that we'll end up with the same
> problems we have for using % in string formatting -- the order of
> operations might not be what users expect. Since join is conceptually
> an addition-like operator, I would expect:
>
> Path('home') / 'a' * 5
>
> to give me:
>
> home/a
>
> If I understand it right, it would actually give me something like:
>
> home/ahome/ahome/ahome/ahome/a
Is there any very deep magic that says / is the One True Operator
to use for this, given that there's to be an operator for it? For
instance, & has lower correct precedence (so that Path('home') & 'a'*5
does something less unexpected), and doesn't look quite so much
as if it denotes arithmetic, and avoids semantic interference
from the idea that "/" should divide things or make them smaller.
(Though, for what it's worth, I think sticking another subdirectory
onto a path *is* dividing and making smaller: think of a path as
representing a subtree.) You do lose the pun on the Unix path separator,
which is a shame.
--
g
___
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] (libffi) Re: Copyright issue
Hye-Shik Chang <[EMAIL PROTECTED]> writes: > On 1/30/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: >> Well done! Would you like to derive a Python patch from that? > > Yup. I'll do. > > On 1/30/06, Thomas Heller <[EMAIL PROTECTED]> wrote: >> That's great! Would you like to integrate these changes into to ctypes >> CVS repository yourself? I indend to do a few releases still from >> there, before the first Python 2.5. If so, please tell me your SF >> username and I'll add you as developer. >> >> Also, please note that all work should be done on the 'branch_1_0' CVS >> branch - the HEAD is only experimental code (and not currently used). > > My SF username is perky. Added. > I'll try to make it portable but it'll > lose some platforms through compilers because few of libffi > sources are in preprocessed assembly (.S) which isn't supported > by distutils yet. So, we'll need tests on various compiler/platforms > before the release. Isn't it sufficient to append ".S" to self.compiler.src_extensions? Thanks, Thomas ___ 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] (libffi) Re: Copyright issue
On 1/30/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > Well done! Would you like to derive a Python patch from that? Yup. I'll do. On 1/30/06, Thomas Heller <[EMAIL PROTECTED]> wrote: > That's great! Would you like to integrate these changes into to ctypes > CVS repository yourself? I indend to do a few releases still from > there, before the first Python 2.5. If so, please tell me your SF > username and I'll add you as developer. > > Also, please note that all work should be done on the 'branch_1_0' CVS > branch - the HEAD is only experimental code (and not currently used). My SF username is perky. I'll try to make it portable but it'll lose some platforms through compilers because few of libffi sources are in preprocessed assembly (.S) which isn't supported by distutils yet. So, we'll need tests on various compiler/platforms before the release. Hye-Shik ___ 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] Extension to ConfigParser
Vinay Sajip wrote: Fuzzyman voidspace.org.uk> writes: Hello Vinjay, In the past there has been some discussion about a new module to replace ConfigParser. Most notably at http://wiki.python.org/moin/ConfigParserShootout [snip] It would be possible to extend to the ConfigObj API to be backwards compatible with ConfigParser. This would bring the added benefits of ConfigObj, without needing to add an extra module to the standard library. Well nearly. ConfigObj supports config file schema with (optional) type conversion, through a companion module called validate. This could be included or left as an added option. Anyway. If this stands a *chance* of acceptance, I'll write the PEP (and if accepted, do the work - which is not inconsiderable). Personally, I'd prefer to have the different candidates in the Shootout be evaluated and a "winner" picked (I'm not sure who would do this, or when it would be done). Quite. I'm suggesting an alternative that bypasses that tortuous and unlikely process. ;-) I'll readily declare an interest - I've implemented an alternative hierarchical config module (which is in no way backward compatible with ConfigParser), see http://www.red-dove.com/python_config.html I realise that there are several alternative modules available . Obviously my personal preference is ConfigObj (I'm not unbiased of course). :-) Lack of complexity is the major feature I would tout here - I guess other people would have different priorities. However, this not the only issue. Adding a new module, with a different API and possibly a different syntax for files, is a recipe for (some) confusion. Not to mention the difficulty of achieving a consensus on python-dev. (Again - ;-) The resolution I'm suggesting means that people can continue to use ConfigParser, with major feature enhancements. *Or* they can migrate to a slightly different API that is easier to use - without needing to switch between incompatible modules. I'm currently adding the ``ConfigParser.get*`` methods to ConfigObj (user request) and also adding full (straightforward) unicode support for reading and writing. These changes will be available in a beta release in the next few days. Anyway, debate on the issue is welcomed. All the best, Fuzzyman http://www.voidspace.org.uk/python/configobj.html Regards, Vinay Sajip ___ 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/fuzzyman%40voidspace.org.uk ___ 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: python-dev Summary for 2006-01-01 through 2006-01-15
> "Tim" == Tim Peters <[EMAIL PROTECTED]> writes: Tim> [Martin v. Löwis] >> Also, I firmly believe that the FSF would *not* sue the PSF, >> but instead first ask that the status is corrected. They would ask first. That's what they did in the case of Aladdin Ghostscript's use of readline. Tim> I'd say that's almost certain. Like any organization with Tim> something fuzzy to protect, the FSF has far more to lose than Tim> to gain by daring a court to rule on their beliefs. Of Tim> course the PSF is in a similar boat: both parties would view Tim> a lawsuit as a rock-bottom last resort. Aladdin took a position similar to Martin's, and only yanked the offending Makefile stanza when the FSF called them and said "we're ready to go to court; are you?" Tim> I wouldn't yank it just to avoid a theoretical possibility Tim> that the FSF might complain someday. It's not theoretical; it's almost identical to the Aladdin case. Legally the PSF is, if anything, in a weaker position than Aladdin (which did not distribute the module that interfaced to libreadline in Ghostscript, but merely a makefile stanza that used it if it were found). -- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of TsukubaTennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software. ___ 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
