Mailman 3 May 2006 - Python-Dev

Assigning "Group" on SF tracker?
by John J Lee 02 May '06

02 May '06

When opening patches on the SF tracker for bugs that affect Python 2.5, but may be candidates for backporting (to 2.4 ATM), should I leave "Group" as "None", or set it to "Python 2.5" to indicate it affects 2.5? If it's known to be a candidate for backporting, should I set it to "Python 2.4" to indicate that? I'm guessing I should always select "Python 2.5" if it affects 2.5, but I've been using "None" up till now, I think... John

2 1

more pyref: comparison precedence
by Fredrik Lundh 01 May '06

01 May '06

one last one for tonight; the operator precedence summary says that "in" and "not in" has lower precedence than "is" and "is not", which has lower precedence than "<, <=, >, >=, <>, !=, ==": http://docs.python.org/ref/summary.html but the comparisions chapter http://docs.python.org/ref/comparisons.html says that they all have the same priority. which one is right ? </F>

2 2

Crazy idea for str.join
by Josiah Carlson 01 May '06

01 May '06

I understand the underlying implementation of str.join can be a bit convoluted (with the auto-promotion to unicode and all), but I don't suppose there is any chance to get str.join to support objects which implement the buffer interface as one of the items in the sequence? Something like: y = 'hello world' buf1 = buffer(y, 0, 5) buf2 = buffer(y, 6) print ''.join([buf1, buf2]) should print "helloworld" It would take a PyBuffer_Check() just after the PyUnicode_Check() block. And one may be able to replace the other PyString_* calls with PyObject_AsCharBuffer() calls. I'm not going to push for this, but someone other than me may find such functionality useful. - Josiah P.S. One interesting thing to note is that quite a few underlying objects take buffer objects in lieu of strings, even when they aren't documented as doing so; file.write(), array.fromstring(), mmap[i:j] = buffer, etc.

7 25

Path.ancestor()
by Mike Orr 01 May '06

01 May '06

This is a potentially long discussion so I'm putting it in a separate thread. When finding one file relative to another, it's difficult to read multiple ".parent" attributes stacked together. Worse, if you have the wrong number, you end up at the wrong directory level, potentially causing destructive damage. Doubly worse, the number of ".parent" is non-intuitive for those used to the near-universal "." and ".." conventions. Say I'm in apps/myapp/bin/myprogram.py and want to add apps/myapp/lib and apps/shared/lib to sys.path in a portable way. app_root = Path(__file__).realpath().abspath().parent.parent assert app_root.parent.name == 'apps' sys.path.insert(0, app_root.parent / 'shared/lib') sys.path.insert(0, app_root / 'lib') Yikes! At least it's better than: lib = os.path.join(os.path.dirname(os.path.dirname(x)), "lib") which is completely unreadable. (Silence to those who say __path__ is obsolete now that setuptools has a function for finding a file in an egg. (1) I don't understand that part of the setuptools docs. (2) It will be many months before most Python programmers are ready to switch to it.) The tricky thing with "." and ".." is they have a different meaning depending on whether the original path is a file or directory. With a directory there's one less ".parent". I've played a bit with the argument and come up with this: # N is number of ".."; None (default arg) is special case for ".". .ancestor() => "." => p.parent or d .ancestor(0) => ValueError .ancestor(1) => ".." => p.parent.parent or d.parent .ancestor(2) => "../.." => p.parent.parent.parent or d.parent.parent The simplest alternative is making N the number of ".parent". This has some merit, and would solve the original problem of too many ".parent" stacking up. But it means Path wouldn't have any equivalent to "." and ".." behavior. Another alternative is to make .ancestor(0) mean ".". I don't like this because "." is a special case, and this should be shown in the syntax. Another alternative is to move every number down by 1, so .ancestor(0) is equivalent to "..". The tidiness of this is outweighed by the difficulty of remembering that N is not the number of "..". -- Mike Orr <sluggoster(a)gmail.com> (mso(a)oz.net address is semi-reliable)

1 0

More Path comments (PEP 355)
by Mike Orr 01 May '06

01 May '06

I just read over the changes to the proposed Path class since the discussion last summer. A big thanks to Bjorn Lindqvist for writing a PEP, Jason Orendorff for the original path.py and his suggestions on how the Path class should be different, and the writers of the Python-Dev Summary for bringing the discussion to my attention. I've been testing/using the interim Path class in the Python subversion (/sandbox/trunk/path, last modified in September), and have a few comments about PEP 355: - .walk*() return a list rather than an iterator. Was this an intentional change or a typo? Most typical uses yield thousands of paths which do not need to be in memory simultaneously. - An equivalent to os.listdir() is frequently useful in applications. This would return a list of filenames (strings) without the parent info. Path.listdir() calls os.listdir() and wraps all the items into Paths, and then I have to unwrap them again, which seems like a waste. I end up calling os.listdir(my_path) instead. If we decide not to subsume many os.* functions into Path, that's fine, but if we deprecate os.listdir(), it's not. - -1 on removing .joinpath(), whatever it's called. Path(basepath, *args) is good but not the same. (1) it's less intuitive: I expect this to be a method on a directory. (2) the class name is hardcoded: do I really have to do self.__class__(self, *args) to make my code forward compatible with whatever nifty subclasses might appear? - +1 on renaming .directory back to .parent. - -1 on losing a 1-liner to read/iterate a file's contents. This is a frequent operation, and having to write a 2-liner or a custom function is a pain. - +1 on consolidating mkdir/makedirs and rmdir/rmdirs. I'd also suggest not raising an error if the operation is already done, and a .purge() method that deletes recursively no matter what it is. This was suggested last summer as a rename for my .delete_dammit() proposal. Unsure what to do if permission errors prevent the operation; I guess propagating the exception is best. This would make .rmtree() redundant, which chokes if the item is a file. - +1 for rationalizing .copy*(). - +1 for .chdir(). This is a frequent operation, and it makes no sense not to include it. -- Mike Orr <sluggoster(a)gmail.com> (mso(a)oz.net address is semi-reliable)

1 0

introducing the experimental pyref wiki
by Fredrik Lundh 01 May '06

01 May '06

the pytut wiki (http://pytut.infogami.com/) has now been up and running for one month, and has seen well over 250 edits from over a dozen contributors. to celebrate this, and to exercise the toolchain that I've deve- loped for pytut and pyfaq (http://pyfaq.infogami.com/), I spent a few hours putting together a hyperlinked mashup of the language reference and portions of the library reference: http://pyref.infogami.com/ a couple of notes: - all important "concepts" have unique URLs: this includes key- words, types, special methods and attributes, statements, builtin functions, and exceptions. - the conversion and structure is a bit rough; especially the syntax/data model/execution model parts needs some serious refactoring. the "concept pages" are in a lot better shape. - registered users can add comments to all pages (editing is currently "by invitation only"; mail me your infogami account if you want to help!) - the documentation style used at the pyref site is tuned for authoring; an "end-user rendering" for python.org can look a lot different. (all three sites can be made available in glorious XHTML for inclusion in arbitrary toolchains). enjoy! </F>

6 8

Re: [Python-Dev] introducing the experimental pyref wiki
by Phillip J. Eby 01 May '06

01 May '06

At 11:37 AM 5/1/2006 -0700, Guido van Rossum wrote: >Agreed. Is it too late to also attempt to bring Doc/ref/*.tex >completely up to date and remove confusing language from it? Ideally >that's the authoritative Language Reference -- admittedly it's been >horribly out of date but needn't stay so forever. Well, I added stuff for PEP 343, but PEP 342 (yield expression plus generator-iterator methods) hasn't really been added yet, mostly because I was unsure of how to fit it in without one of those "first let's explain it how it was, then how we changed it" sort of things. :(

1 0

unittest argv
by John Keyes 01 May '06

01 May '06

Hi, main() in unittest has an optional parameter called argv. If it is not present in the invocation, it defaults to None. Later in the function a check is made to see if argv is None and if so sets it to sys.argv. I think the default should be changed to sys.argv[1:] (i.e. the command line arguments minus the name of the python file being executed). The parseArgs() function then uses getopt to parse argv. It currently ignores the first item in the argv list, but this causes a problem when it is called from another python function and not from the command line. So using the current code if I call: python mytest.py -v then argv in parseArgs is ['mytest.py', '-v'] But, if I call: unittest.main(module=None, argv=['-v','mytest']) then argv in parseArgs is ['mytest'], as you can see the verbosity option is now gone and cannot be used. Here's a diff to show the code changes I have made: 744c744 < argv=None, testRunner=None, testLoader=defaultTestLoader): --- > argv=sys.argv[1:], testRunner=None, testLoader=defaultTestLoader): 751,752d750 < if argv is None: < argv = sys.argv 757c755 < self.progName = os.path.basename(argv[0]) --- > # self.progName = os.path.basename(argv[0]) 769c767 < options, args = getopt.getopt(argv[1:], 'hHvq', --- > options, args = getopt.getopt(argv, 'hHvq', You may notice I have commented out the self.progName line. This variable is not used anywhere in the module so I guess it could be removed. To keep it then conditional check on argv would have to remain and be moved after the self.progName line. I hope this makes sense, and it's my first post so go easy on me ;) Thanks, -John K

2 5

Re: [Python-Dev] unittest argv
by Phillip J. Eby 01 May '06

01 May '06

At 06:11 PM 5/1/2006 +0100, John Keyes wrote: >On 5/1/06, Guido van Rossum <guido(a)python.org> wrote: > > Wouldn't this be an incompatible change? That would make it a no-no. > > Providing a dummy argv[0] isn't so hard is it? > >It would be incompatible with existing code, but that code is >already broken (IMO) by passing a dummy argv[0]. I don't >think fixing it would affect much code, because normally >people don't specify the '-q' or '-v' in code, it is almost >exclusively used on the command line. Speak for yourself - I have at least two tools that would have to change for this, at least one of which would have to grow version testing code, since it's distributed for Python 2.3 and up. That's far more wasteful than providing an argv[0], which is already a common requirement for main program functions in Python.

1 0

__getslice__ usage in sre_parse
by Sanghyeon Seo 01 May '06

01 May '06

Hello, Python language reference 3.3.6 deprecates __getslice__. I think it's okay that UserList.py has it, but sre_parse shouldn't use it, no? __getslice__ is not implemented in IronPython and this breaks usage of _sre.py, a pure-Python implementation of _sre, on IronPython: http://ubique.ch/code/_sre/ _sre.py is needed for me because IronPython's own regex implementation using underlying .NET implementation is not compatible enough for my applications. I will write a separate bug report for this. It should be a matter of removing __getslice__ and adding isinstance(index, slice) check in __getitem__. I would very much appreciate it if this is fixed before Python 2.5. Seo Sanghyeon

3 2