Re: [Python-Dev] PEP487: Simpler customization of class creation

[Martin Teichmann]

Hi list, Hi Nick,

Sorry for my delayed response, it is summer here...

> However, phrasing it that way suggest that it's possible we *did* miss
> something in the PEP: we haven't specified whether or not __set_name__
> should be called when someone does someone does "cls.attr = descr".
> Given the name, I think we *should* call it in that case, and then the
> semantics during class creation are approximately what would happen if
> we actually built up the class attributes as:
>
> for attr, value in cls_ns.items():
> setattr(cls, attr, value)

That's a very good point and actually easy to solve: we would just
need to override type.__setattr__ to do so. Actually, it is already
overridden, so we just need to add code to type.__setattr__ to also
call __set_name__.

One could be of the other standpoint that in your above example it's
the duty of the caller of setattr to also call __set_name__. It would
be pretty easy to add a line in the loop that also calls
__set_owner__.

Greetings

Martin
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 514: Python registration in the Windows registry

[Paul Moore]

This PEP is now accepted. Congratulations, Steve! And thanks for
putting up with all of my last-minute questions :-)

Paul

On 23 July 2016 at 21:20, Guido van Rossum  wrote:
> I'll let Paul pronounce. But you should probably have a BDFL-Delegate:
> ... header.
>
> On Sat, Jul 23, 2016 at 12:16 PM, Steve Dower  wrote:
>> PEP 514 is now ready for pronouncement, so this is the last chance for any
>> feedback (BDFL-delegate Paul has been active on the github PR, so I don't
>> expect he has a lot of feedback left).
>>
>> The most major change from the previous post is the addition of some code
>> examples at the end. Honestly, I don't expect many tools written in Python
>> to be scanning the registry (since once you're in Python you probably don't
>> need to find it), but hopefully they'll help clarify the PEP for people who
>> prefer code.
>>
>> Full text below.
>>
>> Cheers,
>> Steve
>>
>> --
>>
>> PEP: 514
>> Title: Python registration in the Windows registry
>> Version: $Revision$
>> Last-Modified: $Date$
>> Author: Steve Dower 
>> Status: Draft
>> Type: Informational
>> Content-Type: text/x-rst
>> Created: 02-Feb-2016
>> Post-History: 02-Feb-2016, 01-Mar-2016, 18-Jul-2016
>>
>> Abstract
>> 
>>
>> This PEP defines a schema for the Python registry key to allow third-party
>> installers to register their installation, and to allow tools and
>> applications
>> to detect and correctly display all Python environments on a user's machine.
>> No
>> implementation changes to Python are proposed with this PEP.
>>
>> Python environments are not required to be registered unless they want to be
>> automatically discoverable by external tools. As this relates to Windows
>> only,
>> these tools are expected to be predominantly GUI applications. However,
>> console
>> applications may also make use of the registered information. This PEP
>> covers
>> the information that may be made available, but the actual presentation and
>> use
>> of this information is left to the tool designers.
>>
>> The schema matches the registry values that have been used by the official
>> installer since at least Python 2.5, and the resolution behaviour matches
>> the
>> behaviour of the official Python releases. Some backwards compatibility
>> rules
>> are provided to ensure tools can correctly detect versions of CPython that
>> do
>> not register full information.
>>
>> Motivation
>> ==
>>
>> When installed on Windows, the official Python installer creates a registry
>> key
>> for discovery and detection by other applications. This allows tools such as
>> installers or IDEs to automatically detect and display a user's Python
>> installations. For example, the PEP 397 ``py.exe`` launcher and editors such
>> as
>> PyCharm and Visual Studio already make use of this information.
>>
>> Third-party installers, such as those used by distributions, typically
>> create
>> identical keys for the same purpose. Most tools that use the registry to
>> detect
>> Python installations only inspect the keys used by the official installer.
>> As a
>> result, third-party installations that wish to be discoverable will
>> overwrite
>> these values, often causing users to "lose" their original Python
>> installation.
>>
>> By describing a layout for registry keys that allows third-party
>> installations
>> to register themselves uniquely, as well as providing tool developers
>> guidance
>> for discovering all available Python installations, these collisions should
>> be
>> prevented. We also take the opportunity to add some well-known metadata so
>> that
>> more information can be presented to users.
>>
>> Definitions
>> ===
>>
>> A "registry key" is the equivalent of a file-system path into the registry.
>> Each
>> key may contain "subkeys" (keys nested within keys) and "values" (named and
>> typed attributes attached to a key). These are used on Windows to store
>> settings
>> in much the same way that directories containing configuration files would
>> work.
>>
>> ``HKEY_CURRENT_USER`` is the root of settings for the currently logged-in
>> user,
>> and this user can generally read and write all settings under this root.
>>
>> ``HKEY_LOCAL_MACHINE`` is the root of settings for all users. Generally, any
>> user can read these settings but only administrators can modify them. It is
>> typical for values under ``HKEY_CURRENT_USER`` to take precedence over those
>> in
>> ``HKEY_LOCAL_MACHINE``.
>>
>> On 64-bit Windows, ``HKEY_LOCAL_MACHINE\Software\Wow6432Node`` is a special
>> key
>> that 32-bit processes transparently read and write to rather than accessing
>> the
>> ``Software`` key directly.
>>
>> Further documentation regarding registry redirection on Windows is available
>> from the MSDN Library [1]_.
>>
>> Structure
>> =
>>
>> We consider there to be a single collection of Python environments on a
>> machine,
>> where the collection may be different for each user of the machine. There
>> are
>> three potential registr

Re: [Python-Dev] PEP 447: Add __getdescriptor__ to metaclasses

[Nick Coghlan]

On 23 July 2016 at 22:26, Ronald Oussoren  wrote:
> I’m currently working on getting the patch in 18181 up-to-date w.r.t. the
> current trunk, the patch in the issue no longer applies cleanly. After that
> I’ll try to think up some tests that seriously try to break the new
> behaviour, and I want to update a patch I have for PyObjC to make use of the
> new functionality to make sure that the PEP actually fixes the issues I had
> w.r.t. builtin.super’s behavior.

You may also want to check compatibility with Martin's patch for PEP
487 (__init_subclass__ and __set_name__) at
http://bugs.python.org/issue27366

I don't *think* it will conflict, but "try it and see what happens" is
generally a better idea for the descriptor machinery than assuming
changes are going to be non-conflicting :)

> What is the best way forward after that? As before this is a change in
> behavior that, unsurprisingly, few core devs appear to be comfortable with
> evaluating, combined with new functionality that will likely see little use
> beyond PyObjC.

You may want to explicitly ping the
https://github.com/ipython/traitlets developers to see if this change
would let them do anything they currently find impractical or
impossible.

As far as Mark's concern about a non-terminating method definition
goes, I do think you need to double check how the semantics of
object.__getattribute__ are formally defined.

>>> class Meta(type):
... def __getattribute__(self, attr):
... print("Via metaclass!")
... return super().__getattribute__(attr)
...
>>> class Example(metaclass=Meta): pass
...
>>> Example.mro()
Via metaclass!
[, ]

Where the current PEP risks falling into unbounded recursion is that
it appears to propose that the default type.__getdescriptor__
implementation be defined in terms of accessing cls.__dict__, but a
normal Python level access to "cls.__dict__" would go through the
descriptor machinery, triggering an infinite regress.

The PEP needs to be explicit that where "cls.__dict__" is written in
the definitions of both the old and new lookup semantics, it is *not*
referring to a normal class attribute lookup, but rather to the
interpreter's privileged access to the class namespace (e.g. direct
'tp_dict' access in CPython).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 447: Add __getdescriptor__ to metaclasses

[Ronald Oussoren]

> On 24 Jul 2016, at 12:37, Nick Coghlan  wrote:
> 
> On 23 July 2016 at 22:26, Ronald Oussoren  wrote:
>> I’m currently working on getting the patch in 18181 up-to-date w.r.t. the
>> current trunk, the patch in the issue no longer applies cleanly. After that
>> I’ll try to think up some tests that seriously try to break the new
>> behaviour, and I want to update a patch I have for PyObjC to make use of the
>> new functionality to make sure that the PEP actually fixes the issues I had
>> w.r.t. builtin.super’s behavior.
> 
> You may also want to check compatibility with Martin's patch for PEP
> 487 (__init_subclass__ and __set_name__) at
> http://bugs.python.org/issue27366
> 
> I don't *think* it will conflict, but "try it and see what happens" is
> generally a better idea for the descriptor machinery than assuming
> changes are going to be non-conflicting :)

I also don’t think the two will conflict, but that’s based on a superficial 
read 
of that PEP the last time it was posted on python-dev. PEP 487 and 447 affect
different parts of the object model, in particular PEP 487 doesn’t affect 
attribute lookup.

> 
>> What is the best way forward after that? As before this is a change in
>> behavior that, unsurprisingly, few core devs appear to be comfortable with
>> evaluating, combined with new functionality that will likely see little use
>> beyond PyObjC.
> 
> You may want to explicitly ping the
> https://github.com/ipython/traitlets developers to see if this change
> would let them do anything they currently find impractical or
> impossible.

I’ll ask them.

> 
> As far as Mark's concern about a non-terminating method definition
> goes, I do think you need to double check how the semantics of
> object.__getattribute__ are formally defined.
> 
 class Meta(type):
>... def __getattribute__(self, attr):
>... print("Via metaclass!")
>... return super().__getattribute__(attr)
>...
 class Example(metaclass=Meta): pass
>...
 Example.mro()
>Via metaclass!
>[, ]
> 
> Where the current PEP risks falling into unbounded recursion is that
> it appears to propose that the default type.__getdescriptor__
> implementation be defined in terms of accessing cls.__dict__, but a
> normal Python level access to "cls.__dict__" would go through the
> descriptor machinery, triggering an infinite regress.
> 
> The PEP needs to be explicit that where "cls.__dict__" is written in
> the definitions of both the old and new lookup semantics, it is *not*
> referring to a normal class attribute lookup, but rather to the
> interpreter's privileged access to the class namespace (e.g. direct
> 'tp_dict' access in CPython).

On first glance the same is true for all access to dunder attributes in sample
code for the PEP, a similar example could be written for __get__ or __set__. 
I have to think a bit more about how to clearly describe this.

I’m currently coaxing PyObjC into using PEP 447 when that’s available
and that involves several layers of metaclasses in C and that’s annoyingly 
hard to debug when the code doesn’t do what I want like it does now.

But on the other hand, that’s why wanted to use PyObjC to validate
the PEP in the first place.

Back to wrangling C code,

   Ronald


> 
> Cheers,
> Nick.
> 
> -- 
> Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP487: Simpler customization of class creation

[Guido van Rossum]

I am very much against this. The two are not at all like each other. Also,
what's the use case?

On Sunday, July 24, 2016, Martin Teichmann  wrote:

> Hi list, Hi Nick,
>
> Sorry for my delayed response, it is summer here...
>
> > However, phrasing it that way suggest that it's possible we *did* miss
> > something in the PEP: we haven't specified whether or not __set_name__
> > should be called when someone does someone does "cls.attr = descr".
> > Given the name, I think we *should* call it in that case, and then the
> > semantics during class creation are approximately what would happen if
> > we actually built up the class attributes as:
> >
> > for attr, value in cls_ns.items():
> > setattr(cls, attr, value)
>
> That's a very good point and actually easy to solve: we would just
> need to override type.__setattr__ to do so. Actually, it is already
> overridden, so we just need to add code to type.__setattr__ to also
> call __set_name__.
>
> One could be of the other standpoint that in your above example it's
> the duty of the caller of setattr to also call __set_name__. It would
> be pretty easy to add a line in the loop that also calls
> __set_owner__.
>
> Greetings
>
> Martin
> ___
> Python-Dev mailing list
> Python-Dev@python.org 
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>


-- 
--Guido (mobile)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 514: Python registration in the Windows registry

[Ethan Furman]

On 07/24/2016 12:45 AM, Paul Moore wrote:


This PEP is now accepted. Congratulations, Steve!


And more congratulations!  :)

--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP487: Simpler customization of class creation

[Ethan Furman]

On 07/24/2016 08:20 AM, Guido van Rossum wrote:


I am very much against this. The two are not at all like each other. Also, 
what's the use case?


To be clear:  you are against the automatic calling of __set_name__ and/or 
__set_owner__ when using
setattr outside of class creation?  Said another way: class creation mechanics 
should only happen
during class creation?

--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP487: Simpler customization of class creation

[Guido van Rossum]

Yes.

--Guido (mobile)

On Jul 24, 2016 9:34 AM, "Ethan Furman"  wrote:

> On 07/24/2016 08:20 AM, Guido van Rossum wrote:
>
> I am very much against this. The two are not at all like each other. Also,
>> what's the use case?
>>
>
> To be clear:  you are against the automatic calling of __set_name__ and/or
> __set_owner__ when using
> setattr outside of class creation?  Said another way: class creation
> mechanics should only happen
> during class creation?
>
> --
> ~Ethan~
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 514: Python registration in the Windows registry

[Steve Dower]

Thanks Paul.

I'll update the headers on the PEP later today.

Top-posted from my Windows Phone

-Original Message-
From: "Paul Moore" 
Sent: ‎7/‎24/‎2016 0:45
To: "Guido van Rossum" 
Cc: "Steve Dower" ; "Python Dev" 
Subject: Re: [Python-Dev] PEP 514: Python registration in the Windows registry

This PEP is now accepted. Congratulations, Steve! And thanks for
putting up with all of my last-minute questions :-)

Paul

On 23 July 2016 at 21:20, Guido van Rossum  wrote:
> I'll let Paul pronounce. But you should probably have a BDFL-Delegate:
> ... header.
>
> On Sat, Jul 23, 2016 at 12:16 PM, Steve Dower  wrote:
>> PEP 514 is now ready for pronouncement, so this is the last chance for any
>> feedback (BDFL-delegate Paul has been active on the github PR, so I don't
>> expect he has a lot of feedback left).
>>
>> The most major change from the previous post is the addition of some code
>> examples at the end. Honestly, I don't expect many tools written in Python
>> to be scanning the registry (since once you're in Python you probably don't
>> need to find it), but hopefully they'll help clarify the PEP for people who
>> prefer code.
>>
>> Full text below.
>>
>> Cheers,
>> Steve
>>
>> --
>>
>> PEP: 514
>> Title: Python registration in the Windows registry
>> Version: $Revision$
>> Last-Modified: $Date$
>> Author: Steve Dower 
>> Status: Draft
>> Type: Informational
>> Content-Type: text/x-rst
>> Created: 02-Feb-2016
>> Post-History: 02-Feb-2016, 01-Mar-2016, 18-Jul-2016
>>
>> Abstract
>> 
>>
>> This PEP defines a schema for the Python registry key to allow third-party
>> installers to register their installation, and to allow tools and
>> applications
>> to detect and correctly display all Python environments on a user's machine.
>> No
>> implementation changes to Python are proposed with this PEP.
>>
>> Python environments are not required to be registered unless they want to be
>> automatically discoverable by external tools. As this relates to Windows
>> only,
>> these tools are expected to be predominantly GUI applications. However,
>> console
>> applications may also make use of the registered information. This PEP
>> covers
>> the information that may be made available, but the actual presentation and
>> use
>> of this information is left to the tool designers.
>>
>> The schema matches the registry values that have been used by the official
>> installer since at least Python 2.5, and the resolution behaviour matches
>> the
>> behaviour of the official Python releases. Some backwards compatibility
>> rules
>> are provided to ensure tools can correctly detect versions of CPython that
>> do
>> not register full information.
>>
>> Motivation
>> ==
>>
>> When installed on Windows, the official Python installer creates a registry
>> key
>> for discovery and detection by other applications. This allows tools such as
>> installers or IDEs to automatically detect and display a user's Python
>> installations. For example, the PEP 397 ``py.exe`` launcher and editors such
>> as
>> PyCharm and Visual Studio already make use of this information.
>>
>> Third-party installers, such as those used by distributions, typically
>> create
>> identical keys for the same purpose. Most tools that use the registry to
>> detect
>> Python installations only inspect the keys used by the official installer.
>> As a
>> result, third-party installations that wish to be discoverable will
>> overwrite
>> these values, often causing users to "lose" their original Python
>> installation.
>>
>> By describing a layout for registry keys that allows third-party
>> installations
>> to register themselves uniquely, as well as providing tool developers
>> guidance
>> for discovering all available Python installations, these collisions should
>> be
>> prevented. We also take the opportunity to add some well-known metadata so
>> that
>> more information can be presented to users.
>>
>> Definitions
>> ===
>>
>> A "registry key" is the equivalent of a file-system path into the registry.
>> Each
>> key may contain "subkeys" (keys nested within keys) and "values" (named and
>> typed attributes attached to a key). These are used on Windows to store
>> settings
>> in much the same way that directories containing configuration files would
>> work.
>>
>> ``HKEY_CURRENT_USER`` is the root of settings for the currently logged-in
>> user,
>> and this user can generally read and write all settings under this root.
>>
>> ``HKEY_LOCAL_MACHINE`` is the root of settings for all users. Generally, any
>> user can read these settings but only administrators can modify them. It is
>> typical for values under ``HKEY_CURRENT_USER`` to take precedence over those
>> in
>> ``HKEY_LOCAL_MACHINE``.
>>
>> On 64-bit Windows, ``HKEY_LOCAL_MACHINE\Software\Wow6432Node`` is a special
>> key
>> that 32-bit processes transparently read and write to rather than accessing
>> the
>> ``Software`` key directly.
>>
>> Further documentation regarding

Re: [Python-Dev] PEP487: Simpler customization of class creation

[Nick Coghlan]

On 25 July 2016 at 03:00, Guido van Rossum  wrote:
> Yes.

OK, we can cover that in the documentation - if folks want to emulate
what happens during class construction after the fact, they'll need to
do:

cls.name = attr
attr.__set_name__(cls, "name")

Semantically, I agree that approach makes sense - by default,
descriptors created outside a class body won't have a defined owning
class or attribute name, and if you want to give them one, you'll have
to do it explicitly.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 447: Add __getdescriptor__ to metaclasses

[Ronald Oussoren]

On 24 Jul 2016, at 13:06, Ronald Oussoren  wrote:…But on the other hand, that’s why wanted to use PyObjC to validatethe PEP in the first place.I’ve hit a fairly significant issue with this, PyObjC’s super contains more magic than just this magic that would be fixed by PEP 447. I don’t think I’ll be able to finish work on PEP 447 this week because of that, and in the worst case will have to retire the PEP.The problem is as follows: to be able to map all of Cocoa’s methods to Python PyObjC creates two proxy classes for every Cocoa class: the regular class and its metaclass. The latter is used to store class methods. This is needed because Objective-C classes can have instance and class methods with the same name, as an example:@interface NSObject-(NSString*)description;+(NSString*)description@endThe first declaration for “description” is an instance method, the second is a class method.  The Python metaclass is mostly a hidden detail, users don’t explicitly interact with these classes and use the normal Python convention for defining class methods.This works fine, problems starts when you want to subclass in Python and override the class method:class MyClass (NSObject):   @classmethod   def description(cls):       return “hello there from %r” % (super(MyClass, cls).description())If you’re used to normal Python code there’s nothing wrong here, but getting this to work required some magic in objc.super to ensure that its __getattribute__ looks in the metaclass in this case and not the regular class.  The current PEP447-ised version of PyObjC has a number of test failures because builtin.super obviously doesn’t contain this hack (and shouldn’t). I think I can fix this for modern code that uses an argumentless call to super by replacing the cell containing the __class__ reference when moving the method from the regular class to the instance class. That would obviously not work for the code I showed earlier, but that at least won’t fail silently and the error message is specific enough that I can include it in PyObjC’s documentation.The next steps for me are to fix the remaining issues in PyObjC’s support for PEP 447, and trying to implement the replacement of __class__. If that works out I’ll finish the PEP and ask for a pronouncement. If that doesn’t work out I’ll at least report on that.RonaldBack to wrangling C code,  RonaldCheers,Nick.-- Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia___Python-Dev mailing listPython-Dev@python.orghttps://mail.python.org/mailman/listinfo/python-devUnsubscribe: https://mail.python.org/mailman/options/python-dev/ronaldoussoren%40mac.com___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 447: Add __getdescriptor__ to metaclasses

[Ronald Oussoren]

> On 24 Jul 2016, at 13:06, Ronald Oussoren  > wrote:
> 
…

> But on the other hand, that’s why wanted to use PyObjC to validate
> the PEP in the first place.

I’ve hit a fairly significant issue with this, PyObjC’s super contains more 
magic than just this magic that would be fixed by PEP 447. I don’t think I’ll 
be able to finish work on PEP 447 this week because of that, and in the worst 
case will have to retire the PEP.

The problem is as follows: to be able to map all of Cocoa’s methods to Python 
PyObjC creates two proxy classes for every Cocoa class: the regular class and 
its metaclass. The latter is used to store class methods. This is needed 
because Objective-C classes can have instance and class methods with the same 
name, as an example:

@interface NSObject
-(NSString*)description;
+(NSString*)description
@end

The first declaration for “description” is an instance method, the second is a 
class method.  The Python metaclass is mostly a hidden detail, users don’t 
explicitly interact with these classes and use the normal Python convention for 
defining class methods.

This works fine, problems starts when you want to subclass in Python and 
override the class method:

class MyClass (NSObject):
   @classmethod
   def description(cls): 
  return “hello there from %r” % (super(MyClass, cls).description())

If you’re used to normal Python code there’s nothing wrong here, but getting 
this to work required some magic in objc.super to ensure that its 
__getattribute__ looks in the metaclass in this case and not the regular class. 
 The current PEP447-ised version of PyObjC has a number of test failures 
because builtin.super obviously doesn’t contain this hack (and shouldn’t). 

I think I can fix this for modern code that uses an argumentless call to super 
by replacing the cell containing the __class__ reference when moving the method 
from the regular class to the instance class. That would obviously not work for 
the code I showed earlier, but that at least won’t fail silently and the error 
message is specific enough that I can include it in PyObjC’s documentation.

Ronald




> 
> Back to wrangling C code,
> 
>   Ronald
> 
> 
>> 
>> Cheers,
>> Nick.
>> 
>> -- 
>> Nick Coghlan   |   ncogh...@gmail.com    |   
>> Brisbane, Australia
> 
> ___
> Python-Dev mailing list
> Python-Dev@python.org 
> https://mail.python.org/mailman/listinfo/python-dev 
> 
> Unsubscribe: 
> https://mail.python.org/mailman/options/python-dev/ronaldoussoren%40mac.com 
> 
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com