Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
PyType_Ready is called for each class in tp_bases.
This is done in typeobject.c::best_base()
Isn't it the case in your program?
--
nosy: +amaury.forgeotdarc
___
Python
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
The python issue tracker is not the correct place to get this kind of
help. Please ask on the comp.lang.python newsgroup:
http://www.python.org/community/lists
--
nosy: +amaury.forgeotdarc
resolution: -> invali
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
Forget my last remark: it applies to heap types (created with
type_new()) and not to static types.
However, it seems that a non-ready class in tp_bases can happen only
when an extension type inherits from another extension
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
This has nothing to do with doctest. Starting with your script, I get:
>>> a = f()
>>> b = repr(a)
Traceback (most recent call last):
File "", line 1, in
UnicodeEncodeError: 'ascii' c
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
Bingo! doctest sets the __builtins__._ variable,
and the last doctest in decimal.py (in lexicographic order) is
Decimal.__round__, which ends with
>>> round(Decimal('sNaN123'), 0)
Decimal(&
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
I was leaning towards the "doctest should not pollute the __builtins__
module" side.
test_decimal might not be the only test that leaks one object outside
the module.
___
P
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
Here is another patch that modifies doctest itself.
Note that the _ is cleared only if "clear_globs" is True, which makes
sense IMO.
Index: Lib/doctest.py
==
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
You know what? It's a mess.
- from the __main__ module, __builtins__ is a module.
- in all other modules, __builtins__ is a dict.
The fix is correct for most modules:
./python Lib\test\test_decimal.py
but fails for
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
It is actually documented, at the bottom of
http://docs.python.org/dev/library/__builtin__.html
"import builtin" is the correct thing to do.
___
Python tracker <
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
I am working on Thomas' patch, plus tests.
--
assignee: -> amaury.forgeotdarc
nosy: +amaury.forgeotdarc
___
Python tracker <[EMAIL PROTECTED]>
<http
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
I'm quite sure that neither the patch nor the new test make sense on
Windows. A file handle is not a file descriptor!
--
nosy: +amaury.forgeotdarc
___
Python tracker &
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
It's indeed better.
Now with when running my previous script I can see the exception ;-)
Exception in thread Thread-2:
Traceback (most recent call last):
File "C:\dev\python\trunk1\lib\threading.py", line
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
> If it was rewritten to use a fixed-size bytearray
does such an object exist today?
___
Python tracker <[EMAIL PROTECTED]>
<http://bu
New submission from Amaury Forgeot d'Arc <[EMAIL PROTECTED]>:
functions with keyword-only arguments have this form:
def f(x, *args, y):
pass
parameters can appear after the *arg, they are required to be passed by
keyword.
It would be more consistent to allow this fu
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
Committed r65320 in trunk.
I'll close the issue after it is merged into py3k.
--
resolution: -> fixed
status: open -> pending
___
Python tracker <[EMAIL PROTECTED]
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
Should this apply to 2.6 as well? See r65321, I find the last line
easier to read when arguments are in this order.
def grouper(n, iterable, fillvalue=None):
args = [iter(iterable)] * n
return izip_lo
New submission from Amaury Forgeot d'Arc <[EMAIL PROTECTED]>:
See http://docs.python.org/dev/reference/expressions.html#id9
the production rule for "argument_list" is not properly indented.
It seems that the first line is indented up to the widest name of the
list, but subs
Changes by Amaury Forgeot d'Arc <[EMAIL PROTECTED]>:
--
keywords: +patch
Added file: http://bugs.python.org/file11010/kwargs30.patch
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
Patches for both versions are attached.
Added file: http://bugs.python.org/file11011/kwargs26.patch
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
Ok for s#.
But t# uses bf_getcharbuffer(), which does not seem to lock anything.
I wonder if this can lead to the same kind of problems, for example when
calling file_write with a
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
Confirmed.
This happens on architectures where sizeof(long) > sizeof(int):
builtin_unichr() converts its argument to a long, but calls
PyUnicode_FromOrdinal() which accepts an int.
--
assignee: -> amaury
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
Committed r65339.
Will not backport to 2.5: code that used to (approximately) work would
break.
Thanks for the report!
--
resolution: -> fixed
status: open -> closed
_
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
Committed r65343: os.fdopen accepts the same parameters as io.open().
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
The struct module is correct.
You see here the result of "alignment": the address of a long is always
a multiple of the size of a long.
The struct module mimics the C compiler: a "struct { short x; long y;
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
> Assertion failed: (bp != NULL), function PyObject_Malloc, file
> Objects/obmalloc.c, line 755.
This one gives one probable cause of the problem:
- in Modules/_multiprocessing/connection.h, connection_send_obj()
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
To be complete, the patch should also deal with conn_recv_string() which
has the same problem.
And please do not forget the win32 implementation, in pipe_connection.c.
___
Python trac
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
Martin,
There is a small issue with the patch: in the "w#" format handler,
bf_getwritebuffer(arg, 0, res) is wrong. The third argument should be
&res (there is a compilation warning on windows),
And a fe
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
Mark,
There are 3 semicolons missing in your patch, in pipe_connection.c, just
after the calls to WriteFile and ReadFile.
After this, it compiles and runs correctly. Tests pass.
Note that on Windows, your "nine lines&qu
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
I will not have internet access for the next week.
Raymond, would you take care of this issue?
--
assignee: amaury.forgeotdarc -> rhettinger
___
Python tracker <[EMAIL
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
Barry, is it still time for this to be included in 2.6b3?
Guido already approved the idea:
http://mail.python.org/pipermail/python-3000/2008-July/014506.html
--
assignee: rhettinger -> amaury.forgeotdar
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
Maybe I missed something, but the (subclassable) python implementation
of Pickler is still available with another name:
from pickle import _Pickler as Pickler
class ForkingPickler(Pickler):
dispatch = Pickler.di
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
I cannot discuss about the feature itself, but the patch should
certainly use some macro ($(VERSION) ?) instead of the hardcoded "2.6".
Likewise, source files should not contain version number in their names,
or
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
I do not reproduce the problem, but in your example, the trace function
is called only when the script has finished, i.e during interpreter
shutdown. Creating a thread from there is not recommended...
Can you provide t
Changes by Amaury Forgeot d'Arc <[EMAIL PROTECTED]>:
--
assignee: -> amaury.forgeotdarc
nosy: +amaury.forgeotdarc
___
Python tracker <[EMAIL PROTECTED]>
<http://bu
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
I managed to get a proper traceback:
Exception in Tkinter callback
Traceback (most recent call last):
File "c:\afa\python\py3k\lib\tkinter\__init__.py", line 1405, in __call__
return self.func(*args)
Fil
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
Yes, this problem is a duplicate of #2234, for which I had a very
similar fix.
Thanks!
--
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMA
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
Fixed by r65834, thanks to the patch provided in issue3496.
Will backport.
--
nosy: +amaury.forgeotdarc
resolution: -> fixed
status: open -> closed
___
Python tracker
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
committed r65835 in the release25-maint branch.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
I could reproduce the problem, and it appears that it is the same as
#1608818, corrected by r65037:
on posix platforms, listdir() used to check for errno only at the end of
the list; the problem is that the trace functio
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
I guess that the file is simply opened in text mode ("r"). This uses the
"preferred encoding", which is cp1252 on (western) Windows machines.
--
nosy: +amaury.forgeotdarc
___
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
> but if the code that's being debugged
> spawned other threads (which is pretty common), it would be pointless,
No, the problem specifically lies in the implementation of listdir().
This function is not supp
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
There is a problem in your script.
On Windows, the remote processes have to import the mtest module, in
order to execute the get_size() function.
This in turn calls the main() function, which creates a new pool of
pro
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
Also, I was bitten by a runtime error because of an uninitialized variable.
It seems that the Microsoft compiler is able to detect uninitialized
values, in debug mode this causes a dialog to appear and IDLE crashes
when
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
Sorry, I did not notice the failure because test_multiprocessing have
other problems on Windows.
r65905 restores part of the copy_reg calls, just enough to let the tests
pass.
I am working on the proper fix, which is to use
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
The problem comes when PyErr_SetObject triggers garbage collection which
runs python code (finalizers...).
I could reproduce the crash several times, and each time garbage
collection was triggered by the normalization of th
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
> Having a snippet deterministically reproducing the problem
> would really help in any case.
Here you are. Don't ask how I found this.
The attached script, when run, prints
(KeyError(), ValueError())
(KeyError
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
Corrected as r65920. Thanks for the report!
--
nosy: +amaury.forgeotdarc
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http:/
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
[0, 1) denotes an interval, not a python object; 0 is included, 1 is
excluded.
And it follows (one of) the standard syntax to express intervals:
http://en.wikipedia.org/wiki/Interval_notation
--
nosy: +amaury.
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
Can you try with the following patch,
"throwflag" is specific to a generator being deleted.
Index: Python/ceval.c
===
--- Python/ceval.c (revis
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
This last proposal does not correct the behaviour of lostcontext.py.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
Short patch review: __context__ tests are mostly found in test_raise.py
(class TestContext)
test_exceptions.py seems to only deal with the exception object.
___
Python tracker <[E
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
Cygwin seems to have a broken implementation of mbstowcs.
See http://www.google.com/codesearch?q=cygwin+mbstowcs\(NULL
The attached patch corrects the problem.
--
keywords: +patch
nosy: +amaury.forgeotdarc
Added
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
I once fell into the same issue, but the patch should modify
_PyObject_Dump(), around the call to PyObject_Print.
string_print() is not the only function called by _PyObject_Dump, by far...
And beware that many people ro
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
Antoine, your script hangs at the end due to the io.py deadlock (see #3618)
- at the end of the script, flush_io() is called
- this enters code in io.py
- here, garbage collection occurs (thanks to low thresholds)
- the Bug
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
I found another way to loose the current exception context; see
lostcontext2.py
Completely removing the block starting with
if (why == WHY_EXCEPTION && !throwflag) {
corrects the script;
but according to Be
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
Victor, your patch addresses the symptom of the problem, not the cause.
The cause is that in some cases, the exception context chain is lost. Of
course what could be a minor annoyance becomes dramatic when this
precisely
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
The problem comes from this local variable in batch_list() and batch_dict:
PyObject *slice[BATCHSIZE];
and BATCHSIZE=1000...
--
nosy: +amaury.forgeotdarc
___
Python trac
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
Attached patch removes the big array, items are saved when they are
fetched from the container.
I preserved the the special case when there is only one item.
The patch does not merge cleanly into py3k, but the functions bat
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
The provided file does not work for "EXTENSION" characters:
>>> import ia5
>>> u"[a]".encode("ia5")
Traceback (most recent call last):
File "", line 1, in
Fil
New submission from Amaury Forgeot d'Arc <[EMAIL PROTECTED]>:
./python Lib/test/regrtest.py -R:: test_bytes
reveals a leak in py3k.
This is exactly the same as the one corrected by r65785 to bytearray.
(easy) patch attached, needs approval!
--
files: bytes-split.patch
keyw
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
Committed r65985
--
resolution: -> fixed
status: open -> closed
___
Python tracker <[EMAIL PROTECTED]>
<http:/
New submission from Amaury Forgeot d'Arc <[EMAIL PROTECTED]>:
version 3.0, any call to eval() leaks one reference:
>>> eval('1')
1
[42093 refs]
>>> eval('1')
1
[42094 refs]
>>> eval('1')
1
[42095 refs]
>>> eval(
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
The leaked reference refers to the bytes object which encodes the code
being compiled:
>>> for x in range(1000): compile("1", "test", "eval")
>>> sys.getrefcount(b'1')
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
Benjamin: yes, test_bytes calls eval() 128 times.
Christian: please "svn up", I just corrected another leak in bytesobject.c
___
Python tracker <[EMAIL PROTECTED]>
<ht
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
The attached patch corrects the eval() and compile() reference leak.
The problem is in PyObject_AsReadBuffer.
Needs review: view->obj seems to own the reference, but object.h say the
opposite.
--
keywords: +needs
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
PyObject_AsCharBuffer is affected as well.
This fixes for me the last refleak in test_bytes.
Added file: http://bugs.python.org/file11224/buffer-leak.patch
___
Python tracker <[E
Changes by Amaury Forgeot d'Arc <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file11223/buffer-leak.patch
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
Benjamin,
I am testing the patch proposed earlier by Victor in
http://bugs.python.org/msg71579 (who might be the correct one, after all),
and I don't see the problems you mentioned.
I run the test suite without p
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
Of course, I forgot PyObject_AsWriteBuffer in my patch.
I wonder if turning view.obj into an owned reference was a good idea.
There are more calls to bf_getbuffer (in getarg.c), they leak too:
test_struct leaked
Changes by Amaury Forgeot d'Arc <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file11224/buffer-leak.patch
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.
Changes by Amaury Forgeot d'Arc <[EMAIL PROTECTED]>:
--
assignee: -> loewis
nosy: +loewis
___
Python tracker <[EMAIL PROTECTED]>
<http://bu
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
You could start with utf_8.py, and of course replace the calls to
codecs.utf_8_encode and codecs.utf_8_decode.
- your "ia5_encode" follows this interface:
http://docs.python.org/dev/library/codecs.html#codecs
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
Adapted the patch to python 3.0
Added file: http://bugs.python.org/file11228/cpickle-3.0.patch
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
The main cause of these leaks is each time PyArg_ParseTuple("s#") is
passed a bytes object.
If FillInfo() increfs the given object, every object should have a
bf_releaseb
Changes by Amaury Forgeot d'Arc <[EMAIL PROTECTED]>:
--
resolution: -> duplicate
status: open -> closed
superseder: -> eval() leaks 1 reference every time
___
Python tracker <[EMAIL PROTECTED]>
<htt
New submission from Amaury Forgeot d'Arc <[EMAIL PROTECTED]>:
The following output is very suspect: the total number of references
decreases!
Python 3.0b3+ (py3k, Aug 24 2008, 21:56:40) [MSC v.1500 32 bit (Intel)]
on win32
Type "help", "copyright", "credit
New submission from Amaury Forgeot d'Arc <[EMAIL PROTECTED]>:
With python2.6, reloading extension modules does not always leak memory:
Python 2.6b2+ (trunk, Aug 19 2008, 23:45:24) [MSC v.1500 32 bit (Intel)]
on win32
Type "help", "copyright", "credit
New submission from Amaury Forgeot d'Arc <[EMAIL PROTECTED]>:
When PyArg_ParseTuple correctly parses a s* format, but raises an
exception afterwards (for a subsequent parameter), the user code will
not call PyBuffer_Release() and memory will leak.
Seen by "regrtest -R:: tes
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
This new version of the patch modifies getargs.c and use
PyObject_GetBuffer and PyBuffer_Release in place of the raw bf_getbuffer
and bf_releasebuffer.
Also make sure that each GetBuffer is matched with a ReleaseBuffer
(e
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
The "goto error" is not necessary here. Nothing has been allocated at
this point, and "return -1" is enough.
Index: Modules/_fileio.c
===
--
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
Updated patch with the additional PyBuffer_Release mentioned by Neal,
plus a proposition of entry for the NEWS file.
There is no doc about the new interface, so no update is needed :-(
See issue2619.
Added
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
Attached patch writes the "'import site' failed" message to libc stderr
instead of sys.stderr, which does not exist at this point.
The initial problem still remains: site.py cannot use the "open&qu
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
Agreed. PyErr_ExceptionMatches returns owned references, so the tb
variable has to remain an owned reference.
Patch attached, please review.
--
keywords: +needs review, patch
Added file: http://bugs.python.org/file11
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
This patch elegantly reuses the existing cleanup list.
Only two remarks:
- there are a few tabs/spaces inconsistencies.
- I would make the cleanup_ptr explicit:
intead of
addcleanup(*buffer, freelist, NULL);
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
Both patches look good to me.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3668>
___
___
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
Well, it would be interesting to know why r62778 has exactly the
opposite move.
Alexandre, do you remember doing it?
--
nosy: +alexandre.vassalotti
___
Python tracker <[E
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
Well, 3.0b3 is out and many bugs may have been corrected.
Can you try with this newer version?
--
nosy: +amaury.forgeotdarc
___
Python tracker <[EMAIL PROTECTED]>
<ht
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
This is actively being discussed (and developed) in issue3187
--
nosy: +amaury.forgeotdarc
resolution: -> duplicate
status: open -> closed
superseder: -> os.listdir can
Changes by Amaury Forgeot d'Arc <[EMAIL PROTECTED]>:
--
title: Error parsing arguments on OpenBSD <= 4.4 -> mbstowcs
___
Python tracker <[EMAIL PROTECTED]>
<http:/
Changes by Amaury Forgeot d'Arc <[EMAIL PROTECTED]>:
--
title: mbstowcs -> Error parsing arguments on OpenBSD <= 4.4
___
Python tracker <[EMAIL PROTECTED]>
<http:/
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
See also issue3626, which is exactly the same for cygwin.
Maybe a "./configure" paragraph could discover whether mbstowcs is broken.
I don't know how to do it though.
--
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
See also issue3626
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3626>
___
_
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
Isn't PyNumber_AsSsize_t designed for this purpose?
--
nosy: +amaury.forgeotdarc
___
Python tracker <[EMAIL PROTECTED]>
<http://
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
Here is another patch, which tries to replace all problematic usages of
mbstowcs, and a new "#define HAVE_BROKEN_MBSTOWCS" to activate it.
It needs a review, especially the "configure" stuff, it&#x
Changes by Amaury Forgeot d'Arc <[EMAIL PROTECTED]>:
--
priority: -> release blocker
___
Python tracker <[EMAIL PROTECTED]>
<http://bu
Changes by Amaury Forgeot d'Arc <[EMAIL PROTECTED]>:
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3626>
___
___
Python-bugs-list m
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
See also issue3696, and the patch provided there.
Yaakov, you should remove the _locale.dll from your build directory: for
the compilation phase, better have no locale at all than a broken "U" as
default encoding (
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
cygwin has also a nasty bug:
printf("%ls", wide_string)
fails for strings of length 1. %S has the same problem.
$ ./python.exe ab
./python: can't open file 'ab': [Errno 2] No such file or direc
Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:
There is a call to dircheck(), but not in the correct place.
The attached patch makes sure that the "Is a directory" message is not
overwritten.
--
keywords: +needs review, patch
nosy: +amaury.forgeotdarc
p
Changes by Amaury Forgeot d'Arc <[EMAIL PROTECTED]>:
--
keywords: +needs review
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3696>
___
___
801 - 900 of 2691 matches
Mail list logo
