We've just been having a discussion on the Cython list
about implementing the __init__ file of a package as
an extension module.
It turns out that just putting an __init__.so file
in a directory isn't enough to make Python recognise
it as a package.
However, if there is both an __init__.py and an
__init__.so, it's recognised as a package, and the
__init__.so gets loaded. So it's possible, but only
by exploiting some undocumented and probably accidental
behaviour.
So how about officially recognising an __init__.so
file as a package main file?
--
Greg
Problem: You have a package containing a large number of
classes, of which only a few are typically used by any
given application.
If you put each class into its own submodule, then
client code is required to use a lot of tedious
'from foo.thingy import Thingy' statements to import
the classes it wants to use. This also makes all the
submodule names part of the API and makes it hard to
rearrange the packaging without breaking code.
If you try to flatten the namespace by importing all
the classes into the top level module, you end up
importing everything even if it won't be used.
What's needed is a way of lazily importing them, so
that the import won't actually happen unless the
imported names are referenced.
It's possible to hack something like that up now, but
then tools such as py2app and py2exe, that try to find
modules by statically examining the source looking for
import statements, won't be able to accurately determine
which modules are used. At best they'll think the
whole package is used and incorporate all of it; at
worst they'll miss it altogether.
So I think it would be good to have a dedicated syntax
for lazy imports, so the top-level foo package can say
something like
from foo.thing lazily import Thing
from foo.stuff lazily import Stuff
...
Executing a lazy import statement adds an entry to a
list of deferred imports attached to the module. Then,
the first time the imported name is referenced, the
import is performed and the name becomes an ordinary
attribute thereafter.
If py2exe et al are taught about lazy imports, they
will then be able to determine exactly which submodules
are used by an application and exclude the rest.
--
Greg
I'd like to float the idea of an addition of a new function to the
Template class (in the string module). I'm a bit of a newbie around
here, though, and uncertain of the proper procedure. Is this the
right mailing list for that, or should I be using python-list instead?
Thanks,
- Joe
I noticed a minimalistic pytoncore compiled with VS2005 ( eliminating COMDAT and un-used references, optimized for size ) passes the 2Mb of .LIB ( statically linked ). I think that's a lot considering that LUA uses less than 100Kb.
For small game consoles and devices very small RAM and storage would be very good to reduce this size.
thx
__________________________________________________
Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam ¡gratis!
Regístrate ya - http://correo.yahoo.es
I see this code in the python3.0rc1 makebuild_info project for VS2005:
int main(int argc, char*argv[])
{
char command[500] = "cl.exe -c -D_WIN32 -DUSE_DL_EXPORT -D_WINDOWS -DWIN32 -D_WINDLL ";
int do_unlink, result;
if (argc != 2) {
fprintf(stderr, "make_buildinfo $(ConfigurationName)\n");
return EXIT_FAILURE;
}
if (strcmp(argv[1], "Release") == 0) {
strcat_s(command, CMD_SIZE, "-MD ");
}
else if (strcmp(argv[1], "Debug") == 0) {
strcat_s(command, CMD_SIZE, "-D_DEBUG -MDd ");
}
else if (strcmp(argv[1], "ReleaseItanium") == 0) {
strcat_s(command, CMD_SIZE, "-MD /USECL:MS_ITANIUM ");
}
else if (strcmp(argv[1], "ReleaseAMD64") == 0) {
strcat_s(command, CMD_SIZE, "-MD ");
strcat_s(command, CMD_SIZE, "-MD /USECL:MS_OPTERON ");
}
else {
fprintf(stderr, "unsupported configuration %s\n", argv[1]);
return EXIT_FAILURE;
}
I don't think to hardcode the configurations would be a good idea. I went crazy trying to setup a static library(or a custom configuration) and it was difficult to figure things like that... pls fix it, that's not the good way.
__________________________________________________
Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam ¡gratis!
Regístrate ya - http://correo.yahoo.es
Why are we using a 90's mailing list? Why not a modern phpBB web forum?
__________________________________________________
Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam ¡gratis!
Regístrate ya - http://correo.yahoo.es
>I see project files for VS6, VC7.1 and VS8 in the directory
>http://svn.python.org/projects/python/trunk/PC/ :)
But the Solution files(.SLN) in the PC folder are just for VS2008.
__________________________________________________
Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam ¡gratis!
Regístrate ya - http://correo.yahoo.es
And btw, to build static libraries is a nightmare :P
You must add Debug_Static and Relese_Static configurations too.
__________________________________________________
Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam ¡gratis!
Regístrate ya - http://correo.yahoo.es
Now that 3.x fixes the arbitrary object comparison wart and drops (?)
__cmp__, it seems it's a good time to do something with the missing rich
comparators gotcha, e.g. given a class that defines __eq__ and __lt__,
automatically provide the rest missing comparisons. Yes, it can be done with
a custom metaclass or (in 2.6+) with a class decorator [1] but (a) 99% of
the time that's what one expects so "explicit is better than implicit"
doesn't count and (b) a bulitin implementation might well be more efficient.
There might be arguments why this would be a bad idea but I really can't
think of any.
George
[1] http://www.voidspace.org.uk/python/weblog/arch_d7_2008_10_04.shtml
