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) 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 >[email protected] >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 [email protected] 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 >[email protected] >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 [email protected] 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: >> >> >> while >> else: >> >> >> > >In my example, the 3 sections (, and code> are all optional. A basic do-while loop would look like this: > > do: > > while > >(That is, 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 : 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 [email protected] 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 : >>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: until 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 ''.) 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Py2.6 ideas
Michele Simionato wrote: >Raymond Hettinger verizon.net> writes: > > >>* Add a pure python named_tuple class to the collections module. I've been >>using the class for about a year and found that it greatly improves the >>usability of tuples as records. >>http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/500261 >> >> >[snip..] >4. I want help(MyNamedTuple) to work well; in particular it should > display the right module name. That means > that in the m dictionary you should add a __module__ attribute: > >__module__ = sys._getframe(1).f_globals['__name__'] > > > Hello all, If this is being considered for inclusion in the standard library, using _getframe' hackery will guarantee that it doesn't work with alternative implementations of Python (like IronPython at least which doesn't have Python stack frames). At least wrapping it in a try/except would be helpful. All the best, Michael Foord ___ Python-Dev mailing list [email protected] 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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 > [email protected] > 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 [email protected] 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
[email protected]
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
Adam Olsen wrote: On 2/14/06, Just van Rossum <[EMAIL PROTECTED]> wrote: +1 for two functions. My choice would be open() for binary and opentext() for text. I don't find that backwards at all: the text function is going to be more different from the current open() function then the binary function would be since in many ways the str type is closer to bytes than to unicode. Maybe it's even better to use opentext() AND openbinary(), and deprecate plain open(). We could even introduce them at the same time as bytes() (and leave the open() deprecation for 3.0). Thus providing us with a transition period, even with warnings on use of the old function. [snip..] I personally like the move towards all unicode strings, basically any text where you don't know the encoding used is 'random binary data'. This works fine, so long as you are in control of the text source. *However*, it leaves the following problem : The current situation (treating byte-sequences as text and assuming they are an ascii-superset encoded text-string) *works* (albeit with many breakages), simply because this assumption is usually correct. Forcing the programmer to be aware of encodings, also pushes the same requirement onto the user (who is often the source of the text in question). Currently you can read a text file and process it - making sure that any changes/requirements only use ascii characters. It therefore doesn't matter what 8 bit ascii-superset encoding is used in the original. If you force the programmer to specify the encoding in order to read the file, they would have to pass that requirement onto their user. Their user is even less likely to be encoding aware than the programmer. What this means, is that for simple programs where the programmer doesn't want to have to worry about encoding, or can't force the user to be aware, they will read in the file as bytes. Modules will quickly and inevitably be created implementing all the 'string methods' for bytes. New programmers will gravitate to these and the old mess will continue, but with a more awkward hybrid than before. (String manipulations of byte sequences will no longer be a core part of the language - and so be harder to use.) Not sure what we can do to obviate this of course... but is this change actually going to improve the situation or make it worse ? All the best, Michael Foord ___ Python-Dev mailing list [email protected] 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. Löwis 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] 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
[email protected]
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
[email protected]
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
[email protected]
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 [email protected] 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 [email protected] 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: Fredrik Lundh wrote: fwiw, the first google hit for "autodict" appears to be part of someone's link farm At this website we have assistance with autodict. In addition to information for autodict we also have the best web sites concerning dictionary, non profit and new york. Hmmm, looks like some sort of bot that takes the words in your search and stuffs them into its response. I wonder if they realise how silly the results end up sounding? I've seen these sorts of things before, but I haven't quite figured out yet how they manage to get into Google's database if they're auto-generated. Anyone have any clues what goes on? I guess the question is, how would google know *not* to index them ? As soon as they are linked to (or more likely they re-use an expired domain name that is already in the google database) they will be indexed. They may be obviously autogenerated to a human, but it's a lot harder for a computer to tell. It seems that google indexes sites of dubious value - but gives them a low pagerank. This means they do appear in results, but only if there is nothing more relevant available. All the best, Michael Foord ___ Python-Dev mailing list [email protected] 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 as : Baptiste> except with : 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] doc for new restricted execution design for Python
Ka-Ping Yee wrote: >Hi Brett, > >Here are some comments on the description of the restricted execution >model that you posted. > > [snip...] > >>Filesystem >>=== >> >>The most obvious facet of a filesystem to protect is reading from it. >>One does not want what is stored in ``/etc/passwd`` to get out. And >>one also does not want writing to the disk unless explicitly allowed >>for basically the same reason; if someone can write ``/etc/passwd`` >>then they can set the password for the root account. >> >> > >There's a big difference between modifying (or erasing) an existing file >and writing a new file (e.g. for temporary storage). If i give you a >little filesystem of your own to play in, and it starts out empty, you >can put whatever you want in it without violating my secrecy or the >integrity of my files. > >I think you should be talking about this in terms of specifically >what abilities you want to be able to allow, based on examples of >real-life applications. > > > > As an adjunct to this, one of the barriers to Javascript applications is the lack of client-side data persistence. This makes (amongst other things) offline, or entirely clientside, applications very difficult. All sorts of novel ways round this have been found [ http://codinginparadise.org/weblog/2006/04/now-in-browser-near-you-offline-access.html ]. If a 'standard' interpreter running in the browser had sandboxed access to the filesystem, this would be great. Of course Mozilla would probably disable it by default, and only provide horrific means for users to re-enable it [ http://www.mozilla.org/editor/midasdemo/securityprefs.html ]. All the best, Michael Foord http://www.voidspace.org.uk/python/index.shtml > > >-- ?!ng >___ >Python-Dev mailing list >[email protected] >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 [email protected] 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 [email protected] 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 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 [email protected] 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 [email protected] 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 > [email protected] > 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 [email protected] 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 [email protected] 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 [email protected] 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
