[issue37605] CI should not depend on gmane response
robin added the comment: In other news, news.gmane.org is now news.gmane.io; see also https://bugs.python.org/issue39343 -- nosy: +eriker ___ Python tracker <https://bugs.python.org/issue37605> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42909] Email header with ; ; ; ; stuffing takes very long to parse
robin added the comment:
python -mtrace -t repro.py reveals a long string of these:
--- modulename: errors, funcname: __init__
errors.py(85): super().__init__(*args, **kw)
--- modulename: errors, funcname: __init__
errors.py(37): if line is not None:
errors.py(38): super().__init__(line)
errors.py(39): self.line = line
_header_value_parser.py(2417): if value and value[0] != ';':
_header_value_parser.py(2426): if value:
_header_value_parser.py(2428):
mime_parameters.append(ValueTerminal(';', 'parameter-separator'))
--- modulename: _header_value_parser, funcname: __new__
_header_value_parser.py(855): self = super().__new__(cls, value)
_header_value_parser.py(856): self.token_type = token_type
_header_value_parser.py(857): self.defects = []
_header_value_parser.py(858): return self
_header_value_parser.py(2429): value = value[1:]
_header_value_parser.py(2394): while value:
_header_value_parser.py(2395): try:
_header_value_parser.py(2396): token, value = get_parameter(value)
--- modulename: _header_value_parser, funcname: get_parameter
_header_value_parser.py(2252): param = Parameter()
--- modulename: _header_value_parser, funcname: __init__
_header_value_parser.py(110): super().__init__(*args, **kw)
_header_value_parser.py(111): self.defects = []
_header_value_parser.py(2253): token, value = get_attribute(value)
--- modulename: _header_value_parser, funcname: get_attribute
_header_value_parser.py(2135): attribute = Attribute()
--- modulename: _header_value_parser, funcname: __init__
_header_value_parser.py(110): super().__init__(*args, **kw)
_header_value_parser.py(111): self.defects = []
_header_value_parser.py(2136): if value and value[0] in CFWS_LEADER:
_header_value_parser.py(2139): if value and value[0] in ATTRIBUTE_ENDS:
_header_value_parser.py(2140): raise errors.HeaderParseError(
_header_value_parser.py(2141): "expected token but found
'{}'".format(value))
_header_value_parser.py(2398): except errors.HeaderParseError as err:
_header_value_parser.py(2399): leader = None
_header_value_parser.py(2400): if value[0] in CFWS_LEADER:
_header_value_parser.py(2402): if not value:
_header_value_parser.py(2405): if value[0] == ';':
_header_value_parser.py(2406): if leader is not None:
_header_value_parser.py(2408):
mime_parameters.defects.append(errors.InvalidHeaderDefect(
_header_value_parser.py(2409): "parameter entry with no
content"))
... which would make sense as such, except at the end, the list of defects is
empty. And, of course, it should not take so long.
--
___
Python tracker
<https://bugs.python.org/issue42909>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11021] email MIME-Version headers for each part in multipart message
robin added the comment: Propose to close as duplicate of https://bugs.python.org/issue25235 -- nosy: +eriker ___ Python tracker <https://bugs.python.org/issue11021> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25235] EmailMessage.add_attachment() creates parts with spurious MIME-Version header.
robin added the comment: Duplicate of https://bugs.python.org/issue11021 but this one is more current and has a patch. -- nosy: +eriker ___ Python tracker <https://bugs.python.org/issue25235> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42909] Email header with ; ; ; ; stuffing takes very long to parse
New submission from robin :
Attached please find a script which takes on the order of 1 minute to parse
even though the embedded message is reasonably trivial. The main flaw is that
the Content-Type: header has a long string of redundant which is something
some spammers apparently use to bypass some content filters or analyzers.
The script is short enough to inline here for what I hope is convenience for
most visitors.
from email import message_from_bytes
#from email.parser import BytesParser
from email.policy import default
##from cProfile import run as cprun
b = (b'''From: me
To: you
Subject: sample with ; stuffing in MIME Content-Type: header
Content-type: text/plain''' + b';' * 54 + b'\n' +
36 * (b' ' + b';' * 990 + b'\n') + b'''\
Content-transfer-encoding: 7bit
MIME-Version: 1.0
Hello.
''')
## cprun('message_from_bytes(b, policy=default)', sort=1)
m = message_from_bytes(b, policy=default)
#m = BytesParser(policy=default).parsebytes(b)
print(m.as_string())
I have commented out two sets of changes; the ones with a single # demonstrate
that the same error happens with BytesParser, and the ones with ## are for
profiling the code.
For what it's worth, profiling consistently indicates that it gets stuck in
builtins.sum while attempting to parse the message. Here is a partial cProfile
result from Python 3.7.2:
2148205 function calls (2004560 primitive calls) in 34.533 seconds
Ordered by: internal time
ncalls tottime percall cumtime percall filename:lineno(function)
160/4 32.3560.202 32.7288.182 {built-in method builtins.sum}
40.5600.1401.6610.415
_header_value_parser.py:2380(parse_mime_parameters)
1427720.2300.0000.2300.000 {method 'format' of 'str' objects}
1429320.2030.0000.2030.000
_header_value_parser.py:866(all_defects)
1427720.1970.0000.2880.000 errors.py:84(__init__)
143248/240.1670.000 32.7271.364
_header_value_parser.py:126()
1427720.1510.0000.4560.000
_header_value_parser.py:2126(get_attribute)
2858480.1460.0000.1460.000
_header_value_parser.py:109(__init__)
1427720.1020.0000.6310.000
_header_value_parser.py:2241(get_parameter)
1427720.0910.0000.0910.000 errors.py:36(__init__)
1430760.0880.0000.1530.000
_header_value_parser.py:854(__new__)
1430800.0650.0000.0650.000 {built-in method __new__ of type
object at 0x101c20640}
120.0440.0040.0860.007
_header_value_parser.py:716(params)
2858390.0420.0000.0420.000 {method 'endswith' of 'str'
objects}
30.0300.010 27.5129.171
message.py:588(get_content_maintype)
2864820.0290.0000.0290.000 {method 'append' of 'list'
objects}
20.0140.0070.0140.007 :914(get_data)
60.0080.001 25.3694.228 feedparser.py:218(_parsegen)
40.0010.0000.0010.000 {method 'split' of 're.Pattern'
objects}
160/40.0010.000 32.7288.182
_header_value_parser.py:124(all_defects)
2880.0010.0000.0020.000
_header_value_parser.py:1000(get_fws)
2880.0010.0000.0030.000
_header_value_parser.py:1217(get_cfws)
Starting the code and doing a KeyboardInterrupt after a few, or many, seconds
tends to get a traceback like this, which also points to roughly the same
culprit:
^CTraceback (most recent call last):
File "repro.py", line 18, in
m = message_from_bytes(b, policy=default)
File "/Users/eriker/.pyenv/versions/3.7.2/lib/python3.7/email/__init__.py",
line 46, in message_from_bytes
return BytesParser(*args, **kws).parsebytes(s)
File "/Users/eriker/.pyenv/versions/3.7.2/lib/python3.7/email/parser.py",
line 124, in parsebytes
return self.parser.parsestr(text, headersonly)
File "/Users/eriker/.pyenv/versions/3.7.2/lib/python3.7/email/parser.py",
line 68, in parsestr
return self.parse(StringIO(text), headersonly=headersonly)
File "/Users/eriker/.pyenv/versions/3.7.2/lib/python3.7/email/parser.py",
line 57, in parse
feedparser.feed(data)
File "/Users/eriker/.pyenv/versions/3.7.2/lib/python3.7/email/feedparser.py",
line 176, in feed
self._call_parse()
File "/Users/eriker/.pyenv/versions/3.7.2/lib/python3.7/email/feedparser.py",
line 180, in _call_parse
self._parse()
File "/Users/eriker/.pyenv/versions/3.7.2/lib/python3.7/email/feedparser.py",
line 256, in _parsegen
if self._cur.get_content_type() == 'message/delivery-status':
File &
[issue42850] Process hangs when calling urllib.request in a multiprocessing.Process with import of sounddevice package
Robin Scheibler added the comment: Thank you very much for your help! -- ___ Python tracker <https://bugs.python.org/issue42850> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42850] Process hangs when calling urllib.request in a multiprocessing.Process with import of sounddevice package
Robin Scheibler added the comment: Thanks for the suggestion. I had indeed run into some issues with fork vs spawn before. I have tested with 3.8.5 and 3.9.1 and the bug doesn't occur with these more recent versions. Should I leave the bug open since 3.7 is still supported ? -- ___ Python tracker <https://bugs.python.org/issue42850> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42850] Process hangs when calling urllib.request in a multiprocessing.Process with import of sounddevice package
Robin Scheibler added the comment: Thank you very much for the reply! I was indeed hesitating where to post the issue. I have now cross-posted in the sounddevice issue tracker. https://github.com/spatialaudio/python-sounddevice/issues/302 I'll update the issue if things progress on that side. The sounddevice is essentially a wrapper around the portaudio library, similar to pyaudio. I have tried the test code with an import of pyaudio rather than sounddevice, but the issue does not happen in that case. -- ___ Python tracker <https://bugs.python.org/issue42850> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42850] Process hangs when calling urllib.request in a multiprocessing.Process with import of sounddevice package
New submission from Robin Scheibler : I am having an issue with using urllib in a multiprocessing.Process when the package sounddevice (https://github.com/spatialaudio/python-sounddevice) has been already imported. The sub-process hangs upon calling urllib.request.urlopen (and methods from the requests package too). 1. If the package sounddevice is not imported, things work as expected. 2. If the package sounddevice is imported, but urllib.request.urlopen is called once prior to launching thee sub-process, then things also work as expected. I have attached a file containing code to reproduce the issue. I have run this example file in: - Python 3.7.9 (conda distribution) - Mac OS X 10.15.7 # Running the code as is reproduces the problem > python ./test_mp_req.py Nothing in the queue. Leave. wait for process to terminate... finished # Running the code with either line 8 commented *or* line 32 uncommented # gives the expected output > python ./test_mp_req.py Received https://api.github.com. Send GET request... done. Received https://www.google.com. Send GET request... done. https://api.github.com: ok https://www.google.com: ok Nothing in the queue. Leave. wait for process to terminate... finished -- components: Interpreter Core, Library (Lib), ctypes files: test_mp_req.py messages: 384562 nosy: fakufaku priority: normal severity: normal status: open title: Process hangs when calling urllib.request in a multiprocessing.Process with import of sounddevice package type: crash versions: Python 3.7 Added file: https://bugs.python.org/file49724/test_mp_req.py ___ Python tracker <https://bugs.python.org/issue42850> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40803] Unable to execute python.exe from zip in wine
Change by Robin : -- stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue40803> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40803] Unable to execute python.exe from zip in wine
Robin added the comment: Good News. The wine people say "Fixed in wine 4.0". So, a happy result. https://bugs.winehq.org/show_bug.cgi?id=49271 We can close this. -- ___ Python tracker <https://bugs.python.org/issue40803> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40803] Unable to execute python.exe from zip in wine
Robin added the comment: Thanks for such a rapid response. Much appreciated. I think it's a bug in wine, so I've also reported it to them. And you both know that you both have it on your radar! I believe the Win32/API PathCchCanonicalizeEx() is quite new, and that's why it's not in wine-core-magic. However, python could consider reverting to your earlier code. And another possibility is to test that PathCchCanonicalizeEx != NULL before calling it. If it is NULL, then use the "old" code. https://docs.microsoft.com/en-us/windows/win32/api/pathcch/nf-pathcch-pathcchcanonicalizeex Let's see what the wine men (and ladies) say! -- ___ Python tracker <https://bugs.python.org/issue40803> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40803] Unable to execute python.exe from zip in wine
Robin added the comment: I've reported this to the wine team: https://bugs.winehq.org/show_bug.cgi?id=49271 -- ___ Python tracker <https://bugs.python.org/issue40803> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40803] Unable to execute python.exe from zip in wine
New submission from Robin : I've downloaded python38.zip(and python32.zip). It doesn't run because it's using an API `PathCchCanonicalizeEx()` that's not provided in wine. ``` Z:\home\rmills\temp\python-3>wine: Call from 0x7b43cfbc to unimplemented function api-ms-win-core-path-l1-1-0.dll.PathCchCanonicalizeEx, aborting wine: Unimplemented function api-ms-win-core-path-l1-1-0.dll.PathCchCanonicalizeEx called at address 0x7bc50023:0x7b43cfbc (thread 0034), starting debugger... Unhandled exception: unimplemented function api-ms-win-core-path-l1-1-0.dll.PathCchCanonicalizeEx called in 32-bit code (0x7b43cfbc). ``` -- components: Windows messages: 370183 nosy: clanmills, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Unable to execute python.exe from zip in wine type: crash versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue40803> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38728] Update PC/pyconfig.h to support disabling auto linking
Jean-Christophe Fillion-Robin added the comment: Associated pull request has been updated, CLA signed and it is ready for final review and integration. Thanks so much for your time, -- ___ Python tracker <https://bugs.python.org/issue38728> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33339] Using default encoding with `subprocess.run()` is not obvious
Change by Xavier Robin : -- nosy: +Xavier Robin ___ Python tracker <https://bugs.python.org/issue9> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38728] Update PC/pyconfig.h to support disabling auto linking
Jean-Christophe Fillion-Robin added the comment: PY_NO_LINK_LIB will work well. I will work on a patch later this week. -- ___ Python tracker <https://bugs.python.org/issue38728> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38728] Update PC/pyconfig.h to support disabling auto linking
New submission from Jean-Christophe Fillion-Robin : When configuring project using build-system generator like CMake, the linking is explicitly handled and does not to be implicitly hard-coded in pyconfig.h Having the "pythonXY.lib" library hard-coded in pyconfig.h currently requires to explicitly specify a link directory. While possible, this require to increase the complexity of our build-system. I suggest we introduce a new macro (e.g PY_CONFIG_AUTOLINK_DISABLED) -- components: Windows messages: 356158 nosy: Jean-Christophe Fillion-Robin, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Update PC/pyconfig.h to support disabling auto linking type: enhancement versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue38728> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33425] Library glob : Can't find a specific year with glob
Change by Robin Champavier : -- stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue33425> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33425] Library glob : Can't find a specific year with glob
New submission from Robin Champavier : Hello, I work with file name like : PRECI_mmddhh_00.txt and I put them in different directory depending of the year. For file between year 1999 and 2016 there is no problem but with file in year 2017 with months 12, glob.glob can't find them. When I do print K in my file Tri_fichier_texte.py there is no file with PRECI_201712.txt but it works to find the beginning of the year 2017 like PRECI_201701xxx.txt. All file get exactly the same syntax. Thanks for looking my issues. -- components: Library (Lib) files: Tri_fichier_texte.py messages: 316163 nosy: Robin Champavier priority: normal severity: normal status: open title: Library glob : Can't find a specific year with glob versions: Python 2.7 Added file: https://bugs.python.org/file47571/Tri_fichier_texte.py ___ Python tracker <https://bugs.python.org/issue33425> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31325] req_rate is a namedtuple type rather than instance
New submission from Robin:
> Finally, urllib/robotparser.py appears to contain a bug in the
> following:
>
> req_rate = collections.namedtuple('req_rate',
>'requests seconds')
> entry.req_rate = req_rate
> entry.req_rate.requests = int(numbers[0])
> entry.req_rate.seconds = int(numbers[1])
>
> As I read it, this should fail as the req_rate is immutable.
Ref: https://news.ycombinator.com/item?id=15136961
They are mistaken in the nature of the bug, which is that req_rate is
a namedtuple type, rather than an instance. As such, it is actually
mutable, causing the assignments to not fail. Every entry creates a
separate req_rate type, so it all works, but not in the way it should.
--
components: Library (Lib)
messages: 301127
nosy: gvx
priority: normal
pull_requests: 3307
severity: normal
status: open
title: req_rate is a namedtuple type rather than instance
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7
___
Python tracker
<http://bugs.python.org/issue31325>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29016] negative numbers raised to power zero should be 1, not -1
Robin W Gambill added the comment: I see my error now. I'm sorry for my ignorance. I will google how to delete the bugs item, but I guess is permanent, se la vie. Thank you. Robin On Mon, 12/19/16, Tim Peters wrote: Subject: [issue29016] negative numbers raised to power zero should be 1, not -1 To: r_w_gamb...@yahoo.com Date: Monday, December 19, 2016, 12:51 PM New submission from Tim Peters: They already are. >>> (-2)**0 1 You're probably doing this instead: >>> -2**0 -1 Exponentiation has higher precedence than unary minus, so that last example groups as -(2**0), and -1 is correct. -- nosy: +tim.peters resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <http://bugs.python.org/issue29016> ___ -- ___ Python tracker <http://bugs.python.org/issue29016> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29016] negative numbers raised to power zero should be 1, not -1
Changes by Robin W Gambill : -- components: Interpreter Core nosy: rwgambill priority: normal severity: normal status: open title: negative numbers raised to power zero should be 1, not -1 type: behavior versions: Python 3.5 ___ Python tracker <http://bugs.python.org/issue29016> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28092] Build failure for 3.6 on Centos 5.11
Robin Becker added the comment: for what it's worth I tried reverse patching https://hg.python.org/cpython/rev/63ae310b60ff/ and https://hg.python.org/cpython/rev/2f77a9f0b9d6/ in the manylinux docker and the make then proceeds fine with one warning at the end *** WARNING: renaming "_sqlite3" since importing it failed: build/lib.linux-x86_64-3.6/_sqlite3.cpython-36m-x86_64-linux-gnu.so: undefined symbol: sqlite3_stmt_readonly Following modules built successfully but were removed because they could not be imported: _sqlite3 -- ___ Python tracker <http://bugs.python.org/issue28092> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28092] Build failure for 3.6 on Centos 5.11
Robin Becker added the comment: After some searching I tried adding -std=gnu99 and the config goes through OK, but running make produces [root@d3cce9786c2e Python-3.6.0b2]# make -j2 gcc -pthread -c -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -Wformat -fno-gnu89-inline -std=gnu99 -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -I. -I./Include-DPy_BUILD_CORE -o Programs/python.o ./Programs/python.c gcc -pthread -c -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -Wformat -fno-gnu89-inline -std=gnu99 -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -I. -I./Include-DPy_BUILD_CORE -o Parser/acceler.o Parser/acceler.c /tmp/cc3Mfloe.s: Assembler messages: /tmp/cc3Mfloe.s:1575: Error: symbol `stat64' is already defined /tmp/cc3Mfloe.s:1595: Error: symbol `lstat64' is already defined /tmp/cc3Mfloe.s:1615: Error: symbol `fstat64' is already defined /tmp/cc3Mfloe.s:1635: Error: symbol `fstatat64' is already defined make: *** [Programs/python.o] Error 1 make: *** Waiting for unfinished jobs /tmp/ccOoXPte.s: Assembler messages: /tmp/ccOoXPte.s:1575: Error: symbol `stat64' is already defined /tmp/ccOoXPte.s:1595: Error: symbol `lstat64' is already defined /tmp/ccOoXPte.s:1615: Error: symbol `fstat64' is already defined /tmp/ccOoXPte.s:1635: Error: symbol `fstatat64' is already defined make: *** [Parser/acceler.o] Error 1 [root@d3cce9786c2e Python-3.6.0b2]# -- ___ Python tracker <http://bugs.python.org/issue28092> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28092] Build failure for 3.6 on Centos 5.11
Robin Becker added the comment: benjamin.peterson: I tried adding that option -fno-gnu89-inline conditionally for the 3.6.0b2 build, but it goes wrong in config with an error configure:3913: $? = 4 configure:3933: checking whether the C compiler works configure:3955: gcc -Wformat -fno-gnu89-inline conftest.c >&5 cc1: error: -fno-gnu89-inline is only supported in GNU99 or C99 mode The full docker output is here https://www.reportlab.com/media/manylinux-docker-run-output-2.txt -- ___ Python tracker <http://bugs.python.org/issue28092> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28092] Build failure for 3.6 on Centos 5.11
Robin Becker added the comment: I'm not able to access my work computer, I'll try later today at home. -- ___ Python tracker <http://bugs.python.org/issue28092> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28092] Build failure for 3.6 on Centos 5.11
Robin Becker added the comment: tds333, the config says that 4.8.2 is being used, configure:3902: gcc --version >&5 gcc (GCC) 4.8.2 20140120 (Red Hat 4.8.2-15) Copyright (C) 2013 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. but perhaps the make is doing something else or the build goes wrong because shared is disabled. -- ___ Python tracker <http://bugs.python.org/issue28092> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28092] Build failure for 3.6 on Centos 5.11
Robin Becker added the comment: Hi njs, my manylinux diffs https://www.reportlab.com/media/manylinux-diff.txt full output of the docker command docker build -f Dockerfile-x86_64 -t rl/manylinux-x86_64 . &> ~/tmp/ttt https://www.reportlab.com/media/manylinux-docker-run-output.txt the end showing the 3.6b2 config and the failure https://www.reportlab.com/media/manylinux-docker-run-python-3.6b2.txt -- ___ Python tracker <http://bugs.python.org/issue28092> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28092] Build failure for 3.6 on Centos 5.11
Robin Becker added the comment: I executed gcc --version (&cc --version) in the do_cpython_build function immediately prior to the make -j2 that builds python noth show 4.8.2. I see the exact same errors as in the initial report. If the makefile or the configure is doing something special then I guess I have to work around that. A possibility is that the CFLAGS="-Wformat" in the environment or the configure argument --disable-shared is having some effect. I have made very few changes to the build scripts. -- ___ Python tracker <http://bugs.python.org/issue28092> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28092] Build failure for 3.6 on Centos 5.11
Robin Becker added the comment: Don't want to add too much noise, but this issue also affects the manylinux project build compiler (gcc 4.8.2). -- nosy: +rgbecker ___ Python tracker <http://bugs.python.org/issue28092> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27707] List reports incorrect length if modifed after yield
New submission from Robin: reproduction script below. In the last print statement, it shows me a list with items in it, but with a length of 0 def generator(): l = [] yield l l.append(1) # this correctly prints 1 print(len(l)) # this should print [([1], 1)], but actually gives [([1], 0)] print([(l, len(l)) for l in generator()]) -- components: Interpreter Core messages: 272151 nosy: robinh priority: normal severity: normal status: open title: List reports incorrect length if modifed after yield type: behavior versions: Python 3.4 ___ Python tracker <http://bugs.python.org/issue27707> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2466] os.path.ismount doesn't work for mounts the user doesn't have permission to see
Robin Roth added the comment: Based on the review by SilentGhost I removed all refactoring-changes and only left the one line needed for the fix. -- Added file: http://bugs.python.org/file43140/minimal_fix_ismount_directory_not_readable.patch ___ Python tracker <http://bugs.python.org/issue2466> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2466] os.path.ismount doesn't work for mounts the user doesn't have permission to see
Robin Roth added the comment: Any progress on merging this? The fix is simple, there is a test; anything else I can do to help? Ansible integrated the patch posted here as a workaround of an issue this caused. So there was some external review of the fix. See https://github.com/ansible/ansible-modules-core/pull/2737 -- versions: +Python 3.2, Python 3.3 ___ Python tracker <http://bugs.python.org/issue2466> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2466] os.path.ismount doesn't work for mounts the user doesn't have permission to see
Robin Roth added the comment: any comments/updates on merging this? -- ___ Python tracker <http://bugs.python.org/issue2466> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2466] os.path.ismount doesn't work for mounts the user doesn't have permission to see
Robin Roth added the comment: Antoine's suggestion does not work, because "dirname" does not cover enough cases (for example trailing slash, possibly more). As suggested by him I now use realpath (instead of abspath). I can't come up with a symlink-situation that is broken with the old code, but realpath is what "ismount" actually means. I also added a testcase that resembles the issue, i.e. it fails with the old code and passes with the fix. I mock the "Permission denied" by raising a generic OSError. Mocking can not resemble every real-life situation but by simulating all issues reporting and then fixing them, one should get a solid test coverage. I also took the liberty of minor cleanup in/around the functions changed, i.e. remove unused imports and remove single-use variables to make the code easier to read. Attached the updated patch. -- Added file: http://bugs.python.org/file41041/test_fix_ismount_directory_not_readable.patch ___ Python tracker <http://bugs.python.org/issue2466> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2466] os.path.ismount doesn't work for mounts the user doesn't have permission to see
Robin Roth added the comment: Is there any more info needed to the issue or the patch? It would be really helpful to have this fixed and I don't see any critical changes due to the patch. There is an issue in ansible depending on this fix: https://github.com/ansible/ansible-modules-core/issues/2186 Also the current development version is affected (I manually checked 2.7, 3.0, 3.5, dev). -- versions: +Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 ___ Python tracker <http://bugs.python.org/issue2466> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2466] os.path.ismount doesn't work for mounts the user doesn't have permission to see
Robin Roth added the comment: This bug is still present and annoying. For me it appeared when running ismount on a nfs-mounted directory, when the user who runs python has no read permission inside the directory. Therefore the lstat on /mntdir/.. fails. Attached a patch that fixes this by running abspath on the path. Symlinks will also work because they are checked/excluded before the part of the code where the patch is in. msg222528 is not related to the original bug and should be opened separately. -- keywords: +patch nosy: +Robin Roth Added file: http://bugs.python.org/file40641/ismount-permission.patch ___ Python tracker <http://bugs.python.org/issue2466> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25123] Logging Documentation - dictConfig disable_existing_loggers
New submission from Robin: logging.config.dictConfig appears to share the same parameter as logging.config.fileConfig - disable_existing_loggers. This parameter is documented for fileConfig but not dictConfig. Suggest update to dictConfig documentation section. -- assignee: docs@python components: Documentation messages: 250755 nosy: coderobot, docs@python priority: normal severity: normal status: open title: Logging Documentation - dictConfig disable_existing_loggers type: enhancement versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue25123> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18610] wsgiref.validate expects wsgi.input read to give exactly one arg
Robin Schoonover added the comment: I'm not sure I follow, as it has little to say on whether the application's expected behavior here, and only a recommendation that the server allow it. But, it also defers to the "Python Standard Library", which does have an opinion. I feel that (in hindsight) the exact behavior of each method should have been specified in full. *However*, even if I differ on the reading of the spec, on general principle (and this has changed since I first wrote the issue) I agree that the application should not be omitting it anyway, because reading the entire response at once without checking the content length is dangerous. -- ___ Python tracker <http://bugs.python.org/issue18610> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22342] Fix typo in PEP 380 -- Syntax for Delegating to a Subgenerator
New submission from Gael Robin: The first line of the Refactoring Principle subsection of the Rationale section contains the following typo : "It should be possible to take an section of code" should be "It should be possible to take a section of code" -- assignee: docs@python components: Documentation messages: 226425 nosy: Gael.Robin, docs@python priority: normal severity: normal status: open title: Fix typo in PEP 380 -- Syntax for Delegating to a Subgenerator type: enhancement ___ Python tracker <http://bugs.python.org/issue22342> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1047397] cgitb failures
Robin Becker added the comment: I'll repeat the post I made to BreamoreBoy regarding this bug: "re: http://bugs.python.org/issue1047397 this bug is now 10 years old. I'm not sure why it's to be considered closed because the original intent of the bug report was that the html output of the cgitb module could be confused and errors during evaluation could make the html output fail. So far as I can tell by modifying the original cgitbbug.py to run under python 3.4.1 it still fails to correctly produce html when a bug occurs in cgitb.html. Producing a more reasonable traceback is certainly a step forward, but I think that has been true since at least 3.1. The whole point of cgitb is to produce something reasonable for an html consumer." I have re-created the original 002 patch with mods for python 3.4.1. It's a bit of a shame that this wasn't fixed 10 years ago. Hopefully any style pedants will find this patch more acceptable. Personally I don't think style errors should prevent a working fix from being adopted. I would have just fixed the fix style and carped afterwards. -- Added file: http://bugs.python.org/file35995/bugfix003.patch ___ Python tracker <http://bugs.python.org/issue1047397> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21890] wsgiref.simple_server sends headers on empty bytes
Changes by Robin Schoonover : Added file: http://bugs.python.org/file35836/wsgiref-empty-byte-3.patch ___ Python tracker <http://bugs.python.org/issue21890> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21890] wsgiref.simple_server sends headers on empty bytes
Robin Schoonover added the comment: I agree, the current patch is too permissive. Both a server I wrote a while ago, and most other "complaint" servers deal with the problem the exact same way as that patch, and that extra permissiveness led to my misinterpretation when analyzing why I had made that original change. In any case, I've attached an updated patch. -- resolution: not a bug -> status: closed -> open title: wsgiref.simple_server doesn't accept empty bytes before start_response is called -> wsgiref.simple_server sends headers on empty bytes Added file: http://bugs.python.org/file35835/wsgiref-empty-byte-2.patch ___ Python tracker <http://bugs.python.org/issue21890> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21890] wsgiref.simple_server doesn't accept empty bytes before start_response is called
Robin Schoonover added the comment:
Fair enough, I misled myself.
However, and I feel like I'm getting really picky here, but it still doesn't
fulfill the paragraph I quoted:
def application(environ, start_response):
start_response('200 OK',
[('Content-type', 'text/plain')])
yield b''
try:
# produce an exception tuple, so we can re-call s_r
raise RuntimeError
except RuntimeError:
# Headers shouldn't have been sent, but they were
# so this will throw:
start_response('200 OK',
[('Content-type', 'text/plain')],
sys.exc_info())
yield b'error data or whatever'
But if async support a foregone conclusion anyway, is it worth bothering
complying with that odd requirement?
--
___
Python tracker
<http://bugs.python.org/issue21890>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18610] wsgiref.validate expects wsgi.input read to give exactly one arg
Changes by Robin Schoonover : -- nosy: +pje ___ Python tracker <http://bugs.python.org/issue18610> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21890] wsgiref.simple_server doesn't accept empty bytes before start_response is called
New submission from Robin Schoonover:
Consider this paragraph of PEP, referring to headers obtained
via start_response, emphasis mine:
Instead, it must store them for the server or gateway to
transmit only after the first iteration of the application
return value that yields a *non-empty bytestring*, or upon
the application's first invocation of the write() callable.
This means that an WSGI app such as this should be valid, because the
yielded bytes pre-start_response are empty:
def application(environ, start_response):
yield b''
start_response("200 OK", [("Content-Type", "text/plain")])
yield b'Hello, World.\n'
However, in wsgiref's simple server, this fails:
Traceback (most recent call last):
File "/usr/local/lib/python3.4/wsgiref/handlers.py", line 180, in
finish_response
self.write(data)
File "/usr/local/lib/python3.4/wsgiref/handlers.py", line 269, in write
raise AssertionError("write() before start_response()")
AssertionError: write() before start_response()
--
components: Library (Lib)
messages: 222005
nosy: pje, rschoon
priority: normal
severity: normal
status: open
title: wsgiref.simple_server doesn't accept empty bytes before start_response
is called
type: behavior
___
Python tracker
<http://bugs.python.org/issue21890>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21890] wsgiref.simple_server doesn't accept empty bytes before start_response is called
Changes by Robin Schoonover : -- keywords: +patch Added file: http://bugs.python.org/file35810/wsgiref-empty-byte.patch ___ Python tracker <http://bugs.python.org/issue21890> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21878] wsgi.simple_server's wsgi.input read/readline waits forever in certain circumstances
Robin Schoonover added the comment: Issue also occurs if .read() is used with no size. -- title: wsgi.simple_server's wsgi.input readline waits forever for non-multipart/form-data -> wsgi.simple_server's wsgi.input read/readline waits forever in certain circumstances ___ Python tracker <http://bugs.python.org/issue21878> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21878] wsgi.simple_server's wsgi.input readline waits forever for non-multipart/form-data
New submission from Robin Schoonover:
In the reference WSGI server in wsgiref.simple_server, wsgi.input's readline()
hangs if the request body does not actually contain any
newlines.
Consider the following (slightly silly) example:
from wsgiref.simple_server import make_server
def app(environ, start_response):
result = environ['wsgi.input'].readline()
# not reached...
start_response("200 OK", [("Content-Type", "text/plain")])
return []
httpd = make_server('', 8000, app)
httpd.serve_forever()
And the following also silly request (the data kwarg makes it a
POST request):
from urllib.request import urlopen
req = urlopen("http://localhost:8000/";, data=b'some bytes')
print(req)
Normally this isn't a problem, as the reference server isn't intended
for production, and typically the only reason .readline() would be
used is with a request body formatted as multipart/form-data, which
uses ample newlines, including with the content boundaries. However,
for other types of request bodies (such as application/x-www-form-urlencoded)
newlines often wouldn't appear, and using .readline() would wait forever for
new input.
--
components: Library (Lib)
messages: 221774
nosy: rschoon
priority: normal
severity: normal
status: open
title: wsgi.simple_server's wsgi.input readline waits forever for
non-multipart/form-data
type: behavior
___
Python tracker
<http://bugs.python.org/issue21878>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15849] PEP 3121, 384 Refactoring applied to xx module
Robin Schreiber added the comment: Everything except for the Xxo_Type. But you are right. Then again, why are these global static variables from the start? Isn't this because xxmodule is some kind of "dummy" module that is supposed to demonstrate some coding conventions on how to build extension modules? Another possibility could be the faster lookup of the variables, which is now of course invalidated if we store it within the module state. -- ___ Python tracker <http://bugs.python.org/issue15849> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15849] PEP 3121, 384 Refactoring applied to xx module
Robin Schreiber added the comment: Updated patch accordingly. Regarding the problem in http://mail.python.org/pipermail/python-dev/2013-August/127862.html , it can indeed be solved by returning the already existing module object, if PyInit is called multiple times. I followed the discussion and can not make out a definite decision on how to handle this. My understanding is, that up to now extension modules are only supposed to be initialized once per interpreter, so the check I have included in, for example issue15651, makes sense from this perspective. There have been reasonable desires (from Eli) to make the module state separate from each imported module within the interpreter, but this would involve more drastic changes and will be rather part of future Python releases. Should we therefore (for now) make this a mandatory PEP3121 convention and include it into the xxmodule.c refactoring? -- Added file: http://bugs.python.org/file31355/xxmodule_pep3121-384_v2.patch ___ Python tracker <http://bugs.python.org/issue15849> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15849] PEP 3121, 384 Refactoring applied to xx module
Robin Schreiber added the comment: Antoine, regarding that the last pending problem with the patch is related to the NULL checking of FindModule, I would be inclined to include your proposed helper API. I see that issue18710 has not been included into the trunk yet, but I think this is mostly due to the additional _csv patch and not because of the proposed API itself. So I will upload a corrected version of the patch soon, but it will rely on issue18710 to be accepted beforehand... -- ___ Python tracker <http://bugs.python.org/issue15849> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15849] PEP 3121, 384 Refactoring applied to xx module
Robin Schreiber added the comment: Updated the patch, corrected multiple syntax errors and missing INCREFS. Also added the comments that include the members names. I am yet undecided regarding the NULL-check for FindModule. Apart from that I have tried to build some tests that prove that loading and unloading the module do not cause any memory leaks. This has turned up several problems: For one, the only possibility to check for the leaks that PEP 3121 tries to fix, is to run PyInit of the respective module multiple times. This is only possible if Py_finalize() has been called after the module has been imported beforehand. This means we can not test for these leaks from within Python, but need some C-Code that calls Py_initialize(); ... import xx ... Py_finalize(); multiple times. The problem is that also the plain Py_initialize(); Py_finalize(); calls leak memory. Unfortunately the amount of objects that are leaked also seems to vary, so there is no constant factor that I can subtract to determine how much the imported module itself leaks. So I am kind of on a dead end here. I could upload the tests scripts that I have written so far, if that helps. -- keywords: +patch Added file: http://bugs.python.org/file31272/xxmodule_pep3121-384_v1.patch ___ Python tracker <http://bugs.python.org/issue15849> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15849] PEP 3121, 384 Refactoring applied to xx module
Robin Schreiber added the comment: I absolutely agree on mentioning the member names in the comments. :-) In the example Martin gave in his PEP 3121, the PyInit does not perform any INCREFs on the Variables that are referenced from inside the module state. He therefore left out m_free completely as there was nothing to DECREF within the module state. Back when I did my GSoC together with Martin, we decided that the Module state itself can be considered a valid container object, an therefore has to INCREF and in the end of its lifecycle (that is within m_free) also DECREF every object reference it holds. I therefore decided to include that into every module I refactored, and consequently also the xxmodule. I was also thinking about redefining the macro of xx_state_global with a NULL check, however this would lead either to a redundant call of PyState_FindModule (Which may lead to unnecessary performance degregation as xx_state_global is used quite frequently in some parts of the respective module) or I had to find some awkward way to store the result o f FindModule in some local variable exapnded by the macro, which I would not consider a good idea. Instead Martin and I were thinking of including a NULL safe variant of xx_state_global only in CPython Debug Builds. What do you think about that? -- ___ Python tracker <http://bugs.python.org/issue15849> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15787] PEP 3121, 384 Refactoring
Robin Schreiber added the comment: I have in fact used abitype.py to produce all of my PEP 384 patches, however it failed to work correctly in like 50% of all cases, and I had to complete the rest of the patch by hand.I thought about correcting the abitype.py throughout the GSOC, but I happened to find it easier to simply do the missing steps by hand. (I don't know If the script has been fixed up to this point though). In any case, it might also be interesting for external extension module developers to make use of a fully working version of this script, so they can make their modules PEP 384 compliant without investing too much time. One has to keep in mind however that almost any script will fail to work by itself, once we run into problems like refcounting or concurrency when applying the patch to a module. I will have some free time throughout next week and will start to correct the patches for the xx modules (as Alex proposed), and continue from there to all the other patches I have submitted a year ago. I am deeply sorry that I have not continued my work on this project earlier, however I dramatically underestimated the amount if work related to university, etc... I still feel obliged to complete all these patches. -- ___ Python tracker <http://bugs.python.org/issue15787> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18610] wsgiref.validate expects wsgi.input read to give exactly one arg
Changes by Robin Schoonover : -- title: wsgiref.validator expects wsgi.input read to give exactly one arg -> wsgiref.validate expects wsgi.input read to give exactly one arg ___ Python tracker <http://bugs.python.org/issue18610> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18610] wsgiref.validator expects wsgi.input read to give exactly one arg
New submission from Robin Schoonover: wsgiref.validator requires wsgi.input's read to always give EXACTLY one argument. This is incorrect. It's own documentation says: * That wsgi.input is used properly: - .read() is called with zero or one argument PEP says: A server should allow read() to be called without an argument, and return the remainder of the client's input stream. -- components: Library (Lib) files: wsgiref.patch keywords: patch messages: 194027 nosy: Robin.Schoonover priority: normal severity: normal status: open title: wsgiref.validator expects wsgi.input read to give exactly one arg type: behavior versions: Python 3.3 Added file: http://bugs.python.org/file31106/wsgiref.patch ___ Python tracker <http://bugs.python.org/issue18610> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15691] PEP 3121, 384 Refactoring applied to posix module
Robin Schreiber added the comment: Updated posixmodule to work with the 3.4 Branch version. -- keywords: +patch Added file: http://bugs.python.org/file28317/posix_pep3121-384_v1.patch ___ Python tracker <http://bugs.python.org/issue15691> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15690] PEP 3121, 384 Refactoring applied to parser module
Robin Schreiber added the comment: Updated parsermodule patch to work with 3.4 Branch version. -- keywords: +patch Added file: http://bugs.python.org/file28316/parser_pep3121-384_v1.patch ___ Python tracker <http://bugs.python.org/issue15690> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15671] PEP 3121, 384 Refactoring applied to struct module
Robin Schreiber added the comment: Updated patch to work with 3.4 Branch version of _struct.c -- keywords: +patch Added file: http://bugs.python.org/file28315/_struct_pep3121-384_v1.patch ___ Python tracker <http://bugs.python.org/issue15671> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15651] PEP 3121, 384 refactoring applied to elementtree module
Robin Schreiber added the comment: Patch updated to work with current 3.4 Branch version of elementtree. -- keywords: +patch Added file: http://bugs.python.org/file28311/_elementtree_pep3121-384_v1.patch ___ Python tracker <http://bugs.python.org/issue15651> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15390] PEP 3121, 384 refactoring applied to datetime module
Robin Schreiber added the comment: I have updated the patch to work again with the current version of the _datetimemodule. Regarding the suggestion of separating PEP3121 and PEP384. It might be true that datetime and other modules do not benefit directly from PEP 384, however it is still a fact that the stdlib modules should be seen as a set of reference modules, that are all implemented in a way that complies with the implementation fo the xxmodules. I have talked with Martin von Löwis about this, and as far as I understood him correctly he also sees the PEP384 refactoring applied to the whole stdlib as a nessecary "signal" to other developers to refactor their modules accordingly. Anyway I am planning to start to commit all of the open changes that I have created during my GSOC in the next few months. So a decision regarding this separation concern might be helpful. :-) -- keywords: +patch Added file: http://bugs.python.org/file28274/_datetimemodule_pep3121-384_v3.patch ___ Python tracker <http://bugs.python.org/issue15390> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15727] PyType_FromSpecWithBases tp_new bugfix
Robin Schreiber added the comment: Here is revised version of the patch. Martin von Löwis and I had discovered a way to reproduce problems with refactored modules, that occur without this patch. This is was several months ago, however I will try to give you a code sample! :-) -- keywords: +patch Added file: http://bugs.python.org/file28167/PyType_FromSpecWithBases_tp_new_fix_v1.patch ___ Python tracker <http://bugs.python.org/issue15727> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15650] PEP 3121, 384 refactoring applied to dbm module
Robin Schreiber added the comment: Take a look at the discussion in Issue 15653. -- ___ Python tracker <http://bugs.python.org/issue15650> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15389] PEP 3121, 384 refactoring applied to curses module
Changes by Robin Schreiber : -- keywords: +pep3121 -patch ___ Python tracker <http://bugs.python.org/issue15389> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15682] PEP 3121 refactoring applied to fpectl module
Changes by Robin Schreiber : -- keywords: +pep3121 -patch nosy: +loewis ___ Python tracker <http://bugs.python.org/issue15682> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15684] PEP 3121 refactoring applied to fpetest module
Changes by Robin Schreiber : -- keywords: +pep3121 -patch nosy: +loewis ___ Python tracker <http://bugs.python.org/issue15684> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15680] PEP 3121 refactoring applied to audioop module
Changes by Robin Schreiber : -- keywords: +pep3121 -patch nosy: +loewis ___ Python tracker <http://bugs.python.org/issue15680> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15681] PEP 3121 refactoring applied to binascii module
Changes by Robin Schreiber : -- keywords: +pep3121 -patch nosy: +loewis ___ Python tracker <http://bugs.python.org/issue15681> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15685] PEP 3121, 384 Refactoring applied to itertools module
Changes by Robin Schreiber : -- keywords: +pep3121 -patch nosy: +loewis ___ Python tracker <http://bugs.python.org/issue15685> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15686] PEP 3121, 384 Refactoring applied to md5 module
Changes by Robin Schreiber : -- keywords: +pep3121 -patch ___ Python tracker <http://bugs.python.org/issue15686> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15687] PEP 3121, 384 Refactoring applied to mmap module
Changes by Robin Schreiber : -- keywords: +pep3121 -patch nosy: +loewis ___ Python tracker <http://bugs.python.org/issue15687> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15688] PEP 3121 Refactoring applied to nis module
Changes by Robin Schreiber : -- keywords: +pep3121 -patch nosy: +loewis ___ Python tracker <http://bugs.python.org/issue15688> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15689] PEP 3121, 384 Refactoring applied to operator module
Changes by Robin Schreiber : -- keywords: +pep3121 -patch nosy: +loewis ___ Python tracker <http://bugs.python.org/issue15689> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15690] PEP 3121, 384 Refactoring applied to parser module
Changes by Robin Schreiber : -- keywords: +pep3121 -patch ___ Python tracker <http://bugs.python.org/issue15690> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15691] PEP 3121, 384 Refactoring applied to posix module
Changes by Robin Schreiber : -- keywords: +pep3121 -patch ___ Python tracker <http://bugs.python.org/issue15691> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15697] PEP 3121 refactoring applied to pwd module
Changes by Robin Schreiber : -- keywords: +pep3121 -patch ___ Python tracker <http://bugs.python.org/issue15697> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15698] PEP 3121, 384 Refactoring applied to pyexpat module
Changes by Robin Schreiber : -- keywords: +pep3121 -patch ___ Python tracker <http://bugs.python.org/issue15698> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15699] PEP 3121, 384 Refactoring applied to readline module
Changes by Robin Schreiber : -- keywords: +pep3121 -patch ___ Python tracker <http://bugs.python.org/issue15699> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15700] PEP 3121, 384 Refactoring applied to resource module
Changes by Robin Schreiber : -- keywords: +pep3121 -patch ___ Python tracker <http://bugs.python.org/issue15700> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15703] PEP 3121, 384 Refactoring applied to select module
Changes by Robin Schreiber : -- keywords: +pep3121 -patch ___ Python tracker <http://bugs.python.org/issue15703> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15704] PEP 3121, 384 Refactoring applied to sha1 module
Changes by Robin Schreiber : -- keywords: +pep3121 -patch ___ Python tracker <http://bugs.python.org/issue15704> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15705] PEP 3121, 384 Refactoring applied to sha256 module
Changes by Robin Schreiber : -- keywords: +pep3121 -patch ___ Python tracker <http://bugs.python.org/issue15705> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15706] PEP 3121, 384 Refactoring applied to sha512 module
Changes by Robin Schreiber : -- keywords: +pep3121 -patch ___ Python tracker <http://bugs.python.org/issue15706> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15707] PEP 3121, 384 Refactoring applied to signal module
Changes by Robin Schreiber : -- keywords: +pep3121 -patch ___ Python tracker <http://bugs.python.org/issue15707> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15708] PEP 3121, 384 Refactoring applied to socket module
Changes by Robin Schreiber : -- keywords: +pep3121 -patch ___ Python tracker <http://bugs.python.org/issue15708> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15709] PEP 3121, 384 Refactoring applied to termios module
Changes by Robin Schreiber : -- keywords: +pep3121 -patch ___ Python tracker <http://bugs.python.org/issue15709> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15712] PEP 3121, 384 Refactoring applied to unicodedata module
Changes by Robin Schreiber : -- keywords: +pep3121 -patch ___ Python tracker <http://bugs.python.org/issue15712> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15713] PEP 3121, 384 Refactoring applied to zipimport module
Changes by Robin Schreiber : -- keywords: +pep3121 -patch ___ Python tracker <http://bugs.python.org/issue15713> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15714] PEP 3121, 384 Refactoring applied to grp module
Changes by Robin Schreiber : -- keywords: +pep3121 -patch ___ Python tracker <http://bugs.python.org/issue15714> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15651] PEP 3121, 384 refactoring applied to elementtree module
Changes by Robin Schreiber : -- keywords: +pep3121 -patch ___ Python tracker <http://bugs.python.org/issue15651> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15654] PEP 384 Refactoring applied to bz2 module
Changes by Robin Schreiber : -- keywords: +pep3121 -patch ___ Python tracker <http://bugs.python.org/issue15654> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15652] PEP 3121, 384 refactoring applied to gdbm module
Changes by Robin Schreiber : -- keywords: +pep3121 -patch ___ Python tracker <http://bugs.python.org/issue15652> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15655] PEP 384 Refactoring applied to json module
Changes by Robin Schreiber : -- keywords: +pep3121 -patch ___ Python tracker <http://bugs.python.org/issue15655> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15665] PEP 3121, 384 refactoring applied to lsprof module
Changes by Robin Schreiber : -- keywords: +pep3121 -patch ___ Python tracker <http://bugs.python.org/issue15665> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15662] PEP 3121 refactoring applied to locale module
Changes by Robin Schreiber : -- keywords: +pep3121 -patch ___ Python tracker <http://bugs.python.org/issue15662> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15666] PEP 3121, 384 refactoring applied to lzma module
Changes by Robin Schreiber : -- keywords: +pep3121 -patch ___ Python tracker <http://bugs.python.org/issue15666> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15667] PEP 3121, 384 refactoring applied to pickle module
Changes by Robin Schreiber : -- keywords: +pep3121 -patch ___ Python tracker <http://bugs.python.org/issue15667> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15669] PEP 3121, 384 Refactoring applied to sre module
Changes by Robin Schreiber : -- keywords: +pep3121 -patch ___ Python tracker <http://bugs.python.org/issue15669> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
