[issue10570] curses.tigetstr() returns bytes, but curses.tparm() expects a string

STINNER Victor added the comment: See also #12567. -- ___ Python tracker <http://bugs.python.org/issue10570> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue12567] curses implementation of Unicode is wrong in Python 3

STINNER Victor added the comment: See also #10570. -- ___ Python tracker <http://bugs.python.org/issue12567> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue12669] test_curses skipped on buildbots

STINNER Victor added the comment: > Correction: the offending options are -j and *-W* I changed regrtest -W recently to only run the tests once using StringIO as stdout. So it's a regression in Python 3.3. Can't we create a dummy/temporary TTY for the curses tests usin

[issue9561] distutils: set encoding to utf-8 for input and output files

STINNER Victor added the comment: > Ping. What's the progress on this? Will this ever be fixed? Some functions has been fixed in the new packaging module, but not in the distutils yet. -- ___ Python tracker <http://bugs.python.or

[issue12700] test_faulthandler fails on Mac OS X Lion

STINNER Victor added the comment: > After changing NULL to (int *)1, all tests pass. Ok, so Lion has a special case for reading from NULL. I changed the tests to try to fix your bug. Can you tell me if it's now better? -- ___ Python tracke

[issue12700] test_faulthandler fails on Mac OS X Lion

STINNER Victor added the comment: > All tests now pass. Ok, thanks for your report and your feedback. -- resolution: -> fixed status: open -> closed ___ Python tracker <http://bugs.python.or

[issue12699] strange behaviour of locale.getlocale() -> None, None

STINNER Victor added the comment: It should be related to #6203. -- nosy: +haypo ___ Python tracker <http://bugs.python.org/issue12699> ___ ___ Python-bugs-list m

[issue9528] Add pure Python implementation of time module to CPython

STINNER Victor added the comment: @alanjds: Why do you add Python 2.7 version to this issue? -- ___ Python tracker <http://bugs.python.org/issue9528> ___ ___

[issue2857] Add CESU-8 codec ("java modified utf-8")

Changes by STINNER Victor : -- title: add codec for java modified utf-8 -> Add CESU-8 codec ("java modified utf-8") ___ Python tracker <http://bugs.pyth

[issue11230] "Full unicode import system" not in 3.2

STINNER Victor added the comment: > The issue I'm thinking about is that the Mac HSF+ filesystem There is no issue with HFS+ normalization. The kernel "normalizes" filenames to its own variant, Python doesn't have to care about this. When you write "import h<é

[issue2857] Add "java modified utf-8" codec

STINNER Victor added the comment: > Python does have other "weird" encodings like bz2 or rot13. No, it has no more such weird encodings. -- ___ Python tracker <http://bugs.pyth

[issue12746] normalization is affected by unicode width

STINNER Victor added the comment: See also #12737. -- ___ Python tracker <http://bugs.python.org/issue12746> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue12737] str.title() is overzealous by upcasing combining marks inappropriately

STINNER Victor added the comment: See also #12746. -- ___ Python tracker <http://bugs.python.org/issue12737> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue12751] Use macros for surrogates in unicodeobject.c

New submission from STINNER Victor : A lot of code is duplicated in unicodeobject.c to manipulate ("encode/decode") surrogates. Each function has from one to three different implementations. The new decode_ucs4() function adds a new implementation. Attached patch replaces this code

[issue12751] Use macros for surrogates in unicodeobject.c

STINNER Victor added the comment: We may use the following unlikely macro for IS_SURROGATE, IS_HIGH_SURROGATE and IS_LOW_SURROGATE: #define likely(x) __builtin_expect(!!(x), 1) #define unlikely(x) __builtin_expect(!!(x), 0) I suppose that we should use microbenchmarks to validate

[issue12751] Use macros for surrogates in unicodeobject.c

Changes by STINNER Victor : -- nosy: +belopolsky ___ Python tracker <http://bugs.python.org/issue12751> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue12751] Use macros for surrogates in unicodeobject.c

STINNER Victor added the comment: > This has been proposed already in #10542 (the issue also has patches). The two issues are different: this issue is only a refactoring, whereas #10542 adds a new "feature" (function/macro: Py

[issue12755] Service application crash in python25!PyObject_Malloc

STINNER Victor added the comment: Are you sure that errorString is not NULL? It looks like a bug in your application, not in Python. -- nosy: +haypo ___ Python tracker <http://bugs.python.org/issue12

[issue10744] ctypes arrays have incorrect buffer information (PEP-3118)

Changes by STINNER Victor : -- nosy: +haypo ___ Python tracker <http://bugs.python.org/issue10744> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue12760] Add create mode to open()

STINNER Victor added the comment: I'm not sure that O_EXCL is portable (exist on all platforms) because Python source code uses "#ifdef O_EXCL". -- nosy: +haypo ___ Python tracker <http://bugs.pyt

[issue12765] test_packaging failure under Snow Leopard

STINNER Victor added the comment: [309/358/1] test_packaging [70190 refs] test_formats (packaging.tests.test_command_bdist.BuildTestCase) ... ok test_show_formats (packaging.tests.test_command_bdist.BuildTestCase) ... ok test_skip_build (packaging.tests.test_command_bdist.BuildTestCase) ... ok

[issue10542] Py_UNICODE_NEXT and other macros for surrogates

STINNER Victor added the comment: I'm reposting my patch from #12751. I think that it's simpler than belopolsky's patch: it doesn't add public macros in unicodeobject.h and don't add the complex Py_UNICODE_NEXT() macro. My patch only adds private macros in unicode

[issue10542] Py_UNICODE_NEXT and other macros for surrogates

STINNER Victor added the comment: My patch version 2: don't test for a specific major version of an OS, test only its name. My patch now changes also tests for FreeBSD, NetBSD, OpenBSD, (...), and the _expectations list in regrtest.py. -- Added file: http://bugs.python.org/file

[issue10542] Py_UNICODE_NEXT and other macros for surrogates

Changes by STINNER Victor : Removed file: http://bugs.python.org/file22916/linux3-v2.patch ___ Python tracker <http://bugs.python.org/issue10542> ___ ___ Python-bug

[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'

STINNER Victor added the comment: My patch version 2: don't test for a specific major version of an OS, test only its name. My patch now changes also tests for FreeBSD, NetBSD, OpenBSD, (...), and the _expectations list in regrtest.py. -- Added file: http://bugs.python.org/file

[issue10542] Py_UNICODE_NEXT and other macros for surrogates

Changes by STINNER Victor : -- Removed message: http://bugs.python.org/msg142225 ___ Python tracker <http://bugs.python.org/issue10542> ___ ___ Python-bugs-list m

[issue10542] Py_UNICODE_NEXT and other macros for surrogates

STINNER Victor added the comment: (oops, msg142225 was for issue #12326) -- ___ Python tracker <http://bugs.python.org/issue10542> ___ ___ Python-bugs-list mailin

[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'

Changes by STINNER Victor : Removed file: http://bugs.python.org/file22613/linux3.patch ___ Python tracker <http://bugs.python.org/issue12326> ___ ___ Python-bugs-list m

[issue10542] Py_UNICODE_NEXT and other macros for surrogates

STINNER Victor added the comment: > The code review links point to something weird. That's because I posted a patch for another issue. It's the patch set 5, not the patch set 6 :-) Direct link: http://bugs.python.org/review/10542/patch/3174/9874 > My first impression is that

[issue12754] Add alternative random number generators

STINNER Victor added the comment: I don't know if it would help you, but I wrote a C library offering a simple API and supporting various RNG (cryptographic, hardware, pseudo, ...). It reuses existing libraries like GSL, OpenSSL, glib, gcrypt, etc. It supports UNIX/BSD /dev/*random de

[issue12754] Add alternative random number generators

STINNER Victor added the comment: "On my laptop, KISS4691 could produce about 110 million random numbers per second (148 millon if inlined), whereas MT19937 produced 118 million random numbers per second." The problem is that the Python API can only produce one number per

[issue10542] Py_UNICODE_NEXT and other macros for surrogates

STINNER Victor added the comment: Le 17/08/2011 07:04, Ezio Melotti a écrit : > As I said in msg142175 I think the Py_UNICODE_IS{HIGH|LOW|}SURROGATE and > Py_UNICODE_JOIN_SURROGATES can be committed without trailing _ in 3.3 and > with trailing _ in 2.7/3.2. They should go in unicod

[issue12755] Service application crash in python25!PyObject_Malloc

STINNER Victor added the comment: I close this issue because it looks like a bug in your application (you say that there is a least a buffer overrun). If it's really a bug in Python and you use a usecase to reproduce it, please reopen the issue. -- resolution: -> invali

[issue10542] Py_UNICODE_NEXT and other macros for surrogates

STINNER Victor added the comment: Ah yes, the correct prefix for functions working on Py_UNICODE characters/strings is "Py_UNICODE", not "PyUNICODE", sorry. >> For Python 2.7 and 3.2, I would prefer to not touch a public header, >> and so add the macros in un

[issue10542] Py_UNICODE_NEXT and other macros for surrogates

STINNER Victor added the comment: > OK, so in 2.7/3.2 I'll put them in unicodeobject.c It looks like #9200 only needs Py_UNICODE_NEXT, which can be implemented without the other Py_UNICODE_*SURROGATE* macros. -- ___ Python tracke

[issue12769] String with NUL characters truncated by ctypes when assigning to a char array

STINNER Victor added the comment: I don't think that it's a bug, but a feature. Example: buffer=ctypes.create_string_buffer(4) buffer.value='a\0bc' print("buffer.value=%r" % buffer.value) print("buffer.raw=%r" % buffer.raw) displays buffer.value='

[issue12567] curses implementation of Unicode is wrong in Python 3

STINNER Victor added the comment: > what needs to happen for them to move forward? I would like a review of curses_unicode.patch. -- ___ Python tracker <http://bugs.python.org/issu

[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'

STINNER Victor added the comment: > New changeset 50f1922bc1d5 by Victor Stinner in branch 'default': I will backport the fix to 2.7 and 3.2. -- ___ Python tracker <http://bugs.pytho

[issue12775] immense performance problems related to the garbage collector

Changes by STINNER Victor : -- nosy: +haypo ___ Python tracker <http://bugs.python.org/issue12775> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue12775] immense performance problems related to the garbage collector

STINNER Victor added the comment: Can you try to write a short example to reproduce the problem? -- ___ Python tracker <http://bugs.python.org/issue12

[issue12760] Add create mode to open()

STINNER Victor added the comment: > I don't know if it's documented behavior See #12103: it is not documented. -- ___ Python tracker <http://bugs.pytho

[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'

STINNER Victor added the comment: > I still think that sys.platform for the stable releases should > never report 'linux3' I don't understand why do you want to have a special case for Linux. sys.platform is already different for each major version of: * FreeBSD

[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'

STINNER Victor added the comment: > I'm just suggesting one more special case for linux* You suggest to have a special case in Python 2.7 and 3.2, but not in Python 3.3 (3.1, 2.6, etc.)? -- ___ Python tracker <http://bugs.python.org

[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'

STINNER Victor added the comment: > For Python 3.3, (...) In parallel we can change the stdlib > tests to use .startswith() done, see my changeset 50f1922bc1d5 -- ___ Python tracker <http://bugs.python.org/i

[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'

STINNER Victor added the comment: If we change Python 2.7.3 and 3.2.2 to force sys.platform to linux2 (instead of linux3) and use "linux" in Python 3.3, we will have 3 differents values of sys.platform if Python is built on Linux 3: - "linux3" on Python <= 2

[issue9200] Make str methods work with non-BMP chars on narrow builds

STINNER Victor added the comment: I don't think that macros specific to unicodeobject.c should get the _PY_UNICODE_ prefix. "_Py_" prefix is reserved to exported symbols, but symbols reserved for the Python interprefer itself. For _Py_UNICODE_NEXT, you can call it

[issue12784] Concatenation of strings returns the wrong string

Changes by STINNER Victor : -- nosy: +haypo ___ Python tracker <http://bugs.python.org/issue12784> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue12784] Concatenation of strings returns the wrong string

STINNER Victor added the comment: Try hash(buff_A) == hash(buff_B). Are you able to identify which bytes/characters are differents? -- ___ Python tracker <http://bugs.python.org/issue12

[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'

STINNER Victor added the comment: It's really hard to follow this issue. I'm trying to sum up, please comment my message if I'm wrong. -- If I understood correctly, this issue has 3 remaining points: (1) Python 2.7 and 3.2: force sys.platform to 'linux2'? Votes:

[issue12784] Concatenation of strings returns the wrong string

STINNER Victor added the comment: You should retry memtest86+: http://www.memtest.org/#downiso I had also memory errors recently. After 10 minutes, memtest86+ listed me 4 errors. After 30 minutes, there were 30 errors. -- ___ Python tracker <h

[issue12784] Concatenation of strings returns the wrong string

STINNER Victor added the comment: It's an hardware problem, not a Python problem, so I close this issue. Check your RAM and the temperature of your mother board and of the CPU using your tests (e.g. try lm-sensors on Linux). -- resolution: -> invalid status: open -

[issue12213] BufferedRandom, BufferedRWPair: issues with interlaced read-write

STINNER Victor added the comment: > You should not use BufferedRWPair with the same underlying stream (that's the > whole point of BufferedRWPair). It might be documented. Something like "Warning: don't use the same stream as reader and writer, or the BufferedRWPair bec

[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'

STINNER Victor added the comment: I'm working on a patch to remove the major version of sys.platform. The patch is much bigger than expected. You will see when it will be done :-) -- ___ Python tracker <http://bugs.python.org/is

[issue12794] platform: add a major function to get the system major version

New submission from STINNER Victor : #12326 proposes to remove the major version from sys.platform. If we remove it, we will need another easy way to get this information. I don't think that we need the version used to build Python, but the version at runtime. That's why the pla

[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'

STINNER Victor added the comment: > I'm working on a patch to remove the major version of sys.platform As expected by Marc-Andre: we need this information and so it has to be available somewhere else. I created #12794 to add platform.major(). I prefer to get the major version at runt

[issue12795] Remove the major version from sys.platform

New submission from STINNER Victor : sys.platform contains the major system version. If you test the sys.platform value (e.g. sys.platform == 'linux2'), your program doesn't work anymore with the new system major version (e.g. Linux 3). This problem is common with NetBSD, Open

[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'

STINNER Victor added the comment: > I'm working on a patch to remove the major version of sys.platform Done. I created the issue #12795: "Remove the major version from sys.platform". -- ___ Python tracker <http://bugs.

[issue12795] Remove the major version from sys.platform

STINNER Victor added the comment: To have an idea of how much code has to be changed for the sys.platform change, there is the diffstat : $ diffstat sys_platform_without_major.patch Lib/ctypes/util.py |6 -- Lib/distutils/command/build_ext.py |3 - Lib

[issue12794] platform: add a major function to get the system major version

STINNER Victor added the comment: > Can you please elaborate why we need it? platform.major() will be needed if we remove the major version for all platforms from sys.platform (issue #12795). See sys_platform_without_major.patch attached to issue #12795 see how it is u

[issue12795] Remove the major version from sys.platform

STINNER Victor added the comment: At the beginning, I thaught that it would be better to remove the major version from sys.platform on all platforms. When I started to write the patch, I expected to change only 2 or 3 files. But the patch is now huge ("26 files changed, 105 inser

[issue12794] platform: add a major function to get the system major version

STINNER Victor added the comment: > I'm not sure I understand why platform.release() isn't sufficient > for this purpose. Note that some systems return alphanumeric > values for platform.release(), e.g. for Windows you get > 'NT' or 'XP'. It's

[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'

STINNER Victor added the comment: For the sys.build_info, I opened #12794 (platform.major()) but then quickly closed it because it was only useful if the issue #12795 (Remove the major version from sys.platform) was accepted, but I closed it. -- Update votes for "(2) Python 3.3: c

[issue9878] Avoid parsing pyconfig.h and Makefile by autogenerating extension module

STINNER Victor added the comment: "avoid parsing pyconfig.h and Makefile in the sysconfig module by autogenerating an extension module" This feature will be appreciated by small devices embeding Python: on such device, headers and Makefile are not copied to not waste disk space.

[issue12797] io.FileIO and io.open should support openat

STINNER Victor added the comment: > allow an optional dirfd argument at the end of the arglist I prefer this suggestion. I didn't know openat(). Antoine told me that it can be used, for example, to fix security vulnerabilities li

[issue12794] platform: add a major function to get the system major version

Changes by STINNER Victor : -- resolution: -> invalid status: open -> closed ___ Python tracker <http://bugs.python.org/issue12794> ___ ___ Python-bugs-

[issue12799] realpath not resolving symbolic links under Windows

STINNER Victor added the comment: You are right, but this issue is a duplicate of #9949. -- nosy: +haypo resolution: -> duplicate status: open -> closed ___ Python tracker <http://bugs.python.org/i

[issue9949] os.path.realpath on Windows does not follow symbolic links

STINNER Victor added the comment: The issue #12799 has been marked as a duplicate of this issue: "From a look at the code, realpath() does not seem to resolve symlinks under Windows, even though we have the _getfinalpathname function to do that. Please indulge with me if I&#x

[issue12801] C realpath not used by os.path.realpath

STINNER Victor added the comment: The Python implementation (os.path.realpath) was introduced 10 years ago by the issue #461781. The Python implemtation has known bugs: - #9949: os.path.realpath on Windows does not follow symbolic links - #11397: os.path.realpath() may produce incorrect

[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'

STINNER Victor added the comment: > Where's the doc updates for the stable branches? I don't know how to update this documentation. Can someone update the doc, or suggest a patch? > Also, we might think about removing this version number everywhere. Please, s

[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'

STINNER Victor added the comment: > We could change the title of the ticket :-) No please, move the discussion to #12795 which has a well defined title. This issue is closed. (#12795 has also a patch) Well, #12795 is also close but you can reopen it if you explain

[issue12794] platform: add a major function to get the system major version

STINNER Victor added the comment: Le 20/08/2011 21:25, Marc-Andre Lemburg a écrit : > I'm not sure I understand why platform.release() isn't sufficient > for this purpose. You cannot write platform.release() >= (2, 28) (Linux >= 2.28) or platform.release() >= 7 (

[issue12795] Remove the major version from sys.platform

STINNER Victor added the comment: FreeBSD or OpenBSD release major version frequently, something like one per year, or one per two years. FreeBSD and OpenBSD developers knows that for years, and Python programs use sys.platform.startswith() for these OSes. For Linux, it's different.

[issue12795] Remove the major version from sys.platform

STINNER Victor added the comment: > sys.platform refers to build time information, > so the platform module won't help. When I wrote my patch, I realized that sys.platform is used to get the runtime information, which is wrong. See the tests in Lib/test/test_*.py: they use sys.

[issue12794] platform: add a function to get the system version as tuple

STINNER Victor added the comment: > The whole purpose of autoconf/configure is > to try to figure out which features are available on a platform > and those features change with the OS version. Hum, not exactly. autoconf checks if a function exists or if a constant exists in the C he

[issue12795] Remove the major version from sys.platform

STINNER Victor added the comment: >> It is mostly to test FreeBSD major version, and it looks like Python is >> build on the same FreeBSD major version that it is running on. Maybe because >> on FreeBSD, most programs are compiled instead of using prebuild packages >

[issue12795] Remove the major version from sys.platform

STINNER Victor added the comment: > But in general you are right: if you use system provided Python > packages, chances are that your runtime OS version will be > identical or very close to the build time OS version. I asked on #freebsd-fr: even with pkg_add, the installed Python is

[issue12819] PEP 393 - Flexible Unicode String Representation

Changes by STINNER Victor : -- hgrepos: +62 ___ Python tracker <http://bugs.python.org/issue12819> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue9200] Make the str.is* methods work with non-BMP chars on narrow builds

STINNER Victor added the comment: > This issue and #5127 should not be backported to 2.7: > narrow builds don't even accept unichar(0x1). I agee. -- ___ Python tracker <http://bugs.python

[issue12729] Python lib re cannot handle Unicode properly due to narrow/wide bug

Changes by STINNER Victor : -- nosy: +haypo ___ Python tracker <http://bugs.python.org/issue12729> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue12191] Add shutil.chown to allow to use user and group name (and not only uid/gid)

STINNER Victor added the comment: > New changeset d1fd0f0f8e68 by Sandro Tosi in branch 'default' You may add shutil.chmod to the "What's New in Python 3.3?" document. -- ___ Python tracker <ht

[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'

STINNER Victor added the comment: Something like: diff --git a/Doc/library/sys.rst b/Doc/library/sys.rst --- a/Doc/library/sys.rst +++ b/Doc/library/sys.rst @@ -699,20 +699,21 @@ always available. This string contains a platform identifier that can be used to append platform-specific

[issue12822] NewGIL should use CLOCK_MONOTONIC if possible.

Changes by STINNER Victor : -- nosy: +haypo ___ Python tracker <http://bugs.python.org/issue12822> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue12822] NewGIL should use CLOCK_MONOTONIC if possible.

STINNER Victor added the comment: See also #10278. -- ___ Python tracker <http://bugs.python.org/issue12822> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue10278] add time.wallclock() method

STINNER Victor added the comment: See also #12822. -- ___ Python tracker <http://bugs.python.org/issue10278> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue12808] Coverage of codecs.py

Changes by STINNER Victor : -- nosy: +haypo ___ Python tracker <http://bugs.python.org/issue12808> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue12826] module _socket failed to build on OpenBSD

STINNER Victor added the comment: It's surprising that it works on FreeBSD but not on OpenBSD. Thanks for your patch. -- nosy: +haypo ___ Python tracker <http://bugs.python.org/is

[issue12827] OS-specific location in Lib/tempfile.py for OpenBSD

STINNER Victor added the comment: Because it's not exactly a bug, can you only apply the patch to Python 3.3? -- nosy: +haypo ___ Python tracker <http://bugs.python.org/is

[issue12827] OS-specific location in Lib/tempfile.py for OpenBSD

STINNER Victor added the comment: > can you only apply the patch ... Hum, I mean can *we* only apply ... -- ___ Python tracker <http://bugs.python.org/issu

[issue9993] shutil.move fails on symlink source

Changes by STINNER Victor : -- nosy: +haypo, pitrou ___ Python tracker <http://bugs.python.org/issue9993> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue11657] multiprocessing_{send,recv}fd fail with fds > 256

Changes by STINNER Victor : -- nosy: +haypo ___ Python tracker <http://bugs.python.org/issue11657> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue12821] test_fcntl failed on OpenBSD 5.x

Changes by STINNER Victor : -- nosy: +haypo ___ Python tracker <http://bugs.python.org/issue12821> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue12819] PEP 393 - Flexible Unicode String Representation

STINNER Victor added the comment: utf8_fast.patch: fast path for pure ASCII string in the UTF-8 decoder. -- Added file: http://bugs.python.org/file23022/utf8_fast.patch ___ Python tracker <http://bugs.python.org/issue12

[issue12834] memoryview.tobytes() incorrect for non-contiguous arrays

Changes by STINNER Victor : -- nosy: +haypo ___ Python tracker <http://bugs.python.org/issue12834> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue12801] C realpath not used by os.path.realpath

STINNER Victor added the comment: i12801.patch is not correct: on Windows, you should never encode a filename to bytes. Use PyUnicode_Decode() + _Py_wrealpath(), or a #ifdef (as many other posixmodule functions). I prefer to reuse _Py_wrealpath because we will have to add special cases

[issue12801] C realpath not used by os.path.realpath

STINNER Victor added the comment: Patch to get #ifdef REALPATH_SUPPORT_NULL: diff --git a/configure.in b/configure.in --- a/configure.in +++ b/configure.in @@ -1539,6 +1539,17 @@ if test "$have_pthread_t" = yes ; then #endif ]) fi + +AC_MSG_CHECKING(for realpath

[issue1298813] sysmodule.c: realpath() is unsafe

STINNER Victor added the comment: See issue #12801: it has a more recent patch. -- ___ Python tracker <http://bugs.python.org/issue1298813> ___ ___ Python-bug

[issue12801] C realpath not used by os.path.realpath

STINNER Victor added the comment: > I prefer to reuse _Py_wrealpath because we will have > to add special cases: realpath(NULL) and also maybe > canonicalize_file_name(). I read that canonicalize_file_name(name) just calls realpath(name, NULL), so we can maybe avoid this GNU exce

[issue12760] Add create mode to open()

STINNER Victor added the comment: >open(filename, 'w', > fd_opener=lambda path, mode: os.open(path, mode|os.O_CREAT) I prefer open(name, "c"). > it doesn't fill a use case: actually, avoiding race conditions > is an important use case, ... I

[issue12786] subprocess wait() hangs when stdin is closed

STINNER Victor added the comment: subprocess_cloexec-1.diff: I'm too tired too review the test. The subprocess.py part looks correct, except the pipe2 name. Python 3 uses "_create_pipe = _posixsubprocess.cloexec_pipe". Pi

[issue5113] 2.5.4.3 / test_posix failing on HPUX systems

STINNER Victor added the comment: It's surprising to raise a SkipTest *at the end* of the test. Here is another patch. -- Added file: http://bugs.python.org/file23037/chown_hpux-2.diff ___ Python tracker <http://bugs.python.org/i

<    15   16   17   18   19   20   21   22   23   24   >