My favorites | Sign in
Project Home Downloads Wiki Issues Source
New issue   Search
for
  Advanced search   Search tips   Subscriptions
Issue 39: Support compiling of local unknown python modules
3 people starred this issue and may be notified of changes. Back to list
Status:  Duplicate
Owner:  ----
Closed:  Oct 2010


Sign in to add a comment
 
Project Member Reported by thomas.s...@gmail.com, Aug 23, 2009
If shedskin currently does not support an unknown python module, it exits
with "module not found".

With this patch, it tries to copy the module in a subdir "genmod" and tries
to compile it there. After that we can add this directory in the Makefile
so the programm can fetch the new module.cpp/.hpp from there.

The reason for generating "genmod" and not copy it to the lib dir is, that
anything from lib dir should be maintained and shipped by shedskin. But on
an installed system any other user should not be allowed to modify/add
files in this folder. Therefore this patch keeps anything in the local
folder in "genmod" (another better name proposal is welcomed^^).

0001-Support-genmod-directory-where-shedskin-get-called.patch
3.1 KB   View   Download
Aug 24, 2009
Project Member #1 mark.duf...@gmail.com
(as discussed per mail:)

this is an interesting thought/patch, and I will try to think about it
more, but for now I'm hesitant to include something like this..

an important reason is that to me it's often a good idea to not
support something until it works well, and generate a clear error
message before then, so the end user has a clear idea what is wrong
and possibly can work around it him/herself.

with this patch, the end result will usually still be failure, but now
with more cryptic error output. and if it typically doesn't lead to
failure for some module, why not just add the module to the shedskin
lib/ dir..?

another reason is that type inference is typically much more difficult
on a full program than on a simplified type model (lib/*.py)..
Status: WontFix
Aug 25, 2009
Project Member #2 thomas.s...@gmail.com
"an important reason is that to me it's often a good idea to not
support something until it works well"

-> I created this issue here for others to be able to test it and further improve it.
If it's closed as WontFix this doesn't help a bit. If you would let it open, anyone
who is interessted in this project will check it out and maybe start working on it.
WontFix is for something considered as nonesence and throwing away…



"with this patch, the end result will usually still be failure, but now
with more cryptic error output"

-> Mostly it will failure, but with a nice error output, easy to understand:
Leaving copyright notice out and running: "shedskin cpp.py"

Trying to compile module textwrap into c++

*ERROR* textwrap.py:77: unicode is not supported
*ERROR* cpp.py:13: module textwrap could not compiled to c++

in cpp.py is "import textwrap" -> SS tries to compile module textwrap as displayed on
console. -> This is failing, because unicode is not supported -> That's why cpp fails
(textwrap coult not compiled).
Not cryptic at all.



"why not just add the module to the shedskin lib/ dir..?"

->(As mentioned in comment 0.): 
Reported by toms...@fedoraproject.org, Aug 23 (2 days ago)

If shedskin currently does not support an unknown python module, it exits
with "module not found".

With this patch, it tries to copy the module in a subdir "genmod" and tries
to compile it there. After that we can add this directory in the Makefile
so the programm can fetch the new module.cpp/.hpp from there.

The reason for generating "genmod" and not copy it to the lib dir is, that
anything from lib dir should be maintained and shipped by shedskin. But on
an installed system any other user should not be allowed to modify/add
files in this folder. Therefore this patch keeps anything in the local
folder in "genmod".
Aug 26, 2009
Project Member #3 mark.duf...@gmail.com
I changed the status to 'new'. will reply to the rest later..
Status: New
Aug 28, 2009
Project Member #4 mark.duf...@gmail.com
>Not cryptic at all.

shedskin may not even finish if the library is large, because of type inference not
completing. or if it encounters some unsupported construct, we'd much rather like to
just tell the user that the module is not supported, rather than 'warning: system
keyboard interrupt is not caught' or similar.. :) also if it compiles you don't want
to let the user test if it really works. imo, it's much better to not support some
unknown library until it actually compiles, it is tested, and there is a smallish
type model that makes compilation of programs that use them (much) easier.. 
Mar 18, 2010
Project Member #5 mark.duf...@gmail.com
(No comment was entered for this change.)
Labels: -Type-Defect -Priority-Medium Type-Enhancement Priority-Low
Oct 27, 2010
Project Member #6 mark.duf...@gmail.com
I merged all standard library issues into issue 106.
Status: Duplicate
Sign in to add a comment

Powered by Google Project Hosting