[issue11816] Refactor the dis module to provide better building blocks for bytecode analysis

Nick Coghlan added the comment: 'Op' is just an abbreviation of 'operation'. So 'operation code' becomes 'opcode' and 'operation information' becomes 'opinfo'. The fact that it comes for the 'dis' module gives the context that the *kind* of operation we're talking about is a Python byte code

[issue11816] Refactor the dis module to provide better building blocks for bytecode analysis

Meador Inge added the comment: I took a quick look over the final patch (I will do a more thorough review later). I like the general idea a lot. The first thing that popped out at me are the names 'OpInfo' and 'get_opinfo'. 'OpInfo' makes it sound like information concerning only the opcode,

[issue12881] ctypes: segfault with large structure field names

Meador Inge added the comment: I am going to open separate issues for the other crashers. > Also, PyUnicode_FromFormat could be used instead of sprintf. Amaury, how so? 'sprintf' and 'stgdict->format' work with 'char *'s where as 'PyUnicode_FromFormat' builds a unicode string object. Unless

[issue13020] structseq.c: refleak

Meador Inge added the comment: In general I agree that a test case is needed, but in this particular case its looks to be non-trivial to come up with one. The only way the reference leak is triggered is when memory is exhausted during an attempt to new up a 'PyStructSequence' object. -

[issue13013] _ctypes.c: refleak

Meador Inge added the comment: This patch seems reasonable. Upon looking at the code in more detail, however, I can't see how the error condition that leaks the reference can ever by triggered. In particular, the following code from the 'PyCArrayType_from_ctype' function: if (!PyType_Chec

[issue6549] ttk.Style -- minor issues with element_names and configure

Changes by Ethan Furman : -- title: ttk.Style not translating some Tcl options -> ttk.Style -- minor issues with element_names and configure ___ Python tracker ___ __

[issue6549] ttk.Style not translating some Tcl options

Ethan Furman added the comment: The changes to Style.configure were not good. Corrected so the (possibly empty) result is returned when a query is made but not when configuration is set. Two patches: one for the element_names issue, one for the configure issue. Question: Does it ever make

[issue13026] Dis module - documentation of MAKE_FUNCTION

Arnaud Delobelle added the comment: Yes, you are correct. Reading this again, I don't think I should have used the word "pushed" as it sounds like the effect of the opcode is to push stuff onto the stack, whereas I was only trying to describe what is on the stack just before the opcode is ex

[issue13026] Dis module - documentation of MAKE_FUNCTION

Terry J. Reedy added the comment: Minor edit: in 'which are push below TOS', /push/pushed/. I understand 'in this order' to mean that positional defaults are pushed first so that they end up on the bottom, whereas annotations are pushed last and end up just under the code object. Correct? (Thi

[issue13026] Dis module - documentation of MAKE_FUNCTION

New submission from Arnaud Delobelle : The description of the opcode MAKE_FUNCTION in the dis module document is out of date. It still describes the 2.X version of the opcode: """ MAKE_FUNCTION(argc) Pushes a new function object on the stack. TOS is the code associated with the function. The

[issue13010] devguide doc: ./python.exe on OS X

Changes by Ezio Melotti : -- assignee: docs@python -> ezio.melotti ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscrib

[issue13010] devguide doc: ./python.exe on OS X

Ezio Melotti added the comment: Fixed, thanks for the report and the suggestion! -- components: +Devguide -Documentation resolution: -> fixed stage: -> committed/rejected status: open -> closed ___ Python tracker

[issue13010] devguide doc: ./python.exe on OS X

Roundup Robot added the comment: New changeset 9363db42626a by Ezio Melotti in branch 'default': #13010: explain why the python executable has an .exe extension on OS X. http://hg.python.org/devguide/rev/9363db42626a -- nosy: +python-dev ___ Python t

[issue6549] ttk.Style not translating some Tcl options

Ethan Furman added the comment: Not sure what 'embossed' has to do with not having dashes as part of the element option names. Attached is a patch (hopefully in the right format) agains the current 3.3 sources to remove the dash from the names in .element_names(), as well as return None from

[issue13002] peephole.c: unused parameter

Stefan Krah added the comment: Thanks for checking the patch! Closing this now. -- resolution: -> fixed stage: patch review -> committed/rejected status: open -> closed ___ Python tracker

[issue13019] bytearrayobject.c: refleak

Changes by Stefan Krah : -- title: bytearrayobject.c: Resource is not released before returning from the functiion -> bytearrayobject.c: refleak ___ Python tracker ___ _

[issue13015] _collectionsmodule.c: refleak

Changes by Stefan Krah : -- components: +Extension Modules stage: -> patch review title: Resource is not released before returning from the functiion -> _collectionsmodule.c: refleak versions: +Python 3.3 ___ Python tracker

[issue13016] selectmodule.c: refleak

Changes by Stefan Krah : -- components: +Extension Modules stage: -> patch review title: Resource is not released before returning from the functiion -> selectmodule.c: refleak versions: +Python 3.3 ___ Python tracker

[issue13014] _ssl.c: refleak

Changes by Stefan Krah : -- components: +Extension Modules title: _ssl.c: resource is not released before returning from the function -> _ssl.c: refleak versions: +Python 3.3 ___ Python tracker ___

[issue13018] dictobject.c: refleak

Changes by Stefan Krah : -- components: +Interpreter Core stage: -> patch review versions: +Python 3.3 ___ Python tracker ___ ___ Pyt

[issue13017] pyexpat.c: refleak

Changes by Stefan Krah : -- components: +Extension Modules stage: -> patch review versions: +Python 3.3 ___ Python tracker ___ ___ Py

[issue13018] dictobject.c: refleak

Changes by Stefan Krah : -- title: Resource is not released before returning from the functiion -> dictobject.c: refleak ___ Python tracker ___ _

[issue13017] pyexpat.c: refleak

Changes by Stefan Krah : -- title: Resource is not released before returning from the functiion -> pyexpat.c: refleak ___ Python tracker ___

[issue13013] _ctypes.c: refleak

Changes by Stefan Krah : -- title: Resource is not released before returning from the functiion -> _ctypes.c: refleak ___ Python tracker ___

[issue13020] structseq.c: refleak

Changes by Stefan Krah : -- title: Resource is not released before returning from the functiion -> structseq.c: refleak ___ Python tracker ___ __

[issue13005] operator module docs include repeat

Roundup Robot added the comment: New changeset 0d0bfbaaf95c by Senthil Kumaran in branch '3.2': Fix closes issue13005 - Remove the mention of 'repeat' method in the operator module documentation. http://hg.python.org/cpython/rev/0d0bfbaaf95c New changeset 6c60f2aacc83 by Senthil Kumaran in bra

[issue12991] Python 64-bit build on HP Itanium - Executable built successfully but modules failed with HP Compiler

Senthil Kumaran added the comment: Wah meng - Instructions to get the _tkinter compile would be a good idea too. Also, can you verify the same instructions would work for 3.2 version of Python? -- keywords: +patch Added file: http://bugs.python.org/file23221/README.patch

[issue12991] Python 64-bit build on HP Itanium - Executable built successfully but modules failed with HP Compiler

Stefan Krah added the comment: > I think, it is a good idea to improve the Readme for this issue. +1. Wah Meng: Building everything is not enough, does 'make test' complete successfully? For gcc, Python2.7 relies on two critical options, -fno-strict-aliasing and -fwrapv. The HP compiler might

[issue12991] Python 64-bit build on HP Itanium - Executable built successfully but modules failed with HP Compiler

Senthil Kumaran added the comment: Wah Meng and I were discussing about this in a separate thread as well. I think, it is a good idea to improve the Readme for this issue. Wah Meng, since you already went at length to contact HP and clarify linker issue with 64 bit and found a solution to it,

[issue13002] peephole.c: unused parameter

Roundup Robot added the comment: New changeset 573d73e62bbc by Stefan Krah in branch 'default': Issue #13002: Fix Visual Studio warning (not enough actual parameters). http://hg.python.org/cpython/rev/573d73e62bbc -- nosy: +python-dev ___ Python trac

[issue12981] rewrite multiprocessing (senfd|recvfd) in Python

Roundup Robot added the comment: New changeset c158eac8e951 by Charles-François Natali in branch '2.7': Issue #12981: test_multiprocessing: catch ImportError when importing http://hg.python.org/cpython/rev/c158eac8e951 New changeset 6e04d406bb86 by Charles-François Natali in branch '3.2': Issue

[issue12944] Accept arbitrary files for packaging's upload command

Éric Araujo added the comment: This was discussed some time ago in a thread starting here: http://mail.python.org/pipermail/catalog-sig/2011-May/003736.html I’ll summarize the important parts below. Currently, upload will only push files that are products of a command run from the same comm

[issue828450] sdist generates bad MANIFEST on Windows

Éric Araujo added the comment: > One cann't let Python generate MANIFEST files taking Unix-style LF as newline > endings On Windows, I think. Why? Python can open it fine, and it’s not meant for human edition, so the stupidity of notepad.exe is not a problem . > So, does it mean even though w

[issue828450] sdist generates bad MANIFEST on Windows

higery added the comment: >>I’ve just found another problem with MANIFEST files created in Windows: they >>use CRLF. One cann't let Python generate MANIFEST files taking Unix-style LF as newline endings On Windows, I think. So, does it mean even though we have already made much effort for th

[issue6006] ffi.c compile failures on AIX 5.3 with xlc

rubisher added the comment: Hello Gilles, The libffi-4.2.0-3 I used, was coming from the previously mentioned repository: . That said, if I click on link, it points me to So, as far as I un

[issue11682] PEP 380 reference implementation for 3.3

Éric Araujo added the comment: Doc patch 002 is not strictly related to PEP 380 but pertains more to #10289. -- ___ Python tracker ___ __

[issue13019] bytearrayobject.c: Resource is not released before returning from the functiion

Changes by Mark Dickinson : -- components: +Interpreter Core title: Resource is not released before returning from the functiion -> bytearrayobject.c: Resource is not released before returning from the functiion ___ Python tracker

[issue12990] launcher can't work on path including tradition chinese char

Ricky Teng added the comment: Excuse me This is my first time use this bug report. I have uploaded a jpg to show what I do. The result is that a console will show and nothing happen. 於 2011/9/16 下午 07:54, Ronald Oussoren 提到: > New submission from Ronald Oussoren: > > Could you please add som

[issue12990] launcher can't work on path including tradition chinese char

Changes by Teng Ricky : Added file: http://bugs.python.org/file23220/IMG_4359.JPG ___ Python tracker ___ ___ Python-bugs-list mailing list Uns

[issue12508] Codecs Anomaly

Ezio Melotti added the comment: AFAIU final means: * final=0: I'm passing in a few bytes, but there are more to come, so if the last byte(s) doesn't make sense on its own (e.g. it's a start byte but the continuation bytes are missing), wait for the others before raising an error; * final=1

[issue12729] Python lib re cannot handle Unicode properly due to narrow/wide bug

Changes by Zbyszek Szmek : -- nosy: +zbysz ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.o

[issue12991] Python 64-bit build on HP Itanium - Executable built successfully but modules failed with HP Compiler

Wong Wah Meng added the comment: Closing the issue. Please contact me if the README file for HP-UX Itanium 64-bit build should be amended. -- status: open -> closed ___ Python tracker

[issue12991] Python 64-bit build on HP Itanium - Executable built successfully but modules failed with HP Compiler

Wong Wah Meng added the comment: Good news is now I am still using ld, like what is generated in the Makefile file by configure script, and able to do the linking process for the built-in modules successfully. I only need to set CC="cc +DD64" and "CXX=aCC" and the process make process is ab

[issue12508] Codecs Anomaly

Marc-Andre Lemburg added the comment: The final parameter is an extension to the decoder API signature, so it's not surprising that not all codecs implement it. The ones that do should use it for all calls, since that way the actual consumed number of bytes is correctly reported back to the Str

[issue8271] str.decode('utf8', 'replace') -- conformance with Unicode 5.2.0

Changes by Stefan Ring : -- nosy: +Ringding ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.o

[issue12961] itertools: unlabelled balls in boxes

Raymond Hettinger added the comment: Sorry Phillip, I'm closing this feature request because the benefits would likely be outweighed by the costs (maintenance, learning curve, module complexity, etc). It was not the goal of the module to become a complete combinatorics toolkit; rather, the g

[issue1172711] long long support for array module

STINNER Victor added the comment: > New changeset 672b63aff0f4 by Meador Inge in branch 'default' Woops, I wrote the wrong module name. Thanks for fixing it. -- ___ Python tracker __

[issue13014] _ssl.c: resource is not released before returning from the function

Changes by Stefan Krah : -- title: Resource is not released before returning from the functiion -> _ssl.c: resource is not released before returning from the function ___ Python tracker ___

[issue13014] Resource is not released before returning from the functiion

Stefan Krah added the comment: This doesn't look right to me: If (rdn != NULL) && (PyList_Size(rdn) > 0), rdn is already decremented. There is a leak though if (rdn != NULL) && (PyList_Size(rdn) == 0). -- nosy: +skrah ___ Python tracker

[issue6006] ffi.c compile failures on AIX 5.3 with xlc

Gilles PION added the comment: According to ffi site (http://sourceware.org/libffi/, the latest version is libffi-3.0.10, dated few days ago (which BTW I've been unable to compile on AIX, while 3.0.9 is OK) So what are those 4.2.0-3 versions coming from? -- nosy: +gpion