New submission from
Christian Heimes
:
The patches changes:
- change PyString's repr() to return b'...'
- change PyBytes's repr() to return buffer(b'...')
- change parser so that b... returns PyString, not PyBytes
- rename
Christian Heimes added the comment:
Guido van Rossum wrote:
Guido van Rossum added the comment:
GHave you two agreed yet as to which patch(es) I should look at?
Please commit Alexandres patch. His patch for bytesobject.c is based on
my patch. It's more complete and a bit better than mine
Christian Heimes added the comment:
test_ctypes: works for me
test_email: need some help from an email expoert
test_httplib: __file__ has a wrong type str8. I'm looking into it.
test_inspect: same issue as httplib
test_os: same issue
test_re: I had the failing test before my changes
File Lib
Christian Heimes added the comment:
Guido van Rossum wrote:
Did you svn up, make clean and rebuild?
The ctypes package didn't change since my last rebuild an hour ago. I'm
on Linux (Ubuntu i386)
test_email: need some help from an email expoert
Which test is failing
New submission from Christian Heimes:
This is a *preliminary* patch for __file__ and co_filename which decodes
char* / PyString using the FS default encoding. I'm still working on it.
--
components: Interpreter Core
files: py3k_file_fsenc.patch
messages: 56345
nosy: tiran
severity
New submission from Christian Heimes:
The array module is using a different typecode for unicode array
depending on UCS2 or UCS4:
#define Py_UNICODE_SIZE 4
#if Py_UNICODE_SIZE = 4
#define Py_UNICODE_WIDE
#endif
#ifdef Py_UNICODE_WIDE
#define PyArr_UNI 'w'
#define PyArr_UNISTR w
#else
#define
New submission from Christian Heimes:
I'm sending the patch in for review.
--
components: Interpreter Core
files: py3k_file_fsenc2.patch
messages: 56374
nosy: tiran
severity: normal
status: open
title: Decode __file__ and co_filename to unicode using fs default
versions: Python 3.0
Christian Heimes added the comment:
svn annotate shows that you implemented the 'w' typecode in revision
57181. What do you think about my patch and my proposal?
--
nosy: +teoliphant
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1268
Christian Heimes added the comment:
Guido van Rossum wrote:
- You added a removal of hotshot from setup.py to the patch; but that's
been checked in in the mean time.
Oh, the change shouldn't make it into the patch. I guess I forgot a svn
revert on setup.py
- Why add an 'errors' argument
Christian Heimes added the comment:
Guido van Rossum wrote:
- Why copy the default encoding before mangling it? With a little extra
care you will only have to copy it once.
Now I remember why I added the strncpy() call plus encoding[31] = '\0'.
I wanted to make sure that the code doesn't
Christian Heimes added the comment:
Guido van Rossum wrote:
Guido van Rossum added the comment:
Crys, is this OK with you?
Alexandre's mangle loop doesn't do the same job as mine. Chars like _
and - aren't removed from the encoding name and the if clauses don't
catch for example UTF-8
Christian Heimes added the comment:
Alexandre Vassalotti wrote:
That isn't true. My mangler does exactly the same thing as your
original one.
However, I forgot to add Py_CHARMASK to the calls of tolower() and
isalnum() which would cause problems on platforms with signed char.
I wasn't
Christian Heimes added the comment:
Can this be closed now that Travis reverted his patch?
Yes, it can be closed.
By the way svn.python.org and the anon svn server are down the third
time this week. Something is wrong with the server.
Christian
__
Tracker
Christian Heimes added the comment:
Alexandre Vassalotti wrote:
Alexandre Vassalotti added the comment:
I thought of another way to implement PyUnicode_DecodeFSDefault. If
Py_FileSystemDefaultEncoding is set, decode with the codecs module,
otherwise use UTF-8 + replace. This works because
Christian Heimes added the comment:
Oh stop, the array module doesn't build for me (Ubuntu Linux, i386,
UCS-4 build, rev58458):
Modules/arraymodule.c: In function 'array_buffer_getbuf':
Modules/arraymodule.c:1815: error: 'Py_buffer' has no member named 'formats'
Please replace formats
Christian Heimes added the comment:
Changes since updated_file_fsenc-5.patch:
* Fix for hard coded FS default encoding on Apple and Windows
* Added two notes to unicode_default_encoding and
Py_FileSystemDefaultEncoding
__
Tracker [EMAIL PROTECTED]
http
Christian Heimes added the comment:
UnicodeDecodeError: 'utf8' codec can't decode bytes in position
1428-1430: invalid data
I can't reproduce this. Can you open a separate issue?
It breaks for me with the same error message on Ubuntu Linux, i386,
UCS-4 build and locale de_DE.UTF-8
Christian Heimes added the comment:
This looks promising. I'm working on the freeze issue. Once I get that
working I'll check this in. Thanks Alexandre and Christian for all
your hard work!!!
You're welcome. Does the patch qualify me for Misc/ACKS? :)
I'm going to work on the basestring
Christian Heimes added the comment:
I found two minor bugs in the fix. In Modules/posixmodule.c the tmpnam()
and tempnam() methods return a PyString instance. Please change line
5373 and 5431 to use PyUnicode_DecodeFSDefault().
Index: Modules/posixmodule.c
New submission from Christian Heimes:
imp.find_module() returns an io.TextIOWrapper instance first value. The
encoding of the TextIOWrapper isn't set from a -*- coding: Latin-1 -*- line.
import imp
imp.find_module(heapq)
(io.TextIOWrapper object at 0xb7c8f50c,
'/home/heimes/dev/python/py3k
Christian Heimes added the comment:
Here is an updated patch which applies cleanly and fixes some additional
unit tests and removes one that doesn't make sense any more (re.compile
doesn't accept bytes).
The unit tests profile, cProfile and doctest fail w/ and w/o this patch.
They seem
Christian Heimes added the comment:
Can you suggest a patch?
Adding Brett Cannon to the list, possibly his import-in-python would
supersede this?
No, I can't suggest a patch. I don't know how we could get the encoding
from the tokenizer or AST.
Brett is obviously the best man to fix
Christian Heimes added the comment:
Try harder. :-) Look at the code that accomplishes this feat in the
regular parser...
I've already found the methods that find the encoding in
Parser/tokenizer.c: check_coding_spec() and friends.
But it seems like a waste of time to use
Christian Heimes added the comment:
I've some code around which sets sys.stdin, out and err in C code. The
code is far from perfect and I haven't checked it for reference leaks
yet. I like to get your comment on the style and error catching.
--
nosy: +tiran
Christian Heimes added the comment:
Any details on those? They don't fail for me.
Here you are.
$ ./python Lib/test/test_cProfile.py
121 function calls (101 primitive calls) in 1.000 CPU seconds
Ordered by: standard name
ncalls tottime percall cumtime percall
Christian Heimes added the comment:
Guido van Rossum wrote:
BTW we need a 2to3 fixer for this. Should be trivial -- just replace
*all* occurrences of basestring with str.
I believe you that it's trivial for *you* but I've never dealt with the
fixers or the grammar. Fortunately for me I
Christian Heimes added the comment:
I've carefully checked and tested the initstdio() method. I'm sure that
I've catched every edged case. The unit tests pass w/o complains.
I've also added a PyErr_Display() call to Py_FatalError(). It's still
hard to understand an error in io.py but at least
Christian Heimes added the comment:
Guido van Rossum wrote:
Don't call open() with keyword arg for newline=\r; open() takes
positional args too. This is done specifically to simplify life for C
code calling it. :-) Perhaps one of the PyFunction_Call(..) variants
makes it easier to call
Christian Heimes added the comment:
The patch is a combined patch for the imp.find_module() problem and
initstdio. Both patches depend on the new PyFile_FromFileEx() function.
I hope you don't mind.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1267
Christian Heimes added the comment:
Christian Heimes wrote:
* removed unused import of open in initstdio()
* fixed infinite loop in PyTokenizer_FindEncoding() by checking
tok-done == E_OK
I found another bug in Python/import.c:call_find_method. The function
mustn't set an encoding of ftp
Christian Heimes added the comment:
Update since last patch
* removed unnecessary const from const char*
PyTokenizer_FindEncoding(FILE *fp)
* Fixed bug in find_module whith binary files
Please review the patch.
__
Tracker [EMAIL PROTECTED]
http
Christian Heimes added the comment:
The bug was fixed in r58553 together with
http://bugs.python.org/issue1267. Please close this bug.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1278
New submission from Christian Heimes:
The patch fixes the output for profile and cProfile. Another patch from
Alexandre and me added additional calls to the UTF-8 codec.
--
components: Library (Lib)
messages: 56569
nosy: gvanrossum, tiran
severity: normal
status: open
title: Fixes
Christian Heimes added the comment:
Brett Cannon wrote:
Brett Cannon added the comment:
It looks like the file object returned by imp.find_module() has its read
position WAY too far forward (at least on OS X).
That's strange. It should never read more than 2 lines of a file. I
don't
Christian Heimes added the comment:
runpy is failing because pkgutil is failing because it is giving
compile() part of a source file instead of the entire thing::
Traceback (most recent call last):
File /Users/drifty/Dev/python/3.x/pristine/Lib/runpy.py, line 97,
in _run_module_as_main
Christian Heimes added the comment:
It's unrelated to the problem but Parser/tokenizer.c:1619 has a minor bug.
while(((tok-lineno = 2) (tok-done == E_OK))) {
PyTokenizer_Get(tok, p_start, p_end);
}
(tok-lineno 2) is sufficient. See line 516
Christian
Christian Heimes added the comment:
I don't have a Mac at my disposal any more. :(
Can you attach the output of the failing tests to the bug report? Maybe
I can be of assistance.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1267
Christian Heimes added the comment:
Brett Cannon wrote:
Brett Cannon added the comment:
OK, for some reason, when PyTokenizer_FindEncoding() is called and the
resulting file is big enough, it starts off with a seek position
(according to TextIOWrapper.tell()) of 4096. That happens
Christian Heimes added the comment:
I've made a short unit tests which tests a large file with and w/o -*-
coding: -*-. It passes on Linux.
Added file: http://bugs.python.org/file8575/py3k_test_issue1267.patch
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org
Christian Heimes added the comment:
Brett Cannon wrote:
This suggests that perhaps we should standardize on file pointers or
file descriptors in Python to prevent something like this from happening
again.
rewind() it used couple of times in the Python code. Have you checked if
the other
Christian Heimes added the comment:
Sure there is a patch ... well it's ... *uhm* ... it's hidden under your
bed. O:-)
Added file: http://bugs.python.org/file8569/py3k_profile_fix.patches
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1302
Christian Heimes added the comment:
Brett Cannon wrote:
Thanks. I just wish this whole ordeal had not been necessary (filed a
bug report with Apple in hopes that this can be prevented for someone
else). I can see why some people prefer to hack on PyPy, IronPython,
or Jython instead
Christian Heimes added the comment:
Guido van Rossum wrote:
You're right that a lot of this could be avoided if we used file
descriptors consistently. It seems find_module() itself doesn't read
the file; it just needs to know that it's possible to open the file.
Rewriting everywhere
Christian Heimes added the comment:
Yes, I think you got it.
Guido, Brett, how much of the code should I change? import.c is mainly
using file pointers. Should I replace all operations on FILE with
operations on a file descriptor?
Christian
__
Tracker [EMAIL
Christian Heimes added the comment:
Guido van Rossum wrote:
I think find_module() should return a file descriptor (fd), not a
FILE*, but most of the rest of the code should call fdopen() on that
fd. Only call_find_module() should use the fd to turn it into a Python
file object
Christian Heimes added the comment:
The new patch does a far more better job. I had the idea after a
discussion with Alexandre on #python and a small debugging session.
The tests for profile, cProfile and doctest are failing on my Linux box
because Py_FileSystemDefaultEncoding is UTF-8
Christian Heimes added the comment:
I think find_module() should return a file descriptor (fd), not a
FILE*, but most of the rest of the code should call fdopen() on that
fd. Only call_find_module() should use the fd to turn it into a Python
file object. Then the amount of change should
Christian Heimes added the comment:
Guido van Rossum wrote:
Guido van Rossum added the comment:
Do you have access to Windows? I believe it doesn't have dup(). :-(
I've an old laptop with Win2k at my disposal but it has no VS yet. Can
you point me to a set of instruction how to install VS
New submission from Christian Heimes:
bytes_methods.c isn't in PCbuild/pythoncore.vcproj
--
components: Windows
files: py3k_pcbuild_bytes.patch
messages: 56632
nosy: tiran
severity: normal
status: open
title: windows build fix
type: compile error
versions: Python 3.0
Added file: http
Christian Heimes added the comment:
Guido van Rossum wrote:
You might want to compare what I checked in to your patch; I did a few
style cleanups. I also moved the lseek() call into import.c, where it
seems more appropriate.
Ah I see that you prefer to keep assignment and check against NULL
New submission from Christian Heimes:
tempfile breaks on Windows because exception objectss no longer support
e[0]. The fix is simple and short:
Index: Lib/tempfile.py
===
--- Lib/tempfile.py (Revision 58587)
+++ Lib
Christian Heimes added the comment:
os.tmpfile() is the only method that has no duplicate in tempfile. I
chose to keep it for this very reason. But you made good point, too.
What do you think about renaming tmpfile to _tmpfile and make it
available from the tempfile module as tempfile.tmpfile
Christian Heimes added the comment:
Why should I use (sizeof(lower)-1)? Do you mean
PyMem_Malloc(strlen(encoding) + 1)?
Changes since last patch:
* added #include bytes_methods.h in unicodeobject.c
* fix all is* to use the macros from bytes_methods.h
* use malloc/free the lower version instead
Christian Heimes added the comment:
Guido van Rossum wrote:
Christian can you revise your patch to also remove os.tmpfile per
Martin's request? Make sure unit tests and docs are fixed too.
I can do that for you. But I still believe that os.tmpfile() works
different than tempfile.mkstemp
Changes by Christian Heimes:
Added file: http://bugs.python.org/file8612/py3k_remove_os_tmp.patch
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1318
__
___
Python-bugs-list
Christian Heimes added the comment:
Guido van Rossum wrote:
Guido van Rossum added the comment:
Committed revision 58659.
I'm sorry I confused you; I was fine with the version that has char
lower[N] but I wanted you to not repeat N-1 later in the code. See what
I checked in. :-)
I
Christian Heimes added the comment:
Alexandre Vassalotti wrote:
It the address of lower[18] to be exact. (l lower[(sizeof lower) -
2]) is simply tricky notation to check the bound of the array.
Personally, I used like to subtract pointer, ((lower - l + 1) (sizeof
lower)) to get the bound
New submission from Christian Heimes:
The patch fixes for real what Patch # 1323 by Amaury Forgeot d'Arc
claims to have fixed. I reverted his patch to io.py and implemented the
fix in the Windows specific part of truncate in _fileio.c. It fixes two
tests for raw io on Windows
Changes by Christian Heimes:
--
nosy: +gvanrossum, nnorwitz
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1330
__
___
Python-bugs-list mailing list
Unsubscribe:
http
New submission from Christian Heimes:
The patch fixes some of the problems on Windows. It doesn't introduce
addition problems on Linux.
--
components: Library (Lib)
files: py3k_misc_win.patch
messages: 56770
nosy: gvanrossum, nnorwitz, tiran
severity: normal
status: open
title: More
Christian Heimes added the comment:
Ony my Ubuntu box lsb_release is just a small Python script that parses
/etc/lsb-release. I suggest that your read the LSB standards about the
file and use the information to parse it instead of invoking a program.
--
nosy: +tiran
Christian Heimes added the comment:
[EMAIL PROTECTED]:~$ /usr/bin/lsb_release -a
LSB Version:
core-2.0-noarch:core-3.0-noarch:core-3.1-noarch:core-2.0-ia32:core-3.0-ia32:core-3.1-ia32:cxx-2.0-noarch:cxx-3.0-noarch:cxx-3.1-noarch:cxx-2.0-ia32:cxx-3.0-ia32:cxx-3.1-ia32:graphics-2.0
Christian Heimes added the comment:
While I like fixing the position restore in _fileio.c, I also liked
Amaury's flush() call in _BufferedIOMixin. Perhaps you can keep that
part (while losing the position restore)?
Good point. We have to call flush() in _BufferedIOMixin as you said. I
Christian Heimes added the comment:
Can you also use a global variable instead of /etc? Something like
ETC_DIR = /etc for example. It would allow you to ship samples from
several distribution and run unit tests against each.
I've attached the two relevant files from Ubuntu 7.10 Gutsy.
Added
New submission from Christian Heimes:
Here is the long promised bytes iterator view. It was much, *much*
easier to write it than I have thought. In fact I spent more time fixing
the indention than to modify the code from striterator.
I haven't written an unit test for it. The other iterators
New submission from Christian Heimes:
Python 3.0 doesn't run from a directory with umlauts and possible other
non ASCII chars.
I renamed my development folder from C:\dev\ to c:\test äöüß name\.
Python crashes after a few moments before it can reach its shell.
python30.dll
Christian Heimes added the comment:
I think the problem is solved now. I haven't seen glob crashing for a while.
--
nosy: +tiran
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1042
Christian Heimes added the comment:
Here is the patch that contains only the harmless parts of the previous
patches. It changes a bunch of doc strings, changes the name of the
types and their repr() and str(). It also adds __builtin__.buffer but it
leaves __builtin__.bytes, __builtin__.str8
Christian Heimes added the comment:
The patch fixes parts of the problem. At least Python doesn't crash any
more when run from a directory with non ASCII chars. It just fails with
an import error in initstdio().
Added file: http://bugs.python.org/file8633/py3k_more_win_fsencoding.patch
Christian Heimes added the comment:
I've added a fprintf(stderr, %s, path) to makepathobject(). I suspect
that PC/getpathp.c doesn't handle non ASCII chars correctly. It's using
char instead of w_char all over the place. Could that be related to the
issue, Neal?
Microsoft Windows XP [Version
Christian Heimes added the comment:
Warren DeLano wrote:
So I guess that automatically puts me in the **highly-
motivated/willing-to-help** camp, if there's anything useful I can
actually do towards 2.5.2.
You can check every bugs related to 2.5 with urgent, high or no priority
and see
Christian Heimes added the comment:
The patch is fine but you should add a short comment to avoid future
trouble. On the first glance it's not obvious why the StringIO instance
mustn't have a newline argument.
--
nosy: +gvanrossum, tiran
__
Tracker
New submission from Christian Heimes:
Index: Lib/test/test_netrc.py
===
--- Lib/test/test_netrc.py (revision 58695)
+++ Lib/test/test_netrc.py (working copy)
@@ -25,7 +25,7 @@
mode = 'w'
if sys.platform
Christian Heimes added the comment:
Confirmed!
Python 3.0 doesn't start at all on Windows when an environment variable
with non ASCII chars is present. This bug is related to
http://bugs.python.org/issue1342.
However on Linux Python 3.0 can handle unicode characters in paths and
environ vars
New submission from Christian Heimes:
Here is another patch related to stdio from me. It creates and sets up a
very dumb and easy stderr writer until the new io infrastructure is
initialized. It makes debugging problems in the init phase much easier.
--
components: Interpreter Core
Christian Heimes added the comment:
Guido van Rossum wrote:
Guido van Rossum added the comment:
D'oh, I submitted to the wrong branch. The py3k branch will have to
wait until after my son's birthday party. ;-)
Have a nice party! How old is he? IIRC he was about 4 on the pictures
you
Christian Heimes added the comment:
Can you try this patch, please? It has the same effect as the other
patch from Neal but it doesn't loose ref counts. I've patched the
dealloc function of _FileIO to keep fd 1 and fd 2 open.
Index: Modules/_fileio.c
Christian Heimes added the comment:
Martin v. Löwis wrote:
I'm skeptical:
- If you add getsize, why not getlastchangeddate, getowner, getpermissions?
getowner() etc. work only with file based streams and not with memory
buffers. getsize() works with every concrete class in io.py
Christian Heimes added the comment:
Here you go, Guido!
Added file: http://bugs.python.org/file8647/py3k_closefd.patch
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1329
__Index: Python/pythonrun.c
Christian Heimes added the comment:
Improved patch
--
nosy: +gvanrossum
Added file: http://bugs.python.org/file8648/py3k_preliminary_stderr2.patch
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1352
__Index
Christian Heimes added the comment:
Kevin,
It's a known issue which is solved in newer version of OpenSSL. I hope
to convince somebody to update the packages someday.
--
nosy: +tiran
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1320
Christian Heimes added the comment:
Please run the test suite in verbose mode and attach the output:
$ ./python Lib/test/regrtest.py -v test_cookielib test_email test_fileio
test_pipes test_uuid
You seem to missing some packages to build additional extensions. Can
you install sqlite, openssl
Christian Heimes added the comment:
Guido van Rossum wrote:
Shouldn't closefd be passed as 1 in import.c?
I don't see the point of distinguishing between -1 and +1. The block
if (closefd 0) { closefd = 1; } looks rather silly.
I used -1 as default to keep it consistent with buffer=-1. I
Christian Heimes added the comment:
Guido van Rossum wrote:
Are there any places where PyBytes or PyString are written to stderr?
Or can you get away with just supporting PyUnicode?
I could have simple copied the write method from _fileio.c and letting
the argument parser do its job instead
Christian Heimes added the comment:
Yann Cointepas wrote:
I joined a modified version of platform.py. Here is a summary of the
modification:
- replaced '/etc' by global variable _etc_dir
- removed supported_dists parameter of dist()
- each element of dist() result is searched
Changes by Christian Heimes:
--
components: +Library (Lib), Tests
versions: +Python 2.6 -Python 2.5
Added file: http://bugs.python.org/file8664/platform_py25.patch
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1322
Christian Heimes added the comment:
Guido van Rossum wrote:
Are you sure this is the proper fix? Why does netrc.py insist on not
having \r\n line endings? It opens the file in text mode so I don't
quite understand your patch.
I don't quite understand why it fails. :/ I've to take more time
Christian Heimes added the comment:
Guido van Rossum wrote:
Guido van Rossum added the comment:
OK, thanks. The closefd part is good, but the stderrprinter part has a
problem. On Linux, in a non-debug build, this has the odd side effect
of subtracting one from sys.maxunicode. In a debug
Christian Heimes added the comment:
Guido van Rossum wrote:
I've checked in the patch you added to issue 1329, with one mod: where
you wrote int fd : 1; I removed the : 1 since a field width of one
bit makes no sense here.
Can you close http://bugs.python.org/issue1771260, too?
Christian
Christian Heimes added the comment:
Hi Martin!
Thomas Wouters said on #python that you have the Windows Fu to fix the
problem. Parts of the Python API for file paths, sys.path and os.environ
have to be reimplemented using the wide char API.
--
nosy: +loewis
Christian Heimes added the comment:
Here it is.
patch + unit test
Added file: http://bugs.python.org/file8670/py3k_pystring_ssize.patch
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1365
__Index: Objects/stringobject.c
Christian Heimes added the comment:
I was able to reproduce the bug on Windows with Python 2.6 and 3.0. I've
added an unit test to both versions.
--
nosy: +tiran
priority: - low
resolution: - accepted
versions: +Python 2.6, Python 3.0
__
Tracker [EMAIL
Christian Heimes added the comment:
Here is a patch that solves the problem. However the patch is against
the py3k sources and I like somebody to review and test it. I don't have
enough disk space in my VMWare box to test it against the trunk or 2.5.
Reason for the problem: Windows' stat
Christian Heimes added the comment:
Fixed patch. Georg pointed out that PyArg_ParseTuple(s) returns a
reference to the internal data of the PyString object. The new version
copies the path to a fixed width buffer before it mangles the trailing
slashes.
The new patch applies against the trunk
Changes by Christian Heimes:
--
keywords: +patch, py3k
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1373
__
___
Python-bugs-list mailing list
Unsubscribe:
http
Changes by Christian Heimes:
--
keywords: +patch
priority: - high
resolution: - accepted
versions: +Python 2.6, Python 3.0
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1372
Christian Heimes added the comment:
The bug makes debugging a crux :(
--
priority: - high
resolution: - accepted
type: - behavior
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1265
Christian Heimes added the comment:
Applied in r58831
Thanks!
--
keywords: +patch, py3k
nosy: +tiran
resolution: - fixed
status: open - closed
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1380
Christian Heimes added the comment:
I'm going to disable the test for now.
--
keywords: +py3k
resolution: - accepted
superseder: - Crash on Windows if Python runs from a directory with umlauts
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org
Christian Heimes added the comment:
I've checked in part of the patch in r58837. It doesn't solve the
problem but at least it prevents Python from seg faulting on Windows.
--
keywords: +py3k, rfe
priority: - high
resolution: - accepted
__
Tracker
1 - 100 of 6455 matches
Mail list logo