[issue14339] Optimizing bin, oct and hex

[Mark Dickinson]

Mark Dickinson  added the comment:

Thanks for the updates.


> The same assumption is used above in long_to_decimal_string(). I added
> the same assert and changed maxchar to 'f'.

I think 'x' would be more appropriate. :-)

--

___
Python tracker 

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

[issue14586] TypeError: truncate() takes no keyword arguments

[Guy Taylor]

Guy Taylor  added the comment:

What ever change is made to the new CPythons the old docs should be updated to 
prevent confusion, with truncate([size]).

On fixing it for the future I would agree that supporting it as a keyword 
argument is preferred, as it is more pythonic (in my opinion). However this 
would cause ether backwards incompatibility or ambiguity in the language (ie. 
truncate(0, size=1) or need the deprecate, warn then removal stages taken three 
release cycles).

Maybe the less perfect but acceptable solution is just to change the docs and 
wait for Python 4k for the real fix?

--

___
Python tracker 

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

[issue14576] IDLE cannot connect to subprocess - New solution

[clikkeb]

clikkeb  added the comment:

I think that lines 207-210 of GetUserCfgDir should be modified like this:

try:
sys.stderr.write(warn)
except (IOError, AttributeError):# < 
pass#^^

because when you start IDLE via pythonw.exe (that sets sys.stderr to "None"),
the function call sys.stderr.write(warn) raises the following exception:

AttributeError: 'NoneType' object has no attribute 'write'

and IDLE stops running without displaying any exception error, because that
exception is unhandled.

There is a funcion call to sys.stderr.write also at line 222, just before a
"raise SystemExit" statement, which makes ininfluent the missing 
AttributeError exception handling.

--

___
Python tracker 

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

[issue14339] Optimizing bin, oct and hex

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

> I think 'x' would be more appropriate. :-)

Oops. You are right, of cause.

--
Added file: http://bugs.python.org/file25234/long_to_binary_base_3.patch

___
Python tracker 

___diff -r 13307eb5bf47 Objects/longobject.c
--- a/Objects/longobject.c  Sat Apr 14 14:20:29 2012 -0500
+++ b/Objects/longobject.c  Mon Apr 16 12:01:24 2012 +0300
@@ -1672,11 +1672,10 @@
 {
 register PyLongObject *a = (PyLongObject *)aa;
 PyObject *v;
-Py_ssize_t i, sz;
+Py_ssize_t sz;
 Py_ssize_t size_a;
-char *p;
-char sign = '\0';
-char *buffer;
+Py_UCS1 *p;
+int negative;
 int bits;
 
 assert(base == 2 || base == 8 || base == 10 || base == 16);
@@ -1688,6 +1687,7 @@
 return NULL;
 }
 size_a = ABS(Py_SIZE(a));
+negative = Py_SIZE(a) < 0;
 
 /* Compute a rough upper bound for the length of the string */
 switch (base) {
@@ -1706,31 +1706,37 @@
 }
 /* compute length of output string: allow 2 characters for prefix and
1 for possible '-' sign. */
-if (size_a > (PY_SSIZE_T_MAX - 3) / PyLong_SHIFT / sizeof(Py_UCS4)) {
+if (size_a > (PY_SSIZE_T_MAX - 3) / PyLong_SHIFT) {
 PyErr_SetString(PyExc_OverflowError,
 "int is too large to format");
 return NULL;
 }
 /* now size_a * PyLong_SHIFT + 3 <= PY_SSIZE_T_MAX, so the RHS below
is safe from overflow */
-sz = 3 + (size_a * PyLong_SHIFT + (bits - 1)) / bits;
-assert(sz >= 0);
-buffer = PyMem_Malloc(sz);
-if (buffer == NULL) {
+if (size_a == 0) {
+sz = 3;
+}
+else {
+sz = 2 + negative + ((size_a - 1) * PyLong_SHIFT +
+ bits_in_digit(a->ob_digit[size_a - 1]) +
+ (bits - 1)) / bits;
+}
+v = PyUnicode_New(sz, 'x');
+if (v == NULL) {
 PyErr_NoMemory();
 return NULL;
 }
-p = &buffer[sz];
-if (Py_SIZE(a) < 0)
-sign = '-';
-
-if (Py_SIZE(a) == 0) {
+assert(PyUnicode_KIND(v) == PyUnicode_1BYTE_KIND);
+p = PyUnicode_1BYTE_DATA(v) + sz;
+
+if (size_a == 0) {
 *--p = '0';
 }
 else {
 /* JRH: special case for power-of-2 bases */
 twodigits accum = 0;
 int accumbits = 0;  /* # of bits in accum */
+Py_ssize_t i;
 for (i = 0; i < size_a; ++i) {
 accum |= (twodigits)a->ob_digit[i] << accumbits;
 accumbits += PyLong_SHIFT;
@@ -1739,7 +1745,7 @@
 char cdigit;
 cdigit = (char)(accum & (base - 1));
 cdigit += (cdigit < 10) ? '0' : 'a'-10;
-assert(p > buffer);
+assert(p > PyUnicode_1BYTE_DATA(v));
 *--p = cdigit;
 accumbits -= bits;
 accum >>= bits;
@@ -1747,6 +1753,7 @@
 }
 }
 
+assert(p == PyUnicode_1BYTE_DATA(v) + 2 + negative);
 if (base == 16)
 *--p = 'x';
 else if (base == 8)
@@ -1754,10 +1761,8 @@
 else /* (base == 2) */
 *--p = 'b';
 *--p = '0';
-if (sign)
-*--p = sign;
-v = PyUnicode_DecodeASCII(p, &buffer[sz] - p, NULL);
-PyMem_Free(buffer);
+if (negative)
+*--p = '-';
 return v;
 }
 
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14591] Value returned by random.random() out of valid range

[Dave Reid]

New submission from Dave Reid :

A particular combination of seed and jumpahead calls seems to force the MT 
generator into a state where it produces a random variate that is outside the 
range 0-1. Problem looks like it might be in _randommodule.c:genrand_int32, 
which produces a value > 0x for the given state, but I don't understand 
the generator well enough to debug any further.

The attached test case produces 1.58809998297 as the 2nd variate in Python 2.7 
and 1.35540900431 as the 23rd variate in Python 2.7.3. The problem occurs on 
both Linux (CentOS 6) and Mac OSX (10.6.8), both 64-bit.

--
components: Interpreter Core
files: badrand.py
messages: 158406
nosy: Dave.Reid
priority: normal
severity: normal
status: open
title: Value returned by random.random() out of valid range
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file25235/badrand.py

___
Python tracker 

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

[issue8212] A tp_dealloc of a subclassed class cannot resurrect an object

[Kristján Valur Jónsson]

Kristján Valur Jónsson  added the comment:

Updated the patch with better documentation, and recursion safety.

--
Added file: http://bugs.python.org/file25236/basedealloc.diff

___
Python tracker 

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

[issue13959] Re-implement parts of imp in pure Python

[Berker Peksag]

Changes by Berker Peksag :


--
nosy: +berker.peksag

___
Python tracker 

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

[issue14591] Value returned by random.random() out of valid range

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Indeed, jumpahead may have problems on non-32-bit platforms. The proposed patch 
fixes it. Porting to Python 3 is not required.

--
keywords: +patch
nosy: +storchaka
Added file: http://bugs.python.org/file25237/random_jumpahead_64bit.patch

___
Python tracker 

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

[issue14591] Value returned by random.random() out of valid range

[Mark Dickinson]

Changes by Mark Dickinson :


--
nosy: +rhettinger

___
Python tracker 

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

[issue14592] old-style (level=-1) importing broken after importlib changes

[Stefan Behnel]

New submission from Stefan Behnel :

Up to the early Py3.3 developer versions, calling __import__() with a level of 
-1 worked as in Python 2, i.e. it tried a relative import first and then a 
global import.

This no longer seems to be available after the importlib rewrite (e.g. as of 
rev f341b99bb370).

--
components: Interpreter Core
messages: 158409
nosy: scoder
priority: normal
severity: normal
status: open
title: old-style (level=-1) importing broken after importlib changes
type: behavior
versions: Python 3.3

___
Python tracker 

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

[issue14586] TypeError: truncate() takes no keyword arguments

[R. David Murray]

R. David Murray  added the comment:

There wouldn't be serious backward incompatibility.  Truncate(0) would still 
mean the same thing as truncate(size=0).  I don't remember if we treat 
supporting the keyword form when it is doced that as a bug or not, though, so 
you might be right that it can't be backported.

--

___
Python tracker 

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

[issue14593] PyErr_SetFromImportErrorWithNameAndPath lacks error checking

[Antoine Pitrou]

New submission from Antoine Pitrou :

The PyErr_SetFromImportErrorWithNameAndPath implementation never checks for the 
various results returned by the C API functions it invokes.

(also, it needs documenting, see python-dev)

As for PyErr_SetExcWithArgsKwargs, there's a potential refleak when args is 
NULL.

--
components: Interpreter Core
messages: 158411
nosy: brett.cannon, brian.curtin, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: PyErr_SetFromImportErrorWithNameAndPath lacks error checking
type: resource usage
versions: Python 3.3

___
Python tracker 

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

[issue14588] PEP 3115 compliant dynamic class creation

[R. David Murray]

Changes by R. David Murray :


--
assignee:  -> ncoghlan

___
Python tracker 

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

[issue14594] document imp.load_dynamic()

[Stefan Behnel]

New submission from Stefan Behnel :

The imp.load_dynamic() function is used by third party code (e.g. Cython's 
pyximport) but is not currently documented.

http://docs.python.org/dev/library/imp.html

The latest changes to the import mechanism suggest that it should better be 
documented to give a hint that users can rely on it.

--
assignee: docs@python
components: Documentation
messages: 158412
nosy: docs@python, scoder
priority: normal
severity: normal
status: open
title: document imp.load_dynamic()
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

___
Python tracker 

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

Re: [issue14591] Value returned by random.random() out of valid range

[Peter Otten]

Dave Reid wrote:

> 
> New submission from Dave Reid :
> 
> A particular combination of seed and jumpahead calls seems to force the MT
> generator into a state where it produces a random variate that is outside
> the range 0-1. Problem looks like it might be in
> _randommodule.c:genrand_int32, which produces a value > 0x for the
> given state, but I don't understand the generator well enough to debug any
> further.
> 
> The attached test case produces 1.58809998297 as the 2nd variate in Python
> 2.7 and 1.35540900431 as the 23rd variate in Python 2.7.3. The problem
> occurs on both Linux (CentOS 6) and Mac OSX (10.6.8), both 64-bit.

A simple way to reproduce the problem:

>>> import random
>>> r = random.Random()
>>> a, b, c = r.getstate()
>>> r.setstate((a, (0x,)*len(b), c))
>>> r.jumpahead(1)
>>> r.random()
1.8015423506628903


It looks like in random_jumpahead

mt[i] += i+1;

needs to be masked

mt[i] = (mt[i] + i + 1) & 0xUL;

(random_setstate already does that)

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

[issue14595] Complete your registration to Python tracker -- key 25rVzaHLDOR5lFuBNkq7ixbyp3WbqQlG

[Robert E.]

New submission from Robert E. :

Am 16.04.2012 13:49, schrieb Python tracker:
> To complete your registration of the user "roberte" with
> Python tracker, please do one of the following:
> 
> - send a reply to rep...@bugs.python.org and maintain the subject line as is 
> (the
> reply's additional "Re:" is ok),
> 
> - or visit the following URL:
> 
> http://bugs.python.org/?@action=confrego&otk=25rVzaHLDOR5lFuBNkq7ixbyp3WbqQlG

--
messages: 158413
nosy: roberte
priority: normal
severity: normal
status: open
title: Complete your registration to Python tracker -- key  
25rVzaHLDOR5lFuBNkq7ixbyp3WbqQlG

___
Python tracker 

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

[issue14595] Complete your registration to Python tracker -- key 25rVzaHLDOR5lFuBNkq7ixbyp3WbqQlG

[R. David Murray]

R. David Murray  added the comment:

Something seems to have gone wrong with the 'reply' form.  Sorry about that.  
Please use the URL instead.

--
nosy: +r.david.murray
resolution:  -> invalid
stage:  -> 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

[issue14595] Complete your registration to Python tracker -- key 25rVzaHLDOR5lFuBNkq7ixbyp3WbqQlG

[Robert E.]

Robert E.  added the comment:

Well I did that first but the tracker replied:

node with key "roberte" exists

Seems the username is alread in use but I still could register but not
complete the registration.

Am 16.04.2012 13:54, schrieb R. David Murray:
> 
> R. David Murray  added the comment:
> 
> Something seems to have gone wrong with the 'reply' form.  Sorry about that.  
> Please use the URL instead.
> 
> --
> nosy: +r.david.murray
> resolution:  -> invalid
> stage:  -> committed/rejected
> status: open -> closed
> 
> ___
> Python tracker 
> 
> ___

--

___
Python tracker 

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

[issue14428] Implementation of the PEP 418

[STINNER Victor]

STINNER Victor  added the comment:

The precision of mach_absolute_time() is known: it is timebase.numer / 
timebase.denom * 1e-9.

--

___
Python tracker 

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

[issue14591] Value returned by random.random() out of valid range

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Thanks for the report and patch.  I've investigate and load a fix this week.

--
assignee:  -> rhettinger
priority: normal -> high

___
Python tracker 

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

[issue14596] struct.unpack memory leak

[Robert Elsner]

New submission from Robert Elsner :

When unpacking multiple files with _variable_ length, struct unpack leaks 
massive amounts of memory. The corresponding functions from numpy (fromfile) or 
the array (fromfile) standard lib module behave as expected.

I prepared a minimal testcase illustrating the problem on 

Python 2.6.6 (r266:84292, Dec 26 2010, 22:31:48) 
[GCC 4.4.5] on linux2

This is a severe limitation when reading big files where performance is 
critical. The struct.Struct class does not display this behavior. Note that the 
variable length of the buffer is necessary to reproduce the problem (as is 
usually the case with real data files).
I suspect this is due to some internal buffer in the struct module not being 
freed after use.
I did not test on later Python versions, but could not find a related bug in 
the tracker.

--
components: Library (Lib)
files: unpack_memory_leak.py
messages: 158418
nosy: Robert.Elsner
priority: normal
severity: normal
status: open
title: struct.unpack memory leak
versions: Python 2.6
Added file: http://bugs.python.org/file25238/unpack_memory_leak.py

___
Python tracker 

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

[issue14596] struct.unpack memory leak

[Mark Dickinson]

Mark Dickinson  added the comment:

Do you see the same results with Python 2.7?  Python 2.6 is only receiving 
security bugfixes at this point.

--
nosy: +mark.dickinson

___
Python tracker 

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

[issue14596] struct.unpack memory leak

[Robert Elsner]

Robert Elsner  added the comment:

I would love to test but I am in a production environment atm and can't really 
spare the time to set up a test box. But maybe somebody with access to 2.7 on 
linux could test it with the supplied script (just start it and it should 
happily eat 8GB of memory - I think most users are going to notice ;)

--

___
Python tracker 

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

[issue14596] struct.unpack memory leak

[Mark Dickinson]

Mark Dickinson  added the comment:

I suspect that this is due to the struct module cache, which caches Struct 
instances corresponding to formats used.  If that's true, there's no real leak 
as such.

As a test, what happens if you increase your xrange(30) to xrange(300)?  (And 
perhaps decrease the size of the struct itself a bit to compensate).  You 
should see that memory usage stays constant after the first ~100 runs.

Using Struct directly is a good workaround if this is a problem.

--

___
Python tracker 

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

[issue14596] struct.unpack memory leak

[Robert Elsner]

Robert Elsner  added the comment:

Well seems like 3.1 is in the Debian repos as well. Same memory leak. So it is 
very unlikely it has been fixed in 2.7. I modified the test case to be 
compatible to 3.1 and 2.6.

--
versions: +Python 3.1
Added file: http://bugs.python.org/file25239/unpack_memory_leak.py

___
Python tracker 

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

[issue14596] struct.unpack memory leak

[Robert Elsner]

Robert Elsner  added the comment:

Well the problem is, that performance is severely degraded when calling unpack 
multiple times. I do not know in advance the size of the files and they might 
vary in size from 1M to 1G. I could use some fixed-size buffer which is 
inefficient depending on the file size (too big or too small). And if I change 
the buffer on the fly, I end up with the memory leak. I think the caching 
should take into account the available memory on the system. the no_leak 
function has comparable performance without the leak. And I think there is no 
point in caching Struct instances when they go out of scope and can not be 
accessed anymore? If i let it slip from the scope I do not want to use it 
thereafter. Especially considering that struct.Struct behaves as expected as do 
array.fromfile and numpy.fromfile.

--

___
Python tracker 

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

[issue14304] Implement utf-8-bmp codec

[Martin v . Löwis]

Martin v. Löwis  added the comment:

This codec is one that is equal to UTF-8, but restricted to the BMP. For 
non-BMP character, the error handler is called. It will be the stdout codec for 
the IDLE interactive shell, causing non-BMP results to be ascii() escaped.

--

___
Python tracker 

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

[issue14595] Complete your registration to Python tracker -- key 25rVzaHLDOR5lFuBNkq7ixbyp3WbqQlG

[R. David Murray]

R. David Murray  added the comment:

Hmm.  The account *looks* normal, and has your email address attached.  Can you 
log in using the password you chose?

--

___
Python tracker 

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

[issue14304] Implement utf-8-bmp codec

[Andrew Svetlov]

Andrew Svetlov  added the comment:

Tkinter (as Tcl itself) has no support of non-BMP characters in any form. 
It looks like support of UTF-16 without surrogates.
I like to implement codec for that which will process different error modes 
(strict, replace, ignore etc) as well as others codecs does.

It will allow to support BMP well and control processing of non-BMP in IDLE.

About your second question. 
IDLE has interactive shell. This shell in REPL will try to print expression 
result. It it contains non-BMP whole result is converted to ASCII with 
escaping. It's different from standard python console. From my perspective 
expected behavior is to pass BMP chars and escape only non-BMP.

--

___
Python tracker 

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

[issue14596] struct.unpack memory leak

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> I suspect that this is due to the struct module cache, which caches
> Struct instances corresponding to formats used.  If that's true,
> there's no real leak as such.

Well, the posted code creates 30 struct instances. That shouldn't exhaust the 
memory of a 8GB box (which it does here)...

--
nosy: +pitrou
type:  -> resource usage
versions: +Python 2.7, Python 3.2, Python 3.3 -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

[issue14595] Complete your registration to Python tracker -- key 25rVzaHLDOR5lFuBNkq7ixbyp3WbqQlG

[Robert E.]

Robert E.  added the comment:

No I can't (says invalid login). I created a new account using my Google
ID which works alright. If you want to debug this problem I am happy to
help but otherwise this "bug entry" can be removed.

Cheers

Am 16.04.2012 14:47, schrieb R. David Murray:
> 
> R. David Murray  added the comment:
> 
> Hmm.  The account *looks* normal, and has your email address attached.  Can 
> you log in using the password you chose?
> 
> --
> 
> ___
> Python tracker 
> 
> ___

--

___
Python tracker 

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

[issue14596] struct.unpack memory leak

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Yes, the problem is the place to be in Python 2.7, in Python 3.2 and in Python 
3.3. Random size of the structure is important -- if you remove the randint, 
leakage will not.

The memory is not released in cached structuress, which are created in 
module-level unpack.

I now deal with it.

--
nosy: +storchaka

___
Python tracker 

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

[issue12081] Remove distributed copy of libffi

[Martin v . Löwis]

Martin v. Löwis  added the comment:

Arfrever: I doubt anybody has contributed patches back, or that anybody is 
interested in doing so.

I personally don't see a problem in using an old libffi version, so I fail to 
see Benjamin's issue. Figuring out how exactly to use the system libffi is more 
hassle than keeping our own copy.

Please understand that ctypes is unmaintained. Anybody actively taking over 
maintenance of ctypes would have to decide on how integration with libffi is 
supposed to work. Without a maintainer, falling back to the sytem libffi is a 
too high risk, IMO, since this will certainly produce tons of new bug reports, 
with nobody prepared to deal with them.

--

___
Python tracker 

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

[issue14596] struct.unpack memory leak

[Antoine Pitrou]

Antoine Pitrou  added the comment:

It appears the storage of Struct instances is rather inefficient when there's a 
repeat code such as "<48L". In this example, 48 almost identical structures 
describing the "L" format (struct _formatcode) will be created. You can guess 
what happens with large repeat counts...

--

___
Python tracker 

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

[issue12723] Provide an API in tkSimpleDialog for defining custom validation functions

[Andrew Svetlov]

Changes by Andrew Svetlov :


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

[issue14597] Cannot unload dll in ctypes until script exits

[Pat Lynch]

New submission from Pat Lynch :

If I load a dll in ctypes, then delete that loaded DLL instance, the DLL is not 
unloaded until the script finishes and exits.

I'm trying to write some unit tests in python to exercise that DLL where each 
test case loads a DLL, does some work, then unloads the DLL.  Unfortunately the 
DLL only gets unloaded when the unit tests finish.

I've tried forcing the garbage collector to run to get the DLL to unload.  It 
did nothing...

# load the DLL
parser_dll = CDLL(dllpath)

# do some work here

# 'unload' the dll (or as close as I can get it to it)
if (parser_dll):
del parser_dll

--
components: ctypes
messages: 158433
nosy: plynch76
priority: normal
severity: normal
status: open
title: Cannot unload dll in ctypes until script exits
type: enhancement
versions: Python 2.7

___
Python tracker 

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

[issue14576] IDLE cannot connect to subprocess - New solution

[Andrew Svetlov]

Andrew Svetlov  added the comment:

I guess IdleConf should to have flag like 'writable'.
If user environment points to invalid location (or there are no write access) 
this flag should be set.
It flag can affect IDLE configuration dialog: user should be notified what him 
changes will not be permanently saved.
Subprocess can check that flag as well if need.

BTW, there are related issue8231.

--

___
Python tracker 

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

[issue14595] Complete your registration to Python tracker -- key 25rVzaHLDOR5lFuBNkq7ixbyp3WbqQlG

[R. David Murray]

R. David Murray  added the comment:

As long as you are good with a registered account, that's what's important.  If 
I get time I'll take a deeper look, but most likely I won't unless this happens 
again.

--

___
Python tracker 

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

[issue14592] old-style (level=-1) importing broken after importlib changes

[R. David Murray]

Changes by R. David Murray :


--
nosy: +brett.cannon

___
Python tracker 

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

[issue14597] Cannot unload dll in ctypes until script exits

[Pat Lynch]

Pat Lynch  added the comment:

I should mention also, that this is mostly an issue for me on Win7 x64.  It
does behave 'slightly' better on WinXP x86.

(I have the 64-bit version of python installed on Win7 x64 & the 32-bit
version installed on WinXP)

thanks,
Pat.

On 16 April 2012 14:09, Pat Lynch  wrote:

>
> New submission from Pat Lynch :
>
> If I load a dll in ctypes, then delete that loaded DLL instance, the DLL
> is not unloaded until the script finishes and exits.
>
> I'm trying to write some unit tests in python to exercise that DLL where
> each test case loads a DLL, does some work, then unloads the DLL.
>  Unfortunately the DLL only gets unloaded when the unit tests finish.
>
> I've tried forcing the garbage collector to run to get the DLL to unload.
>  It did nothing...
>
> # load the DLL
> parser_dll = CDLL(dllpath)
>
> # do some work here
>
> # 'unload' the dll (or as close as I can get it to it)
> if (parser_dll):
>del parser_dll
>
> --
> components: ctypes
> messages: 158433
> nosy: plynch76
> priority: normal
> severity: normal
> status: open
> title: Cannot unload dll in ctypes until script exits
> type: enhancement
> versions: Python 2.7
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

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

[issue4130] Intel icc 9.1 does not support __int128_t used by ctypes

[Martin v . Löwis]

Martin v. Löwis  added the comment:

Changes to ctypes should not affect the gdbm module.

More likely, icc and python just don't work together. It may be a compiler bug 
in icc (it wouldn't be the first one discovered by Python), or it may be a 
portability defect in Python (where it wouldn't be the first case, either). In 
any case, the gdbm issue is likely unrelated.

--

___
Python tracker 

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

[issue14592] old-style (level=-1) importing broken after importlib changes

[Benjamin Peterson]

Benjamin Peterson  added the comment:

Relative imports are no longer supported in python 3, so this makes sense.

--
nosy: +benjamin.peterson

___
Python tracker 

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

[issue14592] old-style (level=-1) importing broken after importlib changes

[Benjamin Peterson]

Benjamin Peterson  added the comment:

By "relative" I meant "sibling".

--

___
Python tracker 

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

[issue14594] document imp.load_dynamic()

[R. David Murray]

R. David Murray  added the comment:

This is essentially a duplicate of issue 14551, but perhaps with a bit more 
weight behind it.

--
nosy: +brett.cannon, pitrou, r.david.murray
versions:  -Python 2.6, Python 2.7, Python 3.1

___
Python tracker 

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

[issue14594] document imp.load_dynamic()

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Ok, let's redocument them, then :)

--

___
Python tracker 

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

[issue14339] Optimizing bin, oct and hex

[Martin v . Löwis]

Martin v. Löwis  added the comment:

> (1) The patch appears to assume that a Unicode string created with
> PyUnicode_New(size, 127) will have 'kind' PyUnicode_1BYTE_KIND.
> While this might be true in the current implementation, I don't know
> whether this is guaranteed in general.  Martin, any comments on
> this?

There is a guarantee that the shortest form must always be used.
So as long as the Unicode representation doesn't fundamentally change
again, this property is indeed guaranteed.

--

___
Python tracker 

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

[issue14596] struct.unpack memory leak

[Mark Dickinson]

Mark Dickinson  added the comment:

> It appears the storage of Struct instances is rather inefficient when 
> there's a repeat code such as "<48L"

Right.  Repeat counts aren't directly supported in the underlying 
PyStructObject;  a format string containing repeat counts is effectively 
'compiled' to a series of (type, offset, size) triples before it can be used.  
The caching is there to save repeated compilations when the same format string 
is used repeatedly.

--

___
Python tracker 

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

[issue14597] Cannot unload dll in ctypes until script exits

[R. David Murray]

R. David Murray  added the comment:

In general it is difficult to impossible to get Python2 to unload modules 
before the interpreter shuts down.  See issue 9072.  I'm not savvy enough with 
the C stuff to know if the fact that you loaded it via ctypes changes anything, 
but I doubt it.

Note that the implication of that issue is that if you could move to Python3 
there might be a way to do it, but that would indeed be an enhancement as there 
is no direct support for it yet.

--
nosy: +r.david.murray
versions: +Python 3.3 -Python 2.7

___
Python tracker 

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

[issue8212] A tp_dealloc of a subclassed class cannot resurrect an object

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Urg, that's a horrible hack.
How about instead having an API function to resurrect an object from a 
tp_dealloc?

That way the iobase_dealloc code would be written:

if (_PyIOBase_finalize((PyObject *) self) < 0) {
_PyObject_ResurrectFromDealloc(self);
return;
}

That API function could also perhaps take care of the _Py_NewReference stuff 
(see the end of _PyIOBase_finalize).

--

___
Python tracker 

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

[issue14588] PEP 3115 compliant dynamic class creation

[Éric Araujo]

Changes by Éric Araujo :


--
nosy: +eric.araujo

___
Python tracker 

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

[issue14597] Cannot unload dll in ctypes until script exits

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
nosy: +brian.curtin, meador.inge, tim.golden

___
Python tracker 

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

[issue14339] Optimizing bin, oct and hex

[Mark Dickinson]

Mark Dickinson  added the comment:

> There is a guarantee that the shortest form must always be used.

Okay, sounds good.  Thanks.

--

___
Python tracker 

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

[issue14597] Cannot unload dll in ctypes until script exits

[Pat Lynch]

Pat Lynch  added the comment:

thanks for the very quick response.

Since LoadLibrary is called in the constructor, why can't FreeLibrary be
called in the destructor?  or at least expose a function to unload that
calls FreeLibrary?

http://msdn.microsoft.com/en-us/library/windows/desktop/ms683152%28v=vs.85%29.aspx

thanks again,
Pat.

On 16 April 2012 14:30, R. David Murray  wrote:

>
> R. David Murray  added the comment:
>
> In general it is difficult to impossible to get Python2 to unload modules
> before the interpreter shuts down.  See issue 9072.  I'm not savvy enough
> with the C stuff to know if the fact that you loaded it via ctypes changes
> anything, but I doubt it.
>
> Note that the implication of that issue is that if you could move to
> Python3 there might be a way to do it, but that would indeed be an
> enhancement as there is no direct support for it yet.
>
> --
> nosy: +r.david.murray
> versions: +Python 3.3 -Python 2.7
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

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

[issue14452] SysLogHandler sends invalid messages when using unicode

[Roundup Robot]

Roundup Robot  added the comment:

New changeset af46a001d5ec by Vinay Sajip in branch '2.7':
Issue #14452: remove BOM insertion code.
http://hg.python.org/cpython/rev/af46a001d5ec

New changeset 89ab589f6fa7 by Vinay Sajip in branch '3.2':
Closes #14452: remove BOM insertion code.
http://hg.python.org/cpython/rev/89ab589f6fa7

New changeset 372aa4267a43 by Vinay Sajip in branch 'default':
Closes #14452: remove BOM insertion code.
http://hg.python.org/cpython/rev/372aa4267a43

--
nosy: +python-dev
resolution:  -> fixed
stage:  -> 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

[issue14597] Cannot unload dll in ctypes until script exits

[Martin v . Löwis]

Martin v. Löwis  added the comment:

In principle, it should be possible (but perhaps not desirable, see below) to 
call FreeLibrary in a CDLL's __del__. However, since this would be a new 
feature, it can't go into 2.7. Patches are welcome; make sure to support both 
FreeLIbrary and dlclose.

There is a general issue with closing/freeing DLLs: if they are still 
referenced somewhere (e.g. in an atexit function, a C++ virtual method table, 
or on the call stack of another thread), then a later access to the code will 
crash the interpreter. In a typical DLL today (including all Python extension 
modules), the likelihood of crashes is close to 100%. For that reason, it's 
probably not a good idea to have ctypes auto-close DLLs; instead, it should be 
an opt-in mechanism.

For most ctypes uses, closing is irrelevant, since people typically access 
system libraries that are independently loaded anyway, so closing them would 
not have any effect.

--
nosy: +loewis

___
Python tracker 

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

[issue8212] A tp_dealloc of a subclassed class cannot resurrect an object

[Kristján Valur Jónsson]

Kristján Valur Jónsson  added the comment:

Ok, that sounds reasonable, particularly in light of that _NewReference stuff.  
I'll work out a different patch then.  But I think the API must be public, 
since it would need to work from extension modules.

So: if a c type decides that it wants to live after a tp_dealloc(), it must 
call this api ...

--

___
Python tracker 

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

[issue14569] pystate.c #ifdef ordering problem

[Jim Jewett]

Jim Jewett  added the comment:

On Fri, Apr 13, 2012 at 6:19 AM,
Antoine Pitrou  added the comment:

> I don't think you need anyone's permission to commit such a fix :)

Well, *I* would, since I don't have commit privs, and don't currently
have a C dev environment with which to test.

But I figured testing the various build conditions might be good
documentation-of-ability for someone applying to GSoC or otherwise
trying to get started. (OK, the timing wouldn't be ideal, ...)

That said, I foresee adding build-multiple-ways to the regression
tests (as opposed to a buildbot), so I'll let the next applicant come
up with something else.  :D

--

___
Python tracker 

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

[issue14596] struct.unpack memory leak

[Mark Dickinson]

Mark Dickinson  added the comment:

Perhaps the best quick fix would be to only cache small PyStructObjects, for 
some value of 'small'.  (Total size < a few hundred bytes, perhaps.)

--

___
Python tracker 

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

[issue8212] A tp_dealloc of a subclassed class cannot resurrect an object

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> Ok, that sounds reasonable, particularly in light of that
> _NewReference stuff.  I'll work out a different patch then.  But I
> think the API must be public, since it would need to work from
> extension modules.

Needing to work from (stdlib) extension modules and being public are too
different things. I don't think we want to encourage third-party types
to resurrect their instances.

--

___
Python tracker 

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

[issue14596] struct.unpack memory leak

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> Perhaps the best quick fix would be to only cache small
> PyStructObjects, for some value of 'small'.  (Total size < a few
> hundred bytes, perhaps.)

Or perhaps not care at all? Is there a use case for huge repeat counts?
(limiting cacheability could decrease performance in existing
applications)

--

___
Python tracker 

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

[issue14597] Cannot unload dll in ctypes until script exits

[Pat Lynch]

Pat Lynch  added the comment:

ok, that's fair enough if most usage of ctypes is from people accessing
system libraries :)

I wouldn't have thought my usage was that weird though (given the strength
of using python for unit testing).

In local tests, adding a function CDLL::ForceUnloadDll  (which just calls
FreeLibrary(self._handle)) seems to work well.  I haven't done intensive
testing though at this point.  I could be missing something though.

thanks,
Pat.

On 16 April 2012 14:45, Martin v. Löwis  wrote:

>
> Martin v. Löwis  added the comment:
>
> In principle, it should be possible (but perhaps not desirable, see below)
> to call FreeLibrary in a CDLL's __del__. However, since this would be a new
> feature, it can't go into 2.7. Patches are welcome; make sure to support
> both FreeLIbrary and dlclose.
>
> There is a general issue with closing/freeing DLLs: if they are still
> referenced somewhere (e.g. in an atexit function, a C++ virtual method
> table, or on the call stack of another thread), then a later access to the
> code will crash the interpreter. In a typical DLL today (including all
> Python extension modules), the likelihood of crashes is close to 100%. For
> that reason, it's probably not a good idea to have ctypes auto-close DLLs;
> instead, it should be an opt-in mechanism.
>
> For most ctypes uses, closing is irrelevant, since people typically access
> system libraries that are independently loaded anyway, so closing them
> would not have any effect.
>
> --
> nosy: +loewis
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

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

[issue14432] Bug in generator if the generator in created in a C thread

[Andrew Suffield]

Andrew Suffield  added the comment:

I think I've tripped over a variation on this theme using pyqt and 2.7:

When working in a QThread, the PyGILState_Ensure call when transitioning 
control from Qt to python will frequently allocate a new thread state - because 
every time control returns to the Qt event loop, gilstate_counter is likely to 
become zero.

If a generator is kept around longer than this, it becomes quite likely to have 
an older thread state in f_tstate. This happens all the time.

The access that blows up on me is PyEval_GetRestricted, since 
PyFrame_IsRestricted checks f_tstate. Annoyingly this debris is still called on 
the possibly-restricted operations even when restricted execution is nowhere in 
sight.

Hence, any use of open() in a long-lived generator in a QThread is probably 
going to crash.

Patch against 2.7?

--
nosy: +asuffield

___
Python tracker 

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

[issue14596] struct.unpack memory leak

[Robert Elsner]

Robert Elsner  added the comment:

Well I stumbled across this leak while reading big files. And what is
the point of having a fast C-level unpack when it can not be used with
big files?
I am not adverse to the idea of caching the format string but if the
cache grows beyond a reasonable size, it should be freed. And
"reasonable" is not the number of objects contained but the amount of
memory it consumes. And caching an arbitrary amount of data (8GB here)
is a waste of memory.

And reading the Python docs, struct.Struct.unpack which is _not_
affected from the memory leak is supposed to be faster. Quote:

> class struct.Struct(format)
> 
> Return a new Struct object which writes and reads binary data according to 
> the format string format. Creating a Struct object once and calling its 
> methods is more efficient than calling the struct functions with the same 
> format since the format string only needs to be compiled once.

Caching in case of struct.Struct is straightforward: As long as the
object exists, the format string is cached and if the object is no
longer accessible, its memory gets freed - including the cached format
string. The problem is with the "magic" creation of struct.Struct
objects by struct.unpack that linger around even after all associated
variables are no longer in scope.

Using for example fixed 1MB buffer to read files (regardless of size)
incurs a huge performance penalty. Reading everything at once into
memory using struct.unpack (or with the same speed struct.Struct.unpack)
is the fastest way. Approximately 40% faster than array.fromfile and and
70% faster than numpy.fromfile.

I read some unspecified report about a possible memory leak in
struct.unpack but the author did not investigate further. It took me
quite some time to figure out what exactly happens. So there should be
at least a warning about this (ugly) behavior when reading big files for
speed and a pointer to a quick workaround (using struct.Struct.unpack).

cheers

Am 16.04.2012 15:59, schrieb Antoine Pitrou:
> 
> Antoine Pitrou  added the comment:
> 
>> Perhaps the best quick fix would be to only cache small
>> PyStructObjects, for some value of 'small'.  (Total size < a few
>> hundred bytes, perhaps.)
> 
> Or perhaps not care at all? Is there a use case for huge repeat counts?
> (limiting cacheability could decrease performance in existing
> applications)
> 
> --
> 
> ___
> Python tracker 
> 
> ___

--

___
Python tracker 

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

[issue14594] document imp.load_dynamic()

[R. David Murray]

R. David Murray  added the comment:

Yeah, they really need to be documented in order for us to document them as 
deprecated if we decide we really want to remove them later.  "Obsolete" is 
not, I think, the same as "deprecated".

--

___
Python tracker 

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

[issue14452] SysLogHandler sends invalid messages when using unicode

[R. David Murray]

R. David Murray  added the comment:

This appears to be failing on the buildbots:

http://www.python.org/dev/buildbot/all/builders/x86%20OpenIndiana%203.x/builds/3358/steps/test/logs/stdio
http://www.python.org/dev/buildbot/all/builders/x86%20Gentoo%20Non-Debug%203.x/builds/2037/steps/test/logs/stdio

--
nosy: +r.david.murray
status: closed -> open

___
Python tracker 

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

[issue14087] multiprocessing.Condition.wait_for missing

[sbt]

sbt  added the comment:

New patch which calculates endtime outside loop.

--
Added file: http://bugs.python.org/file25240/cond_wait_for.patch

___
Python tracker 

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

[issue14304] Implement utf-8-bmp codec

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Example:

>>> '\u0100'
'Ā'
>>> '\u0100\U0001'
'\u0100\U0001'
>>> print('\u0100')
Ā
>>> print('\u0100\U0001')
Traceback (most recent call last):
  File "", line 1, in 
print('\u0100\U0001')
UnicodeEncodeError: 'UCS-2' codec can't encode characters in position 1-1: 
Non-BMP character not supported in Tk

But I think that it is too specific problem and too specific solution. It would 
be better if IDLE itself escapes the string in the most appropriate way.

def utf8bmp_encode(s):
return ''.join(c if ord(c) <= 0x else '\\U%08x' % ord(c) for c in 
s).encode('utf-8')

or

def utf8bmp_encode(s):
return re.sub('[^\x00-\u]', lambda m: '\\U%08x' % ord(m.group()), 
s).encode('utf-8')

--

___
Python tracker 

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

[issue14437] _io build fails on cygwin

[Alexey Luchko]

Alexey Luchko  added the comment:

Final 2.7.3 didn't get the fix.
Checked http://python.org/ftp/python/2.7.3/Python-2.7.3.tar.xz

--

___
Python tracker 

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

[issue14596] struct.unpack memory leak

[Mark Dickinson]

Mark Dickinson  added the comment:

> Or perhaps not care at all?

That's also possible. :-)   IMO, Robert's use-case doesn't really match the 
intended use-case for struct (parsing structures of values laid out like a 
C-struct ).  There the caching makes sense.

--

___
Python tracker 

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

[issue11750] Mutualize win32 functions

[sbt]

sbt  added the comment:

> How about _windowsapi or _winapi then, to ensure there are no clashes?

I don't have any strong feelings, but I would prefer _winapi.

--

___
Python tracker 

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

[issue14452] SysLogHandler sends invalid messages when using unicode

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 603301cfb194 by Vinay Sajip in branch 'default':
Closes #14452: brought tests in line with removal of BOM insertion code.
http://hg.python.org/cpython/rev/603301cfb194

--
status: open -> closed

___
Python tracker 

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

[issue11750] Mutualize win32 functions

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> > How about _windowsapi or _winapi then, to ensure there are no clashes?
> 
> I don't have any strong feelings, but I would prefer _winapi.

Ditto here.

--

___
Python tracker 

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

[issue14592] old-style (level=-1) importing broken after importlib changes

[Brett Cannon]

Brett Cannon  added the comment:

What Benjamin said. PEP 328 should have done away with relative imports, but 
somehow the __import__() function itself was not updated even though its docs 
were changed to say that index defaulted to 0.

So this isn't actually a regressions because of importlib but actually just the 
implicit fixing of a bug. I was going to make sure to mention it in the "What's 
New" entry, but I will also add something to Misc/NEWS.

--

___
Python tracker 

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

[issue14304] Implement utf-8-bmp codec

[Andrew Svetlov]

Andrew Svetlov  added the comment:

The way is named 'codec'.

--

___
Python tracker 

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

[issue2193] Cookie Colon Name Bug

[Senthil Kumaran]

Senthil Kumaran  added the comment:

I tested setting cookies with ":" in the cookie name in both firefox and 
google-chrome. They both seem to allow and store the cookie with ":" in them.
Firefox sent a request header like this:

Set-Cookie  test:value=solution:is:he

the cookie with name containing ; or , failed.

The patched attached tries to silence the error with SimpleCookie. I am not 
sure how far it is going to help. I believe, we could just allow it from 3.3 
onwards or create a new BrowserCookie class which is more lenient than 
SimpleCookie.

As far I see, the allowing ":" in the Legalchars seem to have met with negative 
votes because it was not in RFC, but well it seems some kind of de-facto 
acceptable behaviour with browsers, so having from a new version may not cause 
any harm. +1 to that. I can modify the tests from the attached patch.

--
nosy: +orsenthil

___
Python tracker 

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

[issue14592] old-style (level=-1) importing broken after importlib changes

[Brett Cannon]

Brett Cannon  added the comment:

I should also mention that the support for -1 indexing in Python 3 was weird 
because support was partially removed, but some 'if' checks only did ``< 1`` 
and so negative indices didn't trigger an error.

--

___
Python tracker 

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

[issue14304] Implement utf-8-bmp codec

[Martin v . Löwis]

Martin v. Löwis  added the comment:

> But I think that it is too specific problem and too specific
> solution. It would be better if IDLE itself escapes the string in the
> most appropriate way.

That is not implementable correctly. If you think otherwise, please
submit a patch. If not, please trust me on that judgment.

--

___
Python tracker 

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

[issue14594] document imp.load_dynamic()

[Brett Cannon]

Brett Cannon  added the comment:

I'm fine w/ documenting load_dynamic() and leaving it as-is since importlib 
uses the function itself (plus the frozen/builtin functions, although the 
frozen stuff might be simplified since they can probably just return the bytes 
for the frozen module instead of doing as much work in C code). But 
load_package(), load_source(), and load_module() need to go.

--

___
Python tracker 

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

[issue14583] try/except import fails --without-threads

[Brett Cannon]

Brett Cannon  added the comment:

Just to clarify the failure for the bug history, somehow multiprocessing is not 
ending up in sys.modules as expected. It changed from a SystemError to a 
KeyError because I started to properly check a PyDict_GetItem() return value 
instead of blindly assuming something was going to be in sys.modules.

--

___
Python tracker 

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

[issue14551] imp.load_source docs removed from python3 docs...is this correct?

[Brett Cannon]

Brett Cannon  added the comment:

David, did you find load_source() convenient because you could specify the file 
to use for the module's source? Did you actually like the file object argument? 
Just trying to gauge if some new API is needed on a loader of if the one-liner 
I proposed is good enough.

--

___
Python tracker 

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

[issue13959] Re-implement parts of imp in pure Python

[Brett Cannon]

Brett Cannon  added the comment:

>From Eric Smith on python-dev:

> +suffix, mode, type_ = details
> +if mode and (not mode.startswith(('r', 'U'))) or '+' in mode:
> +raise ValueError('invalid file open mode {!r}'.format(mode))

Should this be:
if mode and (not mode.startswith(('r', 'U')) or '+' in mode):

to match:

> -if (*mode) {
...
> -if (!(*mode == 'r' || *mode == 'U') || strchr(mode, '+')) {
> -PyErr_Format(PyExc_ValueError,
> - "invalid file open mode %.200s", mode);

--

___
Python tracker 

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

[issue14437] _io build fails on cygwin

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  added the comment:

Yes, the 2.7.3 branch was cut long before the fix (end of February) so it was 
not included.

--

___
Python tracker 

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

[issue14591] Value returned by random.random() out of valid range

[Mark Dickinson]

Mark Dickinson  added the comment:

Patch looks good to me.

There's one other subtle bug in random_jumpahead, which is that it's not 
guaranteed that the resulting state is nonzero.  The way to fix this is to add 
a line like the one near the end of the 'init_by_array' function.

mt[0] = 0x8000UL; /* MSB is 1; assuring non-zero initial array */

--
nosy: +mark.dickinson

___
Python tracker 

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

[issue11750] Mutualize win32 functions

[sbt]

sbt  added the comment:

s/_win32/_winapi/g

--
Added file: http://bugs.python.org/file25241/winapi_module.patch

___
Python tracker 

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

[issue14551] imp.load_source docs removed from python3 docs...is this correct?

[R. David Murray]

R. David Murray  added the comment:

The one-liner is "good enough", but...

The use case is indeed loading a module from an arbitrary file without having 
to worry about sys.path, etc.  For that load_source is intuitive.  The 
one-liner is an adequate substitute, but feels like a step backward for this 
particular use case.  That is, load_source is a *convenience* function, from my 
POV :)

I did not use the 'file' argument.  If I were dealing with an already open file 
it would seem more natural to use imp.load_module.

--

___
Python tracker 

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

[issue14596] struct.unpack memory leak

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

The proposed patch uses a more compact encoding format of large structures.

--
keywords: +patch
Added file: http://bugs.python.org/file25242/struct_repeat.patch

___
Python tracker 

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

[issue14551] imp.load_source docs removed from python3 docs...is this correct?

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> The one-liner is an adequate substitute, but feels like a step
> backward for this particular use case.  That is, load_source is a
> *convenience* function, from my POV :)

Agreed with David.

--

___
Python tracker 

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

[issue14592] old-style (level=-1) importing broken after importlib changes

[Eric Snow]

Changes by Eric Snow :


--
nosy: +eric.snow

___
Python tracker 

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

[issue14594] document imp.load_dynamic()

[Eric Snow]

Changes by Eric Snow :


--
nosy: +eric.snow

___
Python tracker 

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

[issue14598] _cursesmodule.c fails with ncurses-5.9 on Linux

[Peter Häring]

New submission from Peter Häring :

I need to define NCURSES_INTERNALS in py_curses.h before ncurses.h is included, 
even on my Linux system with ncurses-5.9.

See the same issue for cygwin: 14438

--
components: Extension Modules
messages: 158481
nosy: phaering
priority: normal
severity: normal
status: open
title: _cursesmodule.c fails with ncurses-5.9 on Linux
type: compile error
versions: Python 2.7

___
Python tracker 

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

[issue14597] Cannot unload dll in ctypes until script exits

[Pat Lynch]

Pat Lynch  added the comment:

Just to update:-

I've run this pretty extensively on multiple systems (XP x86 & Win7 64-bit)
and it appears to behave as expected (haven't checked it on Linux).  I have
that code being called in 100s of unit tests.

For python 3.1, would it make sense to add it as a ForceUnload function??
- for safety bail out if handle was not None when passed into the
constructor?  i.e. if somebody has accessed an independently loaded DLL,
they will pass in the handle when constructing the CDLL object.  Disallow
ForceUnload in that case.  ForceUnload will only be allowed in cases where
we created that type by passing in the path to the DLL.

I'll be using this code as a local patch, so no rush to put it into 3.1 etc.

thanks for all the info - much appreciated :)

Pat.

On 16 April 2012 15:04, Pat Lynch  wrote:

>
> Pat Lynch  added the comment:
>
> ok, that's fair enough if most usage of ctypes is from people accessing
> system libraries :)
>
> I wouldn't have thought my usage was that weird though (given the strength
> of using python for unit testing).
>
> In local tests, adding a function CDLL::ForceUnloadDll  (which just calls
> FreeLibrary(self._handle)) seems to work well.  I haven't done intensive
> testing though at this point.  I could be missing something though.
>
> thanks,
> Pat.
>
> On 16 April 2012 14:45, Martin v. Löwis  wrote:
>
> >
> > Martin v. Löwis  added the comment:
> >
> > In principle, it should be possible (but perhaps not desirable, see
> below)
> > to call FreeLibrary in a CDLL's __del__. However, since this would be a
> new
> > feature, it can't go into 2.7. Patches are welcome; make sure to support
> > both FreeLIbrary and dlclose.
> >
> > There is a general issue with closing/freeing DLLs: if they are still
> > referenced somewhere (e.g. in an atexit function, a C++ virtual method
> > table, or on the call stack of another thread), then a later access to
> the
> > code will crash the interpreter. In a typical DLL today (including all
> > Python extension modules), the likelihood of crashes is close to 100%.
> For
> > that reason, it's probably not a good idea to have ctypes auto-close
> DLLs;
> > instead, it should be an opt-in mechanism.
> >
> > For most ctypes uses, closing is irrelevant, since people typically
> access
> > system libraries that are independently loaded anyway, so closing them
> > would not have any effect.
> >
> > --
> > nosy: +loewis
> >
> > ___
> > Python tracker 
> > 
> > ___
> >
>
> --
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

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

[issue14597] Cannot unload dll in ctypes until script exits

[R. David Murray]

R. David Murray  added the comment:

Current default will become 3.3.  3.1 has been out for a while :)

Your thought sounds reasonable, though Martin may have further input.

Would you are to propose a patch?  Otherwise most like nothing will happen with 
this issue.  3.3 Beta is scheduled for mid-June, so that would be the deadline 
for new features.

(PS: Could you please trim your replies when replying to tracker messages?  The 
quoted text makes the tracker issue hard to read.)

--

___
Python tracker 

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

[issue14598] _cursesmodule.c fails with ncurses-5.9 on Linux

[Roumen Petrov]

Roumen Petrov  added the comment:

you could find how to resolve in last patch attached to issue 3754

--
nosy: +rpetrov

___
Python tracker 

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

[issue14598] _cursesmodule.c fails with ncurses-5.9 on Linux

[Roumen Petrov]

Roumen Petrov  added the comment:

extracted as separate patch

--
keywords: +patch
Added file: 
http://bugs.python.org/file25243/0001-CROSS-properly-detect-WINDOW-_flags-for-different-nc.patch

___
Python tracker 

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

[issue14304] Implement utf-8-bmp codec

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

May be I did not correctly understand the problem, but I can assume,
that this patch solves it.

'Агов!\U0001'

--
keywords: +patch
Added file: http://bugs.python.org/file25244/idle_escape_nonbmp.patch

___
Python tracker 

___diff -r 13307eb5bf47 Lib/idlelib/rpc.py
--- a/Lib/idlelib/rpc.pySat Apr 14 14:20:29 2012 -0500
+++ b/Lib/idlelib/rpc.pyMon Apr 16 20:08:12 2012 +0300
@@ -615,10 +615,8 @@
 try:
 sys.stdout.write(text)
 except UnicodeEncodeError:
-# let's use ascii while utf8-bmp codec doesn't present
-encoding = 'ascii'
-bytes = text.encode(encoding, 'backslashreplace')
-text = bytes.decode(encoding, 'strict')
+# escape non-BMP characters
+text = ''.join(c if ord(c) <= 0x else '\\U%08x' % ord(c) for c in 
text)
 sys.stdout.write(text)
 sys.stdout.write("\n")
 builtins._ = value
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14304] Implement utf-8-bmp codec

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Sorry, the mail daemon has eaten a piece of example.

>>> '\u0410\u0433\u043e\u0432!\U0001'
'Агов!\U0001'

--

___
Python tracker 

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

[issue14551] imp.load_source docs removed from python3 docs...is this correct?

[Brett Cannon]

Brett Cannon  added the comment:

To help refine this, so you would expect all of the usual import stuff (e.g. 
sys.modules use, generating bytecode, etc.), you just want a short-circuit to 
the loading when you happen to already know the name and desired file path?

Basically I want to kill off the file argument to imp.load_source() since it 
buys you nothing as import is no longer structured to work off of already 
opened files, and especially files opened to return text instead of bytes (the 
only reason load_*() even takes an open file is because it directly exposes 
stuff part way through import.c's import process).

And as for having an already opened file, don't count on load_module() sticking 
around since find_module() is going to go since, once again, it is only 
structured the way it is with its poor API because of how import.c's C code was 
structured.

Thinking about it a little, would importlib.util.SourceFileLoader(name, 
path).load_source() be an okay API for you? Or do you really want a function 
instead of a convenience method on a loader instance? I basically want to gut 
imp down to only stuff that is required for backwards-compatibility for for 
really low-level stuff that normal people never touch and have common stuff 
like load_source() be in importlib somewhere.

--

___
Python tracker 

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

[issue14593] PyErr_SetFromImportErrorWithNameAndPath lacks error checking

[Eric Snow]

Changes by Eric Snow :


--
nosy: +eric.snow

___
Python tracker 

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

[issue14567] http.server query string handling is incorrect and inefficient

[Jim Jewett]

Changes by Jim Jewett :


--
title: http.server query string handling incorrect and inefficient -> 
http.server query string handling is incorrect and inefficient

___
Python tracker 

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

[issue14599] Windows test_import failure

[R. David Murray]

New submission from R. David Murray :

Not sure which revision triggered this, so opening a new bug:

http://www.python.org/dev/buildbot/all/builders/x86%20XP-4%203.x/builds/6381/steps/test/logs/stdio

There's also a test_reprlib failure, no idea if it is related.

--
keywords: buildbot
messages: 158489
nosy: brett.cannon, pitrou, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: Windows test_import failure
type: behavior
versions: Python 3.3

___
Python tracker 

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