[issue46379] itertools.product reference implementation creates temporaries
Markus Wallerberger added the comment: > To a person well versed in recursion and in generator chains it makes sense > but not so much for anyone else. There I pretty much fundamentally disagree. I find the version in the docs much more magical in the sense that it builds up "laterally", i.e., level-by-level, rather than element-by-element. Also, I think from a functional programming perspective, which, let's face it, is what these iteration/generator tools are really modelling, a recursive version is much more natural. It also generalizes nicely to other problems which people may be having -- so it has the added benefit of explaining the code and teaching people useful patterns. Take the itertools.permutation as an example: writing that as it was in the reference implementation the code is IMHO pretty opaque and hard to reason about. Write it in a recursive style and both its working and correctness is immediately obvious. > Plus it is hard to step through by hand to see what it is doing. This I agree with. Anyway, thanks for taking the time to explain the rejection. -- ___ Python tracker <https://bugs.python.org/issue46379> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46379] itertools.product reference implementation creates temporaries
Change by Markus Wallerberger : -- keywords: +patch pull_requests: +28804 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30605 ___ Python tracker <https://bugs.python.org/issue46379> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46379] itertools.product reference implementation creates temporaries
New submission from Markus Wallerberger : The reference implementation of itertools.product creates large temporaries, which we need to remind people of at the top of the code block. However, using generator magic, we don't need to do this and can even simplify the code in the process! Basically,we iterate over a generator of product(*seq[:-1]), and extend each of the values by every value in seq[-1]. -- assignee: docs@python components: Documentation messages: 410573 nosy: docs@python, mwallerb priority: normal severity: normal status: open title: itertools.product reference implementation creates temporaries type: enhancement versions: Python 3.10, Python 3.11, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue46379> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14965] super() and property inheritance behavior
Change by Markus Kitsinger (he/him/his) : -- nosy: +SwooshyCueb nosy_count: 23.0 -> 24.0 pull_requests: +28175 pull_request: https://github.com/python/cpython/pull/29950 ___ Python tracker <https://bugs.python.org/issue14965> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42037] Documentation confusion in CookieJar functions
Markus Israelsson added the comment: I am currently updating the documentation source code. On the cookiejar page it describes 'unverifiable' as a method. I can however not find that method on the request page because it seems to be just a normal attribute. I will make updates for that as well if that is ok with you? -- ___ Python tracker <https://bugs.python.org/issue42037> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42037] Documentation confusion in CookieJar functions
Markus Israelsson added the comment: I got ok from the higherups. Will plan this into next sprint so it will take a week or 2 before I get to it. -- ___ Python tracker <https://bugs.python.org/issue42037> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42037] Documentation confusion in CookieJar functions
Markus Israelsson added the comment: I guess due to something having to be signed I would have to create a personal github account :/ -- ___ Python tracker <https://bugs.python.org/issue42037> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42037] Documentation confusion in CookieJar functions
Markus Israelsson added the comment: Sure. But I will need to get an ok from my company to spend some time on this because I really am not very used to git yet (recently switched). Also, is it possible to make the request/changes through the company github account or must that in that case be tied directly to this bug report account? -- ___ Python tracker <https://bugs.python.org/issue42037> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42037] Documentation confusion in CookieJar functions
Markus Israelsson added the comment: The way I read the documentation for add_cookie_header is: These methods must exist in the Request object: - get_full_url() - get_host() - get_type() - unverifiable... and so on. The documentation for the request objects claims however that: These methods are removed since version 3.4: - add_data - has_data - get_data - get_type - get_host - This method , and some others, are listed as requirements for the add_cookie_header and extract_cookies functions. See list above or link I posted above to the correct places in the docs. So it is only the documentation that is inconsistent. Not the code. Unless, like I said, I misunderstand something in the documentation. -- ___ Python tracker <https://bugs.python.org/issue42037> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42037] Documentation confusion in CookieJar functions
New submission from Markus Israelsson : The documentation in https://docs.python.org/3.8/library/http.cookiejar.html#http.cookiejar.CookieJar claims the following for functions add_cookie_header and extract_cookies. *** The request object (usually a urllib.request.Request instance) must support the methods get_full_url(), get_host(), get_type(), unverifiable(), has_header(), get_header(), header_items(), add_unredirected_header() and origin_req_host attribute as documented by urllib.request. *** When reading the documentation for Request Objects https://docs.python.org/3.8/library/urllib.request.html?highlight=requests#request-objects there is this: *** Changed in version 3.4: The request methods add_data, has_data, get_data, get_type, get_host, get_selector, get_origin_req_host and is_unverifiable that were deprecated since 3.3 have been removed. *** So basically the documentation claims that if the request object does not support functions that are removed then the headers will not be added. The code itself seem to do the correct thing however and add the header. -- assignee: docs@python components: Documentation messages: 378624 nosy: docs@python, markus priority: normal severity: normal status: open title: Documentation confusion in CookieJar functions type: enhancement versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue42037> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40327] list(sys.modules.items()) can throw RuntimeError: dictionary changed size during iteration
New submission from Markus Mohrhard : We have hit an issue in the pickle module where the code throws an exception in a threaded environment: The interesting piece of the backtrace is: File "/xxx/1004060/lib/python3.7/site-packages/numpy/core/__init__.py", line 130, in _ufunc_reduce return _ufunc_reconstruct, (whichmodule(func, name), name) File "/xxx/lib/python3.7/pickle.py", line 309, in whichmodule for module_name, module in list(sys.modules.items()): RuntimeError: dictionary changed size during iteration I tried to find a code path that would explain how the dict could be changed while the list is created but have not been able to find a code path that releases the GIL. The executable is using many threads with imports happening in random threads and a custom class loader but we already make sure that the class loader is always holding the GIL. The issue happens quite rarely (maybe once every one thousand's execution) so I don't have a reproducer right now. -- components: Extension Modules messages: 366762 nosy: Markus Mohrhard priority: normal severity: normal status: open title: list(sys.modules.items()) can throw RuntimeError: dictionary changed size during iteration type: behavior versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue40327> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31539] asyncio.sleep may sleep less time then it should
Markus Roth added the comment: When the fine tuning options for install-directories are set, the default directories "lib", "bin" and "include" are still created with essential content. Even if options like --libdir are set. -- nosy: +CatorCanulis ___ Python tracker <https://bugs.python.org/issue31539> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39609] Set the thread_name_prefix for asyncio's default executor ThreadPoolExecutor
Markus Mohrhard added the comment: We have by now changed to a custom executor. Asyncio is used in some of our dependencies and therefore it took some work to figure out what is creating the thousands of threads that we were seeing. This patch was part of the debuggin and we thought it would be useful for anyone else to immediately see what is creating the threads. -- ___ Python tracker <https://bugs.python.org/issue39609> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39609] Set the thread_name_prefix for asyncio's default executor ThreadPoolExecutor
Change by Markus Mohrhard : -- keywords: +patch pull_requests: +17832 stage: -> patch review pull_request: https://github.com/python/cpython/pull/18458 ___ Python tracker <https://bugs.python.org/issue39609> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39609] Set the thread_name_prefix for asyncio's default executor ThreadPoolExecutor
New submission from Markus Mohrhard : The ThreadPoolExecutor in BaseEventLoop.run_in_executor should set a thread_name_prefix to simplify debugging. Might also be worth to limit the number of max threads. On our 256 core machines we sometimes get 1000+ threads due to the cpu_count() * 5 default limit. -- components: asyncio messages: 361799 nosy: Markus Mohrhard, asvetlov, yselivanov priority: normal severity: normal status: open title: Set the thread_name_prefix for asyncio's default executor ThreadPoolExecutor type: enhancement versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue39609> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37502] Fix default argument handling for buffers argument in pickle.loads
Markus Mohrhard added the comment: Sorr, I somehow managed to overwrite my title before submitting with the one from one if the results of my searches. -- ___ Python tracker <https://bugs.python.org/issue37502> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37502] Fix default argument handling for buffers argument in pickle.loads
Change by Markus Mohrhard : -- title: Pure Python pickle module should not depend on _pickle.PickleBuffer -> Fix default argument handling for buffers argument in pickle.loads ___ Python tracker <https://bugs.python.org/issue37502> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37502] Pure Python pickle module should not depend on _pickle.PickleBuffer
Change by Markus Mohrhard : -- keywords: +patch pull_requests: +14409 stage: -> patch review pull_request: https://github.com/python/cpython/pull/14593 ___ Python tracker <https://bugs.python.org/issue37502> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37502] Pure Python pickle module should not depend on _pickle.PickleBuffer
New submission from Markus Mohrhard : The following piece of code import pickle pickle.loads(pickle.dumps(1, protocol=pickle.HIGHEST_PROTOCOL), buffers=None) fails with "TypeError: 'NoneType' object is not iterable" The corresponding PEP (https://www.python.org/dev/peps/pep-0574/) specifies that buffer=None is the default but the C implementation does not check for Py_None. The PR contains a test for this case that fails without the fix. -- components: Library (Lib) messages: 347299 nosy: Markus Mohrhard priority: normal severity: normal status: open title: Pure Python pickle module should not depend on _pickle.PickleBuffer versions: Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue37502> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36382] socket.getfqdn() returns domain "mshome.net"
Markus added the comment: I found the IP of mshome.net in an Ethernet adapter "vEthernet" It seems that this adapter stems from Hyper-V. It therefore seems that socket.getfqdn() reported the wrong network adapter once. Because I cannot reproduce this, I leave this issue closed. -- resolution: not a bug -> works for me ___ Python tracker <https://bugs.python.org/issue36382> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36382] socket.getfqdn() returns domain "mshome.net"
Markus added the comment: Dear Steve, in fact not a Python bug at all. I used 2 commands: ipconfig /release ipconfig /renew and rebootet. This fixed the issue, for now. Also, I found this domain in c:\Windows\System32\drivers\etc\hosts.ics Unclear who created that entry. Documenting this here could help others with the same problem. Closing this issue. -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue36382> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36382] socket.getfqdn() returns domain "mshome.net"
New submission from Markus : In a corporate network, `wmic computersystem get domain` returns the correct domain. On some clients, the Python query "socket.getfqdn()" returns the wrong domain, namely "mshome.net" >>> import socket >>> socket.getfqdn() '*.mshome.net' I have only found only very old nominations of that domain. Problems persists after reboot. Tried versions Python 2.7.15 (v2.7.15:ca079a3ea3, Apr 30 2018, 16:30:26) [MSC v.1500 64 bit (AMD64)] on win32 Python 3.7.2 (tags/v3.7.2:9a3ffc0492, Dec 23 2018, 22:20:52) [MSC v.1916 32 bit (Intel)] on win32 Currently, I suspect this is a DHCP configuration problem. -- components: Windows messages: 338472 nosy: markuskramerIgitt, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: socket.getfqdn() returns domain "mshome.net" type: behavior versions: Python 2.7, Python 3.7 ___ Python tracker <https://bugs.python.org/issue36382> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35671] reserved identifier violation
Markus Elfring added the comment: * How do you think about to reduce the tampering with the reserved name space in mentioned source code (and also in related components)? * Would you like to avoid that this software depends on undefined behaviour? -- ___ Python tracker <https://bugs.python.org/issue35671> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35671] reserved identifier violation
New submission from Markus Elfring : I would like to point out that identifiers like “__DYNAMIC_ANNOTATIONS_H__” and “_Py_memory_order” do not fit to the expected naming convention of the C++ language standard. https://www.securecoding.cert.org/confluence/display/cplusplus/DCL51-CPP.+Do+not+declare+or+define+a+reserved+identifier Would you like to adjust your selection for unique names? * https://github.com/python/cpython/blob/e42b705188271da108de42b55d9344642170aa2b/Include/dynamic_annotations.h#L56 * https://github.com/python/cpython/blob/130893debfd97c70e3a89d9ba49892f53e6b9d79/Include/internal/pycore_atomic.h#L36 -- components: Interpreter Core messages: 333105 nosy: elfring priority: normal severity: normal status: open title: reserved identifier violation type: security versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue35671> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30545] Enum equality across modules: comparing objects instead of values
Markus Wegmann added the comment: Hi Ethan > Your Enum example in flawless is not an IntEnum, so the error (unable to add > an integer to None) seems entirely unrelated. The TypeError is just a consequence of the faulty Enum identity comparison some lines before. I mentioned the TypeError so you can verify whether your Python version takes the same program flow. I also did further research. The Enum's are definitely different regarding the module path -- the instance comparison will therefore return False. I checked __module__ + __qualname__: `flora_tools.radio_configuration.RadioModem.LORA` vs. `radio_configuration.RadioModem.LORA` The cause is the wrong import statement in `flora_tools/codegen/codegen.py`: `from radio_configuration import RadioConfiguration,\ RADIO_CONFIGURATIONS` It should have been `from flora_tools.radio_configuration import RadioConfiguration\ RADIO_CONFIGURATIONS` The real deal here is why I was allowed to directly import from `radio_configuration` in the first place. I'm not allowed to directly import a submodule in the toy project without the proper root module name appended. Maybe I don't see the big picture, or have some crude options/monkey_patching enabled. Nevertheless, the behaviour regarding Enum comparisons and different import paths seems to me quite misleading. Best regards Atokulus -- ___ Python tracker <https://bugs.python.org/issue30545> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30545] Enum equality across modules: comparing objects instead of values
Markus Wegmann added the comment: Hi there! I came as well in contact with this kind of bug. Sadly, I could not replicate it with a simplified toy example. You can experience the bug, if checkout https://github.com/Atokulus/flora_tools/tree/56bb17ea33c910915875214e916ab73f567b3b0c and run `python3.7 main.py generate_code -d ..` You find the crucial part where the identity check fails at 'radio_math.py:102' in function `get_message_toa`. The program then fails, due to the wrong program flow. ` C:\Users\marku\AppData\Local\Programs\Python\Python37\python.exe C:/Users/marku/PycharmProjects/flora_tools/flora_tools/__main__.py generate_code -d C:\Users\marku\Documents\flora Traceback (most recent call last): File "C:/Users/marku/PycharmProjects/flora_tools/flora_tools/__main__.py", line 110, in main() File "C:/Users/marku/PycharmProjects/flora_tools/flora_tools/__main__.py", line 104, in main generate_code(args.path) File "C:/Users/marku/PycharmProjects/flora_tools/flora_tools/__main__.py", line 58, in generate_code code_gen = CodeGen(flora_path) File "C:\Users\marku\PycharmProjects\flora_tools\flora_tools\codegen\codegen.py", line 37, in __init__ self.generate_all() File "C:\Users\marku\PycharmProjects\flora_tools\flora_tools\codegen\codegen.py", line 40, in generate_all self.generate_radio_constants() File "C:\Users\marku\PycharmProjects\flora_tools\flora_tools\codegen\codegen.py", line 72, in generate_radio_constants radio_toas.append([math.get_message_toa(payload) for payload in payloads]) File "C:\Users\marku\PycharmProjects\flora_tools\flora_tools\codegen\codegen.py", line 72, in radio_toas.append([math.get_message_toa(payload) for payload in payloads]) File "C:\Users\marku\PycharmProjects\flora_tools\flora_tools\radio_math.py", line 130, in get_message_toa ) / self.configuration.bitrate TypeError: unsupported operand type(s) for +: 'int' and 'NoneType' Process finished with exit code 1 ` In the appendix, you find a toy project with similar structure, which in contrast to `flora_tools` works flawlessly. I hope there is somebody out there with a little more experience in spotting the cause. If there is a bug in Python or CPython, it might have quite a security & safety impact. Meanwhile I will hotfix my program by comparing the unerlying enum values. Best regards Atokulus -- nosy: +Markus Wegmann Added file: https://bugs.python.org/file47747/enum_bug-flawless_example.zip ___ Python tracker <https://bugs.python.org/issue30545> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33246] Note in 18.2. json — JSON encoder and decoder is incorrect
New submission from Markus Järvisalo <markus.jarvis...@gmail.com>: The note in https://docs.python.org/2/library/json.html section "18.2. json — JSON encoder and decoder". The note says incorrectly that JSON is a subset of YAML 1.2 but if you follow the text written in YAML 1.2 specification it states that: "The primary objective of this revision is to bring YAML into compliance with JSON as an official subset." So it should be that YAML is a subset of JSON and not the other way around. -- assignee: docs@python components: Documentation messages: 315111 nosy: Markus Järvisalo, docs@python priority: normal severity: normal status: open title: Note in 18.2. json — JSON encoder and decoder is incorrect type: behavior versions: Python 2.7 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33246> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31103] Windows Installer Product Version 3.6.2150.0 Offset By 0.0.150.0
Markus Kramer added the comment: Steve, yes: from my point of view, the version in "Programs and Features" should be 3.6.2 or 3.6.2.0 or 3.6.2.150. Eryk, thank you for your explanation - I had a wrong memory about the third field in ProductVersion to be the micro version and learned something. If that would be helpful, I could change the title of this issue. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31103> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31103] Windows Installer Product Version 3.6.2150.0 Offset By 0.0.150.0
Markus Kramer added the comment: Screenshot of Product Version 3.6.2150.0 -- Added file: http://bugs.python.org/file47056/3.6.2.png ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31103> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31103] Windows Installer Product Version 3.6.2150.0 Offset By 0.0.150.0
New submission from Markus Kramer: Each Windows installation has a “product version”. The Windows installer python-3.6.2.exe has product version "3.6.2150.0" (accessible with context menu / Properties / Details). This causes at least 2 problems: - Automated software inventory relies on product version and therefore does not detect version 3.6.2 - Microsoft installation guidelines require the first three fields to be smaller than 256. Proposed alternatives for the value of product version: - "3.6.2.0" to indicate the final release build. - "3.6.2.150" to indicate the build number. The build number may be higher than 256, but this is unusual for a final release. Side note: This is a sub-problem of http://bugs.python.org/issue31077 -- components: Windows messages: 299651 nosy: Damon Atkins, Markus Kramer, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Windows Installer Product Version 3.6.2150.0 Offset By 0.0.150.0 type: behavior versions: Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31103> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29740] Visual C++ CRT security update from 14 June 2011
Markus added the comment: I beg pardon to be pedantic. The issue is not MFC, but CRT. The related safety bulletin (https://technet.microsoft.com/library/security/ms11-025) says Your application may be an attack vector if all of the following conditions are true: - Your application makes use of the Microsoft Foundation Class (MFC) Library - Your application allows the loading of dynamic link libraries from untrusted locations, such as WebDAV shares This is clearly **not** the case for Python. So far so good. I am concerned that the security update contains an updated vc90.crt 9.0.30729.6161. If Python find the 6161 update, it will use it. I found no information on the change between the 4940 version (from Python 2.7.13) and the 6161 update (from the security update). But as Python uses the 6161 update (if it is installed) I would like to raise the question if Python should ship it. I am not a security expert, so this issue is based completely on the above observations and a crumb of logic. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29740> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29740] Visual C++ CRT security update from 14 June 2011
New submission from Markus: In 14 June 2011 Microsoft released Visual C++ 2008 runtime MFC Security Update https://www.microsoft.com/en-us/download/details.aspx?id=26368 The Security Update also updates the CRT runtime (used by Python 2.7) Without the security update, Python 2.7.13 uses vc90.crt 9.0.30729.4940 With the security update, Python 2.7.13 uses vc90.crt 9.0.30729.6161 (Use e.g. Sysinternals procexp to see) Why does Python not install the vc90.crt of the security update? -- components: Build, Windows messages: 289135 nosy: markuskramerIgitt, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Visual C++ CRT security update from 14 June 2011 type: security versions: Python 2.7 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29740> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29351] absolute imports for logging
Markus Gerstel added the comment: Yes, this is indeed the same for other stdlib modules, too. Logging is just the first one that came to attention in our investigations. I haven't prepared any other patches yet though, because your answer could easily be "No, we cannot consider these changes under any circumstances for 2.7 because $reason". -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29351> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29351] absolute imports for logging
Changes by Markus Gerstel <markus.gers...@diamond.ac.uk>: -- nosy: +vinay.sajip ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29351> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29351] absolute imports for logging
New submission from Markus Gerstel: Running 'import logging' causes at minimum 46 failing 'open' and 12 failing 'stat' calls because python looks for packages inside python/Lib/logging which will never be there, in particular: sys, os, time, cStringIO, traceback, warnings, weakref, collections, codecs, thread, threading, atexit. The impact of this is limited when python is installed locally, but noticeable when run on a networked file system. How to reproduce: run $ strace python -c "import logging;" 2>&1 | grep ENOENT | grep "\/logging\/" How to fix: Add 'from __future__ import absolute_import' to all files in the logging directory. A relevant patch is attached. -- components: Library (Lib) files: 0001-absolute-import.patch keywords: patch messages: 286083 nosy: mgerstel priority: normal severity: normal status: open title: absolute imports for logging type: resource usage versions: Python 2.7 Added file: http://bugs.python.org/file46390/0001-absolute-import.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29351> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28310] Mixing yield and return with value is allowed
New submission from Markus Unterwaditzer: The attached example code raises a SyntaxError in Python 2, but is syntactically valid in Python 3. The return value is ignored and an empty generator is produced. I see no reason for this behavioral change. -- components: Interpreter Core files: lol.py messages: 277691 nosy: untitaker priority: normal severity: normal status: open title: Mixing yield and return with value is allowed versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file44877/lol.py ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28310> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25895] urllib.parse.urljoin does not handle WebSocket URLs
Markus Holtermann added the comment: Thanks for your input. I remove the versionchanged block. -- Added file: http://bugs.python.org/file44649/0001-Enable-WebSocket-URL-schemes-in-urllib.parse.urljoin.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25895> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25895] urllib.parse.urljoin does not handle WebSocket URLs
Markus Holtermann added the comment: Thanks for your input, Berker. Updated as suggested. I still include the versionchanged annotation as I suspect more people to look at the docs than the entire changelog -- Added file: http://bugs.python.org/file44615/0001-Enable-WebSocket-URL-schemes-in-urllib.parse.urljoin.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25895> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25895] urllib.parse.urljoin does not handle WebSocket URLs
Changes by Markus Holtermann <i...@markusholtermann.eu>: Removed file: http://bugs.python.org/file44609/0001-Enable-WebSocket-URL-schemes-in-urllib.parse.urljoin.3.6.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25895> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25895] urllib.parse.urljoin does not handle WebSocket URLs
Changes by Markus Holtermann <i...@markusholtermann.eu>: Removed file: http://bugs.python.org/file44610/0001-Enable-WebSocket-URL-schemes-in-urllib.parse.urljoin.master.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25895> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25895] urllib.parse.urljoin does not handle WebSocket URLs
Markus Holtermann added the comment: Since the patch applies cleanly to the 3.5, 3.6 and master branch I only attached one updated version of it. -- Added file: http://bugs.python.org/file44612/0001-Enable-WebSocket-URL-schemes-in-urllib.parse.urljoin.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25895> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25895] urllib.parse.urljoin does not handle WebSocket URLs
Changes by Markus Holtermann <i...@markusholtermann.eu>: Removed file: http://bugs.python.org/file44608/0001-Enable-WebSocket-URL-schemes-in-urllib.parse.urljoin.3.5.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25895> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25895] urllib.parse.urljoin does not handle WebSocket URLs
Changes by Markus Holtermann <i...@markusholtermann.eu>: Added file: http://bugs.python.org/file44609/0001-Enable-WebSocket-URL-schemes-in-urllib.parse.urljoin.3.6.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25895> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25895] urllib.parse.urljoin does not handle WebSocket URLs
Changes by Markus Holtermann <i...@markusholtermann.eu>: Added file: http://bugs.python.org/file44610/0001-Enable-WebSocket-URL-schemes-in-urllib.parse.urljoin.master.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25895> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25895] urllib.parse.urljoin does not handle WebSocket URLs
Changes by Markus Holtermann <i...@markusholtermann.eu>: Added file: http://bugs.python.org/file44608/0001-Enable-WebSocket-URL-schemes-in-urllib.parse.urljoin.3.5.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25895> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25895] urllib.parse.urljoin does not handle WebSocket URLs
Markus Holtermann added the comment: As discussed with rbcollins during the KiwiPyCon sprints, I'll add patches for 3.5, 3.6 and master with docs mentioning the addition of `ws` and `wss` as of 3.5.3 -- nosy: +MarkusH ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25895> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25137] Behavioral change / regression? with nested functools.partial
Markus Holtermann added the comment: Interesting thing tough, this optimization is nowhere mentioned in the 3.5 release notes ;) -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25137> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25137] Behavioral change / regression? with nested functools.partial
New submission from Markus Holtermann: Since #7830 nested partials are flattened. This is a behavioral change that causes a test failure in Django because we use nested partials to resolve relationships between models: https://github.com/django/django/pull/4423#issuecomment-138996095 In my opinion this is a regression since there's no way to turn off the new behavior. -- components: Library (Lib) messages: 250814 nosy: MarkusH, belopolsky priority: normal severity: normal status: open title: Behavioral change / regression? with nested functools.partial type: behavior versions: Python 3.5 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25137> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20438] inspect: Deprecate getfullargspec?
Markus Unterwaditzer added the comment: It should be properly noted that the API isn't going to be actually removed anytime soon. Also I think issuing a warning about this was a mistake. For software that wants to stay compatible with both Python 2 and 3 it's basically useless. -- nosy: +untitaker ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue20438> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20438] inspect: Deprecate getfullargspec?
Markus Unterwaditzer added the comment: My last comment was in reference to getfullargspec, which is, as far as I understand, not going to be deprecated until after 3.7. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue20438> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24711] Document getpass.getpass behavior on ^C
New submission from Markus Unterwaditzer: getpass.getpass doesn't enter a newline when the user aborts input with ^C, while input/raw_input does. This behavior is surprising and can lead to mis-formatting of subsequent output. However, since this behavior exists since 2.7 and applications may have started to rely on it, I'd add a note to the documentation. -- assignee: docs@python components: Documentation messages: 247302 nosy: docs@python, untitaker priority: normal severity: normal status: open title: Document getpass.getpass behavior on ^C versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24711 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23266] Faster implementation to collapse non-consecutive ip-addresses
Markus added the comment:
My initial patch was wrong wrt. _find_address_range.
It did not loop over equal addresses.
Thats why performance with many equal addresses was degraded when dropping the
set().
Here is a patch to fix _find_address_range, drop the set, and improve
performance again.
python3 -m timeit -s import bipaddress; ips =
[bipaddress.ip_address('2001:db8::1000') for i in range(1000)] --
bipaddress.collapse_addresses(ips)
1000 loops, best of 3: 1.76 msec per loop
python3 -m timeit -s import aipaddress; ips =
[aipaddress.ip_address('2001:db8::1000') for i in range(1000)] --
aipaddress.collapse_addresses(ips)
1000 loops, best of 3: 1.32 msec per loop
--
Added file: http://bugs.python.org/file37794/ipaddress_faster_collapse4.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23266
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23266] Faster implementation to collapse non-consecutive ip-addresses
Markus added the comment:
Eleminating duplicates before processing is faster once the overhead of the set
operation is less than the time required to sort the larger dataset with
duplicates.
So we are basically comparing sort(data) to sort(set(data)).
The optimum depends on the input data.
python3 -m timeit -s import random; import bipaddress; ips =
[bipaddress.ip_address('2001:db8::') + i for i in range(10)];
random.shuffle(ips) -- bipaddress.collapse_addresses(ips)
10 loops, best of 3: 1.49 sec per loop
vs.
10 loops, best of 3: 1.59 sec per loop
If the data is pre-sorted, possible if you retrieve from database, things are
drastically different:
python3 -m timeit -s import random; import bipaddress; ips =
[bipaddress.ip_address('2001:db8::') + i for i in range(10)]; --
bipaddress.collapse_addresses(ips)
10 loops, best of 3: 136 msec per loop
vs
10 loops, best of 3: 1.57 sec per loop
So for my usecase, I basically have less than 0.1% duplicates (if at all),
dropping the set would be better, but ... other usecases will exist.
Still, it is easy to emulate the use of sorted(set()) from a users
perspective - just call collapse_addresses(set(data)) in case you expect to
have duplicates and experience a speedup by inserting unique, possibly even
sorted, data.
On the other hand, if you have a huge load of 99.99% sorted non collapseable
addresses, it is not possible to drop the set() operation in your sorted(set())
from a users perspective, no way to speed things up, and the slowdown you get
is x10.
That said, I'd drop the set().
Optimization depends on data input, dropping the set() allows the user to
optimize base on the nature of his input data.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23266
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23266] Faster implementation to collapse non-consecutive ip-addresses
New submission from Markus: I found the code used to collapse addresses to be very slow on a large number (64k) of island addresses which are not collapseable. The code at https://github.com/python/cpython/blob/0f164ccc85ff055a32d11ad00017eff768a79625/Lib/ipaddress.py#L349 was found to be guilty, especially the index lookup. The patch changes the code to discard the index lookup and have _find_address_range return the number of items consumed. That way the set operation to dedup the addresses can be dropped as well. Numbers from the testrig I adapted from http://bugs.python.org/issue20826 with 8k non-consecutive addresses: Execution time: 0.6893927365541458 seconds vs. Execution time: 12.116527611762285 seconds MfG Markus Kötter -- components: Library (Lib) files: ipaddress_collapse_non_consecutive_performance.diff keywords: patch messages: 234239 nosy: cmn priority: normal severity: normal status: open title: Faster implementation to collapse non-consecutive ip-addresses type: performance versions: Python 3.5 Added file: http://bugs.python.org/file37762/ipaddress_collapse_non_consecutive_performance.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23266 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23266] Faster implementation to collapse non-consecutive ip-addresses
Markus added the comment: I just signed the agreement, ewa@ is processing it. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23266 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23266] Faster implementation to collapse non-consecutive ip-addresses
Markus added the comment: Added the testrig. -- Added file: http://bugs.python.org/file37763/testrig.tar.gz ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23266 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22956] Improved support for prepared SQL statements
Markus Elfring added the comment: Are you really against benefits from reusing of existing application programming interfaces for the explicit preparation and compilation of SQL statements? It seems that other software contributors like Marc-Andre Lemburg and Tony Locke show more constructive opinions. https://mail.python.org/pipermail/db-sig/2014-December/006133.html https://www.mail-archive.com/db-sig@python.org/msg01829.html http://article.gmane.org/gmane.comp.python.db/3784 -- resolution: rejected - later ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22956 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22956] Improved support for prepared SQL statements
New submission from Markus Elfring: An interface for parameterised SQL statements (working with placeholders) is provided by the execute() method from the Cursor class at the moment. https://docs.python.org/3/library/sqlite3.html#sqlite3.Cursor.execute I assume that the SQL Statement Object from the SQLite C interface is reused there already. http://sqlite.org/c3ref/stmt.html I imagine that it will be more efficient occasionally to offer also a base class like prepared_statement so that the parameter specification does not need to be parsed for every passed command. I suggest to improve corresponding preparation and compilation possibilities. -- components: Extension Modules messages: 231759 nosy: elfring priority: normal severity: normal status: open title: Improved support for prepared SQL statements ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22956 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22957] Multi-index Containers Library
New submission from Markus Elfring: I find a data structure like it is provided by the Boost Multi-index Containers Library interesting for efficient data processing. http://www.boost.org/doc/libs/1_57_0/libs/multi_index/doc/index.html How are the chances to integrate a class library with similar functionality into the Python software infrastructure? -- components: Extension Modules messages: 231761 nosy: elfring priority: normal severity: normal status: open title: Multi-index Containers Library type: enhancement ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22957 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22956] Improved support for prepared SQL statements
Changes by Markus Elfring elfr...@users.sourceforge.net: -- type: - enhancement ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22956 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22328] ur'foo\d' raises SyntaxError
New submission from Markus Unterwaditzer: The string literal `ur'foo\d'` causes a SyntaxError while the equivalent `r'foo\d'` causes the correct string to be produced. -- components: Interpreter Core messages: 226281 nosy: untitaker priority: normal severity: normal status: open title: ur'foo\d' raises SyntaxError type: behavior versions: Python 3.1, Python 3.2, Python 3.3, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22328 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8296] multiprocessing.Pool hangs when issuing KeyboardInterrupt
Markus Unterwaditzer added the comment: Can this issue or #9205 be reopened as this particular instance of the problem doesn't seem to be resolved? I still seem to need the workaround from http://stackoverflow.com/a/1408476 -- nosy: +untitaker ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8296 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16587] Py_Initialize breaks wprintf on Windows
Markus Kettunen added the comment: It's quite common to use wide character strings to support Unicode in C and C++. In C++ this often means using std::wstring and std::wcout. Maybe these are more common than wprintf? In any case the console output breaks as Py_Initialize hijacks the host application's standard output streams which sounds quite illegitimate to me. I understand that Python isn't designed for embedding and it would be a lot of work to fix it, but I would still encourage everyone to take a look at this bug. For me, this was one of the reasons I ultimately had to decide against using Python as my application's scripting language, which is a shame. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16587 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16587] Py_Initialize breaks wprintf on Windows
Markus Kettunen added the comment: On Linux, std::wcout doesn't use wprintf(). Do you mean that std::wcout also depends on the mode of stdout (_setmode)? Yes, exactly. I originally noticed this bug by using std::wcout on Windows. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16587 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17656] Python 2.7.4 breaks ZipFile extraction of zip files with unicode member paths
Changes by Markus bela domla...@yahoo.com: -- components: +Windows -Library (Lib), Unicode ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17656 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16587] Py_Initialize breaks wprintf on Windows
New submission from Markus Kettunen: In a C application on Windows, at least on MSVC 2010 and Windows 7, do this: wprintf(LTest\n); Py_Initialize(); wprintf(LTest\n); Output is: Test T e s t I was able to track the issue to fileio.c to the following code block by searching where wprintf breaks: if (dircheck(self, nameobj) 0) goto error; #if defined(MS_WINDOWS) || defined(__CYGWIN__) /* don't translate newlines (\r\n = \n) */ _setmode(self-fd, O_BINARY); - breaks it #endif if (PyObject_SetAttrString((PyObject *)self, name, nameobj) 0) goto error; This can be easily confirmed by adding wprintfs on both sides of _setmode. This issue was also raised at http://mail.python.org/pipermail/python-list/2012-February/620528.html but no solution was provided back then. -- components: IO, Unicode, Windows messages: 176732 nosy: ezio.melotti, makegho priority: normal severity: normal status: open title: Py_Initialize breaks wprintf on Windows type: behavior versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16587 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16587] Py_Initialize breaks wprintf on Windows
Markus Kettunen added the comment: If the standard streams are not used through Python, this hack can be used to work around the bug on C side: #ifdef WIN32 #include fcntl.h #endif ... Py_Initialize(); #ifdef WIN32 _setmode(stdin-_file, O_TEXT); _setmode(stdout-_file, O_TEXT); _setmode(stderr-_file, O_TEXT); #endif -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16587 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16399] argparse:
New submission from Markus Amalthea Magnuson: If the default value for a flag is a list, and the action append is used, argparse doesn't seem to override the default, but instead adding to it. I did this test script: import argparse parser = argparse.ArgumentParser() parser.add_argument( '--foo', action='append', default=['bar1', 'bar2'] ) args = parser.parse_args() print args.foo Output is as follows: $ ./argparse_foo_test.py ['bar1', 'bar2'] $ ./argparse_foo_test.py --foo bar3 ['bar1', 'bar2', 'bar3'] I would expect the last output to be ['bar3']. Is this on purpose (although very confusing) or is it a bug? -- components: Library (Lib) files: argparse_foo_test.py messages: 174735 nosy: Markus.Amalthea.Magnuson priority: normal severity: normal status: open title: argparse: type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file27874/argparse_foo_test.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16399 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16399] argparse: append action with default list adds to list instead of overriding
Changes by Markus Amalthea Magnuson markus.magnu...@gmail.com: -- title: argparse: - argparse: append action with default list adds to list instead of overriding ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16399 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14818] C implementation of ElementTree: Some functions should support keyword arguments
Markus com...@gmx.ch added the comment: Applied the patch, but could not verify 'it works for me' as Element lacks the attrib keyword. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14818 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14849] C implementation of ElementTree: Inheriting from Element breaks text member
New submission from Markus com...@gmx.ch:
Example Code to reproduce:
from xml.etree import ElementTree as etree
class xetree:
cElement = etree.Element
class Element(etree.Element):
def __init__(self, tag, attrib=None):
xetree.cElement.__init__(self, tag, attrib)
etree.Element = xetree.Element
e = etree.Element(test, {'foobar':'bar'})
e.text = failure
print(etree.tostring(e))
# will lack failure
So basic inheritance is broken.
--
components: Library (Lib)
messages: 161043
nosy: cmn
priority: normal
severity: normal
status: open
title: C implementation of ElementTree: Inheriting from Element breaks text
member
versions: Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14849
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13988] Expose the C implementation of ElementTree by default when importing ElementTree
Markus com...@gmx.ch added the comment: New bug - C implementation of ElementTree: Inheriting from Element breaks text member http://bugs.python.org/issue14849 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13988 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14818] C implementation of ElementTree: Some functions should support keyword arguments
Markus com...@gmx.ch added the comment: SubElement needs to handle the attrib keyword too. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14818 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13988] Expose the C implementation of ElementTree by default when importing ElementTree
Markus com...@gmx.ch added the comment: Hi, the C implementation of ElementTree do not support namespaces for find/all/... . To me this is a serious regression, as I rely on ElementTree namespace support, and 3.3 would break it with this change. Breaking namespace support is a fundamental problem. Please reconsider this therefore. Code to reproduced attached - works fine with python 3.2. As the C implementation of ElementTree and Element lack the namespace keyword for findall (and *all* the other methods), where namespaces are very important when dealing with xml, and it is not possible to prevent using the v implementation of ElementTree without changing the python install, I propose to revert this change. Until the C implementation can do namespaces as well. -- nosy: +cmn type: performance - behavior Added file: http://bugs.python.org/file25598/findall_takes_no_keywords_anymore.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13988 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13988] Expose the C implementation of ElementTree by default when importing ElementTree
Changes by Markus com...@gmx.ch: Removed file: http://bugs.python.org/file25598/findall_takes_no_keywords_anymore.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13988 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13988] Expose the C implementation of ElementTree by default when importing ElementTree
Markus com...@gmx.ch added the comment: The file was bad, sorry. re-attached -- Added file: http://bugs.python.org/file25599/findall_takes_no_keywords_anymore.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13988 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14818] C implementation of ElementTree causes regressions
New submission from Markus com...@gmx.ch: The C implementation of ElementTree which is the default by python3.3 [1] does not accept the namespaces keyword for Element/ElementTree.find(all|iter|...) and maybe others. [1] http://bugs.python.org/issue13988 -- components: Library (Lib) messages: 160753 nosy: cmn priority: normal severity: normal status: open title: C implementation of ElementTree causes regressions type: behavior versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14818 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13988] Expose the C implementation of ElementTree by default when importing ElementTree
Markus com...@gmx.ch added the comment: As advised I opened a new bug on this: http://bugs.python.org/issue14818 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13988 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11937] Interix support
Markus Duft markus.d...@salomon.at added the comment: if the buildbot does not need to be reached from the outside, i could provide one, yes (i'm behind a company firewall/proxy infrastructure) as for the patch: comments and improvement suggestions welcome :) as for interix (actually SUA - Subsystem for UNIX Applications): It is a POSIX compatible layer on top of MS Windows (since 2000, up to currently 2008R2/7). I'm working on building gentoo prefix there, which brings a lot improvement to the rather outdated userland of interix (new GCC, python ;), new perl, etc.). Interix suffers from a few smaller problems, making it feel unstable in certain situations. For example, fork() tends to fail with EAGAIN, poll() does not work correctly, etc. To compensate this, i have build a library (suacomp.sf.net) which wraps a lot of library functions. my python fixes python just enough to work with suacomp installed. without suacomp, python will still build (as suacomp only wraps existing apis), but will not work too well (depending on what your doing). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11937 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11937] Interix support
Markus Duft markus.d...@salomon.at added the comment: since the patch is rather small, and prove to not fluctuate too much on releases, i'd be willing to keep maintaining them, although i think that it would not cause too much problems to integrate it into the code base. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11937 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11937] Interix support
New submission from Markus Duft markus.d...@salomon.at: Hey! For a while now, i'm maintaining python build patches for interix for the gentoo prefix project. I thought maybe i can bring them upstream :) currently i have python 2.7.1 building, and i'll start testing python 3.2 in a while... may i ask your opinions on my patch, and maybe inclusion in the repository...? Regards, Markus -- components: Build files: python-2.7.1-interix.patch keywords: patch messages: 134564 nosy: mduft priority: normal severity: normal status: open title: Interix support type: compile error versions: Python 2.7 Added file: http://bugs.python.org/file21796/python-2.7.1-interix.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11937 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11568] docstring of select.epoll.register() is wrong
New submission from Markus Korn thek...@gmx.de: select.epoll.register raises an IOError for already registered fds, however the docstring says the fd gets modified: Python 2.7.1+ (r271:86832, Feb 24 2011, 15:00:15) [GCC 4.5.2] on linux2 Type help, copyright, credits or license for more information. import select print select.epoll.register.__doc__ register(fd[, eventmask]) - None Registers a new fd or modifies an already registered fd. fd is the target file descriptor of the operation. events is a bit set composed of the various EPOLL constants; the default is EPOLL_IN | EPOLL_OUT | EPOLL_PRI. The epoll interface supports all file descriptors that support poll. -- messages: 131100 nosy: thekorn priority: normal severity: normal status: open title: docstring of select.epoll.register() is wrong ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11568 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10803] ctypes: better support of bytearray objects
New submission from Markus F.X.J. Oberhumer mar...@oberhumer.com:
Python 3.2b2 does not properly support accessing bytearrays from
ctypes, which makes dealing with large buffers somewhat unpleasant.
A very first fix - a simple patch for the z_set() function - is given here.
build/Python-3.2b2 $ quilt diff
Index: b/Modules/_ctypes/cfield.c
===
--- a/Modules/_ctypes/cfield.c
+++ b/Modules/_ctypes/cfield.c
@@ -1363,6 +1363,10 @@
*(char **)ptr = PyBytes_AsString(value);
Py_INCREF(value);
return value;
+} else if (PyByteArray_Check(value)) {
+*(char **)ptr = PyByteArray_AsString(value);
+Py_INCREF(value);
+return value;
} else if (PyLong_Check(value)) {
#if SIZEOF_VOID_P == SIZEOF_LONG_LONG
*(char **)ptr = (char *)PyLong_AsUnsignedLongLongMask(value);
--
assignee: theller
components: ctypes
messages: 125032
nosy: mfxmfx, theller
priority: normal
severity: normal
status: open
title: ctypes: better support of bytearray objects
type: feature request
versions: Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10803
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5215] change value of local variable in debug
Markus Pröller mproel...@googlemail.com added the comment: Hello, I changed pdb.py to the file I added in the attachment (I just used the given patch pdb_cache_f_locals.patch) Then I created the following file: import pdb def function_1(number): stack_1 = number function_2(stack_1) def function_2(number): stack_2 = number + 1 function_3(stack_2) def function_3(number): stack_3 = number + 1 pdb.set_trace() print stack_3 function_1(1) and run that file with python -i filename This is my python version: --- Python 2.6.5 (r265:79096, Mar 19 2010, 21:48:26) [MSC v.1500 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. - And here is what I did in the pdb session: c:\tst_pdb.py(14)function_3() - print stack_3 (Pdb) !print stack_3 3 (Pdb) u c:\tst_pdb.py(9)function_2() - function_3(stack_2) (Pdb) l 4 stack_1 = number 5 function_2(stack_1) 6 7 def function_2(number): 8 stack_2 = number + 1 9 - function_3(stack_2) 10 11 def function_3(number): 12 stack_3 = number + 1 13 pdb.set_trace() 14 print stack_3 (Pdb) !print stack_2 *** NameError: name 'stack_2' is not defined (Pdb) d c:\tst_pdb.py(14)function_3() - print stack_3 (Pdb) l 9 function_3(stack_2) 10 11 def function_3(number): 12 stack_3 = number + 1 13 pdb.set_trace() 14 - print stack_3 15 16 function_1(1) [EOF] (Pdb) !stack_3 = 125 #this works now with the patch (Pdb) !print stack_3 125 (Pdb) When I use my original pdb.py, I can print variable stack_2 when I move one frame up, but can't change the value of these local variables. -- Added file: http://bugs.python.org/file18563/pdb.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5215 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5215] change value of local variable in debug
Markus Pröller mproel...@googlemail.com added the comment: Okay, thanks for giving me the correct patch, but I still face the following problem (with the same code snippet): c:\tst_pdb.py(14)function_3() - print stack_3 (Pdb) l 9 function_3(stack_2) 10 11 def function_3(number): 12 stack_3 = number + 1 13 pdb.set_trace() 14 - print stack_3 15 16 function_1(1) [EOF] (Pdb) stack_3 3 (Pdb) !stack_3 = 177 (Pdb) !print stack_3 177 (Pdb) u c:\tst_pdb.py(9)function_2() - function_3(stack_2) (Pdb) l 4 stack_1 = number 5 function_2(stack_1) 6 7 def function_2(number): 8 stack_2 = number + 1 9 - function_3(stack_2) 10 11 def function_3(number): 12 stack_3 = number + 1 13 pdb.set_trace() 14 print stack_3 (Pdb) !print stack_2 2 (Pdb) !stack_2 = 144 (Pdb) !print stack_2 144 (Pdb) d c:\tst_pdb.py(14)function_3() - print stack_3 (Pdb) l 9 function_3(stack_2) 10 11 def function_3(number): 12 stack_3 = number + 1 13 pdb.set_trace() 14 - print stack_3 15 16 function_1(1) [EOF] (Pdb) stack_3 3 (Pdb) u c:\tst_pdb.py(9)function_2() - function_3(stack_2) (Pdb) !print stack_2 2 (Pdb) I set the value of stack_3 to 177, go one frame up, do something, go one frame down and stack_3 is 3 again (not 177 as expected) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5215 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9633] pdb go stack up/down
New submission from Markus Pröller mproel...@googlemail.com: Hello, with python 2.7 I encounter the following problem: I have created the following sample script: import pdb def function_1(number): stack_1 = number function_2(stack_1) def function_2(number): stack_2 = number + 1 function_3(stack_2) def function_3(number): stack_3 = number + 1 pdb.set_trace() print stack_3 function_1(1) This is what I have done in the pdb session: c:\tst_pdb.py(14)function_3() - print stack_3 (Pdb) l 9 function_3(stack_2) 10 11 def function_3(number): 12 stack_3 = number + 1 13 pdb.set_trace() 14 - print stack_3 15 16 function_1(1) [EOF] (Pdb) stack_3 3 (Pdb) !stack_3 = 177 (Pdb) !print stack_3 177 (Pdb) u c:\tst_pdb.py(9)function_2() - function_3(stack_2) (Pdb) l 4 stack_1 = number 5 function_2(stack_1) 6 7 def function_2(number): 8 stack_2 = number + 1 9 - function_3(stack_2) 10 11 def function_3(number): 12 stack_3 = number + 1 13 pdb.set_trace() 14 print stack_3 (Pdb) !print stack_2 2 (Pdb) !stack_2 = 144 (Pdb) !print stack_2 144 (Pdb) d c:\tst_pdb.py(14)function_3() - print stack_3 (Pdb) l 9 function_3(stack_2) 10 11 def function_3(number): 12 stack_3 = number + 1 13 pdb.set_trace() 14 - print stack_3 15 16 function_1(1) [EOF] (Pdb) stack_3 3 (Pdb) u c:\tst_pdb.py(9)function_2() - function_3(stack_2) (Pdb) !print stack_2 2 (Pdb) I walked through the stack and changed the values of the variables stack_x but the values weren't saved when I moved one frame up/down -- components: Library (Lib) messages: 114213 nosy: Markus.Pröller priority: normal severity: normal status: open title: pdb go stack up/down type: behavior versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9633 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5215] change value of local variable in debug
Markus Pröller mproel...@googlemail.com added the comment: Hello, I have tested this patch since a while. In the meantime I have switched to Python 2.6.5, but the problem that I described above is still there. Another problem that brought the patch is, that when I move a frame up in the stack trace, the variables of the current stack are not available any more (only the variables of the newest frame are available). -- components: -None nosy: +Markus.Pröller versions: +Python 2.6 -Python 2.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5215 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7629] Compiling with mingw32 gcc, content of variable extra_postargs invalid
New submission from Markus hardcoreve...@gmx.de: I tried to build pylzma with python setup.py build -cmingw32 and got the following message. C:\MinGW\bin\gcc.exe -mno-cygwin -mdll -O -Wall -DWIN32=1 -DCOMPRESS_MF_MT=1 -DWITH_COMPAT=1 -IC:\work\dev\Python26\include -I. -IC:\work\dev\Python26\include -IC:\work\dev\Python26\PC -c pylzma.c -o build\temp.win32-2.6\Release\pylzma.o /MT gcc: /MT: No such file or directory /MT is the content of variable extra_postargs in cygwinccompiler.py upon the gcc call. Oddly /MT is a switch of the MSVC compiler not MinGW. I modified cygwinccompiler.py and cleared extra_postargs with [] it compiled without a problem then. -- assignee: tarek components: Distutils messages: 97187 nosy: popelkopp, tarek severity: normal status: open title: Compiling with mingw32 gcc, content of variable extra_postargs invalid versions: Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7629 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7629] Compiling with mingw32 gcc, content of variable extra_postargs invalid
Markus hardcoreve...@gmx.de added the comment: Sorry, my fault. /MT was given in setup.py of pylzma. I didn't search properly. Please close. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7629 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6334] 3.0/3.1: Bad bug in range() computation (or possible Integer problem)
Markus F.X.J. Oberhumer mar...@oberhumer.com added the comment: Many thanks for your quick fix! ~Markus -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6334 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6334] 3.0/3.1: Bad bug in range() computation (or possible Integer problem)
New submission from Markus F.X.J. Oberhumer mar...@oberhumer.com: Please note that the correct answer is 25, and the last element is missing ! This bug does not show on 64-bit versions (but 46337**2 is near 2**31). ~Markus C:\Python31python Python 3.1rc2 (r31rc2:73414, Jun 13 2009, 16:43:15) [MSC v.1500 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. len(list(range(46337**2, 46349**2, 46337))) 24 C:\Python30python.exe Python 3.0.1 (r301:69561, Feb 13 2009, 20:04:18) [MSC v.1500 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. len(list(range(46337**2, 46349**2, 46337))) 24 -- components: Interpreter Core messages: 89660 nosy: mfxmfx severity: normal status: open title: 3.0/3.1: Bad bug in range() computation (or possible Integer problem) type: behavior versions: Python 3.0, Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6334 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2140] calculation bug in long() function
Changes by Markus Stoll: -- components: None nosy: must21 severity: normal status: open title: calculation bug in long() function type: behavior versions: Python 2.1.1, Python 2.1.2, Python 2.2, Python 2.2.1, Python 2.2.2, Python 2.2.3, Python 2.3, Python 2.4, Python 2.5 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2140 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2140] calculation bug in long() function
New submission from Markus Stoll: betrag = 146.95 betrag = float(betrag) betrag = betrag * 100.0 betrag = long(betrag) print betrag gives 14694 as result rather than 14695 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2140 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2140] calculation bug in long() function
Markus Stoll added the comment: thank you for fast reply I see the point and do not want to argue about that (rounding is fine for me). I just think this behaviour makes the long() function pretty much useless. Regards, Markus Am 18.02.2008 um 13:25 schrieb Facundo Batista: Facundo Batista added the comment: In short: long(100 * 146.95) 14694L This is NOT a bug, but a behaviour of binary floating point: 146.95 146.94 In binary you can not express this number exactly. 146.95 * 100 14694.9998 When you long() that, you truncate the number, so it goes to 14694. Please address further discussion through python-list. Thanks! -- nosy: +facundobatista resolution: - invalid status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2140 __ __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2140 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
