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 (
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
[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 __fu
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 existi
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
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 ha
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. Cur
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
__
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 sto
[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.o
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 deve
[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
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.
>>
>>
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
> (f
> 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 Spo
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
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 t
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
>> und
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 env
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 a
[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 a
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 cha
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
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 breaki
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
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 t
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 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.
>
>
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.
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
>
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.
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.
>
>
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
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 Co
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 diffe
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 h
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'
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 chan
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 inden
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
> "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
41 matches
Mail list logo