Re: [Python-Dev] The path module PEP
On 1/26/06, Stefan Rank [EMAIL PROTECTED] wrote: on 26.01.2006 14:15 Paul Moore said the following: [snip] Also note that my example Path(C:, Windows, System32) above is an *absolute* path on Windows. But a relative (albeit stupidly-named :-)) path on Unix. How would that be handled? wrong, Path(C:, Windows, System32) is a relative path on windows. see below. Hmm, relative to the CWD on C: is a valid concept, and that is a potential meaning. I hadn't thought of that. Not that os.path gets it perfect: Python 2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. import os os.path.join(C:, Windows, System32) 'C:Windows\\System32' os.path.join(., os.path.join(C:, Windows, System32)) '.\\C:Windows\\System32' this is misleading. observe:: In [1]: import os In [2]: os.path.join(., os.path.join(C:, Windows, System32)) Out[2]: '.\\C:Windows\\System32' but:: In [3]: os.path.join(., os.path.join(C:\\, Windows, System32)) Out[3]: 'C:\\Windows\\System32' The second example uses an absolute path as second argument, and as os.path.join should do, the first argument is discarded. The first case is arguably a bug, since, on windows, C:Windows\System32 is a path relative to the *current directory on disk C:* If the cwd on C: would be C:\temp then C:Windows\System32 would point to C:\temp\Windows\System32 The problem is that Windows has a cwd per partition... (I cannot even guess why ;-) Thanks for the clarification, you are right in your analysis. However, it doesn't really affect my main point, which was that there should be no such thing as a relative Path (please note - I say Path here, to refer to the new Path object, as opposed to the general concept of an OS file path). [...] Arguably, Path objects should always maintain an absolute path - there should be no such thing as a relative Path. So you would have you realise that one might need and/or want to represent a relative path? Absolutely. But not a Path (see distinction above). Aaron Bingham's analogy with time/timedelta applies well here. Relative paths, like relative times, have their own special semantics, which deserve to be addressed in a separate class. You argue that time is merely a timedelta with a fixed start point. I'd disagree - the key point with timedeltas is that they need careful handling (DST issues, for example) _depending upon precisely what they are added to_ - these issues are avoided by the time type exactly because it has a constant base. In exactly the same way, absolute paths have simpler semantics precisely because they are absolute. Paul. ___ 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] SourceForge Download Page, Subversion Home Page
You may be aware that Tim Parkin's work on our next-generation web presence has borne fruit in the shape of beta.python.org. While there's still a lot to be done Tim has given us a great start by creating a framework that makes it rather easier to manage content. I'm just starting to work on the beta site content, and this is causing some examination of the existing web content. Is there any way to affect the target of the very prominent Download Python link on http://sourceforge.net/projects/python/ ? I ask because the link currently takes you to a page whose title is Exiting with Error and whose content is largely No File Packages. While it's not where you arrive from a Google search for python download it is nevertheless a legitimate way (just now) to approach the project, and should therefore really be live. Is there any chance some SF admin could point it to http://www.python.org/download/ There's the further issue that the entire HTML body of http://svn.python.org/ currently reads !-- not sure what to put here -- It would seem like the logical place to have pointers to Subversion software (downloads, documentation, operating instructions) together with an *annotated* summary of http://svn.python.org/projects/ and links back to the main developer site at the very least. I'm not even sure where that web content is under SVN control at the moment. The web revision is going to lead to several of these kinds of discussions. I'll try to only spill on to the python-dev list what impinges on developers. Your opinions on these specific issues are probably the most significant. [pydotorgers: let's try not to spam python-dev with any discussions] regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC www.holdenweb.com PyCon TX 2006 www.python.org/pycon/ ___ 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] The path module PEP
on 27.01.2006 11:16 Paul Moore said the following: [...] Arguably, Path objects should always maintain an absolute path - there should be no such thing as a relative Path. So you would have you realise that one might need and/or want to represent a relative path? Absolutely. But not a Path (see distinction above). Aaron Bingham's analogy with time/timedelta applies well here. Relative paths, like relative times, have their own special semantics, which deserve to be addressed in a separate class. You argue that time is merely a timedelta with a fixed start point. I'd disagree - the key point with timedeltas is that they need careful handling (DST issues, for example) _depending upon precisely what they are added to_ - these issues are avoided by the time type exactly because it has a constant base. In exactly the same way, absolute paths have simpler semantics precisely because they are absolute. Paul. I see your point. I guess there are two options: - `Path` as an enhanced string type that bundles methods related to file system addressing - `Path`s that accurately reflect the possible (abstract) paths. There would be a Path and a PathDelta (with appropriate combining semantics), and probably a UnixPath, a WindowsPath, an URLPath maybe. And there need to be appropriate methods for combining them with/creating them from strings. I actually think the latter would be very neat and somewhere else in this thread someone talks about his `Tree` - `Path` - `File` classes with specialised subclasses. The first option, however, has the benefit of simplicity and there is a working implementation. Well - I'm not the one to decide. And I think anything that bundles path related stuff (using a little object-orientation) and cleans up the standard library is a step forward. cheers, s ___ 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] stabilizing builds
On Thu, Jan 26, 2006 at 09:41:53PM -0500, Tim Peters wrote: [Thomas Wouters] ... I'd need developer access back to check it in, though. AFAICT, twouters has developer access to the Python project -- although maybe someone else re-enabled that w/o mentioning it here. I meant svn-checkin-access (it got disabled for disuse a while back.) If I weren't schizofrenic in sysadmin jobs I could add it myself, but I can't do that. Can I? I guess I can't. Who am I again? Someone-else'ly y'rs, -- 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
Robey Pointer wrote: On 30 Dec 2005, at 18:29, Christopher Armstrong wrote: [epydoc] is not really even good enough for a lot of my usage without some seriously evil hacks. The fundamental design decision of epydoc to import code, plus some other design decisions on the way it figures types and identity seriously hinder its utility. [...] As a side note, I've done a significant amount of work on a newer version of epydoc that supports both inspection source-code parsing (and can merge the info from both sources, if they're available). Hopefully this new version will address some of these concerns (and some other issues I've heard raised). But I haven't had time to work on it in a while -- I need to concentrate on getting my phd thesis done. If anyone is interested in working on this new version, just let me know. :) -Edward ___ 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] SourceForge Download Page, Subversion Home Page
[Steve Holden] Is there any way to affect the target of the very prominent Download Python link on http://sourceforge.net/projects/python/ ? I ask because the link currently takes you to a page whose title is Exiting with Error and whose content is largely No File Packages. While it's not where you arrive from a Google search for python download it is nevertheless a legitimate way (just now) to approach the project, and should therefore really be live. Is there any chance some SF admin could point it to http://www.python.org/download/ Sorry, looks like SF auto-creates the download button, hardwired to the project's SF Files section. The Python project doesn't have any files on SF anymore. If you go to http://sourceforge.net/projects/zodb/ you'll see the equally prominent Download ZODB and ZEO button, pointing to that project's equally ZODB-free Files area. But, in that case, you'll see that there _is_ a package, named README, with a release named How to get the source. If you click on that and fight your way through the download process, you eventually end up with file zodb.txt, which contains a real download URL for ZODB wink/sigh. Overall I'm not sure that's an improvement, but it was the best I could come up with 2 years ago when ZODB stopped using SF for downloads. ___ 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] SourceForge Download Page, Subversion Home Page
On Fri, Jan 27, 2006 at 10:49:59AM -0500, Tim Peters wrote: If you go to http://sourceforge.net/projects/zodb/ you'll see the equally prominent Download ZODB and ZEO button, pointing to that project's equally ZODB-free Files area. But, in that case, you'll see that there _is_ a package, named README, with a release named How to get the source. If you click on that and fight your way through the download process, you eventually end up with file zodb.txt, which contains a real download URL for ZODB wink/sigh. Overall I'm not sure that's an improvement, but it was the best I could come up with 2 years ago when ZODB stopped using SF for downloads. What if the package wasn't named README, but rather 'www.python.org' with a release named visit www.python.org/download instead? I'm not sure if that package/release name is allowed ;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] stabilizing builds
[Thomas] I'd need developer access back to check it in, though. [Tim] AFAICT, twouters has developer access to the Python project -- although maybe someone else re-enabled that w/o mentioning it here. [Thomas] I meant svn-checkin-access (it got disabled for disuse a while back.) I know. AFAICT, you (twouters) already have it. There's a Yes in the twouters row under the CVS Access column on the Python project's Members admin page. Have you tried checking in? What happens when you do? If it doesn't work, one possibility is that you did a read-only SVN _checkout_, and it's actually SVN griping at you. If I weren't schizofrenic in sysadmin jobs I could add it myself, but I can't do that. Can I? I guess I can't. You shouldn't be able to add yourself -- you're not listed as a godly Python project admin, just as a mortal Python developer. Many people who do checkins routinely (like Neal Norwitz) are in the same boat wrt that. Who am I again? Thomas Wouters ;-) Your SourceForge name in the Python project is twouters. ___ 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] stabilizing builds
I suppose another possibility for why twouters couldn't check in is because someone added him to the project's cvs_acls script. If so, I don't know anything about how to get that changed. ___ 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] stabilizing builds
[Tim] ... AFAICT, you (twouters) already have it. There's a Yes in the twouters row under the CVS Access column on the Python project's Members admin page. Have you tried checking in? What happens when you do? ... LOL -- what a bubblehead I am! Whether you can check in has nothing to do with SourceForge CVS access anymore -- never mind, and sorry. I don't have the power to admin svn.python.org either. 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
John J Lee [EMAIL PROTECTED] writes: On Thu, 26 Jan 2006, Thomas Heller wrote: [...] As I said in the other thread (where the discussion should probably be continued anyway): http://mail.python.org/pipermail/python-dev/2006-January/060113.html only aclocal.m4 isn't clear to me about the license. Anyway, it could be that this file isn't needed after all - I don't know enough about the GNU toolchain to be sure. Can anyone comment on this? From 'info autoconf': | The Autoconf macros are defined in several files. Some of the files | are distributed with Autoconf; `autoconf' reads them first. Then it | looks for the optional file `acsite.m4' in the directory that contains | the distributed Autoconf macro files, and for the optional file | `aclocal.m4' in the current directory. Those files can contain your | site's or the package's own Autoconf macro definitions (*note Writing [...] So, I assume aclocal.m4 is under the same license as the rest of the libffi you're using. I cannot uinderstand your reasoning. How can 'info autoconf' incluence the license of the aclocal.m4 file? Or do I misunderstand something? Given that all kind of *nix experts are here on this list - can someone tell if aclocal.m4 is needed for building libffi at all or not? 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
[Python-Dev] (libffi) Re: Copyright issue
[I've added python-dev to cc:] Anthony Green [EMAIL PROTECTED] writes: On Fri, 2006-01-27 at 17:08 +0100, Thomas Heller wrote: Anyway, another question is: Is aclocal.m4 needed at all for building (or maybe for regenerating the configure scripts), or is it optional? aclocal.m4 is required, but is only used as a build-time tool. The fact that aclocal.m4 is distributed under the GPL should have no impact on the licensing terms used for software built using aclocal.m4. If I understand correctly this means that the Python source distribution would have to be GPL licensed, while the built programs would be able to use another license. I'm pretty sure this kills the whole idea (to include libffi in python). 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] DRAFT: python-dev Summary for 2006-01-01 through 2006-01-15
On 27-jan-2006, at 17:14, Thomas Heller wrote: John J Lee [EMAIL PROTECTED] writes: On Thu, 26 Jan 2006, Thomas Heller wrote: [...] As I said in the other thread (where the discussion should probably be continued anyway): http://mail.python.org/pipermail/python-dev/2006-January/060113.html only aclocal.m4 isn't clear to me about the license. Anyway, it could be that this file isn't needed after all - I don't know enough about the GNU toolchain to be sure. Can anyone comment on this? From 'info autoconf': | The Autoconf macros are defined in several files. Some of the files | are distributed with Autoconf; `autoconf' reads them first. Then it | looks for the optional file `acsite.m4' in the directory that contains | the distributed Autoconf macro files, and for the optional file | `aclocal.m4' in the current directory. Those files can contain your | site's or the package's own Autoconf macro definitions (*note Writing [...] So, I assume aclocal.m4 is under the same license as the rest of the libffi you're using. I cannot uinderstand your reasoning. How can 'info autoconf' incluence the license of the aclocal.m4 file? Or do I misunderstand something? Given that all kind of *nix experts are here on this list - can someone tell if aclocal.m4 is needed for building libffi at all or not? aclocal.m4 is needed to build configure, it's a library of configure fragments. I try to stay away from configure as far as possible so cannot say if those fragments are really needed. Ronald smime.p7s Description: S/MIME cryptographic signature ___ 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
Anthony Green [EMAIL PROTECTED] writes: On Fri, 2006-01-27 at 18:03 +0100, Thomas Heller wrote: [I've added python-dev to cc:] Anthony Green [EMAIL PROTECTED] writes: On Fri, 2006-01-27 at 17:08 +0100, Thomas Heller wrote: Anyway, another question is: Is aclocal.m4 needed at all for building (or maybe for regenerating the configure scripts), or is it optional? aclocal.m4 is required, but is only used as a build-time tool. The fact that aclocal.m4 is distributed under the GPL should have no impact on the licensing terms used for software built using aclocal.m4. If I understand correctly this means that the Python source distribution would have to be GPL licensed, while the built programs would be able to use another license. I'm pretty sure this kills the whole idea (to include libffi in python). I guess I wasn't clear. aclocal.m4 is just a tool used to build libffi. Like your C compiler. Bundling it with the Python source distribution should have no impact on the licensing of Python itself, since it isn't really part of the resulting Python binary - just like your C compiler isn't. I guess I understood this already. The difference to the C compiler is that the compiler is not 'bundled' with Python, it is installed separately. Can anyone of the python-dev core team comment: can we live with the GPL licensed aclocal.m4 file, in the source distribution and in SVN? 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
Thomas Heller [EMAIL PROTECTED] wrote: On Fri, 2006-01-27 at 17:08 +0100, Thomas Heller wrote: Anyway, another question is: Is aclocal.m4 needed at all for building (or maybe for regenerating the configure scripts), or is it optional? aclocal.m4 is required, but is only used as a build-time tool. The fact that aclocal.m4 is distributed under the GPL should have no impact on the licensing terms used for software built using aclocal.m4. If I understand correctly this means that the Python source distribution would have to be GPL licensed, while the built programs would be able to use another license. I'm pretty sure this kills the whole idea (to include libffi in python). I guess I wasn't clear. aclocal.m4 is just a tool used to build libffi. Like your C compiler. Bundling it with the Python source distribution should have no impact on the licensing of Python itself, since it isn't really part of the resulting Python binary - just like your C compiler isn't. I guess I understood this already. The difference to the C compiler is that the compiler is not 'bundled' with Python, it is installed separately. That's no different. If you burn a CD containing a copy of the GCC and a copy of a commercial software you are not violating any license. If you distribute an .ISO file containing a copy of the GCC and a copy of a commercial software, you are not violating any license. If you distribute a .zip file containing a copy of GCC and a copy of a commercial software, you are not violating any license. There is an important difference between aggreggation of different programs, and static/dynamic linking of parts. Autoconf is a build tool, and it does not impose any license on the software you use it with. Plus some files have the special exception from GPL so that even the files *generated* by autoconf (and partly made of pieces of autoconf) do not require to be GPL. This is exactly like GCC's runtime library (libgcc, and also libstdc++) which are GPL with the special exception, and you can use them also for commercial products. Also, do not understimate previous history. There are zillions of programs out there using Autconf and *not* being GPL. -- Giovanni Bajo ___ 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 Fri, 27 Jan 2006, Thomas Heller wrote: John J Lee [EMAIL PROTECTED] writes: On Thu, 26 Jan 2006, Thomas Heller wrote: only aclocal.m4 isn't clear to me about the license. Anyway, it could be that this file isn't needed after all - I don't know enough about the GNU toolchain to be sure. Can anyone comment on this? From 'info autoconf': | The Autoconf macros are defined in several files. Some of the files | are distributed with Autoconf; `autoconf' reads them first. Then it | looks for the optional file `acsite.m4' in the directory that contains | the distributed Autoconf macro files, and for the optional file | `aclocal.m4' in the current directory. Those files can contain your | site's or the package's own Autoconf macro definitions (*note Writing [...] So, I assume aclocal.m4 is under the same license as the rest of the libffi you're using. I cannot uinderstand your reasoning. How can 'info autoconf' incluence the license of the aclocal.m4 file? Or do I misunderstand something? OK. I now notice I was confused as to why the license issue arose in the first place, but FWIW: My point was just that the autoconf info pages explain (if I read them right) that one keeps one's project-specific autoconf m4 macros in a file named 'aclocal.m4'. It's not a file distributed with autoconf, it's just a file naming convention, so I made the assumption that since libffi is apparently OK to include in Python, so must be its aclocal.m4 (even if some of the macros in the libffi aclocal.m4 originally derived from some other project). But I'm afraid this would fail with an AssertionError if it weren't pseudocode: import legally_compatible as compat from autoconf import acfiles from ctypes import libffi if compat(acfiles, libffi) and compat(libffi, python): assert compat(acfiles, python), John is not legally competent :-( John ___ 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
Andrew Pinski [EMAIL PROTECTED] writes: Does phython already use autoconf? I think it does, if so then there should be no issues. [Anthony Green] I guess I wasn't clear. aclocal.m4 is just a tool used to build libffi. Like your C compiler. Bundling it with the Python source distribution should have no impact on the licensing of Python itself, since it isn't really part of the resulting Python binary - just like your C compiler isn't. [Thomas Heller] I guess I understood this already. The difference to the C compiler is that the compiler is not 'bundled' with Python, it is installed separately. Giovanni Bajo [EMAIL PROTECTED] writes: That's no different. If you burn a CD containing a copy of the GCC and a copy of a commercial software you are not violating any license. If you distribute an .ISO file containing a copy of the GCC and a copy of a commercial software, you are not violating any license. If you distribute a .zip file containing a copy of GCC and a copy of a commercial software, you are not violating any license. There is an important difference between aggreggation of different programs, and static/dynamic linking of parts. Autoconf is a build tool, and it does not impose any license on the software you use it with. Plus some files have the special exception from GPL so that even the files *generated* by autoconf (and partly made of pieces of autoconf) do not require to be GPL. This is exactly like GCC's runtime library (libgcc, and also libstdc++) which are GPL with the special exception, and you can use them also for commercial products. Also, do not understimate previous history. There are zillions of programs out there using Autconf and *not* being GPL. Ok, understood - there is no problem. Hopefully the rest of the pythondev team is also convinced. The only question I have (maybe this is too off-topic, but since we're here already): Nearly all the tools that autoconf and automake use are careful to include an exception clause to the GPL license. Why is aclocal.m4 different? 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] DRAFT: python-dev Summary for 2006-01-01 through 2006-01-15
Thomas == Thomas Heller [EMAIL PROTECTED] writes: Thomas I cannot uinderstand your reasoning. How can 'info Thomas autoconf' incluence the license of the aclocal.m4 file? It doesn't. The point is the documentation explains that all of the other files are _part of autoconf_, and come under the license of autoconf. They come with special additional rights for users so that the GPL does *not* apply to a project simply because the project uses a configure script generated by autoconf. The aclocal file is not part of autoconf and so doesn't come under that license, but rather the license its author gives it. Presumably that is the same as the rest of the application (here libffi, since an aclocal for libffi was almost certainly written by a libffi developer). Thomas Given that all kind of *nix experts are here on this list Thomas - can someone tell if aclocal.m4 is needed for building Thomas libffi at all or not? Not if libffi is distributed with a prebuilt configure script. Otherwise, not using the distributed aclocal.m4 may be possible, but it's a bad idea. -- 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
Re: [Python-Dev] / as path join operator
It's controversial that Path subclasses str. Some people think it's
flat-out wrong. Even Bjorn argues that it's a practicality-vs-purity
tradeoff. But a strong argument can be made that Path *should* be a
string subclass, practicality be damned. Proof follows.
I. Here's an example of the sort of thing you might say if you did
*not* think of paths as strings:
On 1/25/06, Stephen J. Turnbull [EMAIL PROTECTED] wrote:
I think it's logical to expect that
Path('home') / 'and/or'
points to a file named and/or in directory home, not to a file
named or in directory home/and.
This makes no sense whatsoever. Ergo, by reductio ad absurdum, paths
are strings.
II. And here is the sort of thing you'd say if you thought of paths
*solely* as strings:
(2) Note that '/' is also the path separator used by URIs, which RFC
2396 gives different semantics from Unix. Most of my Python usage to
date has been heavily web-oriented, and I'd have little use for /
unless it follows RFC 2396.
The quandary is resolved by pointing out that URIs are not paths (in
the sense of os.path and generally this whole horrible thread). Thus
not all strings are paths.
Hence the paths are a proper subset of the strings. By the existence
of os.path, they have their own commonly-used operations. By
definition, then, Path is a subclass of string, QED.
Do I really buy all this? I dunno. To say paths aren't strings is
all very well, and in a very abstract sense I almost agree--but you
have to admit it sort of flies in the face of, you know, reality.
Filesystem paths are in fact strings on all operating systems I'm
aware of. And it's no accident or performance optimization. It's
good design.
-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] (libffi) Re: Copyright issue
Thomas Heller wrote: Can anyone of the python-dev core team comment: can we live with the GPL licensed aclocal.m4 file, in the source distribution and in SVN? My understanding that doing so would be in violation of section 2b) of the GPL. However, I still think it is possible to include libffi - we just have to discard the build process, and do our own. 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] / as path join operator
On Fri, Jan 27, 2006 at 06:19:52PM -0500, Jason Orendorff wrote: To say paths aren't strings is all very well, and in a very abstract sense I almost agree--but you have to admit it sort of flies in the face of, you know, reality. Filesystem paths are in fact strings on all operating systems I'm aware of. And it's no accident or performance optimization. It's good design. The question isn't whether Path objects should *act* like strings. I haven't seen anyone argue that they shouldn't, except for a few specific aspects, like iteration, and those are argued on both sides of the subclassing camp. The question is whether they should be actual subclasses of the Python string type. As for what platforms do, if we want to stick to the platform handling of paths, we change nothing. That's apparently not what people want ;) -- 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] (libffi) Re: Copyright issue
Giovanni Bajo wrote: That's no different. If you burn a CD containing a copy of the GCC and a copy of a commercial software you are not violating any license. If you distribute an .ISO file containing a copy of the GCC and a copy of a commercial software, you are not violating any license. If you distribute a .zip file containing a copy of GCC and a copy of a commercial software, you are not violating any license. You misunderstand the GPL. Section 2b) is pretty clear that any application that contains GPL-licensed code must be, itself, distributed under the terms ofthe GPL b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License. It further elaborates (in 2, below c) that you could distribute identifiable sections of [your] work [which] are not derived from the Program separately, as long as you omit the Program. But if you distribute them as a whole, the whole must be licensed under the GPL. There is an important difference between aggreggation of different programs, and static/dynamic linking of parts. There is an exception for mere aggregation: # In addition, mere aggregation of another work not based on the Program # with the Program (or with a work based on the Program) on a volume of # a storage or distribution medium does not bring the other work under # the scope of this License. However, inclusion of aclocal.m4 isn't mere aggregation [...] on a volume of storage. aclocal.m4 is an essential part of the software as a whole, so 2b) applies. Also, do not understimate previous history. There are zillions of programs out there using Autconf and *not* being GPL. Yes, and SCO is (rightly, IMO) complaining that zillions of open source people do not honor IP properly. That doesn't mean Python should follow. Instead, it means we need a build process for libffi which is independent of autoconf (or convince the authors of aclocal.m4 to relicense it, but that is likely futile). As a matter of fact, Python itself uses autoconf, but without aclocal.m4. autoconf generates configure for us, but configure is not GPL-licensed, even though it is generated through autoconf: # Copyright (C) 2003 Free Software Foundation, Inc. # This configure script is free software; the Free Software Foundation # gives unlimited permission to copy, distribute and modify it. 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
Stephen J. Turnbull wrote: Otherwise, not using the distributed aclocal.m4 may be possible, but it's a bad idea. That may not be so bad, actually. It looks like libffi's aclocal.m4 is not hand-written, but generated through aclocal(1). Not sure why this is done, but this seems to be the cause of the explicit mentionings of the GPL (the snippets that aclocal.m4 is generated from are each GPL-licensed, make the whole aclocal.m4 GPL-licensed). That said, I'm uncertain as to what the purpose of aclocal(1) is, so I might be wrong. 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
Ronald Oussoren wrote: Merging the two configure files might be a good idea anyway, that would take away the need to run configure from setup.py. IANAL, but I don't quite get how a GPL'd support script, if there is such a thing, in the build machinery of an extension library would require that Python itself is GPL'd. Section 2b) of the GPL. If a part of the program is GPL, the entire program must be. Also, you must include the entire source of the program, including all build scripts (section 3). So just including the generated configure, and omitting some of its input, would also be a license violation. 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] (libffi) Re: Copyright issue
Thomas Heller [EMAIL PROTECTED] wrote: Andrew Pinski [EMAIL PROTECTED] writes: Does phython already use autoconf? I think it does, if so then there should be no issues. [Anthony Green] I guess I wasn't clear. aclocal.m4 is just a tool used to build libffi. Like your C compiler. Bundling it with the Python source distribution should have no impact on the licensing of Python itself, since it isn't really part of the resulting Python binary - just like your C compiler isn't. [Thomas Heller] I guess I understood this already. The difference to the C compiler is that the compiler is not 'bundled' with Python, it is installed separately. Giovanni Bajo [EMAIL PROTECTED] writes: That's no different. If you burn a CD containing a copy of the GCC and a copy of a commercial software you are not violating any license. If you distribute an .ISO file containing a copy of the GCC and a copy of a commercial software, you are not violating any license. If you distribute a .zip file containing a copy of GCC and a copy of a commercial software, you are not violating any license. There is an important difference between aggreggation of different programs, and static/dynamic linking of parts. Autoconf is a build tool, and it does not impose any license on the software you use it with. Plus some files have the special exception from GPL so that even the files *generated* by autoconf (and partly made of pieces of autoconf) do not require to be GPL. This is exactly like GCC's runtime library (libgcc, and also libstdc++) which are GPL with the special exception, and you can use them also for commercial products. Also, do not understimate previous history. There are zillions of programs out there using Autconf and *not* being GPL. Ok, understood - there is no problem. Hopefully the rest of the pythondev team is also convinced. The only question I have (maybe this is too off-topic, but since we're here already): Nearly all the tools that autoconf and automake use are careful to include an exception clause to the GPL license. Why is aclocal.m4 different? Is aclocal.m4 even GPL in the first place? I don't see such a notice in my libffi copy. Giovanni Bajo ___ 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
Martin v. Löwis [EMAIL PROTECTED] wrote: Can anyone of the python-dev core team comment: can we live with the GPL licensed aclocal.m4 file, in the source distribution and in SVN? My understanding that doing so would be in violation of section 2b) of the GPL. This would be a new interpretation of the license. The whole autotools chain is GPL and it is used on way too many programs which are not GPL. They're so many I won't even mention one. Anyway, IANAL, so if you're really concerned you can mail the FSF and ask clarifications. BTW, by your reading, libffi itself would be a GPL violation. Giovanni Bajo ___ 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] SourceForge Download Page, Subversion Home Page
Tim Peters wrote: Overall I'm not sure that's an improvement, but it was the best I could come up with 2 years ago when ZODB stopped using SF for downloads. Please take a look at my attempt to solve that: putting a text just above the button. 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] (libffi) Re: Copyright issue
Giovanni Bajo wrote: This would be a new interpretation of the license. The whole autotools chain is GPL and it is used on way too many programs which are not GPL. They're so many I won't even mention one. Anyway, IANAL, so if you're really concerned you can mail the FSF and ask clarifications. No. As Tom Tromey explains, significant parts of autoconf have a special exception, allowing parts of autoconf to be used without any restrictions when they get copied into, say, configure. If you only use those parts of autoconf, you don't violate the GPL. However, it appears that (at least parts of) aclocal.m4 originate from code which doesn't have such a liberal license. BTW, this interpretation isn't new at all. I first heard it in 1992. People tend to reinterpret it because they can't believe the original words, and then those interpretations become urban myth. BTW, by your reading, libffi itself would be a GPL violation. Well, no. I interpret it to be dual-licensed: Identifiable parts of it are independent work, and can be licensed independently of the Program (i.e. autoconf). They meet all requirements of the GPL (providing all code they need to provide) - it's just difficult to find out what the license is. 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] Path inherits from string
[M.-A. Lemburg]
I don't see why this is critical for the success of the Path
object. I agree with Thomas that interfaces should be made
compatible to Path object.
See the steps I mentioned. Unless step #1 is completed there is no way
to make the following code work:
open(Path(foobar))
Well, there is one alternative which is:
open(Path(foobar).tostring())
And that is a Java-esque workaraound that I think noone would be happy
with.
Why not ? We've added Unicode support to at least some
file I/O APIs - adding support for instances which
support the string interface shouldn't be all that
difficult :-)
BTW, if you're fine with this API:
class File:
def __unicode__(self):
return utest.txt
then the required change is minimal: we'd just need to
use PyObject_Unicode() in getargs.c:837 and you should
be set.
Alright! If that is true then maybe step #1 isn't as hard as I
thought. First problem is the string interface. What exactly is the
string interface? It needs to be specified. I would have guessed that
it was equal to the stuff in the builtin str class.. :) Then you need
to modify Python's C code so that it accepts all objects implementing
the string interface. That may not be a trivial task [1]. Also don't
forget that Path probably also should work with:
isinstance(Path('.'), basestring)
Because one of the big selling points of Path is that it acts as a
drop-in replacement for strings [2]. And you don't want to mess with
the current canonical way of testing if an object implements the
string interface. But you aren't supposed to subclass basestring
[3].
All I'm saying is that I don't have the technical knowledge required
to modify Python to make Path work without subclassing string. If you,
or someone else, do then pretty please with sugar on top make a patch
so that Path doesn't have to subclass string.
Then you could have a much more pure Path without the dead
methods. But even then, one could argue that Jason Orendorffs original
Path module is still more practical (atleast for compatibility
reasons).
def save_data(somedir, fpath, data):
open(somedir + / + fpath.lower(), w).write(data)
The above code isn't going to work unless fpath is a string (or an
object that inherits from string). It isn't good code, but it isn't
extremely uncommon either.
1 http://mail.python.org/pipermail/python-dev/2006-January/059780.html
2 http://mail.python.org/pipermail/python-list/2005-July/291213.html
3 http://mail.python.org/pipermail/python-dev/2006-January/059782.html
--
mvh Björn
___
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
[Jason Orendorff] Filesystem paths are in fact strings on all operating systems I'm aware of. And it's no accident or performance optimization. It's good design. Isn't that simply because filesystems aren't object orientated? I can't call methods of a path through the filesystem. There's a difference between a path, which is, yes, always (?) a string, and a Path object that provides convenient methods/properties. (Maybe one of the experimental object-orientated file systems has non- string paths. I have no idea). =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] SourceForge Download Page, Subversion Home Page
Martin v. Löwis wrote: Tim Peters wrote: Overall I'm not sure that's an improvement, but it was the best I could come up with 2 years ago when ZODB stopped using SF for downloads. Please take a look at my attempt to solve that: putting a text just above the button. Is it possible to make that URL a hyperlink? It's also worth considering ways to make the alternate URL stand out more, as the green button is dominant enough that I'd expect a lot of people to miss the preceding text. Something like: The Python programming language, an object-oriented scripting and rapid application development language. Despite what the green button below says, you can bNOT/b download it directly from Sourceforge, as SF is used only for bug tracking. You can get releases from the main Python website: a href=http://www.python.org/download;Download from python.org/a useless green button is here Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.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] Path inherits from string
Ian Bicking [EMAIL PROTECTED] wrote: OTOH, str(path) will break unicode filenames. And unicode() breaks anything that simply desires to pass data through without effecting its encoding. That general problem was the motivation for PEP 349. Originally I suggested adding a new built-in. However, Guido's suggestion of allowing str() to return unicode objects works okay too and that's the way the current PEP is written. With Python 2.5 you can do it the ugly way using a str format (e.g. '%s' % obj). Neil ___ 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/27/06, Jason Orendorff [EMAIL PROTECTED] wrote:
On 1/25/06, Stephen J. Turnbull [EMAIL PROTECTED] wrote:
I think it's logical to expect that
Path('home') / 'and/or'
points to a file named and/or in directory home, not to a file
named or in directory home/and.
This makes no sense whatsoever. Ergo, by reductio ad absurdum, paths
are strings.
It makes perfect sense to me. However, since posix doesn't permit '/'
in file names I would expect it to emit an error:
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
However, I'm not sure if the error be emitted when the Path is
created, or when it's passed to open(). The former implies a set of
OS-specific Path classes, and would allow subclassing from str. The
latter allows (but does not require) a single universal Path class,
and that would prohibit subclassing from str (because you need a
higher-level representation to store path segments before converting
them to a platform-specific format.)
I'm -0 on subclassing str in the shortterm and -1 on it in the
longterm. It's cruft and not something we want to be stuck with.
--
Adam Olsen, aka Rhamphoryncus
___
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
Jason == Jason Orendorff [EMAIL PROTECTED] writes: Jason I. Here's an example of the sort of thing you might say if Jason you did *not* think of paths as strings: [...] Jason II. And here is the sort of thing you'd say if you thought Jason of paths *solely* as strings: Please note that my point was entirely different from trying to decide whether to subclass strings. My point was precisely that because of this schizophrenia in the use of / as a path join operator in various string representations of paths, it's a bad choice. People are naturally going to write buggy code because they don't have the implemented spec in mind. 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. Of course there's a string representation, especially for human use, but manipulating that representation as a string in programs is a regular source of bugs. In most cases, the graph is sufficiently constrained that string manipulations are mostly accurate representations of graph traversal, but not always, and you get defects. -- 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
