[issue38882] IDLE should not make the about dialog be a transient of the withdrawn root window
Marc Culler added the comment: One thing to keep in mind is that Apple's release of OSX 10.14.6 caused Tk 8.6.8 to stop working on many systems in an extremely obnoxious way. Starting a Tk Application would trigger a segfault in Apple's WindowServer which would then cause the user to be immediately logged out. That does not happen with 8.6.10. (Other types of applications were also affected.) Here is one of many bug reports: https://github.com/matplotlib/matplotlib/issues/14999 Whether the crash would occur depended on which Apple hardware was used. -- ___ Python tracker <https://bugs.python.org/issue38882> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38882] IDLE should not make the about dialog be a transient of the withdrawn root window
Change by Marc Culler : -- versions: +Python 2.7 -Python 3.7 ___ Python tracker <https://bugs.python.org/issue38882> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38882] IDLE should not make the about dialog be a transient of the withdrawn root window
Marc Culler added the comment: I should have mentioned that I did not see the IDLE hang with Python 3, only with Python 2.7. So I changed the Version in the ticket. -- versions: +Python 3.7 -Python 3.8 ___ Python tracker <https://bugs.python.org/issue38882> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38882] IDLE should not make the about dialog be a transient of the withdrawn root window
Marc Culler added the comment: It definitely makes sense for an on-screen window to have a transient dialog. With a little care (see "messages boxes" in the widget demo) on the mac the transient can be a "sheet" that opens from the top of the master window. It even makes sense for an iconified window to have a transient since the window manager still controls iconified windows. But a withdrawn window, with no icon (and no listing in the mac Window menu) is beyond the user's control. The really deadly combination is when a transient of a withdrawn window (so the transient is withdrawn) also has a grab on mouse and keyboard events. That one should be avoided. It is not clear to me why Tk allows it. I believe it should be avoided on all platforms, since withdrawn windows are supposed to be completely removed from the window manager and only known to Tk. But testing is needed, of course. I don't know the full history. I know there were changes between 8.6.9 and 8.6.10 needed to bring the mac port to its current state where it passes all of the Tk regression tests. (That is not the case with unix at the moment and I know there are many issues with iconified and withdrawn windows in Gnome 3 due to changes in window manager behavior which have not been fully incorporated into Tk.) I suspect there were many prior releases with no changes to this behavior on the mac. PS The formerly soon-to-be-released 8.6.10 has now been released. -- ___ Python tracker <https://bugs.python.org/issue38882> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38882] IDLE should not make the about dialog be a transient of the withdrawn root window
New submission from Marc Culler : The soon-to-be-released Tcl/Tk 8.6.10 includes some changes to the macOS port which cause the wm transient command to behave in the way that the Tk manual says it should: "A transient window will mirror state changes in the master and inherit the state of the master when initially mapped." This means that a transient of a withdrawn window will be withdrawn. In the macOS version of IDLE the about dialog is assigned as a transient of the root window which is withdrawn, so the dialog does not appear on the screen. Consequently, activating the about menu will cause IDLE to become unresponsive as it waits for an offscreen window to be closed. Deleting line 28 in aboutDialog.py: self.transient(parent) makes the about dialog behave normally. -- assignee: terry.reedy components: IDLE messages: 357195 nosy: culler, terry.reedy priority: normal severity: normal status: open title: IDLE should not make the about dialog be a transient of the withdrawn root window type: behavior versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue38882> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37848] More fully implement Unicode's case mappings
Marc-Andre Lemburg added the comment: The Unicode implementation is deliberately not locale specific and this should not change. If a locale specific mapping is requested, this should be done explicitly by e.g. providing a parameter to str.lower() / upper() / title(). -- ___ Python tracker <https://bugs.python.org/issue37848> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37760] Refactor makeunicodedata.py: dedupe parsing, use dataclass
Marc-Andre Lemburg added the comment: BTW: Since when do we use type annotations in Python's stdlib ? -- nosy: +lemburg ___ Python tracker <https://bugs.python.org/issue37760> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37751] In codecs, function 'normalizestring' should convert both spaces and hyphens to underscores.
Marc-Andre Lemburg added the comment: Jordon is right. Conversion has to be to underscores, not hyphens. I guess this bug was introduced when the normalization function was converted to C. -- nosy: +lemburg ___ Python tracker <https://bugs.python.org/issue37751> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37406] Disable runtime checks in release mode
Marc-Andre Lemburg added the comment: Given that extensions call these APIs, I find it highly risky to disable these checks in any version of the Python runtime and am -1 on such a change. Using assert() in C is a pretty bad alternative, since this crashes the whole process. It should really only be used where no other means of error handling are possible. Python's exception mechanism is a much better way to signal and handle such errors at the application level. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Jun 26 2019) >>> Python Projects, Coaching and Consulting ... http://www.egenix.com/ >>> Python Database Interfaces ... http://products.egenix.com/ >>> Plone/Zope Database Interfaces ... http://zope.egenix.com/ ::: We implement business ideas - efficiently in both time and costs ::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ http://www.malemburg.com/ -- nosy: +lemburg title: Disable debug runtime checks in release mode -> Disable runtime checks in release mode ___ Python tracker <https://bugs.python.org/issue37406> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35551] Encoding and alias issues
Marc-Andre Lemburg added the comment: 1. Background for "tactis": https://github.com/python/cpython/commit/4fd73f0465ba11c22f0986d04cf91b387ed22c47 # The codecs for these encodings are not distributed with the # Python core, but are included here for reference, since the # locale module relies on having these aliases available. This codec was available as separate package at the time. Later the CJK codecs got added to the stdlib, but this codec was not. I guess it's fine to remove the alias. 2. If the mappings are identical, just leaving one and making the other an alias is fine. Same for aliases of those mapping names. 3. I think we had already resolved this some time ago. -- ___ Python tracker <https://bugs.python.org/issue35551> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13968] Support recursive globs
Marc added the comment: Please review one word documentation change at https://github.com/python/cpython/pull/12918 to clarify that recursive glob ** follows symbolic links to directories. -- nosy: +marc-hb pull_requests: +12844 ___ Python tracker <https://bugs.python.org/issue13968> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36346] Prepare for removing the legacy Unicode C API
Marc-Andre Lemburg added the comment: On 18.03.2019 22:33, Stefan Behnel wrote: > > I had also looked through the unrelated changes, and while, yes, they are > unrelated, they seemed to be correct and reasonable modernisations of the > code base while touching it. They could be moved to a separate PR, but there > is a relatively high risk of conflicts, so I'm ok with keeping them in here > for now. I don't think changing sequence iteration to list iteration only is something that should be hidden in a wchar_t removal PR. My guess is that these changes have made it into the PR by mistake. They deserve a separate PR and discussion. -- ___ Python tracker <https://bugs.python.org/issue36346> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36346] Prepare for removing the legacy Unicode C API
Marc-Andre Lemburg added the comment:
I'd change the title of this bpo item to "Prepare for removing the whcar_t
caching in the Unicode C API".
Note that the wchar_t caching was put in place to allow for external
applications and C code to easily and efficiently interface with Python. By
removing it you will slow down such code significantly, esp. on Linux and
Windows where wchar_t code is fairly common (one of the reasons we added UCS4
in Python was to make the interaction with Linux wchar_t code more efficient).
This should be clearly mentioned as part of the change and the compile time
flags.
BTW: You have a few other changes in the PR which don't have anything to do
with the intended removal:
-envsize = PySequence_Fast_GET_SIZE(keys);
-if (PySequence_Fast_GET_SIZE(values) != envsize) {
+envsize = PyList_GET_SIZE(keys);
+if (PyList_GET_SIZE(values) != envsize) {
--
nosy: +lemburg
___
Python tracker
<https://bugs.python.org/issue36346>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35967] Better platform.processor support
Marc-Andre Lemburg added the comment:
On 08.03.2019 18:50, Jason R. Coombs wrote:
>
>> It's also easy to bypass that by simply seeding the global cache
>> for uname(): _uname_cache.
>> Or you could monkey-patch the platform module
>> in your utility to work around the circular reference.
>
> I don't think these options are possible in the general case. It was what I
> attempted to do in the first place, but could not. Consider the situation
> where a namespace package is present or where a script uses pkg_resources to
> bootstrap itself (a very common case), or any other case where
> `platform.(anything)` is invoked before the "bypass" or "monkey-patch" has a
> chance to run. This happens when running the test suite for `cmdix` because
> pytest invokes pkg_resources to search for entry points and that code invokes
> `platform.system` (or similar) to evaluate environment markers long before
> the cmdix code has been imported.
I don't quite follow: since you are the author of the tool, you can of
course have your uname.py import platform and then apply one of the
above tricks, e.g.
"""
#!/usr/bin/env python3
import platform
# Seed uname cache to avoid calling uname
platform._uname_cache = platform.uname_result(
system='Linux',
node='moon',
release='5.99.99',
version='#1 SMP 2020',
machine='x86_64',
processor='x86_64')
print ('Hello from uname.py')
print ('platform.uname() = %r' % (platform.uname(),))
"""
> Here's what happens:
>
> `platform.(anything)` runs `platform.uname` and `platform.uname` invokes
> `uname -p` in a subprocess _unconditionally_. Python doesn't provide hooks to
> monkey-patch that out before it gets invoked.
This is only true for the platform APIs which need information from
uname. Not in general.
>> Or you could call your utility something else.
>
> The point of this utility is to supply "coreutils" using Python. It's derived
> from an abandoned project called "pycoreutils", one purpose of which is to
> provide the core utilities on a minimal Linux distribution that doesn't have
> uname. Another is to supply coreutils on Windows. Having an alternate name
> isn't really viable when the purpose is to supply that interface.
>
>
> I do think your considerations are reasonable, and I'm close to giving up. I
> look forward to your feedback on the 'resolved-late' branch.
I don't have anything against making calling of uname lazy.
I also don't have anything against return useful information
rather than "unknown".
Your PR is missing tests, though, to support that it actually
returns the same values are before for a set of common platforms.
--
___
Python tracker
<https://bugs.python.org/issue35967>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36297] Remove unicode_internal codec
Marc-Andre Lemburg added the comment: On 15.03.2019 17:55, Serhiy Storchaka wrote: > Is it for debugging only? No, you can use it to store Unicode object as-is without any encoding/decoding, but after the recent changes to the internals of the Unicode implementation it's not all that useful anymore, since we now have per object state which is not reflected by the codec. -- ___ Python tracker <https://bugs.python.org/issue36297> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36297] Remove unicode_internal codec
Marc-Andre Lemburg added the comment: On 15.03.2019 17:35, Serhiy Storchaka wrote: > > What is the purpose of the unicode-internal codec at first place? It provides a fast and direct access to the internal representation of Unicode used in Python to the outside world. -- nosy: +lemburg ___ Python tracker <https://bugs.python.org/issue36297> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35967] Better platform.processor support
Marc-Andre Lemburg added the comment: On 08.03.2019 18:00, Jason R. Coombs wrote: > >> Perhaps adding a more capable API to interface to /proc/cpuinfo > would be a good idea. > > The core concern I want to address is that it's not possible to use any > function in the platform module without invoking "uname -p", and thus it's > not possible to implement "uname" in Python. No amount of supplementary > interfaces will help with that. I don't know where you get that idea from. The uname family of APIs do use "uname -p" on platforms where this exists, but the other ones don't. It's also easy to bypass that by simply seeding the global cache for uname(): _uname_cache. Or you could call your utility something else. Or you could monkey-patch the platform module in your utility to work around the circular reference. To be clear: I do not consider your use case to be particularly common enough to warrant changes to the module, but would welcome additions which bring more or better functionality to the module, e.g. having the processor variable return meaningful where it previously did not (ie. uname() return '' for the processor entry), or adding another API to provide more detailed information. -- ___ Python tracker <https://bugs.python.org/issue35967> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35967] Better platform.processor support
Marc-Andre Lemburg added the comment: Jason: StackExchange does have lots of good hints, but it's not always the correct. In this case, it's clearly wrong. uname -p has been available on many Unix installations for decades. I started writing the module back in 1999 and even then, the support was already working on the systems I used at the time, and several others, as you can see from this page: https://www.egenix.com/www2002/python/mxCGIPython.html The module was originally created to come up with a good name to use for identifying platform binaries coming out of my mxCGIPython project. Note that the processor is not always needed to determine whether software runs on a machine or not. The "uname -m" output often is enough, but there are cases where e.g. compiler options are used which produces code that only works on particular processors. Perhaps adding a more capable API to interface to /proc/cpuinfo would be a good idea. -- ___ Python tracker <https://bugs.python.org/issue35967> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35967] Better platform.processor support
Marc-Andre Lemburg added the comment: Thanks. It would be good to do some before/after tests on popular platforms, e.g. a few Linuxes, MacOS, Windows. -- ___ Python tracker <https://bugs.python.org/issue35967> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35967] Better platform.processor support
Marc-Andre Lemburg added the comment: As the documentation says, the API is intended as fairly portable implementation of the Unix uname helper across platforms. It's fine to redirect this directly to e.g. /proc output instead of using the executable, but in whatever you do here, the output of platform.uname() needs to stay compatible to what the function returned prior to such a change, which usually means: to the output of the uname helper on a system. Could you please check that on most systems, the output remains the same ? Thanks. -- ___ Python tracker <https://bugs.python.org/issue35967> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35840] Control flow inconsistency on closed asyncio stream
Marc Schlaich added the comment: No, I'm seeing the same issue on MacOS. Attached modified example. -- Added file: https://bugs.python.org/file48160/tcp_test.py ___ Python tracker <https://bugs.python.org/issue35840> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35873] Controlling venv from venv no longer works in 3.7.2
New submission from Marc Schlaich : Controlling a venv from the python.exe from another venv does not work since 3.7.2 on Windows. This is probably related to the change bpo-34977: venv on Windows will now use a python.exe redirector rather than copying the actual binaries from the base environment. This is obviously related to bpo-35872, but this could be a different bug. When a Python script in a venv wants to control another venv by running commands like `another-venv\python.exe -m pip` with subprocess, python.exe is not referencing the other venv. It is referencing to the venv the script currently running from. This is probably because os.environ contains a '__PYVENV_LAUNCHER__' which is pointing to the venv from the script. This can be reproduced with pipx (https://github.com/pipxproject/pipx-app) by running pipx install --python "C:\Program Files (x86)\Python37-32\python.exe" --verbose tox This results in pip installing to venvs\pipx-app and not in venvs\tox. I assume a simpler reproduction might be (but I cannot check this anymore as I'm back on 3.7.1 right now): C:\Program Files (x86)\Python37-32\python.exe -m venv C:\Users\$USER\.local\pipx\venvs\tox c:\users\$USER\.local\pipx\venvs\pipx-app\scripts\python.exe -c "import subprocess; subprocess.run(['C:\Users\$USER\.local\pipx\venvs\tox\Scripts\python.exe', '-m', 'pip', 'install', 'tox'])" Downstream bugreport in pipx is https://github.com/pipxproject/pipx-app/issues/81. -- components: Library (Lib), Windows messages: 334659 nosy: paul.moore, schlamar, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Controlling venv from venv no longer works in 3.7.2 type: behavior versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue35873> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35872] Creating venv from venv no longer works in 3.7.2
New submission from Marc Schlaich : Creating a venv from the python.exe from another venv does not work since 3.7.2 on Windows. This is probably related to the change bpo-34977: venv on Windows will now use a python.exe redirector rather than copying the actual binaries from the base environment. For example running c:\users\$USER\.local\pipx\venvs\pipx-app\scripts\python.exe -m venv C:\Users\$USER\.local\pipx\venvs\tox C:\Users\$USER\.local\pipx\venvs\tox\Scripts\python.exe -m pip install --upgrade pip results in pip installing to venvs\pipx-app and not in venvs\tox. Downstream bugreport in pipx is https://github.com/pipxproject/pipx-app/issues/81. -- components: Library (Lib), Windows messages: 334658 nosy: paul.moore, schlamar, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Creating venv from venv no longer works in 3.7.2 type: behavior versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue35872> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35840] Control flow inconsistency on closed asyncio stream
Marc Schlaich added the comment: After having a closer look I fear that there isn't a correct implementation for half closed sockets and returning True from eof_received results in a fundamentally broken state machine. I'm not sure if a selector implementation can handle half closed sockets, at least I'm pretty sure that this is not supported on Windows (https://docs.microsoft.com/en-us/windows/desktop/api/winsock2/nf-winsock2-select). -- ___ Python tracker <https://bugs.python.org/issue35840> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35840] Control flow inconsistency on closed asyncio stream
New submission from Marc Schlaich : After closing a StreamWriter the `StreamReaderProtocol.connection_lost` on the other end is not getting called. In this case the StreamReader is at EOF but calling write/drain does not raise any Exception (and sending data to Nirvana). I would expect that StreamWriter.is_closing returns True after the close and calling write/drain raises immediately and not just after the second call. Please see attached example. I see the same behavior with Proactor and Selector event loop on Windows. Maybe this is expected behavior. But in this case it is completely undocumented. Should there be a check for `StreamReader.at_eof` (and maybe `StreamReader.exception`) before writing to the StreamWriter? This might be related to bpo-34176. -- components: asyncio files: tcp_test.py messages: 334450 nosy: asvetlov, schlamar, yselivanov priority: normal severity: normal status: open title: Control flow inconsistency on closed asyncio stream type: behavior versions: Python 3.7 Added file: https://bugs.python.org/file48082/tcp_test.py ___ Python tracker <https://bugs.python.org/issue35840> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35699] distutils cannot find Build Tools 2017 since 3.7.2
Change by Marc Schlaich : -- keywords: +patch, patch pull_requests: +11016, 11017 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue35699> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35699] distutils cannot find Build Tools 2017 since 3.7.2
Change by Marc Schlaich : -- keywords: +patch, patch, patch pull_requests: +11016, 11017, 11018 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue35699> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35699] distutils cannot find Build Tools 2017 since 3.7.2
Change by Marc Schlaich : -- keywords: +patch pull_requests: +11016 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue35699> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35699] distutils cannot find Build Tools 2017 since 3.7.2
Marc Schlaich added the comment: We are passing arguments -latest(Return only the newest version and last installed.) and "-requires", "Microsoft.VisualStudio.Component.VC.Tools.x86.x64", So this should handle the cases multiple installs and different products without compilers. I try to get a PR ready. -- ___ Python tracker <https://bugs.python.org/issue35699> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35699] distutils cannot find Build Tools 2017 since 3.7.2
New submission from Marc Schlaich : vshwere.exe doesn't return Build Tools 2017 per default. This means Build Tools 2017 are not detected by distutils in 3.7.2 and you get the famous "Microsoft Visual C++ 14.0 is required" error. Please see https://github.com/Microsoft/vswhere/issues/125 for more details. The solution is to add "-products", "*", to the vswhere.exe call. This is a regression of https://bugs.python.org/issue35067. -- components: Distutils messages: 12 nosy: dstufft, eric.araujo, schlamar, steve.dower priority: normal severity: normal status: open title: distutils cannot find Build Tools 2017 since 3.7.2 type: behavior versions: Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue35699> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9400] multiprocessing.pool.AsyncResult.get() messes up exceptions
Marc Schlaich added the comment: Davin, why isn't just one of the simple one-line patches applied. This would be much more reasonable instead of closing this as won't fix. This is a really ugly bug and it took me hours to find the cause... -- nosy: +schlamar ___ Python tracker <https://bugs.python.org/issue9400> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35596] Fatal Python error: initfsencoding: unable to load the file system codec zipimport.ZipImportError: can't find module 'encodings'
Change by Marc Schlaich : -- nosy: +schlamar ___ Python tracker <https://bugs.python.org/issue35596> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35616] Change references to '4.0'.
Marc-Andre Lemburg added the comment: Why not change the wording to read "... will be considered for removal in the next major Python release". Note that removal of Py_UNICODE APIs will not only break compatibility with Python 2, but also with the early Python 3 releases. And please also consider that we may see another change in the Unicode implementation... I've heard discussions about using UTF-8 as internal representation to address the issues with the current unified approach. -- nosy: +lemburg ___ Python tracker <https://bugs.python.org/issue35616> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35544] unicode.encode docstring says return value can be unicode
Marc-Andre Lemburg added the comment: You can install any codec you like and those essentially decide on what to return as type. However, the unicode methods only allow strings or unicode to be returned in Python 2. In Python 3, .encode() only allows bytes. You can still get the full codec encode/decode functionality via the codecs encode/decode methods in Python 3. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Dec 20 2018) >>> Python Projects, Coaching and Consulting ... http://www.egenix.com/ >>> Python Database Interfaces ... http://products.egenix.com/ >>> Plone/Zope Database Interfaces ... http://zope.egenix.com/ ::: We implement business ideas - efficiently in both time and costs ::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ http://www.malemburg.com/ -- ___ Python tracker <https://bugs.python.org/issue35544> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35348] Problems with handling the file command output in platform.architecture()
Marc-Andre Lemburg added the comment: Guys, please read the doc-string of the platform.architecture() function (or ask the person who wrote most of the module). It clearly refers to inspecting a specific executable and only uses the Python interpreter as default. The running process can provide some sane defaults, but is not necessarily using the same values as the given executable. The function does not support multi-architecture executables. This is simply out of scope for the function. Victor: AFAIK, I still own this module, so if you want to deprecate something, please ping me first. -- ___ Python tracker <https://bugs.python.org/issue35348> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35389] Use gnu_get_libc_version() in platform.libc_ver()?
Marc-Andre Lemburg added the comment: Nice. I never liked the "parse the executable approach", but there wasn't anything better available at the time. -- nosy: +lemburg ___ Python tracker <https://bugs.python.org/issue35389> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35346] Modernize Lib/platform.py code
Marc-Andre Lemburg added the comment: Ok, let me add some history here: When I created the platform module it was clear that this would be a module which will frequently need updates, since platforms evolve faster than Python does. I had developed this with a larger number of contributors outside the stdlib for a while and then there was a request to add it to the stdlib. Now in order to keep the module more or less up-to-date, it still required regular updates, so the plan was to have it updated in the current versions of Python, but allow it to be used in older Python versions as well. That was the compromise to have it in the stdlib and not external. Otherwise, I would have not added it to the stdlib. This is why it has a special status and keep backwards compatibility much longer than other code in the stdlib. This worked quite well, but for some systems such as the Linux distros, it was impossible to keep up with the development in that mode. Well, actually, there were multiple reasons why this part failed: 1. Linux distros didn't not have a standard when I added the code, 2. Then some distros started two or three different ones, 3. Distros started to use multiple standards with conflicting data, 4. New distros became popular more often than we could update the code. That's why I was fine with removing the code again and leaving this part to a PyPI package. Does it make more sense now ? -- ___ Python tracker <https://bugs.python.org/issue35346> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35346] Modernize Lib/platform.py code
Marc-Andre Lemburg added the comment: Please keep Python 2.7 compatibility. It should be possible to copy the module back into Python 2.7 and use it there. This is not hard to do and allows it to fulfill its purpose as platform detection module even while part of the stdlib. -- nosy: +lemburg ___ Python tracker <https://bugs.python.org/issue35346> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31873] Inconsistent capitalization of proper noun - Unicode.
Marc-Andre Lemburg added the comment: If you want to do this correctly, you have to check each case: * if "unicode object" refers to a C PyUnicode object, it's probably better to use "PyUnicode object" * if "unicode object" refers to a C PyObject object, with type "unicode", it's probably better to leave it as is * if "unicode object" refers to a Python unicode object, it's probably better to call it "Unicode string object" or just "string object" in Python 3 * if "unicode object" does not indicate whether Python or C is meant, "Unicode object" is probably better -- ___ Python tracker <https://bugs.python.org/issue31873> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25416] Add encoding aliases from the (HTML5) Encoding Standard
Marc-Andre Lemburg added the comment: Please note that we can only add aliases if the encodings are indeed the same. Given that WhatWG has made changes to several standard encodings, this is especially important, since our codecs are mostly based on what the Unicode consortium defines as these encodings. Tests for aliases can be minimal: just verify that the codecs subsystem detects them and results in the correct codec being used. There's no need to download any WhatWG specs for this. -- ___ Python tracker <https://bugs.python.org/issue25416> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1154351] add get_current_dir_name() to os module
Change by Marc Adam Anderson : -- nosy: -marcadam ___ Python tracker <https://bugs.python.org/issue1154351> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34928] string method .upper() converts 'ß' to 'SS' instead of 'ẞ'
Marc Richter added the comment: Sorry then; that did not show up in my search :/ Yes, seems like this is duplicating that one. -- ___ Python tracker <https://bugs.python.org/issue34928> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34928] string method .upper() converts 'ß' to 'SS' instead of 'ẞ'
New submission from Marc Richter : There's a special letter in German orthography called "eszett" (ß). This letter had no uppercase variant for hundreds of years until 2017, there was an uppercase variant added to the official German orthography called "capital eszett" (ẞ) [1]. Python's .upper() string method still translates this to "SS" (which was correct before 2017): ~ $ python3.7.0 Python 3.7.0 (default, Aug 29 2018, 17:15:17) [GCC 5.4.0 20160609] on linux Type "help", "copyright", "credits" or "license" for more information. >>> 'gruß'.upper() 'GRUSS' >>> The result of this example should have been 'GRUẞ' instead. That being said, it's fair to inform about the fact that this letter is still quite unpopular in Germany; it is not even typeable with German keyboards, yet. Anyways, I think since this became officials orthography, it's not Python's job to adopt behaviors but clear rules instead. I'm not sure if this affects .casefold() as well, since I do not get that method's scope. BR, Marc Richter [1]: https://en.wikipedia.org/wiki/Capital_%E1%BA%9E -- components: Interpreter Core messages: 327336 nosy: Marc Richter priority: normal severity: normal status: open title: string method .upper() converts 'ß' to 'SS' instead of 'ẞ' type: behavior versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue34928> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13828] Further improve casefold documentation
Marc Richter added the comment: +1 as well. To be honest, I did not understand what this function does in detail yet. Since not too long ago (2017) in Germany, there was an uppercase-variant for the special letter from this function's example (ß) been added to the official orthography [1]. Is this something that needs to be changed in this function's behavior now or stays this expected behavior? I'm still puzzled and I think the whole function should get a more clear description. [1]: https://en.wikipedia.org/wiki/Capital_%E1%BA%9E -- nosy: +Marc Richter ___ Python tracker <https://bugs.python.org/issue13828> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22232] str.splitlines splitting on non-\r\n characters
Marc-Andre Lemburg added the comment: Why not simply add a new parameter, to make people who want ASCII linebreaks continue to use .splitlines() ? It think it would be less than ideal to have one method break on all Unicode line breaks and another only on ASCII ones. -- ___ Python tracker <https://bugs.python.org/issue22232> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18291] codecs.open interprets FS, RS, GS as line ends
Marc-Andre Lemburg added the comment: On 05.10.2018 14:06, Serhiy Storchaka wrote: > > Then this particularity of codecs streams should be explicitly documented. Yes, probably. Such extensions of scope for different character types in Unicode vs. ASCII are a common gotcha when moving from Python 2 to 3. The same applies to eg. upper/lower case conversion, conversion to numeric values, the various .is*() methods, etc. > codecs.open() was advertised as a way of writing portable code for Python 2 > and 3, and it can still be used in many old programs. AFAIR, we changed this to recommend io.open() instead, after the io module was rewritten in C. Before that we did indeed advertise codecs.open() as a way to write code which produces Unicode in a similar way as io does in Python 3 (they were never fully identical, though). -- ___ Python tracker <https://bugs.python.org/issue18291> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18291] codecs.open interprets FS, RS, GS as line ends
Marc-Andre Lemburg added the comment: Sorry, I probably wasn't clear: the codecs interface is a direct interface to the Unicode codecs and thus has to work according to what Unicode defines. Your PR changes this to be non-compliant and does this for all codecs. That's a major backwards and Unicode incompatible change and I'm -1 on such a change for the stated reasons. If people want to have ASCII only line break handling, they should use the io module, which only uses the codecs and can apply different logic (as it does). Please note that many file formats where not defined for Unicode, and it's only natural that using Unicode codecs on them will result in some differences compared to the ASCII world. Line breaks are one of those differences, but there are plenty others as well, e.g. potentially breaking combining characters or bidi sections, different ideas about upper and lower case handling, different interpretations of control characters, etc. The approach to this has to be left with the applications dealing with these formats. The stdlib has to stick to standards and clear documentation. -- ___ Python tracker <https://bugs.python.org/issue18291> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22232] str.splitlines splitting on non-\r\n characters
Marc-Andre Lemburg added the comment: I am -1 on changing the default behavior. The Unicode standard defines what a linebreak code point is (all code points with character properties Zl or bidirectional property B) and we adhere to that. This may confuse parsers coming from the ASCII world, but that's really a problem with those parsers assuming that .splitlines() only splits on ASCII line breaks, i.e. they are not written in a Unicode compatible way. As mentioned in https://bugs.python.org/issue18291 we could add a parameter to .splitlines(), but this would render the method not much faster than re.split(). Using re.split() is not a work-around in his case, it's an explicit form of defining the character you want to split lines on, if the standards defining your file format as only accepting ASCII line break characters. Since there are many such file formats, perhaps adding a parameter asciionly=True/False would make sense. .splitlines() could then be made to only split on ASCII linebreak characters. This new parameter would then have to default to False to maintain compatibility with Unicode and all previous releases. -- nosy: +lemburg ___ Python tracker <https://bugs.python.org/issue22232> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18291] codecs.open interprets FS, RS, GS as line ends
Marc-Andre Lemburg added the comment: The Unicode .splitlines() splits strings on what Unicode defines as linebreak characters (all code points with character properties Zl or bidirectional property B). This is different than what typical CSV file parsers or other parsers built for the ASCII text files treat as newline. They usually only break on CR, CRLF, LF, so the use of .splitlines() in this context is wrong, not the method itself. It may make sense extending .splitlines() to pass in a list of linebreak characters to break on, but that would make it a lot slower and the same can already be had by using re.split() on Unicode strings. Closing this as won't fix. -- resolution: -> wont fix stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue18291> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34538] Remove encouragement to author a base class for all Exception subclasses in a module
Marc-Andre Lemburg added the comment: Just as extra data point: It is fairly common to have a common exception class which is then used a mixin class together with the standard exception classes, so that you can indeed identify the source of an exception and catch errors based on the source (e.g. say you want to catch database errors coming from MySQL specifically). The Python DB-API also requires to create a separate hierarchy for this purpose. Overall, I wouldn't call this a non-best practice. It depends on the use case, whether it's useful or not. -- nosy: +lemburg ___ Python tracker <https://bugs.python.org/issue34538> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34763] Python lacks 0x4E17
Marc-Andre Lemburg added the comment: We use the Unicode database for these methods. Could you please check whether the database marks the character as numeric ? If yes, we may need to check the database generation. Otherwise, there isn't much we can do, since we use the Unicode database as reference. Thanks -- Marc-Andre Lemburg Sent from my phone. See http://www.egenix.com/company/ for contact information and impressum. On 21 September 2018 18:38:05 GMT+02:00, Serhiy Storchaka wrote: > > Change by Serhiy Storchaka : > > > -- > nosy: +lemburg > > ___ > Python tracker > <https://bugs.python.org/issue34763> > ___ -- ___ Python tracker <https://bugs.python.org/issue34763> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26544] platform.libc_ver() returns incorrect version number
Marc-Andre Lemburg added the comment: I added a comment to the PR, but other than that I think it's good to go. -- ___ Python tracker <https://bugs.python.org/issue26544> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33663] Web.py wsgiserver3.py raises TypeError when CSS file is not found
Jean-Marc Le Peuvedic added the comment:
The exception is raised in the start_response function provided by web.py's
WSGIGateway class in wsgiserver3.py:1997.
# According to PEP , when using Python 3, the response status
# and headers must be bytes masquerading as unicode; that is, they
# must be of type "str" but are restricted to code points in the
# "latin-1" set.
Therefore, header values must be strings whenever start_response is called.
WSGI servers must accumulate headers in some data structure and must call the
supplied "start_response" function, when they have gathered all the headers and
converted all the values to strings.
The fault I observed is not strictly speaking caused by a bug in Python lib
"server.py". Rather, it is a component interaction failure caused by
inadequately defined semantics. The interaction between web.py and server.py is
quite complex, and no component is faulty when considered alone.
I explain:
Response and headers management in server.py is handled by 3 methods of class
BaseHTTPRequestHandler:
- send_response : puts response in buffer
- send_header : converts to string and adds to buffer
("%s: %s\r\n" % (keyword, value)).encode('latin-1', 'strict'))
- end_headers : flushes buffer to socket
This implementation is correct even if send_header is called with an
int value.
Now, web.py's application.py defines a "wsgi(env, start_resp)" function, which
gets plugged into the CherryPy WSGI HTTP server.
The server is an instance of class wsgiserver.CherryPyWSGIServer created in
httpserver.py:169 (digging deeper, actually at line 195).
This server is implemented as a HTTPServer configured to use gateways of type
class WSGIGateway_10 to handle requests.
A gateway is basically an instance of class initialized with a HTTPRequest
instance, that has a "respond" method. Of course the WSGIGateway implements
"respond" as described in the WSGI standard: it calls the WSGI-compliant web
app, which is a function(environ, start_response(status, headers)) returning an
iterator (for chunked HTTP responses). The start_response function provided by
class WSGIGateway is where the failure occurs.
When the application calls web.py's app.run(), the function runwsgi in web.py's
wsgi.py get called. This function determines if it gets request via CGI or
directly. In my case it starts a HTTP server using web.py's runsimple function
(file httpserver.py:158).
This function never returns, and runs the CherryPyWSGIServer, but it first
wraps the wsgi function in two WGSI Middleware callables. Both are defined in
web.py's httpserver.py file. The interesting one is StaticMiddleWare (line
281). Its role, is to hijack URLs starting with /static, as is the case with my
missing CSS file. In order to serve those static resources quickly, its
implementation uses StaticApp (a WSGI function serving static stuff, defined
line 225), which extends Python's SimpleHTTPRequestHandler. That's where to two
libraries connect.
StaticApp changes the way headers are processed using overloaded methods for
send_response, send_header and end_headers. This means that, when StaticApp
calls SimpleHTTPRequestHandler.send_head() to send the HEAD part of the
response, the headers are managed using the overloaded methods. When
send_head() finds out that my CSS file does not exist and calls send_error() a
Content-Length header gets written, but it is not converted to string, because
the overloaded implementation just stores the header name and value in a list
as they come.
When it has finished gathering headers using Python's send_head(), it
immediately calls start_response provided by WSGIGateway, where the failure
occurs.
The bug in Python is not strictly that send_header gets called with an int in
send_error. Rather, it is a documentation bug which fails to mention that
send_header/end_headers MUST CONVERT TO STRING and ENCODE IN LATIN-1.
Therefore the correction I proposed is still invalid, because the combination
of web.py and server.py after the correction, still does not properly encode
the headers.
As a conclusion I would say that:
- In Python lib, the bug is a documentation bug, where documentation fails to
indicate that send_headers and/or end_headers can receive header names or
values which are not strings and not encoded in strict latin-1, and that it is
their responsibility to do so.
- In Web.py because the implementation of the overloaded methods fails to
properly encode the headers.
Of course, changing int to str does no harm and makes everything more
resilient, but does not fix the underlying bug.
--
___
Python tracker
<https://bugs.python.org/issue33663>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33663] Web.py wsgiserver3.py raises TypeError when CSS file is not found
New submission from Jean-Marc Le Peuvedic <lepeuve...@gmail.com>:
When running the built-in web server of web.py, the following error messages
appear when the HTTP client fetches a non existing CSS file:
TypeError('WSGI response header value 469 is not of type str.',)
Traceback (most recent call last):
File
"/home/jm/miniconda3/envs/REST/lib/python3.6/site-packages/web/wsgiserver/wsgiserver3.py",
line 1089, in communicate
req.respond()
File
"/home/jm/miniconda3/envs/REST/lib/python3.6/site-packages/web/wsgiserver/wsgiserver3.py",
line 877, in respond
self.server.gateway(self).respond()
File
"/home/jm/miniconda3/envs/REST/lib/python3.6/site-packages/web/wsgiserver/wsgiserver3.py",
line 1982, in respond
for chunk in response:
File
"/home/jm/miniconda3/envs/REST/lib/python3.6/site-packages/web/httpserver.py",
line 267, in __iter__
self.start_response(self.status, self.headers)
File
"/home/jm/miniconda3/envs/REST/lib/python3.6/site-packages/web/httpserver.py",
line 320, in xstart_response
out = start_response(status, response_headers, *args)
File
"/home/jm/miniconda3/envs/REST/lib/python3.6/site-packages/web/wsgiserver/wsgiserver3.py",
line 2029, in start_response
"WSGI response header value %r is not of type str." % v)
TypeError: WSGI response header value 469 is not of type str.
The faulty header is added by Python library, http/server.py.
Error added in version 3.4 according to comments.
Lines 467-471 in the attached file:
body = content.encode('UTF-8', 'replace')
self.send_header("Content-Type", self.error_content_type)
self.send_header('Content-Length', int(len(body)))
self.end_headers()
The value for 'Content-Length' is passed as an 'int', but only a 'str' is
acceptable.
In the latest revision of 'server.py', the same code appears line 453.
A possible correction is :
body = content.encode('UTF-8', 'replace')
self.send_header("Content-Type", self.error_content_type)
self.send_header('Content-Length', str(int(len(body
self.end_headers()
--
components: Library (Lib)
files: server.py
messages: 317813
nosy: jmlp
priority: normal
severity: normal
status: open
title: Web.py wsgiserver3.py raises TypeError when CSS file is not found
type: behavior
versions: Python 3.6
Added file: https://bugs.python.org/file47616/server.py
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33663>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33598] ActiveState Recipes links in docs, and the apparent closure of Recipes
Marc-Andre Lemburg <m...@egenix.com> added the comment: I'd suggest to contact ActiveState first before jumping to conclusions. -- nosy: +lemburg ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33598> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28167] remove platform.linux_distribution()
Marc-Andre Lemburg <m...@egenix.com> added the comment: Hi Petr, I'm fine with this. Maintaining the necessary logic Python is not really possible in the stdlib. It's better to have a PyPI module for this which can be updated much more easily. Thanks. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue28167> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20087] Mismatch between glibc and X11 locale.alias
Marc-Andre Lemburg <m...@egenix.com> added the comment: Thanks, Serhiy. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue20087> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33278] libexpat uses HAVE_SYSCALL_GETRANDOM instead of HAVE_GETRANDOM_SYSCALL
New submission from Marc-Andre Lemburg <m...@egenix.com>: See https://github.com/python/cpython/blob/3.6/Modules/expat/xmlparse.c#L87 The Python configure script tests and sets the variable HAVE_GETRANDOM_SYSCALL. The solution would be to have Python's config script define HAVE_SYSCALL_GETRANDOM as well, in case it detects the function. -- components: XML messages: 315289 nosy: lemburg priority: normal severity: normal status: open title: libexpat uses HAVE_SYSCALL_GETRANDOM instead of HAVE_GETRANDOM_SYSCALL versions: Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33278> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29753] Ctypes Packing Bitfields Incorrectly - Linux
Marc Le Roy <mleroy...@gmail.com> added the comment: No solution found to solve this issue ? The anomaly is not a cross platform inconsistency, it is an inconsistency between the behaviours of GCC and ctypes, both under Linux or Cygwin, when defining packed structures : [Marc@I7-860 ~/dev/python/ctypes-bitfields-bug] make test ./bitfield_test1 sizeof(BF32) = 12 ; Memory dump of BF32 = 0x sizeof(BF64) = 12 ; Memory dump of BF64 = 0x python3 bitfield_test1.py sizeof(BF32) = 16 ; Memory dump of BF32 = 0xff00ff00ff00ff00 sizeof(BF64) = 16 ; Memory dump of BF64 = 0x -- Added file: https://bugs.python.org/file47511/ctypes-bitfields-bug.tar.gz ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue29753> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32931] Python 3.70b1 specifies non-existent compiler gcc++
New submission from Marc Culler <cul...@math.uic.edu>: Compiling an external module in the 3.7.0b1 prerelease on macOS High Sierra failed for me because a compiler named "gcc++" was not found. As far as I can tell there is no such compiler in the current XCode release. I don't know if there ever was one. The culprit file is: /Library/Frameworks/Python.framework//Versions/3.7/lib/python3.7/_sysconfigdata_m_darwin_darwin.py The following patch fixed the problem for me: 38c38 < 'CXX': 'gcc++', --- > 'CXX': 'g++', 484c484 < 'LDCXXSHARED': 'gcc++ -bundle -undefined dynamic_lookup', --- > 'LDCXXSHARED': 'g++ -bundle -undefined dynamic_lookup', -- components: macOS messages: 312697 nosy: culler, ned.deily, ronaldoussoren priority: normal severity: normal status: open title: Python 3.70b1 specifies non-existent compiler gcc++ versions: Python 3.7 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32931> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32846] Deletion of large sets of strings is extra slow
Marc-Andre Lemburg <m...@egenix.com> added the comment: Reminds of some experiments someone did a while ago as part of the GIL removal attempts where the ref count integers are all kept in a separate array. The intent there was to be able to do locking on a single array rather than on individual decref cells. This would solve the issue with having to jump around in memory to decref all objects, but I'm not sure whether the overall win would be a lot, since deallocation of the memory blocks typically requires accessing the block itself as well (to update the block chain list pointers), unless the memory allocator uses some smart cache local block management as well (I believe that pymalloc does, but could be wrong). In any case, this sounds like a fun experiment for a GSoC student. Perhaps the PSF could donate an AWS EC2 instance with enough RAM to do the experiments. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32846> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32516] Add a shared library mechanism for win32
Marc-Andre Lemburg <m...@egenix.com> added the comment: On 17.01.2018 02:52, xoviat wrote: > > xoviat <xov...@gmail.com> added the comment: > > For the record, moving the DLL path manipulation code into the interpreter > would address the concern that importing a module would not manipulate the > search path because the behavior would move into Python itself. Can't you simply place the DLLs into the PythonXX\DLLs\ directory ? That's where Python itself keeps external DLLs (and several PYDs) and it won't change after installation of Python. Or create a special container package on PyPI into which you place the DLLs and add dependencies to this in all other packages. You can then load the DLL via win32 LoadLibrary either using the Python win32 tools or ctypes: https://docs.python.org/3.7/library/ctypes.html http://timgolden.me.uk/pywin32-docs/win32api__LoadLibrary_meth.html https://www.programcreek.com/python/example/51388/win32api.LoadLibrary FWIW: I think this ticket has shown plenty options to possible solutions, including many which do not manipulate the path. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32516> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32516] Add a shared library mechanism for win32
Marc-Andre Lemburg <m...@egenix.com> added the comment: Probably better overall to go with a conda package which puts the DLLs in a central location and manages the dependencies. You can then load the DLL in the package before loading the PYD and you're all set. Whether in an __init__.py or elsewhere is really up to the package. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32516> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31900] localeconv() should decode numeric fields from LC_NUMERIC encoding, not from LC_CTYPE encoding
Marc-Andre Lemburg <m...@egenix.com> added the comment: Sounds like a good compromise :-) -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31900> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31900] localeconv() should decode numeric fields from LC_NUMERIC encoding, not from LC_CTYPE encoding
Marc-Andre Lemburg <m...@egenix.com> added the comment: Indeed. The major problem with all libc locale functions is that they are not thread safe. The GIL does help a bit protecting against corrupted data, though. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31900> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31900] localeconv() should decode numeric fields from LC_NUMERIC encoding, not from LC_CTYPE encoding
Marc-Andre Lemburg <m...@egenix.com> added the comment: Ok, it seems that the C setlocale() itself does not follow the conventions set forth for environment variables: http://pubs.opengroup.org/onlinepubs/7908799/xsh/setlocale.html (see the example at the bottom) So the behavior shown by Python's setlocale() is fine. However, that still doesn't magically make this work: locale.setlocale(locale.LC_ALL, 'C.UTF-8') locale.setlocale(locale.LC_NUMERIC, 'fr_FR.ISO8859-1') If LC_NUMERIC uses a different encoding than LC_ALL, there's really no surprise in having numeric formatting fail. localeconv() will output the set encoding for the numeric string conversion and Python will decode this using the locale encoding set by LC_ALL. If those two are different, you run into problems. I would not consider this a bug in Python, but rather in the locale settings passed to setlocale(). -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31900> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31900] localeconv() should decode numeric fields from LC_NUMERIC encoding, not from LC_CTYPE encoding
Marc-Andre Lemburg <m...@egenix.com> added the comment: I just wanted to note that the description and title may cause a wrong interpretation of what should happen: If you first set LC_ALL and then one of the other categories such as LC_NUMERIC, locale C functions will still use the LC_ALL setting for everything. LC_NUMERIC does not override the LC_ALL setting. I tested this on OpenSUSE and get the same wrong results. Apparently, locale.localeconv() does not respect the above order. That's a bug. I'm not sure whether the OP's quoted behavior is a bug, though, since if the locale encoding is not UTF-8, you cannot really expect using UTF-8 numeric separators to output correctly. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31900> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32516] Add a shared library mechanism for win32
Marc-Andre Lemburg <m...@egenix.com> added the comment: >From experience with doing something similar in egenix-pyopenssl, I recommend >putting the DLLs into the same directory as the PYD file on Windows. If you >want to be extra safe, you can explicitly load the DLL, but normally this is >not needed. On Linux and other OSes, it's best to dlopen() to explicitly load the lib, since rpath and OS search paths are not always reliable. -- nosy: +lemburg ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32516> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31900] localeconv() should decode numeric fields from LC_NUMERIC encoding, not from LC_CTYPE encoding
Marc-Andre Lemburg <m...@egenix.com> added the comment: Just FYI: LC_ALL has precedence over all other more specific LC_* settings: http://pubs.opengroup.org/onlinepubs/7908799/xbd/envvar.html http://man7.org/linux/man-pages/man7/locale.7.html Please confirm the bug without having LC_ALL or LANG set. Thanks. -- nosy: +lemburg ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31900> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32291] Value error for string shared memory in multiprocessing
New submission from Marc Guetg <guetg.m...@gmail.com>:
It seems like sharing a string over processes is not possible.
#!/usr/bin/env python3
import multiprocessing
import threading
import ctypes
def fun(share_c, share_s, set_c, set_s, name):
print(f'{name}: {share_c.value}; {share_s.value}')
share_c.value = set_c
share_s.value = set_s
print(f'{name}: {share_c.value}; {share_s.value}')
if __name__ == '__main__':
share_c = multiprocessing.Value(ctypes.c_wchar, 'a')
share_s = multiprocessing.Value(ctypes.c_wchar_p, 'aa')
print(f'pre_thread: {share_c.value}; {share_s.value}')
thread = threading.Thread(target=fun, args=(share_c, share_s,
'b', 'bb', 'thread'))
thread.start()
thread.join()
print(f'post_thread: {share_c.value}; {share_s.value}')
process = multiprocessing.Process(target=fun, args=(share_c,
share_s, 'c', 'cc', 'process'))
process.start()
process.join()
print(f'post_process: {share_c.value}', end='; ')
print(share_s.value) # <--- Blows here
produces:
pre_thread: a; aa
thread: a; aa
thread: b; bb
post_thread: b; bb
process: b; bb
process: c; cc
post_process: c; Traceback (most recent call last):
File "test2.py", line 30, in
print(share_s.value) # <--- Blows here
File "", line 5, in getvalue
ValueError: character U+ff92f210 is not in range [U+; U+10]
Where the character value in the error message is different every time. To me
this seems like a bug as it is working properly with threads as well as single
characters. (Maybe relevant question also here:
https://stackoverflow.com/questions/47763878/how-to-share-string-between-processes?noredirect=1#comment82492062_47763878)
For the case it matters:
Python 3.6.1 (Anaconda 4.4.0) on RHEL 6
--
components: Library (Lib), Unicode
messages: 308144
nosy: ezio.melotti, magu, vstinner
priority: normal
severity: normal
status: open
title: Value error for string shared memory in multiprocessing
type: crash
versions: Python 3.6
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32291>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29753] Ctypes Packing Bitfields Incorrectly - Linux
Change by Marc Le Roy <mleroy...@gmail.com>: -- nosy: +mleroy003 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue29753> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31987] Ctypes Packing Bitfields Incorrectly - GCC both Linux and Cygwin
New submission from Marc Le Roy <mleroy...@gmail.com>:
The structure :
typedef struct __attribute__ ((packed)) {
unsigned int F0:24;
unsigned int F3:24;
unsigned int F6:24;
unsigned int F9:24;
} StructF_T;
is mapped as expected by GCC under both Linux and Cygwin.
As expected, the memory layout seen by the C program is :
0x11223344
Using this definition :
class StructF(ctypes.BigEndianStructure):
_pack_ = 1
_fields_ = [
('F0', ctypes.c_uint, 24),
('F3', ctypes.c_uint, 24),
('F6', ctypes.c_uint, 24),
('F9', ctypes.c_uint, 24),
]
The memory layout seen from Python is not consistent :
0x1100220033004400
It seems that the pack option is ignored by ctypes in such a case.
I found the same problem using both ctypes.BigEndianStructure and
ctypes.LittleEndianStructure
--
components: ctypes
messages: 305914
nosy: mleroy003
priority: normal
severity: normal
status: open
title: Ctypes Packing Bitfields Incorrectly - GCC both Linux and Cygwin
versions: Python 3.6
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue31987>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31895] Native hijri calendar support
Marc-Andre Lemburg <m...@egenix.com> added the comment: There are other PyPI packages available for this specific calendar as well, e.g. https://pypi.python.org/pypi/umalqurra/ Perhaps you could send Neil a PR to make the calculation more accurate ?! In any case, the stdlib is not meant to cover everything, only a basic subset of functionality, so adding support for more than just one calendar is out of scope. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31895> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31895] Native hijri calendar support
Marc-Andre Lemburg <m...@egenix.com> added the comment: I agree with Steven: It's best to use a PyPI package for calendar support such as https://pypi.python.org/pypi/convertdate/. We only have the standard Gregorian calendar support in datetime and calendar modules. -- nosy: +lemburg ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31895> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31803] time.clock() should emit a DeprecationWarning
Marc-Andre Lemburg <m...@egenix.com> added the comment: On 26.10.2017 13:46, Serhiy Storchaka wrote: > > It is very bad, that the function with such attractive name has different > meaning on Windows and Unix. I'm sure that virtually all uses of clock() are > broken because its behavior on other platform than used by the author of the > code. Not really, no. People who write cross-platform code are well aware of the differences of time.clock() and people who just write for one platform know how the libc function of the same function works on their platform. Unix: http://man7.org/linux/man-pages/man3/clock.3.html Windows: https://msdn.microsoft.com/en-us/library/4e2ess30.aspx -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31803> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31803] time.clock() should emit a DeprecationWarning
Marc-Andre Lemburg <m...@egenix.com> added the comment: On 25.10.2017 01:31, STINNER Victor wrote: > > Marc-Andre: "Yes, to avoid yet another Python 2/3 difference. It should be > replaced with the appropriate variant on Windows and non-Windows platforms. > From Serhiy's response that's time.process_time() on non-Windows platforms > and time.perf_counter() on Windows." > > I don't understand why you mean by "replaced with". Do you mean modify the > implementation of the time.clock()? What I meant is that time.clock() is replaced with the higher accuracy timers corresponding to the current time.clock() implementation on the various platforms in order to retain backwards compatibility. In other words: if sys.platform == 'win32': time.clock = time.perf_counter else: time.clock = time.process_time I know that time.clock() behaves differently on different platforms, but this fact has been known for a long time and is being used by Python code out there for timing purposes. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31803> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31803] time.clock() should emit a DeprecationWarning
Marc-Andre Lemburg <m...@egenix.com> added the comment: On 24.10.2017 11:23, STINNER Victor wrote: > > Marc-Andre Lemburg: "Thanks for pointing that out. I didn't know." > > Do you still think that we need to modify time.clock() rather than > deprecating it? Yes, to avoid yet another Python 2/3 difference. It should be replaced with the appropriate variant on Windows and non-Windows platforms. From Serhiy's response that's time.process_time() on non-Windows platforms and time.perf_counter() on Windows. The documentation can point to the new functions and recommend these over time.clock(). -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31803> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31803] time.clock() should emit a DeprecationWarning
Marc-Andre Lemburg <m...@egenix.com> added the comment: On 22.10.2017 15:14, Serhiy Storchaka wrote: > > Serhiy Storchaka <storchaka+cpyt...@gmail.com> added the comment: > > On non-Windows platforms clock() returns the processor time, perf_counter() > does include time elapsed during sleep. > >>>> import time >>>> start = time.clock(); time.sleep(1); print(time.clock() - start) > 9.7001374e-05 >>>> start = time.perf_counter(); time.sleep(1); print(time.perf_counter() - >>>> start) > 1.000714950998372 Thanks for pointing that out. I didn't know. Is there a different clock with similar accuracy we can use to only count CPU time on Unix ? -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31803> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31803] time.clock() should emit a DeprecationWarning
Marc-Andre Lemburg <m...@egenix.com> added the comment: On 20.10.2017 19:46, Serhiy Storchaka wrote: > > This will break a code that depends on the current behavior on non-Windows > platforms. And this will contradict the expectation of non-Windows > programmers. If change the behavior of clock() on non-Windows platforms, it > should be done only after the period of emitting FutureWarning. Could you explain which behavior is changed by this on non-Windows platforms ? time.clock() only switches to a more accurate clock. That's pretty much it. Which clock it used on which platform was platform dependent anyway, so there's no real change in behavior. For benchmarking and other measurements, time.time() was recommended on Unix and time.clock() on Windows. time.clock() never good resolution on Unix, so the situation only improves by using a more accurate clock. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31803> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31803] time.clock() should emit a DeprecationWarning
Marc-Andre Lemburg <m...@egenix.com> added the comment: On 18.10.2017 11:45, STINNER Victor wrote: > Marc-Andre, Ethan: What do you think of removing the deprecation warning from > the C (my last commit), leave the deprecation warning in the documentation, > and modify time.clock() to become an alias to time.perf_counter()? > > By alias, I really mean time.clock = time.perf_counter, so > time.clock.__name__ would say "perf_counter". That's what I think would be a better solution, since the absolute value of time.clock() is never used, only the difference. If you then get better accuracy in that difference, things can only get better, so this is not really backwards compatibility issue (nothing gets worse). Not sure whether the function name would cause an incompatibility issue. I doubt it, but if it does we could have time.clock() as function which then simply calls time.perf_counter(). -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31803> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31803] time.clock() should emit a DeprecationWarning
Marc-Andre Lemburg <m...@egenix.com> added the comment: time.cock() is used in a lot of code. Why can't we simply replace the functionality with one of the other functions ? The documentation certainly allows for such a change, since it pretty much just says that only the delta between two values has a meaning. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31803> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31530] Python 2.7 readahead feature of file objects is not thread safe
Marc-Andre Lemburg added the comment: On 20.09.2017 17:22, Guido van Rossum wrote: > >> Why not simply document the fact that read ahead in Python 2.7 >> is not thread-safe and leave it at that ? > > Program bugs should not crash the interpreter. (ctypes excepted.) Ideally not, agreed :-) -- title: [2.7] Python 2.7 readahead feature of file objects is not thread safe -> Python 2.7 readahead feature of file objects is not thread safe ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31530> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31530] [2.7] Python 2.7 readahead feature of file objects is not thread safe
Marc-Andre Lemburg added the comment: Ah, didn't see Benjamin's patch: much better solution :-) -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31530> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31530] [2.7] Python 2.7 readahead feature of file objects is not thread safe
Marc-Andre Lemburg added the comment: Why not simply document the fact that read ahead in Python 2.7 is not thread-safe and leave it at that ? .next() and .readline() already don't work well together, so this would just add one more case. -- nosy: +lemburg ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31530> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31382] CGI upload error when file ~< 10kb
New submission from Marc:
An error occurs when uploading a file ~<10kb:
A problem occurred in a Python script. Here is the sequence of function calls
leading up to the error, in the order they occurred.
/var/www/html/file-uploader/uploader.py in ()
39
40 # A nested FieldStorage instance holds the file
=> 41 fileitem = form['file']
42
43 # Test if the file was uploaded
fileitem undefined, form = FieldStorage(None, None, '')
/usr/lib/python3.4/cgi.py in __getitem__(self=FieldStorage(None, None, ''),
key='file')
591 """Dictionary style indexing."""
592 if self.list is None:
=> 593 raise TypeError("not indexable")
594 found = []
595 for item in self.list:
builtin TypeError =
TypeError: not indexable
args = ('not indexable',)
with_traceback =
but not when file is ~> 10kb
--
components: Extension Modules
messages: 301582
nosy: mschaming
priority: normal
severity: normal
status: open
title: CGI upload error when file ~< 10kb
versions: Python 3.4
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue31382>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31332] Building modules by Clang with Microsoft CodeGen
Marc-Andre Lemburg added the comment: You will have to also create a new compiler class for the compiler. If this is more or less the same clang as used on Unix and MacOS, chances are high, the UnixCCompiler class already supports most of it. Only some changes related to paths may be necessary. That said, standard CPython is compiled with VC++ so you will likely get better compatibility by compiling extension modules with the same compiler. -- nosy: +lemburg ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31332> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30717] Add unicode grapheme cluster break algorithm
Marc-Andre Lemburg added the comment: On 03.08.2017 15:05, Guillaume Sanchez wrote: > > Guillaume Sanchez added the comment: > > I have a few criticism to do against that proto-PEP > > http://mail.python.org/pipermail/python-dev/2001-July/015938.html > > In particular, the fact that all those functions return an index prevents any > state keeping. If you want state keeping for iterating over multiple parts of the string, you can use an iterator. The APIs were inspired by the standard string.find() APIs, that's why they work on indexes and don't return Unicode strings. As such, they serve a different use case than an iterator. With the APIs, scanning would always start at the given index in the string and move forward/backward to the start of the next . -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30717> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30459] PyList_SET_ITEM could be safer
Espie Marc added the comment: it's still 100% safe as a macro since each parameter is not used more than once. only the return type is an issue. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30459> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30459] PyList_SET_ITEM could be safer
Espie Marc added the comment: Note that the API is fully documented for returning void... not anything else. "No basis" right. We're taling 1 pieces of software. a lot of what is actually used in the world. I'm very surprised, considering python has routinely done "spring cleanup" by breaking fairly old apis. If this breaks, people will fix their code, seriously. In most places, we would rather have undocumented, unportable code, break *cleanly*, rather than rely on a fuzzy behavior that could possibly change at any moment, and that was never documented as doing anything. Or is there some kind of mystique that, because this is low-level C implementation, somehow, python programmers are not going to be able to cope with the internals ? -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30459> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30459] PyList_SET_ITEM could be safer
Espie Marc added the comment: yep, casting to (void) would be safer indeed. didn't think of that one ;) -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30459> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30459] PyList_SET_ITEM could be safer
Espie Marc added the comment: Well, there is not going to be a lot of breakage. This problem is the only instance I've encountered in the full OpenBSD ports tree. I thought python was supposed to be a clean language, and didn't shy away from removing stuff/tweaking stuff to achieve that goal ?... The py-kde4 error was deadly. I'm lucky clang finally caught it, but I'd rather this kind of stuff just not compile. I think we're in a world where *correctness* is finally beginning to matter a bit more than *compatibility forever whatever the cost*. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30459> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30459] PyList_SET_ITEM could be safer
New submission from Espie Marc:
Documentation says PyList_SET_ITEM is void, but it lies. The macro is such that
it yields the actual element being set.
wrapping the macro content in a do {} while (0) makes sure PyList_SET_ITEM is
really void, e.g.:
#define PyList_SET_ITEM(op, i, v) do { (((PyListObject *)(op))->ob_item[i] =
(v)); } while (0)
I just ran into the problem while compiling py-qt4 with clang.
There was some confusion between PyList_SET_ITEM and PyList_SetItem:
if (obj == NULL || PyList_SET_ITEM (l, i, obj) < 0)
g++ didn't catch it (because it doesn't see negative pointers as a problem),
but clang++ instantly broke.
With PyList_SET_ITEM truly void the problem disappears.
--
components: Interpreter Core
messages: 294362
nosy: espie
priority: normal
severity: normal
status: open
title: PyList_SET_ITEM could be safer
type: enhancement
versions: Python 3.6
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30459>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30310] tkFont.py assumes that all font families are encoded as ascii in Python 2.7
Marc Culler added the comment:
The name of a Tk font family is a byte sequence obtained from the operating
system. But, this being Python 2.7, there is no distinction between the str
type and the bytes type. The byte sequence is definitely not ascii encoded on
a Japanese Windows system. It is a utf8-encoded byte string. This is why I
called v.decode('utf8') in my patch. Note that this bug does not occur with
Python 3.6.
Terry, I understand that text is better and I hope I never have to resort to an
image again. Since I don't speak Japanese myself, even setting up a Japanese
Windows VM for testing was pretty challenging for me. I was able to take a
screenshot without having to translate any Japanese menus, so I took that
shortcut. Sorry about that.
This report was indeed triggered by a real "crash" in your sense. It occurred
in a GUI application bundled with pyinstaller. Any unhandled exception in a
pyinstaller app results in termination of the process and posts a Windows error
message box saying 'Failed to execute script XXX'. For the report, however, I
was isolating the underlying unhandled exception in Font.copy() that had caused
the real crash of the GUI application.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30310>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30310] tkFont.py assumes that all font families are encoded as ascii in Python 2.7
Marc Culler added the comment: The attached patch simply decodes string options to the Font._set() method using the utf8 codec. Other options (which will be numbers) are converted to ascii strings as currently happens. This makes it possible to use the Font.copy() method without raising an exception when the font family name is not ascii encoded. -- keywords: +patch Added file: http://bugs.python.org/file46855/tkFont.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30310> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30310] tkFont.py assumes that all font families are encoded as ascii in Python 2.7
Changes by Marc Culler <cul...@math.uic.edu>: Added file: http://bugs.python.org/file46851/JapanesePythonBug.png ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30310> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30310] tkFont.py assumes that all font families are encoded as ascii in Python 2.7
New submission from Marc Culler:
And that is a very bad assumption. On Windows 10 in the Japanese locale the
default TkFixedFont has family u'\uff2d\uff33 \u30b4\u30b7\u30c3\u30af' (a
transliteration of MS Gothic).
The error occurs on line 51:
47 def _set(self, kw):
48 options = []
49 for k, v in kw.items():
50 options.append("-"+k)
>>>> 51 options.append(str(v))
52 return tuple(options)
I will attach a screenshot showing the crash on a Japanese Windows 10 system,
running in the Python 2.7 command line application.
--
components: Tkinter
messages: 293256
nosy: culler
priority: normal
severity: normal
status: open
title: tkFont.py assumes that all font families are encoded as ascii in Python
2.7
type: crash
versions: Python 2.7
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30310>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26434] multiprocessing cannot spawn grandchild from a Windows service
Marc Schlaich added the comment: I opened a PR on GitHub, please review. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26434> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29533] urllib2 works slowly with proxy on windows
Marc Schlaich added the comment: Well, you can read the proxy settings from registry and write them to os.environ (no_proxy needs to be transformed as it has a different format). This will only take effect for the current process. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29533> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29533] urllib2 works slowly with proxy on windows
Marc Schlaich added the comment: BTW, you can workaround this issue by defining the `http_proxy` and `no_proxy` environment variables. In this case urllib isn't doing any DNS request. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29533> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29533] urllib2 works slowly with proxy on windows
Marc Schlaich added the comment: Julia, could you please add other major browsers/HTTP clients (Firefox, Chrome, curl, ...) to your comparison (compare_ie_urllib.txt). I would expect that Python/urllib is the only implementation doing DNS requests for proxy bypass handling. Please note that curl uses the `no_proxy` environment variable, so the syntax is slightly different. For anyone who doesn't fully grasp the details of this issue, there might be a better explanation at https://github.com/kennethreitz/requests/issues/2988. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29533> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
