pyobjc-dev Mailing List for PyObjC (Page 285)

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

bb...@ma... wrote:

> /usr/include/objc/objc-runtime.h:OBJC_EXPORT id objc_lookUpClass(const 
> char *name);

Ah, that settles that. Perfect. Sorry for bringing it up!

Just

bb...@ma... wrote:

[ pyobjc-checkins-list ]
> I would be happy to set up the list and will do so this morning [EST].

Great.

> Assuming python is available on the cvs server [I believe it is],

It is.

> I have commit scripts that coalesces any single checkin such that it
> only sends one email as opposed to the 55 billion emails that most
> checkins send;  one for each directory.   (Christian Pekeler and I
> wrote/refined it over the last few years.)  You are welcome to it, if
> it'd help...

Does it add a (context) diff to the message?

There's a Python script on SF that's developed by Barry Warsaw (I think, could
have been Fred Drake or both) that various Python projects use on SF (including
my own fonttools project) and I love it.

Yes, it does send one message per directory, but how common are huge patches
that touch large numbers of folders? (And if they _are_ common, I think there's
something horribly wrong...)

I'm on one CVS checkins list that _doesn't_ add diffs: it's useless for me. I
need to see what happened.

Besides, if the amount of messages bothers you, you can always set your
subscription to digest ;-)

Just

On Thursday, November 21, 2002, at 09:22 AM, Just van Rossum wrote:
> I see Ronald has renamed lookup_class to lookUpClass. I would have 
> expected
> lookupClass (with a lowercase u) as I tend to think of "lookup" as one 
> word.
> Since english isn't my native tongue I can't really judge whether that 
> is
> correct, or whether it really matters...

We should follow the "conventions" as set forth in the ObjC API:

[bumbox:IssueCenter/V3/Python] bbum% grep -i lookup 
/usr/include/objc/*.h
/usr/include/objc/objc-runtime.h:OBJC_EXPORT id objc_lookUpClass(const 
char *name);

b.bum

On Thursday, November 21, 2002, at 08:35 AM, Just van Rossum wrote:
> My commit rights are finally working! Breakage ahead! (Just kidding.)
>
> I just removed the actionstub stuff from NibClassBuilder.py. I left 
> part of the
> code in there as _if_ we want to issue a warning ourselves if an 
> action is not
> defined, this is the place to do it.

Ok.

> Btw. I see we have no checkin messages mailing list :-(. I know how to 
> set it up
> CVS-wise, but I think you need to be a project admin to create a new 
> list.

I would be happy to set up the list and will do so this morning [EST].

Assuming python is available on the cvs server [I believe it is], I 
have commit scripts that coalesces any single checkin such that it only 
sends one email as opposed to the 55 billion emails that most checkins 
send;  one for each directory.   (Christian Pekeler and I wrote/refined 
it over the last few years.)  You are welcome to it, if it'd help...

> I could update various examples to use NibClassBuilder instead of the 
> nibwrapper
> stuff. Objections?

Makes sense... I'll be updating the Cocoa project template [and the new 
Multi-Document App template] shortly.

b.bum

> Juust

(Interesting that I mis-spell my own name in a mail about spelling ;-)

Jst

I see Ronald has renamed lookup_class to lookUpClass. I would have expected
lookupClass (with a lowercase u) as I tend to think of "lookup" as one word.
Since english isn't my native tongue I can't really judge whether that is
correct, or whether it really matters...

Juust

IMO Tools/mknibwrapper is obsolete now, but if we remove it the Tools dir is
empty apart from a README. It says:

  Reserved for PyObjC related tools"

However, Scripts/README says:

  Reserved for PyObjC related scripts (for 'end-users')

yet contains meta tools nevertheless. Shall I just clear out the Tools/ dir and
remove the "for end users" comment from Scripts/README?

Just

My commit rights are finally working! Breakage ahead! (Just kidding.)

I just removed the actionstub stuff from NibClassBuilder.py. I left part of the
code in there as _if_ we want to issue a warning ourselves if an action is not
defined, this is the place to do it.

Btw. I see we have no checkin messages mailing list :-(. I know how to set it up
CVS-wise, but I think you need to be a project admin to create a new list.

I could update various examples to use NibClassBuilder instead of the nibwrapper
stuff. Objections?

Just

Jack Jansen wrote:

> > I think that Python embedders should think twice about embedding
> > based on an install not included with the system: the above is
> > definitely not the only reason things may break. If you embed, ship
> > Python as well and be done with it.
> 
> I fail to see this... In the case of MacCVS it's simple: if there's no 
> framework Python installation you get no scripting capabilities.

Sure, it's sortof an addon.

I really don't see the point in worrying too much about embedders: X
applications embedding Python will depend on Y versions/installtypes of Python,
and I very much doubt that Y will ever be closer to 1 than to X. Might as well
ship your own Python and get a _lot_ less support request from your users.

> In the case of the Python OSA component I'm not sure what happens,
> but it doesn't really matter: the Python OSA component should be
> considered an integral part of the Python distribution (and we also
> don't really care what the IDE does if Python isn't installed).

I don't really see this as an app embedding Python: it's an environment which
can work with Python if it's installed. If Python is optional, you're not really
embedding...

I'm thinking more of apps that _depend_ on Python, and for such apps a separate
Python install is simply a common source of errors. I _know_, I've been there
with Robofog. Later we shipped two versions: one depending on a separate
MacPython install and one with a truly embedded Python. We got countless
(install) error reports from (experienced!) end users using the former and none
from people using the latter.

Just

Jack Jansen wrote:

> Let's go all the way and put the Mac/Lib stuff where it belongs,

Ok, but then surely a symlink in the repository would be better than a copy?

Just

On Wednesday, Nov 20, 2002, at 16:35 Europe/Amsterdam, Just van Rossum 
wrote:

> Jack Jansen wrote:
>
>> [ ... ] With a shared library approach your python installation
>> cannot be moved around anymore (Python itself can handle this, by
>> using its own argv[0] to locate the Lib folder, but embedding
>> applications will always use the fixed fallback path). [ ... ]
>
> I think that Python embedders should think twice about embedding based 
> on an
> install not included with the system: the above is definitely not the 
> only
> reason things may break. If you embed, ship Python as well and be done 
> with it.

I fail to see this... In the case of MacCVS it's simple: if there's no 
framework Python installation you get no scripting capabilities. In the 
case of the Python OSA component I'm not sure what happens, but it 
doesn't really matter: the Python OSA component should be considered an 
integral part of the Python distribution (and we also don't really care 
what the IDE does if Python isn't installed).
--
- Jack Jansen        <Jac...@or...>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- Emma 
Goldman -

On Wednesday, Nov 20, 2002, at 16:30 Europe/Amsterdam, Just van Rossum 
wrote:

> Jack Jansen wrote:
>
>> How about bringing this up on python-dev, and then (if people agree)
>> submitting the sourceforge support request? Please have the Mac/Lib
>> subtree *copied* to plat-mac, not moved. We still need it in the
>> original location if we want to do a 2.2.3 release.
>
> Ugh, can't we just leave the source tree as it is and just change the 
> install
> location(s)? This is all done by the top level setup.py script, right? 
> If so,
> this suggests we should be able to fully control this.

No, I'm against that. This would make python not find the Mac modules 
when run from the
development directory (as the modules are in a different place then). 
Moreover, the
copying is done from the Makefile, not setup.py, and this would give a 
special case
for Mac/Lib, while there really is no reason for the special case.

Let's go all the way and put the Mac/Lib stuff where it belongs,
--
- Jack Jansen        <Jac...@or...>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- Emma 
Goldman -

On Wednesday, November 20, 2002, at 08:32 AM, Jack Jansen wrote:
> On Wednesday, Nov 20, 2002, at 12:21 Europe/Amsterdam, tmk wrote:
>> That said, I trust the fact that Jack may have very good reasons to 
>> favor the framework install option instead. When you can spare the 
>> time Jack inquiring minds want to know :-)
> As I explained on the pythonmac-sig last month I'm not so sure 
> anymore, I would like to keep both options open for python 2.3, and 
> then we'll see which build catches on.

That's a dangerous game to play in the Mac and NeXT community that we 
have today... there are a lot of people that'll hang on to whatever 
they know for no good reason at all (myself included, at times :-).

> But when people thought I suggested doing away with framework builds 
> completely (which I didn't) there was quite a bit of protest. MacCVS 
> needs it, for using Python as its scripting language, and the Python 
> OSA component needs it.

Why do MacCVS and the OSA component need the framework build?  i.e. 
what is the specific dependency?  (I lurked throughout that 
conversation, but didn't catch specifics -- if you have URLs into the 
archive, that'd be great)

There is a middle ground -- don't build all of the python distribution 
as a framework build.  Simply stuff any resources that are mac specific 
into a bundle or framework that is installed into site-packages/ or 
<prefix>/lib/python<version>/plat-darwin/ and load 'em from that (thus 
also leveraging localization and other Bundle features).   The Mac 
specific modules could be built into the framework/bundle, as well, and 
could be dynamically loaded.   It could be done quite a number of 
ways...

> Note that a non-framework Python with a shared library seems like a 
> solution for this it's really only a poor substitute. With a shared 
> library approach your python installation cannot be moved around 
> anymore (Python itself can handle this, by using its own argv[0] to 
> locate the Lib folder, but embedding applications will always use the 
> fixed fallback path). Especially if we want binary installers things 
> shouldn't depend on a compile-time builtin pathname.

I'm not sure I understand.  Both frameworks and dylibs share the trait 
that they have the path to the library embedded in the dynamically 
loaded code...

[bumbox:~] bbum% otool -L /Library/Frameworks/PGPui.framework/PGPui
/Library/Frameworks/PGPui.framework/PGPui:
         /Library/Frameworks/PGPui.framework/Versions/A/PGPui 
(compatibility version 1.0.0, current version 1.0.0)
         /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa 
(compatibility version 1.0.0, current version 8.0.0)
         /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon 
(compatibility version 2.0.0, current version 122.0.0)
         /Library/Frameworks/PGP.framework/Versions/A/PGP (compatibility 
version 1.0.0, current version 1.0.0)
         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, 
current version 60.2.0)

... and, as such, anything built against that framework will require 
that framework to always be in the spot as specified by the embedded 
path unless you play games with the DYLIB environment variables prior 
to launching the executable that requires the framework [as does 
python-bin-main to allow embedding of frameworks in the app wrapper].

b.bum

On Wednesday, November 20, 2002, at 08:45 AM, Jack Jansen wrote:
> No, not an arbitrary one, it picks the first one you specified. But 
> never mind:
> let's do this your way (i.e. specify the nib by name, separate from 
> the .plist
> files).

I'm confused;  will this work with the localization features built into 
the system?

On Wednesday, November 20, 2002, at 02:19 AM, Ronald Oussoren wrote:
> That said, I'd like to build a module or script to build a template 
> from wrapping yet another Objective-C class library. I don't think it 
> would be usefull to use 'AddressBook = 
> Foundation.Python.GenerateModuleForBundle("AddressBook")' as a 
> replacement for 'import AddressBook'

There are two kinds of 'automatic wrapping' possible and thing there is 
some confusion as to who is referring to which type.

First, 'automatic wrapping' can be something that replaces 'import 
AddressBook'.   For Objective-C APIs, we already have this -- simply 
load the framework as a bundle via load_bundle (soon loadBundle) and 
use the APIs directly.   This is effectively how the AddressBook 
wrapper is currently working outside of it being included as a module 
within the objc project.   Easy to do, but doesn't include support the 
various enumerated types and global variables found in the framework.

The second kind of 'automatic wrapping' would effectively generate a 
distutils based project that included the automatically generated 
source that, when compiled, would produce a module that contained the 
various exported references that can only be accessed via a compiled 
module [the various globals and C functions, etc... though, also 
containing a wrapping of the enumerated types is useful in that a 
simple recompile will pick up any changes to the types].

The first can be done on the fly on any machine.... the second requires 
the dev tools and is really more appropriate for developers looking to 
wrap existing frameworks.

Both very useful but, in general, only the second will be able to fully 
wrap an existing framework automatically.

b.bum

Jack Jansen wrote:

> [ ... ] With a shared library approach your python installation
> cannot be moved around anymore (Python itself can handle this, by
> using its own argv[0] to locate the Lib folder, but embedding
> applications will always use the fixed fallback path). [ ... ]

I think that Python embedders should think twice about embedding based on an
install not included with the system: the above is definitely not the only
reason things may break. If you embed, ship Python as well and be done with it.

Just

Jack Jansen wrote:

> How about bringing this up on python-dev, and then (if people agree)
> submitting the sourceforge support request? Please have the Mac/Lib
> subtree *copied* to plat-mac, not moved. We still need it in the
> original location if we want to do a 2.2.3 release.

Ugh, can't we just leave the source tree as it is and just change the install
location(s)? This is all done by the top level setup.py script, right? If so,
this suggests we should be able to fully control this.

Just

Jack Jansen wrote:

> > I read your code, and it just picks an arbitrary nib if there are
> > more than one, I don't quite understand how you can defend that...
> 
> No, not an arbitrary one, it picks the first one you specified. But
> never mind: let's do this your way (i.e. specify the nib by name,
> separate from the ..plist files).

Ah, whoops, sorry for the misunderstanding!

> >> But unfortunately the __rawmain__ trick is needed for one of the most
> >> useful applications of an applet: taking a standard unix Python
> >> script and turning it into a droplet.
> >
> > Don't you want to move the argv emulation to Python as well? It's
> > hairy stuff and I think we could win a great deal to have it in
> > Python. I really think we should strive to use a vanilla main, and
> > the execve wrapper makes it all possible.
> 
> Let me borrow Guido's time machine .... [POOF] Done!
> 
> PythonW uses the normal unix main program (as of 2.3a0, not in
> 2.2.X). And the __rawmain__ is all about doing the OSA stuff for
> argument emulation.
> 
> Look at Mac/Lib/appletrawmain.py (which is copied to __rawmain__ in
> an applets that wants argv emulation) and argvemulator.py (which does
> the actual work).

Ah, perfect, I hadn't realized that! Very cool. But then I don't  understand
what you meant with your comment about the "__rawmain__ trick" being needed: the
question was whether it is needed in the _actual_ compiled main program, but I
don't see how that could be the case with the execve wrapper.

Just

On Tuesday, Nov 19, 2002, at 18:06 Europe/Amsterdam, Just van Rossum 
wrote:
>> Yes, it's added to the resources. Ah, I now see your "The .lproj or
>> individual nibs should then be listed as a resource" sentence. So you
>> want the user to pass the main nib twice, once as a file and once as
>> a name. Hmm, yes, with nibs in ..lprojs I can see the point. Ok, fine
>> with me, but you should probably add a check that the main nib
>> actually exists.
>
> I read your code, and it just picks an arbitrary nib if there are more 
> than one,
> I don't quite understand how you can defend that...

No, not an arbitrary one, it picks the first one you specified. But 
never mind:
let's do this your way (i.e. specify the nib by name, separate from the 
.plist
files).

>> But unfortunately the __rawmain__ trick is needed for one of the most
>> useful applications of an applet: taking a standard unix Python
>> script and turning it into a droplet.
>
> Don't you want to move the argv emulation to Python as well? It's 
> hairy stuff
> and I think we could win a great deal to have it in Python. I really 
> think we
> should strive to use a vanilla main, and the execve wrapper makes it 
> all
> possible.

Let me borrow Guido's time machine .... [POOF] Done!

PythonW uses the normal unix main program (as of 2.3a0, not in 2.2.X). 
And the __rawmain__
is all about doing the OSA stuff for argument emulation.

Look at Mac/Lib/appletrawmain.py (which is copied to __rawmain__ in an 
applets that wants
argv emulation) and argvemulator.py (which does the actual work).
--
- Jack Jansen        <Jac...@or...>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- Emma 
Goldman -

On Wednesday, Nov 20, 2002, at 00:27 Europe/Amsterdam, Just van Rossum 
wrote:
> I'd suggest to install all Mac stuff in 
> <prefix>/lib/python<version>/plat-darwin
> (or /plat-mac if the install procedure allows that).

plat-mac for the stuff that works both on OSX and OS9, which is 
probably most.
plat-mac isn't currently on sys.path for darwin, but we would fix that 
too.

How about bringing this up on python-dev, and then (if people agree) 
submitting the
sourceforge support request? Please have the Mac/Lib subtree *copied* 
to plat-mac,
not moved. We still need it in the original location if we want to do a 
2.2.3 release.
--
- Jack Jansen        <Jac...@or...>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- Emma 
Goldman -

On Wednesday, Nov 20, 2002, at 12:21 Europe/Amsterdam, tmk wrote:
> That said, I trust the fact that Jack may have very good reasons to 
> favor the framework install option instead. When you can spare the 
> time Jack inquiring minds want to know :-)

As I explained on the pythonmac-sig last month I'm not so sure anymore, 
I would like to keep both options open for python 2.3, and then we'll 
see which build catches on.

But when people thought I suggested doing away with framework builds 
completely (which I didn't) there was quite a bit of protest. MacCVS 
needs it, for using Python as its scripting language, and the Python 
OSA component needs it.

Note that a non-framework Python with a shared library seems like a 
solution for this it's really only a poor substitute. With a shared 
library approach your python installation cannot be moved around 
anymore (Python itself can handle this, by using its own argv[0] to 
locate the Lib folder, but embedding applications will always use the 
fixed fallback path). Especially if we want binary installers things 
shouldn't depend on a compile-time builtin pathname.
--
- Jack Jansen        <Jac...@or...>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- Emma 
Goldman -

On Thursday, November 21, 2002, at 12:11 AM, Jack Jansen wrote:
> On Wednesday, Nov 20, 2002, at 06:13 Europe/Amsterdam, Peter Montagner 
> wrote:
>>>> 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...
>>
>> I think he's talking about doing the standard "Controller" bit of the 
>> MVC paradigm automagically. There is a lot of stuff that a Controller 
>> class does that is done almost every time and is quite tedious to 
>> program. You're not going to be able to eliminate this repetitive 
>> application logic completely but this could help in making PyObjC a 
>> really easy RAD environment. Of course I probably misread his idea.
>
> That's indeed what I was thinking about.

Well, care to elaborate in that case? It sounds very interesting. Have 
you put much thought into it or were you just throwing it out there as 
a possibility. How do you keep everything synced?

Peter

On Wednesday, Nov 20, 2002, at 08:19 Europe/Amsterdam, Ronald Oussoren 
wrote:
> That said, I'd like to build a module or script to build a template 
> from wrapping yet another Objective-C class library. I don't think it 
> would be usefull to use 'AddressBook = 
> Foundation.Python.GenerateModuleForBundle("AddressBook")' as a 
> replacement for 'import AddressBook'

For this specific case you're right. But if we have the mechanism to 
dynamically create modules (and that's a big "if", considering Bills 
remarks) I think we should go down the dynamic path in stead of the 
static path.

To give you an example: MacPython builds AppleScript modules by parsing 
the AETE resources and generating Python code to handle the objects and 
verbs and such. The fact that this isn't done dynamically means that 
you cannot interface to a new scriptable application without first 
going through the motions of creating the interface modules, while it 
would be much nicer if this was done on the fly. But by now the parsing 
and generation code has become so big and complex that changing it to 
something more dynamic is going to be too much hassle.

> It is already there:
> >>> import objc
> >>> print objc.__version__
> 0.7.1
> >>>

Great!

(BTW: the Official Python Way to say that something is already there is 
to use Guido's time machine. As in
"Version numbers? Good idea. One moment, let me borrow Guido's time 
machine.... [poof]. It's implemented" :-)
--
- Jack Jansen        <Jac...@or...>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- Emma 
Goldman -

On Wednesday, Nov 20, 2002, at 06:13 Europe/Amsterdam, Peter Montagner 
wrote:
>>> 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...
>
> I think he's talking about doing the standard "Controller" bit of the 
> MVC paradigm automagically. There is a lot of stuff that a Controller 
> class does that is done almost every time and is quite tedious to 
> program. You're not going to be able to eliminate this repetitive 
> application logic completely but this could help in making PyObjC a 
> really easy RAD environment. Of course I probably misread his idea.

That's indeed what I was thinking about.
--
- Jack Jansen        <Jac...@or...>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- Emma 
Goldman -

On Wednesday, Nov 20, 2002, at 00:27 Europe/Brussels, Just van Rossum 
wrote:

> bb...@ma... wrote:
>
>> I don't understand the benefits of the framework build.   It requires
>> additional maintenance within the Python source trees and doesn't seem
>> to add any capabilities that couldn't be done with a 'regular' build 
>> of
>> Python?   I would think there is a tremendous amount of value in
>> eliminating the number of differences between the build of Python on
>> one platform vs. others.  Certainly, the Mac platform warrants the 
>> slew
>> of Mac specific modules that are in their, but modules build 
>> relatively
>> cleanly without requiring changes to and ongoing maintenance of
>> configure.in....
>
> Hear, hear and hear.
>
> I'd suggest to install all Mac stuff in 
> <prefix>/lib/python<version>/plat-darwin
> (or /plat-mac if the install procedure allows that).

Same here. I was originally a supporter of the framework install. But 
after bbum's excellent arguments in favor of a standard  I can't see 
any advantages in having the official (Apple or not) python install 
being a framework install.

Plus, it seems that even Apple is moving away from framework install 
for OSS type software (Perl, tcl used to be packaged (at least 
partially) as frameworks in Rhapsody and later on).

And last, the many scars I got from trying to build (MachoPython) 
python from source on Mac OS X "non-standard" unix (starting way back 
on Rhapsody and Mac OS X Developper and Preview Releases have made me a 
strong supporter of standards when available ;-). That and the time it 
took to have Python build from source on Mac OS X without one having to 
hack on it.

That said, I trust the fact that Jack may have very good reasons to 
favor the framework install option instead. When you can spare the time 
Jack inquiring minds want to know :-)

Just my .02 euros

= tmk =

>
> Just
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: To learn the basics of securing
> your web site with SSL, click here to get a FREE TRIAL of a Thawte
> Server Certificate: http://www.gothawte.com/rd524.html
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>

2000	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec (9)
2001	Jan (1)	Feb (2)	Mar (3)	Apr (30)	May (18)	Jun	Jul (4)	Aug	Sep	Oct	Nov	Dec
2002	Jan (7)	Feb (2)	Mar (1)	Apr	May	Jun (3)	Jul (13)	Aug	Sep (23)	Oct (180)	Nov (291)	Dec (95)
2003	Jan (338)	Feb (352)	Mar (97)	Apr (46)	May (226)	Jun (184)	Jul (145)	Aug (141)	Sep (69)	Oct (161)	Nov (96)	Dec (90)
2004	Jan (66)	Feb (87)	Mar (98)	Apr (132)	May (115)	Jun (68)	Jul (150)	Aug (92)	Sep (59)	Oct (52)	Nov (17)	Dec (75)
2005	Jan (84)	Feb (191)	Mar (133)	Apr (114)	May (158)	Jun (185)	Jul (62)	Aug (28)	Sep (36)	Oct (88)	Nov (65)	Dec (43)
2006	Jan (85)	Feb (62)	Mar (92)	Apr (75)	May (68)	Jun (101)	Jul (73)	Aug (37)	Sep (91)	Oct (65)	Nov (30)	Dec (39)
2007	Jan (24)	Feb (28)	Mar (10)	Apr (2)	May (18)	Jun (16)	Jul (21)	Aug (6)	Sep (30)	Oct (31)	Nov (153)	Dec (31)
2008	Jan (63)	Feb (70)	Mar (47)	Apr (24)	May (59)	Jun (22)	Jul (12)	Aug (7)	Sep (14)	Oct (26)	Nov (5)	Dec (5)
2009	Jan (10)	Feb (41)	Mar (70)	Apr (88)	May (49)	Jun (62)	Jul (34)	Aug (15)	Sep (55)	Oct (40)	Nov (67)	Dec (21)
2010	Jan (60)	Feb (17)	Mar (26)	Apr (26)	May (29)	Jun (4)	Jul (21)	Aug (21)	Sep (10)	Oct (12)	Nov (3)	Dec (19)
2011	Jan (3)	Feb (13)	Mar (8)	Apr (8)	May (17)	Jun (20)	Jul (21)	Aug (7)	Sep	Oct	Nov (9)	Dec (11)
2012	Jan (3)	Feb	Mar	Apr (5)	May (4)	Jun (14)	Jul (5)	Aug (2)	Sep (15)	Oct (2)	Nov (23)	Dec (1)
2013	Jan (8)	Feb (1)	Mar	Apr	May (5)	Jun (1)	Jul (5)	Aug (4)	Sep	Oct (12)	Nov (10)	Dec (3)
2014	Jan (7)	Feb (14)	Mar (2)	Apr	May (2)	Jun (11)	Jul (10)	Aug (4)	Sep	Oct (8)	Nov (1)	Dec (2)
2015	Jan (9)	Feb (7)	Mar (1)	Apr	May (7)	Jun	Jul (5)	Aug (6)	Sep	Oct (1)	Nov (4)	Dec
2016	Jan (1)	Feb (1)	Mar (4)	Apr (2)	May (1)	Jun	Jul (6)	Aug (8)	Sep (21)	Oct (17)	Nov	Dec (36)
2017	Jan (6)	Feb (2)	Mar (4)	Apr (2)	May	Jun	Jul (1)	Aug	Sep (1)	Oct	Nov (1)	Dec (6)
2018	Jan (2)	Feb (3)	Mar (3)	Apr (14)	May (2)	Jun (2)	Jul (4)	Aug (3)	Sep (6)	Oct (16)	Nov (1)	Dec (6)
2019	Jan (3)	Feb (1)	Mar	Apr	May	Jun	Jul (2)	Aug	Sep	Oct (6)	Nov	Dec
2020	Jan	Feb	Mar (1)	Apr	May (2)	Jun (1)	Jul (7)	Aug (1)	Sep (1)	Oct	Nov (2)	Dec (1)
2021	Jan (1)	Feb	Mar	Apr	May	Jun (2)	Jul	Aug (5)	Sep (1)	Oct	Nov (1)	Dec
2023	Jan	Feb	Mar	Apr (1)	May	Jun	Jul	Aug	Sep (2)	Oct	Nov	Dec
2025	Jan (2)	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct (1)	Nov	Dec (2)

pyobjc-dev Mailing List for PyObjC (Page 285)

pyobjc-dev — CVS commit notices go here