On Mar 3, 2005, at 15:31, Martina Oefelein wrote:
Hi Bob:
Very few people care that undocumented modules don't work correctly.
You have to look pretty hard to even notice their existence in the
first place. I've never heard of a broken undocumented standard
library module becoming a deal-break
Hi Bob:
Very few people care that undocumented modules don't work correctly.
You have to look pretty hard to even notice their existence in the
first place. I've never heard of a broken undocumented standard
library module becoming a deal-breaker for someone new to Python.
Looking at the Globa
On 3/3/05 7:31 AM, "has" <[EMAIL PROTECTED]> wrote:
> Paul Berkowitz wrote:
>
>> The type 'alias' for the Save command in the Standard Suite is a long,
>> longstanding bug in AppleScript.
>
> Replacing (as of 10.3) a previous long, longstanding implementation
> bug where it was specified as a P
Paul Berkowitz wrote:
The type 'alias' for the Save command in the Standard Suite is a long,
longstanding bug in AppleScript.
Replacing (as of 10.3) a previous long, longstanding implementation
bug where it was specified as a POSIX path string. :p
I take it 'alias' is just a documentation error
Donovan Preston wrote:
> No, I wanted a Python OSA component. Different thing. The only person
> I know was asking for an OSA wrapper was Donovan, and he went off to
> work on Nevow yonks ago and AFAIK never did anything with it.
I wanted an OSA module so that it would be possible to write a Pyt
On Mar 2, 2005, at 1:02 PM, has wrote:
It's already there, so it's not going anywhere in 2.4. The
justification is that people *did* ask for an OSA wrapper -- I
believe you were one of the larger proponents.
No, I wanted a Python OSA component. Different thing. The only person
I know was asking
On Mar 2, 2005, at 16:02, has wrote:
Bob wrote:
It can't happen until Python 2.6 at the earliest. I don't think
it's very likely to go away anyway. Good luck!
Why so long? Merely refactoring the distribution doesn't break
backwards compatibility so I don't see why the reorganisation
couldn't b
Bob wrote:
If you learn bgen and submit proper patches
Without proper documentation and tutorials? Sorry, but masochistic
self-flagellation is not my thing. This is somebody else's house of
cards to sort out before everyone else can seriously be expected to
play in it.
Yet you screw around with
On Mar 2, 2005, at 9:51, has wrote:
Bob wrote:
If you learn bgen and submit proper patches
Without proper documentation and tutorials? Sorry, but masochistic
self-flagellation is not my thing. This is somebody else's house of
cards to sort out before everyone else can seriously be expected to
pl
On 3/2/05 6:00 AM, "has" <[EMAIL PROTECTED]> wrote:
>> In this case, the API *asks* for an Alias. So, yeah, you do
>> actually want an Alias.
>
> No, the TextEdit dictionary says 'alias', but the dictionary is
> merely documentation, not the API itself, and dictionaries are
> regularly incorrec
Bob wrote:
Absolutely. I have no problem with mistakes being made. It's
setting them in stone that's the trouble.
Not stone, just molasses.
Near enough as makes no practical difference. It's a situation that
should not occur in the first place. These molasses are entirely
man-made.
If you lear
Bob wrote:
FSSpec is legacy. It should not ever be used in any code except to
reference nonexistent files or to deal with legacy APIs. You
shouldn't use them if the API will take an FSRef or an Alias.
Neither FSRef or Alias can be used to refer to non-existent files.
FileURL does, but I'm not
On Mar 1, 2005, at 3:08 PM, has wrote:
Bob wrote:
1. What's the point of adding a new extension to the standard
library when that extension is not only untested but _already known_
to be broken?
They're automatically generated, these things happen.
Absolutely. I have no problem with mistakes be
Bob wrote:
1. What's the point of adding a new extension to the standard
library when that extension is not only untested but _already
known_ to be broken?
They're automatically generated, these things happen.
Absolutely. I have no problem with mistakes being made. It's setting
them in stone tha
On Mar 1, 2005, at 1:21 PM, has wrote:
Bob wrote:
Instead of fixing OSA, you can write an alternative that isn't bgen
based.
If I do that, will the current OSA.so be thrown out (preferably
right now) and replaced with my version once it's done?
Unlikely, but what does it matter?
1. What's the p
Bob wrote:
Instead of fixing OSA, you can write an alternative that isn't bgen based.
If I do that, will the current OSA.so be thrown out (preferably
right now) and replaced with my version once it's done?
Unlikely, but what does it matter?
1. What's the point of adding a new extension to the stan
On Mar 1, 2005, at 11:58 AM, has wrote:
Bob wrote:
This still leaves Carbon APIs to deal with, however.
It's unlikely that anyone is going to ever bother doing a better job
wrapping Carbon than is already done, because it's a hell of a lot of
work and Carbon isn't really the best way to do most
Bob wrote:
Maybe that's the way to go for CF stuff then: delegate the problem
to PyObjC and get rid of the Carbon.CF extension completely (no
sense in keeping broken modules if they're not worth fixing).
Unfortunately getting rid of an extension is a lot harder than it
sounds. Better is to just
On Mar 1, 2005, at 9:55 AM, has wrote:
Bob wrote:
I wonder if it'd be easier just to hand-code wrappers
Actually, the easiest way is to just use PyObjC!
Maybe that's the way to go for CF stuff then: delegate the problem to
PyObjC and get rid of the Carbon.CF extension completely (no sense in
keep
Bob wrote:
I wonder if it'd be easier just to hand-code wrappers
Actually, the easiest way is to just use PyObjC!
Maybe that's the way to go for CF stuff then: delegate the problem to
PyObjC and get rid of the Carbon.CF extension completely (no sense in
keeping broken modules if they're not worth
On Feb 28, 2005, at 6:16 PM, has wrote:
Bob wrote:
Well I can verify that there definitely are serious problems with
CFURL after screwing around with it a bit.
Figures. Yuck. Must be bgen's revenge for all the nasty things we
ever said about it.
All the nasty things I ever said about it are becau
Bob wrote:
Well I can verify that there definitely are serious problems with
CFURL after screwing around with it a bit.
Figures. Yuck. Must be bgen's revenge for all the nasty things we
ever said about it.
All the nasty things I ever said about it are because of things like this :)
But it's so qu
On Mon, Feb 28, 2005 at 06:41:47PM +, has wrote:
> import Carbon.CF as CF
> f =
> CF.CFURLCreateFromFileSystemRepresentation('file://localhost/Users/has/',
> True)
That's not a filesystem representation (code for "UTF-8 encoded path").
> u'./file://localhost/Users/has' (Where did './' come
Bob wrote:
I'm not really up on these APIs nor their Python wrappers, but I
suspect this stuff is broke:
[...]
Anyone want to confirm/correct me? (OS10.2.8, MacPython 2.3.3)
I wouldn't be surprised if it's broken,
Mmmm... encouraging.
(Hey: if bgen is so great, why won't it generate some damn test
On Feb 28, 2005, at 3:41 PM, has wrote:
Bob wrote:
I'm not really up on these APIs nor their Python wrappers, but I
suspect this stuff is broke:
[...]
Anyone want to confirm/correct me? (OS10.2.8, MacPython 2.3.3)
I wouldn't be surprised if it's broken,
Mmmm... encouraging.
(Hey: if bgen is so gre
On Feb 28, 2005, at 1:41 PM, has wrote:
I'm not really up on these APIs nor their Python wrappers, but I
suspect this stuff is broke:
First try:
import Carbon.CF as CF
f =
CF.CFURLCreateFromFileSystemRepresentation('file://localhost/Users/
has/', True)
print f #
print `f.CFURLGetString().toP
Hi folks,
I'm not really up on these APIs nor their Python wrappers, but I
suspect this stuff is broke:
First try:
import Carbon.CF as CF
f =
CF.CFURLCreateFromFileSystemRepresentation('file://localhost/Users/has/',
True)
print f #
print `f.CFURLGetString().toPython()` #
u'./file://localhost/
27 matches
Mail list logo
