[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
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 &
[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
[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
[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
[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
[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
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: 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
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
[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
[issue6834] use different mechanism for pythonw on osx: universal builds always run 64-bit on OS X 10.6
Changes by Robin : -- nosy: +robince ___ Python tracker <http://bugs.python.org/issue6834> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6869] Embedded python crashed on 4th run, if "ctypes" is used
Changes by Robin : -- nosy: +robince ___ Python tracker <http://bugs.python.org/issue6869> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7541] python-config --ldflags doesn't pick up libpython2.5.a
New submission from Robin : Using my python.org install: robin-mbp:~ robince$ which python-config /Library/Frameworks/Python.framework/Versions/2.5/bin/python-config robin-mbp:~ robince$ python-config --ldflags -L/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/config -ldl -lpython2.5 But if I build a C file with python embedded, the above linker flags result it in it embedding the system python. Obviously the -lpython2.5 is picking up the system one in preference to the one on the -L path. >From Ronald Oussoren on pythonmac-sig: The easiest workaround is to open a terminal window and execute the following commands: cd /Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/config ln -s libpython2.5.a libpython2.5.dylib This will ensure that the OSX linker knows that libpython is a shared library and links to this library. By default the OSX linker searches for a .dylib on the entire linker path and only then looks for .a files. -- assignee: ronaldoussoren components: Macintosh messages: 96569 nosy: robince, ronaldoussoren severity: normal status: open title: python-config --ldflags doesn't pick up libpython2.5.a versions: Python 2.5, Python 2.6, Python 2.7 ___ Python tracker <http://bugs.python.org/issue7541> ___ ___ Python-bugs-list mailing list Unsubscribe: http://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
[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
[issue12382] [msilib] Ambiguous exception message when trying to open a non existing MSI database
New submission from Robin Jarry :
When trying to open a non existing MSI database, an obscure "unknown error 6e"
is raised.
Could it be possible to get a more explicit message such as "File not found" or
whatever ?
Thanks :)
Here is a example:
D:\>ll
total 0
drwxr-xr-x4 tcinteg Administ0 Nov 30 2010 RECYCLER
drwxr-xr-x0 tcinteg Administ0 Jul 6 2009 System Volume
Information
drwxr-xr-x4 tcinteg Administ0 Apr 29 16:03 TC
drwxr-xr-x3 tcinteg Administ0 Apr 29 15:43 stgloc
D:\>python
Python 2.7.1 (r271:86832, Nov 27 2010, 18:30:46) [MSC v.1500 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import msilib
>>> db = msilib.OpenDatabase("I_Do_Not_Exist.msi", msilib.MSIDBOPEN_READONLY)
Traceback (most recent call last):
File "", line 1, in
_msi.MSIError: unknown error 6e
>>>
--
components: Library (Lib)
messages: 138781
nosy: Robin.Jarry, loewis
priority: normal
severity: normal
status: open
title: [msilib] Ambiguous exception message when trying to open a non existing
MSI database
type: behavior
versions: Python 2.7
___
Python tracker
<http://bugs.python.org/issue12382>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12382] [msilib] Obscure exception message when trying to open a non-existent MSI database
Robin Jarry added the comment: changed the headline of the defect for something more meaningful :) -- title: [msilib] Ambiguous exception message when trying to open a non existing MSI database -> [msilib] Obscure exception message when trying to open a non-existent MSI database ___ Python tracker <http://bugs.python.org/issue12382> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12382] [msilib] Obscure exception message when trying to open a non-existent MSI database
Robin Jarry added the comment: This sounds OK as long as the error message is explicit :) -- ___ Python tracker <http://bugs.python.org/issue12382> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4214] no extension debug info with msvc9compiler.py
Robin Dunn added the comment:
No, MSVC does not behave that way any longer. Now it simply creates a file
named "None", so I expect that the newer versions simply do not support writing
the "old-style" debug info written to the DLL or EXE. If a setup script creates
more than one extension module then they all overwrite that None file.
In order to get debug info in a useable form, distutils simply can not use
/pdb:None. By removing that option entirely then debug info is generated like
normal into a *.pdb file and using the debugger to trace through the extension
module's code will happily work correctly.
I've had to have this hack in wxPython's setup.py since Python 2.6 to work
around this problem:
# Yet another distutils hack, this time for the msvc9compiler. There
# is a bug in at least version distributed with Python 2.6 where it
# adds '/pdb:None' to the linker command-line, but that just results
# in a 'None' file being created instead of putting the debug info
# into the .pyd files as expected. So we'll strip out that option via
# a monkey-patch of the msvc9compiler.MSVCCompiler.initialize method.
if os.name == 'nt' and sys.version_info >= (2,6):
import distutils.msvc9compiler
_orig_initialize = distutils.msvc9compiler.MSVCCompiler.initialize
def _initialize(self, *args, **kw):
rv = _orig_initialize(self, *args, **kw)
try:
self.ldflags_shared_debug.remove('/pdb:None')
except ValueError:
pass
return rv
distutils.msvc9compiler.MSVCCompiler.initialize = _initialize
--
versions: +Python 2.6
___
Python tracker
<http://bugs.python.org/issue4214>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3432] Mac, 2.6 framework install error
New submission from Robin Dunn <[EMAIL PROTECTED]>: OSX Leopard (10.5.4) Python-2.6b2 tarball ./configure --enable-universalsdk --enable-framework make sudo make install Ends with this error: cd Mac && make installmacsubtree DESTDIR="" Creating directory /Library/Frameworks/Python.framework/Versions/2.6/Mac/Tools DYLD_FRAMEWORK_PATH=/projects/Python-2.6b2: arch -ppc -i386 ../python.exe ./scripts/cachersrc.py -v /Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/plat-mac /Library/Frameworks/Python.framework/Versions/2.6/Mac/Tools Traceback (most recent call last): File "./scripts/cachersrc.py", line 7, in import macresource File "/projects/Python-2.6b2/Lib/plat-mac/macresource.py", line 6, in from Carbon import Res File "/projects/Python-2.6b2/Lib/plat-mac/Carbon/Res.py", line 4, in from _Res import * ImportError: No module named _Res make[1]: *** [installmacsubtree] Error 1 make: *** [frameworkinstallmaclib] Error 2 Since by this time in the install process the _Res module has already been installed I was able to work around this issue by hacking the generated Mac/Makefile and setting RUNSHARED to nothing. The same problem happens in Mac/IDLE/Makefile as well. -- components: Macintosh messages: 70189 nosy: robind severity: normal status: open title: Mac, 2.6 framework install error type: compile error versions: Python 2.6 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3432> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3433] Mac, 3.0 framework install error with fink cp
New submission from Robin Dunn <[EMAIL PROTECTED]>: OSX Leopard (10.5.4) Python-3.0b2 tarball ./configure --enable-universalsdk --enable-framework make sudo make install Ends with this error: cd PythonLauncher && make install DESTDIR= test -d "/Applications/Python 3.0" || mkdir -p "/Applications/Python 3.0" test -d "/Applications/Python 3.0/Python Launcher.app" && rm -r "/Applications/Python 3.0/Python Launcher.app" cp -r "Python Launcher.app" "/Applications/Python 3.0" touch "/Applications/Python 3.0/Python Launcher.app" test -d "/Applications/Python 3.0" || mkdir -p "/Applications/Python 3.0" test -d "/Applications/Python 3.0/IDLE.app" && rm -r "/Applications/Python 3.0/IDLE.app" make[1]: [install_IDLE] Error 1 (ignored) cp -PR IDLE/IDLE.app "/Applications/Python 3.0" cp: Warning: the meaning of `-P' will change in the future to conform to POSIX. Use `--parents' for the old meaning, and `--no-dereference' for the new one. ln -sf /Library/Frameworks/Python.framework/Versions/3.0/Resources/Python.app/Contents/MacOS/Python "/Applications/Python 3.0/IDLE.app/Contents/MacOS/Python" ln: creating symbolic link `/Applications/Python 3.0/IDLE.app/Contents/MacOS/Python' to `/Library/Frameworks/Python.framework/Versions/3.0/Resources/Python.app/Contents/MacOS/Python': No such file or directory make[1]: *** [install_IDLE] Error 1 make: *** [frameworkinstallapps] Error 2 It looks like this is due to fink's cp being found first on the PATH. Temporarily disabling /sw/bin/cp so /bin/cp would be found first then the install finished. -- components: Macintosh messages: 70190 nosy: robind severity: normal status: open title: Mac, 3.0 framework install error with fink cp type: compile error versions: Python 3.0 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3433> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3434] Mac, 3.0 framework install, Python.app not created
New submission from Robin Dunn <[EMAIL PROTECTED]>: OS X Leopard (10.5.4) Python-3.0b2 tarball ./configure --enable-universalsdk --enable-framework make sudo make install /Library/Frameworks/Python.framework/Versions/3.0/Resources/Python.app is not created by the install step, but it is needed for running python3.0: $ python3.0 python3.0: execv: /Library/Frameworks/Python.framework/Versions/3.0/Resources/Python.app/Contents/MacOS/Python: No such file or directory -- components: Macintosh messages: 70191 nosy: robind severity: normal status: open title: Mac, 3.0 framework install, Python.app not created type: compile error versions: Python 3.0 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3434> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3434] Mac, 3.0 framework install, Python.app not created
Robin Dunn <[EMAIL PROTECTED]> added the comment: This appears to already be fixed in the current py3k branch, so this can be closed. Sorry for the noise. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3434> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3433] Mac, 3.0 framework install error with fink cp
Robin Dunn <[EMAIL PROTECTED]> added the comment: Maybe, but I think that a more proper approach would be one of the following: * Decide that features specific to Apple's cp are required and change the Makefile to use /bin/cp instead of just cp. * Use configure to determine if a GNU cp is present and if so adjust the command-line parameters used. * Just use the $(INSTALL) value already set by configure as already used in the main Makefile. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3433> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3871] cross and native build of python for mingw32 with distutils
Changes by Robin Schoonover : -- nosy: +rschoon ___ Python tracker <http://bugs.python.org/issue3871> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7812] Call to gestalt('sysu') on OSX can lead to freeze in wxPython apps
Changes by Robin Dunn : -- nosy: +robind ___ Python tracker <http://bugs.python.org/issue7812> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8170] Wrong Paths for distutils build --plat-name=win-amd64
New submission from Robin Becker : When building extensions on win32 distutils with --plat-name=win-amd64 adds PCBuild/AMD64 in the wrong place. This patch ensures the AMD64 location comes first -- assignee: tarek components: Distutils files: patch.txt messages: 101259 nosy: rgbecker, tarek severity: normal status: open title: Wrong Paths for distutils build --plat-name=win-amd64 versions: Python 2.6 Added file: http://bugs.python.org/file16574/patch.txt ___ Python tracker <http://bugs.python.org/issue8170> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8171] bdist_wininst builds wrongly for --plat-name=win-amd64
New submission from Robin Becker : I notice this from win32 setup.py bdist_wininst --plat-name=win-amd64 > running bdist_wininst > running build > running build_py > creating build > creating build\lib.win32-2.6 > creating build\lib.win32-2.6\reportlab > copying src\reportlab\rl_config.py -> build\lib.win32-2.6\reportlab .. > C:\Program Files\Microsoft Visual Studio 9.0\VC\BIN\cl.exe /c /nolog followed by errors related to a missing library (the amd64 version won't work with a win32 build). I do have the x86_amd64 stuff installed and after applying a patch to fix another small cross compile error I do see a proper build ie setup.py build --plat-name=win-amd64 and then use setup.py bdist_wininst --plat-name=win-amd64 --skip-build does work. I believe that bdist_wininst is wrongly relying on build to get the right plat_name, but that isn't happening. The attached patch seems to make things work for me by forcing plat_name down from the top -- assignee: tarek components: Distutils files: patch.txt messages: 101260 nosy: rgbecker, tarek severity: normal status: open title: bdist_wininst builds wrongly for --plat-name=win-amd64 versions: Python 2.6 Added file: http://bugs.python.org/file16575/patch.txt ___ Python tracker <http://bugs.python.org/issue8171> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8323] multiprocessing.Queue ignores pickle restrictions in .put()
New submission from Robin Schoonover :
The multiprocessing module's version of the Queue class, which causes objects
to be pickled for process to process transfer, ignores pickle restrictions when
objects are added to the queue. Example code (buffer isn't pickleable):
from multiprocessing import Queue
q = Queue()
q.put(buffer("this is a buffer"))
print(q.get())
It results in an exception, which is expected, but the exception is confusing,
after the problem has already occurred, and if I were actually using multiple
processes, not in the process that tried to send an unsendable object:
Traceback (most recent call last):
File "mppkbuffer.py", line 5, in
print(q.get())
File "/usr/lib/python2.6/multiprocessing/queues.py", line 91, in get
res = self._recv()
TypeError: buffer() takes at least 1 argument (0 given)
Expected result would be a thrown exception when we attempt to put the object
into the queue using .put(), NOT when we attempt pull it out of the queue using
.get(), when it gets unpickled. Basically, while pickle fails when it tries to
dump, Queue succeeds the dump (somehow) and fails to load.
I have tested with python 2.6.4 and 2.7a4. 3.1 doesn't appear to have this bug
(but it does have a different one which I will report later).
--
components: Library (Lib)
messages: 102423
nosy: rschoon
severity: normal
status: open
title: multiprocessing.Queue ignores pickle restrictions in .put()
type: behavior
versions: Python 2.6, Python 2.7
___
Python tracker
<http://bugs.python.org/issue8323>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8323] multiprocessing.Queue ignores pickle restrictions in .put()
Robin Schoonover added the comment: Since these sort of buffer objects don't exist in 3.x (so far as I know), I came up with a different way to test in 3.x (basically, trying to pickle bound or unbound methods). It turns out that using this method to test it in 2.6 seems to fail where it should (in .put()), so if there's some sort of object that isn't pickleable in the same way as buffer that exists in 3.x, it should be tested to see if this specific problem is actually confined to 2.6 or not. -- ___ Python tracker <http://bugs.python.org/issue8323> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8607] OSX: duplicate -arch flags in CFLAGS breaks sysconfig
New submission from Robin Dunn :
In Python 2.7b1, building on OSX 10.6 with this configure command:
export CC=gcc-4.0
export CXX=g++-4.0
export MACOSX_DEPLOYMENT_TARGET=10.4
../configure \
--with-universal-archs=32-bit \
--enable-universalsdk=/Developer/SDKs/MacOSX10.4u.sdk \
--enable-framework
Results in these lines in Makefile:
BASECFLAGS= -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk
-fno-common -dynamic
CFLAGS= $(BASECFLAGS) -arch ppc -arch i386 -isysroot
/Developer/SDKs/MacOSX10.4u.sdk $(OPT) $(EXTRA_CFLAGS)
Then later on in the build the sysconfig module uses the -arch flags in CFLAGS
but is not able to find a match because of the extra set of values, and the
build fails with this exception:
Traceback (most recent call last):
File "./../Lib/site.py", line 542, in
main()
File "./../Lib/site.py", line 521, in main
addbuilddir()
File "./../Lib/site.py", line 118, in addbuilddir
s = "build/lib.%s-%.3s" % (get_platform(), sys.version)
File "/projects/Python-2.7b1/Lib/sysconfig.py", line 646, in get_platform
"Don't know machine value for archs=%r"%(archs,))
ValueError: Don't know machine value for archs=('i386', 'i386', 'ppc', 'ppc')
make: *** [sharedmods] Error 1
--
components: Build
messages: 104905
nosy: robind
priority: normal
severity: normal
status: open
title: OSX: duplicate -arch flags in CFLAGS breaks sysconfig
type: compile error
versions: Python 2.7
___
Python tracker
<http://bugs.python.org/issue8607>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1730] Documentation corrections for os module
New submission from Robin Stocker: I saw a minor inconsistency in the documentation of the os module and then somehow ended up proof-reading the whole file :). The result of this is attached as a patch against trunk. Summary of the changes: - Use the imperative tense in method descriptions - Some more links using semantic markup - Added example for file.seek - Consistently use "" instead of '' in text - or-ed, OR'd replaced with ORed - bit-wise replaced with bitwise Diffstat for the patch:: Doc/c-api/newtypes.rst|2 Doc/library/fcntl.rst |2 Doc/library/functions.rst |2 Doc/library/msvcrt.rst|2 Doc/library/os.rst| 155 +- Doc/library/stdtypes.rst |9 +- Doc/library/winsound.rst |2 Doc/reference/expressions.rst | 18 ++-- Lib/test/test_doctest.py |2 Modules/fcntlmodule.c |2 10 files changed, 101 insertions(+), 95 deletions(-) I hope the changes are ok. -- components: Documentation files: os-module-corrections.patch messages: 59160 nosy: robin.stocker severity: normal status: open title: Documentation corrections for os module Added file: http://bugs.python.org/file9051/os-module-corrections.patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1730> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1745] Backport of PEP 3102 "keyword-only arguments" to 2.6
New submission from Robin Stocker:
The attached patch ports the implementation of keyword-only arguments
from revision 52491 back to trunk.
This is the first time I've worked on the C internals, so here are some
notes:
- test_collections is the only test which fails, because it tries to
call a function with more than 255 arguments, which results in a
SyntaxError because of the following added code in Python/ast.c. What
should be done about it?
if (nposargs + nkwonlyargs > 255) {
ast_error(n, "more than 255 arguments");
return NULL;
}
- The patch only adds what's in revision 52491. There is at least one
more change involving keyword-only arguments, for example issue1573. Are
there others? Should they be included in this patch or in a separate one?
- There are some changes which were generated, like Python/Python-ast.c
(which needs to be checked in separately).
- Is there documentation which needs to be updated?
--
components: Interpreter Core
files: backport-keyword-only-arguments.patch
messages: 59391
nosy: robin.stocker
severity: normal
status: open
title: Backport of PEP 3102 "keyword-only arguments" to 2.6
type: behavior
versions: Python 2.6
Added file:
http://bugs.python.org/file9078/backport-keyword-only-arguments.patch
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1745>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1745] Backport of PEP 3102 "keyword-only arguments" to 2.6
Robin Stocker added the comment: Another note: Because the marshalling of code objects is changed, is there a version number of the format which has to be incremented? __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1745> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1745] Backport of PEP 3102 "keyword-only arguments" to 2.6
Robin Stocker added the comment:
Thanks for the feedback!
It's on line 111 in test_collections.py::
n = 1
import string, random
names = [''.join([random.choice(string.letters) for j in
range(10)]) for i in range(n)]
Big = namedtuple('Big', names)
b = Big(*range(n))
I think the condition is triggered because Big's __new__ (which seems to
be dynamically generated by namedtuple using exec) has an argument list
with 1 arguments.
Ok, I'm now looking through SVN logs and have already added some more
changes to my patchset.
Thanks, I had changed MAGIC but didn't know that marshal.c uses it.
So I won't handle documentation in this issue then.
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1745>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1745] Backport of PEP 3102 "keyword-only arguments" to 2.6
Robin Stocker added the comment: Guido: The check was only done for call nodes, not for function definitions. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1745> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1745] Backport of PEP 3102 "keyword-only arguments" to 2.6
Robin Stocker added the comment: Ok, I checked all the logs and updated the patch. test_collections uses n = 254 now and all tests pass. I left revision 54043 out on purpose, because it fixes Lib/inspect.py and Lib/pydoc.py for both PEP 3102 and 3107, so it should be included in the patch for PEP 3107. Added file: http://bugs.python.org/file9108/backport-keyword-only-arguments-full.patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1745> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1940] curses.filter can not be used as described in its documentation
New submission from Robin Bryce:
curses.filter forces the top most window to 1 line tall and preserves
existing tty content. It must be called *before* curses.initscr in order
to acheive this.
The python documentation states that curses.filter must be called before
initscr but the implementation prevents this. It uses the
NoArgNoReturnVoidFunction macro defined in Include/py_curses.h. This
macro in turn invokes the PyCursesInitialised macro which forces an
error if initscr has not been called.
curses.filter needs an explicit definition to avoid this:
Replacing "NoArgNoReturnVoidFunction(filter)" in Modules/_cursesmodule.c
with
static PyObject *PyCurses_filter (PyObject *self)
{
/* MUST NOT BE PyCursesInitialised */
filter(); \
Py_INCREF(Py_None);
return Py_None;
}
Would allow curses.filter to be called as documented. But really should
get a check for "!PyCursesInitialised".
--
components: Documentation, Library (Lib)
messages: 61708
nosy: robinbryce
severity: normal
status: open
title: curses.filter can not be used as described in its documentation
type: behavior
versions: Python 2.5
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1940>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1745] Backport of PEP 3102 "keyword-only arguments" to 2.6
Robin Stocker <[EMAIL PROTECTED]> added the comment: I've updated the patch to apply cleanly again. Added file: http://bugs.python.org/file9828/backport-keyword-only-arguments-full-2.patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1745> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4214] no extension debug info with msvc9compiler.py
New submission from Robin Dunn <[EMAIL PROTECTED]>: It looks like part of r59290 resulted in /pdb:None always being part of the ldflags_shared_debug list. This means that there will be no debug info stored for extensions built in debug mode, which kinda negates the purpose of doing a debug build. Looking back at the revision history and comparing similar code in msvccompiler.py it looks like the /pdb:None was optionally added in the first place because of compatibility issues with earlier compilers. For MSVC 7 and 9 I think it should be fine to simply remove /pdb:None from that list. My ad hoc testing so far has not revealed any problems with making this change. -- components: Distutils messages: 75264 nosy: robind severity: normal status: open title: no extension debug info with msvc9compiler.py type: compile error versions: Python 2.6 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4214> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2734] 2to3 converts long(itude) argument to int
Changes by Robin Stocker <[EMAIL PROTECTED]>: -- nosy: +robin.stocker ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2734> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5019] Specifying common controls DLL in manifest
New submission from Robin Dunn : This may have already been discussed but my searches didn't turn up anything concrete other than issue 4120 which is a similar but different problem. The problem I'm facing is that wxPython requires that version 6 of the common controls DLL be loaded in order for the GUI applications to use the themed version of the widgets on XP+ platforms, but it appears that this can only be done reliably if the manifest for the .exe is the one that specifies that version of the common controls assembly. Prior to 2.6 I was able to install python[w].exe.manifest files next to the python executables from my installer and it would work fine, but now that Python 2.6 is built with MSVC9 and it has its own manifest that does not always work. Initial testing seems to indicate that using an external manifest still works ok on 32-bit platforms, but not on the 64-bit versions of Windows. I've tried ensuring that the wxPython .pyd's and the wxWidgets DLLs have an internal manifest that specifies the common controls assembly but that has not helped. The only thing I've been able to find that works for both 32 and 64 bit is to replace the internal manifest in python.exe with a new one that specifies both the CRT and the Common Controls assemblies, but that is obviously a Bad Thing for the install of an extension module to do, so I'm opening this issue to look for alternatives. So, does anybody have any experience or ideas on how to enable the wxPython extensions to load the new common controls assembly without needing to change the stock Python executables' manifest? If not, are there any objections to adding the common controls assembly to the stock manifest used for python.exe and pythonw.exe? -- components: Build, Windows messages: 80308 nosy: robind severity: normal status: open title: Specifying common controls DLL in manifest type: behavior versions: Python 2.6 ___ Python tracker <http://bugs.python.org/issue5019> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5125] Strange locale problem with Python 3
Changes by Robin Stocker : -- nosy: +robin.stocker ___ Python tracker <http://bugs.python.org/issue5125> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5019] Specifying common controls DLL in manifest
Robin Dunn added the comment: If I understand correctly then setting an activation context won't help because by the time that an extension module is loaded the choice of which version of the common controls DLL will be loaded has already been made, and it may in fact already be loaded. The system must be told at the time that the .exe is loaded which common controls DLL it wants, otherwise it will use the old non-themed version. Everything I've tried seems to confirm this, if that is not true I'd love to see some examples. ___ Python tracker <http://bugs.python.org/issue5019> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5019] Specifying common controls DLL in manifest
Robin Dunn added the comment: Ok, the following files will be attached: python.exe.manifest: This is a copy of the manifest resource that I put into the 2.6.1 python.exe file by hand for testing. The original manifest was the same but without the 2nd ... group. sample.py: the simple little sample I used to make the screenshots. Snap001,png: This is sample.py running with the original python.exe running on Vista. Notice the plain, flat, outdated and ugly win2k look and style of the notebook tabs and buttons. Snap002.png: The same sample running with a modified python.exe. Now it has textures, gradients, mouse-over effects and etc. and will match the look of other modern applications running on the machine that are using the standard themes. Added file: http://bugs.python.org/file12995/python.exe.manifest ___ Python tracker <http://bugs.python.org/issue5019> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5019] Specifying common controls DLL in manifest
Changes by Robin Dunn : Added file: http://bugs.python.org/file12996/sample.py ___ Python tracker <http://bugs.python.org/issue5019> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5019] Specifying common controls DLL in manifest
Changes by Robin Dunn : Added file: http://bugs.python.org/file12997/Snap001.png ___ Python tracker <http://bugs.python.org/issue5019> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5019] Specifying common controls DLL in manifest
Changes by Robin Dunn : Added file: http://bugs.python.org/file12998/Snap002.png ___ Python tracker <http://bugs.python.org/issue5019> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5019] Specifying common controls DLL in manifest
Robin Dunn added the comment: Sorry, no luck. I've tried before to ensure that all the DLLs and extension modules have the manifest file (in resource 2) and it makes no difference. I rebuilt wxWidgets and wxPython today with ISOLATION_AWARE_ENABLED defined to check if that would help, and reset the manifest resource in all the binaries, but it makes no difference. ___ Python tracker <http://bugs.python.org/issue5019> ___ ___ Python-bugs-list mailing list Unsubscribe: http://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
[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
[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
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 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
[issue8170] Wrong Paths for distutils build --plat-name=win-amd64
Robin Becker added the comment: Some context. ReportLab windows exe installers for pythons 2.x x=4-7 are built on a single 32bit machine with 32bit pythons using a code that looks like this set FT_LIB=c:\devel\libs_x86\freetype.lib \python2x\python setup.py bdist_wininst --bitmap=%BMP% --title="ReportLab" we build the 64 bit versions for 2.6 & 2.7 only. In those cases an extra step does set FT_LIB=c:\devel\libs_amd64\freetype.lib \python2.x\python setup.py bdist_wininst --bitmap=%BMP% --plat-name=win-amd64 --title="ReportLab" To make this work I have copied from 64bit win32 installs of python2.6/7 various lib/dll/pyds. These live in C:\Python2x\PCBuild\AMD64 eg C:\ux\ExeBuilder>ls \Python26\PCBuild\AMD64 _bsddb.lib_socket.lib pyexpat.lib _bsddb.pyd_socket.pyd pyexpat.pyd _ctypes.lib _sqlite3.lib python26.dll _ctypes.pyd _sqlite3.pyd python26.lib _ctypes_test.lib _ssl.lib select.lib _ctypes_test.pyd _ssl.pyd select.pyd _elementtree.lib _testcapi.lib sqlite3.dll _elementtree.pyd _testcapi.pyd tcl85.dll _hashlib.lib _tkinter.lib tclpip85.dll _hashlib.pyd _tkinter.pyd tk85.dll _msi.lib bz2.lib unicodedata.lib _msi.pyd bz2.pyd unicodedata.pyd _multiprocessing.lib py.icowinsound.lib _multiprocessing.pyd pyc.ico winsound.pyd I followed most of section 5.4 in http://docs.python.org/distutils/builtdist.html to get this almost working, but got problems related to the library paths which my patch appears to fix (I seem to get working exes out of this approach). -- ___ Python tracker <http://bugs.python.org/issue8170> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8170] Wrong Paths for distutils build --plat-name=win-amd64
Robin Becker added the comment: That would be a solution if we had a separate 64 bit machine & extra versions of Visual Studio, but the actual bug is with the cross-compiling behaviour. If it's not supposed to work then this isn't a bug and section 5.4 should go; otherwise the correct way to do this should be better documented and made to work. -- ___ Python tracker <http://bugs.python.org/issue8170> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8170] Wrong Paths for distutils build --plat-name=win-amd64
Robin Becker added the comment: I cheated on the building both versions. I had 32 bit python installed and with the help of a colleague got hold of the installed files for the 64 bit version. I noticed that distutils was looking for the 64bit files in new_lib = os.path.join(sys.exec_prefix, 'PCbuild'). However, even though I had the files there the loader was missing them and trying to use the earlier lib specs. Experimenting with the command line led to the desire to prioritize the amd4 lib specification ie use insert instead of append for library_dirs. After this patch things do seem to work, but perhaps there's a better fix that removes/moves the 32 bit libs in some way. However, given that I am building the exes with a 32 bit python I suppose it's natural for distutils to assume we need the 32 bit libs. -- ___ Python tracker <http://bugs.python.org/issue8170> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9303] Migrate sqlite3 module to _v2 API to enhance performance
Robin Schreiber added the comment: Apparently this issue has not been dealt with for quite some time now. As a prospective GSoC student, I still need to submit a patch to pass final screening and I thought, that the needed patch here would be quite suitable for a beginner. I plan to submit a patch, which simply replaces the deprecated method calls with the new ones. Maybe we can also remove some parts of the module code, because of the new semantics of prepare_v2(), however I would first like to hear Gerhards opinion on that :-) -- nosy: +Robin.Schreiber ___ Python tracker <http://bugs.python.org/issue9303> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9303] Migrate sqlite3 module to _v2 API to enhance performance
Robin Schreiber added the comment: I have now submitted a patch, which swapped out all the necessary calls. Tests are all running as expected. I will now try to remove some backwards compatibility code. -- keywords: +patch Added file: http://bugs.python.org/file25211/sqlite.patch ___ Python tracker <http://bugs.python.org/issue9303> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9303] Migrate sqlite3 module to _v2 API to enhance performance
Changes by Robin Schreiber : Removed file: http://bugs.python.org/file25211/sqlite.patch ___ Python tracker <http://bugs.python.org/issue9303> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9303] Migrate sqlite3 module to _v2 API to enhance performance
Changes by Robin Schreiber : Added file: http://bugs.python.org/file25212/sqlite.patch ___ Python tracker <http://bugs.python.org/issue9303> ___ ___ Python-bugs-list mailing list Unsubscribe: http://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
[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
[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
[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
[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
[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
[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: 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 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: 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
[issue14732] PEP 3121 Refactoring applied to _csv module
New submission from Robin Schreiber : This patch presents my first try to apply the proposed Refactoring of PEP3121 to the csv module. I have identified three mutable global variables inside the module, two of which are references to PyObjects. I have wrapped all of them inside a dedicated struct, which is traversed by the gc after "freeing" the module. I also defined some macros, to hide functions calls that are now needed because of the newly introduced indirections. -- components: Extension Modules files: csv_pep3121.patch keywords: patch messages: 160032 nosy: Robin.Schreiber priority: normal severity: normal status: open title: PEP 3121 Refactoring applied to _csv module type: enhancement versions: Python 3.3 Added file: http://bugs.python.org/file25473/csv_pep3121.patch ___ Python tracker <http://bugs.python.org/issue14732> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14732] PEP 3121 Refactoring applied to _csv module
Robin Schreiber added the comment: The following script should fail before you have applied the bespoken patch: It basically checks wether one of the global PyObjects inside the csv module is being deleted after freeing the csv module. -- Added file: http://bugs.python.org/file25474/refactoring_test.py ___ Python tracker <http://bugs.python.org/issue14732> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14732] PEP 3121 Refactoring applied to _csv module
Changes by Robin Schreiber : Added file: http://bugs.python.org/file25559/csv_pep3121_fix1.patch ___ Python tracker <http://bugs.python.org/issue14732> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14935] PEP 341 Refactoring applied to _csv module
New submission from Robin Schreiber : Corresponding to my previous Issue #14732 I have now applied the Heap-Type Refactoring from PEP 341 to the _csv module. As I will apply this refactoring for almost every Standard Module, I will bundle my PEP3121 and PEP341 refactorings into a single patch for future releases. (In case there are no objections) -- components: Extension Modules files: csv_pep341.patch keywords: patch messages: 161791 nosy: Robin.Schreiber priority: normal severity: normal status: open title: PEP 341 Refactoring applied to _csv module type: enhancement versions: Python 3.3 Added file: http://bugs.python.org/file25745/csv_pep341.patch ___ Python tracker <http://bugs.python.org/issue14935> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14935] PEP 384 Refactoring applied to _csv module
Robin Schreiber added the comment: I was of course referring to PEP 384. Sorry for the inconvenience. -- title: PEP 341 Refactoring applied to _csv module -> PEP 384 Refactoring applied to _csv module ___ Python tracker <http://bugs.python.org/issue14935> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14936] PEP 3121, 384 refactoring applied to curses_panel module
New submission from Robin Schreiber : I have now applied the Heap-Type Refactoring from PEP 384 to the curses_panel module. Currently I still provide seperate patches for the PEP 3121 and PEP 384 refactoring. As mentioned in Issue #14935 I am planning to release single patches in the future for each module I refactor. -- components: Extension Modules files: curses_panel_pep384.patch keywords: patch messages: 161793 nosy: Robin.Schreiber priority: normal severity: normal status: open title: PEP 3121, 384 refactoring applied to curses_panel module type: enhancement versions: Python 3.3 Added file: http://bugs.python.org/file25746/curses_panel_pep384.patch ___ Python tracker <http://bugs.python.org/issue14936> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14936] PEP 3121, 384 refactoring applied to curses_panel module
Changes by Robin Schreiber : Added file: http://bugs.python.org/file25747/curses_panel_pep3121.patch ___ Python tracker <http://bugs.python.org/issue14936> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14936] PEP 3121, 384 refactoring applied to curses_panel module
Robin Schreiber added the comment: I have now also added the PEP3121 patch for the curses_panel module. -- ___ Python tracker <http://bugs.python.org/issue14936> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15042] Implemented PyState_AddModule, PyState_RemoveModule
New submission from Robin Schreiber : PEP 3121 suggests a new way of Module-initialization, where the module state is being wrapped inside a dedicate struct, which can be accessed at runtime via the PyState_FindModule method. For code outside the Init-method, there is no other way to receive the module-state, as it has no reference to the object created by PyModule_Create. PyState_FindModule requires, that the module-state has been attached to the interpreter-state beforehand. Inside an extension module code this is almost everywhere the case except inside the Init-method, because currently _PyState_AddModule is only called by the importer AFTER the extension module has been initialized successfully. As most of the macro definitions inside an extension module, which rely on data stored in the module state, have to receive the state via FindModule, they fail to work inside the modules Init-method. This patch suggests an extension of PyState comprising two publicly available methods (PyState_AddModule, PyState_RemoveModule) that can be called from inside the Init-method, so that the module-state is attached to the interpreter state before further initialization of the module continues. As a result, PyState_FindModule will also work in this region of the extension module and the bespoken expanded macros will also work flawlessly when executed inside the Init code. This patch is especially important for the future application of PEP 3121 together with PEP 384, as the newly created heap-types now reside inside the module-state. As type-objects are frequently used in macro-definitions which are also expanded within the Init-method of a module (or inside a function called from Init), the module state has to be received via FindModule. (The alternative would be nasty redefinitions of the specific macros, shortly before Init) -- components: Interpreter Core files: PyState_add-remove_module.patch keywords: patch messages: 162581 nosy: Robin.Schreiber priority: normal severity: normal status: open title: Implemented PyState_AddModule, PyState_RemoveModule type: enhancement versions: Python 3.3 Added file: http://bugs.python.org/file25871/PyState_add-remove_module.patch ___ Python tracker <http://bugs.python.org/issue15042> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15042] Implemented PyState_AddModule, PyState_RemoveModule
Robin Schreiber added the comment: Added missing documentation. Also added documentation of PyState_FindModule() which still happened to be missing. -- Added file: http://bugs.python.org/file26046/PyState_add-remove_module_v2.patch ___ Python tracker <http://bugs.python.org/issue15042> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15146] Implemented PyType_FromSpecWithBases
New submission from Robin Schreiber : Enhancement to the currently existing PyType_FromSpec() which creates and returns a heap type from a given spec. PyType_FromSpecWithBases() works similar to PyType_FromSpec(), however it sets the bases of the newly created heap type to the types contained inside the passed bases-tuple. This allows the programmer to reference other heap-types as base types of a new heap type. This is necessary as the slot-API, which is used for static declarations of the type-spec, currently relies on statically declared type objects as tp_base or tp_bases entries. -- components: Interpreter Core files: PyType_FromSpecWithBases.patch keywords: patch messages: 163502 nosy: Robin.Schreiber priority: normal severity: normal status: open title: Implemented PyType_FromSpecWithBases type: enhancement versions: Python 3.3 Added file: http://bugs.python.org/file26099/PyType_FromSpecWithBases.patch ___ Python tracker <http://bugs.python.org/issue15146> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15146] Implemented PyType_FromSpecWithBases
Changes by Robin Schreiber : -- nosy: +loewis ___ Python tracker <http://bugs.python.org/issue15146> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14935] PEP 384 Refactoring applied to _csv module
Robin Schreiber added the comment: Added missing INCREF and DECREF inside the dealloc, and new methods of the types. -- Added file: http://bugs.python.org/file26381/csv_pep384_v1.patch ___ Python tracker <http://bugs.python.org/issue14935> ___ ___ 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
New submission from Robin Schreiber : Changes proposed in PEP3121 and PEP384 applied to the curses module. As these Changes do not alter behaviour of the specific modules, I would encourage to see this enhancement as a "bugfix" and consequently include this into the coming Python 3.3 release. -- components: Extension Modules files: _cursesmodule_pep3121-384_v0.patch keywords: patch messages: 165804 nosy: Robin.Schreiber priority: normal severity: normal status: open title: PEP 3121, 384 refactoring applied to curses module type: resource usage versions: Python 3.3 Added file: http://bugs.python.org/file26430/_cursesmodule_pep3121-384_v0.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
[issue15390] PEP 3121, 384 refactoring applied to datetime module
New submission from Robin Schreiber : Changes proposed in PEP3121 and PEP384 have now been applied to the datetime module! -- components: Extension Modules files: _datetimemodule_pep3121-384_v0.patch keywords: patch messages: 165805 nosy: Robin.Schreiber priority: normal severity: normal status: open title: PEP 3121, 384 refactoring applied to datetime module type: resource usage versions: Python 3.3 Added file: http://bugs.python.org/file26431/_datetimemodule_pep3121-384_v0.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
[issue15389] PEP 3121, 384 refactoring applied to curses module
Changes by Robin Schreiber : -- nosy: +loewis ___ 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
[issue14935] PEP 384 Refactoring applied to _csv module
Robin Schreiber added the comment: Fixed the dealloc-methods of the types, for proper type dereferencing. -- Added file: http://bugs.python.org/file26797/csv_pep384_v2.patch ___ Python tracker <http://bugs.python.org/issue14935> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14935] PEP 384 Refactoring applied to _csv module
Changes by Robin Schreiber : -- versions: +Python 3.4 -Python 3.3 ___ Python tracker <http://bugs.python.org/issue14935> ___ ___ 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: Fixed _dealloc methods. Also: Init now returns the previously initialized module if available. -- Added file: http://bugs.python.org/file26803/_datetimemodule_pep3121-384_v1.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
[issue15650] PEP 3121, 384 refactoring applied to dbm module
New submission from Robin Schreiber: Changes proposed in PEP3121 and PEP384 have now been applied to the dbm module! -- components: Extension Modules files: _dbmmodule_pep3121-384_v0.patch keywords: patch messages: 168216 nosy: Robin.Schreiber priority: normal severity: normal status: open title: PEP 3121, 384 refactoring applied to dbm module versions: Python 3.4 Added file: http://bugs.python.org/file26804/_dbmmodule_pep3121-384_v0.patch ___ 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
[issue15651] PEP 3121, 384 refactoring applied to elementtree module
New submission from Robin Schreiber: Changes proposed in PEP3121 and PEP384 have now been applied to the elementtree module! -- components: Extension Modules files: _elementtree_pep3121-384_v0.patch keywords: patch messages: 168217 nosy: Robin.Schreiber priority: normal severity: normal status: open title: PEP 3121, 384 refactoring applied to elementtree module type: resource usage versions: Python 3.4 Added file: http://bugs.python.org/file26805/_elementtree_pep3121-384_v0.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
[issue15651] PEP 3121, 384 refactoring applied to elementtree module
Changes by Robin Schreiber : -- nosy: +effbot ___ 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
[issue15652] PEP 3121, 384 refactoring applied to gdbm module
New submission from Robin Schreiber: Changes proposed in PEP3121 and PEP384 have now been applied to the gdbm module! -- components: Extension Modules files: _gdbm_pep3121-384_v0.patch keywords: patch messages: 168219 nosy: Robin.Schreiber, anthony_baxter priority: normal severity: normal status: open title: PEP 3121, 384 refactoring applied to gdbm module versions: Python 3.4 Added file: http://bugs.python.org/file26806/_gdbm_pep3121-384_v0.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
[issue15653] PEP 3121, 384 refactoring applied to hashopenssl module
New submission from Robin Schreiber: Changes proposed in PEP3121 and PEP384 have now been applied to the hashopenssl module! -- components: Extension Modules files: _hashopenssl_pep3121-384_v0.patch keywords: patch messages: 168220 nosy: Robin.Schreiber, gstein priority: normal severity: normal status: open title: PEP 3121, 384 refactoring applied to hashopenssl module type: resource usage versions: Python 3.4 Added file: http://bugs.python.org/file26807/_hashopenssl_pep3121-384_v0.patch ___ Python tracker <http://bugs.python.org/issue15653> ___ ___ 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
New submission from Robin Schreiber: Changes proposed in PEP384 have now been applied to the bz2 module! -- components: Extension Modules files: _bz2_pep384_v0.patch keywords: patch messages: 168221 nosy: Robin.Schreiber priority: normal severity: normal status: open title: PEP 384 Refactoring applied to bz2 module type: resource usage versions: Python 3.4 Added file: http://bugs.python.org/file26808/_bz2_pep384_v0.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
[issue15655] PEP 384 Refactoring applied to json module
New submission from Robin Schreiber: Changes proposed in PEP3121 and PEP384 have now been applied to the json module! -- components: Extension Modules files: _json_pep384_v0.patch keywords: patch messages: 168222 nosy: Robin.Schreiber priority: normal severity: normal status: open title: PEP 384 Refactoring applied to json module type: resource usage versions: Python 3.4 Added file: http://bugs.python.org/file26809/_json_pep384_v0.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
[issue15653] PEP 3121, 384 refactoring applied to hashopenssl module
Robin Schreiber added the comment: Regarding the macro definition, I would be fine with changing it to _hashlib_state. The dance you have found inside the Init, makes shure that the very same module is returned if Init is called twice or multiple times, before the Module is unloaded. A month back, when I created this patch, I had statements such as test.import.import_fresh_module(...) call the Init-method multiple times, before a module was unloaded. This was apparently a bug, as I can no longer reproduce this behavior, but at that time I thought it was the expected behavior :-) The last code snipped verifies, that we only dereference the type if the dealloc function is not being called from inside the subtype_dealloc function. This is necessary because the subtype_dealloc function itself contains a decref of the respective type object. Without this check, we would then end up decrefing the type too many times. -- ___ Python tracker <http://bugs.python.org/issue15653> ___ ___ 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
Robin Schreiber added the comment: Hey Antoine, This comment describes exactly what I intended with the "dance" in issue15653. For example the json testsuite issued multiple calls to the init function before unloading and consequently clearing the module. However it seems as if the behavior this code dealt with, has been a bug inside the import lib. -- ___ 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
