[issue1172] Documentation for done attribute of FieldStorage class
New submission from Bob Kline: I have attached a patch which adds partial documentation for the done attribute of the cgi.FieldStorage class. This addition is needed in order to make it safe to rely on the current behavior of the class, which sets this attribute to the value -1 when an uploaded file from a CGI form does not arrive intact. If I have sufficient free time to do so at some point in the future, I would like to submit a more extensive modification for the module's documentation, using a format which matches that used for most of the other modules (that is, including documentation of all of the methods and attributes intended for public use), and I'd be inclined to modify the cgi.py module itself, to use a less opaque approach for conveying the failure than the 'done' attribute. I'd want some indication that there was a reasonable chance that if I were to invest the work on this improvement the results would actually be used (I see my latest patch for the module has been languishing in the 'ignored' pile for over a year). If anyone else is doing some overhaul work in this area, please speak up so we don't end up with duplication of effort. I would think that this module would be one of the most commonly used in the entire Python library, and would thus warrant careful maintenance (including addressing all of the "XXX let's fix this ..." comments. Cheers! -- components: Documentation files: cgi.rst.diff messages: 55975 nosy: bkline severity: normal status: open title: Documentation for done attribute of FieldStorage class type: rfe __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1172> __--- cgi.rst 2007-09-17 13:40:51.0 -0400 +++ cgi.rst-20070917 2007-09-17 14:57:00.0 -0400 @@ -147,6 +147,11 @@ if not line: break linecount = linecount + 1 +If an error is encountered when obtaining the contents of an uploaded file +(for example, when the user interrupts the form submission by clicking on +a Back or Cancel button) the :attr:`done` attribute of the object for the +field will be set to the value -1. + The file upload draft standard entertains the possibility of uploading multiple files from one field (using a recursive :mimetype:`multipart/\*` encoding). When this occurs, the item will be a dictionary-like :class:`FieldStorage` item. ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1172] Documentation for done attribute of FieldStorage class
Bob Kline added the comment: Thanks for the very quick follow-up. I may be shooting myself in the foot here, but Sean's encouragement about getting patches to the actual code lead me to wonder if it might be better to go straight for the optimal solution here. As I implied in my original message for this issue, there are approaches for exposing the ability to detect failure which would be more straightforward than testing for field.done == -1. A step in the right direction might be an attribute named something like 'incomplete' (True|False). Or perhaps an access method? Based on my more recent experience with getting code patches accepted, I had settled on just documenting the existing code more fully as a minimal solution, but if Sean's more optimistic advice is justified, I'd be happy to wait a little longer for a cleaner solution (and to pitch in for the work to create it, if that's appropriate). I know I have more than one bit of Python code I wrote years ago for situations similar to this where if I had to do it over again I would have thrown an exception, and maybe that's the right thing to do here, with an optional argument to the constructor which suppresses the exception. Perhaps Guido might want to weigh in with his own preferences (this is his code, and he's still listed as the current maintainer of the module). But I'd rather have the documentation patch for the existing code than nothing at all. Cheers, Bob __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1172> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1172] Documentation for done attribute of FieldStorage class
Bob Kline added the comment: Sean Reifschneider wrote: > Assign your issue that has been ignored to me and I'll take a > look at it. I tried, but it doesn't look like I have sufficient permission to change the assignment. It's http://bugs.python.org/issue1541463 Thanks! __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1172> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1541463] Optimizations for cgi.FieldStorage methods
Bob Kline added the comment: Please note that the documentation of the keys() method of the FieldStorage class (both in the method's docstring as well as in the separate library manual) describes the method as a "dictionary style keys() method." Section 3.8 of the documentation has this to say about the keys() method of a dictionary: "Keys and values are listed in an arbitrary order which is non-random, varies across Python implementations, and depends on the dictionary's history of insertions and deletions." I believe the proposed implementation conforms with this specified behavior. _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1541463> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1541463] Optimizations for cgi.FieldStorage methods
Bob Kline added the comment: I'm not sure I would characterize a speedup of several orders of magnitude a "tiny performance gain." We had scripts with very large numbers of fields which were actually timing out. While I understand and agree with the principle of breaking as little existing code as possible, when programmers have actually been told that the method behaves the way the dictionary keys() method behaves it seems unreasonable to assume that the method will preserve the original order of fields (whatever that might mean for multiply-occurring field names). _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1541463> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5340] Change in cgi behavior breaks existing software
Bob Kline added the comment: Just to make life interesting, someone went in and changed all the URLs for messages in the Python mailing list. Here's the new URL for the message which contains the repro instructions: http://mail.python.org/pipermail/python-list/2009-February/1192951.html The URL which represents the reported behavior in that message now points to a machine which has been upgraded to Python 2.7, not 2.6 as reported in the repro instructions, but the behavior is still the same. Of course, these instructions won't be useful forever, because the Debian server which is running Python 2.5 (to show the previous behavior) will (I assume) eventually move on to a later version of Python itself. But for now the repro instructions are still valid. -- ___ Python tracker <http://bugs.python.org/issue5340> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2480] pickling of large recursive structures fails
Bob Kline <[EMAIL PROTECTED]> added the comment: I just ran into this behavior with an attempt to pickle a dom tree for an XML document whose nesting level never got deeper than nine child nodes, and indeed it crashed the interpreter. Throwing an exception would be preferable, of course, to silent blowing up Python, but even the exception seems to fly in the face of the documentation for the pickle module [1] which claims (summarizing) that serializing recursive objects using marshal will fail but pickling recursive objects will not fail. I can provide a repro for the XML/DOM pickling case if you think that would be helpful, but that seems redundant since essentially you've already illustrated the problem with your own repro case. Thanks for your work on the solution. [1] http://docs.python.org/lib/node314.html -- nosy: +bkline type: -> crash __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2480> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2480] eliminate recursion in pickling
Bob Kline <[EMAIL PROTECTED]> added the comment: > Please open a new issue and don't forget to provide an example case. Looks like Daniel beat me to the punch. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2480> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37996] 2to3 introduces unwanted extra backslashes for unicode characters in regular expressions
New submission from Bob Kline :
-UNWANTED = re.compile("""['".,?!:;()[\]{}<>\u201C\u201D\u00A1\u00BF]+""")
+UNWANTED =
re.compile("""['".,?!:;()[\]{}<>\\u201C\\u201D\\u00A1\\u00BF]+""")
The non-ASCII characters in the original string are perfectly legitimate str
characters, using valid standard escapes recognized and handled by the Python
parser. It is unnecessary to lengthen the string argument passed to
re.compile() and defer the conversion of the doubled escapes for the regular
expression engine to handle.
--
components: 2to3 (2.x to 3.x conversion tool)
messages: 350922
nosy: bkline
priority: normal
severity: normal
status: open
title: 2to3 introduces unwanted extra backslashes for unicode characters in
regular expressions
type: behavior
versions: Python 3.7
___
Python tracker
<https://bugs.python.org/issue37996>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37996] 2to3 introduces unwanted extra backslashes for unicode characters in regular expressions
Bob Kline added the comment: The original string had u"""...""" and the u had already been removed by hand in preparation for moving to Python 3. -- ___ Python tracker <https://bugs.python.org/issue37996> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37996] 2to3 introduces unwanted extra backslashes for unicode characters in regular expressions
Bob Kline added the comment:
Ah, this is worse than I first thought. It's not just converting code by adding
extra backslashes to regular expression strings, where at least the regular
expression engine will do what the original code was asking the Python parser
to do (unless user code checks for and enforces limits on regular expression
string lengths, so even that case is broken), but 2to3 is also mangling strings
in places where the behavior is changed (that is, broken). 2to3 wants to change
if c not in ".-_:\u00B7\u0e87":
to
if c not in ".-_:\\u00B7\\u0e87":
Not the same thing at all, as illustrated here:
$ python
Python 3.7.3 (default, Jun 19 2019, 07:38:49)
[Clang 10.0.1 (clang-1001.0.46.4)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> len("\u00B7")
1
>>> len("\\u00B7")
6
>>>
That breaks the original code. This is a serious bug.
--
___
Python tracker
<https://bugs.python.org/issue37996>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37996] 2to3 introduces unwanted extra backslashes for unicode characters in regular expressions
Bob Kline added the comment: Thanks, I understand. However, this highlights something which had slipped under my radar. You get one shot at running a code set through the tool. You can't do what I was doing, which was to run the tool in "don't write" mode, then fix by hand some of the things it says will need to be done, then run it again in the same mode, fix, etc., until I got to the point where I felt like I could trust it (except for things like adding unnecessary `list()` wrappers, for which I learned how to use the option for suppressing certain default fixers), and then run the tool in write mode to fix what was left. I now totally get why the tool did what it did, and why the approach I was using was inappropriate, but was there a warning to this effect that I missed in the documentation? Something like "you can only run this tool once per fixer (or set of fixers) in write mode, and you cannot run a fixer on code for which you have performed any of the needed conversions for that fixer yourself"? Of cour se, it's always possible I'm the only developer clueless enough not to have figured this out without such a warning. :-) Partly in my (lame) defense, I had lured myself into the frame of mind where what I was doing seemed to make sense by having just come out of a similar exercise with pylint, where iterative "fixing" works just fine. I guess I should take this as a good sign, that my brain has moved so far into the Python 3 world that "..." was no longer recognizable as a bytestring. Again, thanks for the gentle explanation. :-) -- ___ Python tracker <https://bugs.python.org/issue37996> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37996] 2to3 introduces unwanted extra backslashes for unicode characters in regular expressions
Bob Kline added the comment: In fact, I suppose it's possible that the warning as I worded it is still not restrictive enough, and that there are subtle dependencies between the fixers which would make the action of one of them render the code no longer safely fixable as Python 2 code by the other fixers, and the real warning should really say something like, "You can only run this tool once in write-in-place mode on a given code set. You can run as many times without the -w option as many times, with as many combinations of fixers as you want, determining which of the fixers you will enable for the final write-in-place run." Are there such dependencies between fixers? -- ___ Python tracker <https://bugs.python.org/issue37996> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38003] Incorrect "fixing" of isinstance tests for basestring
New submission from Bob Kline : We are attempting to convert a large Python 2 code base. Following the guidance of the official documentation (https://docs.python.org/2/library/functions.html#basestring) we created tests in many, many places that look like this: if isinstance(value, basestring): if not isinstance(value, unicode): value = value.decode(encoding) else: some other code It seems that the 2to3 tool is unaware that replacing basestring with str in such cases will break the software. Here's an example. $ 2to3 repro.py ... --- repro.py(original) +++ repro.py(refactored) @@ -1,8 +1,8 @@ from frobnitz import transform def foo(value, encoding=None): -if isinstance(value, basestring): -if not isinstance(value, unicode): +if isinstance(value, str): +if not isinstance(value, str): value = value.decode(encoding or "utf-8") return value else: Help me understand how this "fix" results in the correct behavior. -- components: 2to3 (2.x to 3.x conversion tool) messages: 350964 nosy: bkline priority: normal severity: normal status: open title: Incorrect "fixing" of isinstance tests for basestring type: behavior versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue38003> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38003] Incorrect "fixing" of isinstance tests for basestring
Bob Kline added the comment: > Use str instead. Sure. I understand the advantages of the new approach to strings. Which, by the way, weren't available when this project began. I don't disagree with anything you say in the context of writing new code. I was, however, surprised and dismayed to learn of the cavalier approach the upgrade tool has taken to silently breaking existing code which it is claiming to "fix." Here's my favorite so far. --- cdr.py (original) +++ cdr.py (refactored) @@ -36,15 +36,15 @@ # == from six import itervalues try: -basestring +str is_python3 = False base64encode = base64.encodestring base64decode = base64.decodestring except: base64encode = base64.encodebytes base64decode = base64.decodebytes -basestring = (str, bytes) -unicode = str +str = (str, bytes) +str = str is_python3 = True We wrote this following the example of comparable techniques in http://python-future.org/compatible_idioms.html and similar guides to an upgrade path. Seems we're being punished for taking the trouble to make our code work with Python 2 and 3 during the transition period. :-( It's hard to see how this conversion resulted in something better than what we already had. -- ___ Python tracker <https://bugs.python.org/issue38003> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38003] Incorrect "fixing" of isinstance tests for basestring
Bob Kline added the comment: > Unless you have a specific proposal, ... I _do_ have a specific proposal: replace `basestring` with `(str, bytes)`, which preserves the behavior of the original code. So, if isinstance(value, basestring) becomes if isinstance(value, (str, bytes)) -- ___ Python tracker <https://bugs.python.org/issue38003> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38003] Change 2to3 to replace 'basestring' with '(str,bytes)'
Bob Kline added the comment: OK, I give up. In parting I will point out that the official Python 2 documentation says "basestring() This abstract type is the superclass for str and unicode. It cannot be called or instantiated, but it can be used to test whether an object is an instance of str or unicode. isinstance(obj, basestring) is equivalent to isinstance(obj, (str, unicode))." That's exactly what the code we are converting (much of which was written years before Python 3 even existed) was doing. As for the idea that we weren't really "planning to use it as logical text" (ignoring the fact that _everyone_ used Python 2 str objects to represent logical text back in 2003, and ignoring the fact that the repro case given at the top of this report converts the 8-bit string value to Unicode -- why else would it do that except to use the value as "logical text"?) ... well, I don't know where to start. I'm done here. :->} -- ___ Python tracker <https://bugs.python.org/issue38003> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43777] Remove description of "pip search" command from tutorial
New submission from Bob Kline : The official tutorial instructs users to find third-party packages by using the "pip search" command, which no longer works (and will be deprecated -- and presumably subsequently removed -- according to the error message). See https://docs.python.org/3.10/tutorial/venv.html#managing-packages-with-pip That passage should be removed from the tutorial. -- assignee: docs@python components: Documentation messages: 390550 nosy: bkline, docs@python priority: normal severity: normal status: open title: Remove description of "pip search" command from tutorial versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue43777> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43777] Remove description of "pip search" command from tutorial
Bob Kline added the comment: PR submitted: https://github.com/python/cpython/pull/25287 -- ___ Python tracker <https://bugs.python.org/issue43777> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43777] Remove description of "pip search" command from tutorial
Bob Kline added the comment:
Thanks for the clarification. I submitted a PR, but I'm unable to remove the
"CLA not signed" tag from it (even though I have signed the CLA) and form at
https://check-python-cla.herokuapp.com/ ("You can check yourself to see if the
CLA has been received.") blows up with a 500 ("Server got itself in trouble").
Submitting patches for the Python documentation never used to be this hard. :-)
--
___
Python tracker
<https://bugs.python.org/issue43777>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43790] CLA check fails with a 500 error
New submission from Bob Kline : The tool to check whether the CLA has been received fails with a 500 error. Steps to reproduce: 1. Add your GitHub name to your b.p.o. record. 2. Navigate to https://check-python-cla.herokuapp.com/ 3. Enter your GitHub name and press the "Check" button 4. "500 Internal server error / Server got itself in trouble" -- components: Demos and Tools messages: 390612 nosy: bkline priority: normal severity: normal status: open title: CLA check fails with a 500 error ___ Python tracker <https://bugs.python.org/issue43790> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43777] Remove description of "pip search" command from tutorial
Bob Kline added the comment: I have reported the failure of the CLA check tool. https://bugs.python.org/issue43790 -- ___ Python tracker <https://bugs.python.org/issue43777> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43790] CLA check fails with a 500 error
Bob Kline added the comment: Apparently, it doesn't fail when you enter a name for which it can't find a b.p.o. account. So it knows how to say "beelzebub does not have bpo account" but fails when I put in "bkline" in the GitHub username field. It's tempting to suspect that the 500 error means "yes, I found a b.p.o account for that GitHub user but I just can't say so" but there's no guarantee that this would be a reliable assumption. -- ___ Python tracker <https://bugs.python.org/issue43790> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43790] CLA check fails with a 500 error
Bob Kline added the comment: Super, thanks! -- ___ Python tracker <https://bugs.python.org/issue43790> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43790] CLA check fails with a 500 error
Bob Kline added the comment: Sorry, it's still failing with the same error message. -- status: closed -> open ___ Python tracker <https://bugs.python.org/issue43790> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43790] CLA check fails with a 500 error
Bob Kline added the comment: To reproduce, enter "bkline" in the GitHub username field and press Check. -- ___ Python tracker <https://bugs.python.org/issue43790> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43790] CLA check fails with a 500 error
Bob Kline added the comment: I can, if you prefer, close this ticket and create a new one on GitHub (even though this is the same issue, not a different "further" issue). -- ___ Python tracker <https://bugs.python.org/issue43790> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43790] CLA check fails with a 500 error
Bob Kline added the comment: And now it's working for me as well. Thanks, @Mariatta. -- resolution: third party -> fixed status: open -> closed ___ Python tracker <https://bugs.python.org/issue43790> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41410] Opening a file in binary mode makes a difference on all platforms in Python 3
New submission from Bob Kline : The documentation for tempfile.mkstemp() says "If text is specified, it indicates whether to open the file in binary mode (the default) or text mode. On some platforms, this makes no difference." That might have been true for Python 2.x, but in Python 3, there are no platforms for which the choice whether to open a file in binary mode makes no difference. -- assignee: docs@python components: Documentation messages: 374385 nosy: bkline, docs@python priority: normal severity: normal status: open title: Opening a file in binary mode makes a difference on all platforms in Python 3 versions: Python 3.10, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue41410> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41633] pydoc skips methods of nested classes
New submission from Bob Kline : Although the documentation for the pydoc says that it produces documentation of the classes recursively, this isn't actually true. -- components: Library (Lib) files: repro.py messages: 375891 nosy: bkline priority: normal severity: normal status: open title: pydoc skips methods of nested classes type: behavior versions: Python 3.8 Added file: https://bugs.python.org/file49428/repro.py ___ Python tracker <https://bugs.python.org/issue41633> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41633] pydoc skips methods of nested classes
Bob Kline added the comment: Here is the generated documentation. Note that no mention is made of the inner class's method. -- Added file: https://bugs.python.org/file49429/Screen Shot 2020-08-25 at 11.26.39 AM.png ___ Python tracker <https://bugs.python.org/issue41633> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34028] Python 3.7.0 wont compile with SSL Support 1.1.0 > alledged missing X509_VERIFY_PARAM_set1_host() support
Bob Kline added the comment: I had to add $HOME/usr/lib64 to LD_LIBRARY_PATH to get make to work. -- nosy: +bkline ___ Python tracker <https://bugs.python.org/issue34028> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11849] glibc allocator doesn't release all free()ed memory
Bob Kline added the comment: Would it be inappropriate for this fix to be applied to 2.7? -- nosy: +bkline ___ Python tracker <https://bugs.python.org/issue11849> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11849] glibc allocator doesn't release all free()ed memory
Bob Kline added the comment:
Sorry, I should have used the language of the patch author ("the resolution").
Without the resolution, Python 2.7 eventually runs out of memory and crashes
for some correctly written user code.
--
___
Python tracker
<https://bugs.python.org/issue11849>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11849] glibc allocator doesn't release all free()ed memory
Bob Kline added the comment: Thanks for your responses to my comments. I'm working as hard as I can to get my customer's systems migrated into the Python 3 world, and I appreciate the efforts of the community to provide incentives (such as the resolution for this failure) for developers to upgrade. However, it's a delicate balancing act sometimes, given that we have critical places in our system for which the same code runs more than twice as slowly on Python 3.6 as on Python 2.7. -- ___ Python tracker <https://bugs.python.org/issue11849> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11849] glibc allocator doesn't release all free()ed memory
Bob Kline added the comment: > ... jemalloc can reduce memory usage ... Thanks for the tip. I downloaded the source and successfully built the DLL, then went looking for a way to get it loaded. Unfortunately, DLL injection, which is needed to use this allocator in Python, seems to be much better supported on Linux than on Windows. Basically, Microsoft's documentation [1] for AppInit_DLL, the shim for DLL injection on Windows, says (in effect) "here's how to use this technique, but we don't recommend using it, so here's a link [2] for what we recommend you do instead. That link takes you to "Try searching for what you need. This page doesn’t exist." [1] https://support.microsoft.com/en-us/help/197571/working-with-the-appinit-dlls-registry-value [2] https://support.microsoft.com/en-us/help/134655 -- ___ Python tracker <https://bugs.python.org/issue11849> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31856] Unexpected behavior of re module when VERBOSE flag is set
New submission from Bob Kline :
According to the documentation of the re module, "When this flag [re.VERBOSE]
has been specified, whitespace within the RE string is ignored, except when the
whitespace is in a character class or preceded by an unescaped backslash; this
lets you organize and indent the RE more clearly. This flag also lets you put
comments within a RE that will be ignored by the engine; comments are marked by
a '#' that’s neither in a character class [n]or preceded by an unescaped
backslash." (I'm quoting from the 3.6.3 documentation, but I've tested with
several versions of Python, as indicated in the issue's `Versions` field, all
with the same results.)
Given this description, I would have expected the output for each of the pairs
of calls to findall() in the attached repro code to be the same, but that is
not what's happening. In the case of the first pair of calls, for example, the
non-verbose version finds two more matches than the verbose version, even
though the regular expression is identical for the two calls, ignoring
whitespace and comments in the expression string. Similar problems appear with
the other two pairs of calls.
Here's the output from the attached code:
['&', '(', '/Term/SemanticType/@cdr:ref', '==']
['/Term/SemanticType/@cdr:ref', '==']
[' XXX ']
[]
[' XXX ']
[]
It would seem that at least one of the following is true:
1. the module is not behaving as it should
2. the documentation is wrong
3. I have not understood the documentation correctly
I'm happy for it to be #3, as long as someone can explain what I have not
understood.
--
components: Library (Lib), Regular Expressions
files: regex-repro.py
messages: 304849
nosy: bkline, ezio.melotti, mrabarnett
priority: normal
severity: normal
status: open
title: Unexpected behavior of re module when VERBOSE flag is set
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6
Added file: https://bugs.python.org/file47232/regex-repro.py
___
Python tracker
<https://bugs.python.org/issue31856>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31856] Unexpected behavior of re module when VERBOSE flag is set
Bob Kline added the comment: I had been under the impression that "escaped" in this context meant that an escape character (the backslash) was part of the string value for the regular expression (there's a little bit of overloading going on with that word). Thanks for setting me straight. -- ___ Python tracker <https://bugs.python.org/issue31856> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31856] Unexpected behavior of re module when VERBOSE flag is set
Bob Kline added the comment: The light finally comes on. I actually *was* putting a backslash into the string value, with the raw flag (which is, of course, what you were trying to tell me). Thanks for your patience. :-) -- ___ Python tracker <https://bugs.python.org/issue31856> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31652] make install fails: no module _ctypes
Bob Kline added the comment: Confirming that this is still failing with 3.7.0 released. -- nosy: +bkline ___ Python tracker <https://bugs.python.org/issue31652> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5340] Change in cgi behavior breaks existing software
New submission from Bob Kline : We just upgraded Python to 2.6 on some of our servers and a number of our CGI scripts broke because the cgi module has changed the way it handles POST requests. When the 'action' attribute was not present in the form element on an HTML page the module behaved as if the value of the attribute was the URL which brought the user to the page with the form, but without the query (?x=y...) part. Now FieldStorage.getvalue() is giving the script a list of two copies of the value for some of the parameters (folding in the parameters from the previous request) instead of the single string it used to return for each. I searched the python mailing list looking for a discussion of the proposal to impose this change of behavior, and perhaps I wasn't using the right phrases in my search, but I didn't find anything. I didn't get many responses when I asked for pointers to this discussion, but the few I did get were from people who were as surprised as we were. It's not clear to us (or to those who responded on the mailing list) that the applicable RFCs provide completely clear and unambiguous guidance as to which behavior is correct, but even if the new behavior is correct, it is unusual to have changes to the library which break existing code introduced without any discussion of the impact, or transition period, or options to preserve the previous behavior. For what it's worth, it appears that Perl and PHP (which probably account for the bulk of non-Python CGI scripts in the wild) both behave the way the pre-2.6 cgi module did. We have a workaround (modify all our CGI scripts to explicitly set the action attribute without the parameter suffix), but I was asked by one of the regulars on the mailing list to file a bug report here, so I'm complying with that request. It appears that the breaking change was introduced with http://svn.python.org/view?rev=64447&view=rev in connection with http://bugs.python.org/issue1817. See http://mail.python.org/pipermail/python-list/2009-February/529130.html for repro instructions. -- components: Library (Lib) messages: 82575 nosy: bkline severity: normal status: open title: Change in cgi behavior breaks existing software type: behavior versions: Python 2.6 ___ Python tracker <http://bugs.python.org/issue5340> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29667] socket module sometimes loses response packets
New submission from Bob Kline:
The socket module does not always return response packets which are
successfully delivered to the client host. We ran into this problem with an
HTTP request for which socket.recv() raised an exception instead of returning
the 301 redirection response which the web server sent back:
socket.error: [Errno 10054] An existing connection was forcibly closed by the
remote host
We did some packet tracing, and saw that there were six packets exchanged for
the connection:
client: [SYN]
server: [SYN,ACK]
client: [ACK]
client: GET /cam HTTP/1.1 ...\r\n\r\n
server: HTTP/1.0 301 Moved Permanently ...\r\n\r\n
server: [RST,ACK]
The failure appears to be timing dependent. If the 301 response is processed
quickly enough (the usual case), the socket.recv() call returns it successfully
to the caller. If sufficient delay is introduced, however, the 301 response is
discarded, and the exception is raised. This can happen, for example, if the
socket library has to take the time to handle setting up a requested timeout.
On a slow enough machine, the following code will reproduce the problem:
import socket
s = socket.create_connection(("www.cancer.gov", 80), timeout=5)
s.sendall("GET /cam HTTP/1.1\r\nHost: www.cancer.gov\r\n\r\n")
print s.recv(8192)
You might have to stick a time.sleep(.5) call right in front of the s.recv()
call if you can't find a slow enough machine to test on.
This appears to be a Windows-specific problem, as I can't reproduce it on a
Linux or OS X client, no matter how much of a delay is introduced.
Platform: Windows (any version) with Python 2.7 or Python 3.6.
--
components: Library (Lib)
messages: 288648
nosy: bkline
priority: normal
severity: normal
status: open
title: socket module sometimes loses response packets
type: behavior
versions: Python 2.7, Python 3.6
___
Python tracker
<http://bugs.python.org/issue29667>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
