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

[Eric Smith]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Ezio Melotti]

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 tested it setting iso-8859-1 and utf-8 as default encoding and the behavior 
was consistent with "%s", however the tests assume that the default encoding is 
always ASCII, so they failed (both the tests included in the patch and others 
in test_unicode). I'm not sure if in this case they should be changed/skipped 
or not.

(Also http://docs.python.org/c-api/unicode.html#built-in-codecs says that 
"Setting encoding to NULL causes the default encoding to be used which is 
ASCII.", but this is not always true. If you think it should be fixed I'll do 
it in a separate commit.)

--
stage: committed/rejected -> patch review
Added file: http://bugs.python.org/file16369/issue7649v4.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Eric Smith]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1669349] make install fails if no previous Python installation

[Gael]

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/packages/Python-2.4.5/Lib', 
'/install_path/Plone-3.2.1r4-UnifiedInstaller/packages/Python-2.4.5/Lib/plat-sunos5',
 
'/install_path/Plone-3.2.1r4-UnifiedInstaller/packages/Python-2.4.5/Lib/lib-tk',
 
'/install_path/Plone-3.2.1r4-UnifiedInstaller/packages/Python-2.4.5/Modules', 
'/install_path/Plone-3.2.1r4-UnifiedInstaller/packages/Python-2.4.5/build/lib.solaris-2.10-sun4u-2.4']


PS: Sorry for the message above, haven't seen I was responding to the bug 
system. Feel free to drop it.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Nick]

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, 16777216)
--
b'\x01\x00\x00\x00\x01\x00\x00\x00\x02\x01\x00\x00\x00\x01\x00\x00\x00'
17
(1, 1, 2, 1, 1)
(1, 1, 2, 1, 1)

--
Added file: http://bugs.python.org/file16370/struct_test.py

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Nick]

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 either with '>' or '<', or
native with '=' helps and unpack expects the correct number (17) of bytes.

--
components: Library (Lib)
messages: 100096
nosy: codingrobot
severity: normal
status: open
title: struct.unpack() expects wrong number of bytes
type: behavior
versions: Python 2.6, Python 3.1

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Amaury Forgeot d'Arc]

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' alignment which is: "no alignment is required for any 
type"

--
nosy: +amaury.forgeotdarc
resolution:  -> invalid
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7863] platform module doesn't detect Windows 7

[Brian Curtin]

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 fallback to be a workstation.

This was able to correctly differentiate Vista and Server 2008. I don't have 
access to Server 2008 R2, but I can't imagine it missing a registry key that 
exists on every computer I looked at (XP, 2003, Vista, 2008, 7).

--
Added file: http://bugs.python.org/file16371/issue7863.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7150] datetime operations spanning MINYEAR give bad results

[Alexander Belopolsky]

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().  This seems to leave only *day <=31 
possibly relevant.

I suspect that out of bounds day surviving normalize_y_m_d() is a logical error 
in that function that needs to be fixed and an assert() added at the end.  The 
proposed patch appears to cure the symptom rather than the actual flaw.

--
nosy: +Alexander.Belopolsky

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7150] datetime operations spanning MINYEAR give bad results

[Alexander Belopolsky]

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 a crash?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8020] Crash in Py_ADDRESS_IN_RANGE macro

[Matt Bandy]

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 particular, the following sequence 
of operations is possible and leads to a crash:

1. A thread running Python code enters the Py_ADDRESS_IN_RANGE macro to test a 
pointer value which was allocated by the system allocator, not the pool-based 
allocator.
2. That thread intentionally reads a value (POOL)->arenaindex from memory which 
was not allocated by the Python interpreter.
3. The value (POOL)->arenaindex is tested and is less than maxarenas.
4. An unrelated thread which actually allocated the memory Py_ADDRESS_IN_RANGE 
is in the middle of looking at modifies the value referenced by 
(POOL)->arenaindex, changing it to a different value which is larger than 
maxarenas.
5. The original thread running Python code subscripts arenas with the new value 
and reads memory past the end of the arenas array, leading to unpredictable 
behavior or an access violation.

It's possible to fix this problem by changing Py_ADDRESS_IN_RANGE to a function 
so that it reads (POOL)->arenaindex only once, but the adjacent comment 
suggests that it's important for performance that it be a macro.

I observed this crash on Windows Vista x64 using an embedded Python 2.6.4 
interpreter, although the same code appears to exist in later versions of 
Python as well.

--
components: Interpreter Core
messages: 100106
nosy: mbandy
severity: normal
status: open
title: Crash in Py_ADDRESS_IN_RANGE macro
versions: Python 2.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7150] datetime operations spanning MINYEAR give bad results

[Amaury Forgeot d'Arc]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8020] Crash in Py_ADDRESS_IN_RANGE macro

[Tim Peters]

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.

--
nosy: +tim_one

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8020] Crash in Py_ADDRESS_IN_RANGE macro

[Amaury Forgeot d'Arc]

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? I suppose the compiler 
would optimize it and generate code as fast as a macro.

--
nosy: +amaury.forgeotdarc

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8020] Crash in Py_ADDRESS_IN_RANGE macro

[Antoine Pitrou]

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 allocations should be 
serialized by the GIL (the Global Interpreter Lock).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8020] Crash in Py_ADDRESS_IN_RANGE macro

[Matt Bandy]

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 standalone interpreter).  The other thread is just 
unlucky to have allocated non-Python related memory in the same page where a 
Python object was allocated.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8020] Crash in Py_ADDRESS_IN_RANGE macro

[Matt Bandy]

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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8020] Crash in Py_ADDRESS_IN_RANGE macro

[Tim Peters]

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 currently running in obmalloc is forbidden:  forbidden, not 
allowed, begging for undefined behavior, etc etc.

> Could we use an "inline" function instead of a macro?

If every C compiler on every platform Python runs on supports such a thing with 
exactly the same spelling, sure ;-)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Asheesh Laroia]

Asheesh Laroia  added the comment:

Hey all,

I think this is ready. Can someone review the patch?

--
nosy: +Asheesh.Laroia

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8020] Crash in Py_ADDRESS_IN_RANGE macro

[Tim Peters]

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 to be thread-safe _period_, but I agree the current 
behavior in the case described is obnoxious enough that if it's easy to worm 
around it, fine.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8020] Crash in Py_ADDRESS_IN_RANGE macro

[Matt Bandy]

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 be to ensure that any memory Python allocates is 
not in the same page as memory not allocated by Python, but that seems like it 
would be much more complex than the current "just call malloc()" solution.  
Your proposed change to the macro sounds more reasonable to me.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[David Schere]

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 handler( *args ):
   sys.exit(-1) #<-- terminate program


signal.signal( signal.SIGALRM, handler ) 
# set alarm to go off in one second that calls handler()
signal.alarm( 1 )


time.sleep( 3 )


print 'You should never see this message'


This code results in sys.exit() begin ignored and the code inside the “except:” 
block being executed!

import signal
import time
import sys
import traceback

def handler( *args ):
   sys.exit(-1) #<-- terminate program


signal.signal( signal.SIGALRM, handler ) 
# set alarm to go off in one second that calls handler()
signal.alarm( 1 )

try:
   time.sleep( 3 )
except:
   print 'This message should not be seen'
   sys.exit()
   
print 'You should never see this message'


The work around is to raise an exception inside the 
handler() function.

--
messages: 100120
nosy: david_schere
severity: normal
status: open
title: sys.exit() doesn't execute inside a signal handler while blocked inside 
an try/except
type: behavior
versions: Python 2.5

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[David Schere]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8020] Crash in Py_ADDRESS_IN_RANGE macro

[Tim Peters]

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(P, POOL)\
((POOL)->arenaindex < maxarenas &&  \
 (uptr)(P) - (x = arenas[(POOL)->arenaindex].address) < 
(uptr)ARENA_SIZE && \
 x != 0)

where some better name than `x` is picked, and the trick is clearly documented 
at x's declaration point.  Nothing wrong with expediency here!  This is 
time-critical code and has always been skating on the edge.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Amaury Forgeot d'Arc]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8020] Crash in Py_ADDRESS_IN_RANGE macro

[Matt Bandy]

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 arena shouldn't change since it does belong to Python, so no 
one should be monkeying with it without the GIL.  The arenaindex is vulnerable 
since POOL can point to something not owned by Python.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Alexander Belopolsky]

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 behavior.

--
components: +Library (Lib)
keywords: +patch
nosy: +Alexander.Belopolsky
type:  -> behavior
Added file: http://bugs.python.org/file16373/issue8015.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8020] Crash in Py_ADDRESS_IN_RANGE macro

[Tim Peters]

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 away.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Matthew Barnett]

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:]].

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Alexander Belopolsky]

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 group ID shall not be changed; if egid is -1, the 
effective group ID shall not be changed.
"""

I think passing -1 to os. setregid() should be supported.

Meanwhile the following work-around works for me on OSX, but may not work on 
other platforms:

>>> os.setregid(2**32-1,2**32-1)

--
nosy: +Alexander.Belopolsky

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5475] urllib2.getproxies not documented

[Senthil Kumaran]

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

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8022] Leak when creating certain classes that subclass ABCs

[Daniel Stutzbach]

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 iteration of the loop.  In Python 3.1, the number of 
objects remains fixed after the second iteration.  I don't have a Python 2.7 
branch handy to test.

The problem could lie in the C code or perhaps ABCMeta is keeping a reference?  
I'm not sure.

Cashew:~$ python2.6 leak.py
4842
4850
4858
4866
4874
4882
4890
4898
4906
4914

Cashew:~$ python3.1 leak.py
4286
4273
4273
4273
4273
4273
4273
4273
4273
4273

--
components: Interpreter Core, Library (Lib)
files: leak.py
messages: 100132
nosy: stutzbach
severity: normal
status: open
title: Leak when creating certain classes that subclass ABCs
type: resource usage
versions: Python 2.6
Added file: http://bugs.python.org/file16374/leak.py

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Asheesh Laroia]

Asheesh Laroia  added the comment:

Ryan -- would you take a further look at this?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8022] Leak when creating certain classes that subclass ABCs

[Benjamin Peterson]

Changes by Benjamin Peterson :


--
resolution:  -> duplicate
status: open -> closed
superseder:  -> ABC caches should use weak refs

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Matthew Barnett]

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.zip

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7994] object.__format__ should reject format strings

[Meador Inge]

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(w[0].message)/, since 
  BaseException.message was deprecated in 2.6.

I also have the following general comments:

   1. PEP 3101 explicitly defines the string conversion for 
  object.__format__.  What is the rationale behind this?  Should
  we find out before making this change?
   2. I don't think the comments in 'abstract.c' and 'typeobject.c'
  explaining that the warning will eventually become an error are
  needed.  I think it would be better to open separate issues for
  these migration steps as they can be tracked easier and will be 
  more visible.
   3. test_unicode, test_str have cases that trigger the added 
  warning.  Should they be altered now or when (if) this becomes 
  an error?

--
nosy: +minge
Added file: http://bugs.python.org/file16376/issue7994-3.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Pablo Mouzo]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com