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.
Vinay Sajip wrote:
Fuzzyman fuzzyman at 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
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
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
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') /
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
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
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
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
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
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
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
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
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
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
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
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
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
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
[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,
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
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.
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
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
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
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
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
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
[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
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
[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
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
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
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.
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
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
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.
[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
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
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
40 matches
Mail list logo
