Guido van Rossum wrote:
>>Well, that's pretty bizarre. There's _obviously_ no way to get to a
>>reference to `e` without going through
>>
>>x = _PyLong_AsScaledDouble(vv, &e);
>>
>>first. That isn't a useful warning.
>
>
> But how can the compiler know that it is an output-only argument
Tim Peters wrote:
>>I noticed a few compiler warnings, when I compile Python on my amd64 with
>>gcc 4.0.3:
>>
>>Objects/longobject.c: In function 'PyLong_AsDouble':
>>Objects/longobject.c:655: warning: 'e' may be used uninitialized in this
>>function
>
>
> Well, that's pretty bizarre. There's _
Robert Kim Wireless Internet Advisor <[EMAIL PROTECTED]> wrote:
> u guys are way over my head :)
> bob
You seem to be new to the python-dev mailing list. As a heads-up,
python-dev is for the development _of_ python. If you are using Python,
and want help or want to help others using Python, you
Sorry, I didn't follow up here like I should have, and I haven't
followed the rest of this conversation, so apologies if I am being
redundant...
Fuzzyman wrote:
>>While ConfigParser is okay for simple configuration, it is (IMHO) not a
>>very good basis for anyone who wants to build better syste
On 1/31/06, Robert Kim Wireless Internet Advisor <[EMAIL PROTECTED]> wrote:
> u guys are way over my head :)
> bob
>
>
> --
> Robert Kim
> 2611s Highway 101
> suite 102
> San diego CA 92007
> 206 984 0880
>
Stop spamming our list.
Jeremy
___
Python-Dev
On Jan 31, 2006, at 8:16 PM, Tim Peters wrote:
> [Thomas Wouters]
>> I noticed a few compiler warnings, when I compile Python on my
>> amd64 with
>> gcc 4.0.3:
>>
>> Objects/longobject.c: In function 'PyLong_AsDouble':
>> Objects/longobject.c:655: warning: 'e' may be used uninitialized
>> in
u guys are way over my head :)
bob
--
Robert Kim
2611s Highway 101
suite 102
San diego CA 92007
206 984 0880
http://evdo-coverage.com/cellular-repeater.html
On 1/31/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 1/31/06, Tim Peters <[EMAIL PROTECTED]> wrote:
> > [Thomas Wouters]
> > > Obj
[Tim]
>> Well, that's pretty bizarre. There's _obviously_ no way to get to a
>> reference to `e` without going through
>>
>> x = _PyLong_AsScaledDouble(vv, &e);
>>
>> first. That isn't a useful warning.
[Guido]
> But how can the compiler know that it is an output-only argument?
In the a
On 1/31/06, Tim Peters <[EMAIL PROTECTED]> wrote:
> [Thomas Wouters]
> > Objects/longobject.c:655: warning: 'e' may be used uninitialized in this
> > function
>
> Well, that's pretty bizarre. There's _obviously_ no way to get to a
> reference to `e` without going through
>
> x = _PyLong_A
[Thomas Wouters]
> I noticed a few compiler warnings, when I compile Python on my amd64 with
> gcc 4.0.3:
>
> Objects/longobject.c: In function 'PyLong_AsDouble':
> Objects/longobject.c:655: warning: 'e' may be used uninitialized in this
> function
Well, that's pretty bizarre. There's _obviously
2006/1/31, Bengt Richter <[EMAIL PROTECTED]>:
> In that case, could I also make a pitch for the letter c which would similarly
> follow a radix (in decimal) but would introduce the rest of the number as
> a radix-complement signed number, e.g., -2, 16cfe, 8c76, 2c110, 10c98 would
> all have the sa
2006/1/30, Fredrik Lundh <[EMAIL PROTECTED]>:
> fwiw, I've *never* used INI files to store program state, and I've
> never used the save support in ConfigParser.
As a SiGeFi developing decision, we obligated us to keep the program
state between executions (hey, if I set the window this big, I wan
On Tue, 31 Jan 2006 17:17:22 -0500, "Andrew Koenig" <[EMAIL PROTECTED]> wrote:
>> Apart from making 0640 a syntax error (which I think is wrong too),
>> could this be solved by *requiring* the argument to be a string? (Or
>> some other data type, but that's probably overkill.)
>
>That solves the p
On Jan 31, 2006, at 3:09 PM, Tim Parkin wrote:
> Georg Brandl wrote:
>> 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
Georg Brandl wrote:
> 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 occas
> Apart from making 0640 a syntax error (which I think is wrong too),
> could this be solved by *requiring* the argument to be a string? (Or
> some other data type, but that's probably overkill.)
That solves the problem only in that particular context.
I would think that if it is deemed undesirab
On 1/31/06, Andrew Koenig <[EMAIL PROTECTED]> wrote:
> > Possibly os.chmod and os.umask could be extended to take a string
> > argument so we could write chmod(path, "0640").
>
> -1.
>
> Would you really want chmod(path, 0640) and chmod(path, "0640") to have
> different meanings?
Apart from making
On Tue, Jan 31, 2006 at 09:04:39PM +0100, "Martin v. Löwis" wrote:
> Thomas Wouters wrote:
> > All in all, it seems like a timing issue -- the timing is different because
> > the previous test already imported some modules. The test_logging test uses
> > threads, *ugh*. I tried adding a few Event-w
On 1/31/06, Tony Meyer <[EMAIL PROTECTED]> wrote:
> Why doesn't this work? It does here:
>
> $ cat suite.ini
> [sect]
> opt1 = 1
> opt2 = 2
> $ cat app.ini
> [sect]
> opt1 = 3
> opt4 = 5
> $ python
> Python 2.4.1 (#2, Mar 31 2005, 00:05:10)
> [GCC 3.3 20030304 (Apple Computer, Inc. build 1666)] on
On Tuesday 31 January 2006 14:55, Andrew Koenig wrote:
> Would you really want chmod(path, 0640) and chmod(path, "0640") to have
> different meanings?
Actually, the proposal that suggested this also proposed that 0640 would raise
a SyntaxError, since it was all about getting rid of octal litera
On Tue, Jan 31, 2006 at 08:57:18PM +0100, Georg Brandl wrote:
> While we're at it, is the Python library going to incorporate some YAML
> parser in the future? YAML seems like a perfectly matching data format
> for Python.
JSON is even better!
Oleg.
--
Oleg Broytmannhttp://ph
Thomas Wouters wrote:
> All in all, it seems like a timing issue -- the timing is different because
> the previous test already imported some modules. The test_logging test uses
> threads, *ugh*. I tried adding a few Event-waits and time.sleep()'s at
> strategic places, but it doesn't seem to matte
Andrew Koenig <[EMAIL PROTECTED]> wrote:
>> Possibly os.chmod and os.umask could be extended to take a string
>> argument so we could write chmod(path, "0640").
>
>-1.
>
>Would you really want chmod(path, 0640) and chmod(path, "0640") to have
>different meanings?
I want the former to be a syntax
[Paul Moore]
> * No way to merge files or sections. Usually to provide default
> values. I have a suite of applications, all using the same framework.
> I have a hardcoded DEFAULT_CONFIG in the code, overriden by a
> .ini, overridden again by a .ini. OK, maybe it's
> overengineered, but I do use th
[Scott Dial]
[Re: http://python.org/sf/1410680]
> I've spent a small amount of time playing with this patch, and the
> intent is there, but it appears to have some obvious bugs with adding
> blank lines and (at least) making an empty [DEFAULT] section appear
> and
> disappear. I'm not sure that
Guido van Rossum 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 the entries will never be modified by a user -
> Possibly os.chmod and os.umask could be extended to take a string
> argument so we could write chmod(path, "0640").
-1.
Would you really want chmod(path, 0640) and chmod(path, "0640") to have
different meanings?
___
Python-Dev mailing list
Python-
Guido van Rossum <[EMAIL PROTECTED]> wrote:
>Right. And this is not a hypothetical issue either -- in Perl, hex and
>oct *do* work the other way I believe. More reasons to get rid of
>these in Python 3000. Perhaps we should also get rid of hex/oct
>lterals?
I would like to argue for removing oct
Michael Foord wrote:
> Tony Meyer wrote:
>> [Guido van Rossum]
>> Add 'surgical editing' to ConfigParser
>> http://python.org/sf/1410680
>> Adds an update_file method (no other changes) that updates the given
>> file to match the current configuration, preserving blank lines,
>> comments,
On Tue, Jan 31, 2006 at 06:04:45PM +0100, "Martin v. Löwis" wrote:
> Thomas Wouters wrote:
> > I also noticed test_logging is spuriously failing, and not just on my
> > machine (according to buildbot logs.) Is anyone (Vinay?) looking at that
> > yet?
> I looked at it, and I couldn't figure it out.
anybody here?
bob
2611 s highway 101
san diego, ca 92007
209 984 0880
http://evdo-coverage.com/cell-phone-antenna-booster.html
--
Robert Q Kim, Wireless Internet Advisor
http://evdo-coverage.com/cellular-repeater.html
http://hsdpa-coverage.com
2611 S. Pacific Coast Highway 101
Suite 102
On Mon, 2006-01-30 at 16:44 -0500, Tim Peters wrote:
> OTOH, I have no reason to _presume_ that this is their hoped-for
> outcome wrt Python, neither to presume that the politics shaping their
> tussle with Aladdin are relevant to the PSF. "The law" is rarely
> applied uniformly, in large part be
Thomas Wouters wrote:
> I also noticed test_logging is spuriously failing, and not just on my
> machine (according to buildbot logs.) Is anyone (Vinay?) looking at that
> yet?
I looked at it, and I couldn't figure it out. It appears that the last
line of communication is somehow lost, but I could
Fuzzyman voidspace.org.uk> writes:
> In my opinion dictionary syntax is the most natural way to represent a
> config file - it is a data structure with named members. This means the
> API for accessing the data - whether from a subclass that does
> additional value processing or from code that ju
Tony Meyer wrote:
> [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
Paul Moore wrote:
> On 1/30/06, Guido van Rossum <[EMAIL PROTECTED]> 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
>>
I noticed a few compiler warnings, when I compile Python on my amd64 with
gcc 4.0.3:
Objects/longobject.c: In function ‘PyLong_AsDouble’:
Objects/longobject.c:655: warning: ‘e’ may be used uninitialized in this
function
Objects/longobject.c: In function ‘long_true_divide’:
Objects/longobject.c:2
On 1/30/06, Guido van Rossum <[EMAIL PROTECTED]> 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
> "Jason" == Jason Orendorff <[EMAIL PROTECTED]> writes:
Jason> You seem to think that because I said "operating systems",
Jason> I'm talking about kernel algorithms and such.
I can see how you'd get that impression, but it's not true. My reason
for mentioning OS-level filesystem was
> "Tim" == Tim Peters <[EMAIL PROTECTED]> writes:
Tim> I'm not making myself clear.
Whatever makes you think that? In fact, everything you've said
about your criteria for behavior was quite clear from the first, and
it was fairly easy to infer your beliefs about the implications of
histor
40 matches
Mail list logo
