> "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 strin
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".
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. Ho
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
[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
[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"))
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 clarific
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
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 i
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
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 requir
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
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.
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 sys
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 libff
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" == 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_,
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
>>> d
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 tool
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 onl
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 n
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.
[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 re
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
[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
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.pytho
[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 kn
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
[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".
> Whil
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
>>
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-chec
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 n
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 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 tha
34 matches
Mail list logo
