[issue858809] Use directories from configure rather than hardcoded
Changes by Andy Buckley a...@insectnation.org: -- nosy: +andybuckley ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue858809 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1294959] Problems with /usr/lib64 builds.
Changes by Andy Buckley a...@insectnation.org: -- nosy: +andybuckley ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1294959 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue444582] Finding programs in PATH, addition to os
Andy Buckley a...@insectnation.org added the comment: Personally I think it's a very useful feature: the purpose for running which may not be to get the full path to the executable and then run it, but rather that that path prefix is important for something else. I'm sure when I joined this issue I had some need like that -- after all, as you say, if you just want to run it then there are better ways. In general, once users have a need (for whatever reason) to start firing off subprocesses from their Python scripts, things can get ugly. Providing a portable path search function provides a way to keep one kind of that ugliness inside Python for the cases where it really is needed. As for abuse... well, people will always find a way to abuse bits of the library: I think that's an issue for them, rather than a reason to block this functionality ;) My $0.02, Andy -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue444582 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9080] Provide list prepend method (even though it's not efficient)
New submission from Andy Buckley a...@insectnation.org: I know that Python lists aren't designed for efficient prepending, but sometimes when working with small lists it's exactly what needs to be done (search path lists being a common example). For a programmer aware of the performance issue and having convinced themself that it's not a problem for their use-case, it's a niggle that there is no prepend() function for lists by direct analogy to the commonly-used append(). Writing l = [foo] + l, or something mucky based on l.insert(0, ...) or reverse/append/reverse is annoyingly asymmetric and no more performant. So I suggest that l.append(x) be added to the list interface, with a prominent warning in the documentation that it's not an efficient operation on that type (possibly mention the complexity scaling with list length). I think the role of the interface is to make simple things simple, not to make it difficult to do simple-but-inefficient things that people will do anyway ;) -- components: Library (Lib) messages: 108587 nosy: andybuckley priority: normal severity: normal status: open title: Provide list prepend method (even though it's not efficient) type: feature request versions: Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9080 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9080] Provide list prepend method (even though it's not efficient)
Andy Buckley a...@insectnation.org added the comment: Maybe I just value method symmetry/equivalence higher than the designers when it comes to interface expectations. I've seen several I expected there to be a prepend() method like append() on lists, but there isn't -- what do I do? emails on list archives when searching for info on this, which I think is in itself a hint that the current situation is counter-intuitive. The argument that there are already two ways to do it, so why add a third?, is not bad, but if applied to appending, it would ban the append() method... except that it's already there. Personally, the behaviour of append() is very familiar, while insert(0, ...) is less-used and I always have to explicitly confirm to myself that it isn't going to overwrite the zeroth existing element. Adding a prepend(x) method which just calls insert(0, x) (or calls the same underlying C function) would change nothing in terms of code efficiency -- bad programmers will always write inefficient code, one way or another -- but would make the list API more intuitive and improve code readability: seems to me like the sort of thing that Python is philosophically into ;) Sorry to bring up this issue that I guess has been raised (many times?) before, but I thought I'd have a stab at a convincing case! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9080 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9080] Provide list prepend method (even though it's not efficient)
Andy Buckley a...@insectnation.org added the comment: Still not convinced with the reasoning, I'm afraid, but I certainly agree that modifications to built-ins are not to be made lightly. Using deques, which are far less familiar, is not a particularly natural thing to do for a search path, and of course can't be used with a built-in list to which you might well wish to prepend: sys.path. Personally, I would have no problem with a list pop_front method ;) I understand the connection of API availability and misuse of algorithmically inefficient methods -- for large lists -- but I don't find be inconveniently absent so that users search for an answer and find out about complexity issues a very compelling or Pythonic design aim. But I admit that l.insert(0, x) is not such a hard idiom to learn -- just a bit less syntactically elegant and self-explanatory than I would prefer for a simple task, especially where I've already conciously made the efficiency decision in my choice of container type. But thanks for listening... as mentioned, this can stay here as a reference for further enquiries (I searched for a pre-existing prepend() request before submitting this ticket, of course!) and I'll go visit python-ideas. Cheers! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9080 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4256] optparse: provide a simple way to get a programmatically useful list of options
Andy Buckley a...@insectnation.org added the comment: The backward compatible solution is to have --help-options disabled by default, and ask people to enable it with add_interface=True. Or to add the option just before arg parsing, if it has not already been defined? Thanks for the patches, Filip! Andy -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4256 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4256] optparse: provide a simple way to get a programmatically useful list of options
Andy Buckley a...@insectnation.org added the comment:
Thanks for the pointers to both of these... I wasn't aware of either. I see
argparse has been recently approved for Python stdlib inclusion, too:
http://www.python.org/dev/peps/pep-0389/ Congratulations!
As far as I can tell, genzshcomp is parsing the output of the help command to
reverse-engineer what the allowed flags should be. Assuming that only one space
occurs between the arg and its metavar, this should work 99% or the time... I'm
not sure if there is any attempt to be clever when the formatting is ambiguous.
But given that the opt parser already contains the structured information, life
can be made easier by writing out a more readily parseable format.
Here's an example bash parser function and its usage, for a further-simplified
form of the above format where each arg (long or short) gets a line of its own
and the arguments are indicated by a separate word as in the current output:
Example input:
$ foo --help-options
#OPTPARSE_FORMAT 0
--version
-h
--help
-r REGEXP
--regexp REGEXP
-s N
--start N
-e M
--end M
-f FILE
--file FILE
and the parser/completion functions:
function _optparse_getargs() {
local opts cur prev
COMPREPLY=()
cur=${COMP_WORDS[COMP_CWORD]}
prev=${COMP_WORDS[COMP_CWORD-1]}
PREVIFS=$IFS
IFS=$'\n'
for line in `$1 --help-options | egrep '^-'`; do
opt=`echo $line | sed 's/^\(-[^ ]\+\).*$/\1/'`
argeq=`echo $line | sed 's/^--[^ ]\+ \([A-Za-z0-9]*\)$/=/'`
if [[ $argeq != = ]]; then argeq=; fi
opts=$opts $opt$argeq;
done
IFS=$PREVIFS
unset PREVIFS
opts=`echo $opts | sed -e 's/^ *//' -e 's/ *$//'`
if [[ ${cur} == -* ]] ; then
COMPREPLY=( $(compgen -W ${opts} -- ${cur}) )
if test -n $COMPREPLY; then
return 0
fi
fi
return 0
}
function _foo() {
_optparse_getargs foo
return 0
}
complete -F _foo -o default foo
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4256
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4256] optparse: provide a simple way to get a programmatically useful list of options
Andy Buckley a...@insectnation.org added the comment: That sort of idea, yes: just a wild thought, but it would be really nice if this was available so that in combination with a standard bash/zsh function, getting basic automatic command completion for scripts built with optparse (and any other implementer of such a scheme) was as simple as adding complete -F _optparse -o default mycmdname to the completion script library. The simple scheme you laid out seems fine to me, but in the best bikeshedding tradition it would be useful to distinguish between options which take an argument and those which don't, pre-empt the need for a format version, and make the parsing even easier by removing cosmetic whitespace, commas etc.: grusz...@gruszczy-laptop:~/Programs/logbuilder$ ./logbuilder --help-options #OPTPARSE_FORMAT 0 --version -h --help -r= --regexp= -c= --contains= -s= --start= -e= --end= -f= --file= -t= --template= -p= --purge= Maybe this is just a pipe-dream, but the need to hand-write basic completion scripts seems so unnecessary, just for lack of any (even de-facto) standardisation. As optparse already enforces/encourages many good habits and conventions, some system like this would further help the integration with shell completion. Or maybe the existing --help output is good enough for a rather more fiddly standard bash completion parsing function. I've tried writing one of these, but it would hard for it be generally robust since the descriptive strings can contain any structure that they feel like, and could hence mess up the pattern-matching. I'm very happy if someone can out-sed me and make that work! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4256 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue444582] Finding programs in PATH, addition to os
Changes by Andy Buckley a...@insectnation.org: -- nosy: +andybuckley ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue444582 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5374] optparse special usage tokens conflict with formatting characters
Andy Buckley a...@insectnation.org added the comment: I'm easy either way --- I appreciate that it is a non-issue with new formatting, but until developers can rely on the presence of Py = 2.6, %-formatting wil continue to be widely used. Since optparse's special use of %-delimited tokens clashes with the established formatting in a way that could arguably do with clarification (I was blind enough to the solution to start this ticket), I think it could be useful to document it close to the description of %prog usage. Of course, since I now know the answer, *I* don't need it to be in the documentation, but it might be helpful to others ;) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5374 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5374] optparse special usage tokens conflict with formatting characters
Andy Buckley a...@insectnation.org added the comment: Doc patch for Doc/library/optparse.rst attached. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5374 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5374] optparse special usage tokens conflict with formatting characters
Andy Buckley a...@insectnation.org added the comment: Sorry, browser error last time. Should work now (fingers crossed). -- keywords: +patch Added file: http://bugs.python.org/file13360/optparse-prog-escape.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5374 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4278] optparse quirks
Andy Buckley a...@insectnation.org added the comment: Are these really bugs? The first message just reports the error the other way around from how you view it: you are thinking of -TO as a two-character short option, optparse thinks of it as a two-character long option which is missing a dash. I would side with optparse's definition, since the point of short options is that they can be combined under a single dash --- a multi-character option can't do that, and so can't be short by definition. In both this and the -h issue, optparse is reasonably enforcing a UI convention as well as providing parsing facilities. That uniformity of UI behaviour is a design goal is made explicit in the documentation. Using optparse means that users can rely on -h to give them help documentation, which IMO is a very useful convention to respect. And the splitting of long and short options by whether they are single character (and hence can be combined) or multi-character (hence uncombinable, but good for less-used options without eating up the alphabetic option namespace) is another nice convention which optparse enforces. -1 from me: I think the existing behaviours are good, largely *because* they aren't flexible. -- nosy: +andybuckley ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4278 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4318] optparse: formatting of help text/descriptions
Andy Buckley a...@insectnation.org added the comment: FWIW, I would like to see an option on textwrap to preserve newlines for purposes other than optparse formatting. optparse would then just be able to pass that as a flag when building the text wrapper object. Should I open a separate issue targeted at textwrap? -- nosy: +andybuckley ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4318 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5374] optparse special usage tokens conflict with formatting characters
New submission from Andy Buckley a...@insectnation.org: optparse's OptionParser takes a usage string as a constructor argument, in which a %prog token is replaced with the executable name. Nice idea, but the choice of a percent sign for token delimiter is troublesome since it means that attempting to substitute any variables into the usage string, e.g. usage = %prog [options] foo bar ... Some computed info: %s % myinfo gives a ValueError: ValueError: unsupported format character 'p' (0x70) at index 2 Maybe this ceases to be a problem with what I've heard about the formatting re-design in Python 3.x, but it will probably continue to be awkward for the 2.x series where the % operator still applies. Maybe optparse could also use a safer token (@prog, say), so that those of use who would like to substitute variables into usage strings don't have to artificially break our strings apart every time we use the program name? -- components: Library (Lib) messages: 82755 nosy: andybuckley severity: normal status: open title: optparse special usage tokens conflict with formatting characters type: behavior versions: Python 2.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5374 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5374] optparse special usage tokens conflict with formatting characters
Andy Buckley a...@insectnation.org added the comment: Dang, why didn't I think of that? Cheers. Might be worth mentioning that in the documentation, in case there are other people with my particular brand of tunnel vision ;) ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5374 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4151] Separate build dir broken
Andy Buckley a...@insectnation.org added the comment: I'm having trouble with this as well :( It's pretty much a blocker for integrating distutils-based extension builds with an autotools library build, because the make distcheck target explicitly does the build in a subtree of the source directory, and write-protects the srcdir during the build. Effectively the source is referred to in my setup.py as living in ../../pyext, which translates into distutils attempting to build the extension in build/temp.linux-i686-2.5/../../pyext/, which is the write-protected source dir. This would work okay if the directory path to the source file were ignored when constructing the output path: would the proposed patch(es) fix this? -- nosy: +andybuckley ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4151 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4673] Distutils should provide an uninstall command
Andy Buckley a...@insectnation.org added the comment: If an uninstall registry is feasible, the it could be neat. The suggested behaviour of unlinking known files based on the source directory is not all that inconvenient: it's by no means perfect, but it has its uses and is familiar to many, since it is how GNU autotools behaves. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4673 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4672] Distutils SWIG support blocks use of SWIG -outdir option
Andy Buckley a...@insectnation.org added the comment: Dumb question, but why is distutils wrapping the command args in quotes anyway? I'm not even sure why lists are being used (rather than a string) for the options, except that lists are a bit more Pythony and can be used to semantically divide the options from each other. If you end up having to use separate list elements for the option flag and the value it takes, doesn't that indicate that the list isn't being used properly? ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4672 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5070] Distutils should create install dir if needed
New submission from Andy Buckley a...@insectnation.org: If you attempt to call python setup.py install --prefix=/foo, and /foo/lib/pythonX.Y/site-packages does not exist, the installation will fail, requiring that the directory be made by hand. Since there is no easy way to know in advance (other than by running Python to build the version number string) exactly where the install will go, this can be troublesome for automated build scripts. For this reason, and also to be more consistent with existing build/install systems like autotools, I suggest that distutils builds the necessary portions of the lib directory tree (provided /foo exists). This should certainly happen (IMHO) if the --force option is given. -- components: Distutils messages: 80573 nosy: andybuckley severity: normal status: open title: Distutils should create install dir if needed type: feature request versions: Python 2.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5070 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5071] Distutils should not fail if install dir is not in PYTHONPATH
New submission from Andy Buckley a...@insectnation.org: At present, distutils exits with an error return code if the directory that modules are being installed into is not in PYTHONPATH. Since the install path is not easily obtained (it at least requires running Python to work out the version string, plus some guesswork about lib vs. lib64, etc. etc.), it would be nice if this was not a blocking problem... at least when the --force flag is passed to setup.py (PS. It would be nice if there *is* a way to get the installation path from distutils before installing, for the reasons mentioned: that way automatic install scripts like the one I'm managing could work out the path, make it and add it to the PYTHONPATH, without worrying about getting it wrong. Am I just missing something that already exists?) -- components: Distutils messages: 80576 nosy: andybuckley severity: normal status: open title: Distutils should not fail if install dir is not in PYTHONPATH type: feature request versions: Python 2.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5071 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5070] Distutils should create install dir if needed
Andy Buckley a...@insectnation.org added the comment: Thanks for the rapid feedback: yes, I am using setuptools and didn't realise it would be responsible for this override. Is setuptools feedback done completely independently from this tracker? ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5070 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4672] Distutils SWIG support blocks use of SWIG -outdir option
New submission from Andy Buckley a...@insectnation.org:
When using distutils to build an extension module using SWIG, it makes
most sense to use the built-in SWIG support. However, the distutils seem
to vet the options passed via the Extension.swig_opts attr/arg:
[...]
ext_modules=[Extension('_hepmc', ['@top_srcdir@/hepmc.i'],
swig_opts=['-c++', '-...@hepmcincpath@', '-outdir .'],
include_dirs=['@HEPMCINCPATH@'],
library_dirs=['@HEPMCLIBPATH@'],
libraries=['HepMC'])],
[...]
results in this error:
building '_hepmc' extension
swigging ./hepmc.i to ./hepmc_wrap.cpp
swig -python -c++ -I/home/andy/heplocal/include -outdir . -o
./hepmc_wrap.cpp ./hepmc.i
swig error : Unrecognized option -outdir .
Use 'swig -help' for available options.
error: command 'swig' failed with exit status 1
but calling the same swig command works fine. It's the same copy of
swig, but it seems to be distutils rather than swig that is throwing the
error. This is particularly relevant since I need to use -outdir to meet
the autotools distcheck requirement of successfully building from a
build-dir separate from the source dir: code generation tools like SWIG
blur such a distinction and so need to support output location flags
like -outdir.
I see this was also noticed some time ago:
http://osdir.com/ml/python.distutils.devel/2006-06/msg9.html
but no useful reply was ever forthcoming ;( Maybe this time will be
luckier!
--
components: Distutils
messages: 77883
nosy: andybuckley
severity: normal
status: open
title: Distutils SWIG support blocks use of SWIG -outdir option
type: behavior
versions: Python 2.5
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4672
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4673] Distutils should provide an uninstall command
New submission from Andy Buckley a...@insectnation.org: It would make package maintenance easier, as well as integration with other build systems e.g. autotools (necessary for projects where not everything is Python), if the distutils supported an uninstallation command, e.g. python setup.py uninstall This would presumably require monitoring of which files were installed where, and it's of course possible to do undesirable things, but exactly the same counter-arguments exist for autotools, and there the uninstall target is an important and useful feature for developers, once you know how to behave in a way to make it safe. -- components: Distutils messages: 77885 nosy: andybuckley severity: normal status: open title: Distutils should provide an uninstall command type: feature request versions: Python 2.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4673 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1479255] Fix building with SWIG's -c++ option set in setup.py
Andy Buckley a...@insectnation.org added the comment: This works in my current version of distutils (Python 2.5.2, from Ubuntu Intrepid). Maybe it was fixed and no-one noticed that this bug was relevant ;) -- nosy: +andybuckley ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1479255 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4256] optparse: provide a simple way to get a programmatically useful list of options
New submission from Andy Buckley [EMAIL PROTECTED]: optparse is a great option parser, but one thing that would make it even greater would be if it provided a standard option (cf. --help) which lists all the available options in a parseable form. Something prefixed with --help, e.g. --help-options would be ideal since it doesn't clutter the option namespace. This would provide a simple command-line hook for e.g. bash completion customisation with complete/compgen, which could then easily and maintainably obtain the list of available switches via the --help-options flag rather than hard-coding the option names or attempting to grep the output of --help It would also be good if the OptionParser provided a simple Python API way to obtain the names of all option switches, rather than having to loop over OptionGroups, calling the unadvertised 'option_list' and 'get_option_name' methods! -- components: Library (Lib) messages: 75469 nosy: andybuckley severity: normal status: open title: optparse: provide a simple way to get a programmatically useful list of options type: feature request versions: Python 2.5 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4256 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
