Russell Finn wrote:
>Well, no; see below.
>
>> join('d1', 'Users')
>> ':d1:Users' # wrong! (should be 'd1:Users')
>
>The docstring for macpath.isabs() contradicts this, however:
>
>"""On the Mac, relative paths begin with a colon,
>but as a special case, paths with no colons at all are als
On 20-apr-2006, at 19:49, Russell Finn wrote:
>
>> More examples of brokenness:
>>
>> exists('d1:Users:has')
>> False
>> exists('/Users/has')
>> True
>
> [snip]
>
> If d1 is the name of your system volume, then that would be a bug --
> if you were explicitly calling macpath.exists() in the first c
On 4/20/06, has <[EMAIL PROTECTED]> wrote:
> > >>> macpath.join('foo', 'bar')
> >':foo:bar'
>
> That said, the actual result in the above example is wrong. It should be
> 'foo:bar', since 'foo' is an absolute path (a leading colon indicates a
> relative path, which is not the same):
Well, no; se
On 20-apr-2006, at 11:02, has wrote:
> Ronald wrote:
>
Macpath deals with OS9/Carbon style paths (Volume:directory:file
instead of /Volume/directory/file).
>>>
>>> Don't know where you're seeing this; I've tried a few of the
>>> functions and none work with HFS-style paths, only POSIX
On 20-apr-2006, at 11:50, has wrote:
> Ronald Oussoren wrote:
>
2.1 macpath -- MacOS path manipulation functions
>>>
>>> Deprecate. Also note that the 2.4.3 documentation now says "It
>>> can be used to manipulate old-style Macintosh pathnames on Mac OS
>>> X (or any other platform
Ronald wrote:
>>>Macpath deals with OS9/Carbon style paths (Volume:directory:file
>>>instead of /Volume/directory/file).
>>
>>Don't know where you're seeing this; I've tried a few of the functions and
>>none work with HFS-style paths, only POSIX-style paths.
>
> >>> macpath.join('foo', 'bar')
>
Ronald Oussoren wrote:
>>> 2.1 macpath -- MacOS path manipulation functions
>>
>>Deprecate. Also note that the 2.4.3 documentation now says "It can be used to
>>manipulate old-style Macintosh pathnames on Mac OS X (or any other
>>platform)." which is incorrect (it uses POSIX-style paths),
Well, I was planning on fixing the documentation, but apparently the
process requires a level of bureaucracy I'm just not willing to go
through (though I can see why it might be necessary). I can't just
check out the TeX sources and fix them, then check them back in.
Instead, I apparently have to
On 19-apr-2006, at 22:23, has wrote:
> Ronald wrote:
>
>> Macpath deals with OS9/Carbon style paths (Volume:directory:file
>> instead of /Volume/directory/file).
>
> Don't know where you're seeing this; I've tried a few of the
> functions and none work with HFS-style paths, only POSIX-style
Ronald> I don't know who will do it, I do know that we won't get very
Ronald> far by just talking about it ;-). Pick some part that you
Ronald> consider broken and propose how this can be fixed. I do want to
Ronald> fix as many bugs as possible for python 2.5, but that won't
Ro
On 19-apr-2006, at 22:13, Bill Janssen wrote:
>>
>> On 19-apr-2006, at 18:14, Bill Janssen wrote:
>>
>>> Thanks, Has.
>>>
>>> I was hoping someone would go through that list bit-by-bit.
>>>
>>> I'm still in favor of simply removing outdated and dangerous
>>> docs, but
>>> perhaps there's some e
On 19-apr-2006, at 22:11, Kevin Walzer wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Ronald Oussoren wrote:
>
>>>
4.2 Carbon.AH -- Apple Help
>>> Do nothing.
>>
>> Documentation would be nice :-)
>>
>>>
>
> I might be able to help here. I've actually used this module in
Ronald wrote:
>Macpath deals with OS9/Carbon style paths (Volume:directory:file instead of
>/Volume/directory/file).
Don't know where you're seeing this; I've tried a few of the functions and none
work with HFS-style paths, only POSIX-style paths. The documentation describes
it as an OS9 impl
>
> On 19-apr-2006, at 18:14, Bill Janssen wrote:
>
> > Thanks, Has.
> >
> > I was hoping someone would go through that list bit-by-bit.
> >
> > I'm still in favor of simply removing outdated and dangerous docs, but
> > perhaps there's some effective way of thoroughly marking them as bad,
> > ins
On Apr 19, 2006, at 12:52, Ronald Oussoren wrote: 2.1 macpath -- MacOS path manipulation functions Deprecate. Also note that the 2.4.3 documentation now says "It can be used to manipulate old-style Macintosh pathnames on Mac OS X (or any other platform)." which is incorrect (it uses POSI
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ronald Oussoren wrote:
>>
>>>4.2 Carbon.AH -- Apple Help
>> Do nothing.
>
> Documentation would be nice :-)
>
>>
I might be able to help here. I've actually used this module in
non-Python apps (I used to use in Tcl/Tk apps by exec'ing 'pyth
On 19-apr-2006, at 18:14, Bill Janssen wrote:
> Thanks, Has.
>
> I was hoping someone would go through that list bit-by-bit.
>
> I'm still in favor of simply removing outdated and dangerous docs, but
> perhaps there's some effective way of thoroughly marking them as bad,
> instead.
I'm in favour
On 19-apr-2006, at 15:38, has wrote:
>
>
>>2.1 macpath -- MacOS path manipulation functions
>
> Deprecate. Also note that the 2.4.3 documentation now says "It can
> be used to manipulate old-style Macintosh pathnames on Mac OS X (or
> any other platform)." which is incorrect (it uses
Bob Ippolito wrote:
[EasyDialogs]
>>Didn't see a waste dependency in the module; you sure about that? I've tried
>>it and it still seems to be working okay (as well as it ever did, anyway), in
>>which case immediate removal is not necessary. I wouldn't be averse to
>>deprecating it just on gene
On 19-apr-2006, at 2:23, Bill Janssen wrote:
> Just looking at the docs, I'm trying to figure out what's good and
> what's bad.
>
> 1) We should no longer point people to Jack's site, we point them to
>the python.org Mac download page instead.
Right.
>
> 2) references to PythonIDE and Packa
Bob Ippolito wrote:
>>In addition, all mentions of OS 9 should either be expunged (e.g. the 'using
>>Python on Mac OS 9' chapter) or changed to 'not supported' (should they still
>>need to be documented for any reason).
>
>Mac OS 9 is definitely no longer supported at all. The *final* release f
Nicholas Riley wrote:
> > >2.3 ic -- Access to Internet Config
> >
> > No idea about this. Anyone else know if this is still working/relevant?
>
>It is basically deprecated for LaunchServices now.
Righto, add it to the 'deprecate' list then.
> It would be really good if we could get a d
Bill Janssen wrote:
>Thanks, Has.
>
>I was hoping someone would go through that list bit-by-bit.
See also NR's post and my reply to it; anything Internet Config-related looks
reasonable to add to the 'deprecate' list. Hopefully there'll be a few more
yeas/nays on it from other folks; like I say
On Apr 19, 2006, at 9:14, Bill Janssen wrote:
> I'm still in favor of simply removing outdated and dangerous docs, but
> perhaps there's some effective way of thoroughly marking them as bad,
> instead.
Put in doc sections entitled Deprecated and Obsolete and do the same
for the web and wiki.
I
Thanks, Has.
I was hoping someone would go through that list bit-by-bit.
I'm still in favor of simply removing outdated and dangerous docs, but
perhaps there's some effective way of thoroughly marking them as bad,
instead.
Bill
___
Pythonmac-SIG mailli
On Wed, Apr 19, 2006 at 02:38:22PM +0100, has wrote:
> >2.3 ic -- Access to Internet Config
>
> No idea about this. Anyone else know if this is still working/relevant?
It is basically deprecated for LaunchServices now. It would be really
good if we could get a decent LaunchServices bindi
> >4.2 Carbon.AH -- Apple Help
>
> Do nothing.
Much like Apple Help itself :-).
Bill
___
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
On 19/04/2006, at 03:23, Bill Janssen wrote:
> 3) What about the following:
>
> 2. MacPython Modules
> 2.1 macpath -- MacOS path manipulation functions
> 2.2 macfs -- Various file system services
> 2.2.1 FSSpec Objects
> 2.2.2 Alias Objects
> 2.2.3 F
Bill Janssen wrote:
>1) We should no longer point people to Jack's site, we point them to
> the python.org Mac download page instead.
Agree. Having links to the old MacPython site in places where folk expect to
find up-to-date information doesn't help.
Also, if there's somewhere to provide a
Just looking at the docs, I'm trying to figure out what's good and
what's bad.
1) We should no longer point people to Jack's site, we point them to
the python.org Mac download page instead.
2) references to PythonIDE and PackageManager should go.
3) What about the following:
2. MacPy
30 matches
Mail list logo
