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...
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?
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
I'm not going to push for this, but someone other than me may find such
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] =
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 ".."
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
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
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)
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)
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:
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).
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. :(
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
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:
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:
< argv=None, testRunner=None, testLoader=defaultTestLoader):
> argv=sys.argv[1:], testRunner=None, testLoader=defaultTestLoader):
< if argv is None:
< argv = sys.argv
< self.progName = os.path.basename(argv)
> # self.progName = os.path.basename(argv)
< 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 ;)
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 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. 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, which is already a common requirement for main
program functions in Python.
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:
_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.