Mailman 3 August 2004 - Python-Dev

Tuple/list assignment question
by Dave Cole 08 Aug '04

08 Aug '04

Is there any reason why something like this would not be a good idea? >>> a_list = [1, 2, 3, 4, 5] >>> a, b, *c = a_list You could then do things like this: >>> lol = [[1, 2], [3, 4, 5, 6, 7], [8, 9, 10, 11, 12, 13]] >>> for a, b *c in lol: ... - Dave -- http://www.object-craft.com.au

8 12

Attribute strings?
by Edward K. Ream 08 Aug '04

08 Aug '04

Has anyone suggested the following? Create a new kind of string, _not_ a docstring, to hold annotations, etc. """@annotate whatever""" or even ""@" whatever""" Pros: Open ended possibilities, might quiet dissent, could be placed before function or inside it. Biggest drawback: something that looks like a string will affect generated code. thinking-inside-the-string'ly yours, Edward -------------------------------------------------------------------- Edward K. Ream email: edreamleo(a)charter.net Leo: Literate Editor with Outlines Leo: http://webpages.charter.net/edreamleo/front.html --------------------------------------------------------------------

2 1

Thoughts on validation, events, rules
by Jim Fulton 08 Aug '04

08 Aug '04

I'm a bit unsatisfied with container constraints: http://dev.zope.org/Zope3/ContainmentConstraints While I think this was a step forward conceptually, it has turned out to be a bit unwieldy in practice: - Container constraints are difficult to express. I've written convenience API's to make the basic machinery of expressing constraints easier, but there is a problem that's not so easy to fix. Often you want to express a symmetric constraint between two interfaces. For example, you want to say that objects implementing I1 can only contain objects implementing I2 and that objects implementing I2 can only be contained in objects implementing I1. If the constraint is expressed in the interfaces themselves, you can only express it by either defining the interfaces in a single operation or by mutating the interfaces. I don't like the idea of mutating interfaces, but perhaps I just need to get over that. - Container constraints are cumbersome to check. - Container constraints force the contained objects to implement IContained. This is fine when the contained objects will actually access their containers. Often, however, we want to constrain an object's container for external reasons. For example, we might want to only allow indexes to be added to catalogs, even though indexes are passive and never invoke operations on their containers. In this case, the constraint is not part of the index's contract. I've been thinking of other ways to solve this problem. In the context of schema validation, we've been thinking of using subscription adapters: http://dev.zope.org/Zope3/NoMoreSchemaBinding http://mail.zope.org/pipermail/zope3-dev/2004-June/011315.html The advantage of subscription adapters is that they provide the ability to express constraints in a highly flexible and decentralized manner. Another advantage of using subscription adapters is that doing so takes advantage of a highly optimized mechanism and should be fairly efficient. It occurred to me today that subscription adapters provide a form of rule-based processing. Any number of rules (subscribers) can fire as the result of some event, where an event could take the form of a query, such as "validate adding this object to this container" or "validate setting this attribute to this value". It's interesting to note that validating adding an object to a container and validating assigning an attribute are both special cases of validating establishing a relationship between two objects. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org

1 1

Re: Python-Dev Digest, Vol 13, Issue 77
by Peter Harris 08 Aug '04

08 Aug '04

Andrew Durdin wrote: Message: 6 Date: Sat, 7 Aug 2004 22:36:59 +1000 From: Andrew Durdin <adurdin(a)gmail.com> Subject: [Python-Dev] Decorators with arguments are curries! To: python-dev(a)python.org Message-ID: <59e9fd3a04080705361b6314be(a)mail.gmail.com> Content-Type: text/plain; charset=US-ASCII Having waded through all the decorator syntax discussions recently, and some of the historical ones, I haven't found this point mentioned before, so I'll bring it up now: Consider the following code: def foo(bar): return 1 a = foo a = foo(bar) The first assignment to a is binding a reference to a function; the second is calling the function. This is a very significant difference in python, and I'm concerned that all the current proposed decorator syntaxes[*] are liable to cause confusion on this point. For example: def foo_decorator(func): print "no params to this" return func def bar_decorator(func, param): print param return func @foo_decorator @bar_decorator("one param here") def decorated_func(): pass Here the first decorator statement is bare, while the second one includes parentheses and an argument; the first one looks like a function reference, while the second looks like a function call. I find this confusing; semantically, this appears to equivalent to (assuming expressions are allowed in decorator statements): # using curry as proposed in PEP 309 [**] @foo_decorator @curry(bar_decorator, "one param here") def decorated_func(): pass Most of my concern here is that this aspect of decorator syntax appears to be implicitly introducing a currying syntax in one special circumstance, which is then *not* transferable to currying functions in normal situations, as it would conflict with function calling. And if a currying syntax (or built-in) was introduced down the track, then these decorators would be inconsistent with them. Has anyone else noticed this issue? Andrew Durdin [*] Except those which don't allow for arguments [**] For a nice coincidence, PEP 309 suggested using '@' to mark curries Hmm. I sort of see what you're on about, but please note: PEP309 no longer proposes (and didn't for long) using '@'. The callable class in PEP309 is called partial() not curry() because it's not technically a curried function in the narrow computer-science sense, and if we mis-named it the Haskell folks would point and laugh. You could use partial() on decorators as well as functions and classes, and though it would melt my brain, I'm sure someone out there would see a beautifully elegant use for it. PEP309 is accepted but not checked in; @ decorators are checked in but tentative. On topic: @ is OK but I prefer the recently suggested |. pie, pipe = (+0.5, +1) Peter Harris

1 0

hi I am new in the list
by Rafael Ernesto Moran Bautista 08 Aug '04

08 Aug '04

hi, my name is Rafael Mor�n and I am new in this list, I hope help in this an interesting project called Python. I think could help in these topics: Translations (my native language is spanish and know a little of english), Python programming, C/C++ programming. Att. Rafael Mor�n __________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail

2 1

decimal.Context.copy() shallow or deep?
by Raymond Hettinger 08 Aug '04

08 Aug '04

Currently, the copy() method for Context objects makes a shallow copy of the context. To get a deepcopy, you have to use copy.deepcopy(thecontext). Though, copies are usually shallow and deepcopies are deep, I'm now having misgivings about the copy method. I would think that a deep copy is almost invariably what you would want and expect, (i.e. the copy doesn't share traps and flags with the original). Do you guys think it should be left alone (shallow) or changed (made deep)? The wrinkle in all this is that internally the module makes many uses of copy and expects it to be shallow (or least, tests fail in droves when copy is made deep). So I would have to rename the current copy to _shallow_copy and replace the original with a deep version for the public API. Any thoughts? Raymond

3 2

RE: [Python-Dev] @decorators, the PEP and the "options" out there?
by Tony Meyer 07 Aug '04

07 Aug '04

[Tim Peters explaining that you don't have to crunch everything up together] > That bothers me a lot too, but because the world really isn't running > out of vertical whitespace: > > class MyLittleToy: > > def methy1(self): > print 'whee' > > @staticmethod > def methy2(): > print 'woo' > > @staticmethod > def methy3(arg): > for i in arg: > print 'woohoo' If the syntax does end up along these lines (and I'm expressing no opinion either way), then maybe it would be worth explicitly telling people (i.e. in PEP 8) that they ought to put a blank line before decorators to make it clear? Yes, people should figure this themselves, but they probably won't <0.5 wink>, and it does make for ugly code. Same deal for "don't do '@this @and_this @on_the_same_line'" (unless that loses it's validity). (And if some other syntax 'wins', then a guide for using that couldn't hurt, too). =Tony Meyer p.s. Anyone else have a suspicion that Anthony checked in the @decorators to 2.4a2 as a sneaky way of getting more people than normal (all them riled up ones) to download the alpha and try it out? <wink>

3 2

Re: [Python-checkins] python/dist/src/Lib/test test_builtin.py, 1.33, 1.34
by Michael Hudson 07 Aug '04

07 Aug '04

jhylton(a)users.sourceforge.net writes: > Update of /cvsroot/python/python/dist/src/Lib/test > In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv9225/Lib/test > > Modified Files: > test_builtin.py > Log Message: > Subclasses of string can no longer be interned. The semantics of > interning were not clear here -- a subclass could be mutable, for > example -- and had bugs. Explicitly interning a subclass of string > via intern() will raise a TypeError. Internal operations that attempt > to intern a string subclass will have no effect. > > Added a few tests to test_builtin that includes the old buggy code and > verifies that calls like PyObject_SetAttr() don't fail. Perhaps these > tests should have gone in test_string. Would have been nice if you'd run the test suite before checking this in... test_descr contains stuff like: s = madstring("x y") vereq(s, "x y") verify(intern(s).__class__ is str) verify(intern(s) is intern("x y")) vereq(intern(s), "x y") though if madstring was mad enough to redefine __hash__, maybe it wouldn't. Cheers, mwh -- > It might get my attention if you'd spin around in your chair, > spoke in tongues, and puked jets of green goblin goo. I can arrange for this. ;-) -- Barry Warsaw & Fred Drake

1 0

Pickler()'s bin argument
by A.M. Kuchling 07 Aug '04

07 Aug '04

PEP 307 says this about Pickler: Passing 'bin' as a keyword argument is deprecated, and a PendingDeprecationWarning is issued in this case. You have to invoke the Python interpreter with -Wa or a variation on that to see PendingDeprecationWarning messages. In Python 2.4, the warning class may be upgraded to DeprecationWarning. Should I change it to become a DeprecationWarning in 2.4? --amk

3 2

RE: [spambayes-dev] bug in imap filter or in email package
by Tony Meyer 07 Aug '04

07 Aug '04

There has been a little bit of discussion on spambayes-dev about a bug with the 2.4a1 email package, where header lines that end with \r\n are not treated correctly (the value ends up with a \r at the end). A SF bug was opened for this: [ 1002475 ] email message parser doesn't handle \r\n correctly <http://sf.net/tracker/?group_id=5470&atid=105470&func=detail&aid=1002475> I've created a patch to fix this, and a couple of tests to add to test_email.py: [ 1003693 ] Fix for 1002475 (Feedparser not handling \r\n correctly) <http://sf.net/tracker/index.php?func=detail&aid=1003693&group_id=5470&atid= 305470> If someone would like to review this and check it in after 2.4a2 is all done that would be great. Maybe someone at the bug day? (I might come along to that, but it's the middle of the night, so probably not). Thanks! =Tony Meyer

2 1