[issue25551] Event's test_reset_internal_locks too fragile

[Nir Soffer]

Changes by Nir Soffer :


--
keywords: +patch
Added file: 
http://bugs.python.org/file40941/0001-Issue-254074-Test-condition-behavior-instead-of-inte.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24726] OrderedDict has strange behaviour when dict.__setitem__ is used.

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Thanks for your review Eric.

test_delitem_2 was not added because it fails in just added TestCase for 
COrderedDict subclass. Added tests for direct calls of other dict methods as 
Eric suggested.

During writing new tests for direct calls of other dict methods I found yet one 
bug. Following code makes Python to hang and eat memory.

from collections import OrderedDict
od = OrderedDict()
for i in range(10):
od[str(i)] = i

for i in range(9):
dict.__delitem__(od, str(i))

list(od)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25410] Clean up and fix OrderedDict

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Could you please make a review of last three patches Eric?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25551] Event's test_reset_internal_locks too fragile

[Nir Soffer]

New submission from Nir Soffer:

test_reset_internal_locks is looking at Event's _cond._lock - this make it 
harder to change internal details of the Condition object and make the test 
fragile.

We should test the condition behavior instead.

--
components: Tests
messages: 254074
nosy: nirs
priority: normal
severity: normal
status: open
title: Event's test_reset_internal_locks too fragile
type: enhancement
versions: Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24934] django_v2 benchmark not working in Python 3.6

[R. David Murray]

R. David Murray added the comment:

An additional argument for waiting is issue 25486.

--
type: crash -> behavior

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23571] Raise SystemError if a function returns a result with an exception set

[Jesús Cea Avión]

Changes by Jesús Cea Avión :


--
nosy: +jcea

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25410] Clean up and fix OrderedDict

[Eric Snow]

Eric Snow added the comment:

I will review those patches soon.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24802] int and float constructing from non NUL-terminated buffer

[Martin Panter]

Martin Panter added the comment:

The patch looks good to me.

However I don’t understand what you meant about restoring int(bytes, base) 
behaviour. None of the patches here, nor in Issue 22896, touch long_new() in 
/Objects/longobject.c.

--
nosy: +martin.panter

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5550] [urllib.request]: Comparison of HTTP headers should be insensitive to the case

[Martin Panter]

Changes by Martin Panter :


--
superseder: Implement PEP 3108 -> urllib/httplib header capitalization

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2275] Make urllib.request.Request.has_header() etc case-insensitive

[Martin Panter]

Martin Panter added the comment:

Rui: See Issue 12455 about changing the letter case of field names sent to the 
server. Unless someone wants to write a patch to fix all the bugs at once, I 
suggest to keep this thread focussed on Request.has_header() etc.

I closed Issue 5550 as a duplicate of this one. There is a patch there from 
2014 which does the same sort of thing as John’s issue2775.patch from 2008, but 
IMO John’s patch would be more efficient. It needs updating for Python 3.6 
though.

The remove_header() method (added in 3.4) should also be adjusted to be 
case-insensitive.

It may also be worth clarifying in the header_items() documentation that the 
keys have been converted as if by str.capitalize().

FTR: John’s issue2775.patch seems to be Patch Set 1 in the code review, despite 
being third in the list above.

--
nosy: +martin.panter
stage: patch review -> needs patch
title: urllib/httplib header capitalization -> Make 
urllib.request.Request.has_header() etc case-insensitive
type: behavior -> enhancement

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12612] Valgrind suppressions

[Marius Gedminas]

Marius Gedminas added the comment:

Could this fix be backported to the 2.7 branch as well?

--
nosy: +mgedmin

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12978] Figure out extended attributes on BSDs

[William Orr]

William Orr added the comment:

After a considerable amount of rework, I've gotten something worth submitting. 
All unit tests pass, and it handles some of the more unfortunate differences 
between FreeBSD's extended attribute syscalls and Linux's.

One of the bigger changes is that I reworked the calls to getxattr and 
listxattr. These used to be called with a small buffer, and if the size of the 
extended attribute(s) exceeded the buffer length, we'd throw out that buffer 
and start again with a buffer of the maximum possible attribute size allocated.

I threw this out, and opted for always making two calls - one to get the size 
of the buffer, and one to actually get the contents (or list of attributes). 
This works the same for both FreeBSD and Linux. FreeBSD's extattr_get_* and 
extattr_list_* unfortunately only return the number of bytes read, *not* the 
number of bytes in the attribute value or the list. That means that there's no 
real way to determine if we've read less data than there is in the attribute.

This passes the unit tests (on FreeBSD 10.1). I'd be interested to see results 
from other users and comments.

--
Added file: http://bugs.python.org/file40946/extattrs.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25553] SMTP.data(msg) function may cause the last CRLF of msg lost if msg is quoted-printable encoding.

[Deli Zhang]

Deli Zhang added the comment:

Correct the action of appending the end-of-data sequence "."

--
Added file: http://bugs.python.org/file40945/smtplib.py

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23760] Tkinter in Python 3.4 on Windows don't post internal clipboard data to the Windows clipboard on exit

[Jon Snoo]

Jon Snoo added the comment:

I tested the code posted by Victor with Python 3.5 (which uses Tcl/Tk 8.6.4) 
and I still get an empty clipboard when the script exits.

I also downloaded ActiveState's Tcl binary which is also version 8.6.4, and 
tested the minimal reproducer posted by Serhiy with this

wish issue23760.tcl

and it works i.e. I get "Result" in the system clipboard.

I don't really know what to make of this.

--
nosy: +Jon Snoo

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25549] call sum on list of timedelta throws TypeError

[R. David Murray]

R. David Murray added the comment:

I don't think this warrants a special error message.  If you get it, it is 
obvious you weren't yourself adding an int to a timedelta, so the next logical 
course of action should be to look at the docs for sum.

--
nosy: +r.david.murray
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23760] Tkinter in Python 3.4 on Windows don't post internal clipboard data to the Windows clipboard on exit

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Related Tk issues:

http://core.tcl.tk/tk/tktview/822002ff
http://core.tcl.tk/tk/tktview/732662ff
http://core.tcl.tk/tk/tktview/1844034f
http://core.tcl.tk/tk/tktview/939389ff

The problem should be fixed (at least on Windows) in the last issue, but 
perhaps Tkinter doesn't execute this code.

A workaround is to make a pause about 0.1 sec (can be depend on perfomance of 
your computer, it doesn't work if the pause is too short). Append following 
lines to you example:

r.after(100, r.destroy)
r.mainloop()

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25539] python3 fail on parsing http header

[R. David Murray]

R. David Murray added the comment:

Support for handling such headers could be added to the new email API (ie: add 
a policy setting to accept them), if someone wants to make a feature request.

--
nosy: +r.david.murray

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24802] int and float constructing from non NUL-terminated buffer

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

I prefer to merge issue24802 and issue24803 and discuss them at one place.

Here is merged and revised patch.

The patch is changed. There is a very rare corner case: when the type of 
argument is a subclass of bytes or bytearray with overloaded 
tp_as_buffer->bf_getbuffer, returned view can be not NUL terminated. To avoid 
ambiguity and for unifying with int constructor, I have added special cases for 
bytes and bytearray (this is also restores pre-issue22896 behavior for 
int(bytes, base)).

Tests are moved and added additional tests for memoryview slices.

>>> int(memoryview(b'123')[1:3])
23
>>> int(memoryview(b'123\x00')[1:3])
23
>>> int(memoryview(b'123 ')[1:3])
Traceback (most recent call last):
  File "", line 1, in 
ValueError: invalid literal for int() with base 10: b'23'
>>> int(memoryview(b'123A')[1:3])
Traceback (most recent call last):
  File "", line 1, in 
ValueError: invalid literal for int() with base 10: b'23'
>>> int(memoryview(b'1234')[1:3])
Traceback (most recent call last):
  File "", line 1, in 
ValueError: invalid literal for int() with base 10: b'23'
>>> float(memoryview(b'12.3')[1:4])
2.3
>>> float(memoryview(b'12.3\x00')[1:4])
2.3
>>> float(memoryview(b'12.3 ')[1:4])
2.3
>>> float(memoryview(b'12.3A')[1:4])
2.3
>>> float(memoryview(b'12.34')[1:4])
Traceback (most recent call last):
  File "", line 1, in 
ValueError: could not convert string to float: 

There is similar dangerously looking code for complex. But it is never 
executed, because complex accepts only one non-numeric type: str. The patch 
removes this misleading dead code.

--
title: PyFloat_FromString Buffer Over-read -> int and float constructing from 
non NUL-terminated buffer
Added file: http://bugs.python.org/file40940/int_float_from_buffer.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25521] optparse module does not emit DeprecationWarning

[John Hagen]

John Hagen added the comment:

Is there any consensus on how to move forward with this?  I feel there are at 
least 4 options:

1) Do nothing.
Pro: No work.
Con: It feels misleading to the user since the docs clearly state it's 
deprecated.  Some users (especially new ones) may miss the fact they should 
really be using argparse.

2) Throw PendingDeprecationWarning from optparse, and simply suppress it where 
it's used.
Pro: Not as much work.  Users of optparse are properly notified.
Con: Kicks the can down the road for someone else to have to eventually 
port off of optparse.

3) Throw PendingDeprecationWarning from optparse and port stdlib modules to 
argparse.
Pro: Seems like the "purest" solution at least from what is indicated in 
docs that it will no longer be supported.  Users of optparse are properly 
notified.
Con: Most amount of work.  argparse has some bugs that need to be patched.

4) Some combination of 2) and 3) where some modules are suppressed and others 
are ported.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24803] PyNumber_Long Buffer Over-read.patch

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Merged with issue24802.

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25550] RecursionError in re with '(' * 500

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

re.compile can also raise ValueError and OverflowError. Agree that may be these 
exceptions can be converted to re.error.

But it can also raise MemoryError, and KeyboardInterrupt. And these exceptions 
can't be converted to re.error.

RecursionError is closer to the latter case. It depends not only on the pattern 
itself, but on the place where it is called. A pattern that is compiled 
successfully at top level can produce a RecursionError if it is compiled deeply 
in the recursion.

>>> import re
>>> def r(n):
... if not n:
... return re.compile('x')
... return r(n-1)
... 
>>> r(990)
Traceback (most recent call last):
  File "", line 1, in 
  File "", line 4, in r
  File "", line 4, in r
...
  File "", line 4, in r
  File "", line 3, in r
  File "/home/serhiy/py/cpython/Lib/re.py", line 224, in compile
return _compile(pattern, flags)
  File "/home/serhiy/py/cpython/Lib/re.py", line 293, in _compile
p = sre_compile.compile(pattern, flags)
  File "/home/serhiy/py/cpython/Lib/sre_compile.py", line 555, in compile
p = sre_parse.parse(p, flags)
  File "/home/serhiy/py/cpython/Lib/sre_parse.py", line 822, in parse
source = Tokenizer(str)
  File "/home/serhiy/py/cpython/Lib/sre_parse.py", line 225, in __init__
self.__next()
RecursionError: maximum recursion depth exceeded
>>> re.compile('x')
re.compile('x')

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25521] optparse module does not emit DeprecationWarning

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

I vote for gradual porting stdlib modules and scripts to argparse and fixing 
found problems, but doesn't touch optparse right now. We have enough time 
before 3.6 feature freezing.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25545] email parsing docs need to be clear that only ASCII strings are supported

[R. David Murray]

R. David Murray added the comment:

There is no problem with supporting both 2.7 and python3 with the same email 
API as long as your input strings are ASCII only, which is what is required by 
the email RFCs (as I said, they do not support unicode...even the new one only 
supports utf8 (a unicode encoding) not unicode itself).  So if your input is 
RFC compliant (using content transfer encoding to encode non-ASCII characters), 
things will work fine.  Just think of unicode as a 7-bit transmission channel 
(which is what it is from email's perspective).  Otherwise the bytes/string 
issues are no different than they are for any other shared-code-base 
application.

I have an extensive doc rewrite in process, but I'm not sure when it will land. 
 I thought I had already added the note about ASCII-only to the parser docs, 
but I see that I did not.  I'll reopen this issue to remind myself to do that, 
since the doc rewrite will only apply to 3.6 (when the new API will no longer 
be provisional).

--
resolution: not a bug -> 
stage: resolved -> needs patch
status: closed -> open
title: email.message.get_payload returns wrong encoding -> email parsing docs 
need to be clear that only ASCII strings are supported
versions: +Python 3.4, Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25521] optparse module does not emit DeprecationWarning

[R. David Murray]

R. David Murray added the comment:

I vote for (4): (2) with a helping of (3).  That is, add the warning, but don't 
try to port all the stdlib modules to argparse beforehand.  Those should be 
addressed one by one, as I mentioned in another issue.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25521] optparse module does not emit DeprecationWarning

[Stéphane Wirtel]

Stéphane Wirtel added the comment:

+1 with @serhiy.storchaka

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue23883] __all__ lists are incomplete

[Michael Selik]

Michael Selik added the comment:

many things are not present in os.__all__ that should be, including
os.getcwd

--
nosy: +selik

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25550] RecursionError in re with '(' * 500

[Florian Bruhin]

New submission from Florian Bruhin:

I just found this thanks to Hypothesis[1]:

>>> import re
>>> re.compile('(' * 500)
Traceback (most recent call last): 
  File "", line 1, in 
  File "/usr/lib/python3.5/re.py", line 224, in compile
return _compile(pattern, flags)
  File "/usr/lib/python3.5/re.py", line 293, in _compile
p = sre_compile.compile(pattern, flags)
  File "/usr/lib/python3.5/sre_compile.py", line 536, in compile
p = sre_parse.parse(p, flags)
  File "/usr/lib/python3.5/sre_parse.py", line 829, in parse
p = _parse_sub(source, pattern, 0)
  File "/usr/lib/python3.5/sre_parse.py", line 437, in _parse_sub
itemsappend(_parse(source, state))
  File "/usr/lib/python3.5/sre_parse.py", line 778, in _parse
p = _parse_sub(source, state)
  File "/usr/lib/python3.5/sre_parse.py", line 437, in _parse_sub
itemsappend(_parse(source, state))
  File "/usr/lib/python3.5/sre_parse.py", line 778, in _parse
p = _parse_sub(source, state)
  File "/usr/lib/python3.5/sre_parse.py", line 437, in _parse_sub
itemsappend(_parse(source, state))
  [...]
  File "/usr/lib/python3.5/sre_parse.py", line 493, in _parse
subpattern = SubPattern(state)
RecursionError: maximum recursion depth exceeded

It seems a maximum recursion error has been treated as a bug before (like in 
issue401612), so I'm guessing this isn't intended here either.

[1] https://hypothesis.readthedocs.org/

--
components: Library (Lib)
messages: 254040
nosy: The Compiler, effbot, ezio.melotti, pitrou, serhiy.storchaka
priority: normal
severity: normal
status: open
title: RecursionError in re with '(' * 500
type: behavior
versions: Python 3.4, Python 3.5

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25550] RecursionError in re with '(' * 500

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

This isn't a bug, this is a limitation of the implementation. Regular 
expression parser is recursive and Python has a limit for recursion depth. You 
can increase this limit if needed.

>>> import sys, re
>>> sys.setrecursionlimit(2000)
>>> re.compile('(' * 500)
Traceback (most recent call last):
  File "/home/serhiy/py/cpython/Lib/sre_parse.py", line 437, in _parse_sub
itemsappend(_parse(source, state))
  File "/home/serhiy/py/cpython/Lib/sre_parse.py", line 778, in _parse
p = _parse_sub(source, state)
  File "/home/serhiy/py/cpython/Lib/sre_parse.py", line 437, in _parse_sub
itemsappend(_parse(source, state))
...
  File "/home/serhiy/py/cpython/Lib/sre_parse.py", line 778, in _parse
p = _parse_sub(source, state)
  File "/home/serhiy/py/cpython/Lib/sre_parse.py", line 437, in _parse_sub
itemsappend(_parse(source, state))
  File "/home/serhiy/py/cpython/Lib/sre_parse.py", line 781, in _parse
source.tell() - start)
sre_constants.error: missing ), unterminated subpattern at position 499

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25313] IDLE: gracefully handle themes (or keysets, or ...) not present

[Terry J. Reedy]

Terry J. Reedy added the comment:

Here is patch with a subdued message to see Help when IDLE Dark is selected.  
It goes away when something else is selected. I tried no emphasis, colored 
background, relief, and the dull red text in the patch.  I tested, but I want 
to retest systematically when fresh.  Test on *nix would good, though I do not 
think anything is system specific.

Under some conditions, entry 'new = ' is being put in user config-main.cfg 
[Theme] section. It seems harmless but I hope to track it down, while 
retesting, before committing.  It might just be something I did in my installed 
idlelib, but I'd like to know.

--
versions: +Python 3.4
Added file: http://bugs.python.org/file40939/@cfg_text.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2142] difflib.unified_diff(...) produces invalid patches

[Evgeny Kapun]

Changes by Evgeny Kapun :


--
nosy: +abacabadabacaba

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25545] email.message.get_payload returns wrong encoding

[Christian Tanzer]

Christian Tanzer added the comment:

R. David Murray wrote at Tue, 03 Nov 2015 19:59:53 +:

>  Your problem is that your input email is ia unicode string.  A unicode
>  string has no RFC defintion as an email, so things do not work right,
>  as you observed.  Whether or not email should throw an error when fed
>  a non-ascii unicode string is an interesting question, but it hasn't
>  in the past and so for backward compatibility reasons we won't change
>  that.

Excuse me, I am using `email.message_from_string` which is documented
to convert a unicode string to an email object. If you are serious
`message_from_string` should not even exist! As long as it is there
and documented as::

  email.message_from_string(s, _class=email.message.Message, *, 
policy=policy.compat32)

Return a message object structure from a string. This is exactly
equivalent to Parser().parsestr(s). _class and policy are
interpreted as with the Parser class constructor.

Changed in version 3.3: Removed the strict argument. Added the
policy keyword.

your argument is unfounded and this is definitely a serious bug!

> You might also be interested in the newer email API, currently
> documented in the 'contentmanager' and 'policy' chapters of the
> documentation.  It says it is provisional, but the changes (other than
> bug fixes) between the current API and what will be final in 3.6 are
> trivial.

I'm using Python 2.7 and only just exploring 3.5.

Unfortunately, there are many bugs and your response is a typical
example why moving from 2.7 to 3.x is hard.

There is gratuitous breakage but the reaction is::

resolution:  -> not a bug

I would ask you to reconsider that stance.

As long as my code needs to support 2.7, use of any new API doesn't
fly. After an eventual switch to 3.5 (probably years in the future), I
might use new APIs for new code but changing existing code that used
to work won't be in the cards

> get_content_charset is None because you don't have any actual headers
> in your message, just body.  This is because of the leading newline in
> your triple quoted string, which the email package takes as the end of
> the headers.

Thanks for the hint. BTW, removing the leading newline doesn't change
the buggy behavior of `message_from_string`!

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25550] RecursionError in re with '(' * 500

[SilentGhost]

Changes by SilentGhost :


--
components: +Regular Expressions
nosy: +mrabarnett
versions: +Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25313] IDLE: gracefully handle themes (or keysets, or ...) not present

[Terry J. Reedy]

Terry J. Reedy added the comment:

I also want to document new Current Theme in docstring and maybe comments for 
future readers.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25498] Python 3.4.3 core dump with simple sample code

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
assignee: serhiy.storchaka -> 

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24726] OrderedDict has strange behaviour when dict.__setitem__ is used.

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Ping.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25550] RecursionError in re with '(' * 500

[Florian Bruhin]

Florian Bruhin added the comment:

I see how it's not possible to compile that pattern as it's using recursion - I 
don't mind that.

However, I think this should be handled and re-raised as a re.error ("Exception 
raised [...] when some other error occurs during compilation or matching.").

I think no matter what the pattern is, it's quite unexpected to get anything 
other than a re.error (or a TypeError) from re.compile.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25061] Add native enum support for argparse

[desbma]

desbma added the comment:

I guess the question is whether Enum should be considered a first class 
'native' type that deserves support in argparse, or just a tool among others in 
the stdlib.

The fact that Enum is implemented as a class, and lives in a module, tends to 
lead to the second, but the fact that some constants were converted to enums in 
the stdlib (like in socket) tends to the first.

As a C/C++ developer, I may have a bias towards enums :)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25539] python3 fail on parsing http header

[Martin Panter]

Martin Panter added the comment:

Just noticed the whitespace scenario is mentioned at 
:

'''
No whitespace is allowed between the header field-name and colon.  In the past, 
differences in the handling of such whitespace have led to security 
vulnerabilities in . . . response handling.  . . .  A proxy must remove any 
such whitespace from a response message before forwarding the message 
downstream.
'''

It would not be possible build a proxy that does that using Python 3’s current 
HTTP client.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25539] python3 fail on parsing http header

[Shin Dong-won]

Shin Dong-won added the comment:

Yeah, this is server's fault and python does not have to deal with non-standard 
cases. I'll close this issue. Thanks!

--
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5550] [urllib.request]: Comparison of HTTP headers should be insensitive to the case

[Martin Panter]

Martin Panter added the comment:

Regarding the original bug reported by Cocobear, I think this is by design. The 
“addheaders” attribute seems to serve as a set of default header fields, 
although this is hardly obvious from the documentation. In fact the current 
documentation suggests you have to use the application/x-www-form-urlencoded 
content type for request data. I think the documentation should be relaxed; I 
opened Issue 23360 about that.

The rest of the thread seems to have side-tracked into patches to make 
Request.has_header() and friends case insensitive. I’ll have to study the 
threads closer, but I think this side-track is a duplicate of Issue 2275.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com