Re: [Pyobjc-dev] Separating functionality into modules

[<bb...@ma...>]

On Tuesday, November 19, 2002, at 07:48 AM, Jack Jansen wrote:
> On Monday, Nov 18, 2002, at 16:45 Europe/Amsterdam, bb...@ma... wrote:
>>> 4. Why AddressBook is included completely eludes me. Is this 
>>> framework somehow
>>>    more important than the other ones, or is this really only an 
>>> example?
>>
>> At the moment, it is the only first-class, high level, OO API 
>> included with the system that is not highly application specific 
>> [PreferencesPane, ScreenSaver, Project Builder] and includes a public 
>> API.   It is generically useful and represents functionality that 
>> quite a number of developers will want to use.
>
> Ok, fair enough.

Whether or not it should be included is still up in the air.... I'm not 
attached to it in that context.

>>> If for (4) I'm correct and AddressBook is just an example, shouldn't 
>>> we provide a general solution in the form of a factory function so 
>>> the user can do
>>> AddressBook = 
>>> Foundation.Python.GenerateModuleForBundle("AddressBook")
>>
>> It requires a compiled component to wrap a framework such that 
>> enumerated types, #defines, and functions can be exported.  Ronald 
>> has done an amazing job of automating the generating of the wrappers, 
>> but it needs some work before it could automatically generate a 
>> module project to wrap a specific framework.  That would be very, 
>> very > cool...
>
> Oops, I missed that bit, I didn't realise there was an extension 
> module too, I thought it was pure python.
> [search.... search....]
> No, I can't find it. Are you sure that this module isn't pure Python? 
> Because if it is then my factory function idea should work (create a 
> module, populate it with the classes returned by 
> Foundation.load_bundle, return the module).
> And, if there is C code for AddressBook: where is it?

Hey, what do you know... you're right! I thought it had a compiled 
component, as well!  I assumed it had a compiled component because of 
the enumerated types and the global references used throughout the 
module.

Let me amend that:  It *needs* a compiled component if it is to be a 
complete bridge of the AddressBook framework.  Sorry about the 
confusion.

Your factory function would be tremendously valuable anyway and the 
AddressBook is a good example;  for quickly wrapping a framework for 
which enough of the functionality is available via the pure ObjC API to 
be useful.

>>> We need a new place to put Python-specific modules, at the moment 
>>> only for
>>> AppKit but later we may want this for the other packages too. I can 
>>> see two simple solutions:
>>> A. Put them in a sub-package. Foundation.Python comes to mind, but 
>>> there may
>>>    be better names.
>>> B. Prefix them with "Py". Again, another prefix is also possible.
>>
>> Before we go here, how much functionality are we actually talking 
>> about?
>
> At the moment there isn't much, indeed, but I can imagine it growing. 
> With Python's multiple inheritance and operator overloading, for 
> instance, there's all sorts of nifty things you could do, such as
> class TableViewList(list, PyObjC.listTableDataSourceMixin):
> 	pass
> x = TableViewList()
> and then use x both as a normal Python list and as an 
> NSTableDataSource. Note that I haven't actually worked this example 
> out (so it may be plain impossible), but you get the idea.

Totally possible and a very cool idea!   I constantly use a couple of 
hunks of code that I have developed over the years to map an array to 
an NSTableView and map a set of collection classes to NSOutlineView.

> Another example of a python-specific functionality is a mixin class 
> for a dialog that would automatically keep the dialog items synced 
> with another object (using Pythons introspection to obtain the names 
> of the dialog items, looking them up in the other object. Combined 
> with slots this could even happen completely automatic).

Not sure I get this one...

>>> Oh yes: I want a version number somewhere, probably in objc. I don't 
>>> really care whether there's a static version number or a function 
>>> that returns a version number, but I need a version number for my 
>>> Python Installation Manager (which will help keep the size of 
>>> MacPython distributions down, but still allow pretty easy access to 
>>> any package for end users; see the pythonmac-sig discussions for 
>>> more details).
>>
>> Yes;   how about something like....
>>
>> >>> sys.version_info
>> (2, 2, 0, 'final', 0)
>> >>> sys.version
>> '2.2 (#1, 07/14/02, 23:25:09) \n[GCC Apple cpp-precomp 6.14]'
>
> What I want is the version of the PyObjC package. The only thing I 
> need it for is to compare it against the most recent version (which is 
> obtain from a net-based database) and to warn the user that a new 
> version is available. So a simple
> version = '0.9'
> in objc/__init__.py should suffice. It doesn't matter what the 
> datatype of the version is, as long as it is monotonically increasing.

Yes -- what I was asking was more a 'should we advertise a version and 
version_info in the same format as the python core because that is a 
standard?' ... not that the contents of sys.version_info and 
sys.version have any bearing on what pyobjc provide.

     (0, 8, 0, 'alpha', 0)

and

     '0.8.0 alpha (#1, ....), [GCC ... OS X 10.2.2 6F21]'

Or something like it?

b.bum