[issue1268] array unittest problems with UCS4 build

[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

[issue1269] Exception in pstats print_callers()

[Andrew Stromnov]

New submission from Andrew Stromnov:

Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import pstats
>>> ps = pstats.Stats("profile.log")
>>> ps.add("profile.log")

>>> ps.print_callers()
   Random listing order was used

{method 'append' of 'list' objects}
   <-
Traceback (most recent call last):
  File "", line 1, in 
  File "C:\Python25\lib\pstats.py", line 388, in print_callers
self.print_call_line(width, func, callers, "<-")
  File "C:\Python25\lib\pstats.py", line 417, in print_call_line
nc, cc, tt, ct = value
ValueError: too many values to unpack

--
components: Library (Lib)
files: profile.log
messages: 56358
nosy: stromnov
severity: normal
status: open
title: Exception in pstats print_callers()
type: crash
versions: Python 2.5

__
Tracker <[EMAIL PROTECTED]>

__

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

[issue1216] Python2.5.1 fails to compile under VC.NET2002 ( 7.0 )

[Martin v. Löwis]

Martin v. Löwis added the comment:

The actual change that broke that was r41672, which added the ULL
suffix. r46064 fixed it for VC6 and embedded VC.

Raising the minimum _MSC_VER to above 1300 is fine (VC 7.1 is 1310).

I personally can't test with VS 2002 anymore, so I have to trust that it
doesn't support the suffix, and that it's value of _MSC_VER is 1300.

__
Tracker <[EMAIL PROTECTED]>

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

[issue1216] Python2.5.1 fails to compile under VC.NET2002 ( 7.0 )

[Martin v. Löwis]

Martin v. Löwis added the comment:

Thanks for the report. This is now fixed in r58430 and r584301

__
Tracker <[EMAIL PROTECTED]>

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

[issue1216] Python2.5.1 fails to compile under VC.NET2002 ( 7.0 )

[Martin v. Löwis]

Changes by Martin v. Löwis:


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

[issue1271] Raw string parsing fails with backslash as last character

[Tim Gordon]

New submission from Tim Gordon:

If you have a raw string with a backslash as the last character, the 
parser thinks the following quote, actually used to mark the end of the 
string, is being quoted by the backslash.  For example, r'\' should be 
the string with one backslash, but...

>>> print r'\'
SyntaxError: EOL while scanning single-quoted string

There seems to have been a fix added to python 3.0 (see issue 1720390), 
but it doesn't look like it's been backtracked into any earlier version.

--
components: Interpreter Core
messages: 56370
nosy: QuantumTim
severity: normal
status: open
title: Raw string parsing fails with backslash as last character
versions: Python 2.4, 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

[issue1270] MemoryError when working on large dictionaries on Windows 2003 Server

[Martin v. Löwis]

Martin v. Löwis added the comment:

I personally don't think this problem can be resolved by discussion.
Instead, you have to use a debugger, debug your application, Python, and
Windows, to find out the true cause of the problem. Only then discussion
can be fruitful.

If you cannot do these steps yourself, consider hiring somebody for you
who can.

If you still want to discuss, try python-list.

__
Tracker <[EMAIL PROTECTED]>

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

[issue1270] MemoryError when working on large dictionaries on Windows 2003 Server

[Martin v. Löwis]

Martin v. Löwis added the comment:

> I set the IMAGE_FILE_LARGE_ADDRESS_AWARE flag on python and I still get the
> memoryerror exceptions. When they start happening there is still more than
> 1GB of available memory!

Just in case it isn't clear: I still don't see an indication of a bug in
Python here. If Python reports MemoryError, it likely means that the
system has refused to provide Python with more memory, whether or not
it has memory available for other purposes.

Martin

__
Tracker <[EMAIL PROTECTED]>

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

[issue1272] Decode __file__ and co_filename to unicode using fs default

[Christian Heimes]

New submission from Christian Heimes:

I'm sending the patch in for review.

--
components: Interpreter Core
files: py3k_file_fsenc2.patch
messages: 56374
nosy: tiran
severity: normal
status: open
title: Decode __file__ and co_filename to unicode using fs default
versions: Python 3.0

__
Tracker <[EMAIL PROTECTED]>

__Index: Python/pythonrun.c
===
--- Python/pythonrun.c	(revision 58412)
+++ Python/pythonrun.c	(working copy)
@@ -867,7 +867,8 @@
 		return -1;
 	d = PyModule_GetDict(m);
 	if (PyDict_GetItemString(d, "__file__") == NULL) {
-		PyObject *f = PyString_FromString(filename);
+		PyObject *f;
+		f = PyUnicode_DecodeFSDefault(filename, 0, NULL);
 		if (f == NULL)
 			return -1;
 		if (PyDict_SetItemString(d, "__file__", f) < 0) {
Index: Python/import.c
===
--- Python/import.c	(revision 58412)
+++ Python/import.c	(working copy)
@@ -652,7 +652,7 @@
 	/* Remember the filename as the __file__ attribute */
 	v = NULL;
 	if (pathname != NULL) {
-		v = PyString_FromString(pathname);
+		v = PyUnicode_DecodeFSDefault(pathname, 0, NULL);
 		if (v == NULL)
 			PyErr_Clear();
 	}
@@ -983,7 +983,7 @@
 		PySys_WriteStderr("import %s # directory %s\n",
 			name, pathname);
 	d = PyModule_GetDict(m);
-	file = PyString_FromString(pathname);
+	file = PyUnicode_DecodeFSDefault(pathname, 0, NULL);
 	if (file == NULL)
 		goto error;
 	path = Py_BuildValue("[O]", file);
Index: Python/compile.c
===
--- Python/compile.c	(revision 58412)
+++ Python/compile.c	(working copy)
@@ -4001,7 +4001,7 @@
 	freevars = dict_keys_inorder(c->u->u_freevars, PyTuple_Size(cellvars));
 	if (!freevars)
 	goto error;
-	filename = PyString_FromString(c->c_filename);
+	filename = PyUnicode_DecodeFSDefault(c->c_filename, 0, NULL);
 	if (!filename)
 		goto error;
 
Index: Python/importdl.c
===
--- Python/importdl.c	(revision 58412)
+++ Python/importdl.c	(working copy)
@@ -62,7 +62,9 @@
 		return NULL;
 	}
 	/* Remember the filename as the __file__ attribute */
-	if (PyModule_AddStringConstant(m, "__file__", pathname) < 0)
+	PyObject *path;
+	path = PyUnicode_DecodeFSDefault(pathname, 0, NULL);
+	if (PyModule_AddObject(m, "__file__", path) < 0)
 		PyErr_Clear(); /* Not important enough to report */
 
 	if (_PyImport_FixupExtension(name, pathname) == NULL)
Index: Include/unicodeobject.h
===
--- Include/unicodeobject.h	(revision 58412)
+++ Include/unicodeobject.h	(working copy)
@@ -154,6 +154,7 @@
 # define PyUnicode_DecodeASCII PyUnicodeUCS2_DecodeASCII
 # define PyUnicode_DecodeCharmap PyUnicodeUCS2_DecodeCharmap
 # define PyUnicode_DecodeLatin1 PyUnicodeUCS2_DecodeLatin1
+# define PyUnicode_DecodeFSDefault PyUnicodeUCS2_DecodeFSDefault
 # define PyUnicode_DecodeRawUnicodeEscape PyUnicodeUCS2_DecodeRawUnicodeEscape
 # define PyUnicode_DecodeUTF32 PyUnicodeUCS2_DecodeUTF32
 # define PyUnicode_DecodeUTF32Stateful PyUnicodeUCS2_DecodeUTF32Stateful
@@ -245,6 +246,7 @@
 # define PyUnicode_DecodeASCII PyUnicodeUCS4_DecodeASCII
 # define PyUnicode_DecodeCharmap PyUnicodeUCS4_DecodeCharmap
 # define PyUnicode_DecodeLatin1 PyUnicodeUCS4_DecodeLatin1
+# define PyUnicode_DecodeFSDefault PyUnicodeUCS4_DecodeFSDefault
 # define PyUnicode_DecodeRawUnicodeEscape PyUnicodeUCS4_DecodeRawUnicodeEscape
 # define PyUnicode_DecodeUTF32 PyUnicodeUCS4_DecodeUTF32
 # define PyUnicode_DecodeUTF32Stateful PyUnicodeUCS4_DecodeUTF32Stateful
@@ -641,6 +643,25 @@
 PyAPI_FUNC(PyObject *) _PyUnicode_AsDefaultEncodedString(
 PyObject *, const char *);
 
+/* Decode a string to a Python unicode object using either
+   Py_FileSystemDefaultEncoding or UTF-8 if the default encoding isn't given.
+
+   The function is intended to be used for paths and file names only. It
+   doesn't use the codecs module and PyUnicode_Decode() since it is required
+   during boot strapping and before the codecs are set up. For that reason
+   the default fs encoding should be UTF-8, UTF-16, UTF-32, Latin-1 or MBCS.
+
+   In case the length paramenter is 0 the length of string is autodetected
+   with strlen(string). errors must be set to NULL.
+*/
+
+PyAPI_FUNC(PyObject*) PyUnicode_DecodeFSDefault(
+const char *string, 	/* encoded string */
+Py_ssize_t length,	 	/* size of string */
+const char *errors		/* error handling */
+);
+
+
 /* Return a char* holding the UTF-8 encoded value of the
Unicode object.
 
Index: setup.py
===
--- setup.py	(revision 58412)
+++ setup.py	(working copy)
@@ -414,7 +414,6 @@
 # Python C API test module
 exts.append( Extension('_testcapi', ['_testcapimodu

[issue1251] ssl module doesn't support non-blocking handshakes

[Chris Stawarz]

Chris Stawarz added the comment:

> The loop in _ssl.c/do_handshake will never return WANT_READ or
> WANT_WRITE, so the loop in the test case, for instance, is  
> unnecessary.

I don't know why you think that, but it's easy enough to show that  
this statement is incorrect.  I've attached two scripts  
(nonblocking_handshake.py and blocking_handshake.py).  The first does  
basically the same thing as my test case, but connecting to a  
different server and with some print statements added.  Here's the  
output I get when I run it using an up-to-date trunk checkout with my  
patch applied:

$ ../build/bin/python2.6 nonblocking_handshake.py
starting handshake
need read
need read
need read
handshake complete

The second reproduces the situation that led me to file this bug  
report in the first place.  Here's what happens when I run it with an  
*unpatched* trunk build:

$ ../build/bin/python2.6 blocking_handshake.py
starting handshake
need read
Traceback (most recent call last):
   File "blocking_handshake.py", line 14, in 
 s = ssl.wrap_socket(s,cert_reqs=ssl.CERT_NONE)
   File "/Users/cstawarz/Documents/Code/Python/svn/build/lib/ 
python2.6/ssl.py", line 466, in wrap_socket
 ssl_version=ssl_version, ca_certs=ca_certs)
   File "/Users/cstawarz/Documents/Code/Python/svn/build/lib/ 
python2.6/ssl.py", line 103, in __init__
 cert_reqs, ssl_version, ca_certs)
ssl.SSLError: [Errno 1] _ssl.c:429: error:04077068:rsa  
routines:RSA_verify:bad signature

As you see, in both cases the handshaking fails with  
SSL_ERROR_WANT_READ.  But without the fixes introduced by my patch,  
there's no way to handle the error.

__
Tracker <[EMAIL PROTECTED]>

__import select
import socket
import ssl


s = ssl.wrap_socket(socket.socket(socket.AF_INET),
cert_reqs=ssl.CERT_NONE,
do_handshake_on_connect=False)

s.connect(('people.csail.mit.edu', 443))
s.setblocking(False)

print 'starting handshake'

while True:
try:
s.do_handshake()
break
except ssl.SSLError, err:
if err.args[0] == ssl.SSL_ERROR_WANT_READ:
print 'need read'
select.select([s], [], [])
elif err.args[0] == ssl.SSL_ERROR_WANT_WRITE:
print 'need write'
select.select([], [s], [])
else:
raise

print 'handshake complete'
s.close()

import select
import socket
import ssl


s = socket.socket(socket.AF_INET)
s.connect(('people.csail.mit.edu', 443))
s.setblocking(False)

print 'starting handshake'

while True:
try:
s = ssl.wrap_socket(s, cert_reqs=ssl.CERT_NONE)
break
except ssl.SSLError, err:
if err.args[0] == ssl.SSL_ERROR_WANT_READ:
print 'need read'
select.select([s], [], [])
elif err.args[0] == ssl.SSL_ERROR_WANT_WRITE:
print 'need write'
select.select([], [s], [])
else:
raise

print 'handshake complete'
s.close()

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

[issue1251] ssl module doesn't support non-blocking handshakes

[Bill Janssen]

Bill Janssen added the comment:

Chris,

Looking at this a bit harder, I don't see that it accomplishes much.  
The loop in _ssl.c/do_handshake will never return WANT_READ or 
WANT_WRITE, so the loop in the test case, for instance, is unnecessary.  
The original code handled the non-blocking case just fine.  I think this 
fix is unnecessary.

__
Tracker <[EMAIL PROTECTED]>

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

[issue1233] bsddb.dbshelve.DbShelf.append doesn't work

[Gregory P. Smith]

Gregory P. Smith added the comment:

heh yep that does look like a bug.  Laughing at that one goes well with
this comment currently in test_dbshelve.py:

# TODO:  Add test cases for a DBShelf in a RECNO DB.

i'll fix it. :)

__
Tracker <[EMAIL PROTECTED]>

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

[issue1273] email module example email-unpack.py error

[Ed Vinyard]

New submission from Ed Vinyard:

In the email module example, email-unpack.py
(http://docs.python.org/lib/email-unpack.txt), line 56 throws an
AttributeError.  It is currently

ext = mimetypes.guess_extension(part.get_type())

I think this line should be

ext = mimetypes.guess_extension(part.get_content_type())

The Message documentation
(http://docs.python.org/lib/module-email.message.html) mentions that
"Changed in version 2.5: The previously deprecated methods get_type(),
get_main_type(), and get_subtype() were removed."

--
components: Documentation
messages: 56376
nosy: esv
severity: minor
status: open
title: email module example email-unpack.py error
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

[issue1271] Raw string parsing fails with backslash as last character

[Tim Gordon]

Tim Gordon added the comment:

So basically raw strings are useless if you need to end a string with a 
backslash, as there is no way to quote the backslash to make it not do 
this...  This surely can't be too hard to "fix" if one considers it a 
problem (which I do), and just because even the docs say it is the 
correct behaviour, doesn't mean it should be.  Perhaps this has been 
debated before (and if so, where?), but it does seem rather odd behaviour.

__
Tracker <[EMAIL PROTECTED]>

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

[issue1272] Decode __file__ and co_filename to unicode using fs default

[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

[issue1274] doctest fails to run file based tests with 8bit paths

[Mike Taylor]

New submission from Mike Taylor:

In our builds the included patch fixes this issue.

Patch by Brian Kirsch, tested at OSAF on Python 2.5.1

--
nosy: +bear

__
Tracker <[EMAIL PROTECTED]>

__

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

[issue1270] MemoryError when working on large dictionaries on Windows 2003 Server

[Andre M. Descombes]

Andre M. Descombes added the comment:

Thanks Martin,

I think you are right, perhaps someone on the python-list will have seen and
solved the problem before.

Andre

__
Tracker <[EMAIL PROTECTED]>

__Thanks Martin,I think you are right, perhaps someone on the python-list 
will have seen and solved the problem before.Andre

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

[issue1270] MemoryError when working on large dictionaries on Windows 2003 Server

[Andre M. Descombes]

Andre M. Descombes added the comment:

I set the IMAGE_FILE_LARGE_ADDRESS_AWARE flag on python and I still get the
memoryerror exceptions. When they start happening there is still more than
1GB of available memory!

__
Tracker <[EMAIL PROTECTED]>

__I set the IMAGE_FILE_LARGE_ADDRESS_AWARE flag on python and I still get the 
memoryerror exceptions. When they start happening there is still more than 1GB 
of available memory!

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

[issue1270] MemoryError when working on large dictionaries on Windows 2003 Server

[Martin v. Löwis]

Martin v. Löwis added the comment:

No, Python does not have IMAGE_FILE_LARGE_ADDRESS_AWARE set; that's not
a bug, though.

In any case, the lack of this flag cannot explain why your application
works on Windows XP and not on Windows 2003.

__
Tracker <[EMAIL PROTECTED]>

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

[issue1270] MemoryError when working on large dictionaries on Windows 2003 Server

[Andre M. Descombes]

Andre M. Descombes added the comment:

Martin,

it is really a bug, as I have tried on a machine with Windows 2003 server
and 4GBs of ram and it still doesn't run, and it does run on xp with only
1GB of ram.
Does python.exe have then IMAGE_FILE_LARGE_ADDRESS_AWARE bit set, that could
explain the behaviour it its not set.

Thanks,

Andre M. Descombes

On 10/12/07, Martin v. Löwis <[EMAIL PROTECTED]> wrote:
>
>
> Martin v. Löwis added the comment:
>
> Please understand that the purpose of this bug tracker is to track bug
> reports and patches to Python, not a means of getting help in using
> Python. If you think you have found a bug, please submit a bug report
> that allows us to reproduce the bug. If you merely need help, please use
> some of the Python community channels, such as [EMAIL PROTECTED]
>
> As for your question: I'm not aware of an issue with Windows 2003 server
> that could explain that behavior. Most likely, you get the MemoryError
> because you really ran out of memory. Try increasing the page file, and
> put more main memory into the machine.
>
> --
> nosy: +loewis
> resolution:  -> invalid
>
> __
> Tracker <[EMAIL PROTECTED]>
> 
> __
>

__
Tracker <[EMAIL PROTECTED]>

__Martin,it is really a bug, as I have tried on a machine with Windows 
2003 server and 4GBs of ram and it still doesn't run, and it does run on xp 
with only 1GB of ram. Does python.exe have then 
IMAGE_FILE_LARGE_ADDRESS_AWARE bit set, that could explain the behaviour it its 
not set.
Thanks,Andre M. DescombesOn 10/12/07, Martin v. 
Löwis [EMAIL PROTECTED]> 
wrote:
Martin v. Löwis 
added the comment:Please understand that the purpose of this bug 
tracker is to track bug
reports and patches to Python, not a means of getting help in 
usingPython. If you think you have found a bug, please submit a bug 
reportthat allows us to reproduce the bug. If you merely need help, please 
use
some of the Python community channels, such as mailto:[EMAIL 
PROTECTED]">[EMAIL PROTECTED].As for your question: I'm not 
aware of an issue with Windows 2003 serverthat could explain that behavior. 
Most likely, you get the MemoryError
because you really ran out of memory. Try increasing the page file, 
andput more main memory into the machine.--nosy: 
+loewisresolution:  -> 
invalid__
Tracker [EMAIL 
PROTECTED]>http://bugs.python.org/issue1270>__


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

[issue1270] MemoryError when working on large dictionaries on Windows 2003 Server

[Martin v. Löwis]

Changes by Martin v. Löwis:


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

[issue1270] MemoryError when working on large dictionaries on Windows 2003 Server

[Martin v. Löwis]

Martin v. Löwis added the comment:

Please understand that the purpose of this bug tracker is to track bug
reports and patches to Python, not a means of getting help in using
Python. If you think you have found a bug, please submit a bug report
that allows us to reproduce the bug. If you merely need help, please use
some of the Python community channels, such as [EMAIL PROTECTED]

As for your question: I'm not aware of an issue with Windows 2003 server
that could explain that behavior. Most likely, you get the MemoryError
because you really ran out of memory. Try increasing the page file, and
put more main memory into the machine.

--
nosy: +loewis
resolution:  -> invalid

__
Tracker <[EMAIL PROTECTED]>

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

[issue1270] MemoryError when working on large dictionaries on Windows 2003 Server

[Andre M. Descombes]

New submission from Andre M. Descombes:

Hi everybody,

I am using Python 2.5.1.
I am creating a rather large dictionnary, with more than 8 million
entries, memory usage should be about 1.5GB. If I run the program on
Windows XP all runs fine, if I run the program on Windows Server 2003 I
start getting MemoryError exceptions around the 1GB boundary.
Is there a known issue with Windows 2003 Server?

Thanks,

André M. Descombes

--
components: Interpreter Core
messages: 56361
nosy: amdescombes
severity: critical
status: open
title: MemoryError when working on large dictionaries on Windows 2003 Server
type: resource usage
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

[issue1271] Raw string parsing fails with backslash as last character

[Georg Brandl]

Georg Brandl added the comment:

There's more to allowing \ at the end of a raw string: if you do that,
the raw string will end at the first quote character which is the same
as the opening one, so you can't put such a quote character into a raw
string anymore. At the moment, you can, by escaping it with a backslash,
though the backslash is left in the string.

There are basically two main uses for raw strings: Windows path names
and regular expressions. The current situation is optimal for the
latter: you can put both quote characters in a raw string, and the
backslash needed to quote the "string quote" being retained is not a
problem.

--
nosy: +georg.brandl

__
Tracker <[EMAIL PROTECTED]>

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

[issue1268] array unittest problems with UCS4 build

[Christian Heimes]

Christian Heimes added the comment:

svn annotate shows that you implemented the 'w' typecode in revision
57181. What do you think about my patch and my proposal?

--
nosy: +teoliphant

__
Tracker <[EMAIL PROTECTED]>

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

[issue1270] MemoryError when working on large dictionaries on Windows 2003 Server

[Andre M. Descombes]

Andre M. Descombes added the comment:

Apparently, XP is more lax when it comes to checking this flag on the
programs it runs then Windows 2003 Server. I am currently doing a test where
I have manually added the flag to python to see if this makes the problem go
away. I will post my results as soon as I have them.

Andre M. Descombes

__
Tracker <[EMAIL PROTECTED]>

__Apparently, XP is more lax when it comes to checking this flag on the programs 
it runs then Windows 2003 Server. I am currently doing a test where I have 
manually added the flag to python to see if this makes the problem go away. I 
will post my results as soon as I have them.
Andre M. Descombes

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

[issue1271] Raw string parsing fails with backslash as last character

[Facundo Batista]

Facundo Batista added the comment:

As stated in the docs...
  http://docs.python.org/dev/reference/lexical_analysis.html#string-literals

  r"\" is not a valid string literal (even a raw string cannot 
  end in an odd number of backslashes).  Specifically, a raw 
  string cannot end in a single backslash (since the backslash 
  would escape the following quote character).

--
nosy: +facundobatista
resolution:  -> invalid
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

[issue1270] MemoryError when working on large dictionaries on Windows 2003 Server

[Andre M. Descombes]

Andre M. Descombes added the comment:

Ok, so where would you recommend I move this discussion to?

Andre

On 10/12/07, Martin v. Löwis <[EMAIL PROTECTED]> wrote:
>
>
> Martin v. Löwis added the comment:
>
> > I set the IMAGE_FILE_LARGE_ADDRESS_AWARE flag on python and I still get
> the
> > memoryerror exceptions. When they start happening there is still more
> than
> > 1GB of available memory!
>
> Just in case it isn't clear: I still don't see an indication of a bug in
> Python here. If Python reports MemoryError, it likely means that the
> system has refused to provide Python with more memory, whether or not
> it has memory available for other purposes.
>
> Martin
>
> __
> Tracker <[EMAIL PROTECTED]>
> 
> __
>

__
Tracker <[EMAIL PROTECTED]>

__Ok, so where would you recommend I move this discussion 
to?AndreOn 10/12/07, Martin v. Löwis [EMAIL PROTECTED]
> wrote:Martin v. Löwis added the comment:> I set the 
IMAGE_FILE_LARGE_ADDRESS_AWARE flag on python and I still get the
> memoryerror exceptions. When they start happening there is still more 
than> 1GB of available memory!Just in case it isn't clear: I 
still don't see an indication of a bug inPython here. If Python reports 
MemoryError, it likely means that the
system has refused to provide Python with more memory, whether or notit 
has memory available for other 
purposes.Martin__Tracker 

[EMAIL PROTECTED]>http://bugs.python.org/issue1270>__

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

[issue1275] bsddb closing a DB object before all DBCursors using it are closed crashes

[Gregory P. Smith]

New submission from Gregory P. Smith:

If a bsddb.db.DB object is closed before any DBCursor objects
referencing it are closed, python will crash when the cursors are closed
or deleted.

Workaround: never close a database with open cursors.  this is annoying
in unittest code where a tearDown method closes the DB in the exception
handling path on a test failure before the cursors have been closed or
garbage collected.

I've got a test in my sandbox, I'll check it in with the fix as its a
crasher otherwise.

--
assignee: gregory.p.smith
components: Extension Modules
messages: 56383
nosy: gregory.p.smith
severity: normal
status: open
title: bsddb closing a DB object before all DBCursors using it are closed 
crashes
type: crash

__
Tracker <[EMAIL PROTECTED]>

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

[issue1233] bsddb.dbshelve.DbShelf.append doesn't work

[Gregory P. Smith]

Gregory P. Smith added the comment:

Fixed in python trunk r58434, release25-maint r58435, py3k r58438

--
resolution:  -> fixed
status: open -> closed
versions: +Python 2.6, 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

[issue1274] doctest fails to run file based tests with 8bit paths

[Mike Taylor]

Changes by Mike Taylor:


--
components: Tests
severity: major
status: open
title: doctest fails to run file based tests with 8bit paths
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

[issue1274] doctest fails to run file based tests with 8bit paths

[Brett Cannon]

Changes by Brett Cannon:


--
keywords: +patch

__
Tracker <[EMAIL PROTECTED]>

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

[issue1580738] httplib hangs reading too much data

[Marcos Dione]

Marcos Dione added the comment:

with facundo we were tracking this bug down. mhammond is right about 
that read() should allow 0 size responses, but the bug is that the 
response is "not closed". HTTPResponse.read() says:

if amt is None:
# unbounded read
if self.length is None:
s = self.fp.read()
else:
s = self._safe_read(self.length)
self.length = 0
self.close()# we read everything
return s

see that if self.close()s, which really closes the fp created with 
makefile() in the constructor. this does not closes the underlying 
socket, as you can see trying this short example:

import httplib

c= httplib.HTTPConnection ('www.python.org', 80)

c.request ('GET', '/index.html')
a1= c.getresponse ()
data1= a1.read()

c.request ('GET', '/404.html')
a2= c.getresponse ()
data2= a2.read()

and run it under strace -e network,file.

if the last part of read is changed to this, read(n) works just like 
read() does:

# we do not use _safe_read() here because this may be 
a .will_close
# connection, and the user is reading more bytes than will be 
provided
# (for example, reading in 1k chunks)
s = self.fp.read(amt)
if self.length is not None:
self.length -= len(s)
if len(s)==0:
self.close ()

return s

--
nosy: +StyXman, facundobatista

_
Tracker <[EMAIL PROTECTED]>

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

[issue1580738] httplib hangs reading too much data

[Facundo Batista]

Facundo Batista added the comment:

Mark is ok, zero length responses are ok. But that has nothing to do
with self.length.

self.lenght reaching zero means that everything that needed to be read
is already read. If the read() method is called without an argument, it
reads everything until it reaches self.lenght, and then it closes self.

So, when is called with an argument, is ok to close self if after
reading something self.length reaches zero (note that this actually
means that something was read, and self.length was lowered down...)

If self is closed also in this instance (see the patch), all tests pass
ok, and how you use HTTPConnection reading small pieces and not the
whole thing, is actually simplified...

--
assignee:  -> facundobatista
keywords: +patch
versions: +Python 2.5 -Python 2.4

_
Tracker <[EMAIL PROTECTED]>

_Index: Lib/httplib.py
===
--- Lib/httplib.py	(revisión: 58443)
+++ Lib/httplib.py	(copia de trabajo)
@@ -530,7 +530,8 @@
 s = self.fp.read(amt)
 if self.length is not None:
 self.length -= len(s)
-
+if not self.length:
+self.close()
 return s
 
 def _read_chunked(self, amt):
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com