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
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
28 matches
Mail list logo
