Re: build a static executable program with python
My app uses Python 2.4 and the Pythonwin GUI (Python MFC wrapper). I build it as a single exe file with everything linked in it. It's a lot smaller than all the DLL's put together. The Python modules are also put into the file as a Win32 resource which contains all the modules bz2 compressed. I gather the required modules the same way as py2exe does (using modulefinder), then I compile them to .pyc files, bundle them all together in one file with some information (like size and name) and than bzip compress the whole file. When the app starts it uncompresses them and init's the PyImport_FrozenModules variable (just like in freeze). So I only have one exe file to ship, which contains everything needed. Right now it's size is 2 MB, but bear in mind that it contains STLport and Crypto++ which are big libraries. It compresses down to under 1 MB. It's not very difficult to do if you have some experience. But you do have to tweak some Python header files (to disable for example the normal link against python24.lib). You are right about the DLL modules. You just compile tham as a static lib and manually call their's their's init function, AND ALSO THE DllMain ONE. The exe file will still export the DLL functions, but you can disable this with some tweaks. Hope that helps. I can guide you through the process if you wish. On Thursday, December 30, 2004 Torsten Mohr wrote: > Hi, > i'd like to build an executable file that is linked with > a python library and executes a script via PyRun_SimpleString > or similar functions. > Is there a static library of python available, so the users > don't need to install python? > What about DLL modules, do i just need to compile them > as a static lib, link them together with my program and > call their init function? > What about python modules, can i just use a tool like > "freeze" or "py2exe" to break up the import hierarchy > and call them before my script? > Is there some more information about building a static > executable available? > Thanks for any hints, > Torsten. -- http://mail.python.org/mailman/listinfo/python-list
Is it ok to type check a boolean argument?
Hello,
Me and my colleagues are having an discussion about the best way to
code a function (more Pythonic).
Here is the offending function:
def find(field, order):
if not isinstance(order, bool):
raise ValueError("order must be a bool")
order_by = "asc" if order else "desc"
return _find(field + "+" + order_by)
We are not sure what's the best practice here. Should we or should we
not check the type of the "order" variable, which should be a bool?
In one of our unit-tests we passed the "invalid_order" string as the
order argument value. No exception was raised, since the string was
evaluated as being True.
We know about "Don't look before we jump", but we are not sure how it
applies in this case, since we don't get any exception when passing an
invalid type argument.
This function is not visible to our clients, only internally in our
project. It's part of the public interface of a sub-system, so we are
not sure either if the fact that it returns an invalid result for a
badly type argument it's an API specification break or not.
The pro argument was that if a new programmer comes and passes a
wrongly typed argument, he will get a silent failure.
The cons argument was that there are many functions which could
silently fail in this mode, especially those having bool arguments.
Should we in general check when doing unit-testing that the methods
behave correctly when passed arguments of the wrong type? What do you
do in your projects?
--
http://mail.python.org/mailman/listinfo/python-list
Re: Is it ok to type check a boolean argument?
On Jan 7, 10:15 pm, Bruno Desthuilliers
wrote:
> This being said, I can only concur with other posters here about the
> very poor naming. As far as I'm concerned, I'd either keep the argument
> as a boolean but rename it "ascending" (and use a default True value),
> or keep the 'order' name but then accept 'asc' and 'desc' as values
> ('asc' being the default).
Well, I lied a bit :-p
The actual function is 20 lines long, and does other stuff to. The
"order" argument is not passed as an argument, but as a field on an
input object. Since I generally don't like it when people post
questions and include gazillions of lines of code, I boiled down the
real function to the one posted above, which is the minimum required
to show our dilemma. "_find" also does not exist in the real code.
You are all right, "order" is a bad name choice. "sort_ascending"
would be a much better name for a boolean variable.
I found Paul's idea very interesting, but I prefer to not introduce
new objects which behave like C enums (maybe that would be more
Pythonic?), so I found this variant:
def find(field, sort_ascending):
order_by = {True: "asc", False: "desc"}
return _find(field + "+" + order_by[sort_ascending])
But what if we can't solve it as ellegantly, and we need to execute
different code depending on the condition:
def find(field, fast_mode=True):
if fast_mode:
do_something(field, 1, DEFAULT_PAGE_SIZE)
else:
do_another_thing(field, False, "xml", ignore_error=False)
and_another_one()
Should we typecheck in this case to ensure that if we pass a string
for "fast_mode" we will raise an exception?
--
http://mail.python.org/mailman/listinfo/python-list
