shop soon with fixed tests.
--
Mike Orr <[EMAIL PROTECTED]>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
On 1/28/07, Mike Orr <[EMAIL PROTECTED]> wrote:
> > Passing an absolute foreign path is an error, because there's no sane way
> > to interpret "C:\\" on Posix or "/" on Windows.
> > There is in fact a very sane way to interpret "/" on Wi
special attribute.
Accommodating either would require changing the entire model to
accommodate an obscure Windows-only feature, even though the model
works quite well otherwise.
It may be that Unipath just isn't suitable for manipulating Windows
drive-relative paths, and
On 1/28/07, Steven Bethard <[EMAIL PROTECTED]> wrote:
> On 1/28/07, Michael Foord <[EMAIL PROTECTED]> wrote:
> > Mike Orr wrote:
> > > I finally finished my path package (Unipath) and put it in the Cheeseshop.
> > > http://sluggo.scrapping.cc/python/unipath
e Path
methods need more testing and use in the real world before they'd be
ready for the stdlib. The FSPath methods are more experimental so I'd
say they need a year of use before they can be considered sufficiently
stable.
--
Mike Orr <[EMAIL PROTECTED]>
_
arts.
They silently succeed if the operation is already done, and have
arguments to smartly create/delete intermediate directories, etc.
- Two extra functions are in 'unipath.tools'. 'dict2dir' creates a
directory hierarchy modeled after a dict. 'dump_path' displays an
ASCII
or at least localize the problem to
ONE place (the string constructor) where it'll be in every
programmer's face and they'll all hopefully learn to handle it
consistently and not pass bad strings to other packages.
Getting rid of old-style classes would be nice too.
--
Mike Orr <
rl 5 handle the situation? I basically waited
2-3 years after Perl 5 came out, then started programming the new way.
If it mattered (it didn't), I would have tied my applications
specifically to Perl 4.
--
Mike Orr <[EMAIL PROTECTED]>
___
Pyt
This may be a bit too FAQ-ish for some people but I'll post it in case
anybody benefits from the answer.
On 11/30/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 02:46 PM 11/30/2006 -0800, Mike Orr wrote:
> >Speaking of Virtual Python [1], I've heard some people recomm
t/virtual-python.py
(It installs a pseudo copy of Python symlinked to the system one,
so that you have your own site--packages directory independent of others )
--
Mike Orr <[EMAIL PROTECTED]>
___
Python-Dev mailing list
Python-Dev@python.org
http://
s can still break the OS if the system itself installs
> incompatible versions of such packages into its site-packages.
One wishes distro vendors would install a separate copy of Python for
their internal OS stuff so that broken-library or version issues
wouldn't affect the system. That wo
(unfinished) material I've been
working on anyway that relates to his vision. When I get some other
projects cleared away I'd like to put together that TOC of links I
mentioned and perhaps collaborate on a Guide with whoever wants to.
But I also need to learn more about setuptools before
lti-tool or are outside the scope of
setuptools; some span both the Peak docs and the Python docs. People
need an answer that starts with their question, rather than an answer
that's a section in a manual describing a particular tool.
--
Mike Orr <[EMAIL PROTECTED]>
___
ers are
appearing who are unfamiliar with the "distutils-only" approach. So
requests like Talin's will become more frequent.
It's such a big job and Python 2.6 is slated as "minimal features"
release, so it may be better to target this for Python 3 and backport
it
ile = FileAccess( Path(file_access_obj,path, "my_file") )
Working on my Path implementation. (Yes it's necessary, Glyph, at
least to me.) It's going slow because I just got a Macintosh laptop
and am still rounding up packages to install.
--
Mike Orr <[EMAIL PROTECTED]&g
ng why.)This
could theoretically go either way, doing either the same thing as
os.path.join, getting a little smarter, or doing "safe" joins by
disallowing "/" embedded in string arguments.
I would say that a directory-tuple Path object with these features
could be mainta
'm tempted to say Path("/a/b").join("c", "d") should do the same
thing your .child method does, but allow multiple levels in one step.
But on the other hand, there will always be people with prebuilt
"path/fragments" to join to other fragments, an
been
trying to spread the word about it. For whatever reason, I haven't
heard about it till now. Not sure what this means.
But what I meant is, we OO proponents have been trying to promote
path.py and/or get a similar module into the stdlib for years, and all
we got was... not even hostility.
is configured differently than you thought it was, or the
string contains Windows curly quotes et al which are undefined in
Latin-1.)
> * the documentation really can't emphasize enough how bad using
> 'os.path.exists/isfile/isdir', and then assuming the file continues to exis
It does mean moving a lot of
functions that may be moved again at some point in the future.
If we do move shutil functions into os, I'd at least like to make some
tiny improvements in them. Adding four lines to the beginning of
rmtree would make it behave like my purge() function without
detr
.
I agree that supporting non-filesystem directories (zip files,
CSV/Subversion sandboxes, URLs) would be nice, but we already have a
big enough project without that. What constraints should a Path
object keep in mind in order to be forward-compatible with this?
If anyone has design ideas/conce
f keyword-only arguments, for the reasons
Terry Reedy has mentioned.)
--
Mike Orr <[EMAIL PROTECTED]>
([EMAIL PROTECTED] address is semi-reliable)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsub
entities will be significantly
> different. A common parent Path object may still make sense if there's
> sufficient overlap, though (e.g. retrieving status related information).
Very interesting. The user knows whether he wants a file or
directory, so why not force him to specify?
Path("/a/b")
If the directory components are on an attribute
p.path[:-1] # ("a", "b")
How do you do slicing and joining? If Path subclasses object, it
could be done there like in the first example. But if Path subclasses
string, that API is taken:
p[:-1]
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 indefin
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 document
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.
&g
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]>
([EMAI
.unlink() is cryptic to non-Unix users. Although
I'd argue that .delete() is more universally understood than either.
> I removed expand. There's no need to use normpath, so it's equivalent
> to .expanduser().expandvars(), and I think that the explicit form is
&g
king 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
uld 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 <[EMAIL PROTECTED]>
([EMAIL PROTECTED] address is semi-reliable)
_
31 matches
Mail list logo
