[issue3323] Clarify __slots__ behaviour when inheriting
New submission from Andy <[EMAIL PROTECTED]>: Suggest clarification on behaviour of the __slots__ attribute when inheriting from classes that don't have __slots__ defined. Obviously the superclass automatically creates __dict__, and it seems the subclass inherits this. I presume this is expected behaviour, but I think it would be worth clarifying in the 'Notes on using __slots__' section - perhaps add something like: "If you define __slots__ on a subclass when its superclass doesn't have __slots__ defined, the superclass will automatically create a __dict__ instance which will be inherited by the subclass (as will other instance attributes). Defining __slots__ on the subclass doesn't block this inheritance." -- assignee: georg.brandl components: Documentation messages: 69460 nosy: georg.brandl, strangefeatures severity: normal status: open title: Clarify __slots__ behaviour when inheriting type: feature request versions: Python 2.2, Python 2.2.1, Python 2.2.2, Python 2.2.3, Python 2.3, Python 2.4, Python 2.5, Python 2.6, Python 2.7 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3323> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3353] make built-in tokenizer available via Python C API
Andy <[EMAIL PROTECTED]> added the comment: Sorry for the terribly dumb question about this. Are you meaning that, at this stage, all that is required is: 1. the application of the PyAPI_FUNC macro 2. move the file to the Include directory 3. update Makefile.pre.in to point to the new location Just I have read this now 10 times or so and keep thinking more must be involved :-) [certainly given my embarrassing start to the Python dev community re:asynchronous thread exceptions :-| ] I have attached a patch that does this. Though at this time it is lacking any documentation that will state what parts of "struct tok_state" are private and public. I will need to trawl the code some more to do that. I have executed: - ./configure - make - make test And all proceed well. -- keywords: +patch nosy: +kirkshorts Added file: http://bugs.python.org/file10961/issue3353.diff ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3353> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3353] make built-in tokenizer available via Python C API
Andy <[EMAIL PROTECTED]> added the comment: Did that and it builds fine. So my test procedure was: - checkout clean source - apply patch as per guidelines - remove the file Psrser/tokenizer.h (*) - ./configure - make - ./python setup.py install Build platform: Ubuntu , gcc 4.2.3 All works fine. thanks for the extra test files. * - one question though. I removed the file using 'svn remove' but the diff makes it an empty file not removed why is that? (and is it correct?) ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3353> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3713] Compile warning for Objects/stringlib
New submission from Andy <[EMAIL PROTECTED]>: Checked out the PY3K branch and built. Received a warning about "characters after #ifdef ignored" from Objects/stringlib/find.h the line in question is: #ifdef STRINGLIB_WANT_CONTAINS_OBJ && !defined(FROM_BYTEARRAY) Which is likely to mean that it will not do what is expected. System is Ubuntu using GCC (otoh can't remember full compiler spec will post in later) Patch to follow that modifies the above line to: #if defined(STRINGLIB_WANT_CONTAINS_OBJ) && !defined(FROM_BYTEARRAY) and will change the comment on the closing #endif too. hope component choice is correct -- components: Library (Lib) messages: 72087 nosy: kirkshorts severity: normal status: open title: Compile warning for Objects/stringlib versions: Python 3.0 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3713> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3713] Compile warning for Objects/stringlib
Andy <[EMAIL PROTECTED]> added the comment: patch for issue attached. gcc -v => gcc version 4.2.3 (Ubuntu 4.2.3-2ubuntu7) tests: ./runtests.sh => 0 BAD 297 GOOD 27 SKIPPED 324 total -- keywords: +patch Added file: http://bugs.python.org/file11291/issue3713.patch ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3713> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4279] Module 'parser' fails to build
New submission from Andy <[EMAIL PROTECTED]>: With a clean checkout of the py3k source it fails to build the Parser exension module (based on Modules/parsermodule.c) when building against a cygwin target. This appears to be related to the movement of the symbol _PyParser_Grammar from graminit.c to Parser\metagrammar.c. (At least this is where it was going by the code comments) Because of this the module now requires Parser\metagrammar.c to get this information via Py_meta_grammar. The patch modifies setup.py to add the required file and modifies parsermodule.c to use the accessor function. (This fails on a clean trunk build in the same way as well - which makes me very suspicious that this is not a "real" issue as the buildbots seem to be green.) My gut feeling is that my modification to setup.py for the module is incorrect - it just looks messy. So I await the inevitable: "That's not how to fix it" :-) -- components: Extension Modules files: parsermodule_fix.diff keywords: patch messages: 75603 nosy: kirkshorts severity: normal status: open title: Module 'parser' fails to build type: compile error versions: Python 3.0 Added file: http://bugs.python.org/file11960/parsermodule_fix.diff ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4279> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4279] Module 'parser' fails to build
Andy <[EMAIL PROTECTED]> added the comment: bah I *am* a idiot, #4288 and Christian's comments point out that I can't use 'find' & 'xargs' properly :-( Will modify patch to use the correct grammar file &c. (and maybe one day I might actually say something sensible to do with Python development :-) ) ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4279> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4279] Module 'parser' fails to build
Changes by Andy <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file11960/parsermodule_fix.diff ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4279> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4279] Module 'parser' fails to build
Andy <[EMAIL PROTECTED]> added the comment: a new patch that will use the grammar definition from Python/graminit.c - it is as of yet untested for Cygwin (can't get to that machine right now). It follows the same pattern as the previous, i.e. it makes us of an accessor function to get the grammar definition. This has expanded the patch somewhat to include changes to: - setup.py for Cygwin environment. - Parser/pgenmain.c to write out the function body - Python/pythonrun.c to use the new function - Include/grammar.h to declare the new function - Modules/parsermodule.c to use the new function All of which makes me think that the change to make the symbol "public" and use it directly without hiding it is a better way to go. Will look at this under my Cygwin environment tomorrow. (I have run a configre - make - test cycle on Ubuntu (hardy heron) and it is OK [but then its not broken there anyway :-) ] ) Added file: http://bugs.python.org/file11970/nu_diff.txt ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4279> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4288] parsermodule and grammar variable
Andy <[EMAIL PROTECTED]> added the comment: looks like it might be a similar root issue to the one I raised in #4279. Looks like this patch breaks the data hiding that I think has been attempted :-( though it doesn't mess with setup.py in the way mine does :-) Don't know how Christian's comment affects either of our patches though (still an uber newbie to the whole contributing to Python thing ;-) ) -- nosy: +kirkshorts ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4288> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4288] parsermodule and grammar variable
Andy <[EMAIL PROTECTED]> added the comment: Christian: sorry my 'find' kung fu is weak :-( :-$ I see why. Will work on a better patch. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4288> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4279] Module 'parser' fails to build
Andy <[EMAIL PROTECTED]> added the comment: Martin: Looking at it I agree with you 100% - the patch is too complicated for what it is intending to resolve. It simply does not need another accessor function to muddy the waters when making the symbol public as done in #4288 resolves the issue. My personal preference is to try to hide such data structures - but that doesn't always mean its the correct thing to do :-) ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4279> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4288] parsermodule and grammar variable
Andy <[EMAIL PROTECTED]> added the comment: Christian: Cool, thanks for the feedback d00d - it took longer than i though to get what I predicted :-) No worries on the whole "core target" platform thing - I understand it perfectly, had the same issue for work related things: too many platform and too few test resources :-( And sadly I am in not a position to gift any to the cause - sorry. Can I ask how it would mean that parser would get a different grammar? In the interests of a newbie learning if you don't mind (maybe post the reply to #4279 as I guess it is more relevant there than here) ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4288> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37871] 40 * 473 grid of "é" has a single wrong character on Windows
New submission from ANdy :
# To reproduce:
# Put this text in a file `a.py` and run `py a.py`.
# Or just run: py -c "print(('é' * 40 + '\n') * 473)"
# Scroll up for a while. One of the lines will be:
# ��ééé
# (You can spot this because it's slightly longer than the other lines.)
# The error is consistently on line 237, column 21 (1-indexed).
# The error reproduces on Windows but not Linux. Tested in both powershell and
CMD.
# (Failed to reproduce on either a real Linux machine or on Ubuntu with WSL.)
# On Windows, the error reproduces every time consistently.
# There is no error if N = 472 or 474.
N = 473
# There is no error if W = 39 or 41.
# (I tested with console windows of varying sizes, all well over 40 characters.)
W = 40
# There is no error if ch = "e" with no accent.
# There is still an error for other unicode characters like "Ö" or "ü".
ch = "é"
# There is no error without newlines.
s = (ch * W + "\n") * N
# Assert the string itself is correct.
assert all(c in (ch, "\n") for c in s)
print(s)
# There is no error if we use N separate print statements
# instead of printing a single string with N newlines.
# Similar scripts written in Groovy, JS and Ruby have no error.
# Groovy: System.out.println(("é" * 40 + "\n") * 473)
# JS: console.log(("é".repeat(40) + "\n").repeat(473))
# Ruby: puts(("é" * 40 + "\n") * 473)
--
components: Windows
messages: 349837
nosy: anhans, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: 40 * 473 grid of "é" has a single wrong character on Windows
type: behavior
versions: Python 3.7
___
Python tracker
<https://bugs.python.org/issue37871>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31809] ssl module unnecessarily pins the client curve when using ECDH
Andy added the comment: While debugging I reproduced this on - 'OpenSSL 1.1.0f 25 May 2017' - 'OpenSSL 1.0.1f 6 Jan 2014' - and 'BoringSSL', latest. using Python 2.7.12, 2.7.13, 2.7.6 and 3.5.3. This was all on Debian. Note that since I used Python <2.7.14 (or equivalent for 3.x) for all tests, the check "... && !defined(OPENSSL_VERSION_1_1)" is missing and therefore the bug *always* triggers regardless of OpenSSL version. I'm not sure I agree that this one curve is a good default. Note that openssl has 81 curves currently (openssl ecparam -list_curves) and probably can use most of them to connect to a server - accommodating a variety of server setups. Restricting this list to one single curve seems suboptimal. Think about it like this, if tomorrow we find an issue with that particular curve, all servers can just migrate to a different one and all clients will be able to connect just fine - except those that use Python, they will not be able to talk to those servers ever again until they are upgraded. I mean in the end it's your call but having a *client* just accepting one single security parameter and nothing else doesn't seem right. -- ___ Python tracker <https://bugs.python.org/issue31809> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31809] ssl module unnecessarily pins the client curve when using ECDH
Andy added the comment: Thanks for adding the test! If the official stance is that only the latest OpenSSL is supported then this is definitely WAI. Sounds like a good policy... I'll close this issue. -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue31809> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5166] ElementTree and minidom don't prevent creation of not well-formed XML
Andy added the comment: I'm also of the opinion that this would be a valuable feature to have. I think it's a reasonable expectation that an XML library produces valid XML. It's particularly strange that ET would output XML that it can't itself read. Surely the job of making the input valid falls on the XML creator - that's the point of using libraries in the first place, to abstract away from details like not being able to use characters in the 0-32 range, in the same way that ampersands etc are auto-escaped. Granted, it's not as clear-cut here since the low-range ASCII characters are likely to be less frequent and the strategy to handle them is less clear. I think the sanest behaviour would be to raise an exception by default, although a user-configurable option to replace or omit the characters would also make sense. If impacting performance is a concern, maybe it would make sense to be off by default, but I would have thought that the single regex that could perform the check would have relatively minimal impact - and it seems to be an acceptable overhead on the parsing side, so why not on generation? -- nosy: +strangefeatures ___ Python tracker <http://bugs.python.org/issue5166> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42548] debugger stops at breakpoint of `pass` that is not actually reached
Andy S added the comment: Can reproduce this on 3.9. Is the fact 3.9 is in `bugfix` status enough to backport any fixing changes from 3.11 (if that's true and the bug was fixed)? -- ___ Python tracker <https://bugs.python.org/issue42548> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42548] debugger stops at breakpoint of `pass` that is not actually reached
Andy S added the comment: Then maybe those RMs (for 3.9 and 3.10) should decide on their own? That should mean the bug should be reopened for them to get assigned to. -- ___ Python tracker <https://bugs.python.org/issue42548> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1235] CGIHTTPRequestHandler.run_cgi() does not run on Windows if sys.executable contains blanks
New submission from Andy Schumann: On Windows a path can contain spaces (e.g. C:\Program Files\python22 \python.exe). If using popenx each component in a command line has therefore to be double quoted as well as the whole command string. The method run_cgi() of the class CGIHTTPRequestHandler in the module CGIHTTPServer does not do this. Therefore the line 236: cmdline = "%s -u %s" % (interp, cmdline) should be replaced by cmdline = '""%s" -u "%s""' % (interp, cmdline) -- components: Windows messages: 56229 nosy: schu severity: normal status: open title: CGIHTTPRequestHandler.run_cgi() does not run on Windows if sys.executable contains blanks versions: Python 2.3 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1235> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12584] win.protocol('WM_DELETE_WINDOW'...) still deletes window on OSX
New submission from Andy Wildenberg :
This was originally posted on
http://stackoverflow.com/questions/1800452/how-to-intercept-wm-delete-window-on-osx-using-tkinter
but seems not to have been reported as a bug.
On OS X (10.6.8, python 2.6.1) register a protocol on 'WM_DELETE_WINDOW'. Your
callback will get called when the user clicks on the red "kill" icon in the
top-left of the window, but the window will still be destroyed. The same file
on Python 2.6.5 Linux behaves as it should, i.e. the "kill" icon is effectively
disabled on the "win" window.
--
assignee: ronaldoussoren
components: Macintosh, Tkinter
files: bug.py
messages: 140624
nosy: Andy.Wildenberg, ronaldoussoren
priority: normal
severity: normal
status: open
title: win.protocol('WM_DELETE_WINDOW'...) still deletes window on OSX
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file22689/bug.py
___
Python tracker
<http://bugs.python.org/issue12584>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
Changes by Andy Buckley : -- nosy: +andybuckley ___ Python tracker <http://bugs.python.org/issue2292> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11339] annotation for class being defined
New submission from Andy Harrington : You cannot make a self-referential annotation like class Graph: def reverse(self) -> Graph: # ... This corresponds to a common coding situation. -- components: Interpreter Core messages: 129587 nosy: andyharrington priority: normal severity: normal status: open title: annotation for class being defined type: feature request versions: Python 3.3 ___ Python tracker <http://bugs.python.org/issue11339> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue858809] Use directories from configure rather than hardcoded
Changes by Andy Buckley : -- nosy: +andybuckley ___ Python tracker <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 : -- nosy: +andybuckley ___ Python tracker <http://bugs.python.org/issue1294959> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5755] "-Wstrict-prototypes" is valid for Ada/C/ObjC but not for C++"
Changes by Andy Bailey : -- nosy: +GooseYArd ___ Python tracker <http://bugs.python.org/issue5755> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4953] cgi module cannot handle POST with multipart/form-data in 3.x
Andy Harrington added the comment: I found a similar issue. If you want more simple files demonstrating the issue, I have attached some. If I start my localCGIServer.py, then I can use adder.html fine (uses get), but with adderpost.html (uses post) the cgi action file, adder.cgi (that worked fine with the get version) hangs. -- nosy: +andyharrington Added file: http://bugs.python.org/file20392/localCGIServer.py ___ Python tracker <http://bugs.python.org/issue4953> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4953] cgi module cannot handle POST with multipart/form-data in 3.x
Changes by Andy Harrington : Removed file: http://bugs.python.org/file20392/localCGIServer.py ___ Python tracker <http://bugs.python.org/issue4953> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4953] cgi module cannot handle POST with multipart/form-data in 3.x
Changes by Andy Harrington : Added file: http://bugs.python.org/file20393/adder.html ___ Python tracker <http://bugs.python.org/issue4953> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4953] cgi module cannot handle POST with multipart/form-data in 3.x
Changes by Andy Harrington : Added file: http://bugs.python.org/file20394/adderpost.html ___ Python tracker <http://bugs.python.org/issue4953> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4953] cgi module cannot handle POST with multipart/form-data in 3.x
Changes by Andy Harrington : Added file: http://bugs.python.org/file20395/localCGIServer.py ___ Python tracker <http://bugs.python.org/issue4953> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4953] cgi module cannot handle POST with multipart/form-data in 3.x
Changes by Andy Harrington : Added file: http://bugs.python.org/file20396/adder.cgi ___ Python tracker <http://bugs.python.org/issue4953> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2950] silly readline module problem
New submission from Andy Novocin <[EMAIL PROTECTED]>: I installed python 2.5.2 on my SUSE 10.3 system which came with 2.4.4 and when you type import readline it returns No module named readline. When installing I just unzipped, ./configure, make, sudo make install. Im brand new to Linux and Python (probably clearly). -- components: Extension Modules messages: 67236 nosy: AndyNovo severity: normal status: open title: silly readline module problem versions: Python 2.5 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2950> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3570] str.find docstring typo
New submission from Andy Harrington <[EMAIL PROTECTED]>:
When you enter help("".find)
you get
...
such that sub is contained within s[start,end]
...
s[start, end] makes no sense. It should be s[start:end].
--
assignee: georg.brandl
components: Documentation
messages: 71240
nosy: andyharrington, georg.brandl
severity: normal
status: open
title: str.find docstring typo
versions: Python 2.5
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3570>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3704] cookielib doesn't handle URLs with / in parameters
New submission from Andy Kilpatrick <[EMAIL PROTECTED]>:
cookielib doesn't handle URLs like "http://server/script?
err=/base/error.html&ok=/base/ok.html", as
CookieJar::_cookie_from_cookie_tuple uses rfind("/") to strip off the
end of the URL, returning "http://server/script?
err=/base/error.html&okc=/base" instead of "http://server/script";.
My suggested fix (attached, line 1465-1468) is to first strip off
anything after "?" if present, then continue as with existing code.
--
components: None
files: cookielib.py
messages: 72035
nosy: andyk
severity: normal
status: open
title: cookielib doesn't handle URLs with / in parameters
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file11271/cookielib.py
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3704>
___
___
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 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 <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 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
<http://bugs.python.org/issue4256>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8379] if __debug__: has nonobvious behaviour when evaluating .pyo without -O
New submission from Andy Friesen :
In certain circumstances, "if __debug__" seems to be evaluating its "else"
clause even when -O is not specified. This can cause very surprising behavior.
a.zip contains a single file named a/__init__.pyo. It is the compiled form of
the following code:
if __debug__:
print 'DEBUG'
else:
print 'RELEASE'
if __debug__ == True:
raise Exception("this is impossible")
pythonbug.py evaluates this script with the following:
import sys
sys.path = ['a.zip']
import a
When using Windows Python 2.6.2 and 2.6.5, running pythonbug.py produces this
output:
RELEASE
Traceback (most recent call last):
File "pythonbug.py", line 3, in
import a
File "__init__.py", line 8, in
raise Exception("this is impossible")
Exception: this is impossible
When -O is passed, the exception is not raised.
My best guess is that the Python bytecode is optimizing the "if __debug__" test
away in the produced .pyo, but does not actually affect the value of __debug__
or check more complex expressions involving __debug__.
--
files: pythonbug.zip
messages: 102975
nosy: afriesen
severity: normal
status: open
title: if __debug__: has nonobvious behaviour when evaluating .pyo without -O
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file16901/pythonbug.zip
___
Python tracker
<http://bugs.python.org/issue8379>
___
___
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 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 <http://bugs.python.org/issue4256> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2398] test_errno fails with unexpected error value EREMOTEIO
New submission from Andy Balaam <[EMAIL PROTECTED]>: Running test_errno on my 32-bit Ubuntu Gutsy machine gives me this: $ ./python Lib/test/test_errno.py test_for_improper_attributes (__main__.ErrnoAttributeTests) ... FAIL test_using_errorcode (__main__.ErrnoAttributeTests) ... ok test_attributes_in_errorcode (__main__.ErrorcodeTests) ... ok == FAIL: test_for_improper_attributes (__main__.ErrnoAttributeTests) -- Traceback (most recent call last): File "Lib/test/test_errno.py", line 46, in test_for_improper_attributes "%s is an unexpected error value" % attribute) AssertionError: EREMOTEIO is an unexpected error value -- Ran 3 tests in 0.001s FAILED (failures=1) Traceback (most recent call last): File "Lib/test/test_errno.py", line 68, in test_main() File "Lib/test/test_errno.py", line 64, in test_main test_support.run_unittest(ErrnoAttributeTests, ErrorcodeTests) File "/home/andy/cvs/python/Lib/test/test_support.py", line 573, in run_unittest _run_suite(suite) File "/home/andy/cvs/python/Lib/test/test_support.py", line 556, in _run_suite raise TestFailed(err) test.test_support.TestFailed: Traceback (most recent call last): File "Lib/test/test_errno.py", line 46, in test_for_improper_attributes "%s is an unexpected error value" % attribute) AssertionError: EREMOTEIO is an unexpected error value I've attached a patch which changes test_errno.py so that its list of expected errors exactly matches the possible errors listed in Modules/errnomodule.c in the latest SVN trunk. I don't know whether this is the right solution, but the patch is there if it is :) Apologies if I've misunderstood something, or formatted the patch wrong etc. This is my first Python patch. -- components: Tests files: add_more_error_values_to_test_errno.patch keywords: patch messages: 63934 nosy: andybalaam severity: normal status: open title: test_errno fails with unexpected error value EREMOTEIO type: behavior versions: Python 3.0 Added file: http://bugs.python.org/file9730/add_more_error_values_to_test_errno.patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2398> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2398] test_errno fails with unexpected error value EREMOTEIO
Andy Balaam <[EMAIL PROTECTED]> added the comment: Adding Brett Cannon since it looks like his checkin created the test which fails on my machine. Apologies if this is very bad etiquette. I couldn't find any guidelines about this in the developers' docs, but probably that's because I am incompetent. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2398> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2398] test_errno fails with unexpected error value EREMOTEIO
Andy Balaam <[EMAIL PROTECTED]> added the comment: Woah! fast response, and what looks like a much more sensible fix. Thanks Brett. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2398> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1038909] pydoc method documentation lookup enhancement
Andy Harrington <[EMAIL PROTECTED]> added the comment: After going to the sprint Monday, I am working on this as my first patch. There is no test file for pydoc. ?? -- nosy: +andyharrington _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1038909> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1038909] pydoc method documentation lookup enhancement
Andy Harrington <[EMAIL PROTECTED]> added the comment: Several points: Additional note in pydoc output: I thought that 'inherited' docs should be marked, so I chose to add to the note for any function that gets docs displayed from an inherited function: ', docs from inherited ' Alternate verbiage could certainly be used, but I strongly believe that the substitution should be marked and its source indicated. This addition occurs in HTMLDoc.docroutine and TextDoc.docroutine. Elaboration? If a user just calls help() or help(), this patch is certainly appropriate. On the other hand, if the call is help(), and the module includes the definitions of the inherited classes from which documentation is 'inherited', then there is duplication within the output, which the user might or might not desire. To allow a choice would require a change in parameters or a global flag in pydoc. A global flag like allow_doc_redundancy could be set to False to block inherited documentation when the ancestor function is already putting a copy of the documentation in the output. I would be happy to add this change if requested, but I thought it would be presumptuous of me to just add it to the requested patch. Testing I added a test specifically for the inherited docs, test.test_pydoc_inheritance, generating documentaton on test.test_pydoc_sample and comparing results to previously generated results files test/test_pydoc.txt and test/test_pydoc.html. If further changes to pydoc cause outward change to the documentation format, run test_pydoc_inheritance.regenerateData() to replace the result files. Nothing in the patch in 2.6 dependent. Users could choose to upgrade pydoc for 2.5.x Added file: http://bugs.python.org/file9823/pydoc.PATCH _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1038909> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1038909] pydoc method documentation lookup enhancement
Changes by Andy Harrington <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file9823/pydoc.PATCH _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1038909> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1038909] pydoc method documentation lookup enhancement
Andy Harrington <[EMAIL PROTECTED]> added the comment: HM, before writing my patch I tested pydoc to see the issue was still there. I did not look at the 2004 patch from aschmolck since it was so old and was clearly not implemented, and brett just listed this issue as one to deal with in 2008. Now I see pydoc.py.PATCH does address the same issue. Comments on the differences: 1. I allow for the case that an ancestor uses the name but not as a method. That *should* stop the search. 2. The 2004 patch does not use inspect.ismethod, but creates its own test. 3. I stuck with the original pydoc convention that comments could substitute for docs. The 2004 patch does not look for comments in ancestors and only uses comments in the current method if no ancestor has docs. That is a difference in design that could be discussed. I am OK with either. 4. The 2004 patch makes its substitution silently. I prefer explicitly noting that the docs are 'inherited'. 5. There is nothing to add to the test package in the 2004 patch. Before looking at the 2004 patch, I replaced my last patch. I just reread the Python source and documentation conventions and changed names and documentation to match. The only change to my previous comments is that test_pydoc_inheritance.regenerateData was renamed test_pydoc_inheritance.regenerate_data One related comment after thinking about the style guides: Should this pydoc change affect the style guide? Is duplication in the source code recommended for 'inherited' docs? Rather than say absolutely nothing in the overriding method, would a standard comment #inherit docs make sense in the source code? In that case a further change to pydoc is needed to recognize this as a special case, where the 'inherited' docs should be substituted. Alternately the search sequence followed in the 2004 patch could be used, which would find the inherited docs before the comment, whatever the comment. Added file: http://bugs.python.org/file9834/pydoc2.PATCH _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1038909> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1038909] pydoc method documentation lookup enhancement
Andy Harrington <[EMAIL PROTECTED]> added the comment: Alexander, I have no idea why your patch languished. On the one hand I might have skipped this if I realized that before. On the other hand, I did add something extra, and I might not have had an open mind if I had looked at yours. Plus, maybe I got it moving! :) You made a good enhancement suggestion. From the continuing interchange below, it looks like two minds are better than either one. Comments on your comments on mine: 2. Hm, good point. I do not think pydoc should substitute for PyLint, but it only makes sense to copy the docs from the same type of function in an ancestor class: static, class or method, though you are right it need not matter whether the ancestor is built-in or not, though the assumption is made that you know about built-in docs - you might only note the inheritance. And again, as I did it, finding any ancestor of the wrong type should stop the search. There is one inconsistency with static method docs: If we are given a class, and have a static method in it, we can search the inheritance chain for docs. Neither of us does this at present, though it looks easier to add through my access point in docroutine. On the other hand, if the top-level request is just to document a static function, there is a problem, since you cannot identify the class it comes from, not having an im_class attribute, and hence the documentation may look different from when it was just a part of the documentation for the class. I do not see this as a reason to skip the inheritance chain for a static method when given it's class: better information in -> better information out. 3. I agree people should use doc strings not comments, but if everyone did that, our versions would have the same effect. The only difference is if the coder *does* want to use comments for some reason. Hence the question is: do you want to document what people do or push them to code the way you want? Ping apparently chose the former approach, so I am not suggesting changing it. Thanks, Andy _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1038909> _ ___ 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
[issue4672] Distutils SWIG support blocks use of SWIG -outdir option
New submission from Andy Buckley :
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
<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 : 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 <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 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 <http://bugs.python.org/issue1479255> ___ ___ 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 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 <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 : 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 <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 : 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 <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 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 <http://bugs.python.org/issue5070> ___ ___ 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 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 <http://bugs.python.org/issue4673> ___ ___ 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 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 <http://bugs.python.org/issue4151> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43828] MappingProxyType accepts string
New submission from Andy Maier :
MappingProxyType objects can currently be initialized from a string object.
Given is purpose, I think this is a bug and should result in TypeError being
raised.
Example code (on CPython 3.9.1):
>>> from types import MappingProxyType
>>> mp = MappingProxyType('abc')
>>> list(mp)
['a', 'b', 'c']
>>> mp.items()
Traceback (most recent call last):
File "", line 1, in
AttributeError: 'str' object has no attribute 'items'
Other invalid input types are properly checked:
>>> mp = MappingProxyType(42)
Traceback (most recent call last):
File "", line 1, in
TypeError: mappingproxy() argument must be a mapping, not int
>>> mp = MappingProxyType(['a'])
Traceback (most recent call last):
File "", line 1, in
TypeError: mappingproxy() argument must be a mapping, not list
>>> mp = MappingProxyType(('a',))
Traceback (most recent call last):
File "", line 1, in
TypeError: mappingproxy() argument must be a mapping, not tuple
--
components: Library (Lib)
messages: 390935
nosy: andymaier
priority: normal
severity: normal
status: open
title: MappingProxyType accepts string
versions: Python 3.9
___
Python tracker
<https://bugs.python.org/issue43828>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43828] MappingProxyType accepts string
Change by Andy Maier : -- type: -> behavior ___ Python tracker <https://bugs.python.org/issue43828> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43829] MappingProxyType cannot hash a hashable underlying mapping
New submission from Andy Maier :
Objects of MappingProxyType do expose a __hash__() method, but if the
underlying mapping is hashable, it still does not support hashing it.
Example:
Content of mp_hash.py:
--
#!/usr/bin/env python
from nocasedict import NocaseDict, HashableMixin
from types import MappingProxyType
class HashableDict(HashableMixin, NocaseDict):
"""A hashable dictionary"""
pass
hd = HashableDict({'a': 1, 'b': 2})
print("hash(hd): {}".format(hash(hd)))
mp = MappingProxyType(hd)
print("hash(mp): {}".format(hash(mp)))
---
Running the mp_hash.py script:
hash(hd): 3709951335832776636
Traceback (most recent call last):
File
"/Users/maiera/Projects/Python/cpython/issues/mappingproxy/./mp_hash.py", line
14, in
print("hash(mp): {}".format(hash(mp)))
TypeError: unhashable type: 'mappingproxy'
There are use cases where a function wants to return an immutable view on an
internal dictionary, and the caller of the function should be able to use the
returned object like a dictionary, except that it is read-only.
Note there is https://bugs.python.org/issue31209 on the inability to pickle
MappingProxyType objects which was closed without adding the capability. That
would fall under the same argument.
--
components: Library (Lib)
messages: 390936
nosy: andymaier
priority: normal
severity: normal
status: open
title: MappingProxyType cannot hash a hashable underlying mapping
type: behavior
versions: Python 3.9
___
Python tracker
<https://bugs.python.org/issue43829>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43828] MappingProxyType accepts string
Andy Maier added the comment:
I accept that the issue was closed, but wanted to document some things:
1. The dict class manages very well to detect that a string is invalid input:
>>> d = dict('abc')
Traceback (most recent call last):
File "", line 1, in
ValueError: dictionary update sequence element #0 has length 1; 2 is required
2. When initialized with strings, it looses some of its dictionary methods, but
does a quite reasonable job in pointing that out in the error message:
>>> mp = MappingProxyType('abc')
>>> mp.items()
Traceback (most recent call last):
File "", line 1, in
AttributeError: 'str' object has no attribute 'items'
--
___
Python tracker
<https://bugs.python.org/issue43828>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43858] Provide method to get list of logging level names
New submission from Andy Lowry : It would be useful to have something like a `getLevelNames` method to return the current list of level names, ordered by priority. This currently appears to be available only by accessing a private member, like `_levelToName` or `_nameToLevel`. This functionality is useful, for example, in populating a `choices` list for an `argparse` option to allow a user to select a logging level when launching a program from a command line. -- components: Library (Lib) messages: 391145 nosy: andylowry priority: normal severity: normal status: open title: Provide method to get list of logging level names versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue43858> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43912] http.client.BadStatusLine raised and response contains request
New submission from Andy Maier : Hello, we have a nasty occurrence of BadStatusLine that shows the status line of the request(!!) in one of our projects. That exception is raised when checking a response and should check the response, not the request. Further debugging revealed that not only the status line is from the request, but also the headers and the body of the response are from the request when this error happens. Example exception when using http.client to send the requests: http.client.BadStatusLine: POST http://localhost:5 HTTP/1.1 I have created a standalone script that can be used to reproduce the behavior. The script can use http.client or the requests package for sending the requests. The server is a threaded HTTP server. The script needs to be run multiple times to reproduce the error. On my local system, the error showed up pretty reliably within the first 50 repetitions of the script. The header comment of the script explains the details. If http.client is chosen to be used, the script is purely based on standard Python library functions. The error shows up on all CPython versions I tried, up to 3.9. -- components: Library (Lib) files: badstatusline.py messages: 391601 nosy: andymaier priority: normal severity: normal status: open title: http.client.BadStatusLine raised and response contains request type: behavior versions: Python 3.9 Added file: https://bugs.python.org/file49971/badstatusline.py ___ Python tracker <https://bugs.python.org/issue43912> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43912] http.client.BadStatusLine raised and response contains request
Andy Maier added the comment: I should have added that my local system is macOS, and that "up to 3.9" means I only tried up to 3.9. -- ___ Python tracker <https://bugs.python.org/issue43912> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44070] Regression with relative paths in sys.path in python 3.8.10
Andy Fiddaman added the comment: I've just found this while investigating a regression with my project following update to 3.9.5. It took me some time to discover that the new test failures were due to __file__ now being fully qualified when it wasn't before. As far as I can tell so far it is just breaking the tests, not the software (https://github.com/omniosorg/pkg5) but this doesn't feel like a change that should be made in a minor release. -- nosy: +omnios ___ Python tracker <https://bugs.python.org/issue44070> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43858] Provide method to get list of logging level names
Andy Lowry added the comment: @andrei.avk Yes, that sounds just fine. Many thanks. -- ___ Python tracker <https://bugs.python.org/issue43858> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38810] SSL connect() raises SSLError "[SSL] EC lib (_ssl.c:728)"
New submission from Andy Maier : A user of our pywbem package gets an SSLError with message "[SSL] EC lib (_ssl.c:728)" when invoking the connect() method on an SSL wrapped socket. See https://github.com/pywbem/pywbem/issues/1950. The issue is that with this error message, it is not possible for us to figure out what the problem is and how to correct it. This happens with CPython 3.5. I have tried to find the place in _ssl.c (https://github.com/python/cpython/blob/3.5/Modules/_ssl.c) where a string "EC lib" or " lib" is created but did not find it there. I have two requests: 1. Please explain what the reason is for this exception and what to change in the environment to make it work. 2. Please improve the message in this exception so that it is self-explanatory. -- assignee: christian.heimes components: SSL messages: 356654 nosy: andymaier, christian.heimes priority: normal severity: normal status: open title: SSL connect() raises SSLError "[SSL] EC lib (_ssl.c:728)" versions: Python 3.5 ___ Python tracker <https://bugs.python.org/issue38810> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38810] SSL connect() raises SSLError "[SSL] EC lib (_ssl.c:728)"
Andy Maier added the comment: More details about the environment this happens on: Python 3.5.7 (default, Aug 16 2019, 10:17:32) [GCC 4.4.7 20120313 (Red Hat 4.4.7-4)] on linux -- ___ Python tracker <https://bugs.python.org/issue38810> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38810] SSL connect() raises SSLError "[SSL] EC lib (_ssl.c:728)"
Andy Maier added the comment: Our user was able to fix this issue by upgrading the OpenSSL version used on the client side from 1.0.1e-fips to 1.1.1. It seems to me that Python's SSL support cannot do anything about this issue. As far as I'm concerned ths issue can be closed. -- ___ Python tracker <https://bugs.python.org/issue38810> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38810] SSL connect() raises SSLError "[SSL] EC lib (_ssl.c:728)"
Andy Maier added the comment: Thanks for the help, Christian! -- ___ Python tracker <https://bugs.python.org/issue38810> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39127] _Py_HashPointer's void * argument should be const
New submission from Andy Lester : _Py_HashPointer in Python/pyhash.c takes a pointer argument that can be made const. This will let compiler and static analyzers know that the pointer's target is not modified. You can also change calls to _Py_HashPointer that are down-casting pointers. For example, in meth_hash in Objects/methodobject.c, this call can have the void * changed to const void *. y = _Py_HashPointer((void*)(a->m_ml->ml_meth)); -- components: Interpreter Core messages: 358839 nosy: petdance priority: normal severity: normal status: open title: _Py_HashPointer's void * argument should be const ___ Python tracker <https://bugs.python.org/issue39127> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39127] _Py_HashPointer's void * argument should be const
Change by Andy Lester : -- keywords: +patch pull_requests: +17145 stage: -> patch review pull_request: https://github.com/python/cpython/pull/17690 ___ Python tracker <https://bugs.python.org/issue39127> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39150] See if PyToken_OneChar would be faster as a lookup table
New submission from Andy Lester : PyToken_OneChar in Parser/token.c is autogenerated. I suspect it may be faster and smaller if it were a lookup into a static table of ops rather than a switch statement. Check to see if it is. -- components: Interpreter Core messages: 358975 nosy: petdance priority: normal severity: normal status: open title: See if PyToken_OneChar would be faster as a lookup table type: enhancement ___ Python tracker <https://bugs.python.org/issue39150> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39150] See if PyToken_OneChar would be faster as a lookup table
Andy Lester added the comment: Thank you. I appreciate the pointer. -- ___ Python tracker <https://bugs.python.org/issue39150> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39146] too much memory consumption in re.compile unicode
Change by Andy Lester : -- components: +Regular Expressions -Library (Lib) nosy: +ezio.melotti, mrabarnett ___ Python tracker <https://bugs.python.org/issue39146> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39150] See if PyToken_OneChar would be faster as a lookup table
Andy Lester added the comment:
I tried out some experimenting with the lookup table vs. the switch
statement.
The relevant diff (not including the patches to the code generator) is:
--- Parser/token.c
+++ Parser/token.c
@@ -77,31 +77,36 @@
int
PyToken_OneChar(int c1)
{
-switch (c1) {
-case '%': return PERCENT;
-case '&': return AMPER;
-case '(': return LPAR;
-case ')': return RPAR;
-case '*': return STAR;
-case '+': return PLUS;
-case ',': return COMMA;
-case '-': return MINUS;
-case '.': return DOT;
-case '/': return SLASH;
-case ':': return COLON;
-case ';': return SEMI;
-case '<': return LESS;
-case '=': return EQUAL;
-case '>': return GREATER;
-case '@': return AT;
-case '[': return LSQB;
-case ']': return RSQB;
-case '^': return CIRCUMFLEX;
-case '{': return LBRACE;
-case '|': return VBAR;
-case '}': return RBRACE;
-case '~': return TILDE;
-}
+static char op_lookup[] = {
+OP,OP,OP,OP,OP,
+OP,OP,OP,OP,OP,
+OP,OP,OP,OP,OP,
+OP,OP,OP,OP,OP,
+OP,OP,OP,OP,OP,
+OP,OP,OP,OP,OP,
+OP,OP,OP,OP,OP,
+OP,OP,PERCENT, AMPER, OP,
+LPAR, RPAR, STAR, PLUS, COMMA,
+MINUS, DOT, SLASH, OP,OP,
+OP,OP,OP,OP,OP,
+OP,OP,OP,COLON, SEMI,
+LESS, EQUAL, GREATER, OP,AT,
+OP,OP,OP,OP,OP,
+OP,OP,OP,OP,OP,
+OP,OP,OP,OP,OP,
+OP,OP,OP,OP,OP,
+OP,OP,OP,OP,OP,
+OP,LSQB, OP,RSQB, CIRCUMFLEX,
+OP,OP,OP,OP,OP,
+OP,OP,OP,OP,OP,
+OP,OP,OP,OP,OP,
+OP,OP,OP,OP,OP,
+OP,OP,OP,OP,OP,
+OP,OP,OP,LBRACE,VBAR,
+RBRACE,TILDE
+};
+if (c1>=37 && c1<=126)
+return op_lookup[c1];
return OP;
}
To test the speed change, I couldn't use pyperformance, because the only
thing I wanted to time was the In my testing, I didn't use pyperformance
because the only part of the code I wanted to test was the actual
compilation of the code. My solution for this was to find the 100 largest
*.py files in the cpython repo and compile them like so:
python -m py_compile $(List-of-big-*.py-files)
The speedup was significant: My table-driven lookup ran the compile tests
about 10% than the existing switch approach. That was without
--enable-optimizations in my configure.
However, as pablogsal suspected, with PGO enabled, the two approaches ran
the code in pretty much the same speed.
I do think that there may be merit in using a table-driven approach that
generates less code and doesn't rely on PGO speeding things up.
If anyone's interested, all my work is on branch Issue39150 in my fork
petdance/cpython.
--
___
Python tracker
<https://bugs.python.org/issue39150>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39150] See if PyToken_OneChar would be faster as a lookup table
Andy Lester added the comment:
Yes, I ran it multiple times on my 2013 Macbook Pro and got ~10% speedup. I
also ran it on my Linux VM (that I only use for development) and got a speedup
but less so.
The code I used to run the tests is at:
https://github.com/petdance/cpython/blob/Issue39150/timetests
LOG=timelog.txt
NRUNS=100
NFILES=100
if [ -x ./python.exe ] ; then
PYTHON=./python.exe
else
PYTHON=./python
fi
# Build a file list, but throw out some that have syntax errors.
# Use the 100 biggest files.
FILES=$(
find . -name '*.py' -type f -ls \
| grep -v Tools/test2to3/ \
| grep -v Lib/lib2to3/tests/ \
| grep -v Lib/test/badsyntax \
| grep -v Lib/test/bad_coding \
| sort -r -n -k7 \
| awk '{print $11}' \
| head -n $NFILES
)
echo "Compiling $NFILES files for $NRUNS iterations"
rm -f $LOG
for (( i=1; i<=$NRUNS; i++ )) do
echo "Run $i"
{ time $PYTHON -m py_compile $FILES; } >> $LOG 2>&1
done
perl -ne'if(/real\s+0m([\d.]+)s/){$t+=$1;$n++} END { printf "%d runs, average
%0.4f\n", $n, $t/$n}' $LOG
--
___
Python tracker
<https://bugs.python.org/issue39150>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39150] See if PyToken_OneChar would be faster as a lookup table
Andy Lester added the comment: Re: branch prediction. The branch if (c1>=37 && c1<=126) could just as easily be if (c1>=0 && c1<=126) with no other changes to the code. It could be just if (c1<=126) if c1 wasn't signed. As far as branch prediction, we could make it something like if (c1>=0 && c1<=255) and expand the table lookup, depending on what the likely inputs are. I could play around with that some if anyone was interested. I'm not trying to push on this. Just sharing some thoughts and research. -- ___ Python tracker <https://bugs.python.org/issue39150> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39588] Use memcpy() instead of for() loops in _PyUnicode_To*
New submission from Andy Lester : Four functions in Objects/unicodectype.c copy values out of lookup tables with a for loop int i; for (i = 0; i < n; i++) res[i] = _PyUnicode_ExtendedCase[index + i]; instead of a memcpy memcpy(res, &_PyUnicode_ExtendedCase[index], n * sizeof(Py_UCS4)); My Apple clang version 11.0.0 on my Mac optimizes away the for loop and generates equivalent code to the memcpy. gcc 4.8.5 on my Linux box (the newest GCC I have) does not optimize away the loop. The four functions are: _PyUnicode_ToLowerFull _PyUnicode_ToTitleFull _PyUnicode_ToUpperFull _PyUnicode_ToFoldedFull -- components: Unicode messages: 361636 nosy: ezio.melotti, petdance, vstinner priority: normal severity: normal status: open title: Use memcpy() instead of for() loops in _PyUnicode_To* type: performance ___ Python tracker <https://bugs.python.org/issue39588> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39150] See if PyToken_OneChar would be faster as a lookup table
Andy Lester added the comment: I'm closing this as it seems there's not much interest in this. -- stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue39150> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39588] Use memcpy() instead of for() loops in _PyUnicode_To*
Andy Lester added the comment: Thanks for replying. I figured that might be the case, which is why I made a ticket before bothering with a pull request. I've also seen this kind of thing around: i = ctx->pattern[0]; Py_ssize_t groupref = i+i; instead of Py_ssize_t groupref = ctx->pattern[0]*2; Is that also the kind of thing we would leave for the compiler to sort out? -- ___ Python tracker <https://bugs.python.org/issue39588> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39591] Functions in Python/traceback.c can take const pointer arguments
New submission from Andy Lester : The functions tb_displayline and tb_printinternal can take const pointers on some of their arguments. tb_displayline(PyObject *f, PyObject *filename, int lineno, const PyObject *name) tb_printinternal(const PyTracebackObject *tb, PyObject *f, long limit) -- components: Interpreter Core messages: 361643 nosy: petdance priority: normal severity: normal status: open title: Functions in Python/traceback.c can take const pointer arguments type: enhancement ___ Python tracker <https://bugs.python.org/issue39591> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39491] Import PEP 593 (Flexible function and variable annotations) support already implemented in typing_extensions
Change by Andy Lester : -- pull_requests: +17793 pull_request: https://github.com/python/cpython/pull/18420 ___ Python tracker <https://bugs.python.org/issue39491> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39591] Functions in Python/traceback.c can take const pointer arguments
Change by Andy Lester : -- keywords: +patch pull_requests: +17794 stage: -> patch review pull_request: https://github.com/python/cpython/pull/18420 ___ Python tracker <https://bugs.python.org/issue39591> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39491] Import PEP 593 (Flexible function and variable annotations) support already implemented in typing_extensions
Change by Andy Lester : -- pull_requests: +17797 pull_request: https://github.com/python/cpython/pull/18422 ___ Python tracker <https://bugs.python.org/issue39491> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39591] Functions in Python/traceback.c can take const pointer arguments
Change by Andy Lester : -- pull_requests: -17794 ___ Python tracker <https://bugs.python.org/issue39591> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39591] Functions in Python/traceback.c can take const pointer arguments
Change by Andy Lester : -- pull_requests: +17798 pull_request: https://github.com/python/cpython/pull/18422 ___ Python tracker <https://bugs.python.org/issue39591> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39491] Import PEP 593 (Flexible function and variable annotations) support already implemented in typing_extensions
Change by Andy Lester : -- pull_requests: +17799 pull_request: https://github.com/python/cpython/pull/18422 ___ Python tracker <https://bugs.python.org/issue39491> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39591] Functions in Python/traceback.c can take const pointer arguments
Change by Andy Lester : -- pull_requests: -17798 ___ Python tracker <https://bugs.python.org/issue39591> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39591] Functions in Python/traceback.c can take const pointer arguments
Andy Lester added the comment: I'm sorry, I think my comment was misleading. The changes I had proposed were not making the object itself const, but some of the arguments in the static worker functions. For example: -tb_displayline(PyObject *f, PyObject *filename, int lineno, PyObject *name) +tb_displayline(PyObject *f, PyObject *filename, int lineno, const PyObject *name) and -tb_printinternal(PyTracebackObject *tb, PyObject *f, long limit) +tb_printinternal(const PyTracebackObject *tb, PyObject *f, long limit) I've got -Wincompatible-pointer-types-discards-qualifiers and -Wcast-qual turned on, and no errors occur. Is there somewhere in the deep internals of the Python macros where constness can be changed but the compiler isn't reporting on it? Thanks, Andy -- ___ Python tracker <https://bugs.python.org/issue39591> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39591] Functions in Python/traceback.c can take const pointer arguments
Andy Lester added the comment: > Yes, Py_INCREF and Py_DECREF change the type, and therefore constness. Understood. The changes that I have proposed are not to objects that get sent through Py_INCREF/Py_DECREF. If they did, -Wcast-qual would have caught it. -Wcast-qual catches if you cast, say, a const char * to a char *. Let's let this stay closed and I'll resubmit with a clearer ticket & PR. -- ___ Python tracker <https://bugs.python.org/issue39591> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39605] Fix some casts to not cast away const
New submission from Andy Lester : gcc -Wcast-qual turns up a number of instances of casting away constness of pointers. Some of these can be safely modified, by either: * Adding the const to the type cast, as in: -return _PyUnicode_FromUCS1((unsigned char*)s, size); +return _PyUnicode_FromUCS1((const unsigned char*)s, size); * Removing the cast entirely, because it's not necessary (but probably was at one time), as in: -PyDTrace_FUNCTION_ENTRY((char *)filename, (char *)funcname, lineno); +PyDTrace_FUNCTION_ENTRY(filename, funcname, lineno); These changes will not change code, but they will make it much easier to check for errors in consts. -- components: Interpreter Core messages: 361780 nosy: petdance priority: normal severity: normal status: open title: Fix some casts to not cast away const type: enhancement ___ Python tracker <https://bugs.python.org/issue39605> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39605] Fix some casts to not cast away const
Change by Andy Lester : -- keywords: +patch pull_requests: +17827 stage: -> patch review pull_request: https://github.com/python/cpython/pull/18453 ___ Python tracker <https://bugs.python.org/issue39605> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39620] PyObject_GetAttrString and tp_getattr do not agree
New submission from Andy Lester : PyObject_GetAttrString(PyObject *v, const char *name) typedef PyObject *(*getattrfunc)(PyObject *, char *) The outer PyObject_GetAttrString takes a const char *name, but then casts away the const when calling the underlying tp_getattr. This means that an underlying function would be free to modify or free() the char* passed in to it, which might be, for example, a string literal, which would be a Bad Thing. The setattr function pair has the same problem. The API doc at https://docs.python.org/3/c-api/typeobj.html says that the tp_getattr and tp_setattr slots are deprecated. If they're not going away soon, I would think this should be addressed. Fixing this in the cPython code by making tp_getattr and tp_setattr take const char * pointers would be simple. I don't have any idea how much outside code it would affect. -- components: C API messages: 361929 nosy: petdance priority: normal severity: normal status: open title: PyObject_GetAttrString and tp_getattr do not agree type: enhancement ___ Python tracker <https://bugs.python.org/issue39620> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39620] PyObject_GetAttrString and tp_getattr do not agree
Andy Lester added the comment: Do you know why it was reverted? (Granted, it was 15 years ago...) It looks like the original changeset is trying to address at least two different problems with non-const string literals. My ticket here is focusing only on getattrfunc and setattrfunc. The handling of all the kwlist is a separate issue, that I'm about to write up as a different ticket. -- ___ Python tracker <https://bugs.python.org/issue39620> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39621] md5_compress() in Modules/md5module.c can take a const buf
New submission from Andy Lester : The function md5_compress does not modify its buffer argument. static void md5_compress(struct md5_state *md5, unsigned char *buf) buf should be const. -- components: Extension Modules messages: 361932 nosy: petdance priority: normal severity: normal status: open title: md5_compress() in Modules/md5module.c can take a const buf type: enhancement ___ Python tracker <https://bugs.python.org/issue39621> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39621] md5_compress() in Modules/md5module.c can take a const buf
Change by Andy Lester : -- keywords: +patch pull_requests: +17871 stage: -> patch review pull_request: https://github.com/python/cpython/pull/18497 ___ Python tracker <https://bugs.python.org/issue39621> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39630] Const some pointers to string literals
New submission from Andy Lester : Here are some fixes of char * pointers to literals that should be const char * in these four files. +++ Objects/frameobject.c +++ Objects/genobject.c +++ Python/codecs.c +++ Python/errors.c -- components: Interpreter Core messages: 361982 nosy: petdance priority: normal severity: normal status: open title: Const some pointers to string literals type: enhancement ___ Python tracker <https://bugs.python.org/issue39630> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39630] Const some pointers to string literals
Change by Andy Lester : -- keywords: +patch pull_requests: +17886 stage: -> patch review pull_request: https://github.com/python/cpython/pull/18510 ___ Python tracker <https://bugs.python.org/issue39630> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39573] Make PyObject an opaque structure in the limited C API
Andy Lester added the comment: @vstinner would it be helpful if I went on a sweep looking for places we can use the new Py_IS_TYPE macro? Getting away from Py_TYPE(op) would also mean a move to making the internals const-correct. -- nosy: +petdance ___ Python tracker <https://bugs.python.org/issue39573> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
