[issue13508] ctypes' find_library breaks with ARM ABIs
Trevor Newton added the comment: I am still encountering this issue when using pyudev on Python 3.8.5. -- nosy: +trevor.newton ___ Python tracker <https://bugs.python.org/issue13508> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42774] 'ipaddress' module, bad result for 'is_private' on "192.0.0.0"
Change by Trevor Marvin : -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue42774> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42774] 'ipaddress' module, bad result for 'is_private' on "192.0.0.0"
New submission from Trevor Marvin :
Tested on Python 3.6.9 with "ipaddress" module, module version 1.0.
ipaddress.ip_address('192.0.0.0').is_private
Incorrectly returns as 'True'. Per RFC 1918 / BCP 5, section 3, the private
IPv4 space sarting with '192' is only '192.168.0.0/16'.
--
components: Library (Lib)
messages: 383942
nosy: trevormarvin
priority: normal
severity: normal
status: open
title: 'ipaddress' module, bad result for 'is_private' on "192.0.0.0"
type: behavior
versions: Python 3.6
___
Python tracker
<https://bugs.python.org/issue42774>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42270] libregrtest BrokenPipeError on OpenEmbedded builds
New submission from Trevor :
In OpenEmbedded we have a test wrapper for tests such as those in Python, and
currently we are experiencing the following error when running them:
sed: couldn't flush stdout: Resource temporarily unavailable
[37/1846]
test test_strftime crashed -- Traceback (most recent call last):
File "/usr/lib/python3.9/test/libregrtest/runtest.py", line 270, in
_runtest_inner
refleak = _runtest_inner2(ns, test_name)
File "/usr/lib/python3.9/test/libregrtest/runtest.py", line 234, in
_runtest_inner2
test_runner()
File "/usr/lib/python3.9/test/libregrtest/runtest.py", line 209, in
_test_module
support.run_unittest(tests)
File "/usr/lib/python3.9/test/support/__init__.py", line 1918, in run_unittest
_run_suite(suite)
File "/usr/lib/python3.9/test/support/__init__.py", line 1796, in _run_suite
result = runner.run(suite)
File "/usr/lib/python3.9/unittest/runner.py", line 176, in run
test(result)
File "/usr/lib/python3.9/unittest/suite.py", line 84, in __call__
return self.run(*args, **kwds)
File "/usr/lib/python3.9/unittest/suite.py", line 122, in run
test(result)
File "/usr/lib/python3.9/unittest/suite.py", line 84, in __call__
return self.run(*args, **kwds)
File "/usr/lib/python3.9/unittest/suite.py", line 122, in run
test(result)
File "/usr/lib/python3.9/unittest/suite.py", line 84, in __call__
return self.run(*args, **kwds)
File "/usr/lib/python3.9/unittest/suite.py", line 122, in run
test(result)
File "/usr/lib/python3.9/unittest/case.py", line 653, in __call__
return self.run(*args, **kwds)
File "/usr/lib/python3.9/unittest/case.py", line 566, in run
result.startTest(self)
File "/usr/lib/python3.9/test/support/testresult.py", line 49, in startTest
self.stream.flush()
BrokenPipeError: [Errno 32] Broken pipe
Traceback (most recent call last):
File "/usr/lib/python3.9/runpy.py", line 197, in _run_module_as_main
return _run_code(code, main_globals, None,
File "/usr/lib/python3.9/runpy.py", line 87, in _run_code
exec(code, run_globals)
File "/usr/lib/python3.9/test/__main__.py", line 2, in
main()
File "/usr/lib/python3.9/test/libregrtest/main.py", line 716, in main
Regrtest().main(tests=tests, **kwargs)
File "/usr/lib/python3.9/test/libregrtest/main.py", line 638, in main
self._main(tests, kwargs)
File "/usr/lib/python3.9/test/libregrtest/main.py", line 691, in _main
self.run_tests()
File "/usr/lib/python3.9/test/libregrtest/main.py", line 518, in run_tests
self.run_tests_sequential()
File "/usr/lib/python3.9/test/libregrtest/main.py", line 409, in
run_tests_sequential
self.display_progress(test_index, text)
File "/usr/lib/python3.9/test/libregrtest/main.py", line 169, in
display_progress
self.log(f"[{line}] {text}")
File "/usr/lib/python3.9/test/libregrtest/main.py", line 158, in log
print(line, flush=True)
BrokenPipeError: [Errno 32] Broken pipe
Warning -- Unraisable exception
Exception ignored in: <_io.TextIOWrapper name=1 mode='w' encoding='utf-8'>
BrokenPipeError: [Errno 32] Broken pipe
---
I'm looking into it already, but need to document it.
--
components: Tests
messages: 380423
nosy: threexc
priority: normal
severity: normal
status: open
title: libregrtest BrokenPipeError on OpenEmbedded builds
type: crash
versions: Python 3.9
___
Python tracker
<https://bugs.python.org/issue42270>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17703] Trashcan mechanism segfault during interpreter finalization in Python 2.7.4
Trevor Joynson added the comment: I can also confirm that the included patch does "workaround" the issue. A big pain point here for me is in determining what exit handler is causing this. GDB has been it's usual great help in determining information about the exact segfault, but the problem code itself is rather elusive since it's ran so much earlier and just causes this issue downstream later in execution. Unfortunately the extensions I'm dealing with also happen to take a lifetime to compile, exacerbated by the fact that they are dependent upon one another. Can we please apply this to 3.x's tree? -- ___ Python tracker <https://bugs.python.org/issue17703> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17703] Trashcan mechanism segfault during interpreter finalization in Python 2.7.4
Trevor Joynson added the comment: I can verify this bug does still in fact exist in all 3.x versions I've tested (3.4-3.7). It's been the cause of many long-standing segfaults we've been having at exit in applications that use OpenRAVE and/or boost::python::numeric. -- nosy: +ned.deily, trevorj versions: +Python 3.6 -Python 3.4 ___ Python tracker <https://bugs.python.org/issue17703> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33008] urllib.request.parse_http_list incorrectly strips backslashes
New submission from W. Trevor King <wk...@tremily.us>: Python currently strips backslashes from inside quoted strings: $ echo 'a="b\"c",d=e' | python3 -c 'from sys import stdin; from urllib.request import parse_http_list; print(parse_http_list(stdin.read()))' ['a="b"c"', 'd=e'] It should be printing: ['a="b\"c"', 'd=e'] The bug is this continue [1], which should be removed. This was not a problem with the original implementation [2]. It was introduced in [3] as a fix for #735248 with explicit tests asserting the broken behavior [3]. Stripping backslashes from the insides of quoted strings is not appropriate, because it breaks explicit unquoting with email.utils.unquote [4]: import email.utils import urllib.request list = r'"b\\"c"' entry = urllib.request.parse_http_list(list)[0] entry # '"b\\"c"', should be '"b"c"' email.utils.unquote(entry) # 'b"c', should be 'b\\"c' I'm happy to file patches against the various branches if that would help, but as a one-line removal (plus adjusting the tests), it might be easier if a maintainer files the patches. [1]: https://github.com/python/cpython/blob/v3.7.0b2/Lib/urllib/request.py#L1420 [2]: https://github.com/python/cpython/commit/6d7e47b8ea1b8cf82927dacc364689b8eeb8708b#diff-33f7983ed1a69d290366fe426880581cR777 [3]: https://github.com/python/cpython/commit/e1b13d20199f79ffd3407bbb14cc09b1b8fd70d2#diff-230a8abfedeaa9ae447490df08172b15R52 [4]: https://docs.python.org/3.5/library/email.util.html#email.utils.unquote -- components: Library (Lib) messages: 313308 nosy: labrat priority: normal severity: normal status: open title: urllib.request.parse_http_list incorrectly strips backslashes versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33008> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33003] urllib: Document parse_http_list
New submission from W. Trevor King <wk...@tremily.us>: Python has had a parse_http_list helper since urllib2 landed in 6d7e47b8ea (EXPERIMENTAL, 2000-01-20). With Python3 it was moved into urllib.request, and the implementation hasn't changed since (at least as of 4c19b9573, 2018-03-05). External projects depend on the currently undocumented function [1,2], so it would be nice to have some user-facing documentation for it. If that sounds appealing, I'm happy to work up a pull request. [1]: https://github.com/requests/requests/blob/v2.18.4/requests/compat.py#L42 [2]: https://github.com/requests/requests/blob/v2.18.4/requests/compat.py#L58 -- assignee: docs@python components: Documentation messages: 313294 nosy: docs@python, labrat priority: normal severity: normal status: open title: urllib: Document parse_http_list type: enhancement versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33003> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26080] "abandonned" -> "abandoned" in PEP 510's https://hg.python.org/peps/rev/b463c740990c
New submission from W. Trevor King: In the recently-landed [1], There was also the Unladen Swallow project, but it was abandonned in 2011. Should have used “abandoned” instead of “abandonned”. [1]: https://hg.python.org/peps/rev/b463c740990c changeset: 6155:b463c740990c user: Victor Stinner <victor.stinner< at >gmail.com> date: Sun Jan 10 14:58:17 2016 +0100 summary: PEP 510: rationale for static optimize vs JIT compiler http://permalink.gmane.org/gmane.comp.python.cvs/114604 -- assignee: docs@python components: Documentation messages: 257974 nosy: docs@python, labrat priority: normal severity: normal status: open title: "abandonned" -> "abandoned" in PEP 510's https://hg.python.org/peps/rev/b463c740990c type: enhancement ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26080> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25852] smtplib's SMTP.connect() should store the server name in ._host for .starttls()
New submission from W. Trevor King: With the current tip, starttls uses ._host when calling wrap_socket [1], but ._host is only setup in SMTP.__init__ [2]. Before #22921 [3] starttls would ignore ._host when SNI wasn't available locally. But as far as I can tell, starttls has never used _host when connection happens via an explicit connect() call. This leads to errors like [4]: >>> smtp = smtplib.SMTP() >>> smtp.connect(host="smtp.gmail.com", port=587) >>> smtp.ehlo() >>> smtp.starttls() File "smtp_test.py", line 10, in smtp.starttls() File "/usr/lib/python3.4/smtplib.py", line 676, in starttls server_hostname=server_hostname) File "/usr/lib/python3.4/ssl.py", line 344, in wrap_socket _context=self) File "/usr/lib/python3.4/ssl.py", line 540, in __init__ self.do_handshake() File "/usr/lib/python3.4/ssl.py", line 767, in do_handshake self._sslobj.do_handshake() ssl.SSLError: [SSL: TLSV1_ALERT_DECODE_ERROR] tlsv1 alert decode error (_ssl.c:598) I think a better approach would be to move the ._host set into .connect (patch attached). It would still happen in SMTP(host=…) because [5], but would also allow starttls when users use SMTP() and then call connect(host=…) explicitly. I've formatted the patch with Git, but its simple enough that it should be easy to apply in Mercurial. Still, let me know if I can make applying it easier by rerolling the patch. [1]: https://hg.python.org/cpython/file/323c10701e5d/Lib/smtplib.py#l766 [2]: https://hg.python.org/cpython/file/323c10701e5d/Lib/smtplib.py#l244 [3]: http://bugs.python.org/issue22921 [4]: http://stackoverflow.com/questions/23616803/smtplib-smtp-starttls-fails-with-tlsv1-alert-decode-error [5]: https://hg.python.org/cpython/file/323c10701e5d/Lib/smtplib.py#l251 -- components: Library (Lib) files: 0001-smtplib-Set-SMTP._host-in-.connect.patch keywords: patch messages: 256299 nosy: labrat priority: normal severity: normal status: open title: smtplib's SMTP.connect() should store the server name in ._host for .starttls() type: behavior versions: Python 3.3, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file41291/0001-smtplib-Set-SMTP._host-in-.connect.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25852> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24086] Configparser interpolation is unexpected
Trevor Bekolay added the comment: Thanks for the quick response! I can see the use case for using interpolation in .pypirc. Unfortunately for me, I push releases for both Python 2 and Python 3, so having the double percent sign will cause problems for me on Python 2. The exception that's being raised is at line 442 (https://hg.python.org/cpython/file/default/Lib/configparser.py#l442). The message itself seems to have the right information, but setuptools seems to mangle it (perhaps InterpolationSyntaxError needs a __repr__ or __str__?) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24086 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24086] Configparser interpolation is unexpected
New submission from Trevor Bekolay:
I was having an issue installing a package in Python 3, which installed
properly in Python 2. This is the error message I got:
Complete output from command python setup.py egg_info:
Traceback (most recent call last):
... snip unhelpful traceback ...
File
/usr/local/Cellar/python3/3.4.3/Frameworks/Python.framework/Versions/3.4/lib/python3.4/configparser.py,
line 423, in _interpolate_some
found: %r % (rest,))
configparser.Interpolation
Command python setup.py egg_info failed with error code 1 in
/private/var/folders/12/p4ngkfbx2pnb1ln81csjb19cgn/T/pip-build-6xhgg5x6/nengo
This wasn't a super helpful error message. I managed to figure out that Python
3 (or setuptools?) was attempting to parse my ~/.pypirc file, which raised a
configparser.InterpolationSyntaxError because my password contained a
percent-sign. Configparser doesn't try to interpolate this string in Python 2,
so it worked fine. As a workaround, I've changed my PyPI password, but this
failure was quite surprising to me.
As for what I would expect to happen, I would not expect interpolation to
happen if I don't want it to happen. All of the examples shown on in the docs
use the syntax %(key)s or ${key}. If this is the only way to interpolate,
then why is % ambiguous? Surely we can look forward one character, and if
it's not ( then % should be interpreted literally. Instead, configparser
requires me to disambiguate with %%. But, this would cause my string to be
parsed incorrectly in Python 2's configparser, so I'm unable to make that
change.
--
components: Library (Lib)
messages: 242283
nosy: tbekolay
priority: normal
severity: normal
status: open
title: Configparser interpolation is unexpected
type: behavior
versions: Python 3.2, Python 3.3, Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24086
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22684] message.as_bytes() produces recursion depth exceeded
W. Trevor King added the comment:
Here's an example from the notmuch list. You can trigger the exception in
Python 3.4 with:
import email.policy
import mailbox
mbox = mailbox.mbox('msg.mbox', factory=None, create=False)
message = mbox[0]
message.as_bytes(policy=email.policy.SMTP)
Traceback (most recent call last):
File stdin, line 1, in module
File /home/wking/src/notmuch/ssoma_mda.py, line 319, in deliver
message_bytes = message.as_bytes(policy=_email_policy.SMTP)
File /usr/lib64/python3.4/email/message.py, line 179, in as_bytes
g.flatten(self, unixfrom=unixfrom)
File /usr/lib64/python3.4/email/generator.py, line 112, in flatten
self._write(msg)
File /usr/lib64/python3.4/email/generator.py, line 192, in _write
self._write_headers(msg)
…
File /usr/lib64/python3.4/email/_header_value_parser.py, line 195, in
genexpr
return ''.join(str(x) for x in self)
RuntimeError: maximum recursion depth exceeded while getting the str of an
object
Interestingly, it serializes fine using the default policy:
message.as_bytes()
b'Return-Path: …-\n'
--
nosy: +labrat
Added file: http://bugs.python.org/file37143/msg.mbox
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22684
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22684] message.as_bytes() produces recursion depth exceeded
W. Trevor King added the comment:
The troublesome header formatting is:
import email.policy
email.policy.SMTP.fold_binary('Cc',
'notmuch\n\tpublic-public-notmuch-gxuj+Tv9EO5zyzON3hdc1g-wOFGN7rlS/M9smdsby/k...@plane.gmane.org,\n\tpublic-notmuch-gxuj+tv9eo5zyzon3hd...@plane.gmane.org,\n\tRainer
M Krug public-r.m.krug-re5jqeeqqe8avxtiumw...@plane.gmane.org,\n\tJeremy
Nickurak\n\tpublic-public-not-much-kexSNQTsIoD754YsiR0rpA-wOFGN7rlS/M9smdsby/k...@plane.gmane.org')
Traceback (most recent call last):
…
RuntimeError: maximum recursion depth exceeded while getting the str of an
object
Trimming that down a bit, a minimal trigger seems to be:
email.policy.SMTP.fold_binary('Cc',
'a\n\ta,\n\ta')
Traceback…
Where removing much of anything gives a working fold.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22684
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22684] message.as_bytes() produces recursion depth exceeded
W. Trevor King added the comment: In email._header_value_parser._Folded.append_if_fits, if I shift: if token.has_fws: ws = token.pop_leading_fws() if ws is not None: self.stickyspace += str(ws) stickyspace_len += len(ws) token._fold(self) return True to: if token.has_fws: ws = token.pop_leading_fws() if ws is not None: self.stickyspace += str(ws) stickyspace_len += len(ws) token._fold(self) return True I can avoid the recursion. The problem seems to be that the a …aaa token/part contains folding white space, but doesn't *start* with folding whitespace. Maybe the folding should try to split on existing FWS, instead of just trying to pop leading FWS? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22684 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21226] PyImport_ExecCodeModuleObject not setting module attributes
New submission from Trevor Caira: In Python/import.c, PyImport_ExecCodeModuleObject creates a new module object but doesn't set all of the attributes required for modules, such as __spec__ or __loader__. This breaks mod_wsgi from 3.3 and up, which depends on PyImport_ExecCodeModuleEx, which delegates to PyImport_ExecCodeModuleObject for its module creation logic. See https://code.google.com/p/modwsgi/source/browse/mod_wsgi/mod_wsgi.c#6289 -- components: Library (Lib) messages: 216217 nosy: brett.cannon, eric.snow, ncoghlan, trevor3 priority: normal severity: normal status: open title: PyImport_ExecCodeModuleObject not setting module attributes type: behavior versions: Python 3.3, Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21226 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19226] distutils/command/upload.py show response gives: TypeError: sequence item 1: expected str instance, bytes found
New submission from W. Trevor King:
Avoid:
Traceback (most recent call last):
File setup.py, line 61, in module
'html2text (=3.0.1)',
File /.../python3.2/distutils/core.py, line 148, in setup
dist.run_commands()
File /.../python3.2/distutils/dist.py, line 917, in run_commands
self.run_command(cmd)
File /.../python3.2/distutils/dist.py, line 936, in run_command
cmd_obj.run()
File /.../python3.2/distutils/command/upload.py, line 66, in run
self.upload_file(command, pyversion, filename)
File /.../python3.2/distutils/command/upload.py, line 201, in
upload_file
msg = '\n'.join(('-' * 75, r.read(), '-' * 75))
TypeError: sequence item 1: expected str instance, bytes found
by converting the bytes returned by HTTPResponse.read [1] to a string
before joinging it with other strings. HTTPResponse.headers supports
the Message interface [2], so we can use get_param to extract the
charset [3], falling back on ISO-8859-1 [4].
[1]:
http://docs.python.org/3/library/http.client.html#http.client.HTTPResponse.read
[2]: http://docs.python.org/3/library/http.client.html#httpmessage-objects
[3]:
http://docs.python.org/3/library/email.message.html#email.message.Message.get_param
[4]: http://tools.ietf.org/html/rfc2616#section-3.7.1
--
assignee: eric.araujo
components: Distutils
files: show-response-string.patch
keywords: patch
messages: 199489
nosy: eric.araujo, labrat, tarek
priority: normal
severity: normal
status: open
title: distutils/command/upload.py show response gives: TypeError: sequence
item 1: expected str instance, bytes found
versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file32045/show-response-string.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19226
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19226] distutils/command/upload.py show response gives: TypeError: sequence item 1: expected str instance, bytes found
W. Trevor King added the comment: On Fri, Oct 11, 2013 at 05:21:15PM +, Ned Deily wrote: This problem has been reported previously as Issue17354, a duplicate of Issue12853 which is still open at the moment. Ah, I searched for a fwe possible subject lines, but didn't hit those :p. I thought that if it wasn't fixed in the master branch it must not have an associated issue… I like my patch better than Issue17354's, because PyPI servers may not always use UTF-8. I'll ping Issue12853 about the patches, because either one would fix Issue12853, and it's currently needs patch. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19226 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12853] global name 'r' is not defined in upload.py
W. Trevor King added the comment: I just posted a patch fixing this in the current master branch [1]. Ned Deily pointed out that my Issue19226 duplicated an earlier Issue17354, which also has a patch fixing this problem. Merging either one of these patches should close this issue. I like my patch's generic charset handling better, but for PyPI uploads either one would work fine. I've looked through the Mercurial logs, but it looks like this r *has* been around since 34794 (Implement the Distutils 'upload' subcommand (upload package to PyPI), 2005-03-21), so I don't know where the global name 'r' is not defined message came from. -- nosy: +labrat ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12853 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19142] Cross-compile fails trying to execute foreign pgen on build host
Trevor Bowen added the comment: I thought make touch was only for those trying to build from the Mecurial source, as opposed to building from the released tar-ball source. I thought my efforts laid on the other side of the need for that command. If I understood wrong, when would I use it and why? ... Thanks! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19142 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19142] Cross-compile fails trying to execute foreign pgen on build host
Trevor Bowen added the comment: Thanks, David! I have no interest in running pgen on the target/host. My only interest is building python and its various modules to run on my embedded host. I do not want to develop Python on the embedded host. Unfortunately, the build process requires Parser/pgen to build the grammar files, which are needed for several object files. Here's the relevant snippet from the Makefile.pre.in: $(GRAMMAR_H): $(GRAMMAR_INPUT) $(PGENSRCS) @$(MKDIR_P) Include $(MAKE) $(PGEN) $(PGEN) $(GRAMMAR_INPUT) $(GRAMMAR_H) $(GRAMMAR_C) $(GRAMMAR_C): $(GRAMMAR_H) $(GRAMMAR_INPUT) $(PGENSRCS) $(MAKE) $(GRAMMAR_H) touch $(GRAMMAR_C) $(PGEN):$(PGENOBJS) $(CC) $(OPT) $(LDFLAGS) $(PGENOBJS) $(LIBS) -o $(PGEN) Parser/grammar.o: $(srcdir)/Parser/grammar.c \ $(srcdir)/Include/token.h \ $(srcdir)/Include/grammar.h ... Python/compile.o Python/symtable.o Python/ast.o: $(GRAMMAR_H) $(AST_H) If there is a way to eliminate the need for Parser/pgen to run on the build system to cross-compile the default all target, that would be great. ... I'll experiment with make touch. ... Thanks! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19142 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19142] Cross-compile fails trying to execute foreign pgen on build host
Trevor Bowen added the comment: I executed make touch between configure and make, but the build process still created Parser/pgen and then tried to use it, which of course crashed the build, since pgen was compiled for the embedded host not the build system. :( Was that the wrong usage? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19142 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19142] Cross-compile fails trying to execute foreign pgen on build host
Trevor Bowen added the comment: In the vein of: http://randomsplat.com/id5-cross-compiling-python-for-embedded-linux.html I have created a patch and top-level build script, which builds the requisite python interpreter and Parser/pgen binary to run on the build system, which are both used during the cross-compile process. In some ways, this patch is simpler, because of the new cross-compile capabilities in 2.7.4 and 2.7.5. However, previous work is still insufficient, because the Makefile assumes the cross-compiled Parser/pgen can be executed on the build system during build. This patch primarily compensates for that, but it also works around some misplaced installation file issues. My top-level cross-compile script, which applies the patch *during* the build process is also attached. It depends on a VCS to restore the original version, but I could have just as easily made 2 copies of the patched files (before and after patching) and copied the original versions as needed. I hope this helps others. Hopefully, bits of this can be integrated to help further simplify future cross-compile efforts. -- keywords: +patch Added file: http://bugs.python.org/file31991/Python-2.7.5-xcompile.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19142 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19142] Cross-compile fails trying to execute foreign pgen on build host
Trevor Bowen added the comment:
Short version of cross-compile script without error checking:
#!/bin/bash
export RFS=/local/my_root_file_system
make distclean
rm -rf python_for_build Parser/pgen_for_build
git checkout -- Makefile.pre.in Modules/Setup.dist configure setup.py
./configure
make python Parser/pgen
mv python python_for_build
mv Parser/pgen Parser/pgen_for_build
patch -p3 Python-2.7.5-xcompile.patch
export
PATH=/opt/my_cross_compile_toolchain/gcc-4.3.74-eglibc-2.8.74-dp-2/powerpc-none-linux-gnuspe/bin:${PATH}
make distclean
./configure --host=powerpc-none-linux-gnuspe --build=i586-linux-gnu --prefix=/
\
--disable-ipv6 ac_cv_file__dev_ptmx=no ac_cv_file__dev_ptc=no
ac_cv_have_long_long_format=yes
make --jobs=4
sudo make install DESTDIR=${RFS} PATH=${PATH}
--
Added file: http://bugs.python.org/file31992/cross-compile.sh
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19142
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19142] Cross-compile fails trying to execute foreign pgen on build host
Trevor Bowen added the comment: FWIW, I also explored my original proposal, which essentially moved the above script and modifications into the Python configure.ac and Makefile.pre.in files, so that Python's internal build process would create the native build system versions of Python and Parser/pgen, if necessary. I made some progress in creating additional Make targets just for the native build system, which redefined the toolchain after completion; however, I encountered unexepected, overwhelming configure contamination in the auto-generated header files. Maybe someone can push this farther than me? I'm attaching my patch, in case it helps someone else and just as reference. As for me, I think it is much easier to use the above solution, which would require very little patching to the sources to make a 2-step compilation to be trivial. -- Added file: http://bugs.python.org/file31993/Python-2.7.5-xcompile_improvements.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19142 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19142] Cross-compile fails trying to execute foreign pgen on build host
Trevor Bowen added the comment: Ok, thanks for the tips. I'm new to developing on Python itself. I'll start simple by trying to develop a set of patches for the 2.7.5 source tar-ball, which I usually use to build Python. If that succeeds, I'll look into pushing it into the related source files. So far, I'm anticipating modifying these files: configure, Makefile.pre.in, and setup.py. ... Thanks! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19142 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19142] Cross-compile fails trying to execute foreign pgen on build host
New submission from Trevor Bowen:
FWIW, I'm using a Freescale cross-compile tool-chain on a Linux x86-64 build
host, although I have duplicated the cross-compile error on an x86 Ubunutu
10.04 build host.
Steps to reproduce:
$ wget http://www.python.org/ftp/python/2.7.5/Python-2.7.5.tar.bz2
$ tar -jxf Python-2.7.5.tar.bz2
$ cd Python-2.7.5
$ export
PATH=/opt/freescale/usr/local/gcc-4.3.74-eglibc-2.8.74-dp-2/powerpc-none-linux-gnuspe/bin:${PATH}
# For info only:
$ ls -l
/opt/freescale/usr/local/gcc-4.3.74-eglibc-2.8.74-dp-2/powerpc-none-linux-gnuspe/bin
total 10472
-rwxrwxrwx 1 root root 590485 Mar 5 2012 powerpc-none-linux-gnuspe-addr2line
-rwxrwxrwx 1 root root 614647 Mar 5 2012 powerpc-none-linux-gnuspe-ar
-rwxrwxrwx 1 root root 897161 Mar 5 2012 powerpc-none-linux-gnuspe-as
-rwxrwxrwx 1 root root 235382 Mar 5 2012 powerpc-none-linux-gnuspe-c++
-rwxrwxrwx 1 root root 589227 Mar 5 2012 powerpc-none-linux-gnuspe-c++filt
-rwxrwxrwx 1 root root 234277 Mar 5 2012 powerpc-none-linux-gnuspe-cpp
-rwxrwxrwx 1 root root8503 Mar 5 2012 powerpc-none-linux-gnuspe-embedspu
-rwxrwxrwx 1 root root 235382 Mar 5 2012 powerpc-none-linux-gnuspe-g++
-rwxrwxrwx 1 root root 233126 Mar 5 2012 powerpc-none-linux-gnuspe-gcc
-rwxrwxrwx 1 root root 233126 Mar 5 2012 powerpc-none-linux-gnuspe-gcc-4.3.2
-rwxrwxrwx 1 root root 16512 Mar 5 2012 powerpc-none-linux-gnuspe-gccbug
-rwxrwxrwx 1 root root 28017 Mar 5 2012 powerpc-none-linux-gnuspe-gcov
-rwxrwxrwx 1 root root 655127 Mar 5 2012 powerpc-none-linux-gnuspe-gprof
-rwxrwxrwx 1 root root 1036372 Mar 5 2012 powerpc-none-linux-gnuspe-ld
-rwxrwxrwx 1 root root 603678 Mar 5 2012 powerpc-none-linux-gnuspe-nm
-rwxrwxrwx 1 root root 750617 Mar 5 2012 powerpc-none-linux-gnuspe-objcopy
-rwxrwxrwx 1 root root 895336 Mar 5 2012 powerpc-none-linux-gnuspe-objdump
-rwxrwxrwx 1 root root 614647 Mar 5 2012 powerpc-none-linux-gnuspe-ranlib
-rwxrwxrwx 1 root root 264063 Mar 5 2012 powerpc-none-linux-gnuspe-readelf
-rwxrwxrwx 1 root root 593901 Mar 5 2012 powerpc-none-linux-gnuspe-size
-rwxrwxrwx 1 root root 591853 Mar 5 2012 powerpc-none-linux-gnuspe-strings
-rwxrwxrwx 1 root root 750617 Mar 5 2012 powerpc-none-linux-gnuspe-strip
$ ./configure --host=powerpc-none-linux-gnuspe \
--build=i586-linux-gnu --prefix=/ \
--disable-ipv6 ac_cv_file__dev_ptmx=no \
ac_cv_file__dev_ptc=no
$ make
Make fails because the foreign (powerpc, in this case) pgen binary is used to
build the $(GRAMMAR_H). Instead, a native version of the python interpreter
(preferrable) and pgen (essential) need to be built first using the host's
toolchain. Then, these tools can be used to build the full foreign suite.
FWIW, This 2 step process is well documented here:
http://randomsplat.com/id5-cross-compiling-python-for-embedded-linux.html
However, the cross-compile fixes from Issue17086 may have helped this process.
(It's hard for me to determine how to take advantage of these updates.)
Certainly, they changed the above process dramatically.
Incidentally, Python 3.3.2 exhibits almost the exact same build error, if not
the same.
Build log on an x86-64 host for Python-2.7.5 for a PowerPC-linux target is
attached.
Tail of log:
make Parser/pgen
make[1]: Entering directory `/home/user/Python-2.7.5'
powerpc-none-linux-gnuspe-gcc -c -fno-strict-aliasing -g -O2 -DNDEBUG -g
-fwrapv -O3 -Wall -Wstrict-prototypes -I. -IInclude -I./Include
-DPy_BUILD_CORE -o Python/mysnprintf.o Python/mysnprintf.c
powerpc-none-linux-gnuspe-gcc -c -fno-strict-aliasing -g -O2 -DNDEBUG -g
-fwrapv -O3 -Wall -Wstrict-prototypes -I. -IInclude -I./Include
-DPy_BUILD_CORE -o Python/pyctype.o Python/pyctype.c
powerpc-none-linux-gnuspe-gcc -c -fno-strict-aliasing -g -O2 -DNDEBUG -g
-fwrapv -O3 -Wall -Wstrict-prototypes -I. -IInclude -I./Include
-DPy_BUILD_CORE -o Parser/tokenizer_pgen.o Parser/tokenizer_pgen.c
powerpc-none-linux-gnuspe-gcc -c -fno-strict-aliasing -g -O2 -DNDEBUG -g
-fwrapv -O3 -Wall -Wstrict-prototypes -I. -IInclude -I./Include
-DPy_BUILD_CORE -o Parser/printgrammar.o Parser/printgrammar.c
powerpc-none-linux-gnuspe-gcc -c -fno-strict-aliasing -g -O2 -DNDEBUG -g
-fwrapv -O3 -Wall -Wstrict-prototypes -I. -IInclude -I./Include
-DPy_BUILD_CORE -o Parser/pgenmain.o Parser/pgenmain.c
powerpc-none-linux-gnuspe-gcc -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
Parser/acceler.o Parser/grammar1.o Parser/listnode.o Parser/node.o
Parser/parser.o Parser/parsetok.o Parser/bitset.o Parser/metagrammar.o
Parser/firstsets.o Parser/grammar.o Parser/pgen.o Objects/obmalloc.o
Python/mysnprintf.o Python/pyctype.o Parser/tokenizer_pgen.o
Parser/printgrammar.o Parser/pgenmain.o -lpthread -ldl -lpthread -lutil -o
Parser/pgen
make[1]: Leaving directory `/home/user/Python-2.7.5'
Parser/pgen ./Grammar/Grammar Include/graminit.h Python/graminit.c
Parser/pgen: Parser/pgen: cannot execute binary file
make: *** [Include/graminit.h
[issue19142] Cross-compile fails trying to execute foreign pgen on build host
Trevor Bowen added the comment: Sorry, I do not mean to compound an already open and complex problem. I thought that the fixes in 2.7.4 were meant in part to help alleviate this problem. I had not found any feedback or tutorials, so I wanted to provide a status update of sorts. I'm sure there is some. I just have not been able to find it myself. If the configure script passed in the cross-compile tool-chain *and* the build-host tool-chain, could the Makefile be enhanced to build pgen and python first with the build-host and then use them to build the full cross-compiled versions? Or, would there be a better general approach? I am not familiar with the MINGW requirements. Would this satisfy their needs? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19142 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9253] argparse: optional subparsers
W. Trevor King added the comment: Since [1] it seems like subparsers *are* optional by default. At least I get “error: too few arguments” for version 70740 of Lib/argparse.py, but no error for version 70741. It looks like this may be an unintentional side effect, since I see no mention of subparsers in #10424. [1]: http://hg.python.org/cpython/rev/cab204a79e09 -- nosy: +labrat Added file: http://bugs.python.org/file28778/check.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9253 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13558] multiprocessing package incompatible with PyObjC
New submission from Trevor Bentley mrme...@gmail.com: The multiprocessing package appears to spawn a new process by calling only fork(). Apple's CoreFoundation libraries (and possibly more, I do not know the full extent) *require* new processes to be spawned with the full fork()+exec*() combo. When using PyObjC to access native Mac libraries, Python's multithreading library is not usable. The error thrown is: The process has forked and you cannot use this CoreFoundation functionality safely. You MUST exec(). Break on __THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__() to debug. Test code: https://gist.github.com/1448398 -- assignee: ronaldoussoren components: Macintosh files: threadtest3.py messages: 149051 nosy: mrmekon, ronaldoussoren priority: normal severity: normal status: open title: multiprocessing package incompatible with PyObjC type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file23884/threadtest3.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13558 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12386] packaging fails in install_distinfo when writing RESOURCES
trevor tre...@well.com added the comment: [eric.araujo] Do you see that when running a test, a command or some other code? when attempting to install a self-created package. tools from 3.3a ~72060:1696e2789d91 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12386 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12386] packaging fails in install_distinfo when writing RESOURCES
trevor tre...@well.com added the comment: i see the same behavior - the error occurs leaving an empty RESOURCES file -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12386 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12388] cannot specify recursive extra_files in packaging setup.cfg
Changes by trevor tre...@well.com: -- nosy: +trevor ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12388 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12386] packaging fails in install_distinfo when writing RESOURCES
Changes by trevor tre...@well.com: -- nosy: +trevor ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12386 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12830] --install-data doesn't effect resources destination
New submission from trevor tre...@well.com: attempting to point the relative destination with --install-data does not seem to have an effect. the specified directory is created, but resources are still installed relative to the present working directory. setup.cfg: [files] resources = externalfiles/tobemoved.txt = support % pysetup3 run install_dist --install-data /tmp/example /tmp/example is created with no files, ./support/tobemoved.txt is created -- assignee: tarek components: Distutils2 messages: 142878 nosy: alexis, eric.araujo, tarek, trevor priority: normal severity: normal status: open title: --install-data doesn't effect resources destination type: behavior versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12830 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9640] Improved doctest REPORT_*DIFFs with ELLIPSIS and/or NORMALIZE_WHITESPACE
New submission from W. Trevor King wk...@drexel.edu: I had been struggling to find the failure-causing mismatch in a doctest with lots of output. REPORT_UDIFF gave lots of false mismatches because I was also using NORMALIZE_WHITESPACE. Looking through the doctest.py source, I saw a comment suggesting a nicer diff in the similar REPORT_*DIFF and ELLIPSIS situation. So I went ahead and implemented one. I'm not super happy with the cleanliness of the implementation, but it ended up being a bit trickier than I'd initially expected. -- components: Library (Lib) messages: 114340 nosy: labrat priority: normal severity: normal status: open title: Improved doctest REPORT_*DIFFs with ELLIPSIS and/or NORMALIZE_WHITESPACE type: feature request versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9640 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9640] Improved doctest REPORT_*DIFFs with ELLIPSIS and/or NORMALIZE_WHITESPACE
W. Trevor King wk...@drexel.edu added the comment: Here's my patch, or pull from my Mercurial repository http://www.physics.drexel.edu/~wking/code/hg/hgwebdir.cgi/python/rev/6638df20c1a4 -- keywords: +patch Added file: http://bugs.python.org/file18575/doctest_diff.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9640 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5752] xml.dom.minidom does not escape CR, LF and TAB characters within attribute values
W. Trevor King wk...@drexel.edu added the comment:
And while we're at it, we should also
.replace('', 'amp;').replace('', quot;).replace('', 'lt;')
which would have to go at the beginning to avoid double-escaping the ''.
We could use xml.sax.saxutils.escape to do all the escaping rather than
chaining replaces:
data = escape(data, {'':'quot;', '\r':'#xD;', '\n':'#xA;', '\t':'#x9;'})
which also escapes '' (not strictly required for attribute values, but
shouldn't be harmful either).
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5752
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5752] xml.dom.minidom does not escape CR, LF and TAB characters within attribute values
W. Trevor King wk...@drexel.edu added the comment: As a workaround until the patch gets included, you can import this monkey patch module. -- nosy: +labrat Added file: http://bugs.python.org/file18325/minidom.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5752 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6612] 'import site' fails when called from an unlinked directory
W. Trevor King wk...@drexel.edu added the comment: I just fixed it myself ;). As I said before, not really a big deal, but it was an easy fix. I've attached a patch, or you can merge my hg branch f python-trunk at http://www.physics.drexel.edu/~wking/code/hg/hgwebdir.cgi/python/ -- keywords: +patch versions: +Python 2.6, Python 2.7 Added file: http://bugs.python.org/file18264/issue6612.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6612 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6612] 'import site' fails when called from an unlinked directory
New submission from W. Trevor King wk...@drexel.edu:
I don't imagine this comes up very often, but:
$ mkdir /tmp/a; cd /tmp/a; rmdir /tmp/a; python -c 'import site';
rmdir: removing directory, /tmp/a
'import site' failed; use -v for traceback
Traceback (most recent call last):
File string, line 1, in module
File /home/wking/lib/python/site.py, line 73, in module
__boot()
File /home/wking/lib/python/site.py, line 33, in __boot
imp.load_module('site',stream,path,descr)
File /usr/lib/python2.5/site.py, line 408, in module
main()
File /usr/lib/python2.5/site.py, line 392, in main
paths_in_sys = removeduppaths()
File /usr/lib/python2.5/site.py, line 96, in removeduppaths
dir, dircase = makepath(dir)
File /usr/lib/python2.5/site.py, line 72, in makepath
dir = os.path.abspath(os.path.join(*paths))
File /usr/lib/python2.5/posixpath.py, line 403, in abspath
path = join(os.getcwd(), path)
OSError: [Errno 2] No such file or directory
--
messages: 91129
nosy: labrat
severity: normal
status: open
title: 'import site' fails when called from an unlinked directory
versions: Python 2.5
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6612
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue936813] fast modular exponentiation
Trevor Perrin tr...@users.sourceforge.net added the comment: Hi Mark, Let me know if I can give you any help with this. The original patch was split into 3 parts. The only part remaining unapplied is the Montgomery Reduction. It appeared to be a significant speedup when I was last testing, and is frequently used in other modular exponentiation libraries, but it does, admittedly, complicate the code. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue936813 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3040] optparse documentation: variable arguments example doesn't work as listed
New submission from Trevor Meyerowitz [EMAIL PROTECTED]: There are two minor bugs in the example in: http://docs.python.org/lib/optparse-callback-example-6.html For the optparse example documentation, the call to parser.add_option is listed as: parser.add_option(-c, --callback, action=callback, callback=varargs) this has two bugs: 1. It refers to the wrong function name 2. It needs to have a dest variable defined, b/c the callback function operates on that. This can be fixed if the parser.add_option call is changed to: parser.add_option(-c, --callback, action=callback, dest=foo, callback=varargs_callback) -- assignee: georg.brandl components: Demos and Tools, Documentation messages: 67709 nosy: georg.brandl, meyerowitz severity: normal status: open title: optparse documentation: variable arguments example doesn't work as listed type: behavior versions: Python 2.5 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3040 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
