🌐 Mailman 3 November 1999 - Python-list - python.org

Re: Produce .pyc without execution
by François Pinard Nov. 2, 1999

Nov. 2, 1999

Michael Hudson <mwh21(a)cam.ac.uk> writes: > I think installing .pyc's but not .py's is mischevious, if only > because meaningful tracebacks are nice. We have to be careful in our search for virtue. Richard Stallman always wanted packages to install un-stripped binaries, for reasons like above. The disk space it takes, as well as the principle, is not very acceptable for a lot of users, and Linux packagers defeat it quite systematically, so far that I know. It surely required a lot of doing and many fights (I do know some of them :-) before the thing could be done with more ease than difficulty within GNU, and I've been told that some of the last problems are going to be solved in the next release of Autoconf, if not already. I do not follow this file closely anymore, now, as helping GNU is too exhausting. My opinion is that quality packages should not traceback anyway, and rather produce their own user-oriented diagnostics. The installation process should be oriented more towards users than towards debugging, for anything else than alpha software. Even for Emacs, Linux packagers set things so LISP sources are optional. Oh, no doubt that having sources installed is a good things for many users, but in the long run, we are going to have more and more users who are not especially programmers, or not especially interested in the inner details of everything they use, so we should silence our natural proselytism :-). > > What would be ideal is a way for `compile_dir' to produce `.pyc' in > > the build hierarchy directly from the source hierarchy at `make all' > > time, and that `make install' just move these ready `.pyc' files into > > the installation directories. > It shouldn't be all that hard to adapt Lib/py_compile.py & > Lib/compileall.py as appropriate to effect this. I hope that people responsible for these packages are listening! :-) -- François Pinard http://www.iro.umontreal.ca/~pinard

1 0

Feature request for interactive interpreter
by Bjorn Pettersen Nov. 1, 1999

Nov. 1, 1999

I'm getting tired of typing, so my request for the next version of the interactive interpreter is a "help" function, probably defined as: def help(x): print x.__doc__ (with the appropriate 'no help available' message if the object doesn't have a doc string...) pretty-pleas'ly y'rs --bjorn

3 2

Re: Produce .pyc without execution
by François Pinard Nov. 1, 1999

Nov. 1, 1999

"Adrian Eyre" <a.eyre(a)optichrome.com> writes: > > However, I could not decently propose this scheme for integration in > > Automake, and that makes it a bit unsatisfactory. It would be nicer, > > for example, if `src/*.py' files were recompiled into the `src/' build > > hierarchy from the `src/' distribution hierarchy, and then installed from > > there. But `compileall' wants to install compiled files next to sources > > in the same directory, which is a bit inconvenient. Any simple solution? > This is the default behaviour for Python, and without modifying its source > the .pyc will always be created in the same dir as the source. Can't > you add something like: > install-data-hook: > @echo 'import compileall; compileall.compile_dir("$(pkgdatadir)")' \ > | $(PYTHON); \ > for pyc in $(pkgdatadir)/*.pyc; do mv $$pyc somewhere_else/; done Not really. There are many things to keep in mind for fitting well in the Automake spirit, and these two are a bit more relevant, here: * The distribution hierarchy (by opposition to build hierarchy) should be considered read-only, as if, say, it was already exploded in a CD-ROM; a mere, simple installation should not modify, create or delete files in it; this is only allowed in the build hierarchy. * Many people do `make all' as one user, and `make install' as a different user (`root' or `bin', say), so ideally, all needed files should be prepared in the build hierarchy at `make all' time, `make install' should not create any more files in the build directory, once `make all' has been done. The only files `make install' may create sit in the various installation directories. Above, $(pkgdatadir) is an installation directory, so things are already in their final place, no need to move them further once there. The scheme I used is acceptable when one wants to provide all sources installed with the compiled forms, but some people prefer to keep sources non-installed, just to spare disk space, say. What would be ideal is a way for `compile_dir' to produce `.pyc' in the build hierarchy directly from the source hierarchy at `make all' time, and that `make install' just move these ready `.pyc' files into the installation directories. -- François Pinard http://www.iro.umontreal.ca/~pinard

2 1

Bug in standard cursesmodule?
by Gerrit Holl Nov. 1, 1999

Nov. 1, 1999

Hello, A does not work, B does work! --- *** A *** --- #!/usr/bin/python import curses stdscr = curses.initscr() stdscr.addch(24, 79, ord('X')) stdscr.refresh() curses.endwin() --- *** A *** --- --- *** B *** --- #include <ncurses.h> main () { initscr(); mvaddch(24, 79, 'X'); refresh(); endwin(); } --- *** B *** --- I think it's a bug... Am I right? When I run A, it says: error: [mv]waddstr() returned ERR regards, Gerrit.

1 0

Re: commas vs. spaces. vs. the legions of new lines
by François Pinard Nov. 1, 1999

Nov. 1, 1999

"G. Lewis" <lemiss(a)my-deja.com> writes: > c.l.py has an exellent reputation for being extremely friendly and > helpful---i'm astonished at the general endless patience I've seen > exhibited here, even for the most inane and pathetic newbie FAQs. > Lets keep it! By all means, I agree. I moved to Python from Perl mainly _because_ of the difference in people attitudes, and only learned to really appreciate the language after the fact. My only fear is that Python will grow popular enough so the sad history of c.l.py repeats here, so I hope that Python will spread slowly enough so the spirit gets preserved! :-) > So the unix old-timers <wink> know a billion and one ways to convert Dos > to Unix text files. Why discourage someone from making a pure python > implementation... and a decent attempt at it as well, with subdirectories > and attempts at some sort of "smart" file type guessing. Not a tool I'd > use, myself, but surely it has value. Or even if it didn't, still surely > it does not deserve denegration. Not one person complimented his code. I was one of those who replied to this thread, and feel concerned by your remarks. Yes, I should have acknowledged the effort, at least because I understand what it means, and am sorry for not having done so. On the other hand, to compliment some code, one has to take a look at it, and not being Internet-connected usually (I use UUCP), it requires a special effort on me which I often try to spare. If someone saw denegration in what I said, then I was surely misinterpreted -- as I did not have such feelings, really not. -- François Pinard http://www.iro.umontreal.ca/~pinard

2 1

Ultimate newbie question? How to execute DOS commands via Python.
by Gabe Newcomb Nov. 1, 1999

Nov. 1, 1999

Hi all: My job here at work would be so much easier if I could use Python to run a series of DOS commands (I'd rather do this than write a batch file for a number of reasons). Any pointers/examples on this would extremely helpful! Thanks in advance, Gabe Newcomb

2 1

ANNOUNCE: Free Python Scripts For Blender (export to free renderers)
by Jan Walter Nov. 1, 1999

Nov. 1, 1999

Hi, At http://www.q-bus.de/Blender you can find a web page from which you can download several Python scripts to export to following renderers within Blender (http://www.blender.nl): Panorama (http://www.gnu.org/software/panorama/panorama.html) Povray (http://www.povray.org) Radiance (http://radsite.lbl.gov/radiance/HOME.html) RenderMan (http://www.renderman.org, http://www.bmrt.org) I try to compare this renderers and any comments are welcome ... Cheers, Jan

1 0

Re: Detect file existance before open?
by François Pinard Nov. 1, 1999

Nov. 1, 1999

"Gordon McMillan" <gmcm(a)hypernet.com> writes: > > I would like to check for the existance of a file before I > > attempt an open and maybe throw an exception. > os.path.exists(nm), probably also os.path.isfile(nm). And also os.path.islink(nm), unfortunately. If a symbolic link exists and points to a deleted file, say, os.path.exists returns None. I found out that you need to test both os.path.exists and os.path.islink before assuming the path is free for safe re-use. It is a bit of constant annoyance in some projects, and do not clearly see how Python `os' library could be improved to make this more transparent. I guess we just have to learn to live with this (?) ... -- François Pinard http://www.iro.umontreal.ca/~pinard

1 0

dynamically generating function assignent
by anantk＠my-deja.com Nov. 1, 1999

Nov. 1, 1999

Hi, Here is my problem. I have defined say 12 pairs of functions func_a() parse_func_a() func_b() parse_func_b() . . func_l() parse_func_l() A file contains a series of strings which are the names of these functions eg: a c f b Now for each of these strings I need to call the two functions func_<x>(), and parse_func_<x>(), where <x> is the name of the function that string refers to. I know you can do something like call = func_a, and call effectively gets assigned to func_a. My question is how can I generate the RHS of this assignment dynamically? So that all I have to do is <variable> = <next line in file> call1 = func_<variable> call2 = parse_func_<variable> call1() call2() Any help would be appriciated. Thanks -- Anant anantk(a)yahoo.com Sent via Deja.com http://www.deja.com/ Before you buy.

1 0

Looking for example of calling C++ from Python
by Ephi Dror Nov. 1, 1999

Nov. 1, 1999

Hi All, I am new to python and would like to know if there is any example of how to use C++ classes from Python. Thanks a lot in advance, Ephi.

2 1