Mailman 3 November 2005 - Python-Dev

str.dedent
by Sokolov Yura Nov. 21, 2005

Nov. 21, 2005

>>/ msg = textwrap.dedent('''\ >/>/ IDLE's subprocess can't connect to %s:%d. This may be due \ >/>/ to your personal firewall configuration. It is safe to \ >/>/ allow this internal connection because no data is visible on \ >/>/ external ports.''' % address) >/>/ >/ >Unfortunately, it won't help, since the 'dedent' method won't treat >those spaces as indentation. > So that it would be usefull to implicit … [View More]

1 0

How to stay almost backwards compatible with all these new cool features
by Gregory Petrosyan Nov. 19, 2005

Nov. 19, 2005

Here's some of my ideas about subject. Maybe some of them are rather foolish, others -- rather simple and common... I just want to add my 2 cents to Python development. 1) What is the reason for making Python backwards incompatible (let it be just 'BIC', and let 'BC' stands for 'backwards compatible')? The reason is revolution. But how much can we get just from intensive evolution? 2) Is there any way both for staying (almost) BC and intense evolving? Yes. General rule is rather simple: make … [View More]old way of doing something *deprecated* (but *not* remove it entirely) and *add* the new way of doing this. But how to _force_ users to use new way instead of old? My proposal: Python should raise DeprecationError after old way is used: old_way() should be equivalent to old_way() raise DeprecationError('description') So people who want to use old way should write something like try: old_way() except DeprecationError: pass I think they soon will migrate to new style :-) [Manual/semi-automatic migration] Another benefit is that apps that were written for old-way Python version could be run under new-way Python after this simple modification (there might be standard script for making old apps compatible with new versions of Python!). [Automatic migration] 3) Staying BC means no revolutions in syntax. But there are problems with some of new-style features: a) 'raise' statement. I dislike idea about inheriting all exceptions from the base class and about removing 'raise' in favor of '.raise()'. Reasons: we can think about 'raise' as about more powerful variant of 'return'. Classic example is recursive search in binary tree: raising the result there seems to be very elegant and agile. Exception != Error is true IMHO. b) Interfaces. I like them. But isn't it ugly to write: interface SuperInterface: ... Note: 'interface' is repeated there two times! And this is *not* BC solution at all. Remember exception classes: class MyCommonError(Exception): ... but not exception MyCommonError(...): ... and it seems to be OK! And I have great agility with it: as mentioned, I can raise just 'some_object', but not only 'exception'. So, my proposal is syntax class SuperInterface(Interface): ... or maybe class SuperInterface: ... but not interface SuperInterface: ... Note: first two variants are BC solutions! And *yes*, you should be able to implement *any* class. Example: class Fish(object): def swim(): do_swim() # else ... class Dog(object): def bark(): do_bark() # else ... class SharkLikeDog(Fish) implements Dog Isn't it very good-looking? Note: IMHO Type == Implemented interface. So that's why every type/class can be used as interface. (Sorry for type/class mess). Could we find some benefits of it? c) I like Optional TypeChecking. But I think it could be improved with implementing some sort of Optional InterfaceChecking. Maybe like this: def f(a implements B, c: D = 'HELLO') implements E: # ?function implements interface? well, maybe it can be some type check interface? # some code here or def f(a implements B, c: D = 'HELLO') -> implements E: # some code here Summary -------------- Well, I think the main idea is (2): - Don't remove; make it strongly deprecated Then: - Some changes to interfaces implementation - etc ('raise' statement, InterfaceCheck -- see (3) ) Sorry for my English and for mess. -- Regards, Gregory. [View Less]

2 1

str.dedent
by Reinhold Birkenfeld Nov. 19, 2005

Nov. 19, 2005

Hi, some time ago, I proposed a string method "dedent" (which currently is in the textwrap module). The RFE is at http://python.org/sf/1237680. Any opinions? If I don't get positive comments, I'll reject it. Reinhold -- Mail address is perfectly valid!

16 26

Weekly Python Patch/Bug Summary
by Kurt B. Kaiser Nov. 19, 2005

Nov. 19, 2005

Patch / Bug Summary ___________________ Patches : 379 open (+14) / 2968 closed ( +7) / 3347 total (+21) Bugs : 910 open ( +6) / 5384 closed (+17) / 6294 total (+23) RFE : 200 open ( +0) / 191 closed ( +2) / 391 total ( +2) New / Reopened Patches ______________________ PythonD DJGPP-specific patch set for porting to DOS. (2005-11-08) http://python.org/sf/1351020 opened by Ben Decker PythonD new file: python2.4/plat-ms-dos5/djstat.py (2005-11-08) http://… [View More]

1 0

Enjoy a week without me
by Guido van Rossum Nov. 18, 2005

Nov. 18, 2005

Folks, I'm off for a week with my wife's family (and one unlucky turkey :-) in a place where I can't care about email. I will be back here on Monday Nov 28. -- --Guido van Rossum (home page: http://www.python.org/~guido/)

1 0

Re: [Python-Dev] isatty() on closed StringIO
by Walter Dörwald Nov. 18, 2005

Nov. 18, 2005

Paul Svensson wrote: > On Fri, 18 Nov 2005, Walter Dörwald wrote: > >> BTW, isatty() has a similar problem: >> >> >>> import StringIO, cStringIO >> >>> s = StringIO.StringIO() >> >>> s.close() >> >>> s.isatty() >> Traceback (most recent call last): >> File "<stdin>", line 1, in ? >> File "/usr/local/lib/python2.4/StringIO.py", line 93, in isatty >> _complain_ifclosed(self.closed)… [View More]

1 0

Another StringIO/cStringIO discrepancy
by Walter Dörwald Nov. 18, 2005

Nov. 18, 2005

>>> import StringIO, cStringIO >>> s = StringIO.StringIO() >>> s.truncate(-42) Traceback (most recent call last): File "<stdin>", line 1, in ? File "/usr/local/lib/python2.4/StringIO.py", line 203, in truncate raise IOError(EINVAL, "Negative size not allowed") IOError: [Errno 22] Negative size not allowed >>> s = cStringIO.StringIO() >>> s.truncate(-42) >>>

2 2

Iterating a closed StringIO
by Walter Dörwald Nov. 18, 2005

Nov. 18, 2005

Currently StringIO.StringIO and cStringIO.StringIO behave differently when iterating a closed stream: s = StringIO.StringIO("foo") s.close() s.next() gives StopIteration, but s = cStringIO.StringIO("foo") s.close() s.next() gives "ValueError: I/O operation on closed file". Should they raise the same exception? Should this be fixed for 2.5? Bye, Walter Dörwald

4 8

Memory management in the AST parser & compiler
by Jim Jewett Nov. 18, 2005

Nov. 18, 2005

There is a public-domain implementation of alloca at http://www.cs.purdue.edu/homes/apm/courses/BITSC461-fall03/listen-code/list… It would still fail on architectures that don't use a stack frame; other than that, it seems like a reasonable fallback, if alloca is otherwise desirable. -jJ

1 0

Re: [Python-Dev] Pre-PEP: Task-local variables
by Phillip J. Eby Nov. 17, 2005

Nov. 17, 2005

At 08:57 AM 10/20/2005 -0700, Guido van Rossum wrote: >Whoa, folks! Can I ask the gentlemen to curb their enthusiasm? > >PEP 343 is still (back) on the drawing table, PEP 342 has barely been >implemented (did it survive the AST-branch merge?), and already you >are talking about adding more stuff. Please put on the brakes! Sorry. I thought that 343 was just getting a minor tune-up. In the months since the discussion and approval (and implementation; Michael Hudson actually … [View More]had a PEP 343 patch out there), I've been doing a lot of thinking about how they will be used in applications, and thought that it would be a good idea to promote people using task-specific variables in place of globals or thread-locals. The conventional wisdom is that global variables are bad, but the truth is that they're very attractive because they allow you to have one less thing to pass around and think about in every line of code. Without globals, you would sooner or later end up with every function taking twenty arguments to pass through states down to other code, or else trying to cram all this data into some kind of "context" object, which then won't work with code that doesn't know about *your* definition of what a context is. Globals are thus extremely attractive for practical software development. If they weren't so useful, it wouldn't be necessary to warn people not to use them, after all. :) The problem with globals, however, is that sometimes they need to be changed in a particular context. PEP 343 makes it safer to use globals because you can always offer a context manager that changes them temporarily, without having to hand-write a try-finally block. This will make it even *more* attractive to use globals, which is not a problem as long as the code has no multitasking of any sort. Of course, the multithreading scenario is usually fixed by using thread-locals. All I'm proposing is that we replace thread locals with task locals, and promote the use of task-local variables for managed contexts (such as the decimal context) *that would otherwise be a global or a thread-local variable*. This doesn't seem to me like a very big deal; just an encouragement for people to make their stuff easy to use with PEP 342 and 343. By the way, I don't know if you do much with Java these days, but a big part of the whole J2EE fiasco and the rise of the so-called "lightweight containers" in Java has all been about how to manage implicit context so that you don't get stuck with either the inflexibility of globals or the deadweight of passing tons of parameters around. One of the big selling points of AspectJ is that it lets you implicitly funnel parameters from point A to point B without having to modify all the call signatures in between. In other words, its use is promoted for precisely the sort of thing that 'with' plus a task variable would be ideal for. As far as I can tell, 'with' plus a task variable is *much* easier to explain, use, and understand than an aspect-oriented programming tool is! (Especially from the "if the implementation is easy to explain, it may be a good idea" perspective.) >I know that somewhere in the proto-PEP Phillip argues that the context >API needs to be made a part of the standard library so that his >trampoline can efficiently swap implicit contexts required by >arbitrary standard and third-party library code. My response to that >is that library code (whether standard or third-party) should not >depend on implicit context unless it assumes it can assume complete >control over the application. I think maybe there's some confusion here, at least on my part. :) I see two ways to read your statement, one of which seems to be saying that we should get rid of the decimal context (because it doesn't have complete control over the application), and the other way of reading it doesn't seem connected to what I proposed. Anything that's a global variable is an "implicit context". Because of that, I spent considerable time and effort in PEAK trying to utterly stamp out global variables. *Everything* in PEAK has an explicit context. But that then becomes more of a pain to *use*, because you are now stuck with managing it, even if you cram it into a Zope-style acquisition tree so there's only one "context" to deal with. Plus, it assumes that everything the developer wants to do can be supplied by *one* framework, be it PEAK, Zope, or whatever, which is rarely the case but still forces framework developers to duplicate everybody else's stuff. In other words, I've come to realize that the path the major Python application frameworks is not really Pythonic. A Pythonic framework shouldn't load you down with new management burdens and keep you from using other frameworks. It should make life easier, and make your code *more* interoperable, not less. Indeed, I've pretty much come to agreement with the part of the Python developer community that has says Frameworks Are Evil. A primary source of this evil in the big three frameworks (PEAK, Twisted, and Zope) stem from their various approaches to dealing with this issue of context, which lack the simplicity of global (or task-local) variables. So, the lesson I've taken from my attempt to make everything explicit is that what developers *really* want is to have global variables, just without the downsides of uncontrolled modifications, and inter-thread or inter-task pollution. Explicit isn't always better than implicit, because oftentimes the practicality of having implicit things is much more important than the purity of making them all explicit. Simple is better than complex, and task-local variables are *much* simpler than trying to make everything explicit. >Also, Nick wants the name 'context' for PEP-343 style context >managers. I think it's overloading too much to use the same word for >per-thread or per-coroutine context. Actually, I was the one who originally proposed the term "context manager", and it doesn't seem like a conflict to me. Indeed, I suggested in the pre-PEP that "@context.manager" might be where we could put the decorator. The overload was intentional, to suggest that when creating a new context manager, it's worth considering whether the state should be kept in a context variable, rather than a global variable. The naming choice was for propaganda purposes, in other words. :) Anyway, I'll withdraw the proposal for now. We can always leave it out of 2.5, I can release an independent implementation, and then submit it for consideration again in the 2.6 timeframe. I just thought it would be a no-brainer to use task locals where thread locals are currently being used, and that's really all I was proposing we do as far as stdlib changes anyway. I was also hoping to get good input from Python-dev regarding some of the open issues, to try and build a consensus on them from the beginning. [View Less]

7 7