Re: [Python-Dev] Alternative path suggestion
I've updated the wiki with a second proposal based on this thread, and also summarized the Python-dev discussions. Please make sure your favorite feature or pet peeve is adequately represented. http://wiki.python.org/moin/AlternativePathClass -- Mike Orr <[EMAIL PROTECTED]> ([EMAIL PROTECTED] address is semi-reliable) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Alternative path suggestion
On 5/4/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Mike Orr wrote:
> >> == a tuple instead of a string ==
> >>
> >> The biggest conceptual change is that my path object is a subclass of
> >> ''tuple'', not a subclass of str.
>
> Why subclass anything? The path should internally represent the filesystem
> path as a list or tuple, but it shouldn't *be* a tuple.
Good point.
> Also, was it a deliberate design decision to make the path objects immutable,
> or was that simply copied from the fact that strings are immutable?
>
> Given that immutability allows the string representation to be calculated once
> and then cached, I'll go with that interpretation.
Immutability also allows them to be dictionary keys. This is
convenient in many applications.
> Similarly, I would separate out the extension to a distinct attribute, as it
> too uses a different separator from the normal path elements ('.' most places,
> but '/' on RISC OS, for example)
That would be too surprising to users. p[-1] should be the full
filename. We can use p.name, p.extsep, and p.ext for the parts.
> Alternatively, if the path elements are stored in separate attributes, there's
> nothing stopping the main object from inheriting from str or unicode the way
> the PEP 355 path object does.
Do the string methods call .__str__(), or how do they get the string value?
> I wouldn't expose stat() - as you say, it's a Unixism. Instead, I'd provide a
> subclass of Path that used lstat instead of stat for symbolic links.
>
> So if I want symbolic links followed, I use the normal Path class. This class
> just generally treat symbolic links as if they were the file pointed to
> (except for the whole not recursing into symlinked subdirectories thing).
>
> The SymbolicPath subclass would treat normal files as usual, but *wouldn't*
> follow symbolic links when stat'ting files (instead, it would stat the
> symlink).
Normally I'd be processing the subdirectories, then the symlinks, off
the same path. I'd rather just call a different method rather than
having to construct another object.
> >> == One Method for Finding Files ==
> >>
> >> (They're actually two, but with exactly the same interface). The
> >> original path object has these methods for finding files:
> >>
> >> {{{
> >> def listdir(self, pattern = None): ...
> >> def dirs(self, pattern = None): ...
> >> def files(self, pattern = None): ...
> >> def walk(self, pattern = None): ...
> >> def walkdirs(self, pattern = None): ...
> >> def walkfiles(self, pattern = None): ...
> >> def glob(self, pattern):
> >> }}}
> >>
> >> I suggest one method that replaces all those:
> >> {{{
> >> def glob(self, pattern='*', topdown=True, onlydirs=False,
> >> onlyfiles=False): ...
> >> }}}
>
> Swiss army methods are even more evil than wide APIs.
I don't see the point in combining these either. There's the problem
of walking special files, but these are so rare and diverse that we
either have to provide methods for all of them, or an argument, or
force the user to use .walk(). Since they are rare, the latter is OK.
> Now, what might potentially be genuinely useful is paired walk methods that
> allowed the following:
>
># Do path.walk over this directory, and also return the corresponding
># information for a destination directory (so the dest dir information
># probably *won't* match that file system
>for src_info, dest_info in src_path.pairedwalk(dest_path):
>src_dirpath, src_subdirs, src_files = src_info
>dest_dirpath, dest_subdirs, dest_files = dest_info
># Do something useful
>
># Ditto for path.walkdirs
>for src_dirpath, dest_dirpath in src_path.pairedwalkdirs(dest_path):
># Do something useful
>
># Ditto for path.walkfiles
>for src_path, dest_path in src_path.pairedwalkfiles(dest_path):
>src_path.copy_to(dest_path)
These look like os.walk() derivatives. I've never found that as
useful as getting a flat iteration of paths. But if enough people
want it...
--
Mike Orr <[EMAIL PROTECTED]>
([EMAIL PROTECTED] address is semi-reliable)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Alternative path suggestion
On 5/4/06, Paul Moore <[EMAIL PROTECTED]> wrote: > On 5/4/06, Nick Coghlan <[EMAIL PROTECTED]> wrote: > > My inclination was to have a PlatformPath subclass that accepted 'os', 'sep' > > and 'extsep' keyword arguments to the constructor, and provided the > > appropriate 'sep' and 'extsep' attributes (supplying 'os' would just be a > > shortcut to avoid specifying the separators explicitly). > > > > That way the main class can avoid being complicated by the relatively rare > > need to operate on another platform's paths, while still supporting the > > ability. > > You ought to have predefined classes for the standard OSes. Expecting > people to know the values for sep and extsep seems unhelpful. > > In fact, unless you expect to support the os.path interface forever, > as well as the new interface, I'd assume there would have to be > internal WindowsPath and PosixPath classes anyway - much like the > current ntpath and posixpath modules. So keeping that structure, and > simply having > > if os.name == 'posix': > Path = PosixPath > elif os.name == 'nt': > Path = WindowsPath > ... etc > > at the end, would seem simplest. Why not just put a platform-specific Path class inside posixpath, macpath, etc. Python already chooses os.path for the actual platform, and you can import a foreign module directly if you want to. > (But all the current proposals seem to build on os.path, so maybe I > should assume otherwise, that os.path will remain indefinitely...) They build on os.path because that's what we're familiar with using. There's no reason to write the platform-specific classes until we agree on an API; that would just be work down the drain. When the new classes are in the library, we can: (one or more) - Leave os.path.foo() alone because it works and most existing programs need it. - Discourage os.path.foo() in the documentation but continue to support it. - Rewrite os.path.foo() to use Path.foo(). A lot of useless work if we... - Remove os.path.foo() in Python 3.0. -- Mike Orr <[EMAIL PROTECTED]> ([EMAIL PROTECTED] address is semi-reliable) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python sprint mechanics
Martin v. Löwis wrote: > I think Fredrik Lundh points to svk at such occasions. SVK makes it trivial to mirror a remote SVN repository, and make zillions of local light-weight branches against that repository (e.g.one branch per bug you're working on); see e.g. http://gcc.gnu.org/wiki/SvkHelp for a brief tutorial. I think you can set things up so others can work against your local repository, but I haven't done that myself. anyone here knows more about this ? (if that turns out to be hard, it's trivial to work with patch sets under SVK). ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] binary trees. Review obmalloc.c
Josiah Carlson wrote: "Vladimir 'Yu' Stepanov" <[EMAIL PROTECTED]> wrote: Comparison of functions of sorting and binary trees not absolutely correctly. I think that function sort will lose considerably on greater lists. Especially after an insert or removal of all one element. Generally speaking, people who understand at least some of Python's internals (list internals specifically), will not be *removing* entries from lists one at a time (at least not using list.pop(0) ), because that is slow. If they need to remove items one at a time from the smallest to the largest, they will usually use list.reverse(), then repeatedly list.pop(), as this is quite fast (in general). Yes. I understood it when resulted a set example. However, as I just said, people usually don't remove items from just-sorted lists, they tend to iterate over them via 'for i in list:' . Such problem arises at creation of the list of timers. And this list is in constant change: addition/removal of elements in the list. collections.deque here does not approach, as if addition in the big list is made or search of the nearest value on the average it is necessary to lead quantity of checks N/2 is made. For a binary tree the quantity of necessary checks on former is equal log2 (N). Other variant of use of binary trees: search of concurrence to ranges. Such ranges can be blocks IP of addresses. Also this kind of the dictionary can be used for a fast finding, whether the given point enters into one of pieces. These problems can be realized by means of binary search. For binary search the same lacks, as for above resulted example are characteristic: the insert and removal for lists are carried out slowly and after an insert sorting of the list is required. Except for that function of binary search is absent in standard package Python. It is possible to write its analogue on pure Python, but it will be more than twice more slowly. - Josiah As an aside, I have personally implemented trees a few times for different reasons. One of the issues I have with most tree implementations is that it is generally difficult to do things like "give me the kth smallest/largest item". Of course the standard solution is what is generally called a "partial order" or "order statistic" tree, but then you end up with yet another field in your structure. One nice thing about Red-Black trees combined with order-statistic trees, is that you can usually use the uppermost bit of the order statistics for red/black information. Of course, this is really only interesting from an "implement this in C" perspective; because if one were implementing it in Python, one may as well be really lazy and not bother implementing guaranteed balanced trees and be satisfied with randomized-balancing via Treaps. Here that I have found through Google on a line " order statistic binary tree ": http://www.cs.mcgill.ca/~cs251/OldCourses/1997/topic20/ I have understood, that similar I have already made something :). The result of the test shows on the most bad result, but is certainly worse, than a usual tree. Badly that up to the end I have not tested this realization. Percent on 90 I am assured that it is efficient. There is a question. What API should be used? Therefore as if to address to object, as to MAP to object __getitem__ will return one result. And if as to the list - another. Here the list of already existing attributes and methods: class xtree(__builtin__.object) | X-Tree. Binary tree with AVL balance mechanism. | | Methods defined here: | | __contains__(...) | x.__contains__(y) <==> y in x | | __delitem__(...) | x.__delitem__(y) <==> del x[y] | | __getitem__(...) | x.__getitem__(y) <==> x[y] | | __iter__(...) | x.__iter__() <==> iter(x) | | __len__(...) | x.__len__() <==> len(x) | | __repr__(...) | x.__repr__() <==> repr(x) | | __setitem__(...) | x.__setitem__(i, y) <==> x[i]=y | | append(...) | D.append((k: v)) -> None, append new pair element into tree with sorting. | Return pair element if argument is exist. | | clear(...) | D.clear() -> None. Remove all items from D. | | copy(...) | D.copy() -> a shallow copy of D. | | get(...) | D.get(k[,d]) -> D[k] if k in D, else d. d defaults to None. | | has_key(...) | D.has_key(k) -> True if D has a key k, else False. | | items(...) | D.items() -> list of D's (key, value) pairs. | | iteritems(...) | D.iteritems() -> an iterator over the (key, value) items of D. | | iterkeys(...) | D.iterkeys() -> an iterator over the keys of D. | | itervalues(...) | D.itervalues() -> an iterator over the values of D. | | keys(...) | D.keys() -> list of D's keys. | | pop(...)
Re: [Python-Dev] Python sprint mechanics
On 5/5/06, Tim Peters <[EMAIL PROTECTED]> wrote: > Since I hope we see a lot more of these problems in the future, what > can be done to ease the pain? I don't know enough about SVN admin to > know what might be realistic. Adding a pile of "temporary > committers" comes to mind, but wouldn't really work since people will > want to keep working on their branches after the sprint ends. Purely > local SVN setups wouldn't work either, since sprint projects will > generally have more than one worker bee, and they need to share code > changes. There: I think that's enough to prove I don't have a clue > :-) Is it possible to create a branch in the main Python svn, and grant commit privs to that branch only, for sprint participants? I seem to recall something like mod_authzsvn being involved, but I don't know much more... Paul. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Alternative path suggestion
Mike Orr wrote: > On 5/4/06, Paul Moore <[EMAIL PROTECTED]> wrote: >> (But all the current proposals seem to build on os.path, so maybe I >> should assume otherwise, that os.path will remain indefinitely...) > > They build on os.path because that's what we're familiar with using. > There's no reason to write the platform-specific classes until we > agree on an API; that would just be work down the drain. When the new > classes are in the library, we can: (one or more) > > - Leave os.path.foo() alone because it works and most existing programs need > it. The threading module doesn't really obsolete the thread module, it just provides a higher level, more convenient API. Similarly, I don't believe it's a given that a nice path object will obsolete the low level operations. When translating a shell script to Python (or vice versa), having access to the comparable low level operations would be of benefit. At most, I would expect provision of an OO path API to result in a comment in the documentation of various modules (os.path, shutil, fnmatch, glob) saying that "pathlib.Path" (or whatever it ends up being called) is generally a more convenient API. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3102: Keyword-only arguments
On 5/5/06, Terry Reedy <[EMAIL PROTECTED]> wrote:
> At present, Python allows this as a choice.
Not always - take a look from another perspective:
def make_person(**kwds):
name = kwds.pop('name', None)
age = kwds.pop('age', None)
phone = kwds.pop('phone', None)
location = kwds.pop('location', None)
...
This already requires the caller to use keywords, but results in
horrid introspection based documentation. You know it takes some
keywords, but you have no clue what keywords they are. It's as bad as
calling help() on many of the C functions in the python stdlib.
So what allowing named keyword-only arguments does for us is allows us
to document this case. That is an absolute win.
Michael
--
Michael Urman http://www.tortall.net/mu/blog
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python sprint mechanics
Paul Moore wrote: > Is it possible to create a branch in the main Python svn, and grant > commit privs to that branch only, for sprint participants? I'm not familiar with the mechanics, recent versions of Subversion allow per-directory security. We do this to give some customers read access to parts of the repo, and read-write to others. It shouldn't be difficult (given a recent enough Subversion) to set up a sprint area in the repo. -- Benji York ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3102: Keyword-only arguments
On Friday 05 May 2006 02:38, Terry Reedy wrote: > My point has been that the function writer should not make such a > requirement (for four no-defaut, required params) and that proposing to do > so with the proposed '*' is an abuse (for public code). The caller should And what exactly is the point at which constraining use goes from unreasonable to reasonable? Perhaps that involves a judgement call? I think it does. Since we're all consenting adults, we should have the tools to make our judgements easy to apply. Since it requires specific action to make the constraint (insertion of the "*" marker), there doesn't appear to be any real issue here. -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3102: Keyword-only arguments
On Fri, 5 May 2006 08:20:02 -0500, Michael Urman <[EMAIL PROTECTED]> wrote:
>On 5/5/06, Terry Reedy <[EMAIL PROTECTED]> wrote:
>> At present, Python allows this as a choice.
>
>Not always - take a look from another perspective:
>
>def make_person(**kwds):
>name = kwds.pop('name', None)
>age = kwds.pop('age', None)
>phone = kwds.pop('phone', None)
>location = kwds.pop('location', None)
>...
>
>This already requires the caller to use keywords, but results in
>horrid introspection based documentation. You know it takes some
>keywords, but you have no clue what keywords they are. It's as bad as
>calling help() on many of the C functions in the python stdlib.
>
>So what allowing named keyword-only arguments does for us is allows us
>to document this case. That is an absolute win.
Here you go:
import inspect
@decorator
def keyword(f):
def g(*a, **kw):
if a:
raise TypeError("Arguments must be passed by keyword")
args = []
expectedArgs = inspect.getargspec(f)[0]
defaults = inspect.getargspec(f)[-1]
for i, a in enumerate(expectedArgs):
if a in kw:
args.append(kw[a])
elif i >= len(expectedArgs) - len(defaults):
args.append(defaults[i - len(expectedArgs)])
else:
raise TypeError("Missing argument for " + a)
return f(*args)
return g
@keyword
def foo(a, b, c=10, d=20, e=30):
return a, b, c, d, e
try:
foo()
except TypeError:
pass
else:
assert False, "Should have raised TypeError"
try:
foo(1)
except TypeError:
pass
else:
assert False, "Should have raised TypeError"
try:
foo(a=1)
except TypeError:
pass
else:
assert False, "Should have raised TypeError"
assert foo(a=1, b=2) == (1, 2, 10, 20, 30)
assert foo(a=1, b=2, c=3) == (1, 2, 3, 20, 30)
assert foo(a=1, b=2, d=4) == (1, 2, 10, 4, 30)
assert foo(a=1, b=2, c=3, d=4, e=5) == (1, 2, 3, 4, 5)
print 'Success!'
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3102: Keyword-only arguments
Fred L. Drake, Jr. wrote: > On Friday 05 May 2006 02:38, Terry Reedy wrote: > > My point has been that the function writer should not make such a > > requirement (for four no-defaut, required params) and that proposing to do > > so with the proposed '*' is an abuse (for public code). The caller should > > And what exactly is the point at which constraining use goes from > unreasonable > to reasonable? Perhaps that involves a judgement call? I think it does. > Since we're all consenting adults, we should have the tools to make our > judgements easy to apply. > > Since it requires specific action to make the constraint (insertion of the > "*" > marker), there doesn't appear to be any real issue here. And I imagine API designers that abused the feature would end up being abused by their users :) Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3102: Keyword-only arguments
On Friday 05 May 2006 10:16, Nick Coghlan wrote: > And I imagine API designers that abused the feature would end up being > abused by their users :) If used to create poor APIs, I think that's a reasonable outcome. :-) I don't think using such a feature to constrain APIs is necessarily abuse, which is what seems to be the point of disagreement in this thread. -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python for Windows CE
- Original Message - From: ""Martin v. Löwis"" <[EMAIL PROTECTED]> To: "Luke Dunstan" <[EMAIL PROTECTED]> Cc: Sent: Thursday, May 04, 2006 5:03 AM Subject: Re: [Python-Dev] Python for Windows CE > Luke Dunstan wrote: >> 1. Is there any reason in principle why patches for Windows CE support >> would >> be rejected? > > No, not in principle. Of course, > - the patch shouldn't break anything > - you should state an explicit commitment to support the port for > some years (or else it might get removed at the slightest problem) Thanks for your response. I hope I can continue to support Python for Windows CE for a while at least. >> 4. The latest existing patch set uses os.name = "ce", and this can be >> used >> to distinguish Windows CE from other operating systems in Python code. >> The >> existing patches also set sys.platform = "Pocket PC", but I am not so >> keen >> on keeping this, mainly because Windows CE is equivalent to Win32 in many >> cases. Any comments? > > I would guide the decision based on the number of API changes you need > to make to the standard library (e.g. distutils). In any case, the > platform module should be able to reliably report the specific system > (including the specific processor architecture). OK. Actually I think distutils will be the last thing to be ported because it is not necessary for using the rest of Python. Does distutils has support for cross-compiling anyway? > >> (b) Instead we could use #ifdef HAVE_DIRECT_H, requiring patches to >> #define >> HAVE_DIRECT_H for other platforms > > That would be best. Python generally uses autoconf methodology, which > implies that conditionally-existing headers should be detected using > HAVE_*_H. > > Regards, > Martin OK, but what about ANSI C headers like signal.h? I expected HAVE_SIGNAL_H to exist already but I just came across this patch: http://svn.python.org/view/python/trunk/pyconfig.h.in?rev=35255&r1=35221&r2=35255 I am guessing that the reason for this patch was to reduce the number of #ifdefs in the Python source to ease maintenance. Would you want to add some of them back again? Luke ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] binary trees. Review obmalloc.c
"Vladimir 'Yu' Stepanov" <[EMAIL PROTECTED]> wrote:
> Josiah Carlson wrote:
> > However, as I just said, people usually don't remove items from
> > just-sorted lists, they tend to iterate over them via 'for i in list:' .
> >
> Such problem arises at creation of the list of timers.
I've never seen that particular use-case.
Please understand something. I believe that trees can be useful in some
cases. However, I don't believe that they are generally useful
enough in Python, given that we already have key,value dictionaries and
sortable lists. They become even less worthwhile in Python, given the
total ordering problem that I describe later in this message.
> Except for that function of binary search is absent in standard
> package Python.
Binary search exists in the standard library as the bisect module.
> Here that I have found through Google on a line " order statistic binary
> tree ":
>
> http://www.cs.mcgill.ca/~cs251/OldCourses/1997/topic20/
Yes, that link does describe what an 'order statistic tree' is. One
thing to note is that you can add order statistics to any tree wih one
more field on each tree node. That is, you can have your AVL or
Red-Black tree, and add order statistics to it. Allowing tree['x'] to
return the associated value for the key 'x' (the same as a dictionary),
as well as offer the ability to do tree.select(10) to get the 10th (or
11th if one counts from 0) smallest key (or key,value), or get the 'rank'
of a key with tree.rank('x').
> > Of course all of this discussion about trees in Python is fine, though
> > there is one major problem. With minimal work, one can construct 3
> > values such that ((a < b < c) and (c < a)) is true.
> >
> The same problem is inherent in the standard dictionary - dict (), only
> roots at it, it is others. For example:
This problem has nothing to do with dictionaries and hashing, it has to
do with the fact that there may not be a total ordering on the elements
of a sequence.
>>> 'b' < (0,) < u'a' < 'b'
True
>>> x = ['b', (0,), u'a']
>>> random.shuffle(x)
>>> x.sort()
>>> x
[u'a', 'b', (0,)]
>>> random.shuffle(x)
>>> x.sort()
>>> x
['b', (0,), u'a']
>>>
What effect does this have on trees? Imagine, for a moment, that your
tree looked like:
(0,)
/\
'b'u'a'
Then you added sufficient data so that your tree was rebalanced to be
something like:
u'a'
/ \
(0,) (stuff)
/
'b'
If you were searching for 'b', you would never find it, because in your
search, you would compare 'b' against u'a', and take the right branch,
where 'b' isn't.
- Josiah
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3102: Keyword-only arguments
Jean-Paul Calderone <[EMAIL PROTECTED]> wrote:
>
> On Fri, 5 May 2006 08:20:02 -0500, Michael Urman <[EMAIL PROTECTED]> wrote:
> >On 5/5/06, Terry Reedy <[EMAIL PROTECTED]> wrote:
> >> At present, Python allows this as a choice.
> >
> >Not always - take a look from another perspective:
> >
> >def make_person(**kwds):
> >name = kwds.pop('name', None)
> >age = kwds.pop('age', None)
> >phone = kwds.pop('phone', None)
> >location = kwds.pop('location', None)
> >...
> >
> >This already requires the caller to use keywords, but results in
> >horrid introspection based documentation. You know it takes some
> >keywords, but you have no clue what keywords they are. It's as bad as
> >calling help() on many of the C functions in the python stdlib.
> >
> >So what allowing named keyword-only arguments does for us is allows us
> >to document this case. That is an absolute win.
>
> Here you go:
[snip]
Nice work! So, can we add this to the functools module right next to
decorator, and bypass the syntax change?
- Josiah
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] lambda in Python
Delaney, Timothy (Tim) wrote: > Should we add an explicit rule to the Python-dev spam filter for Xah? > Based on his past history, I doubt we'll ever see anything useful from > him. > I'm not sure Xah is so much a troll as he is completely out of his mind. At any rate, it seems he never has anything coherent to contribute. I, however, dislike the idea of censoring someone just for being incoherent and obnoxious. Ignoring him is probably the most pragmatic thing to do. -- Ian D. Bollinger ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3102: Keyword-only arguments
"Michael Urman" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> On 5/5/06, Terry Reedy <[EMAIL PROTECTED]> wrote:
>> At present, Python allows this as a choice.
I made that statement in the context of comparing these syntaxes
def make_person(name, age, phone, location) # current
def make_person(*, name, age, phone, location) # possible future
for a function with required, no-default parameters. In that context, my
statement is true.
> Not always - take a look from another perspective:
As I wrote it, I was aware that it was not true in the alternate context
(not perspective) of using **names. Many true statements become otherwise
when their context is ripped away.
> def make_person(**kwds):
>name = kwds.pop('name', None)
>age = kwds.pop('age', None)
>phone = kwds.pop('phone', None)
>location = kwds.pop('location', None)
This version gives the parameters default values and make them optional.
The current version, ignoring error messages, of the possible future above
is
def make_person(**names):
name = names.pop('name')
age = names.pop('age')
phone = names.pop('phone')
location = names.pop('location')
if names: raise KeyError("Extra named args passed")
Now there are no defaults and all are required.
> This already requires the caller to use keywords,
Your version allows the seemingly senseless no-keyword call make_person().
> but results in horrid introspection based documentation.
> You know it takes some
> keywords, but you have no clue what keywords they are. It's as bad as
> calling help() on many of the C functions in the python stdlib.
Improving doc strings for C functions is a separate issue.
> So what allowing named keyword-only arguments does for us is allows us
> to document this case. That is an absolute win.
That is your opinion, whereas mine is that this generally a bad case that
should not be written and that making it easier to write and therefore more
likely is a loss.
Terry Jan Reedy
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] lambda in Python
Ian D. Bollinger wrote: > I'm not sure Xah is so much a troll as he is completely out of his > mind. Is that Bollinger's law? Any sufficiently advanced insanity is indistinguishable from trolling. -- Benji York ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3102: Keyword-only arguments
"Fred L. Drake, Jr." <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > On Friday 05 May 2006 02:38, Terry Reedy wrote: > > My point has been that the function writer should not make such a > > requirement (for four no-defaut, required params) and that proposing to > > do > > so with the proposed '*' is an abuse (for public code). The caller > > should > > And what exactly is the point at which constraining use goes from > unreasonable > to reasonable? Perhaps that involves a judgement call? I think it does. Well, if so, it is my increasingly strong judgment that requiring another programmer to junk up his or her code with make_person(name=name, age=age, phone=phone, location = location) # instead of # make_person(name, age, phone, location) # or * make_person(name=person_data[0], age=person_data[2], phone=person_data[3], location=person_data[3]) # instead # make_person(*person_data) is generally unreasonable. Remember, any person who actually prefers to write the longer forms is free to do so. > Since we're all consenting adults, That is the basis for my objection. Most of the 'reasons' given for imposing the longer forms above have been about *not* treating function-calling programmers as fellow consenting adults, or rather, about treating them as non-adults. One exception is the claim that in the alpha phase of a library project, the developer might be willing to freeze parameter names before freezing parameter positions. But this should be rare, temporary, and might be dealt with as well by the common procedure of stating that function signatures (APIs) are subject to change, while indicating which aspect are considered most stable or unstable. > we should have the tools to make our judgements easy to apply. The discussion is about a tool to make a very disputable judgment easier to impose on others > Since it requires specific action to make the constraint (insertion of > the "*" > marker), there doesn't appear to be any real issue here. I do not see the logic of this statement. I could just as well claim that it is constraints that require action, and which are therefore, in a sense, optional, that are disputable issues. Terry Jan Reedy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python sprint mechanics
Paul Moore wrote: > Is it possible to create a branch in the main Python svn, and grant > commit privs to that branch only, for sprint participants? I seem to > recall something like mod_authzsvn being involved, but I don't know > much more... We couldn't technically enforce it - but I'm sure sprint participants would restrict checkins to a branch if they were told to. However, I don't see how that would help. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python sprint mechanics
Benji York wrote: > I'm not familiar with the mechanics, recent versions of Subversion allow > per-directory security. We do this to give some customers read access > to parts of the repo, and read-write to others. It shouldn't be > difficult (given a recent enough Subversion) to set up a sprint area in > the repo. It works fine for http(s), but not for svn+ssh. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python for Windows CE
Luke Dunstan wrote: > OK. Actually I think distutils will be the last thing to be ported because > it is not necessary for using the rest of Python. Does distutils has support > for cross-compiling anyway? No, it doesn't. > OK, but what about ANSI C headers like signal.h? I expected HAVE_SIGNAL_H to > exist already but I just came across this patch: > > http://svn.python.org/view/python/trunk/pyconfig.h.in?rev=35255&r1=35221&r2=35255 > > I am guessing that the reason for this patch was to reduce the number of > #ifdefs in the Python source to ease maintenance. Would you want to add some > of them back again? Yes. with a record what system (and version) requires them, so we can remove them again when the system becomes unsupported. Regards, ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python sprint mechanics
Martin v. Löwis wrote: > Benji York wrote: > >>I'm not familiar with the mechanics, recent versions of Subversion allow >>per-directory security. > > It works fine for http(s), but not for svn+ssh. Versions prior to 1.3 could use Apache's authorization system. Subversion 1.3 added a path-based authorization feature to svnserve. -- Benji York ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3102: Keyword-only arguments
On 5/5/06, Jean-Paul Calderone <[EMAIL PROTECTED]> wrote: > @keyword > def foo(a, b, c=10, d=20, e=30): > return a, b, c, d, e Cute, indeed. That decorator implementation is not as flexible as the * which can go after positional parameters, but of course that is easy to tweak. However the part I didn't bring up as a reason to prefer explicit syntax for required-as-keyword is performance. I suspect syntactic support will be faster than **kw.pop; I'm almost certain it's faster than decorator gimmicks. I'm not certain at all that it's a concern either way. Michael -- Michael Urman http://www.tortall.net/mu/blog ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Alternative path suggestion
Noam Raphael <[EMAIL PROTECTED]> wrote: > The only drawback I can see in using a logical representation is that > giving a path object to functions which expect a path string won't > work. The immediate solution is to simply use str(p) instead of p. The > long-term solution is to make all related functions accept a path > object. I'm not an expert in this field, but I believe that if you can make your Path object support the so-called buffer interface, it would be directly usable for functions like open() without an explicit conversion. Giovanni Bajo ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Alternative path suggestion
Greg Ewing <[EMAIL PROTECTED]> wrote:
>> Similarly, I would separate out the extension to a distinct
>> attribute, as it too uses a different separator from the normal path
>> elements ('.' most places, but '/' on RISC OS, for example)
>
> -1. What constitutes "the extension" is not well-defined in
> all cases. What about filenames with multiple suffixes,
> such as "spam.tar.gz"? What part of that would you put in
> the extension attribute?
.gz of course:
Path = "foo.tar.gz"
Path.ext = ".gz"
Path.name.ext = ".tar"
Path.name.name.ext = ""
Which is exactly the *same* thing that os.path.splitext() does. And yes, I do
use splitext quite a lot.
Giovanni Bajo
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] A critic of Guido's blog on Python's lambda
In this post, i'd like to deconstruct one of Guido's recent blog about lambda in Python. In Guido's blog written in 2006-02-10 at http://www.artima.com/ weblogs/viewpost.jsp?thread=147358 is first of all, the title “Language Design Is Not Just Solving Puzzles”. In the outset, and in between the lines, we are told that “I'm the supreme intellect, and I created Python”. This seems impressive, except that the tech geekers due to their ignorance of sociology as well as lack of analytic abilities of the mathematician, do not know that creating a language is a act that requires little qualifications. However, creating a language that is used by a lot people takes considerable skill, and a big part of that skill is salesmanship. Guido seems to have done it well and seems to continue selling it well, where, he can put up a title of belittlement and get away with it too. Gaudy title aside, let's look at the content of his say. If you peruse the 700 words, you'll find that it amounts to that Guido does not like the suggested lambda fix due to its multi-line nature, and says that he don't think there could possibly be any proposal he'll like. The reason? Not much! Zen is bantered about, mathematician's impractical ways is waved, undefinable qualities are given, human's right brain (neuroscience) is mentioned for support, Rube Goldberg contrivance phraseology is thrown, and coolness of Google Inc is reminded for the tech geekers (in juxtaposition of a big notice that Guido works there.). If you are serious, doesn't this writing sounds bigger than its content? Look at the gorgeous ending: “This is also the reason why Python will never have continuations, and even why I'm uninterested in optimizing tail recursion. But that's for another installment.”. This benevolent geeker is gonna give us another INSTALLMENT! There is a computer language leader by the name of Larry Wall, who said that “The three chief virtues of a programmer are: Laziness, Impatience and Hubris” among quite a lot of other ingenious outpourings. It seems to me, the more i learn about Python and its leader, the more similarities i see. So Guido, i understand that selling oneself is a inherent and necessary part of being a human animal. But i think the lesser beings should be educated enough to know that fact. So that when minions follow a leader, they have a clear understanding of why and what. Regarding the lambda in Python situation... conceivably you are right that Python lambda is perhaps at best left as it is crippled, or even eliminated. However, this is what i want: I want Python literatures, and also in Wikipedia, to cease and desist stating that Python supports functional programing. (this is not necessarily a bad publicity) And, I want the Perl literatures to cease and desist saying they support OOP. But that's for another installment. This post is archived at: http://xahlee.org/UnixResource_dir/writ/python_lambda_guido.html Xah [EMAIL PROTECTED] ∑ http://xahlee.org/ ☄ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Weekly Python Patch/Bug Summary
Patch / Bug Summary
___
Patches : 378 open ( +0) / 3216 closed (+17) / 3594 total (+17)
Bugs: 894 open ( -7) / 5811 closed (+19) / 6705 total (+12)
RFE : 216 open ( +2) / 215 closed ( +1) / 431 total ( +3)
New / Reopened Patches
__
Rename functional to functools (2006-04-29)
http://python.org/sf/1478788 opened by Collin Winter
Take advantage of BaseException/Exception split in cookielib (2006-04-29)
http://python.org/sf/1478993 opened by John J Lee
Split open() and file() (2006-04-29)
CLOSED http://python.org/sf/1479181 opened by Aahz
ColorDelegator - Several bug fixes (2006-04-30)
http://python.org/sf/1479219 opened by Tal Einat
Fix building with SWIG's -c++ option set in setup.py (2006-04-30)
http://python.org/sf/1479255 opened by dOb
Make urllib2 digest auth and basic auth play together (2006-04-30)
http://python.org/sf/1479302 opened by John J Lee
with statement context managers - with should be keyword (2006-04-30)
CLOSED http://python.org/sf/1479438 opened by Matt Fleming
speed up function calls (2006-04-30)
http://python.org/sf/1479611 opened by Neal Norwitz
Heavy revisions to urllib2 howto (2006-05-01)
http://python.org/sf/1479977 opened by John J Lee
weakref dict methods (2006-05-01)
CLOSED http://python.org/sf/1479988 opened by Fred L. Drake, Jr.
urllib2 digest auth redirection bug causes 400 error (2006-05-01)
CLOSED http://python.org/sf/1480067 opened by John J Lee
patch smtplib:when SMTPDataError, rset crashes with sslerror (2006-05-03)
http://python.org/sf/1481032 opened by kxroberto
Support HTTP_REFERER in CGIHTTPServer.py (2006-05-03)
http://python.org/sf/1481079 opened by Sébastien Martini
Python long option support (2006-05-03)
http://python.org/sf/1481112 opened by Heiko Wundram
Cleaned up 16x16px icons for windows. (2006-05-03)
http://python.org/sf/1481304 opened by goxe
imputil "from" os.path import bug (2006-05-03)
CLOSED http://python.org/sf/1481530 opened by Eric Huss
Patches Closed
__
--enable-universalsdk on Mac OS X (2006-04-17)
http://python.org/sf/1471883 closed by ronaldoussoren
Split open() and file() (2006-04-29)
http://python.org/sf/1479181 closed by nnorwitz
urllib2 ProxyBasicAuthHandler broken (2006-04-15)
http://python.org/sf/1470846 closed by gbrandl
Forbid iteration over strings (2006-04-16)
http://python.org/sf/1471291 closed by gbrandl
Fix for urllib/urllib2 ftp bugs 1357260 and 1281692 (2006-04-15)
http://python.org/sf/1470976 closed by gbrandl
cPickle produces locale-dependent dumps (2006-04-20)
http://python.org/sf/1473625 closed by gbrandl
IndentationError for unexpected indent (2006-04-25)
http://python.org/sf/1475845 closed by loewis
rlcompleter to be usable without readline (2006-04-19)
http://python.org/sf/1472854 closed by gbrandl
fix for #1472251 (2006-04-18)
http://python.org/sf/1472263 closed by gbrandl
with statement context managers - with should be keyword (2006-04-30)
http://python.org/sf/1479438 closed by gbrandl
fixed handling of nested comments in mail addresses (2006-04-05)
http://python.org/sf/1464708 closed by bwarsaw
weakref dict methods (2006-05-01)
http://python.org/sf/1479988 closed by fdrake
urllib2 digest auth redirection bug causes 400 error (2006-05-01)
http://python.org/sf/1480067 closed by gbrandl
Fix to allow urllib2 digest auth to talk to livejournal.com (2005-02-18)
http://python.org/sf/1143695 closed by gbrandl
pdb: fix for #1472191('clear' command bug) (2006-04-18)
http://python.org/sf/1472184 closed by gbrandl
__init__.py'less package import warnings (2006-04-26)
http://python.org/sf/1477281 closed by gbrandl
imputil "from" os.path import bug (2006-05-04)
http://python.org/sf/1481530 closed by gbrandl
New / Reopened Bugs
___
urllib2.Request constructor to urllib.quote the url given (2006-04-20)
CLOSED http://python.org/sf/1473560 reopened by gbrandl
'compile' built-in function failures when missing EOL (2006-04-30)
http://python.org/sf/1479099 opened by Ori Peleg
test_inspect fails on WinXP (2.5a2) (2006-04-30)
CLOSED http://python.org/sf/1479226 opened by Miki Tebeka
Segmentation fault while using Tkinter (2006-05-01)
http://python.org/sf/1479586 opened by Ali Gholami Rudi
Uninstall does not clearn registry (2006-05-01)
http://python.org/sf/1479626 opened by Miki Tebeka
float->str rounding bug (2006-05-01)
CLOSED http://python.org/sf/1479776 opened by Michael Nolta
Quitter object masked (2006-05-01)
http://python.org/sf/1479785 opened by Jim Jewett
mmap tries to truncate special files (2006-05-02)
CLOSED http://python.org/sf/1480678 opened by Carl Banks
long(f
Re: [Python-Dev] Python sprint mechanics
Benji York wrote: >>> I'm not familiar with the mechanics, recent versions of Subversion >>> allow per-directory security. >> >> It works fine for http(s), but not for svn+ssh. > > Versions prior to 1.3 could use Apache's authorization system. How would that work? Apache is not involved at all. > Subversion 1.3 added a path-based authorization feature to svnserve. That's what I mean by "does not work fine": I would need to update to subversion 1.3. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] binary trees. Review obmalloc.c
Vladimir 'Yu' Stepanov wrote: > Yes. I understood it when resulted a set example. >> However, as I just said, people usually don't remove items from >> just-sorted lists, they tend to iterate over them via 'for i in list:' . >> > Such problem arises at creation of the list of timers. For a list of timers/timeout events, a priority queue is often the best data structure, which is already available through the heapq module. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Alternative path suggestion
On 5/5/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Mike Orr wrote:
> > On 5/4/06, Paul Moore <[EMAIL PROTECTED]> wrote:
> >> (But all the current proposals seem to build on os.path, so maybe I
> >> should assume otherwise, that os.path will remain indefinitely...)
> >
> > They build on os.path because that's what we're familiar with using.
> > There's no reason to write the platform-specific classes until we
> > agree on an API; that would just be work down the drain. When the new
> > classes are in the library, we can: (one or more)
> >
> > - Leave os.path.foo() alone because it works and most existing programs
> > need it.
>
> The threading module doesn't really obsolete the thread module, it just
> provides a higher level, more convenient API.
>
> Similarly, I don't believe it's a given that a nice path object will obsolete
> the low level operations. When translating a shell script to Python (or vice
> versa), having access to the comparable low level operations would be of
> benefit.
I think you meant to say Perl in that sentence. In Python there
should be one way to do it, and beautiful is better than ugly. The
os.path functions are bad enough, but shutil.copy2 is just plain evil.
Is it that much of a step to translate:
Y="$(dirname $(dirname $X))/lib"
as
y = Path(x).parent.parent + "lib"
y = Path(x).parent.parent.join("lib")
or whatever the syntax do jour is
rather than
y = os.path.join(os.path.dirname(os.path.dirname(x)), "lib")
?
--
Mike Orr <[EMAIL PROTECTED]>
([EMAIL PROTECTED] address is semi-reliable)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Alternative path suggestion
[Nick]
>>> Similarly, I would separate out the extension to a distinct
>>> attribute, as it too uses a different separator from the normal path
>>> elements ('.' most places, but '/' on RISC OS, for example)
[Greg]
>> -1. What constitutes "the extension" is not well-defined in
>> all cases. What about filenames with multiple suffixes,
>> such as "spam.tar.gz"? What part of that would you put in
>> the extension attribute?
[Giovanni]
> .gz of course:
>
> Path = "foo.tar.gz"
> Path.ext = ".gz"
> Path.name.ext = ".tar"
> Path.name.name.ext = ""
>
> Which is exactly the *same* thing that os.path.splitext() does. And yes, I do
> use splitext quite a lot.
Remember, the idea with portable path information is to *never* store os.sep
and os.extsep anywhere in the internal data - those should only be added when
needed to produce strings to pass to OS-specific functions or to display to
users.
So I suggest splitting the internal data into 'path elements separated by
os.sep', 'name elements separated by os.extsep' and 'the base path' (which can
be any kind of object that supports __str__, including another path object).
This leads to the following:
import pathlib
from pathlib import Path, PosixPath, WindowsPath, HOMEDIR
pth = Path("~/foo/bar/baz.tar.gz"):
assert pth.basepath == HOMEDIR
assert pth.dirparts == ('foo', 'bar')
assert pth.nameparts == ('baz', 'tar', 'gz')
I would also provide an alternate constructor "from_parts" which looked like:
pth = Path.from_parts(HOMEDIR, ('foo', 'bar'), ('baz', 'tar', 'gz'))
Now consider PosixPath and WindowsPath subclasses:
psx = PosixPath(pth)
win = WindowsPath(pth)
(platform specific Path variants would still accept posix-formatted path
strings & other Path variants as inputs in addition to path strings formatted
for the current platform)
# Formatting of the prefix is platform dependent
assert pth.prefix == str(pth.basepath)
assert psx.prefix == "/home/nick/"
assert win.prefix == r"C:\Documents and Settings\Nick\"
# Formatting of the directory path is platform dependent
assert pth.dir == os.sep.join(pth.dirparts + ('',))
assert psx.dir == "foo/bar/"
assert win.dir == r"foo\bar\"
# Formatting of the file name is the same on both platforms
assert pth.name == os.extsep.join(pth.nameparts)
assert psx.name == "baz.tar.gz"
assert win.name == "baz.tar.gz"
# The full path name will then also be platform dependent
assert str(pth) == pth.prefix + pth.dir + pth.name
assert str(psx) == "/home/nick/foo/bar/baz.tar.gz"
assert str(win) == r"C:\Documents and Settings\Nick\foo\bar\baz.tar.gz"
The separation of the directory parts and the name parts also allows the
difference between "/foo/bar/" and "foo/bar" to be represented properly:
pth1 = PosixPath("/foo/bar/")
assert pth1.prefix = '/'
assert pth1.dir == "foo/bar/"
assert pth1.name == ""
assert str(pth1) == "/foo/bar/"
pth2 = PosixPath("/foo/bar")
assert pth2.prefix = '/'
assert pth2.dir == "foo/"
assert pth2.name == "bar"
assert str(pth2) == "/foo/bar"
Operations such as pth.walk() would then return path objects where basepath
was set to the original path object, and only the relative path was included
in "dirparts".
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://www.boredomandlaziness.org
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
