Mailman 3 July 2010 - Python-Dev

Re: [Python-Dev] Removing IDLE from the standard library
by David Beazley July 13, 2010

July 13, 2010

> I would like to propose removing IDLE from the standard library. > -1000. From the Python training department, I would like to say that this would be a horrible idea. Having taught numerous on-site training courses for Python, the one thing that I've learned is that you never know what you're going to get when you show up to teach a course. More often than not, you're thrown into some training room with a bunch of PCs, operated by someone who doesn't know anything about Python at all, and who had a hard enough time installing it in the first place. The fact that IDLE comes with Python means that even in such situations, as long as Python has been installed somewhere, there's going to be at least one halfway-reasonable environment for working with it (although I suppose there are some people who would still prefer to use the Windows command shell and Notepad). For what it's worth, I think IDLE works fine as a development environment, despite the fact that it has some flaky bits. The most annoying issue that I encounter in classes is people starting IDLE by right-clicking on files. This starts up IDLE without its subprocess and causes all sorts of bizarre problems related to the environment (e.g., restarting, module imports, etc.). Other than that, it's fine. Cheers, Dave

11 20

Re: [Python-Dev] avoiding accidental shadowing of top-level libraries by the main module
by Nick Coghlan July 13, 2010

July 13, 2010

On Tue, Jul 13, 2010 at 7:47 AM, Fred Drake <fdrake(a)acm.org> wrote: > On Mon, Jul 12, 2010 at 5:42 PM, Michael Foord > <fuzzyman(a)voidspace.org.uk> wrote: >> I'm sure Brett will love this idea, but if it was impossible to reimport the >> script being executed as __main__ with a different name it would solve these >> problems. > > Indeed! And I'd be quite content with such a solution, since I > consider scripts and modules to be distinct. And here I've been busily blurring that distinction for years ;) (actually, the whole "name == '__main__'" idiom meant the distinction was already pretty blurry long before I got involved) I take it the concrete proposal here is if the filename of a new module matches either __main__.__file__ or __main__.__cached__, then that module should be ignored completely for import purposes allowing a module with the same name later on sys.path to be found? I'm not sure I like that, I'd be more inclined to just return the __main__ module in that case rather than letting the search continue further down sys.path (although I agree the current semantics of getting two copies of the same module under different names in this case are less than ideal). Cheers, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia

3 5

Problem with executing python interpretetor on special build of win server 2003
by Бажен Ржеутский July 13, 2010

July 13, 2010

Hello. Actual problem in the next, when i trying to execute portable python on my build then nothing happens, and the error code is 128. What does mean this code 128?

2 1

Re: [Python-Dev] [Idle-dev] Removing IDLE from the standard library
by Beni Cherniavsky-Paskin July 13, 2010

July 13, 2010

On Sun, Jul 11, 2010 at 18:20, Tal Einat <taleinat(a)gmail.com> wrote: > The (hopefully) compelling arguments were others, such as the sentence > following the one you quoted: > > "I think that in its current state, IDLE may still be helpful for > learning Python, but it is more likely to drive away users who run > into its various quirks and problems." > > Having taught a few Python courses myself, I must say that while not perfect [I had to apologize for some IDLE issues, which shamed me into filing bugs/patches for some of them], it is *better* for interactive use than most other IDEs! That's IMHO the #1 is the real reason that makes it ideal for teaching, not the fact that it's bundled with Python. I wouldn't mind telling people "install Python and X" instead of "install Python", but very few Python environments do multiline history correctly :-(. The only one I know that beats IDLE is Dreampie (designed by Noam Raphael, a long time IDLE contributor). However, without an editor and F5 it's not a winner for teaching. For the record, I'm -42 on removing IDLE from the distribution (unless you have a better replacement?), but +1 on widening commit access and setting up one obvious way for users to try bleeding-edge IDLE. -0 on extracting it from the stdlib (it's one way to implement the above, not sure if best way). But here's a thought: why not make IDLE an early adopter of Mercurial? It seems to me that could ease a lot of the issues: - contributors will be able to publish their changes without waiting for official commiters - contributors will be able to maintain "beefed up" IDLE branches with much less pain - trying out bleeding-edge branches would be much simpler - I expect a de-facto "stable" IDLE branch will emerge from the community -- Beni Cherniavsky-Paskin <cben(a)users.sf.net>

1 0

Intended behavior of backlash in raw strings
by John Arbash Meinel July 13, 2010

July 13, 2010

I'm trying to determine if this is intended behavior: >>> r"\"" '\\"' >>> r'\'' "\\'" Normally, the quote would end the string, but it gets escaped by the preceding '\'. However, the preceding slash is interpreted as 'not a backslash' because of the raw indicator, so it gets left in verbatim. Note that it works anywhere: >>> r"testing \" backslash and quote" 'testing \\" backslash and quote' It happens that this is the behavior I want, but it seemed just as likely to be an error. I tested it with python2.5 and 2.6 and got the same results. Is this something I can count on? Or is it undefined behavior and I should really not be doing it? John =:->

2 1

Re: [Python-Dev] Removing IDLE from the standard library
by Tal Einat July 13, 2010

July 13, 2010

Guido van Rossum wrote: >David Beazley wrote: >> >>> I would like to propose removing IDLE from the standard library. >>> >> >> -1000. From the Python training department, I would like to say that this would be a horrible idea. > >Right. IDLE fits a niche. It's never going to be the world's best >Python development environment but it isn't the worst either, and it's >worth keeping around. > >There clearly are *some* folks who care enough about IDLE to submit >bug reports and fixes. How about we empower these people by giving at >least one of them commit privileges? IDLE development has often been >done by people who aren't otherwise contributing to the core, and we >surely should trust those folks with commit privileges. This would certainly be a great improvement on the current situation. However, I still think IDLE is not currently in a state that it should be suggested for use by beginners. - Tal Einat

2 1

Python equivalents in stdlib Was: Include datetime.py in stdlib or not?
by Alexander Belopolsky July 13, 2010

July 13, 2010

On Tue, Jul 6, 2010 at 11:54 PM, Terry Reedy <tjreedy(a)udel.edu> wrote: > On 7/6/2010 3:59 PM, Alexander Belopolsky wrote: > > I am more interested in Brett's overall vision than this particular module. > I understand that to be one of a stdlib that is separate from CPython and is > indeed the standard Python library. > I am also very much interested in the overall vision, but I would like to keep the datetime.py thread focused, so I a going to reply to broad questions under a separate subject. > Questions: > > 1. Would the other distributions use a standard stdlib rather than current > individual versions? I certainly hope they will. In the ideal word, passing test.regrtest with unmodified Lib should be *the* definition of what is called Python. I understand that there is already some work underway in this direction such as marking implementation specific tests with appropriate decorators. > > 2. Would the other distributions pool their currently separate stdlib > efforts to help maintain one standard stdlib? I believe that making stdlib and test.regrtest more friendly to alternative implementations will go long way towards this goal. It will, of course, be a decision that each project will have to make. > > 3. What version of Python would be allowed for use in the stdlib? I would > like the stdlib for 3.x to be able to use 3.x code. This would be only a > minor concern for CPython as long as 2.7 is maintained, but a major concern > for the other implementation currently 'stuck' in 2.x only. A good 3to2 > would be needed. Availability of python equivalents will hopefully help "other implementation currently 'stuck' in 2.x only" to get "unstuck" and move to 3.x. I understand that this is a somewhat sensitive issue at the moment, but I believe a decision has been made supporting new features for 2.x is outside of python-dev focus. > 4. Does not ctypes make it possible to replace a method of a Python-coded > class with a faster C version, with something like > try: > connect to methods.dll > check that function xyx exists > replace Someclass.xyy with ctypes wrapper > except: pass > For instance, the SequenceMatcher heuristic was added to speedup the > matching process that I believe is encapsulated in one O(n**2) or so > bottleneck method. I believe most everything else is O(n) bookkeeping. > The ctypes modules is very CPython centric as far as I know. For the new modules, this may be a valid way to rapidly develop accelerated versions. For modules that are already written in C, I don't see much benefit in replacing them with ctypes wrappers. > [.. datetime specific discussion skipped ..] > From scanning that and the posts here, it seems like a pep or other doc on > dual version modules would be a good idea. It should at least document how > to code the switch from python version to the x coded version and how to > test both, as discussed. > I am certainly not ready to write such PEP. I may be in a better position to contribute to it after I gain more experience with test_datetime.py. At the moment I have more questions than answers. For example, the established practice appears to be: modulename.py # Python code try: from _modulename import * except: pass This is supposed to generate a .pyc file with no python definitions in it if _modulename is available. The problem with datetime.py is that it have several helper methods like _ymd2ord() that will still stay in the module. Should an "else:" clause be added to clean these up? should these methods become class or static methods as appropriate? The established practice for testing is py_module = support.import_fresh_module('modulename', blocked=['_modulename']) c_module = support.import_fresh_module('modulename', fresh=['_modulename']) class TestDefnitions: # not a unittest.TestCase subclass def test_foo(self): self.module.foo(..) ... class C_Test(TestDefnitions, unittest.TestCase): module = c_module class Py_Test(TestDefnitions, unittest.TestCase): module = py_module For datetime.py this approach presents several problems: 1. replacing datetime with self.module.datetime everywhere can get messy quickly. 2. There are test classes defined at the test_datetime module level that subclass from datetime classes. The self.module is not available at the module level. These should probably be moved to setUp() methods and attached to test case self. 3. If #2 is resolved by moving definitions inside functions, the classes will become unpickleable and pickle tests will break. Some hackery involving injecting these classes into __main__ or module globals may be required. These challenges make datetime.py an interesting showcase for other modules, so rather than writing a PEP based on abstract ideas, I think it is better to get datetime.py integrated first and try to establish the best practices on the way.

9 30

PEP 3148 ready for pronouncement [ACCEPTED]
by Titus von der Malsburg July 13, 2010

July 13, 2010

Hi I learned about the futures PEP only today. I saw the example on http://code.google.com/p/pythonfutures/ One thing that worries me is that this approach seems to bypass the usual exception handling mechanism of Python. In particular I'm wondering why you have to do things like: if future.exception() is not None: ... This reminds me a lot of how things are done in C but it's not very pythonic. Wouldn't it be possible and nicer to raise the exception -- if there was one inside the asynchronous job -- when the result of the future is accessed? try: print('%r page is %d bytes' % (url, len(future.result()))) except FutureError: print('%r generated an exception: %s' % (url, future.exception())) Best, Titus

4 4

A grammatical oddity: trailing commas in argument lists.
by Mark Dickinson July 12, 2010

July 12, 2010

While looking at a parser module issue (http://bugs.python.org/issue9154) I noticed that Python's grammar doesn't permit trailing commas after keyword-only args. That is, def f(a, b,): pass is valid syntax, while def f(*, a, b,): pass is not. I was just curious whether the latter was deliberate or an oversight. And if an oversight, is it worth fixing after the moratorium expires? (See also http://bugs.python.org/issue2009.) Mark

6 10

Re: [Python-Dev] Removing IDLE from the standard library
by Glyph Lefkowitz July 12, 2010

July 12, 2010

On Jul 12, 2010, at 4:34 AM, Éric Araujo wrote: >> Plus, <http://twistedmatrix.com/trac/report/15> is a useful resource >> for core developers with only a little bit of free time to do a >> review. > > Title: “Review Tickets, By Order You Should Review Them In” > I haven’t found a description of this order, can you explain? Thanks. Part of the reason that the report is worded that way is that we may decide that the order should be different, but it will still be the order that you should review them in :). Right now the order is "amount of time since last change, sorted from highest to lowest". In other words, first come, first serve, by last activity.

1 0