Re: [Python-Dev] DRAFT: python-dev Summary for 2006-01-01 through 2006-01-15
> "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 history. I just wanted to state that there is a clear precedent of an FSF complaint about exactly what Python is doing. -- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of TsukubaTennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] / as path join operator
> "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 to show that even in that limited domain, treating paths as strings leads to bugs. Jason> I think paths are used more for communication, less for Jason> computation. True. For that purpose it is absolutely essential to have a string represention. However, I was discussing the use of "/" to invoke path composition, which is a computation. Nobody will use that for communication (except to describe a path expression in graph theoretic terms), and I don't think it's a good idea to use that particular symbol for that operation. -- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of TsukubaTennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Extension to ConfigParser
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 that too. As Joel Spolski points out in
> his book on UI design, most configuration options are signs of
> indecisive developers, and most users never change the defaults.)
While you're right that a lot of the comments people make about
ConfigParser are actually about INI files (e.g., no nested sections,
no "top-level" values), I do find that when I use ConfigParser, I
often need to write a wrapper around it to make it more usable.
A couple of examples, from a current application:
* 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 the various levels, so it's also
useful... (The defaults parameter to the constructor is misnamed,
AFAICT, as it's for interpolation defaults, not value defaults).
* A dictionary interface, or even attribute access (where the key
names are Python identifiers, which is usually the case), is usually
far cleaner to work with in code. For example, conf.log.level vs
conf.get('log', 'level'). But that may just be me - it's certainly a
style issue.
Nothing major, but worth considering.
I agree entirely that once you go beyond INI format, you should have a
new module. Of course, ConfigParser already allows more than basic INI
format ("key: value" lines, continuations, and substitution strings)
but we'll gloss over that... :-)
Paul.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Compiler warnings
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:2263: warning: ‘aexp’ may be used uninitialized in this function Objects/longobject.c:2263: warning: ‘bexp’ may be used uninitialized in this function Modules/linuxaudiodev.c: In function ‘lad_obuffree’: Modules/linuxaudiodev.c:392: warning: ‘ssize’ may be used uninitialized in this function Modules/linuxaudiodev.c: In function ‘lad_bufsize’: Modules/linuxaudiodev.c:348: warning: ‘ssize’ may be used uninitialized in this function Modules/linuxaudiodev.c: In function ‘lad_obufcount’: Modules/linuxaudiodev.c:369: warning: ‘ssize’ may be used uninitialized in this function Those are all fairly harmless, just the compiler can't figure out that they are never actually used when they aren't explicitly initialized, because the initialization happens a few functioncalls deeper into the callstack. This one: Python/marshal.c: In function ‘PyMarshal_ReadShortFromFile’: Python/marshal.c:410: warning: ‘rf.end’ is used uninitialized in this function Python/marshal.c:410: warning: ‘rf.ptr’ is used uninitialized in this function (The linenumber is off, it should be 884) is more of the same, except you can't tell from the function that it is a "can never happen" situation: if PyMarshal_ReadShortFromFile() was called with NULL as fp, it would actually use the uninitialized 'end' and 'ptr' struct members. An assert() is probably in place here. Should these warnings be fixed? I know Tim has always argued to fix them, in the past (and I agree,) and it doesn't look like doing so, by initializing the variables, wouldn't be too big a performance hit. 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? -- Thomas Wouters <[EMAIL PROTECTED]> Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Extension to ConfigParser
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
>> configurable. I disagree with that too. As Joel Spolski points out in
>> his book on UI design, most configuration options are signs of
>> indecisive developers, and most users never change the defaults.)
>>
>
> While you're right that a lot of the comments people make about
> ConfigParser are actually about INI files (e.g., no nested sections,
> no "top-level" values), I do find that when I use ConfigParser, I
> often need to write a wrapper around it to make it more usable.
>
> A couple of examples, from a current application:
>
> * 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 the various levels, so it's also
> useful... (The defaults parameter to the constructor is misnamed,
> AFAICT, as it's for interpolation defaults, not value defaults).
>
> * A dictionary interface, or even attribute access (where the key
> names are Python identifiers, which is usually the case), is usually
> far cleaner to work with in code. For example, conf.log.level vs
> conf.get('log', 'level'). But that may just be me - it's certainly a
> style issue.
>
> Nothing major, but worth considering.
>
> I agree entirely that once you go beyond INI format, you should have a
> new module. Of course, ConfigParser already allows more than basic INI
> format ("key: value" lines, continuations, and substitution strings)
> but we'll gloss over that... :-)
>
Well, ConfigObj is listed as an XML alternative at :
http://www.pault.com/pault/pxml/xmlalternatives.html
For complex configuration situations, many people feel that handcrafting
XML is not a fun alternative.
One of the driving forces behind ConfigObj was a firm that *used* to
have their system administrators using ZConfig, but wanted something
more friendly.
They have configuration files nested a few levels deep configuring
services, plugins, network details, etc. This is all properly
'application configuration'. (Not data persistence.)
The file format (and config structure) is easily visible from the files.
The config files are automatically validated from the schema
(configspecs) which also facilitate the automatic creation of new sections.
I *personally* think that this is a common use case and the format is a
natural extension of the 'INI-like' format. I'm happy for it to remain a
separate module (as indeed ConfigObj will). There are several valid
complaints about ConfigParser - and it is *possible* (although possibly
not desirable) to largely solve them all without breaking backwards
compatibility with ConfigParser.
Is it likely that an *additional* module could be added ? The suggestion
to narrow the ConfigObj API and not subclass dict (but still use the
mapping protocol) are interesting, and certainly not out of the
question. Nested sections however, are a significant part of the reason
for it's existence.
All the best,
Fuzzyman
http://www.voidspace.org.uk/python/index.shtml
> Paul.
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk
>
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Extension to ConfigParser
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 dict to allow ordering > http://python.org/sf/1371075 > Adds an optional argument to the constructor, the value of which will > be the class used to store the configuration data (so that a third- > party order-preserving dictionary class can be used). > > ConfigParser to save with order > http://python.org/sf/1399309 > Does a sort() of the sections and options before writing them. > > These first two patches don't seem to address the main issue, which is preserving the *original* order of the file. > 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, and order. [Disclaimer: this is my patch] > > This one however does, and if it does what it says on the box - is definitely worth accepting. All the best, Michael Foord http://www.voidspace.org.uk/python/index.shtml > =Tony.Meyer > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk > > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Extension to ConfigParser
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 just accesses the data. I agree with this, and also with Michael's comments that configuration is not just for the end user. (Alternatively, you could say that developers are end users too!) As a developer who works for many different clients, I find it saves me a fair amount of time when I have configurable software modules which I can put together to meet client requirements. The client doesn't need to see this "internal" configuration stuff - it's for developers and maintainers of the software, but very useful nonetheless! When I implemented my own config module (see http://www.red-dove.com/python_config.html), I decided not to use an INI-like format, as I found it wanting. The syntax I used is like Python and like JSON, but it is not executable (i.e. not Python) and allows bits of the configuration to refer to other bits of the configuration, provides some restricted evaluation of values such as "sys.stderr" but in a general way, readily allows defaults at different levels (e.g. user, program, suite), handles repeating values and mappings, uses dict or attribute syntax etc. - and all in a single 1500-line module, since I didn't have to implement INI support. What I'd like to know is, what happens how? There are a whole lot of alternatives put forward in the ConfigParserShootout wiki page, but how do we move things forward from here? Regards, Vinay Sajip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Compiler warnings
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 not find out why that might happen. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] DRAFT: python-dev Summary for 2006-01-01 through 2006-01-15
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 because it usually is means rather > than end. 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. I agree, and suggest we do nothing unless the FSF asks us to. -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] (no subject)
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 Cardiff by the Sea, CA 92007 206 984 0880 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Compiler warnings
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. It appears that the last > line of communication is somehow lost, but I could not find out why that > might happen. Not just the last line, see below. It never happens, as far as I can tell, when the test_logging test is run alone; it never once broke in several hundred solo tests. When I ran all combinations of a non-logging test followed by test_logging, it seems to break fairly randomly with almost all tests. Certainly not just tests that deal with signals, subprocesses, threads or sockets, also with tests like test_dircache, test_cookielib, test_coding, test_filecmp, and others. Just about the only correlation that makes sense is the duration of the first test. Not all of the other tests trigger test_logging's failure in any degree of reliability, although I get the feeling tests that take longer trigger the bug more often -- except that a test consisting of 'time.sleep(30)' never triggered it. 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 matter. Regardless of my pinpointing efforts, much more than just the last line is sometimes missing, though: $ ./python -E -tt Lib/test/regrtest.py -uall test_dircache test_logging test_dircache test_logging test test_logging produced unexpected output: ** *** line 515 of expected output missing: - DEB -> WARNING: Message 16 (via logrecv.tcp.DEB) *** line 521 of expected output missing: - UNDEF -> INFO: Message 22 (via logrecv.tcp.UNDEF) *** line 524 of expected output missing: - INF -> INFO: Finish up, it's closing time. Messages should bear numbers 0 through 24. (via logrecv.tcp.INF) ** I've 'seen' at least all messages between 16 and 22 disappear, although not more than 3 or 4 in total. There's only ever messages missing, never out of order or garbled. I'm starting to think there might actually be a bug in the logging module ;P -- Thomas Wouters <[EMAIL PROTECTED]> Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Extension to ConfigParser
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, and order. [Disclaimer: this is my patch] >> >> > This one however does, and if it does what it says on the box - is > definitely worth accepting. > 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 this is the place to make these comments, so I will stop with that. In case it wasn't clear, I am new here.. Hi. -- Scott Dial [EMAIL PROTECTED] [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Octal literals
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 octal literals. This feature has a very bad property: it can cause obscure problems for people who do not know or care about it. I have seen people try to use leading zeroes to make integer literals line up in a table. If they are lucky, they will get a syntax error. If they are unlucky, their program will silently do the wrong thing. It would be rather offputting to have to warn about this in the tutorial. But at present, a learner who isn't familiar with another language using this convention would have no reason to suspect it exists. As far as I can tell, it's documented only in the BNF. I think the safe thing in Python 3000 would be for literals with leading 0 to be syntax errors. Possibly os.chmod and os.umask could be extended to take a string argument so we could write chmod(path, "0640"). -M- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Octal literals
> 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-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] YAML (was Re: Extension to ConfigParser)
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 - but many >> will need to be edited and read by a developer. In a production >> environment importing from python modules is not likely to be safe. > > 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 the developer) form. 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. Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Extension to ConfigParser
[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 this is the place to make these comments, > so I will stop with that. Could you please add whatever information you have to the tracker? If you don't have a sf account and don't want to get one, I suppose you could just email it to me and I'll add it. =Tony.Meyer ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Extension to ConfigParser
[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 the various levels, so it's also
> useful... (The defaults parameter to the constructor is misnamed,
> AFAICT, as it's for interpolation defaults, not value defaults).
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 darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import ConfigParser
>>> c = ConfigParser.ConfigParser()
>>> c.read(("suite.ini", "app.ini"))
['suite.ini', 'app.ini']
>>> c.sections()
['sect']
>>> c.options("sect")
['opt4', 'opt2', 'opt1']
>>> c.get("sect", "opt1")
'3'
Or do you mean something else?
=Tony.Meyer
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Octal literals
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 error, as I said in the preceding paragraph. -M- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Compiler warnings
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 matter. Regardless of my > pinpointing efforts, much more than just the last line is sometimes missing, > though: Can you create a truss/strace dump of a failed run (I tried, but it always succeeded for me when run under strace). Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] JSON (was: YAML)
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://phd.pp.ru/[EMAIL PROTECTED] Programmers don't die, they just GOSUB without RETURN. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Octal literals
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 literals. -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Extension to ConfigParser
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 darwin
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import ConfigParser
> >>> c = ConfigParser.ConfigParser()
> >>> c.read(("suite.ini", "app.ini"))
> ['suite.ini', 'app.ini']
> >>> c.sections()
> ['sect']
> >>> c.options("sect")
> ['opt4', 'opt2', 'opt1']
> >>> c.get("sect", "opt1")
> '3'
>
> Or do you mean something else?
Err. Because I missed the fact that read() method takes multiple
filenames? There's even a specific explanation of how to load defaults
and then override them with optional files.
I don't know how I missed that. Thanks for pointing it out.
(The whole day's been like that - I'm not sure why I get out of bed
sometimes:-)
Paul.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Compiler warnings
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-waits and time.sleep()'s at > > strategic places, but it doesn't seem to matter. Regardless of my > > pinpointing efforts, much more than just the last line is sometimes missing, > > though: > Can you create a truss/strace dump of a failed run (I tried, but it > always succeeded for me when run under strace). Nope, they always succeed when run under strace. I haven't been able to capture the supposedly-TCP traffic either, not even when binding and connecting to my actual IP address. I wonder if glibc is doing trickery because it sees both endpoints of the socket are in the same process. -- Thomas Wouters <[EMAIL PROTECTED]> Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Octal literals
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 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.) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Octal literals
> 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 undesirable for a leading 0 to imply octal, then it would be best to decide on a different syntax for octal literals and use that syntax consistently everywhere. I am personally partial to allowing an optional radix (in decimal) followed by the letter r at the beginning of a literal, so 19, 8r23, and 16r13 would all represent the same value. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] YAML (was Re: Extension to ConfigParser)
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 occasionally editable >>(for the developer) form. > > > 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. Unfortunately, YAML still doesn't have a fully featured pure python parser (pyyaml works on simple yaml documents). The specification also doesn't have a blueprint implementation (there was talk about one at some point) and the fact that the specification has a context sensitive grammar and quite a large lookahead means that writing parsers with standard components is a little tricky (I know I tried for some time). The defacto standard implementation is 'syck' which is a c library that is used in the ruby distribution and works very well. Up until recently the only python wrapper that didn't segfault for syck was our own pyrex wrapper. Forunately, Kirill Simonov has written an excellent wrapper (which handles load and dump) which is available at http://xitology.org/pysyck/. Although we make extensive use of yaml and it is definitely the best human editable data format I've used - and our non techy clients agree that it's pretty simple to use - it is a lot more complicated than ini files. Our opinion is that it undoubtedly has it's bad points but that it makes complex configuration files easy to write, read and edit. If you want a human readable serialisation format, it's way, way better than xml. If you want to create config files that have some nesting and typing, have a look and see what you think. Tim Parkin p.s. JSON is 'nearly' a subset of YAML (the nearly point is being considered by various parties). ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] YAML (was Re: Extension to ConfigParser)
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 saving >>> near-arbitrary persistent data in a readable and occasionally >>> editable >>> (for the developer) form. >> >> >> 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. > > Unfortunately, YAML still doesn't have a fully featured pure python > parser (pyyaml works on simple yaml documents). That's the killer for me. I wanted to try it out once, but since there wasn't a good implementation I tossed it. > p.s. JSON is 'nearly' a subset of YAML (the nearly point is being > considered by various parties). There's a subset of JSON that is valid YAML. The output of simplejson is intentionally valid JSON and YAML, for example. Basically, the JSON serializer just needs to put whitespace in the right places. JSON isn't a great human editable format... Better than XML I guess, but it's not terribly natural. However, it is simple to implement, and the tools to deal with it are very widely available. -bob ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Octal literals
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 problem only in that particular context. > >I would think that if it is deemed undesirable for a leading 0 to imply >octal, then it would be best to decide on a different syntax for octal >literals and use that syntax consistently everywhere. > >I am personally partial to allowing an optional radix (in decimal) followed >by the letter r at the beginning of a literal, so 19, 8r23, and 16r13 would >all represent the same value. 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 same value, and the sign-digit could be arbitrarily repeated to the left without changing the value, e.g., -2, 16cfffe, 8c776, 2c1110, 10c8 would all have the same value. Likewise the positive values, where the "sign-digit" would be 0 instead of radix-1 (in the particular digit set for the radix). E.g., 2, 16c02, 16c0002, 8c02, 8c0002, 2c010, 2c0010, 10c02, 10c2, etc. Of course you can put a unary minus in front of any of those, so -16f7 == 1609, and -2c0110 == -6 == 2c1010 etc. This permits negative literal constants to be expressed "showing the bits" as they are in two's complement or with the bits grouped to show as hex or octal digits etc. And 16cf8000 would become a 32-bit int, not a long as would -0x8000 (being a unary minus on a positive value that is promoted to long). Regards, Bengt Richter ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Extension to ConfigParser
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 want the window this big next time!). It was natural to us to save it in the user home directory, in a ".sigefi" file. And we thought it was unpolite, at less, to put a pickled dictionary in users home directory. That's how we finished keeping program state in a .INI, :s. Regards, .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Octal literals
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 same value, and the sign-digit could be arbitrarily repeated to > the left without changing the value, e.g., -2, 16cfffe, 8c776, 2c1110, > 10c8 > would all have the same value. Likewise the positive values, where the > "sign-digit" > would be 0 instead of radix-1 (in the particular digit set for the radix). > E.g., > 2, 16c02, 16c0002, 8c02, 8c0002, 2c010, 2c0010, 10c02, 10c2, etc. Of > course > you can put a unary minus in front of any of those, so -16f7 == 1609, and > -2c0110 == -6 == 2c1010 etc. This is getting too complicated. I dont' want to read code and pause myself 5 minutes while doing math to understand a number. I think that the whole point of modifying something is to simplify it. I'm +0 on removing 0-leading literals. But only if we create "d", "h" and "o" suffixes to represent decimal, hex and octal literals (2.35d, 3Fh, 660o). And +0 on keeping the "0x" preffix for hexa (c'mon, it seems so natural). Regards, .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Compiler warnings
[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_ no way to get to a reference to `e` without going through x = _PyLong_AsScaledDouble(vv, &e); first. That isn't a useful warning. > Objects/longobject.c: In function 'long_true_divide': > Objects/longobject.c:2263: warning: 'aexp' may be used uninitialized in this > function > Objects/longobject.c:2263: warning: 'bexp' may be used uninitialized in this > function Same thing, really, complaining about vrbls whose values are always set by _PyLong_AsScaledDouble(). > Modules/linuxaudiodev.c: In function 'lad_obuffree': > Modules/linuxaudiodev.c:392: warning: 'ssize' may be used uninitialized in > this function > Modules/linuxaudiodev.c: In function 'lad_bufsize': > Modules/linuxaudiodev.c:348: warning: 'ssize' may be used uninitialized in > this function > Modules/linuxaudiodev.c: In function 'lad_obufcount': > Modules/linuxaudiodev.c:369: warning: 'ssize' may be used uninitialized in > this function Those are Linux bugs ;-) > ... > Should these warnings be fixed? I don't know. Is this version of gcc broken in some way relative to other gcc versions, or newer, or ... ? We certainly don't want to see warnings under gcc, since it's heavily used, but I'm not clear on why other versions of gcc aren't producing these warnings (or are they, and people have been ignoring that?). > I know Tim has always argued to fix them, in the past (and I agree,) and it > doesn't look like doing so, by initializing the variables, wouldn't be too > big a > performance hit. We shouldn't see any warnings under a healthy gcc. > 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? FWIW, I've never seen this fail on Windows. The difference is probably that sockets on Windows work . ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Compiler warnings
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_AsScaledDouble(vv, &e); > > first. That isn't a useful warning. But how can the compiler know that it is an output-only argument? -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Compiler warnings
[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 absence of interprocedural analysis, it cannot -- and neither
can it know that it's not an output argument. It can't know anything
non-trivial, and because it can't, a reasonable compiler would avoid
raising a red flag at "warning" level. "info", maybe, if it has such
a concept. It's as silly to me as seeing, e.g.,
"""
double
recip(double z)
{
return 1.0 / z;
}
"warning: possible division by 0 or signaling NaN"
"""
Perhaps, but not useful because there's no reason to presume it's a
_likely_ error.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Compiler warnings
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] > > > 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_AsScaledDouble(vv, &e); > > > > first. That isn't a useful warning. > > But how can the compiler know that it is an output-only argument? > > -- > --Guido van Rossum (home page: http://www.python.org/~guido/) > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/evdo.hsdpa%40gmail.com > -- 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 Cardiff by the Sea, CA 92007 206 984 0880 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Compiler warnings
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 this function
>
> 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.
Look closer, and it's not quite so obvious. Here's the beginning of
PyLong_AsDouble:
> double
> PyLong_AsDouble(PyObject *vv)
> {
> int e;
> double x;
>
> if (vv == NULL || !PyLong_Check(vv)) {
> PyErr_BadInternalCall();
> return -1;
> }
> x = _PyLong_AsScaledDouble(vv, &e);
> if (x == -1.0 && PyErr_Occurred())
> return -1.0;
> if (e > INT_MAX / SHIFT)
> goto overflow;
Here's the beginning of _PyLong_AsScaledDouble:
> _PyLong_AsScaledDouble(PyObject *vv, int *exponent)
> {
> #define NBITS_WANTED 57
> PyLongObject *v;
> double x;
> const double multiplier = (double)(1L << SHIFT);
> int i, sign;
> int nbitsneeded;
>
> if (vv == NULL || !PyLong_Check(vv)) {
> PyErr_BadInternalCall();
> return -1;
> }
Now here's the thing: _PyLong_AsScaledDouble *doesn't* set exponent
before returning -1 there, which is where the warning comes from.
Now, you might protest, it's impossible to go down that code path,
because of two reasons:
1) PyLong_AsDouble has an identical "(vv == NULL || !PyLong_Check
(vv))" check, so that codepath in _PyLong_AsScaledDouble cannot
possibly be gone down. However, PyLong_Check is a macro which expands
to a function call to an external function, "PyType_IsSubtype((vv)-
>ob_type, (&PyLong_Type)))", so GCC has no idea it cannot return an
error the second time. This is the kind of thing C++'s const
2) There's a guard "(x == -1.0 && PyErr_Occurred())" before "e" is
used in PyLong_AsDouble, which checks the conditions that
_PyLong_AsScaledDouble set. Thus, e cannot possibly be used, even if
the previous codepath *was* possible to go down. However, again,
PyErr_BadInternalCall() is an external function, so the compiler has
no way of knowing that PyErr_BadInternalCall() causes PyErr_Occurred
() to return true.
So in conclusion, from all the information the compiler has available
to it, it is giving a correct diagnostic.
James
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Compiler warnings
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 mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Extension to ConfigParser
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 systems, like
>>config files that can be changed programmatically, or error messages
>>that point to file and line numbers. Those aren't necessarily features
>>we need to expose in the standard library, but it'd be nice if you could
>>implement that kind of feature without having to ignore the standard
>>library entirely.
>>
>>
>
> Can you elaborate on what kinds of programattic changes you envisage ?
> I'm just wondering if there are classes of usage not covered by
> ConfigObj. Of course you can pretty much do anything to a ConfigObj
> instance programattically, but even so...
ConfigObj does fine, my criticism was simply of ConfigParser in this
case. Just yesterday I was doing (with ConfigParser):
conf.save('app:main', '## Uncomment this next line to enable
authentication:\n#filter-with', 'openid')
This is clearly lame ;)
>>That said, I'm not particularly enthused about a highly featureful
>>config file *format* in the standard library, even if I would like a
>>much more robust implementation.
>>
>>
>
> I don't see how you can easily separate the format from the parser -
> unless you just leave raw values. (As I said in the other email, I don't
> think I fully understand you.)
>
> If accessing raw values suits your purposes, why not subclass
> ConfigParser and do magic in the get* methods ?
I guess I haven't really looked closely at the implementation of
ConfigParser, so I don't know how serious the subclassing would have to
be. But, for example, if you wanted to do nested sections this is not
infeasible with the current syntax, you just have to overload the
meaning of the section names. E.g., [foo.bar] (a section named
"foo.bar") could mean that this is a subsection of "foo". Or, if the
parser allows you to see the order of sections, you could use [[bar]] (a
section named "[bar]") to imply a subsection, not unlike what you have
already, except without the indentation.
I think there's lots of other kinds of things you can do with the INI
syntax as-is, but providing a different interface to it. If you allow
an easy-to-reuse parser, you can even check that syntax at read time.
(Or if you keep enough information, check the syntax later and still be
able to signal errors with filenames and line numbers)
An example of a parser that doesn't imply much of anything about the
object being produced is one that I wrote here:
http://svn.colorstudy.com/INITools/trunk/initools/iniparser.py
On top of that I was able to build some other fancy things without much
problem (which ended up being too fancy, but that's a different issue ;)
>> From my light reading on ConfigObj, it looks like it satisfies my
>>personal goals (though I haven't used it), but maybe has too many
>>features, like nested sections. And it seems like maybe the API can be
>>
>
> I personally think nested sections are very useful and would be sad to
> not see them included. Grouping additional configuration options as a
> sub-section can be *very* handy.
Using .'s in names can also do grouping, or section naming conventions.
--
Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Compiler warnings
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 should instead join python-list, or the equivalent comp.lang.python newsgroup. Posting as a new user what you just did "u guys are way over my head :)", as well as your earlier post of "anybody here?", is a good and fast way of being placed in everyone's kill file. - Josiah ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Compiler warnings
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 _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.
It inlines the function to make this determination. Now, it's not true
that e can be uninitialized then, but there the gcc logic fails:
If you take the
if (vv == NULL || !PyLong_Check(vv)) {
PyErr_BadInternalCall();
return -1;
}
case in _PyLong_AsScaledDouble, *exponent won't be initialized. Then,
in PyLong_AsDouble, with
x = _PyLong_AsScaledDouble(vv, &e);
if (x == -1.0 && PyErr_Occurred())
return -1.0;
it looks like the return would not be taken if PyErr_Occurred returns
false. Of course, it won't, but that is difficult to analyse.
> I don't know. Is this version of gcc broken in some way relative to
> other gcc versions, or newer, or ... ? We certainly don't want to see
> warnings under gcc, since it's heavily used, but I'm not clear on why
> other versions of gcc aren't producing these warnings (or are they,
> and people have been ignoring that?).
gcc 4 does inlining in far more cases now.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Compiler warnings
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? If a variable's address is passed to a function, gcc normally assumes that the function will modify the variable, so you normally don't see "might be used uninitialized" warnings. However, gcc now also inlines the functions called if possible, to find out how the pointer is used inside the function. Changing the order of the functions in the file won't help anymore, either. If you want to suppress inlining, you must put __attribute__((noinline)) before the function. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
