Re: Issue sending data from C++ to Python

Pablo Martinez Ulloa wrote at 2022-5-18 15:08 +0100: >I have been using your C++ Python API, in order to establish a bridge from >C++ to Python. Do you know `cython`? It can help very much in the implementation of bridges between Python and C/C++. -- https://mail.python.org/mailman/li

Re: Issue sending data from C++ to Python

Am 18.05.22 um 16:08 schrieb Pablo Martinez Ulloa: I have been using your C++ Python API, in order to establish a bridge from C++ to Python. We want to do this, as we have a tactile sensor, which only has a library developed in C++, but we want to obtain the data in real time in Python

Re: Issue sending data from C++ to Python

On 2022-05-18 15:08, Pablo Martinez Ulloa wrote: Hello, I have been using your C++ Python API, in order to establish a bridge from C++ to Python. We want to do this, as we have a tactile sensor, which only has a library developed in C++, but we want to obtain the data in real time in Python

Issue sending data from C++ to Python

Hello, I have been using your C++ Python API, in order to establish a bridge from C++ to Python. We want to do this, as we have a tactile sensor, which only has a library developed in C++, but we want to obtain the data in real time in Python to perform tests with a robotic arm and gripper

[issue45814] datetime.time.strftime: use the same function signature for C and Python implementations

rent keyword argument: fmt (pure) or format (C) ___ Python tracker <https://bugs.python.org/issue45814> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.o

[issue45814] datetime.time.strftime: use the same function signature for C and Python implementations

Change by Alex Waygood : -- title: Use the same function signature for datetime.time.strftime -> datetime.time.strftime: use the same function signature for C and Python implementations ___ Python tracker <https://bugs.python.org/issu

[issue41031] Inconsistency in C and python traceback printers

Change by Irit Katriel : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___ ___

[issue41031] Inconsistency in C and python traceback printers

Serhiy Storchaka added the comment: New changeset 9e31b3952f6101ef71ec029481b972169ab0e0f1 by Irit Katriel in branch 'main': bpo-41031: Match C and Python code formatting of unprintable exceptions and exceptions in the __main__ module. (GH-28139) https://github.com/python/cpython/commit

[issue41031] Inconsistency in C and python traceback printers

Change by Irit Katriel : -- versions: +Python 3.11, Python 3.9 ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue41031] Inconsistency in C and python traceback printers

Change by Irit Katriel : -- keywords: +patch nosy: +iritkatriel nosy_count: 1.0 -> 2.0 pull_requests: +26578 stage: -> patch review pull_request: https://github.com/python/cpython/pull/28139 ___ Python tracker

[issue44267] Wrong PEP 515 parsing in decimal module (both C and Python versions)

Sergey B Kirpichev added the comment: On Sun, May 30, 2021 at 08:58:56AM +, Mark Dickinson wrote: > Yep, you're absolutely right. I should have said "after the PEP is final" Unfortunately, neither correction can fix that the PEP does not "accurately describes the state of the

[issue44267] Wrong PEP 515 parsing in decimal module (both C and Python versions)

Change by Mark Dickinson : -- resolution: -> wont fix stage: -> resolved status: open -> closed ___ Python tracker ___ ___

[issue44267] Wrong PEP 515 parsing in decimal module (both C and Python versions)

Mark Dickinson added the comment: > Regarding mail thread: I don't think that following the PEP will slow down string conversion. Sorry, I just don't think it's worth re-opening this discussion; Stefan Krah had good reasons (not just speed) to avoid implementing a precise interpretation of

[issue44267] Wrong PEP 515 parsing in decimal module (both C and Python versions)

Mark Dickinson added the comment: > Well, then I something misunderstood in PEP 0 Yep, you're absolutely right. I should have said "after the PEP is final", not "after the PEP is accepted". PEP 515 was marked final on April 28th, 2017. > The current behaviour is documented. Thanks; I

[issue44267] Wrong PEP 515 parsing in decimal module (both C and Python versions)

Sergey B Kirpichev added the comment: On Sun, May 30, 2021 at 08:32:40AM +, Mark Dickinson wrote: > Standards Track PEPs are historical documents; it's quite common that an > actual implementation ends up diverging from a PEP in small ways after > the PEP is accepted, and we don't usually

[issue44267] Wrong PEP 515 parsing in decimal module (both C and Python versions)

Mark Dickinson added the comment: > If this is not a bug - it should be adjusted Standards Track PEPs are historical documents; it's quite common that an actual implementation ends up diverging from a PEP in small ways after the PEP is accepted, and we don't usually do post-hoc updates in

[issue44267] Wrong PEP 515 parsing in decimal module (both C and Python versions)

Sergey B Kirpichev added the comment: On Sun, May 30, 2021 at 08:20:14AM +, Mark Dickinson wrote: > There was some discussion of this on the python-dev mailing list at the time I see. > It's probably best left alone. PEP 515 is clear. If this is not a bug - it should be adjusted (as it

[issue44267] Wrong PEP 515 parsing in decimal module (both C and Python versions)

Mark Dickinson added the comment: There was some discussion of this on the python-dev mailing list at the time - see https://mail.python.org/pipermail/python-dev/2016-March/143556.html and the surrounding thread. It's probably best left alone. --

[issue44267] Wrong PEP 515 parsing in decimal module (both C and Python versions)

Change by Sergey B Kirpichev : Added file: https://bugs.python.org/file50072/0001-bpo-44267-fix-parsing-Decimal-s-with-underscores.patch ___ Python tracker ___

[issue44267] Wrong PEP 515 parsing in decimal module (both C and Python versions)

Change by Karthikeyan Singaravelan : -- nosy: +facundobatista, mark.dickinson, rhettinger ___ Python tracker ___ ___

[issue44267] Wrong PEP 515 parsing in decimal module (both C and Python versions)

ary (Lib) files: _pydecimal-pep515.diff keywords: patch messages: 394750 nosy: Sergey.Kirpichev priority: normal severity: normal status: open title: Wrong PEP 515 parsing in decimal module (both C and Python versions) versions: Python 3.11 Added file: https://bugs.python.org/file50071/_pydecima

[issue43559] ctypes: Heap Pointer is damaged between C and Python

Canberk Sönmez added the comment: Alright, I solved the problem. It was simply a typo: "restypes" instead of "res_types". It didn't cause a problem in Python 3.6 but obviously, something was changed. A nice error message might be nice when setting these attributes. -- resolution: ->

[issue43559] ctypes: Heap Pointer is damaged between C and Python

Eric V. Smith added the comment: Are you using a 64-bit version of python? What is sys.maxsize? -- nosy: +eric.smith ___ Python tracker ___

[issue43559] ctypes: Heap Pointer is damaged between C and Python

New submission from Canberk Sönmez : Please see the SO post: https://stackoverflow.com/questions/66713071/ctypes-heap-pointer-is-damaged-between-c-and-python-linux-x86-64 In summary, when I return a pointer to a heap-allocated memory location from a C function, its most significant 32 bits

Universal compiler that runs Java, Ruby, C++, and Python in a single VM

It's called Oracle's Truffle. Truffle runs all those languages with an autogenerated JIT. This is my response to the neos drama. -- https://mail.python.org/mailman/listinfo/python-list

[issue41031] Inconsistency in C and python traceback printers

ent.py", line 6, in raise E() E: -- components: Library (Lib) messages: 371855 nosy: msimacek priority: normal severity: normal status: open title: Inconsistency in C and python traceback printers type: behavior versions: Python 3.10 ___ Py

[issue38500] PEP 523: Add private _PyInterpreterState_SetEvalFrameFunc() function to the C API (Python 3.8 regression)

Change by STINNER Victor : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue38500] PEP 523: Add private _PyInterpreterState_SetEvalFrameFunc() function to the C API (Python 3.8 regression)

STINNER Victor added the comment: New changeset 0b72b23fb0c130279f65f3bcd23521acf4a98c88 by Victor Stinner in branch 'master': bpo-38500: Add _PyInterpreterState_SetEvalFrameFunc() (GH-17340) https://github.com/python/cpython/commit/0b72b23fb0c130279f65f3bcd23521acf4a98c88 --

[issue38500] PEP 523: Add private _PyInterpreterState_SetEvalFrameFunc() function to the C API (Python 3.8 regression)

STINNER Victor added the comment: Mark: Would you mind to open a separated issue for your following idea? > I propose a new method on code objects `withCallAtLine(callable: Callable[], > line:int)` which returns a new code object with calls to the given callable > at the given line. > A

[issue38500] PEP 523: Add private _PyInterpreterState_SetEvalFrameFunc() function to the C API (Python 3.8 regression)

STINNER Victor added the comment: I took Mark's concerns in account and I updated my PR to only add *private* functions to the C API, not *public* functions. -- ___ Python tracker

[issue38500] PEP 523: Add private _PyInterpreterState_SetEvalFrameFunc() function to the C API (Python 3.8 regression)

Change by STINNER Victor : -- title: PEP 523: Add PyInterpreterState_SetEvalFrameFunc() to the public C API (Python 3.8 regression) -> PEP 523: Add private _PyInterpreterState_SetEvalFrameFunc() function to the C API (Python 3.8 regress

[issue38500] PEP 523: Add PyInterpreterState_SetEvalFrameFunc() to the public C API (Python 3.8 regression)

STINNER Victor added the comment: Mark: > PEP 523 is quite vague, but the rationale indicates that exposing > `eval_frame` is for "a method-level JIT". PEP 523 did not suggest adding an > API. I disagree, the PEP is quite explicit: "Third-party code may then set their own frame evaluation

[issue38500] PEP 523: Add PyInterpreterState_SetEvalFrameFunc() to the public C API (Python 3.8 regression)

STINNER Victor added the comment: Mark Shannon: `PyThreadState` is an internal opaque data structure, which means we are free to change it. I guess that you mean PyInterpreterState which was moved to the internal C API in Python 3.8. It was part of public C API in Python 3.7. See commit

[issue38500] PEP 523: Add PyInterpreterState_SetEvalFrameFunc() to the public C API (Python 3.8 regression)

STINNER Victor added the comment: Somehow related, I just created bpo-39946: "Is it time to remove _PyThreadState_GetFrame() hook?". -- ___ Python tracker ___

[issue38500] PEP 523: Add PyInterpreterState_SetEvalFrameFunc() to the public C API (Python 3.8 regression)

STINNER Victor added the comment: For me, the *short term* goal is to find a way to limit the number of broken C extension module while we modify the C API to make it more opaque. We cannot reach all goals at once (opaque C API, subinterpreter, more optimizations, etc). We have to move step

[issue38500] PEP 523: Add PyInterpreterState_SetEvalFrameFunc() to the public C API (Python 3.8 regression)

STINNER Victor added the comment: > Why not do so by reverting the change that caused it? Making PyInterpreterState structure private was motivated by the subinterpreters work but also by the work on cleaning the C API. Over time, PyInterpreterState became more and more complex because many

[issue38500] PEP 523: Add PyInterpreterState_SetEvalFrameFunc() to the public C API (Python 3.8 regression)

Mark Shannon added the comment: I'm not suggesting immediate removal of PEP 532. I am requesting that you don't add a new function to the C API that will prevent implementation of many meaningful optimizations to CPython. PEP 532 does not add any API functions. I understand that you want to

[issue38500] PEP 523: Add PyInterpreterState_SetEvalFrameFunc() to the public C API (Python 3.8 regression)

STINNER Victor added the comment: > I think you mean PEP 352? And a more formal proposal to withdraw would need > to be made and that has not happened, so assume the PEP is still accepted and > final. I mean PEP 523 "Adding a frame evaluation API to CPython" as I wrote in the title, sorry

[issue38500] PEP 523: Add PyInterpreterState_SetEvalFrameFunc() to the public C API (Python 3.8 regression)

Brett Cannon added the comment: > Mark Shannon listed flaws in the PEP 532 and suggest to withdraw this PEP. I think you mean PEP 352? And a more formal proposal to withdraw would need to be made and that has not happened, so assume the PEP is still accepted and final. --

[issue38500] PEP 523: Add PyInterpreterState_SetEvalFrameFunc() to the public C API (Python 3.8 regression)

Change by STINNER Victor : -- title: Provide a way to get/set PyInterpreterState.frame_eval without needing to access interpreter internals -> PEP 523: Add PyInterpreterState_SetEvalFrameFunc() to the public C API (Python 3.8 regression) versions: -Python

[issue37579] Difference in equality check between C and Python implementation for datetime module's timedelta and time

Serhiy Storchaka added the comment: See issue37685. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue37579] Difference in equality check between C and Python implementation for datetime module's timedelta and time

miss-islington added the comment: New changeset c6b31061997526b31961ec34328408ca421f51fc by Miss Islington (bot) (Xtreak) in branch '3.7': [3.7] bpo-37579: Improve equality behavior for pure Python datetime and time (GH-14726) (GH-14745)

[issue37579] Difference in equality check between C and Python implementation for datetime module's timedelta and time

Change by Paul Ganssle : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___ ___

[issue37579] Difference in equality check between C and Python implementation for datetime module's timedelta and time

miss-islington added the comment: New changeset 143672cf028740fc549e532c049559c522930c95 by Miss Islington (bot) in branch '3.8': bpo-37579: Improve equality behavior for pure Python datetime and time (GH-14726)

[issue37579] Difference in equality check between C and Python implementation for datetime module's timedelta and time

Change by Karthikeyan Singaravelan : -- pull_requests: +14541 pull_request: https://github.com/python/cpython/pull/14745 ___ Python tracker ___

[issue37579] Difference in equality check between C and Python implementation for datetime module's timedelta and time

Change by miss-islington : -- pull_requests: +14539 pull_request: https://github.com/python/cpython/pull/14743 ___ Python tracker ___

[issue37579] Difference in equality check between C and Python implementation for datetime module's timedelta and time

Paul Ganssle added the comment: New changeset e6b46aafad3427463d6264a68824df4797e682f1 by Paul Ganssle (Xtreak) in branch 'master': bpo-37579: Improve equality behavior for pure Python datetime and time (GH-14726)

[issue37579] Difference in equality check between C and Python implementation for datetime module's timedelta and time

Serhiy Storchaka added the comment: Do you mind to fix also other similar cases if they are? __lt__ and others should have the same property. -- ___ Python tracker ___

[issue37579] Difference in equality check between C and Python implementation for datetime module's timedelta and time

Change by Karthikeyan Singaravelan : -- keywords: +patch pull_requests: +14522 stage: -> patch review pull_request: https://github.com/python/cpython/pull/14726 ___ Python tracker

[issue37579] Difference in equality check between C and Python implementation for datetime module's timedelta and time

New submission from Karthikeyan Singaravelan : As reported by Serhiy on https://bugs.python.org/issue37555#msg347733 there is a difference in __eq__ definition in datetime module's C and Python implementation for timedelta and time. When the other in __eq__ is not of the same type

[issue34481] Different behavior of C and Python impls of datetime.strftime with non-UTF-8-encodable strings

Change by Raymond Hettinger : -- nosy: +brett.cannon ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34481] Different behavior of C and Python impls of datetime.strftime with non-UTF-8-encodable strings

Paul Ganssle added the comment: I've left a mostly finished PR on #8983, but I've decided it's not really worth continuing to work on. Anyone can feel free to take it and run with it if they want to implement the fix for this. As Alexey mentions, that PR indeed already fixes this bug, I

[issue34481] Different behavior of C and Python impls of datetime.strftime with non-UTF-8-encodable strings

" means here). That's not to discourage you, just to point out that we should be extra careful at this point when there might be users relying on every variety of the current behavior. And that's also why I don't want to mix the fix for C vs. Python issue (low risk) with changes in time.strftime()

[issue34481] Different behavior of C and Python impls of datetime.strftime with non-UTF-8-encodable strings

Paul Ganssle added the comment: @izbyshev That's totally fair and I wouldn't want to make it a condition of merging the existing fixes - I've already made great progress in fixing the time.strftime part as well. The main reason it relates here is that I generally find the tests to be among

[issue34481] Different behavior of C and Python impls of datetime.strftime with non-UTF-8-encodable strings

Alexey Izbyshev added the comment: @p-ganssle > I'm finding it very difficult to reconcile these things. Paul, this issue was only about reconciling C and Python implementations of datetime module -- not fixing time.strftime(), which both of them delegate to. While the latter is certai

[issue34481] Different behavior of C and Python impls of datetime.strftime with non-UTF-8-encodable strings

STINNER Victor added the comment: > Because caring of surrogates, Before* -- ___ Python tracker ___ ___ Python-bugs-list mailing

[issue34481] Different behavior of C and Python impls of datetime.strftime with non-UTF-8-encodable strings

STINNER Victor added the comment: Because caring of surrogates, I would prefer to first fix time.strftime() and time.strptime() for legit time zone names. Currently, Python uses the C function strfime() because the string produced by wcsftime() cannot be parsed later. We should use

[issue34481] Different behavior of C and Python impls of datetime.strftime with non-UTF-8-encodable strings

Paul Ganssle added the comment: I'm finding it very difficult to reconcile these things. I'm not entirely sure, but we may need to take a performance hit in normal strftime if we want to make this work with surrogate characters, which really does not appeal to me (though we can certainly

[issue34481] Different behavior of C and Python impls of datetime.strftime with non-UTF-8-encodable strings

Change by STINNER Victor : -- nosy: +vstinner ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34481] Different behavior of C and Python impls of datetime.strftime with non-UTF-8-encodable strings

Change by Paul Ganssle : -- keywords: +patch pull_requests: +8457 stage: -> patch review ___ Python tracker ___ ___

[issue34481] Different behavior of C and Python impls of datetime.strftime with non-UTF-8-encodable strings

Change by Paul Ganssle : -- nosy: +p-ganssle ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34481] Different behavior of C and Python impls of datetime.strftime with non-UTF-8-encodable strings

63 nosy: belopolsky, izbyshev, pitrou, serhiy.storchaka, taleinat priority: normal severity: normal status: open title: Different behavior of C and Python impls of datetime.strftime with non-UTF-8-encodable strings type: behavior versions: Python 3.6, Python 3.7, Python 3.8 _

Re: Handle SIGINT in C and Python (Posting On Python-List Prohibited)

ll() >> * poll() aborted with EINTR >> * Python runs your signal handler >> >> Versus native C code: >> >> * your code calls poll() >> * poll() aborted with EINTR >> * your signal handler is run >> >> Where is there a fundamental difference? >

Re: Handle SIGINT in C and Python (Posting On Python-List Prohibited)

Lawrence D’Oliveiro wrote: > On Thursday, February 1, 2018 at 5:57:58 PM UTC+13, Victor Porton wrote: >> I meant to call poll() from C code, not Python code. > > Do you need to use C code at all? Python is quite capable of handling this > <https://docs.python.org/3/lib

Re: Handle SIGINT in C and Python (Posting On Python-List Prohibited)

our code calls poll() > * poll() aborted with EINTR > * your signal handler is run > > Where is there a fundamental difference? I meant to call poll() from C code, not Python code. In this case when poll() is aborted with EINTR, the pythonic signal handler does not run. -- Victor Porton - http://portonvictor.org -- https://mail.python.org/mailman/listinfo/python-list

Re: Handle SIGINT in C and Python (Posting On Python-List Prohibited)

Lawrence D’Oliveiro wrote: > On Wednesday, January 31, 2018 at 9:55:45 PM UTC+13, Victor Porton wrote: >> Lawrence D’Oliveiro wrote: >> >>> On Wednesday, January 31, 2018 at 8:58:18 PM UTC+13, Victor Porton >>> wrote: For this reason I cannot use Python signals because "A Python signal

Re: Handle SIGINT in C and Python (Posting On Python-List Prohibited)

Lawrence D’Oliveiro wrote: > On Wednesday, January 31, 2018 at 8:58:18 PM UTC+13, Victor Porton wrote: >> For this reason I >> cannot use Python signals because "A Python signal handler does not get >> executed inside the low-level (C) signal handler. Instead, the low-level >> signal handler sets

Re: Handle SIGINT in C and Python

Victor Porton wrote: > I need to assign a real C signal handler to SIGINT. > > This handler may be called during poll() waiting for data. For this reason > I cannot use Python signals because "A Python signal handler does not get > executed inside the low-level (C) signal handler. Instead, the

Handle SIGINT in C and Python

I need to assign a real C signal handler to SIGINT. This handler may be called during poll() waiting for data. For this reason I cannot use Python signals because "A Python signal handler does not get executed inside the low-level (C) signal handler. Instead, the low-level signal handler sets

[issue28706] msvc9compiler does not find a vcvarsall.bat of Visual C++ for Python 9.0

Change by Stefan Krah : -- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> setup.py cannot find vcversall.bat on MSWin 8.1 if installed in user AppData ___ Python tracker

[issue28706] msvc9compiler does not find a vcvarsall.bat of Visual C++ for Python 9.0

8s) Finished command: build (0.139s) Command '"c:\program files\python27\python.exe" -u build.py build' failed with exit code 1. I found out that the problem is in msvc9compiler. The dir where vcvarsall.bat is installed is not found. It is installed (by default) in C:\Users\Jir

PyEmbedC 1.0 - Embed C in Python code

Python module for embedding C/C++ code within Python code. It is designed to allow coders to easily speed up slow code by replacing small portions of Python with compiled C/C++ that can transparently read and modify Python variables. Keeping all the code in the same source file simplifies

[issue16050] ctypes: callback from C++ to Python fails with Illegal Instruction call

R. David Murray added the comment: Arnon also checked that our local copy of libffi contains the upstream fix. In the absence of a way to test this, we'll just have to assume it is fixed. -- nosy: +r.david.murray resolution: - out of date stage: - resolved status: open - closed

[issue16050] ctypes: callback from C++ to Python fails with Illegal Instruction call

Arnon Yaari added the comment: libffi seem to have fixed this issue in their commit 4acf005 - Build fix for soft-float power targets. The fix is different than what Pavel suggested, but sounds like it should do the same. -- nosy: +wiggin15 ___

how to create an external string when binding C to Python?

I'd like to make a C memory buffer available inside Python via the Python C/API without copying that memory into Python. How to do this? I've read [1] but it's not clear that this functionality exists. In javascript it's possible using String::NewExternal() [2]. Creates a new external string

how to create a zero copy external string when binding C to Python?

I'd like to make a C memory buffer available inside Python via the Python C/API without copying that memory into Python. How to do this? I've read [1] but it's not clear that this functionality exists. In javascript it's possible using String::NewExternal() [2]. Creates a new external string

Re: how to create an external string when binding C to Python?

On 09/05/2014 00:10, Simon wrote: I'd like to make a C memory buffer available inside Python via the Python C/API without copying that memory into Python. How to do this? I've read [1] but it's not clear that this functionality exists. In javascript it's possible using String::NewExternal

Re: how to create an external string when binding C to Python?

On Thu, May 8, 2014 at 5:10 PM, Simon simo...@gmail.com wrote: I'd like to make a C memory buffer available inside Python via the Python C/API without copying that memory into Python. How to do this? I've read [1] but it's not clear that this functionality exists. In javascript it's

C++ to python for LED Matrix

Hey folks, So the last week or so I've been searching this site for information on how to control and program a LED Matrix (or a number of them) for a project. A few Topics have caught my eye, with me originally having in mind using a Maxim MAX7221 to control the matrix, but none more than

Re: C++ to python for LED Matrix

Yes you could use Python for this sort of thing. The link you posted is just using a kernel spi driver that Python can write to just as well as C++ can (via it's /dev/spidev0.0 file). There is a python library that can talk to SPI in Python on the pi:

[issue19846] Setting LANG=C breaks Python 3 on Linux

Serhiy Storchaka added the comment: And yet, in Python 2, people could do that, and Python didn't care. *That's* the regression I'm worried about. If it hadn't round-tripped cleanly in Python 2, I wouldn't care here either. $ python2.7 -c print u'\u20ac' € $ LANG=C python2.7 -c print

[issue19846] Setting LANG=C breaks Python 3 on Linux

. This is not a locale of your terminal. Try `LANG=C xterm`. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19846 ___ ___ Python-bugs-list mailing list Unsubscribe

[issue19846] Setting LANG=C breaks Python 3 on Linux

/onlinepubs/009695399/basedefs/xbd_chap07.html The C and POSIX locale settings are the only locale settings that are guaranteed to always exist in C libraries. Python 3 should work with such locale settings. It doesn't have to be able to output non-ASCII code points, but it should run with ASCII data

[issue19846] Setting LANG=C breaks Python 3 on Linux

STINNER Victor added the comment: I didn't understand Serhiy's ls example. I tried: $ mkdir unicode $ cd unicode $ python3 -c 'open(ab\xe9.txt, w).close()' $ python3 -c 'open(euro\u20ac.txt, w).close()' $ ls abé.txt euro€.txt $ LANG=C ls ab??.txt euro???.txt Ah yes, I didn't remember that

[issue19846] Setting LANG=C breaks Python 3 on Linux

STINNER Victor added the comment: Nick testing applications for POSIX compliance Sorry but what do you mean by POSIX compliance? The POSIX standard only specify the ASCII encoding. http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap07.html The tables in Locale Definition describe

[issue19846] Setting LANG=C breaks Python 3 on Linux

STINNER Victor added the comment: Marc-Andre AFAIK, Python 3 does work with ASCII data in the C locale, so I'm not sure whether this is a bug at all. What do you mean? Python uses the surrogateescape encoding since Python 3.1, undecodable bytes are stored as surrogate characters. Many bugs

[issue19846] Setting LANG=C breaks Python 3 on Linux

exceptions if you use a C locale and write non-ASCII data to stdout. I also don't think that the new ticket title is correct - or at least, I fail to see which aspect of Python breaks with LANG=C :-) -- ___ Python tracker rep...@bugs.python.org http

[issue19846] Setting LANG=C breaks Python 3

Changes by Nick Coghlan ncogh...@gmail.com: -- title: print() and write() are relying on sys.getfilesystemencoding() instead of sys.getdefaultencoding() - Setting LANG=C breaks Python 3 ___ Python tracker rep...@bugs.python.org http

[issue19846] Setting LANG=C breaks Python 3

Changes by STINNER Victor victor.stin...@gmail.com: -- title: print() and write() are relying on sys.getfilesystemencoding() instead of sys.getdefaultencoding() - Setting LANG=C breaks Python 3 ___ Python tracker rep...@bugs.python.org http

[issue19846] Setting LANG=C breaks Python 3

should be used when the C locale is used: the encoding announced by the OS using nl_langinfo(CODESET) (current choice) or use an arbitrary optimistic utf-8 encoding? (b) for technical reasons, Python reuses the C codec during Python initialization to decode and encode OS data, and so currently

[issue19846] Setting LANG=C breaks Python 3

Antoine Pitrou added the comment: On dim., 2013-12-08 at 22:22 +, STINNER Victor wrote: (b) for technical reasons, Python reuses the C codec during Python initialization to decode and encode OS data, and so currently Python *must* use the locale encoding for its filesystem encoding Ahhh

[issue19846] Setting LANG=C breaks Python 3

STINNER Victor added the comment: It seems there is more work to do to get this right, but I'm not terribly interested either. Feel free to take over. If you are talking to me: I'm currently opposed to change anything, so I'm not interested to work on a patch. IMO Python works fine and you

[issue19846] Setting LANG=C breaks Python 3 on Linux

filesystem, and is used for almost all bytes-based OS APIs, not just filesystem metadata) -- nosy: +a.badger, bkabrda title: Setting LANG=C breaks Python 3 - Setting LANG=C breaks Python 3 on Linux ___ Python tracker rep...@bugs.python.org http

[issue19846] Setting LANG=C breaks Python 3 on Linux

STINNER Victor added the comment: End users tripping over this by setting LANG=C is one of the pain points of Python 3 relative to Python 2 for Fedora, so I've added a couple of Fedora folks to the nosy list. Sorry, I'm not aware of such issue. Do you have examples? - the main problem is

[issue19846] Setting LANG=C breaks Python 3 on Linux

Nick Coghlan added the comment: On 9 December 2013 12:08, STINNER Victor rep...@bugs.python.org wrote: STINNER Victor added the comment: End users tripping over this by setting LANG=C is one of the pain points of Python 3 relative to Python 2 for Fedora, so I've added a couple of Fedora

[issue19846] Setting LANG=C breaks Python 3 on Linux

Sworddragon added the comment: You should keep things more simple: - Python and the operation system/filesystem are in a client-server relationship and Python should validate all. - It doesn't matter what you will finally decide to be the default encoding on various places - all will provide

Re: Implementing #define macros similar to C on python

15.11.13 06:57, Chris Angelico написав(ла): On Fri, Nov 15, 2013 at 3:10 PM, Roy Smith r...@panix.com wrote: Why would you want to? One of the most horrible things about C/C++ is the preprocessor. Hey, that's not fair! Without the preprocessor, how would you be able to do this: //Hide this

Re: Implementing #define macros similar to C on python

On 16/11/2013 05:38, JL wrote: On Saturday, November 16, 2013 8:22:25 AM UTC+8, Mark Lawrence wrote: Yes but please don't top post. Actually print is a statement in Python 2 so your code should work if you use from __future__ import print_function at the top of your code. Would you also be

Re: Implementing #define macros similar to C on python

On 15-11-2013 3:29, JL wrote: One of my favorite tools in C/C++ language is the preprocessor macros. One example is switching certain print messages for debugging use only #ifdef DEBUG_ENABLE DEBUG_PRINT print #else DEBUG_PRINT Is it possible to implement something similar in

Re: Implementing #define macros similar to C on python

Thanks! This is the answer which I am seeking. However, I am not able to get the following line to work. I am using python 2.7.5 debug_print = print Can we assign a function into a variable in this manner? On Friday, November 15, 2013 11:49:52 AM UTC+8, Chris Angelico wrote: On Fri, Nov 15,

  1   2   3   4   5   >