Mailman 3 June 2003 - Python-Dev

Re: [Python-checkins] python/dist/src/Objectslistobject.c,2.153,2.154
by Neal Norwitz 17 Jun '03

17 Jun '03

Moving to python-dev. On Tue, Jun 17, 2003 at 09:28:50AM -0400, Raymond Hettinger wrote: > > I suppose we could have more debate after the fact, > but this one seems straight-forward enough: > > * discussed on comp.lang.python > * had an RFE on SF > * has clear use cases > * got a +1 from Guido > * is backwards compatible > * matches the signature of str.index() and unicode.index() > * matches the search technique for regular expressions > * was a relatively simple coding change > * checked in with thorough tests While overall I think the idea is worthwhile, I have two concerns: * the doc wasn't updated * negative indices are handled differently: >>> 'abc'.split().index('a', -3) Traceback (most recent call last): File "<stdin>", line 1, in ? ValueError: list.index(x): x not in list >>> 'abc'.index('a', -3) 0 Neal > ----- Original Message ----- > From: "Barry Warsaw" <barry(a)python.org> > > This seems like a pretty significant change to Python's API (or at least > one of its more common built-ins). Given that Python 2.3 is in beta, > I'm wondering how wise it is to add this feature. I'm sure I missed the > python-dev debate about it <wink>.

3 3

RE: [Python-Dev] New PEP: 319
by Moore, Paul 17 Jun '03

17 Jun '03

From: Michael Chermside [mailto:mcherm@mcherm.com] > Michel Pelletier writes: > [...] >> No explicit lock is necessary. Any object may be synchronized upon >> (except, perhaps, None). > [...] > In my opinion, this is one of the glaring *flaws* of the java threading > and synchronization model. Locks are entities of their own, to be used > when synchronization is needed. There does NOT need to be a lock > associated with each and every object in the system (even if, as an > implementation detail, that lock isn't created unless it is used). If > a programmer needs to synchronize, they should THINK about what exactly > needs to be synchronized with what, and create an appropriately named > lock. Explicit is better than implicit. Making it "easy" for programmers > who use threads by making unnecessary for them to think about details > like which lock is used for what synchronization, is almost certainly > NOT doing them a favor... instead, it's just inviting subtle, hard-to- > find bugs. I agree entirely. Thank you for putting it so well. Paul.

1 0

IDLE bug?
by Gus Tabares 17 Jun '03

17 Jun '03

Hey all, Does anyone have an issue trying to get the 'Save Copy As...' control keys to work in IDLE under Windows? (Alt+Shift+S) I'm not sure if this is the right place to post bugs about IDLE. I've tested this on 4+ machines and it did not work on all of them. Maybe this is already a known issue? Is anyone else experiencing this? Thanks, Gus

2 1

RE: PEP-317
by Michael Chermside 16 Jun '03

16 Jun '03

Greg Ewing: > Also while we're at it, how about storing the traceback in the > exception object, and getting rid of sys.exc_info() etc.? Guido: > That's a good idea, and I'd support a PEP on that topic more than PEP > 317 (which IMO is unnecessary). IMO the biggest advantage of PEP 317 is not what it does directly but the future enhancements it allows. If all exceptions really are objects, (particularly if strengthened to say "instances of Exception or subclasses") then we can add new features to Exception. Moving the traceback into the object is one idea. Making Exception a new-style object is another (no need to rush, but it'll happen SOMEDAY, right?). Exception chaining (aka exception masking) is another. The point is, without PEP 317, you can't do these things, because sometimes you use an object, and sometimes just mention a class (and sometimes just use a string). PEP 317 choose not to try to bite off anything bigger than fixing this so future enhancements would be possible. But we EVER want these kinds of enhancements, then start a PEP 317 style migration NOW, because degree of code breakage means that the migration time will be really slow. Deprecating (ideally with warnings) sooner is better. -- Michael Chermside

9 14

problem with assignment shadows builtin warning
by Jeremy Hylton 16 Jun '03

16 Jun '03

I ran into a problem with the new deprecation warning today. When you are doing package imports, Python uses setattr to populate the namespace of the parent package. That is, if you import A.B.C, Python does the equiavalent of setattr(A, "B", A.B) and setattr(A.B, "C", A.B.C). The result is that I get a bunch of deprecation warnings if my modules shadow builtin names. Module names that are also builtin names are common in some work projects. (Ouput from our test runner is at the end of the message.) Do we want to discourage the use of module names that overlap with builtin names? If so, we need a better error message, because if you go to the line mentioned in the warning you won't see an obvious assignment :-). My initial reaction was that we should not have a deprecation warning for this kind of shadowing, but I'm growing less comfortable about the names. I'd definitely complain about a top-level "import list"; I don't know why it is any better as a module within a package. Jeremy /home/jeremy/src/Zope3/build/lib.linux-i686-2.3/zope/app/security/_protections.py:85: DeprecationWarning: assignment shadows builtin from persistence.list import PersistentList /home/jeremy/src/Zope3/build/lib.linux-i686-2.3/zope/app/security/_protections.py:93: DeprecationWarning: assignment shadows builtin from persistence.dict import PersistentDict /home/jeremy/src/Zope3/build/lib.linux-i686-2.3/zope/app/event/globalservice.py:22: DeprecationWarning: assignment shadows builtin from zope.interface.type import TypeRegistry /home/jeremy/src/Zope3/build/lib.linux-i686-2.3/zope/app/ftp/__init__.py:22: DeprecationWarning: assignment shadows builtin from zope.app.interfaces.file import IReadFile, IWriteFile /home/jeremy/src/Zope3/build/lib.linux-i686-2.3/zodb/storage/tests/test_demo.py:21: DeprecationWarning: assignment shadows builtin from zodb.storage.file import FileStorage /home/jeremy/src/Zope3/build/lib.linux-i686-2.3/zope/app/event/subs.py:37: DeprecationWarning: assignment shadows builtin from zope.app.services.type import PersistentTypeRegistry /home/jeremy/src/Zope3/build/lib.linux-i686-2.3/zope/app/browser/content/image.py:19: DeprecationWarning: assignment shadows builtin from zope.app.browser.content.file import FileUpload /home/jeremy/src/Zope3/build/lib.linux-i686-2.3/zope/app/content/file.py:26: DeprecationWarning: assignment shadows builtin from zope.app.interfaces.content.file import IFile, IReadFile, IFileContent /home/jeremy/src/Zope3/build/lib.linux-i686-2.3/zope/app/content/image.py:18: DeprecationWarning: assignment shadows builtin from zope.app.content.file import File

4 8

Re: [Python-Dev] New PEP: 319
by Samuele Pedroni 16 Jun '03

16 Jun '03

Look here, if want a (short) summary of current thinking on java sync primitives from Java side: <http://www.jcp.org/en/jsr/detail?id=166> Python is already doing things alright, it already has got the higher-level constructs. 'synchronized' makes sense on methods to have thread-safe data structures. The rest of Java synchronization facilities should really be used to construct higher-level tools. I think 'with' is very likely a worthy addition. And maybe something along the lines of: class C(object,Synchronizable): def meth(self,...) [syncmethod]: ... I'm very skeptical about syncrhonize/asynchronize and implicit locks associated/able with all objects. regards. At 13:55 16.06.2003 -0500, Michel Pelletier wrote: > >> I don't see how this can possibly work. It looks like self.counter is > >> an int, so the statement > >> synchronize self.counter: ... > >> must be using some particular int (say, 3) for purposes of > >> synchronization. What sense does this make? > > > > Hmm good point, integer objects are a special case, they are shared and > > are thus a bad example. Perhaps only instances should be synchronizable. > > > >> (and where can you store > >> the lock, since an int is immutable and can't have new attributes > >> created?) > > > > that's up to the implementation. Lock association does not effect > > mutability. > >I should add that I am experimenting with this in Jython, not CPython >which is why I said it's up to the implementation. I immagine CPython >would add some unitialized behind-the-scenes pointer to a lock object and >lazily initialize and lock it when the object is first sychronized. Any >subsequent asynchronizing or sychronizing would use this lock until the >object is garbage collected. > > >> On the other hand, if the thing you're locking is the counter > >> attribute of slot (and ignoring for a moment where the lock is stored) > >> then what if self.counter is a list but id(self.counter) == > >> id(globallist)? > > > > If they have the same id() they are the same object and thus the same > > associated lock. the below code will be prevented from executing at the > > same time. > >Ah I'm going over all the emails I got today for my next revision and >sorry I missed where you said "attribute of the slot" the first time I >read it. You meant, I gather, sychronizing on the slot and not the value >it stores. Sorry to confuse things. I do not think sychronizing on the >slot is the right thing (as I said above). > >Thanks for everyones comments, please keep sending them if you have them. > >-Michel > >_______________________________________________ >Python-Dev mailing list >Python-Dev(a)python.org >http://mail.python.org/mailman/listinfo/python-dev

2 1

"%%s %s"%"hi"%ho" works here and not there
by Hunter Peress 16 Jun '03

16 Jun '03

In irc, I gave this unusually compact line as an answer to a slightly related question: "%%s %s"%"hi"%ho" It ended up not working on a lot of the other users systems. "%%s %s"%a%b worked though on all i believe. Although this alone is probably too trivial to report to the list, it works on *my* 2.2.2 and 2.3b and yet it worked no one elses. Im on debian and the versions where this work are: Python 2.2.2 (#1, Mar 21 2003, 23:01:54) [GCC 3.2.3 20030316 (Debian prerelease)] and Python 2.3b1+ (#2, May 14 2003, 07:47:44) [GCC 3.2.3] on linux2 I've confirmed with a friend on debian unstable that his 2.2.3 and his 2.3b1 (built on june4) both error out on the line above. Anyway, i cant even figure out from the grammar whether this should or should not be allowed: http://python.org/doc/2.2/ref/strings.html __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com

6 7

Details on Python shutting down
by Brett C. 16 Jun '03

16 Jun '03

On bug #754449 I suspected something was being set to None by a person's app and ended up writing a trace function to catch when that happened. Time then stepped in and pointed out that the OP said when Python was shutting down and that globals are set to None during tear down which would explain the behavior. He suggested I move this over to python-dev. So, what exactly does Python do during shutdown? I assume all objects get cleaned up and have their __del__ methods called if they have them. Tim mentioned in the patch that Python "systematically sets module-global bindings to None". So I assume this means that referencing *any* globals during shutdown just doesn't work since it might be None (which makes sense in the case of this bug report). Is there any specific order to this teardown? I remember Tim saying that in __del__ methods you had to have locally bound anything you needed to call since otherwise it could be gone when you need it. Any words of wisdom here would be greatly appreciated. -Brett

3 2

New PEP: 319
by Michael Chermside 16 Jun '03

16 Jun '03

Michel Pelletier writes: [...] > No explicit lock is necessary. Any object may be synchronized upon > (except, perhaps, None). [...] In my opinion, this is one of the glaring *flaws* of the java threading and synchronization model. Locks are entities of their own, to be used when synchronization is needed. There does NOT need to be a lock associated with each and every object in the system (even if, as an implementation detail, that lock isn't created unless it is used). If a programmer needs to synchronize, they should THINK about what exactly needs to be synchronized with what, and create an appropriately named lock. Explicit is better than implicit. Making it "easy" for programmers who use threads by making unnecessary for them to think about details like which lock is used for what synchronization, is almost certainly NOT doing them a favor... instead, it's just inviting subtle, hard-to- find bugs. -- Michael Chermside

1 0

RE: [Python-Dev] New PEP: 319
by Delaney, Timothy C (Timothy) 16 Jun '03

16 Jun '03

> From: Roman Suzi [mailto:rnd@onego.ru] > > What about just adding a parameter to try operator? > > def increment(self): > try self.counter_lock: > self.counter += 1 > > - this will save from keyword and could also be used with > except part with, for example, se-syncronization outcomes > for some kinds of locks: > > def increment(self): > try self.counter_lock: > self.counter += 1 > except SomeLockError: > bla-bla-bla Hmm - so this is essentially the initially: self.counter_lock.acquire() try: ... finally: self.counter_lock.release() but with the condition that the "parameter" to try implement the Lockable interface (or something along those lines). Interesting idea. Not sure about the syntax, but I think we could go somewhere with this. Tim Delaney

1 0