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?
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
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
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
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
[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
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
[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.
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
[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
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
[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,
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):
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
[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))
[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
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
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.
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
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
34 matches
Mail list logo
