[issue5965] Format Specs: doc 's' and implicit conversions

Eric Smith added the comment: Checked in. trunk: r78440 release26-maint: r78441 py3k: r78442 release31-maint: r78443 -- resolution: -> accepted stage: patch review -> committed/rejected status: open -> closed ___ Python tracker

[issue7649] "u'%c' % char" broken for chars in range '\x80'-'\xFF'

Ezio Melotti added the comment: The latest patch (issue7649v4.diff) checks if the char is ASCII or non-ASCII and then, if the char is ASCII, it converts it directly to Unicode, otherwise it tries to decode it using the default encoding, raising a UnicodeDecodeError if the decoding fails. I t

[issue7928] String formatting: grammar wrongly limits [index] to integer

Eric Smith added the comment: Checked in. trunk: r78444 release26-maint: r78445 py3k: r78446 release31-maint: r78447 -- resolution: -> accepted stage: patch review -> committed/rejected status: open -> closed ___ Python tracker

[issue1669349] make install fails if no previous Python installation

Gael added the comment: Here it is. Python 2.4.5 (#1, Feb 24 2010, 08:26:11) [GCC 3.4.6] on sunos5 Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> print sys.path [ '', '/tmp/Python-2.4/lib/python24.zip', '/install_path/Plone-3.2.1r4-UnifiedInstaller/

[issue8019] struct.unpack() expects wrong number of bytes

Nick added the comment: tested on macosx 10.6.2 64-bit and debian amd64 with both python2.6 and python3.1 the output is always the same: b'\x01\x00\x00\x00\x01\x00\x00\x00\x02\x00\x00\x00\x01\x00\x00\x00\x01\x00\x00\x00' 20 (1, 1, 2, 1, 1) (1, 1, 2, 16777216, 16777216) (1, 1, 2, 16777216, 167

[issue8019] struct.unpack() expects wrong number of bytes

New submission from Nick : the code I'm trying to execute (block is long enough): unpack("2IB2I", block) executing this raises an exception: struct.error: unpack requires a bytes argument of length 20 Setting native byte-order with '@' causes the same error. Specifying the correct byte-order ei

[issue8019] struct.unpack() expects wrong number of bytes

Amaury Forgeot d'Arc added the comment: It's not about byte ordering. '@' and '=' also change the alignment! The documentation says it well: - '@' (or no marker) uses the 'native' alignment, which (on every platform I know) aligns 4-bytes ints to multiple of 4 bytes. - '=' uses the 'standard'

[issue7863] platform module doesn't detect Windows 7

Brian Curtin added the comment: This patch should cover everything, and it works with 2.6 as well. In order to figure out workstation vs. server, it uses the ProductName from the registry when it can't the info from getwindowsversion. If it finds a server name, it's a server, otherwise fallba

[issue7150] datetime operations spanning MINYEAR give bad results

Alexander Belopolsky added the comment: Given assert(*m > 0); assert(*d > 0); at the end of normalize_y_m_d(), it looks like at lest 1 <=*month and 1 <=*day are redundant. A closer look also reveals assert(1 <= *m && *m <= 12); in the middle of normalize_y_m_d().

[issue7150] datetime operations spanning MINYEAR give bad results

Alexander Belopolsky added the comment: Aha! My reliance on asserts() was misguided. With the debug build: >>> t0-d2 Assertion failed: (ordinal >= 1), function ord_to_ymd, file /Users/sasha/Work/python-svn/trunk/Modules/datetimemodule.c, line 269. Abort trap Should we reclassify this bug as

[issue8020] Crash in Py_ADDRESS_IN_RANGE macro

New submission from Matt Bandy : Using the Py_ADDRESS_IN_RANGE macro can result in a crash under certain threading conditions. Since it is intentionally possible for (POOL)->arenaindex to reference memory which is not under Python's control, another thread may modify that memory. In particul

[issue7150] datetime operations spanning MINYEAR give bad results

Amaury Forgeot d'Arc added the comment: No, because normally distributions do not use debug builds. but that's the reason why tests are needed: they must pass with asserts enabled. -- ___ Python tracker ___

[issue8020] Crash in Py_ADDRESS_IN_RANGE macro

Tim Peters added the comment: Note that nothing in obmalloc is _intended_ to be thread-safe. Almost all Python API functions make the caller responsible for serializing calls (which is usually accomplished "by magic" via the GIL). This includes calls to all facilities supplied by obmalloc.

[issue8020] Crash in Py_ADDRESS_IN_RANGE macro

Amaury Forgeot d'Arc added the comment: No, the description above says it: only the first thread calls Py_ADDRESS_IN_RANGE. The other thread happens to modify the memory at the beginning of the page, just at the address (POOL)->arenaindex. Could we use an "inline" function instead of a macro?

[issue8020] Crash in Py_ADDRESS_IN_RANGE macro

Antoine Pitrou added the comment: Obviously it also involves changing the code where the macro is invoked. It would be quite non-controversial though. I've a got a more interesting question: how does the memory allocator end up being invoked from two threads at once? Usually memory allocation

[issue8020] Crash in Py_ADDRESS_IN_RANGE macro

Matt Bandy added the comment: Amaury is correct -- in the case I observed, the other thread had nothing to do with Python and was not calling Python functions that would have required obtaining the GIL at any time (again, I'm using an embedded Python interpreter in a larger app, not the stand

[issue8020] Crash in Py_ADDRESS_IN_RANGE macro

Matt Bandy added the comment: You can't add a block without changing the way the macro is used -- it's usually used like: if (Py_ADDRESS_IN_RANGE(p, pool)) This won't work with your proposed change since you can't put a do {} loop into the test expression of the if statement. -- __

[issue8020] Crash in Py_ADDRESS_IN_RANGE macro

Tim Peters added the comment: Amaury, I have no real idea what your "No, the description above says it: ..." is a response to, but if it's to my point that obmalloc is not intended to be thread-safe, it's not addressing that point. Any case in which another thread can affect a thread current

[issue6538] MatchObject is not a hyperlink in the 're' module documentation

Asheesh Laroia added the comment: Hey all, I think this is ready. Can someone review the patch? -- nosy: +Asheesh.Laroia ___ Python tracker ___ _

[issue8020] Crash in Py_ADDRESS_IN_RANGE macro

Tim Peters added the comment: Just noting there are ways to trick the macro into reading a thing once. For example, embed something like a ((x = arenas[(POOL)->arenaindex].address) || 1) clause early on & refer to x later (where x is some file-scope new variable). obmalloc is not intended t

[issue8020] Crash in Py_ADDRESS_IN_RANGE macro

Matt Bandy added the comment: It's a pretty major limitation on the embedding case if you can't allow other threads that aren't related to Python to run at any time that another thread may be in obmalloc, and one I haven't seen documented anywhere. The only other fix that occurs to me would

[issue8021] sys.exit() doesn't execute inside a signal handler while blocked inside an try/except

New submission from David Schere : When doing an exit() within a signal handler for an alarm I am seeing something strange: This code works, it exits within signal handler as expected. You never see the print statement executed. import signal import time import sys import traceback def handl

[issue8021] sys.exit() doesn't execute inside a signal handler while blocked inside an try/except

David Schere added the comment: sys.exit() does not behave the way a C programming thinks. It raises an exception. I'm probably not the first person to get this 'gotcha' -- status: open -> closed ___ Python tracker

[issue8020] Crash in Py_ADDRESS_IN_RANGE macro

Tim Peters added the comment: Right, I already agreed it would be fine to fix this if it's cheap ;-) I didn't give any real thought to the macro solution, but that's fine by me too. It would be best to embed the assignment in a _natural_ place, though; like, say: #define Py_ADDRESS_IN_RANGE

[issue6538] MatchObject is not a hyperlink in the 're' module documentation

Amaury Forgeot d'Arc added the comment: It would be simpler to add a ".. class:: MatchObject" directive. Also, RegexpObject should be handled as well. -- nosy: +amaury.forgeotdarc ___ Python tracker ___

[issue8020] Crash in Py_ADDRESS_IN_RANGE macro

Matt Bandy added the comment: That should probably be: #define Py_ADDRESS_IN_RANGE(P, POOL)\ ((x = (POOL)->arenaindex) < maxarenas &&\ (uptr)(P) - arenas[x].address < (uptr)ARENA_SIZE && \ arenas[x].address != 0) The address in the

[issue8015] pdb "commands" command throws you into postmortem if you enter an empty command

Alexander Belopolsky added the comment: I am attaching the patch that fixes the issue by ignoring empty and all space lines during commands' entry. Note that as written the patch also makes pdb ignore shell escapes unless it is extended with do_shell method. I think this is the right behavio

[issue8020] Crash in Py_ADDRESS_IN_RANGE macro

Tim Peters added the comment: > `x` should be a local variable. ... assembler code will be smaller. ??? It should make no difference to an optimizing compiler. Lifetime analysis (even if it's feeble) should be able to determine that all uses are purely local, with no need to store the value a

[issue1528154] New sequences for Unicode groups and block ranges needed

Matthew Barnett added the comment: \p{name} is supported for Unicode properties, scripts and blocks in my regex module (see issue #2636). It also supports the POSIX set syntax, although I'm not sure that we really need to have 2 ways of doing it, eg \p{Alpha} and [[:Alpha:]]. -- ___

[issue7999] setregid does not work with -1 as argument

Alexander Belopolsky added the comment: I reproduced this bug on OSX 10.6: >>> os.setregid(-1,-1) Traceback (most recent call last): File "", line 1, in OverflowError: group id too big Since -1 has special meaning as an argument to POSIX setregid(rgid, egid), """ If rgid is -1, the real gr

[issue5475] urllib2.getproxies not documented

Senthil Kumaran added the comment: urllib.getproxies() might be helpful to be documented too. I have added documentaion to this helper function in the r78457 (trunk), r78458, r78459, r78460. -- resolution: -> fixed status: open -> closed ___ Pytho

[issue8022] Leak when creating certain classes that subclass ABCs

New submission from Daniel Stutzbach : Attached is a minimal example. It has a function called leak(). The end of the script calls that function, runs the garbage collector, and prints out the number of objects in the system. In Python 2.6, the number of objects increases after each iterati

[issue6538] MatchObject is not a hyperlink in the 're' module documentation

Asheesh Laroia added the comment: Ryan -- would you take a further look at this? -- ___ Python tracker ___ ___ Python-bugs-list mailin

[issue8022] Leak when creating certain classes that subclass ABCs

Changes by Benjamin Peterson : -- resolution: -> duplicate status: open -> closed superseder: -> ABC caches should use weak refs ___ Python tracker ___ _

[issue2636] Regexp 2.7 (modifications to current re 2.2.2)

Matthew Barnett added the comment: issue2636-20100226.zip is a new version of the regex module. It now supports the branch reset (?|...|...), enabling the different branches of an alternation to reuse group numbers. -- Added file: http://bugs.python.org/file16375/issue2636-20100226.zi

[issue7994] object.__format__ should reject format strings

Meador Inge added the comment: The patch looks reasonable. I built on it with the following changes: 1. Added some extra test cases to cover Unicode format strings, since the code was changed to handle these as well. 2. Changed test_builtin.py by s/m[0].message.message/str(

[issue7911] unittest.TestCase.longMessage should default to True in Python 3.2

Pablo Mouzo added the comment: The patch changes the default to True, and updates the tests and the docs to reflect this. -- keywords: +patch nosy: +pablomouzo Added file: http://bugs.python.org/file16377/issue7834.diff ___ Python tracker