Re: [Python-Dev] [Pydotorg] Should we help pythonmac.org?
Bill Janssen wrote: I strongly recommend that we *NOT* make macports.org the main, official Mac OS X version of Python. Secondary is fine, but not primary. Macports is what the name says: it's a system of Mac ports of Linux packages, mostly command-line only. I agree with David about this. The official Mac Python should be an OS X application, with an icon, living in /Applications, ideally with a Mac-standard editor app (the 2.5.1 I have has IDLE), etc. No, probably not. Frankly, I think the official Mac Python should be (and is) /usr/bin/python, the version that Apple ships with the system. I always try to make my stuff work with that Python, instead of installing a different version, which in my experience usually leads to grief somewhere down the road. I've certainly heard many tales of Mac users coming to grief because they decided to overwrite their system Python, or tried to be clever and run multiple interpreters (which is usually somewhat less disastrous). The Mac system depends a lot on stuff that comes installed with the system version of Python - including specific versions of Twisted etc. I *thought* (relative Mac newbie), the standard advice was that if you want to install extension modules then you should install your own version of Python and not mess with the system version. Meaning that you have to maintain two Python installs - something that hasn't been a problem for me yet. So even if Mac OS ships with Python 2.6, many users will still want to install their own version. The default page for Python on the Mac is horribly out of date: http://python.org/download/mac/ No mention of Leopard. Michael I guess this underlines the fact that Apple don't really want the hoi polloi tinkering with their systems; it's somewhat tedious when code is released for later Python versions and you have to privately backport, though, isn't it? There have been hints dropped that if the 2.6 release hits its deadline it will be incorporated into vendor builds. Let's hope one of them is MacOS, then at least it'll be relatively up to date. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ ___ 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] splitext('.cshrc')
Oleg Broytmann wrote: [snip..] this is different on Windows, I cannot imagine that anyone would a) have dotfiles under that OS It is very common for cross platform programs to create configuration files which are dotfiles, whichever OS they are running on. Michael Foord ___ 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] PEP 315 - do while
Nick Coghlan wrote: Hans Polak wrote: Ok, I see your point. Really, I've read more about Python than worked with it, so I'm out of my league here. Can I combine your suggestion with mine and come up with the following: do: setup code loop body while condition else: loop completion code In my example, the 3 sections (setup code, loop body and loop completion code are all optional. A basic do-while loop would look like this: do: setup code while condition (That is, setup code is still repeated each time around the loop - it's called that because it is run before the loop evaluated condition is evaluated) +1 This looks good. The current idiom works fine, but looks unnatural : while True: if condition: break Would a 'while' outside of a 'do' block (but without the colon) then be a syntax error ? 'do:' would just be syntactic sugar for 'while True:' I guess. Michael Foord http://www.voidspace.org.uk Cheers, Nick. ___ 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] PEP 315 - do while
Nick Coghlan wrote: [snip..] The current idiom works fine, but looks unnatural : while True: if condition: break There's the rationale for the PEP in a whole 5 lines counting whitespace ;) Would a 'while' outside of a 'do' block (but without the colon) then be a syntax error ? 'do:' would just be syntactic sugar for 'while True:' I guess. That's the slight issue I still have with the idea - you could end up with multiple ways of spelling some of the basic loop forms, such as these 3 flavours of infinite loop: do: pass # Is there an implicit 'while True' at the end of the loop body? do: while True while True: pass Following the current idiom, isn't it more natural to repeat the loop 'until' a condition is met. If we introduced two new keywords, it would avoid ambiguity in the use of 'while'. do: loop body until condition A do loop could require an 'until', meaning 'do' is not *just* a replacement for an infinite loop. (Assuming the parser can be coerced into co-operation.) It is obviously still a new construct in terms of Python syntax (not requiring a colon after 'condition'.) I'm sure this has been suggested, but wonder if it has already been ruled out. An 'else' block could then retain its current meaning (execute if the loop is not terminated early by an explicit break.) Michael Foord http://www.voidspace.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] Explicit Lexical Scoping (pre-PEP?)
Talin wrote: Ka-Ping Yee wrote: On Mon, 10 Jul 2006 [EMAIL PROTECTED] wrote: I think Talin's got a point though. It seems hard to find one short English word that captures the essence of the desired behavior. None of the words in his list seem strongly suggestive of the meaning to me. I suspect that means one's ultimately as good (or as bad) as the rest. What's wrong with nonlocal? I don't think i've seen an argument against that one so far (from Talin or others). Well, I just think that a fix for an aesthetic wart should be, well, aesthetic :) I also think that it won't be a complete disaster if we do nothing at all - there *are* existing ways to deal with this problem; there are even some which aren't hackish and non-obvious. For example, its easy enough to create an object which acts as an artificial scope: def x(): scope = object() scope.x = 1 def y(): scope.x = 2 To my mind, the above code looks about as elegant and efficient as most of the proposals put forward so far, and it already works. How much are we really saving here by building this feature into the language? def x(): ...:scope = object() ...:scope.x = 1 ...:def y(): ...:scope.x = 2 x() --- exceptions.AttributeErrorTraceback (most recent call last)ipython console I've often found it a nuisance that you can't instantiate an 'object', to use as a mutable 'namespace', but instead have to define an arbitrary empty class. What happened to the 'namespace' proposal ? Michael Foord http://www.voidspace.org.uk/python/index.shtml -- Talin ___ 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] Explicit Lexical Scoping (pre-PEP?)
Robin Bryce wrote: outbound x = 1 FWINW, to me 'nonlocal' clearly and immediately tells you what you need to know about the variable. 'outbound' has no programming associations for me (it makes me think of 'outward bound' and roaming the great outdoors). So negative or not I'm +1 on nonlocal if we really need this... (Hey, and I'm a native.) Michael Foord http://www.voidspace.org.uk/python/index.shtml x = 2 evaluating using Jeremy Hilton's' list: 1. is a real word 2. For me - in python - it would mean: Is found in 'outer' scope and is already bound. And the literal meaning of 'outbound 'headed away' [1] is pretty darn close to what I mean when I spell the usual mutables kluge. 3 statement is positive form 4. I like it could not find a use of outbound in python source (2.4.3) [1] http://dictionary.reference.com/search?q=outbound Robin ___ 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] Py3k: Except clause syntax
Michael Hudson wrote: [EMAIL PROTECTED] writes: Greg except type as value: Baptiste except type with value: Can I catch multiple exceptions with a single value in this case? Today, I write: try: foo() except (TypeError, KeyError), msg: print msg Either of the above seem like they'd require me to repeat the value, e.g: try: foo() except TypeError with msg, KeyError with msg: print msg Not very Pythonic methinks. Wasn't the proposal : try: something except NameError, OtherError as e: something... ? With e being bound for any of the exceptions... Michael Foord except TypeError or KeyError as msg: ! not-serious-ly y'rs, mwh ___ 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] defaultdict proposal round three
Greg Ewing wrote:
Fuzzyman wrote:
I've had problems in code that needs to treat strings, lists and
dictionaries differently (assigning values to a container where all
three need different handling) and telling the difference but allowing
duck typing is *problematic*.
You need to rethink your design so that you don't
have to make that kind of distinction.
Well... to *briefly* explain the use case, it's for value assignment in
ConfigObj.
It basically accepts as valid values strings and lists of strings [#]_.
You can also create new subsections by assigning a dictionary.
It needs to be able to recognise lists in order to check each list
member is a string. (See note below, it still needs to be able to
recognise lists when writing, even if it is not doing type checking on
assignment.)
It needs to be able to recognise dictionaries in order to create a new
section instance (rather than directly assigning the dictionary).
This is *terribly* convenient for the user (trivial example of creating
a new config file programatically) :
from configobj import ConfigObj
cfg = ConfigObj(newfilename)
cfg['key'] = 'value'
cfg['key2'] = ['value1', 'value2', 'value3']
cfg['section'] = {'key': 'value', 'key2': ['value1', 'value2',
'value3']}
cfg.write()
Writes out :
key = value
key2 = value1, value2, value3
[section]
key = value
key2 = value1, value2, value3
(Note none of those values needed quoting, so they aren't.)
Obviously I could force the creation of sections and the assignment of
list values to use separate methods, but it's much less readable and
unnecessary.
The code as is works and has a nice API. It still needs to be able to
tell what *type* of value is being assigned.
Mapping and sequence protocols are so loosely defined that in order to
support 'list like objects' and 'dictionary like objects' some
arbitrary decision about what methods they should support has to be
made. (For example a read only mapping container is unlikely to
implement __setitem__ or methods like update).
At first we defined a mapping object as one that defines __getitem__
and keys (not update as I previously said), and list like objects as
ones that define __getitem__ and *not* keys. For strings we required a
basestring subclass. In the end I think we ripped this out and just
settled on isinstance tests.
All the best,
Michael Foord
.. [#] Although it has two modes. In the 'default' mode you can assign
any object as a value and a string representation is written out. A
more strict mode checks values at the point you assign them - so
errors will be raised at that point rather than propagating into the
config file. When writing you still need to able to recognise lists
because each element is properly quoted.
___
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] defaultdict proposal round three
Greg Ewing wrote:
Fuzzyman wrote:
cfg = ConfigObj(newfilename)
cfg['key'] = 'value'
cfg['key2'] = ['value1', 'value2', 'value3']
cfg['section'] = {'key': 'value', 'key2': ['value1', 'value2', 'value3']}
If the main purpose is to support this kind of notational
convenience, then I'd be inclined to require all the values
used with this API to be concrete strings, lists or dicts.
If you're going to make types part of the API, I think it's
better to do so with a firm hand rather than being half-
hearted and wishy-washy about it.
[snip..]
Thanks, that's the solution we settled on. We use ``isinstance`` tests
to determine types.
The user can always do something like :
cfg['section'] = dict(dict_like_object)
Which isn't so horrible.
All the best,
Michael
--
Greg
___
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
[Python-Dev] operator.is*Type
Hello all, Feel free to shoot this down, but a suggestion. The operator module defines two functions : isMappingType isSquenceType These return a guesstimation as to whether an object passed in supports the mapping and sequence protocols. These protocols are loosely defined. Any object which has a ``__getitem__`` method defined could support either protocol. Therefore : from operator import isSequenceType, isMappingType class anything(object): ... def __getitem__(self, index): ... pass ... something = anything() isMappingType(something) True isSequenceType(something) True I suggest we either deprecate these functions as worthless, *or* we define the protocols slightly more clearly for user defined classes. An object prima facie supports the mapping protocol if it defines a ``__getitem__`` method, and a ``keys`` method. An object prima facie supports the sequence protocol if it defines a ``__getitem__`` method, and *not* a ``keys`` method. As a result code which needs to be able to tell the difference can use these functions and can sensibly refer to the definition of the mapping and sequence protocols when documenting what sort of objects an API call can accept. All the best, Michael Foord ___ 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] operator.is*Type
Raymond Hettinger wrote: from operator import isSequenceType, isMappingType class anything(object): ... def __getitem__(self, index): ... pass ... something = anything() isMappingType(something) True isSequenceType(something) True I suggest we either deprecate these functions as worthless, *or* we define the protocols slightly more clearly for user defined classes. They are not worthless. They do a damned good job of differentiating anything that CAN be differentiated. But as far as I can tell (and I may be wrong), they only work if the object is a subclass of a built in type, otherwise they're broken. So you'd have to do a type check as well, unless you document that an API call *only* works with a builtin type or subclass. In which case - an isinstance call does the same, with the advantage of not being broken if the object is a user-defined class. At the very least the function would be better renamed ``MightBeMappingType`` ;-) Your example simply highlights the consequences of one of Python's most basic, original design choices (using getitem for both sequences and mappings). That choice is now so fundamental to the language that it cannot possibly change. Get used to it. I have no problem with it - it's useful. In your example, the results are correct. The anything class can be viewed as either a sequence or a mapping. But in practise an object is *unlikely* to be both. (Although conceivable a mapping container *could* implement integer indexing an thus be both - but *very* rare). Therefore the current behaviour is not really useful in any conceivable situation - not that I can think of anyway. In this and other posts, you seem to be focusing your design around notions of strong typing and mandatory interfaces. I would suggest that that approach is futile unless you control all of the code being run. Not directly. I'm suggesting that the loosely defined protocol (used with duck typing) can be made quite a bit more useful by making the definition *slightly* more specific. A preference for strong typing would require subclassing, surely ? The approach I suggest would allow a *less* 'strongly typed' approach to code, because it establishes a convention to decide whether a user defined class supports the mapping and sequence protocols. The simple alternative (which we took in ConfigObj) is to require a 'strongly typed' interface, because there is currently no useful way to determine whether an object that implements __getitem__ supports mapping or sequence. (Other than *assuming* that a mapping container implements a random choice from the other common mapping methods.) All the best, Michael Raymond ___ 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] defaultdict proposal round three
Greg Ewing wrote: Delaney, Timothy (Tim) wrote: However, *because* Python uses duck typing, I tend to feel that subclasses in Python *should* be drop-in replacements. Duck-typing means that the only reliable way to assess whether two types are sufficiently compatible for some purpose is to consult the documentation -- you can't just look at the base class list. What's the API for that ? I've had problems in code that needs to treat strings, lists and dictionaries differently (assigning values to a container where all three need different handling) and telling the difference but allowing duck typing is *problematic*. Slightly-off-topic'ly-yours, Michael Foord ___ 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] defaultdict proposal round three
Guido van Rossum wrote: On 2/21/06, Fuzzyman [EMAIL PROTECTED] wrote: I've had problems in code that needs to treat strings, lists and dictionaries differently (assigning values to a container where all three need different handling) and telling the difference but allowing duck typing is *problematic*. Consider designing APIs that don't require you to mae that kind of distinction, if you're worried about edge cases and classifying arbitrary other objects correctly. It's totally possible to create an object that behaves like a hybrid of a string and a dict. Understood. If you're only interested in classifying the three specific built-ins you mention, I'd check for the presense of certain attributes: hasattr(x, lower) - x is a string of some kind; hasattr(x, sort) - x is a list; hasattr(x, update) - x is a dict. Also, hasattr(x, union) - x is a set; hasattr(x, readline) - x is a file. That's duck typing! Sure, but that requires a dictionary like object to define an update method, and a list like object to define a sort method. The mapping and sequence protocols are so loosely defined that some arbitrary decision like this has to be made. (Any object that defines __getitem__ could follow either or both and duck typing doesn't help you unless you're prepared to make an additional requirement that is outside the loose requirements of the protocol.) I can't remember how we solved it, but I think we decided that an object would be treated as a string if it passed isinstance, and a dictionary or sequence if it has _getitem__ (but isn't a string instance or subclass). If it has update as well as __getitem__ it is a dictionary-alike. All the best, Michael Foord -- --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] Proposal: defaultdict
Martin v. Lwis wrote: Guido van Rossum wrote: Feedback? I would like this to be part of the standard dictionary type, rather than being a subtype. d.setdefault([]) (one argument) should install a default value, and d.cleardefault() should remove that setting; d.default should be read-only. Alternatively, d.default could be assignable and del-able. Also, I think has_key/in should return True if there is a default. And exactly what use would it then be ? Michael Foord 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/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] str object going in Py3K
Guido van Rossum wrote:
[snip..]
In py3k, when the str object is eliminated, then what do you have?
Perhaps
- bytes(\x80), you get an error, encoding is required. There is no
such thing as default encoding anymore, as there's no str object.
- bytes(\x80, encoding=latin-1), you get a bytestring with a
single byte of value 0x80.
Yes to both again.
*Slightly* related question. Sorry for the tangent.
In Python 3K, when the string data-type has gone, what will
``open(filename).read()`` return ? Will the object returned have a
``decode`` method, to coerce to a unicode string ?
Also, what datatype will ``u'some string'.encode('ascii')`` return ?
I assume that when the ``bytes`` datatype is implemented, we will be
able to do ``open(filename, 'wb').write(bytes(somedata))`` ? Hmmm... I
probably ought to read the bytes PEP and the Py3k one...
Just curious...
All the best,
Michael Foord
--
--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
[Python-Dev] Old Style Classes Goiung in Py3K
Hello all, I understand that old style classes are slated to disappear in Python 3000. Does this mean that the following will be a syntax error : class Something: pass *or* that instead it will automatically inherit from object ? The latter would break a few orders of magnitude less code of course... All the best, Michael Foord http://www.voidspace.org.uk/python/index.shtml ___ 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
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 to extend to the ConfigObj API to be backwards compatible with ConfigParser. This would bring the added benefits of ConfigObj, without needing to add an extra module to the standard library. Well nearly. ConfigObj supports config file schema with (optional) type conversion, through a companion module called validate. This could be included or left as an added option. Anyway. If this stands a *chance* of acceptance, I'll write the PEP (and if accepted, do the work - which is not inconsiderable). Personally, I'd prefer to have the different candidates in the Shootout be evaluated and a "winner" picked (I'm not sure who would do this, or when it would be done). Quite. I'm suggesting an alternative that bypasses that tortuous and unlikely process. ;-) I'll readily declare an interest - I've implemented an alternative hierarchical config module (which is in no way backward compatible with ConfigParser), see http://www.red-dove.com/python_config.html I realise that there are several alternative modules available . Obviously my personal preference is ConfigObj (I'm not unbiased of course). :-) Lack of complexity is the major feature I would tout here - I guess other people would have different priorities. However, this not the only issue. Adding a new module, with a different API and possibly a different syntax for files, is a recipe for (some) confusion. Not to mention the difficulty of achieving a consensus on python-dev. (Again - ;-) 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'm currently adding the ``ConfigParser.get*`` methods to ConfigObj (user request) and also adding full (straightforward) unicode support for reading and writing. These changes will be available in a beta release in the next few days. Anyway, debate on the issue is welcomed. All the best, Fuzzyman http://www.voidspace.org.uk/python/configobj.html 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/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
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 maintain while changing the internals without breaking lots of code. In practice, everything is a public interface. So I think the implementation as it stands should stay in place, and if anything it should be deprecated instead of being enhanced in-place. Somehow that's not my experience. What's so bad about ConfigParser? What would break if we rewrote the save functionality to produce a predictable order? Well, what I'm suggesting is not merely enhancing ConfigParser in place - but replacing it with the ConfigObj and a compatibility layer to support legacy code. As I mentioned, it would require *some* changes to the parser (ConfigObj) to be fully compatible with the existing syntax, but that is well achievable. The aim would be that no existing code breaks, and few (if any) config files break. I could flesh this out in a PEP if it was likely that it would be accepted. Issues with ConfigParser that ConfigObj *immediately* fixes : * Simpler API - uses dictionary syntax/methods for adding/deleting/accessing keys and sections (Each section - including the ConfigObj itself - is a dictionary subclass with all methods available) * Nested sub-sections to any depth. * Fully integrated (extensible) validation schema system, with type conversion. No complexity overhead for not using it. * List values parsed by default (handling quotes sanely) * Retains order of keys/section for iteration and writing out config file. * Retains *all* comments and allows inline comments The next enhancement will add full unicode support, which for a text based format really makes sense and I should have implemented it earlier. Additionally ConfigObj allows values in the root section - meaning that for simple config files you aren't *forced* to have an arbitrary 'section'. All the best, Fuzzyman http://www.voidspace.org.uk/python/configobj.html -- --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/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
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 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 of code. In practice, everything is a public interface. So I think the implementation as it stands should stay in place, and if anything it should be deprecated instead of being enhanced in-place. Another class or module could be added that fulfills the documented interface to ConfigParser. This would provide an easy upgrade path, without calling it a backward-compatible interface. I personally would like if any new config system included a parser, and then an interface to the configuration that was read (ConfigParser is only the latter). Then people who want to do their own thing can work with just the parser, without crudely extending and working around the configuration interface. But to implement a parser you still need to agree a basic syntax. For example ConfigObj supports list values, handles quotes sanely, uses triple quotes for multiline values, allows inline comments, and has a syntax for nested sections. Once you have agreed these and a *basic* API spec for accessing the data then you've implemented most of your config file handler. In order to implement a write (save) method you also have to agree on how to handle non string values (like lists). There's not an *awful* lot left to do. In ConfigObj if you switch off list handling when parsing and interpolation when fetching values, you have access to the raw values and are free to extend value handling any way you choose. 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 may be misunderstanding you of course (or more likely not fully understanding). :-) All the best, Fuzzyman http://www.voidspace.org.uk/python/index.shtml ___ 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
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 internals without breaking lots of code. In practice, everything is a public interface. So I think the implementation as it stands should stay in place, and if anything it should be deprecated instead of being enhanced in-place. Somehow that's not my experience. What's so bad about ConfigParser? What would break if we rewrote the save functionality to produce a predictable order? That's a fairly minor improvement, and I can't see how that would break anything. But Michael (aka Fuzzyman -- sorry, I just can't refer to you as Fuzzyman without feeling absurd ;) Don't worry, absurdity is a common reaction I inspire in people. Actually Fuzzyman is more of a description than a nickname. I understand that I may not be the only one worthy of such a title of course. ;-) was proposing ConfigObj specifically (http://www.voidspace.org.uk/python/configobj.html). I assume the internals of ConfigObj bear no particular resemblence to ConfigParser, even if ConfigObj can parse the same syntax (plus some, and with different failure cases) and provide the same public API. 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... 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 ? 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. reduced in size with a little high-level refactoring -- APIs generally grow over time so as to preserve backward compatibility, but I think if it was introduced into the standard library that might be an opportunity to trim the API back again before it enters the long-term API freeze that the standard library demands. Hmmm possibly. :-) walk, decode and encode are the obvious extraneous methods. walk can be re-implemented as a recursive function and encode/decode will be unnecessary when unicode support is complete. Additional complexity comes from retaining all comments and supporting validation. I think retaining comments is worthwhile, because it allows a program to modify a config file (e.g. from a GUI) without losing user comments in a handwritten config file. The validation support has several levels to it - but it can be completely ignored with no complexity for the user. Some validation support is integrated into instantiation, but this could *probably* be broken out into a subclass. Anyway, ho hum - possibly. All for future hypothetical discussion I guess... All the best, Fuzzyman http://www.voidspace.org.uk/python/configobj.html ___ 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] Extension to ConfigParser
Hello all, In the past there has been some discussion about a new module to replace ConfigParser. Most notably at http://wiki.python.org/moin/ConfigParserShootout Specific issues that could be addressed include : * Simpler API * Nested subsections * List values * Storing/converting datatypes * Config file schema * Keeps track of order of values Plus other issues. I'm the (co-)author of ConfigObj - http://www.voidspace.org.uk/python/configobj.html This is a reasonably mature project (now in it's fourth incarnation), and is being used in projects like `Bazaar http://www.bazaar-ng.org/`_ and `PlanetPlus http://planetplus.python-hosting.com/`_. It occurs to me that the ConfigObj API and syntax is *almost* fully compatible with ConfigParser. It would be possible to extend to the ConfigObj API to be backwards compatible with ConfigParser. This would bring the added benefits of ConfigObj, without needing to add an extra module to the standard library. Well nearly. ConfigObj supports config file schema with (optional) type conversion, through a companion module called validate. This could be included or left as an added option. Anyway. If this stands a *chance* of acceptance, I'll write the PEP (and if accepted, do the work - which is not inconsiderable). Summary of ConfigObj ConfigObj is a Python 2.2 compatible config file parser. It's major feature is simplicity of use. It reads (and writes) INI file like config files and presents the members using a dictionary interface. The order of keys/sections is preserved, and it allows nested subsections to any level : e.g. :: key = value [section] key = value [[sub-section]] key = value It is fully documented with a barrage of doctests. All comments in the config file are also preserved as attributes of the object, and will be written back out. This can be useful for including comments in programatically generated config files. It is integrated with a powerful validation system. Difficulties Differences = A ConfigObj instance is a sub-class of the dictionary datatpe. This means that the ``get`` method of ConfigParser clashes. ConfigObj allows values in the root section (why not ?). ConfigObj doesn't support line continuations (it does all multi-line values through the use of triple quoted strings). ConfigObj currently only allows '=' as a valid divider. Creating ConfigParser (and related classes) compatibility is a big job. Solution = All of these problems (if deemed necessary) can be resolved. Either through options, or just by extending the ConfigObj API. I'm happy to put the work in. Comments ? All the best, Fuzzyman http://www.voidspace.org.uk/python/index.shtml ___ 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
