Changes by Andy Buckley a...@insectnation.org:
--
nosy: +andybuckley
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue858809
___
___
Python-bugs-list
Changes by Andy Buckley a...@insectnation.org:
--
nosy: +andybuckley
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1294959
___
___
Python-bugs
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
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
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
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
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
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
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
Changes by Andy Buckley a...@insectnation.org:
--
nosy: +andybuckley
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue444582
___
___
Python-bugs-list
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
27 matches
Mail list logo
