[issue1108] Problem with doctest and decorated functions

[Daniel Larsson]

New submission from Daniel Larsson:

Seems like doctest won't recognize functions inside the module under
test are actually in that module, if the function is decorated by a
decorator that wraps the function in an externally defined function,
such as in this silly example:

# decorator.py
import functools

def simplelog(f):
@functools.wraps(f)
def new_f(*args, **kwds):
print "Wrapper calling func"
return f(*args, **kwds)
return new_f

# test.py
from decorator import simplelog

@simplelog
def test():
"""
This test should fail, since the decorator prints output.
Seems I don't get called though
>>> test()
'works!'
"""
return "works!"

if __name__ == '__main__':
import doctest
doctest.testmod()

--

The problem lies in DocTestFinder._from_module, which checks if the
function's func_globals attribute is the same as the module's __dict__
attribute.

I'd propose to do the __module__/inspect.getmodule() checks (aren't they
 both checking the same thing btw?) before the inspect.isfunction check.

--
components: Library (Lib)
messages: 55660
nosy: danilo
severity: normal
status: open
title: Problem with doctest and decorated functions
type: behavior
versions: Python 2.5

__
Tracker <[EMAIL PROTECTED]>

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

[issue786737] patch for build with read-only $srcdir

[Martin v. Löwis]

Martin v. Löwis added the comment:

Thanks for the patch. Committed as r57990 and r57991.

--
resolution:  -> accepted
status: open -> closed
versions: +Python 2.5, Python 2.6 -Python 2.3


Tracker <[EMAIL PROTECTED]>


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

[issue1684991] Explain __method__ lookup semantics for new-style classes

[Georg Brandl]

Georg Brandl added the comment:

Added a paragraph in rev. 57992, 57993.

--
resolution:  -> fixed
status: open -> closed

_
Tracker <[EMAIL PROTECTED]>

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

[issue1109] Warning required when calling register() on an ABCMeta subclass

[Mark Summerfield]

New submission from Mark Summerfield:

GvR asked me to add this to the bug tracker.

If you do this:

class A(ABCMeta): pass

A.register(list)

you get this error message:

Traceback (most recent call last):
File "", line 1, in 
RuntimeError: maximum recursion depth exceeded in __instancecheck__

This is not very helpful.

You probably meant to write:

class A(metaclass=ABCMeta): pass

Perhaps a warning message like this would be better:

"register() should not be called on an ABCMeta subclass; maybe you
forgot the metaclass keyword argument when declaring the class?"

--
components: Interpreter Core
messages: 55663
nosy: mark
severity: normal
status: open
title: Warning required when calling register() on an ABCMeta subclass
type: behavior
versions: Python 3.0

__
Tracker <[EMAIL PROTECTED]>

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

[issue1777530] ctypes on Solaris

[Martin v. Löwis]

Martin v. Löwis added the comment:

The patch looks fine to me (with the addition of checking for sunos5
instead). A few things to consider:
- you could check the system at import time, rather than call time, of
_get_soname()
- notice that the file is located in /usr/ccs/bin, which may not be
  in everybody's path. So using an explicit path would be better.
- Sun itself recommend dump(1) instead of elfdump(1) for use 
  in "shell scripts". "/usr/ccs/bin/elfdump -Lpv /lib/libc.so.1"
  gives output including the line "[6]\tSONAME  libc.so.1\n"

--
nosy: +loewis

_
Tracker <[EMAIL PROTECTED]>

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

[issue1110] Problems with the msi installer - python-3.0a1.msi

[Vlastimil Brom]

New submission from Vlastimil Brom:

I encountered problems installing python 3.0 alpha 1 from the MSI 
installer supplied on the python download page (python-3.0a1.msi). 
If the advanced option of the installer ("compile .py files to bytecode 
after installation") is checked - the following message is shown
"There is a problem with this Windows installer package. A program run 
as part of the setup did not finish as expected ..."
If I don't choose the option to compile files, the installation 
finishes without any visible errors.

The result is in both cases the same however. After calling python.exe 
it shows the version info etc. in the interactive prompt, but it 
doesn't "respond" in any way.
e.g.
>>> 1+1
object  : RuntimeError('lost sys.stdout',)
type: RuntimeError
refcount: 4
address : 00A65BD0
lost sys.stderr
>>> 

Running of any .py file doesn't work either.

My system is Win XPh SP2 Czech (the same on Win XPp SP2 Czech).

Could possibly the Czech windows version/ language setting/ locale/ 
timezone or whatever be the problem (as there were some problems 
reported with the manual compilation on German or Polish Winsows-
systems)?

Or am I missing something trivial?

Thanks,
 Vlastimil Brom

--
components: Windows
messages: 55665
nosy: vbr
severity: normal
status: open
title: Problems with the msi installer - python-3.0a1.msi
versions: Python 3.0

__
Tracker <[EMAIL PROTECTED]>

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

[issue1110] Problems with the msi installer - python-3.0a1.msi

[Martin v. Löwis]

Martin v. Löwis added the comment:

There are really two issues here; it is usually better to report them
separately, so they can be analyzed, fixed, and closed separately:
a) the compileall script apparently fails (not surprisingly so, I never
tested it for 3.0), and
b) Python does not work on your version of Windows.

Please confirm that you use the Python console, not IDLE.

As for issue b), yes, that's possibly a locale-related problem. How is
"Program Files" called in your installation? What target directory did
you set for Python?

--
nosy: +loewis

__
Tracker <[EMAIL PROTECTED]>

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

[issue978833] SSL-ed sockets don't close correct?

[Arkadiusz Miskiewicz Arkadiusz Miskiewicz]

Arkadiusz MiskiewiczArkadiusz Miskiewicz added the 
comment:

How to deal with this on python 2.5.x? I assume that msg21288 means that 
fakeclose.diff isn't good way for python 2.5.x.

Unfortunately there are web services that refuse to respond to second 
query if first wasn't properly ended (rare but I'm dealing with one).

--
nosy: +arekm


Tracker <[EMAIL PROTECTED]>


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

[issue978833] SSL-ed sockets don't close correct?

[Martin v. Löwis]

Martin v. Löwis added the comment:

For 2.5, it reverts to the state of 2.4. You'll have to find a
work-around on your own.


Tracker <[EMAIL PROTECTED]>


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

[issue1110] Problems with the msi installer - python-3.0a1.msi

[Vlastimil Brom]

Vlastimil Brom added the comment:

The path to the python executable on my system is:
"C:\Python30\python.exe"

The path to Program Files is "C:\Program Files", but it doesn't matter 
in that case, I guess.

And yes, I use the console window (i.e. the cmd window in Windows) - 
the IDLE doesn't run either, as all other .py files (using python 3.0).

__
Tracker <[EMAIL PROTECTED]>

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

[issue1777530] ctypes on Solaris

[Thomas Heller]

Thomas Heller added the comment:

Martin, here is a patch (solaris-2.patch), hopefully according to your
comments.

_
Tracker <[EMAIL PROTECTED]>

_Index: util.py
===
--- util.py	(revision 57929)
+++ util.py	(working copy)
@@ -66,16 +66,28 @@
 return None
 return res.group(0)
 
-def _get_soname(f):
-# assuming GNU binutils / ELF
-if not f:
-return None
-cmd = "objdump -p -j .dynamic 2>/dev/null " + f
-res = re.search(r'\sSONAME\s+([^\s]+)', os.popen(cmd).read())
-if not res:
-return None
-return res.group(1)
 
+if sys.platform == "sunos5":
+# use /usr/ccs/bin/dump on solaris
+def _get_soname(f):
+if not f:
+return None
+cmd = "/usr/ccs/bin/dump -Lpv 2>/dev/null " + f
+res = re.search(r'\[.*\]\sSONAME\s+([^\s]+)', os.popen(cmd).read())
+if not res:
+return None
+return res.group(1)
+else:
+def _get_soname(f):
+# assuming GNU binutils / ELF
+if not f:
+return None
+cmd = "objdump -p -j .dynamic 2>/dev/null " + f
+res = re.search(r'\sSONAME\s+([^\s]+)', os.popen(cmd).read())
+if not res:
+return None
+return res.group(1)
+
 if (sys.platform.startswith("freebsd")
 or sys.platform.startswith("openbsd")
 or sys.platform.startswith("dragonfly")):
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1111] Users' directories information

[Maciej Piechorka]

New submission from Maciej Piechorka:

User directories varies along systems. On unikses all user data is kept
in $HOME directory. Configuration is kept in dot-files. However on
others systems places are different.
Using predefined values would be most convinent.

--
components: Library (Lib)
messages: 55671
nosy: uzytkownik
severity: minor
status: open
title: Users' directories information
versions: Python 2.6

__
Tracker <[EMAIL PROTECTED]>

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

[issue1112] Test debug assertion in bsddb test_1413192.py

[David Bolen]

New submission from David Bolen:

The change made to Lib/bsddb/test/test_1413192.py to clean up temporary
files causes an abort in the DB library when trying to abort an open
transaction at object destruction type - currently when the Python
interpreter exits, because the transaction log file has been removed. 
In the Windows debug version this also causes an assertion pop-up dialog
window.  This has been seen on the 2.5 branch (r57311), trunk (r57286)
and py3k branch (57285).

The proposed change controls the object lifetime through a wrapper
object so the transaction object is destroyed before cleaning up the
filesystem.  It has the added benefit of permitting the filesystem
cleanup to work under Windows since the files are no longer in use.  The
test still generates a warning about a DBTxn aborted in destructor, but
does not abort the interpreter. 

I have tried testing this without the original (issue 1413192, r42177)
change to _bsddb that it was testing, but neither my modified version
nor the original seem to crash in my environment, so I can't say
absolutely whether or not the proposed change affects what the test was
originally designed to test.  I suspect subsequent changes to _bsddb.c
are perhaps also satisfying the original problem.

--
components: Tests
files: test_1413192.py.diff
messages: 55672
nosy: db3l
severity: normal
status: open
title: Test debug assertion in bsddb test_1413192.py
type: crash
versions: Python 2.5, Python 2.6, Python 3.0

__
Tracker <[EMAIL PROTECTED]>

__

test_1413192.py.diff
Description: Binary data
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1113] interrupt_main() fails to interrupt raw_input()

[Anand Patil]

New submission from Anand Patil:

Mac OS 10.4, Python 2.5 from pythonmac.org: The function listen() in the 
attached should be interrupted after a second, but it waits until return 
is pressed before  catching the exception.

--
components: Macintosh
files: test.py
messages: 55673
nosy: anand
severity: normal
status: open
title: interrupt_main() fails to interrupt raw_input()
type: behavior
versions: Python 2.5

__
Tracker <[EMAIL PROTECTED]>

__from thread import *
from threading import *
from time import *

def interrupt():
sleep(1)
print 'Interrupting main thread now'
interrupt_main()

def listen():
t = Thread(target=interrupt)
t.start()
try:
b = raw_input()
except KeyboardInterrupt:
print 'Exception caught'___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1101] Is there just no PRINT statement any more? Or it just doesn't work.

[Richard Katz]

Richard Katz added the comment:

"What's wrong with

py> for x in 1,2,3:print(x,end=" ")"
-
I'd like to suggest (for those of us just now focusing on Python 3.0) replacing 
the last 3 bullet points of the paragraph "Common Stumbling Blocks?" 
http://docs.python.org/dev/3.0/whatsnew/3.0.html

With the following simple reference:

"The print statement has been REMOVED and is replaced by a print() function. 
SEE PEP 3105." 

Rather than burying 3105 in the middle of "other language changes."  That would 
do a lot to clear it up.  

A) Especially I'd like to suggest getting rid of the quite cryptic: "You’ll be 
finding yourself typing print x a lot in interactive mode." I had no idea that 
was a *warning message - meaning "it won't work..." And 

B) The rather misleading - "Also, print and print (x, y)  behave differently 
without warning:"

They certainly do...   But not in the way explained. "print" now displays 
"" since it's a function...What they probably 
meant was print()? 

Where would I suggest (or make) these changes to What's New? Is there a Doc 
Wiki?

Thanks!

Regards,

Rich

-Original Message-
>From: "=?utf-8?q?Martin_v._L=C3=B6wis?=" <[EMAIL PROTECTED]>
>Sent: Sep 4, 2007 5:31 PM
>To: [EMAIL PROTECTED]
>Subject: [issue1101] Is there just no PRINT statement any more? Or it just 
>doesn't work.
>
>
>Martin v. Löwis added the comment:
>
>What's wrong with
>
>py> for x in 1,2,3:print(x,end=" ")
>...
>1 2 3
>
>Closing as invalid.
>
>--
>nosy: +loewis
>resolution:  -> invalid
>status: open -> closed
>
>__
>Tracker <[EMAIL PROTECTED]>
>
>__

__
Tracker <[EMAIL PROTECTED]>

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

[issue1114] _curses issues on 64-bit big-endian (e.g, AIX)

[Luke Mewburn]

New submission from Luke Mewburn:

Attempting to use curses attributes with python 2.3.5 on AIX (64bit
powerpc) doesn't work, and occasionally results in exceptions being raised.

_cursesmodule.c assumes that attr_t is a `long' and uses the "l"
decoding of PyArg_ParseTuple() to read values from python to C.  On
platforms where sizeof(int) == sizeof(long), this isn't a problem. 
However, on LP64, especially big-endian LP64, this results in the wrong
value being stored in the target address.

My solution is to use ParseTuple("l") into a variable with an explicit
type of 'long', and then assign that to the attr_t variable that the
underlying curses(3) functions are called with.

(I don't know if there's a different convention for dealing with reading
numbers from python into underlying C types where the C type size isn't
consistently an `int' or a `long', other that reading into an explicit
int/long and then assigning/casting to the final type)

The code in question doesn't appear to have changed much between python
2.3.5 and the svn trunk (as at 20070906), and my patch for the former
applied fairly cleanly to my checkout of the latter.  I've attached a
diff from the svn checkout.

--
components: Extension Modules
files: curses-attr_t-long.diff
messages: 55675
nosy: lukemewburn
severity: normal
status: open
title: _curses issues on 64-bit big-endian (e.g, AIX)
type: behavior
versions: Python 2.3

__
Tracker <[EMAIL PROTECTED]>

__Index: Modules/_cursesmodule.c
===
--- Modules/_cursesmodule.c	(revision 57996)
+++ Modules/_cursesmodule.c	(working copy)
@@ -315,9 +315,6 @@
 Window_NoArg2TupleReturnFunction(getmaxyx, int, "ii")
 Window_NoArg2TupleReturnFunction(getparyx, int, "ii")
 
-Window_OneArgNoReturnFunction(wattron, attr_t, "l;attr")
-Window_OneArgNoReturnFunction(wattroff, attr_t, "l;attr")
-Window_OneArgNoReturnFunction(wattrset, attr_t, "l;attr")
 Window_OneArgNoReturnFunction(clearok, int, "i;True(1) or False(0)")
 Window_OneArgNoReturnFunction(idlok, int, "i;True(1) or False(0)")
 #if defined(__NetBSD__)
@@ -372,6 +369,7 @@
   PyObject *temp;
   chtype ch = 0;
   attr_t attr = A_NORMAL;
+  long lattr;
   
   switch (PyTuple_Size(args)) {
   case 1:
@@ -379,8 +377,9 @@
 	  return NULL;
 break;
   case 2:
-if (!PyArg_ParseTuple(args, "Ol;ch or int,attr", &temp, &attr))
+if (!PyArg_ParseTuple(args, "Ol;ch or int,attr", &temp, &lattr))
   return NULL;
+attr = lattr;
 break;
   case 3:
 if (!PyArg_ParseTuple(args,"iiO;y,x,ch or int", &y, &x, &temp))
@@ -389,8 +388,9 @@
 break;
   case 4:
 if (!PyArg_ParseTuple(args,"iiOl;y,x,ch or int, attr", 
-		 &y, &x, &temp, &attr))
+		 &y, &x, &temp, &lattr))
   return NULL;
+attr = lattr;
 use_xy = TRUE;
 break;
   default:
@@ -418,6 +418,7 @@
   int x, y;
   char *str;
   attr_t attr = A_NORMAL , attr_old = A_NORMAL;
+  long lattr;
   int use_xy = FALSE, use_attr = FALSE;
 
   switch (PyTuple_Size(args)) {
@@ -426,8 +427,9 @@
   return NULL;
 break;
   case 2:
-if (!PyArg_ParseTuple(args,"sl;str,attr", &str, &attr))
+if (!PyArg_ParseTuple(args,"sl;str,attr", &str, &lattr))
   return NULL;
+attr = lattr;
 use_attr = TRUE;
 break;
   case 3:
@@ -436,8 +438,9 @@
 use_xy = TRUE;
 break;
   case 4:
-if (!PyArg_ParseTuple(args,"iisl;int,int,str,attr", &y, &x, &str, &attr))
+if (!PyArg_ParseTuple(args,"iisl;int,int,str,attr", &y, &x, &str, &lattr))
   return NULL;
+attr = lattr;
 use_xy = use_attr = TRUE;
 break;
   default:
@@ -464,6 +467,7 @@
   int rtn, x, y, n;
   char *str;
   attr_t attr = A_NORMAL , attr_old = A_NORMAL;
+  long lattr;
   int use_xy = FALSE, use_attr = FALSE;
 
   switch (PyTuple_Size(args)) {
@@ -472,8 +476,9 @@
   return NULL;
 break;
   case 3:
-if (!PyArg_ParseTuple(args,"sil;str,n,attr", &str, &n, &attr))
+if (!PyArg_ParseTuple(args,"sil;str,n,attr", &str, &n, &lattr))
   return NULL;
+attr = lattr;
 use_attr = TRUE;
 break;
   case 4:
@@ -482,8 +487,9 @@
 use_xy = TRUE;
 break;
   case 5:
-if (!PyArg_ParseTuple(args,"iisil;y,x,str,n,attr", &y, &x, &str, &n, &attr))
+if (!PyArg_ParseTuple(args,"iisil;y,x,str,n,attr", &y, &x, &str, &n, &lattr))
   return NULL;
+attr = lattr;
 use_xy = use_attr = TRUE;
 break;
   default:
@@ -510,6 +516,7 @@
   PyObject *temp;
   chtype bkgd;
   attr_t attr = A_NORMAL;
+  long lattr;
 
   switch (PyTuple_Size(args)) {
 case 1:
@@ -517,8 +524,9 @@
 return NULL;
   break;
 case 2:
-  if (!PyArg_ParseTuple(args,"Ol;ch or int,attr", &temp, &attr))
+  if (!PyArg_ParseTuple(args,"Ol;ch or int,attr", &temp, &lattr))
 return NULL;
+  attr = lattr;
   break;
 default:
   PyErr_SetString(PyExc_TypeError, "bkgd requires 1

[issue1111] Users' directories information

[Martin v. Löwis]

Martin v. Löwis added the comment:

Can you please elaborate? What does that have to do with Python?

--
nosy: +loewis

__
Tracker <[EMAIL PROTECTED]>

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

[issue1112] Test debug assertion in bsddb test_1413192.py

[Martin v. Löwis]

Changes by Martin v. Löwis:


--
keywords: +patch

__
Tracker <[EMAIL PROTECTED]>

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

[issue1101] Is there just no PRINT statement any more? Or it just doesn't work.

[Martin v. Löwis]

Martin v. Löwis added the comment:

A plain "print" only results in output of "" in
interactive mode, as interactive mode will not only perform the action,
but also display the result. In a Python script, a plain "print" will
have no effect.

Guido, can you take a look at the proposed "what's new" changes?

--
assignee:  -> gvanrossum
components: +Documentation -Interpreter Core
nosy: +gvanrossum
resolution: invalid -> 
status: closed -> open

__
Tracker <[EMAIL PROTECTED]>

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

[issue1115] Minor Change For Better cross compile

[Zhang Zengbo]

New submission from Zhang Zengbo:

Some test in configure.in is AC_TRY_RUN, which can be replaced by
AC_TRY_COMPILE, achieve the same goal and give better support for cross
compiling.  This patch is for svn reversion 57996.

--
files: autocheck.patch
messages: 55678
nosy: zengbo
severity: minor
status: open
title: Minor Change For Better cross compile
versions: Python 2.6

__
Tracker <[EMAIL PROTECTED]>

__Index: configure.in
===
--- configure.in	（版本 57996）
+++ configure.in	（工作副本）
@@ -802,10 +802,10 @@
 AC_MSG_CHECKING(whether $CC accepts -fno-strict-aliasing)
  ac_save_cc="$CC"
  CC="$CC -fno-strict-aliasing"
- AC_TRY_RUN([int main() { return 0; }],
+ AC_TRY_COMPILE([],[int main() { return 0; }],
  ac_cv_no_strict_aliasing_ok=yes,
  ac_cv_no_strict_aliasing_ok=no,
- ac_cv_no_strict_aliasing_ok=no)
+ )
  CC="$ac_save_cc"
 AC_MSG_RESULT($ac_cv_no_strict_aliasing_ok)
 if test $ac_cv_no_strict_aliasing_ok = yes
@@ -866,10 +866,10 @@
 AC_CACHE_VAL(ac_cv_opt_olimit_ok,
 [ac_save_cc="$CC"
 CC="$CC -OPT:Olimit=0"
-AC_TRY_RUN([int main() { return 0; }],
+AC_TRY_COMPILE([],[int main() { return 0; }],
   ac_cv_opt_olimit_ok=yes,
   ac_cv_opt_olimit_ok=no,
-  ac_cv_opt_olimit_ok=no)
+  )
 CC="$ac_save_cc"])
 AC_MSG_RESULT($ac_cv_opt_olimit_ok)
 if test $ac_cv_opt_olimit_ok = yes; then
@@ -888,10 +888,10 @@
   AC_CACHE_VAL(ac_cv_olimit_ok,
   [ac_save_cc="$CC"
   CC="$CC -Olimit 1500"
-  AC_TRY_RUN([int main() { return 0; }],
+  AC_TRY_COMPILE([],[int main() { return 0; }],
 ac_cv_olimit_ok=yes,
 ac_cv_olimit_ok=no,
-ac_cv_olimit_ok=no)
+)
   CC="$ac_save_cc"])
   AC_MSG_RESULT($ac_cv_olimit_ok)
   if test $ac_cv_olimit_ok = yes; then
@@ -3444,6 +3444,7 @@
 }],
 [AC_MSG_RESULT(yes)
  AC_DEFINE(PY_FORMAT_SIZE_T, "z", [Define to printf format modifier for Py_ssize_t])],
+ AC_MSG_RESULT(no),
  AC_MSG_RESULT(no))
 
 AC_CHECK_TYPE(socklen_t,,
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1112] Test debug assertion in bsddb test_1413192.py

[Martin v. Löwis]

Martin v. Löwis added the comment:

Greg, can you take a look? If not, please unassign.

--
assignee:  -> gregory.p.smith
nosy: +gregory.p.smith, loewis

__
Tracker <[EMAIL PROTECTED]>

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