[issue12589] test_long.test_nan_inf() failed on OpenBSD (powerpc)

STINNER Victor added the comment: I'm not sure that your version of gdb understands macros. You may have to set a breakpoint on __isinf. Compile Python with "-g -ggdb" helps gdb. Py_IS_INFINITY is may not defined as "# define Py_IS_INFINITY(X) isinf(X)". To check

[issue12612] Valgrind suppressions

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

[issue12613] itertools fixer fails

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

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

STINNER Victor added the comment: It's too late to "fix" sys.platform. -- ___ Python tracker <http://bugs.python.org/issue12326> ___ ___ Python-b

[issue12607] subprocess(stdout=..., stderr=sys.stdout) breaks stderr for child

STINNER Victor added the comment: save_fds should be moved outside the try block: +try: +# save a copy of the standard file descriptors +saved_fds = [os.dup(fd) for fd in range(3)] +... +finally: +for std

[issue12632] Windows GPF with Code Page 65001

STINNER Victor added the comment: You can use PYTHONIOENCODING="utf-8". Code page 65001 is not exactly like Python UTF-8 codec: see issue #6058. Using issue #12281, it may be possible to implement a cp65001 codec. See also issue #1602 for the Windows console. Why do you u

[issue12625] sporadic test_unittest failure

STINNER Victor added the comment: > getpid() is called after each kill(getpid(), ), > to "force" the signal delivery Please write a function (in test.support?) with a comment explaining why you are doing that. You may also only do this workaround on specific platforms. For e

[issue10883] urllib: socket is not closed explicitly

STINNER Victor added the comment: Thanks for your patch. ResourceWarning are really useful! -- ___ Python tracker <http://bugs.python.org/issue10883> ___ ___

[issue12632] Windows GPF with Code Page 65001

STINNER Victor added the comment: > Python shouldn't GPF for ANY reason if it can be easily fixed "Code page 65001" issue cannot be "easily" fixed. Did you read the history of the issue #6058? It took one year and a half to decide that cp65001 cannot be set as an

[issue12632] Windows GPF with Code Page 65001

STINNER Victor added the comment: > Finally, the "fix" you suggest would be applicable if python > used WriteConsole or WriteFile... but it does not! It uses > the write() function, which probably calls WriteConsole > or WriteFile at some point, but does not take unic

[issue12632] Windows GPF with Code Page 65001

STINNER Victor added the comment: > All I'm trying to do is run different versions of Python on the same machine > from the command line. > Some code inside Python now "break" if Python 3.1 is started with Code Page > 65001. Yes, this issue can be seen as a regres

[issue12607] subprocess(stdout=..., stderr=sys.stdout) breaks stderr for child

STINNER Victor added the comment: i12607_v2.patch: the test fails if Python is compiled with pydebug. Add "err = support.strip_python_stderr(err)" before self.assertEqual(err, b"err") in test_subprocess.py to fix the failure. -- versions: -Python 2.6, Py

[issue12181] SIGBUS error on OpenBSD (sparc64)

STINNER Victor added the comment: select.kevent(bignum, 1, 2, 3, sys.maxsize, bignum) raises a OverflowError('signed integer is greater than maximum') on a 64 bits system. select.kevent() constructor parses the 4th argument using "i" (an int): sys.maxsize doesn't fi

[issue12181] SIGBUS error on OpenBSD (sparc64)

STINNER Victor added the comment: OpenBSD has a patch for this issue: http://www.openbsd.org/cgi-bin/cvsweb/ports/lang/python/2.7/patches/patch-Modules_selectmodule_c -- ___ Python tracker <http://bugs.python.org/issue12

[issue12181] SIGBUS error on OpenBSD (sparc64)

STINNER Victor added the comment: patch-Modules_selectmodule_c is not enough to fix kqueue_event_init(): it doesn't catch overflow error on the ident attribute. -- ___ Python tracker <http://bugs.python.org/is

[issue12643] code.InteractiveConsole ignores sys.excepthook

STINNER Victor added the comment: What do you suggest? -- nosy: +haypo ___ Python tracker <http://bugs.python.org/issue12643> ___ ___ Python-bugs-list mailin

[issue12643] code.InteractiveConsole ignores sys.excepthook

STINNER Victor added the comment: > If it's not possible for InteractiveConsole to allow exceptions > to propagate through sys.excepthook. Ok, I was not sure that I understood correctly. This change should be an option to not break ex

[issue11871] test_default_timeout() of test_threading.BarrierTests failure: BrokenBarrierError

STINNER Victor added the comment: YES YOU CAN -- ___ Python tracker <http://bugs.python.org/issue11871> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue12170] index() and count() methods of bytes and bytearray should accept byte ints

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

[issue12636] IDLE ignores -*- coding -*- with -r option

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

[issue12647] Add __bool__ to None

STINNER Victor added the comment: > I'm not sure why the special case shouldn't be retained. We can keep the fast path in PyObject_IsTrue but add a __bool__ method to NoneType. -- nosy: +haypo ___ Python tracker <http://bugs.pytho

[issue12636] IDLE ignores -*- coding -*- with -r option

STINNER Victor added the comment: Yes, tokenize.open() should fix this issue, but you should close the file after using it. Use for example "with tokenize.open(): ...". Can you write a patch? You can download the source code using Mercurial or download it manually from http://hg.

[issue12650] Subprocess leaks fd upon kill()

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

[issue12540] "Restart Shell" command leaves pythonw.exe processes running

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

[issue12700] test_faulthandler fails on Mac OS X Lion

STINNER Victor added the comment: test_enable_file, test_enable_single_thread, test_gil_released and test_read_null read an int (4 bytes) from the address 0 (NULL). test_sigsegv pass: this test raises explicitly a SIGSEGV and the signal handler writes the right message ("Segmentation

[issue10087] HTML calendar is broken

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

[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

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