[Pythonmac-SIG] Setting the Screen Saver
Is there a way of setting the OS X screen saver using Python? The System Preferences ap looks like it's AppleScript (and hence appscript) drivable, but I can't work out how to make it actually change any settings. I've also found the screen saver plist, but it's binary rather than XML, so I'd rather not go there if I can avoind it. Besides, I don't know if changing the plisty would take immediate effect. Any hints? -- Cheers, Simon B, [EMAIL PROTECTED], http://www.brunningonline.net/simon/blog/ ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Setting the Screen Saver
Simon Brunning wrote: > Is there a way of setting the OS X screen saver using Python? > > The System Preferences ap looks like it's AppleScript (and hence > appscript) drivable, but I can't work out how to make it actually > change any settings. System Preferences' scripting support is rudimentary. You can switch between preference panes, but that's about it. Anything more, you'll need to use GUI Scripting (with the usual caveats about brittleness, etc). has -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] [Numpy-discussion] Packaging numpy with py2app
On 18/07/2006, at 3:15 PM, Bob Ippolito wrote:
>> def check(cmd, mf):
>> m = mf.findNode('matplotlib')
>> if m is None or m.filename is None:
>> return None
>> mf.import_hook('pytz.zoneinfo', m, ['UTC'])
>> return dict(
>> packages = ['matplotlib']
>> )
>>
>> If anyone needs to actual work with the plotting of time-zone
>> relative dates in matplotlib in embedded Cocoa, it'll die.
>> However, the likelihood of this occurring is low, but for future
>> reference for the Googlers of the future; add the time-zones you
>> need to the list in import_hook, ie ['UTC', 'Australia.Sydney'].
>
> If you were actually doing that, you should write the imports
> yourself. The right place to put that metadata is in your code with
> import statements, because that's cross-platform and cross-
> packager. py2exe and cx_Freeze will understand import statements too.
Agreed. I searched through matplotlib and pytz, and found that you
can add a straightforward import of pytz.zoneinfo.UTC rather than
going through a loader function. I will submit as a patch to the
matplotlib developers. I suggest leaving the line in the recipe for a
while at least.
> You can't do that so long as scipy is wholly included with the
> packages option. The packages option does "cp -r" effectively, I'm
> not going to complicate it for this use case. I might accept a
> patch if it wasn't too horrible, but the effort is better spent
> making scipy work in a zip archive.
Agreed, although with the latest version of py2app working out of the
box with the recipes, I'll probably let it slide.
I spent a bit more time looking at matplotlib, and realised I just
need to include the data files (fonts, rc, icons) directory in the
Resources dir in the app. When I did this manually, it worked fine,
since there is code to detect frozen status in the initialisation,
and it searches the Resources dir.
However, I can't figure out how to copy resources in the recipe. It
seems in recipes, you can return in the dict: packages, flatpackages,
filters, loader_files, and prescripts. Could you enlighten me on the
use of each of these?
Regards,
Josh
___
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] Adding resource fork support to tarfile.py
Dear List,I am new to the list and new to python, so please be kind :) I've recently started playing with duplicity (http://duplicity.nongnu.org) and really like the feature set that is offered by the project. However, I am being stung by the thorn in Apple's side; resource forks. duplicity uses a copy of tarfile.py to build the tar archives. And since this file does not call OS X's tar, nor does it have support for resource forks, it will only add data forks to the tar archive.So, I started looking around and found that OS X has a tarfile.py (System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/) as part of the standard python install. This tarfile.py is different from the one distributed by duplicity, and at first I though I would use it in the distribution. However, using this default install shows that it too does not respect resource forks. For example, doing a simple:#!/usr/bin/pythonimport tarfiletar = tarfile.open("sample.tar", "w")for name in ["Arial"]: tar.add(name)tar.close()produces a tar file with only the data fork. The resource fork is lost. In the case of fonts, this is bad.I am currently running 10.4.7 so I know that resource forks are supported in many unix tools such as cp, mv, tar, and others. For example, if I execute a simple tar cf archive.tar Arial, the font is intact upon expansion, tar xvf archive.tar.Also, from searches, there appears to be some level on integration between python and resources forks on the Mac through the use of "import MacOS > from Carbon import Res". From searching the archives I've found some sample code to allow the reading of the contents of a resource fork (thanks to the poster for that). However, I need to make the tarfile library respect the forks as this is how duplicity creates the archive files.Has anyone figured out a way around this limitation in python' tarfile.py library. Admittedly, I generally avoided python so this is a bit foreign to me. Any help or even clarification would be appreciated. I realize that for a person new to the language, this is a tall order. Thanks for your time.Reid___
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] [Numpy-discussion] Packaging numpy with py2app
Josh Marshall wrote: > However, I can't figure out how to copy resources in the recipe. It > seems in recipes, you can return in the dict: packages, flatpackages, > filters, loader_files, and prescripts. Could you enlighten me on the use > of each of these? I wonder what the plan should be for recipes for MPL and the like. As Bob mentioned, perhaps it's best for the developer to find a way to manually include what they want, as there is a LOT of stuff in MPL (and certainly SciPy!) and much of will not be used by a given application. It seems the only way to make a recipe that is useful would be for it to include EVERYTHING. That may not be a bad default, but there should certainly be a way to turn it off if need be. Is there an incantation to turn off a recipe? Also, I got a numpy app to work yesterday by using: packages=['numpy'] That then includes the entire numpy package. That works, but it puts in a lot of stuff I don't need (dft, linear_algebra, etc). Maybe the recipe should include only the core stuff, and let the user add the extra packages, if need be. Or should numpy be fixed so that it doesn't do weird imports? -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [EMAIL PROTECTED] ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] [Numpy-discussion] Packaging numpy with py2app
On Jul 18, 2006, at 3:48 PM, Christopher Barker wrote: > Josh Marshall wrote: >> However, I can't figure out how to copy resources in the recipe. It >> seems in recipes, you can return in the dict: packages, flatpackages, >> filters, loader_files, and prescripts. Could you enlighten me on >> the use >> of each of these? > > I wonder what the plan should be for recipes for MPL and the like. As > Bob mentioned, perhaps it's best for the developer to find a way to > manually include what they want, as there is a LOT of stuff in MPL > (and > certainly SciPy!) and much of will not be used by a given application. > > It seems the only way to make a recipe that is useful would be for > it to > include EVERYTHING. That may not be a bad default, but there should > certainly be a way to turn it off if need be. > > Is there an incantation to turn off a recipe? No > Or should numpy be fixed so that it doesn't do weird imports? bingo. -bob ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Adding resource fork support to tarfile.py
On Jul 18, 2006, at 17:17 , Apple Consultants Network wrote:
Dear List,
I am new to the list and new to python, so please be kind :) I've
recently started playing with duplicity (http://
duplicity.nongnu.org) and really like the feature set that is
offered by the project. However, I am being stung by the thorn in
Apple's side; resource forks. duplicity uses a copy of tarfile.py
to build the tar archives. And since this file does not call OS
X's tar, nor does it have support for resource forks, it will only
add data forks to the tar archive.
So, I started looking around and found that OS X has a tarfile.py
(System/Library/Frameworks/Python.framework/Versions/2.3/lib/
python2.3/) as part of the standard python install. This
tarfile.py is different from the one distributed by duplicity, and
at first I though I would use it in the distribution. However,
using this default install shows that it too does not respect
resource forks. For example, doing a simple:
#!/usr/bin/python
import tarfile
tar = tarfile.open("sample.tar", "w")
for name in ["Arial"]:
tar.add(name)
tar.close()
produces a tar file with only the data fork. The resource fork is
lost. In the case of fonts, this is bad.
You've got to explicitly handle the resource fork yourself. The tar
format (AFAIK) doesn't support any notion of extra metadata or forks
of a file. Tiger's tar fakes it by saving the resource fork as a
separate file with '._' added to the front (e.g., for 'hello.font',
it stores the data fork as 'hello.font', and the resource fork as
'._hello.font').
I've attached two scripts I wrote a while ago that handle the
resource forks in this way.
--
|>|\/|<
/--\
|David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/
|[EMAIL PROTECTED]#!/usr/bin/env python
import os
from os.path import join, getsize
import tarfile
import sys
import fnmatch
def add_files(tar, directory, root_as='', exclude_pats =[]):
def get_arcname(root, name):
if root.startswith(directory):
root = root_as + root[len(directory):]
return join(root, name)
def add_resource_fork(root, name):
rf = join(root, name, 'rsrc')
try:
s = getsize(rf)
except os.error:
pass
else:
if s != 0:
arcname = get_arcname(root, '._' + name)
tfi = tar.gettarinfo(rf, arcname)
fo = open(rf, 'rb')
tfi.type = tarfile.REGTYPE
tfi.size = s
try:
tar.addfile(tfi, fo)
except IOError, e:
print >>sys.stderr, '***%s (%s) %s' % (rf, arcname, e)
fo.close()
def add_file(root, name):
filename = join(root, name)
arcname = get_arcname(root, name)
for expat in exclude_pats:
if fnmatch.fnmatch(arcname, expat):
return False
try:
tar.add(filename, arcname, recursive=False)
except IOError, e:
print >>sys.stderr, '***%s (%s) %s' % (filename, arcname, e)
add_resource_fork(root, name)
return True
for root, dirs, files in os.walk(directory):
print >>sys.stderr, root
rec_dirs = []
for d in dirs:
if add_file(root, d):
rec_dirs.append(d)
dirs[:] = rec_dirs
for name in files:
add_file(root, name)
def main():
rootdir = sys.argv[1]
tfname = sys.argv[2]
expats = sys.argv[3:]
tar = tarfile.open(tfname, "w")
tar.posix=False
add_files(tar, rootdir, exclude_pats=expats)
tar.close()
if __name__ == '__main__':
main()
#!/usr/bin/env python
import os
import tarfile
import sys
def extract_files(tar, directory):
for tfi in tar:
print >>sys.stderr, tfi.name
head, tail = os.path.split(tfi.name)
if tail.startswith('._'):
# resource fork. We're depending on the data fork being
# extracted first, though.
name = tail[2:]
dfname = os.path.join(head, name)
if not os.path.exists(dfname):
fo = open(dfname, 'w')
fo.close()
tfi.name = os.path.join(head, name, 'rsrc')
tar.extract(tfi, directory)
def main():
tfname = sys.argv[1]
dirname = sys.argv[2]
if not os.path.isdir(dirname):
os.mkdir(dirname)
tar = tarfile.open(tfname, 'r')
extract_files(tar)
if __name__ == '__main__':
main()
___
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] [Numpy-discussion] Packaging numpy with py2app
On Jul 18, 2006, at 2:36 PM, Josh Marshall wrote:
> On 18/07/2006, at 3:15 PM, Bob Ippolito wrote:
>>> def check(cmd, mf):
>>> m = mf.findNode('matplotlib')
>>> if m is None or m.filename is None:
>>> return None
>>> mf.import_hook('pytz.zoneinfo', m, ['UTC'])
>>> return dict(
>>> packages = ['matplotlib']
>>> )
>>>
>>> If anyone needs to actual work with the plotting of time-zone
>>> relative dates in matplotlib in embedded Cocoa, it'll die.
>>> However, the likelihood of this occurring is low, but for future
>>> reference for the Googlers of the future; add the time-zones you
>>> need to the list in import_hook, ie ['UTC', 'Australia.Sydney'].
>>
>> If you were actually doing that, you should write the imports
>> yourself. The right place to put that metadata is in your code
>> with import statements, because that's cross-platform and cross-
>> packager. py2exe and cx_Freeze will understand import statements too.
>
> Agreed. I searched through matplotlib and pytz, and found that you
> can add a straightforward import of pytz.zoneinfo.UTC rather than
> going through a loader function. I will submit as a patch to the
> matplotlib developers. I suggest leaving the line in the recipe for
> a while at least.
Yeah, that's fine.
>> You can't do that so long as scipy is wholly included with the
>> packages option. The packages option does "cp -r" effectively, I'm
>> not going to complicate it for this use case. I might accept a
>> patch if it wasn't too horrible, but the effort is better spent
>> making scipy work in a zip archive.
>
> Agreed, although with the latest version of py2app working out of
> the box with the recipes, I'll probably let it slide.
>
> I spent a bit more time looking at matplotlib, and realised I just
> need to include the data files (fonts, rc, icons) directory in the
> Resources dir in the app. When I did this manually, it worked fine,
> since there is code to detect frozen status in the initialisation,
> and it searches the Resources dir.
>
> However, I can't figure out how to copy resources in the recipe. It
> seems in recipes, you can return in the dict: packages,
> flatpackages, filters, loader_files, and prescripts. Could you
> enlighten me on the use of each of these?
The recipe mechanism doesn't allow for it because it doesn't
generally make sense. There are very few packages that can find their
resources in an alternative manner. I'm not totally opposed to adding
another feature to support that use case, but throwing it directly in
the resources dir seems like a bad idea to do automatically from a
recipe. The files should sit under some kind of matplotlib hierarchy.
It would be nicer to see matplotlib just figure out how to make their
app work from a zip... pygame does, and it has fonts and icons.
packages wholly includes a package as-is, outside the zip.
flatpackages doesn't do anything useful, it inserts a false node into
the graph to group "extra_path" packages together. PIL and PyObjC are
the only two projects I can recall doing this. Changing the graph in
such a way has no effect whatsoever, it's merely an aesthetic change
to the graph which can be useful if you're visualizing it.
filters adds a dependency filter.. a function that gets called with
every modulegraph node and decides whether to include it or not.
There are several of these in py2app, but none demonstrated as a
recipe. It usually doesn't make sense to use this in a recipe. See
py2app.filters for examples of filters.
loader_files puts data files *in the zip*
prescripts are code that gets put in the bootstrap. The PIL recipe
has one of these.
-bob
___
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] [Numpy-discussion] Packaging numpy with py2app
Thanks for the info on how the various recipes work, Bob. Very helpful.
On 19/07/2006, at 9:28 AM, Bob Ippolito wrote:
> The recipe mechanism doesn't allow for it because it doesn't
> generally make sense. There are very few packages that can find
> their resources in an alternative manner. I'm not totally opposed
> to adding another feature to support that use case, but throwing it
> directly in the resources dir seems like a bad idea to do
> automatically from a recipe. The files should sit under some kind
> of matplotlib hierarchy. It would be nicer to see matplotlib just
> figure out how to make their app work from a zip... pygame does,
> and it has fonts and icons.
I think matplotlib can access files inside the zip, since it searches
inside the following directories upon startup and is frozen-aware.
MatplotlibEmbedSample.app/Contents/Resources/lib/python2.4/site-
packages.zip/matplotlib/mpl-data
MatplotlibEmbedSample.app/Contents/mpl-data
MatplotlibEmbedSample.app/Contents/Resources/mpl-data
So I have been attempting to put the data files in the zip.
> loader_files puts data files *in the zip*
Indeed it does. When I use the following recipe: (noting that the
recipe's filename can't be "matplotlib.py", I've been using
"matplotlib_recipe.py"):
def check(cmd, mf):
m = mf.findNode('matplotlib')
if m is None or m.filename is None:
return None
import matplotlib, glob, os
mpl_datapath = matplotlib.get_data_path()
mpl_datafilelist = glob.glob(mpl_datapath + r'/*')
# only include individual files from the mpl-data directory
# this should exclude directories, which should only be
Matplotlib.nib
mpl_datafilelist = [mpl_file for mpl_file in mpl_datafilelist
if os.path.isfile(mpl_file)]
mf.import_hook('pytz.zoneinfo', m, ['UTC'])
mf.import_hook('matplotlib.numerix', m, ['random_array'])
return dict(
loader_files = [
('matplotlib', mpl_datafilelist),
],
)
The data files then get put in the matplotlib directory in the zip.
However, matplotlib searches in the mpl-data directory *inside* the
matplotlib directory, as shown in the search paths above.
I have not been able to find a way to include a directory within the
matplotlib directory. If I use
loader_files = [
('matplotlib/mpl-data', mpl_datafilelist),
],
py2app barfs when trying to copy the files since the directory
doesn't exist. Any ideas Bob?
Chris, can you please copy my email when replying to the thread? I'm
getting the digest, so I don't get your messages for quite some time
otherwise.
Christopher Barker wrote:
> I wonder what the plan should be for recipes for MPL and the like.
> As Bob mentioned, perhaps it's best for the developer to find a way
> to manually include what they want, as there is a LOT of stuff in
> MPL (and certainly SciPy!) and much of will not be used by a given
> application.
If we can get numpy and scipy to work without a recipe that just
includes the packages we can definitely do this. The problem here is
not with py2app, but rather with numpy/scipy themselves and their
crazy custom importer which doesn't work with a zipped site-packages.
I am close to getting matplotlib working with a decent non-naive
recipe. This means it'll only include what is being used by the
application.
> It seems the only way to make a recipe that is useful would be for
> it to include EVERYTHING. That may not be a bad default, but there
> should certainly be a way to turn it off if need be.
No, a useful and "proper" recipe just adds the files that are not
referenced directly through imports, ie., data files. This is what I
am doing with matplotlib.
> Also, I got a numpy app to work yesterday by using:
> packages=['numpy']
The recipe I sent out in the zip yesterday did exactly that. Bob has
added it to py2app trunk. There is a similar recipe for scipy and
matplotlib as well. These will do until we get proper ones working.
The packages option does include *everything*, by doing a full copy
of the package. This means that source, documentation, example files,
etc gets included along with the bytecode files.
> That then includes the entire numpy package. That works, but it
> puts in a lot of stuff I don't need (dft, linear_algebra, etc).
> Maybe the recipe should include only the core stuff, and let the
> user add the extra packages, if need be.
AFAICT, this can't really be done. From looking at the numpy
structure, there are subpackages
'testing','core','lib','linalg','dft','random','f2py', which are all
loaded in the numpy __init__.py via the following:
pkgload = PackageLoader()
pkgload('testing','core','lib','linalg','dft','random','f2py',
verbose=NUMPY_IMPORT_VERBOSE,postpone=False)
The doc string for PackageLoader.__call__() says:
>This function is intended to shorten t
Re: [Pythonmac-SIG] [Numpy-discussion] Packaging numpy with py2app
On Jul 18, 2006, at 5:32 PM, Josh Marshall wrote:
> Thanks for the info on how the various recipes work, Bob. Very
> helpful.
>
> On 19/07/2006, at 9:28 AM, Bob Ippolito wrote:
>> The recipe mechanism doesn't allow for it because it doesn't
>> generally make sense. There are very few packages that can find
>> their resources in an alternative manner. I'm not totally opposed
>> to adding another feature to support that use case, but throwing it
>> directly in the resources dir seems like a bad idea to do
>> automatically from a recipe. The files should sit under some kind
>> of matplotlib hierarchy. It would be nicer to see matplotlib just
>> figure out how to make their app work from a zip... pygame does,
>> and it has fonts and icons.
>
> I think matplotlib can access files inside the zip, since it searches
> inside the following directories upon startup and is frozen-aware.
>
> MatplotlibEmbedSample.app/Contents/Resources/lib/python2.4/site-
> packages.zip/matplotlib/mpl-data
> MatplotlibEmbedSample.app/Contents/mpl-data
> MatplotlibEmbedSample.app/Contents/Resources/mpl-data
>
> So I have been attempting to put the data files in the zip.
>
>> loader_files puts data files *in the zip*
>
> Indeed it does. When I use the following recipe: (noting that the
> recipe's filename can't be "matplotlib.py", I've been using
> "matplotlib_recipe.py"):
>
> def check(cmd, mf):
> m = mf.findNode('matplotlib')
> if m is None or m.filename is None:
> return None
>
> import matplotlib, glob, os
> mpl_datapath = matplotlib.get_data_path()
> mpl_datafilelist = glob.glob(mpl_datapath + r'/*')
>
> # only include individual files from the mpl-data directory
> # this should exclude directories, which should only be
> Matplotlib.nib
> mpl_datafilelist = [mpl_file for mpl_file in mpl_datafilelist
> if os.path.isfile(mpl_file)]
>
> mf.import_hook('pytz.zoneinfo', m, ['UTC'])
> mf.import_hook('matplotlib.numerix', m, ['random_array'])
> return dict(
> loader_files = [
> ('matplotlib', mpl_datafilelist),
> ],
> )
>
> The data files then get put in the matplotlib directory in the zip.
> However, matplotlib searches in the mpl-data directory *inside* the
> matplotlib directory, as shown in the search paths above.
>
> I have not been able to find a way to include a directory within the
> matplotlib directory. If I use
> loader_files = [
> ('matplotlib/mpl-data', mpl_datafilelist),
> ],
> py2app barfs when trying to copy the files since the directory
> doesn't exist. Any ideas Bob?
This should work in svn (r13). You can easily run the development
version straight from a svn checkout:
svn co http://svn.pythonmac.org/py2app/py2app/trunk py2app
cd py2app
python setup.py develop
That'll set it up such that the "installed" py2app is actually what's
sitting in your svn checkout. You can make changes without re-
installing or anything.
-bob
___
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] [Numpy-discussion] Packaging numpy with py2app
Thanks for the fix Bob. Unfortunately Matplotlib does not work with zipped data files, after all that. So, we'll leave the recipes as is, as they work for now. I suspect the way forward is to get numpy/Matplotlib/scipy working with setuptools and using pkg_resources to manage the data files. Any thoughts on this? ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] [Numpy-discussion] Packaging numpy with py2app
On Jul 18, 2006, at 7:26 PM, Josh Marshall wrote: > Thanks for the fix Bob. > > Unfortunately Matplotlib does not work with zipped data files, > after all that. So, we'll leave the recipes as is, as they work for > now. > > I suspect the way forward is to get numpy/Matplotlib/scipy working > with setuptools and using pkg_resources to manage the data files. > Any thoughts on this? Yes, that is the way. -bob ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Packaging numpy with py2app
Josh Marshall wrote: > so it seems like the entire purpose of PackageLoader is to make life > difficult for me, just to save a few lines of typing. :) Seriously, > can a numpy developer tell me why PackageLoader is necessary? I can't think of a good reason why it's used in __init__.py the way it is (it used to have postpone=True). If Pearu, who wrote that bit of code, doesn't speak up by Thursday, I'll have it removed in favor of regular imports for the beta. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Packaging numpy with py2app
On Jul 18, 2006, at 9:16 PM, Robert Kern wrote: > Josh Marshall wrote: >> so it seems like the entire purpose of PackageLoader is to make life >> difficult for me, just to save a few lines of typing. :) Seriously, >> can a numpy developer tell me why PackageLoader is necessary? > > I can't think of a good reason why it's used in __init__.py the way > it is (it > used to have postpone=True). If Pearu, who wrote that bit of code, > doesn't speak > up by Thursday, I'll have it removed in favor of regular imports > for the beta. Note that all you need is the bytecode, it doesn't have to actually execute. So you can still use whatever custom import junk if you really want to: def _modulegraph_hints(): import foo You should do it in a dead function instead of "if 0" because dead functions will never be stripped by the compiler but dead code blocks sometimes are. -bob ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
