pyobjc-dev Mailing List for PyObjC (Page 277)
Brought to you by:
ronaldoussoren
You can subscribe to this list here.
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
|
Nov
|
Dec
|
From: Ronald O. <ous...@ci...> - 2003-01-05 17:45:18
|
On Sunday, Jan 5, 2003, at 18:17 Europe/Amsterdam, Mirko Viviani wrote: > Ronald Oussoren <ous...@ci...> ha scritto: > >>> The runtime support, apart for bugs and missing objc_addClass() >>> implementation, >>> should be quit ok, but unfortunately it dumps core: >> You might want to rebuild python with debugging enabled (or at least >> building with '-g'), that makes debugging a lot easier. > > PyObjc was already compiled with -g else I become mad ! :-) > >> The stacktrace doesn't mention PyObjC code, which of course doesn't >> help in finding the problem :-(. > > I've fixed and now it works. > > I've done a couple of test using lookUpClass() with success but when I > run > the tests it fails to lookup the classes: > > [mirko@rey] /usr/home/mirko/src/gnustep/pyobjc> Scripts/runalltests > -- Running 'Lib/Foundation/test/test_nsarray.py' > EEEEEEEEE > ====================================================================== > ERROR: testContains (__main__.TestNSArrayInteraction) > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "Lib/Foundation/test/test_nsarray.py", line 19, in testContains > x = NSArray.arrayWithArray_( ["foo", "bar", "baz"] ) > NameError: global name 'NSArray' is not defined > This is probably a problem in Modules/objc/class-list.m:ObjC_GetClassList. As the comment above the GNUstep version indicates that the GNUstep is mostly a placeholder. Ronald |
From: Mirko V. <mi...@ob...> - 2003-01-05 17:17:42
|
Ronald Oussoren <ous...@ci...> ha scritto: > > The runtime support, apart for bugs and missing objc_addClass() > > implementation, > > should be quit ok, but unfortunately it dumps core: > You might want to rebuild python with debugging enabled (or at least > building with '-g'), that makes debugging a lot easier. PyObjc was already compiled with -g else I become mad ! :-) > The stacktrace doesn't mention PyObjC code, which of course doesn't > help in finding the problem :-(. I've fixed and now it works. I've done a couple of test using lookUpClass() with success but when I run the tests it fails to lookup the classes: [mirko@rey] /usr/home/mirko/src/gnustep/pyobjc> Scripts/runalltests -- Running 'Lib/Foundation/test/test_nsarray.py' EEEEEEEEE ====================================================================== ERROR: testContains (__main__.TestNSArrayInteraction) ---------------------------------------------------------------------- Traceback (most recent call last): File "Lib/Foundation/test/test_nsarray.py", line 19, in testContains x = NSArray.arrayWithArray_( ["foo", "bar", "baz"] ) NameError: global name 'NSArray' is not defined ====================================================================== ERROR: testIn (__main__.TestNSArrayInteraction) ---------------------------------------------------------------------- Traceback (most recent call last): File "Lib/Foundation/test/test_nsarray.py", line 30, in testIn x = NSMutableArray.array() NameError: global name 'NSMutableArray' is not defined How to check ? Thanks. -- Ciao Mirko |
From: Ronald O. <ous...@ci...> - 2003-01-05 16:07:38
|
On Sunday, Jan 5, 2003, at 05:56 Europe/Amsterdam, Bill Bumgarner wrote: > > The real problem is that something created via array.array() comes > back as an object that behaves differently. Clearly, a bug in my > bridge code, yes, but raises a question: > > What should I be using? > > From the python side, it appears to only be possible to create buffer > style objects-- big byte bags-- via the array module [yes a <str> will > work, but a byte-array seems so much more correct]. On the C side, it > seems that the only way to create a byte buffer like object is to use > the PyBuffer* API. You could use the array module on the C side. That is more work than just using the PyBuffer API but would solve your problem. <advocate style=devil> However, what if I raw strings into the API. If I get array objects back from the API there still is an inconsistency. </advocate> I agree that array objects are more suitable for 'bags of bytes' than the (builtin) alternatives. Note that some people seem to use Numeric python for image processing (http://www.pfdubois.com/numpy/). Adding support for using numeric arrays instead of array.array might be a usefull extension, but probably more as an item on the TODO list than something to implement right now. All things considered I'd go for using array.array from C, with a fallback to the PyBuffer API when you cannot import the array module. Ronald |
From: Bill B. <bb...@co...> - 2003-01-05 15:27:44
|
I'm in the process of bridging various methods in PyObjC that take (void *) types as arguments or return (void *) buffer references. On the C side of the fence, I'm using PyBuffer_FromReadWriteMemory() or PyBuffer_FromMemory() as appropriate to create the buffer. On the Python side, I use array.array('B') to create the buffer that is passed across the bridge and mapped to the (void *) method arguments. However, I noticed that the two types are not the same. They both work as byte buffers just fine, but the result of PyBuffer*() acts as, basically, a big <str> on the Python side whereas array.array('B') is a buffer of specifically typed unsigned chars. In writing the unit tests, I came across a problematic situation that could easily arise in code (feel free to comment on the silliness of this code, if any... and note that I'm using the comprehension style even after that long rant I posted earlier :-): singlePlane = array.array('B') singlePlane.fromlist([0 for x in range(0, width*height*3)] ) for i in range(0, 256*256): si = i * 3 singlePlane[si] = rPlane[i] singlePlane[si+1] = gPlane[i] singlePlane[si+2] = bPlane[i] i2 = ... create i2 using data in singlePlane ... .... then ... bitmapData = i2.bitmapData() self.assertEquals(len(bitmapData), len(singlePlane)) for i in range(0,100): self.assertEquals(bitmapData[i], singlePlane[i], "bitmapData and singlePlane differ at byte %d" % i) The contents of singlePlane and bitmapData are identical, but the unit test fails: <type 'str'> -- type of element 0 of bitmapData <type 'int'> -- type of element 0 of singlePlane F. ====================================================================== FAIL: testImageData (__main__.TestNSBitmapImageRep) ---------------------------------------------------------------------- Traceback (most recent call last): File "Lib/AppKit/test/test_nsbitmapimagerep.py", line 74, in testImageData self.assertEquals(bitmapData[i], singlePlane[i], "bitmapData and singlePlane differ at byte %d" % i) File "/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/ unittest.py", line 292, in failUnlessEqual raise self.failureException, \ AssertionError: bitmapData and singlePlane differ at byte 0 ---------------------------------------------------------------------- Ran 2 tests in 1.564s FAILED (failures=1) -- The real problem is that something created via array.array() comes back as an object that behaves differently. Clearly, a bug in my bridge code, yes, but raises a question: What should I be using? From the python side, it appears to only be possible to create buffer style objects-- big byte bags-- via the array module [yes, a <str> will work, but a byte-array seems so much more correct]. On the C side, it seems that the only way to create a byte buffer like object is to use the PyBuffer* API. Advice, please? BTW: All of this lays the foundation for creating a PILImage object in Cocoa that is a seamless part of the NSImage family of classes. I.e. PIL would then be fully integrated into any Cocoa app that can dynamically load the python interpreter (another problem I'm working through). Thanks. b.bum b.bum We gladly feast on those who would subdue us. |
From: Ronald O. <ous...@ci...> - 2003-01-05 14:13:37
|
On Sunday, Jan 5, 2003, at 14:28 Europe/Amsterdam, Mirko Viviani wrote: > Ronald Oussoren <ous...@ci...> ha scritto: > >>> How to proceed ? >> Lot's of ifdefs is not the right solution. The code in class-builder.m >> should use the definitions from objc_support.h instead of the native >> Apple/NexStep definitions. Hopefully this mechanism solves most of >> your >> problems. > > Ok, I've modified all the code to use objc_support. There are yet some > GNU_RUNTIME/GNUSTEP but it is much much better now. > > The runtime support, apart for bugs and missing objc_addClass() > implementation, > should be quit ok, but unfortunately it dumps core: You might want to rebuild python with debugging enabled (or at least building with '-g'), that makes debugging a lot easier. The stacktrace doesn't mention PyObjC code, which of course doesn't help in finding the problem :-(. You may want to add lots of print statements to dictionary.py, to check how far into the script python is crashing. This script doesn't use python subclassing, which rules out problems in class-builder.m. Ronald |
From: Mirko V. <mi...@ob...> - 2003-01-05 13:29:28
|
Ronald Oussoren <ous...@ci...> ha scritto: > > How to proceed ? > Lot's of ifdefs is not the right solution. The code in class-builder.m > should use the definitions from objc_support.h instead of the native > Apple/NexStep definitions. Hopefully this mechanism solves most of your > problems. Ok, I've modified all the code to use objc_support. There are yet some GNU_RUNTIME/GNUSTEP but it is much much better now. The runtime support, apart for bugs and missing objc_addClass() implementation, should be quit ok, but unfortunately it dumps core: (gdb) r Starting program: /usr/local/bin/python dictionary.py (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... Deprecated bfd_read called at /usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/dbxread.c line 2627 in elfstab_build_psymtabs Deprecated bfd_read called at /usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/dbxread.c line 933 in fill_symbuf (no debugging symbols found)... Program received signal SIGSEGV, Segmentation fault. 0x805471b in PyObject_Print () (gdb) where #0 0x805471b in PyObject_Print () #1 0x80a4dce in PyFile_WriteObject () #2 0x8070230 in PyEval_EvalCode () #3 0x807246c in PyEval_EvalCodeEx () #4 0x806ee79 in PyEval_EvalCode () #5 0x8089117 in PyRun_FileExFlags () #6 0x80890d2 in PyRun_FileExFlags () #7 0x80890a6 in PyRun_FileExFlags () #8 0x8088438 in PyRun_SimpleFileExFlags () #9 0x8087f54 in PyRun_AnyFileExFlags () #10 0x8052c59 in Py_Main () #11 0x8052570 in main () #12 0x80524cb in _start () It prints correctly the class returned by objc.lookUpClass() but it hangs when it try to print the object. Any hints where should I start looking ? Thanks. > BTW. I noticed GNUstep has a build-option for using a > garbage-collector. Using that option might cause problems with > subclassing Objective-C classes from Python, the current code depends > on reference-counts in both Python and Objective-C to detect if objects > are alive. I know, but I've never used it and it seems to remember that is a bit untested. -- Ciao Mirko |
From: Ronald O. <ous...@ci...> - 2003-01-04 18:19:42
|
On Saturday, Jan 4, 2003, at 18:51 Europe/Amsterdam, Mirko Viviani wrote: > Ronald Oussoren <ous...@ci...> ha scritto: > >> Sure, especially given the name-clash your having. I've renamed >> objc_error to ObjCExc_error. > > Ok, thanks. > > I've modified some things in class-builder.m (see attach) but as you > can see > the source loose readability. > > How to proceed ? Lot's of ifdefs is not the right solution. The code in class-builder.m should use the definitions from objc_support.h instead of the native Apple/NexStep definitions. Hopefully this mechanism solves most of your problems. BTW. I noticed GNUstep has a build-option for using a garbage-collector. Using that option might cause problems with subclassing Objective-C classes from Python, the current code depends on reference-counts in both Python and Objective-C to detect if objects are alive. Ronald |
From: Ronald O. <ous...@ci...> - 2003-01-04 17:53:49
|
On Saturday, Jan 4, 2003, at 17:12 Europe/Amsterdam, Jack Jansen wrote: > > On zaterdag, jan 4, 2003, at 13:42 Europe/Amsterdam, Ronald Oussoren > wrote: > >> >> On Saturday, Jan 4, 2003, at 10:42 Europe/Amsterdam, Mirko Viviani >> wrote: >> >>> Ciao! >>> >>> I'm trying to get pyobjc working on gnustep... I don't know the >>> pyobjc internals >>> yet but should it be possible to rename objc_error to something else >>> ? >> Sure, especially given the name-clash your having. I've renamed >> objc_error to ObjCExc_error. > > Why not make all externally visible symbols (at the C level, I'm not > talking about Python here) start with "pyobjc_" or some such? We currently use 'OC_' as the prefix on Objective-C class names (such as OC_PythonArray) and ObjC as the prefix on most newer C code (objc_error was one of the exceptions). Older code uses no prefix or 'objc_' as the prefix. I agree that it would be wise to use a prefix on all externally visible symbols. We could use either 'OC', 'ObjC' or 'PyObjC', with mixed case identifiers. Now that I've put some more thought in it I think that PyObjC would be the best choice because it is highly unlike that anyone else uses this prefix. I initialy choose ObjC because it was already in use (ObjCPointer is a surviving example of this) and because the 'Py' prefix is claimed by Python. Summary of my proposal: Use the same naming scheme as the Python core, but using 'PyObjC' instead of 'Py' (see also PEP 7 at http://www.python.org/peps/pep-0007.html) I'll write a coding style document for PyObjC that mentions this. If everyone agrees we can then rename all externally visible symbols, preferably only once. Ronald |
From: Mirko V. <mi...@ob...> - 2003-01-04 17:51:43
|
Ronald Oussoren <ous...@ci...> ha scritto: > Sure, especially given the name-clash your having. I've renamed > objc_error to ObjCExc_error. Ok, thanks. I've modified some things in class-builder.m (see attach) but as you can see the source loose readability. How to proceed ? I think we can use a rename Method and IVar to something different and use a typedef for gnu/next. I've implemented a couple of missing runtime function in objc_support.m but how to do with the one with different names ? (ie class_get_instance_method/class_getInstanceMethod) Use the GNU_RUNTIME switch or a function wrapper ? -- Ciao Mirko |
From: Jack J. <Jac...@or...> - 2003-01-04 16:12:47
|
On zaterdag, jan 4, 2003, at 13:42 Europe/Amsterdam, Ronald Oussoren wrote: > > On Saturday, Jan 4, 2003, at 10:42 Europe/Amsterdam, Mirko Viviani > wrote: > >> Ciao! >> >> I'm trying to get pyobjc working on gnustep... I don't know the >> pyobjc internals >> yet but should it be possible to rename objc_error to something else ? > Sure, especially given the name-clash your having. I've renamed > objc_error to ObjCExc_error. Why not make all externally visible symbols (at the C level, I'm not talking about Python here) start with "pyobjc_" or some such? -- - 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 - |
From: Bill B. <bb...@co...> - 2003-01-04 14:38:13
|
NSBitmapImageRep can now be used from PyObjC. ObjCPointer probably should go away as the methods used for NSData and NSBIR seem to work really well. The support for NSData and NSBIR is currently incomplete, but they are usable. See the unit test for example usage. The NSBIR unit test needs to be fixed as it currently writes files to /tmp/ and shouldn't. b.bum |
From: Ronald O. <ous...@ci...> - 2003-01-04 12:43:36
|
On Saturday, Jan 4, 2003, at 10:42 Europe/Amsterdam, Mirko Viviani wrote: > Ciao! > > I'm trying to get pyobjc working on gnustep... I don't know the pyobjc > internals > yet but should it be possible to rename objc_error to something else ? Sure, especially given the name-clash your having. I've renamed objc_error to ObjCExc_error. Ronald |
From: Lele G. <le...@se...> - 2003-01-04 11:30:17
|
>>>>> On Sat, 4 Jan 2003 09:42:55 -0000, "Mirko Viviani" <mi...@ob...> said: MV> Ciao! I'm trying to get pyobjc working on gnustep... I don't MV> know the pyobjc internals yet but should it be possible to MV> rename objc_error to something else ? Ciao Mirko! Nice to know this. I'm going to spend some time on it too, but I'm afraid not very soon. Anyway, please, let's keep in touch&sync on this! ciao&grazie, lele. -- nickname: Lele Gaifax | Quando vivro' di quello che ho pensato ieri real: Emanuele Gaifas | comincero' ad aver paura di chi mi copia. email: le...@se... | -- Fortunato Depero, 1929. |
From: Mirko V. <mi...@ob...> - 2003-01-04 09:43:14
|
Ciao! I'm trying to get pyobjc working on gnustep... I don't know the pyobjc internals yet but should it be possible to rename objc_error to something else ? extern void objc_error(id object, int code, const char* fmt, ...); extern void objc_verror(id object, int code, const char* fmt, va_list ap); building 'objc._objc' extension cc -DNDEBUG -O2 -s -pipe -D_THREAD_SAFE -fPIC -I/usr/local/include/python2.2 -c Modules/objc/objc_util.m -o build/temp.freebsd-4.7-PRERELEASE-i386-2.2/objc_util.o -DOBJC_PARANOIA_MODE -DPyOBJC_UNIQUE_PROXY -DGNU_RUNTIME -Wno-import -I/usr/local/GNUstep/System/Headers -I/usr/local/GNUstep/System/Headers/gnustep -I/usr/local/GNUstep/System/Headers/ix86/freebsd Modules/objc/objc_util.m:12: `objc_error' redeclared as different kind of symbol /usr/local/GNUstep/System/Headers/objc/objc-api.h:100: previous declaration of `objc_error' Modules/objc/objc_util.m: In function `ObjC_UpdateConvenienceMethods': Modules/objc/objc_util.m:301: warning: comparison of distinct pointer types lacks a cast error: command 'cc' failed with exit status 1 -- Ciao Mirko |
From: Bill B. <bb...@co...> - 2003-01-03 21:38:55
|
Ronald-- I apologize in advance. My intentions were good, the end result really doesn't improve the situation all that much [but doesn't make it any worse]. I started down the path of restructuring the various ObjC_RegisterMethods invocations into their own files that are compiled via setup.py directly (as opposed to being included into the main mapping.m file). I lost. Static declarations defeated me. But, things are more separated out now than before and, most importantly, NSData no longer crashes with large buffers-- I don't know why, but I'm happy that the unit tests pass. I'm going to add NSBitmapImageRep support next. b.bum |
From: Guido v. R. <gu...@py...> - 2003-01-03 16:38:13
|
> There's a discussion over on the pyobjc developers mailing list at the > moment about the use of __all__. > > Some people suggested that for a certain module we only put "often > used" items in __all__, so that "from module import *" will import only > these commonly used items into your namespace. The module would contain > other items which *are* useful and which should be callable from the > outside, but these would have to be explicitly imported into your > namespace (or used via "import objc; objc.SetVerbose()". > > This doesn't feel right to me, as I've always used __all__ to mean "the > whole externally visible API", and I've considered anything else that > the module exports basically an artefact of the implementation. But > when I looked this up in the reference manual it is rather vague about > this. > > Any opinions on the matter? __all__ should contain the entire public API. It's mostly intended to avoid accidentally exporting other things you've *imported* like os, sys, and other library modules. Another way of doing that would be to write e.g. import sys as _sys but I don't like excessive underscoring. --Guido van Rossum (home page: http://www.python.org/~guido/) |
From: Skip M. <sk...@po...> - 2003-01-03 16:19:52
|
Jack> This doesn't feel right to me, as I've always used __all__ to mean Jack> "the whole externally visible API", and I've considered anything Jack> else that the module exports basically an artefact of the Jack> implementation. But when I looked this up in the reference manual Jack> it is rather vague about this. I believe you are correct. If it's in the external API and is (or should be) documented, it belongs in __all__. Skip |
From: <ba...@py...> - 2003-01-03 16:15:10
|
>>>>> "JJ" == Jack Jansen <Jac...@cw...> writes: JJ> Some people suggested that for a certain module we only put JJ> "often used" items in __all__, so that "from module import *" JJ> will import only these commonly used items into your JJ> namespace. I hope __all__ isn't just for from-import-* support. If so, maybe we should get rid of most of them in the ongoing quest to actively discourage from-import-* (or better yet, set them to the empty list). -Barry |
From: Jack J. <Jac...@cw...> - 2003-01-03 16:04:23
|
There's a discussion over on the pyobjc developers mailing list at the moment about the use of __all__. Some people suggested that for a certain module we only put "often used" items in __all__, so that "from module import *" will import only these commonly used items into your namespace. The module would contain other items which *are* useful and which should be callable from the outside, but these would have to be explicitly imported into your namespace (or used via "import objc; objc.SetVerbose()". This doesn't feel right to me, as I've always used __all__ to mean "the whole externally visible API", and I've considered anything else that the module exports basically an artefact of the implementation. But when I looked this up in the reference manual it is rather vague about this. Any opinions on the matter? -- Jack Jansen, <Jac...@cw...>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman |
From: Lele G. <le...@se...> - 2003-01-03 14:59:29
|
>>>>> On Fri, 3 Jan 2003 13:14:00 +0100, Jack Jansen <Jac...@cw...> said: JJ> On Friday, Jan 3, 2003, at 07:54 Europe/Amsterdam, Ronald JJ> Oussoren wrote: >> We could define __all__ in objc/__init__.py: >> >> __all__ = [ 'YES', 'NO', 'IBAction', 'IBOutlet' ] >> >> That would make it possible to do 'from objc import *' for >> accessing often used 'end-user' functionality, while keeping >> the namespace > clean. JJ> I think this is too magic. People expect "from xxx import *" JJ> to really import everything that is remotely useful. Uh? That syntax is deprecated since the BigBang. To be remotely useful, one has to know about it, and thus the "correct" form is to explicit its name. The "__all__" magic is to allow *the*developer* to export major "entry points" of the module, for lazy on-the-fly imports... JJ> My vote would be for the {py}objc_ prefix to the methods, even JJ> though you then have to type objc.pyobjc_setVerbose() if you JJ> "import objc". Again with the same reasoning as last time: it JJ> communicates to the reader that it's useless to try and look JJ> up this function in Apple's documentation. I'm with Ronald here: adding another prefix does not bring significant information, that by the way could be better explained by setVerbose.__doc__. ciao, lele. -- nickname: Lele Gaifax | Quando vivro' di quello che ho pensato ieri real: Emanuele Gaifas | comincero' ad aver paura di chi mi copia. email: le...@se... | -- Fortunato Depero, 1929. |
From: Bill B. <bb...@co...> - 2003-01-03 14:06:14
|
I figured out how to deal w/(void *) in the context of NSData. It is simply a matter of using Ronald's most excellent method bridging mechanism to create a bridge for the various methods that convert void* into bufferobjects and vice-versa. I am committing working code -- see unit test. Working, with caveats. It spews a warning because I have *no clue* what to do for calls to super and because the code may not actually be working (additional unit tests appreciated). Also, note that -initWithBytes:length: fails for larger hunks o' data. Probably alloc hack related???? [bumbox:~/bbum-developer/sourceforge/pyobjc] bbum% python Python 2.2 (#1, 07/14/02, 23:25:09) [GCC Apple cpp-precomp 6.14] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> from Foundation import NSData >>> def newData(s): ... return NSData.alloc().initWithBytes_length_(s, len(s)) ... >>> newData("asdfasdf") <61736466 61736466 > >>> newData("asdfasdfasdfasdfasdfasdf") <61736466 61736466 61736466 61736466 61736466 61736466 > >>> newData("asdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasdfasd fasdfasdfasdfasdfasdfasdf") Segmentation fault In any case, this lays the foundation for fully supporting NSBitmapImageRep and anything else that uses pointers to big hunks of memory-- whether or not that memory is generated within Cocoa or within Python can be made irrelevant outside of the normal lifespan issues. b.bum |
From: Jack J. <Jac...@cw...> - 2003-01-03 13:30:51
|
On Friday, Jan 3, 2003, at 07:54 Europe/Amsterdam, Ronald Oussoren wrote: > We could define __all__ in objc/__init__.py: > > __all__ = [ 'YES', 'NO', 'IBAction', 'IBOutlet' ] > > That would make it possible to do 'from objc import *' for accessing > often used 'end-user' functionality, while keeping the namespace > clean. I think this is too magic. People expect "from xxx import *" to really import everything that is remotely useful. My vote would be for the {py}objc_ prefix to the methods, even though you then have to type objc.pyobjc_setVerbose() if you "import objc". Again with the same reasoning as last time: it communicates to the reader that it's useless to try and look up this function in Apple's documentation. -- Jack Jansen, <Jac...@cw...>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman |
From: Jack J. <Jac...@cw...> - 2003-01-03 13:15:21
|
My preference for the implementation of the various "magic" bits for accessing class methods, unbound instance methods, etc. would be to use methods and class methods (Python methods and Python class methods) on the ancestor of all objects (the NSObject bridge object?). This would give us class.pyobjc_getClassMethod("pythonicname"), class.pyobjc_getUnboundMethod("pythonicname") and instance.pyobjc_getBoundMethod("pythonicname"). Aside from attribute access and such, instance.pyobjc_getBoundMethod("pythonicname") should be equivalent to instance.pythonicname. class.pythonicname would become equivalent to try: return instance.pyobjc_getClassMethod("pythonicname") except AttributeError: return instance.pyobjc_getUnboundMethod("pythonicname") Or, if we add a second "default" parameter to all the _get methods, return instance.pyobjc_getClassMethod("pythonicname", None) or instance.pyobjc_getUnboundMethod("pythonicname") -- Jack Jansen, <Jac...@cw...>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman |
From: Ronald O. <ous...@ci...> - 2003-01-03 06:55:23
|
On Thursday, Jan 2, 2003, at 22:16 Europe/Amsterdam, Bill Bumgarner wrote: > On Thursday, Jan 2, 2003, at 14:11 US/Eastern, Ronald Oussoren wrote: >> Don't do that then ;-) I really mean that, the objc module is meant >> to be used with 'import objc' instead of 'from objc import *'. > > OK -- then, it is... > > import objc > from objc import YES, NO > > ... for me, anyway. We could define __all__ in objc/__init__.py: __all__ = [ 'YES', 'NO', 'IBAction', 'IBOutlet' ] That would make it possible to do 'from objc import *' for accessing often used 'end-user' functionality, while keeping the namespace clean. Ronald |
From: Bill B. <bb...@co...> - 2003-01-02 21:39:49
|
On Thursday, Jan 2, 2003, at 16:35 US/Eastern, Just van Rossum wrote: > Bill Bumgarner wrote: >> import objc >> from objc import YES, NO >> >> .... for me, anyway. > Can't Python's True and False (in 2.3 at least) be mapped to YES and > NO? Yes. And 1,0 work fine, as well, it seems. As of 10.2 (I believe), ObjC actually identifies (BOOL) as something separate from (char) in the method signatures. This will be an issue for the GnuStep folks unless that has been propagated back to GNU (it may have). b.bum |