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
Change by Marc Culler :
--
versions: +Python 2.7 -Python 3.7
___
Python tracker
<https://bugs.python.org/issue38882>
___
___
Python-bugs-list mailing list
Unsub
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.
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.
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
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
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/issue37
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
<ht
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
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
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
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 co
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 w
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 ar
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 use
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.
-
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 i
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
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/issue35
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
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/issue35
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
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
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
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
Change by Marc Schlaich :
--
keywords: +patch, patch
pull_requests: +11016, 11017
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issu
Change by Marc Schlaich :
--
keywords: +patch, patch, patch
pull_requests: +11016, 11017, 11018
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issu
Change by Marc Schlaich :
--
keywords: +patch
pull_requests: +11016
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue35699>
___
___
Py
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 product
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/
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
Change by Marc Schlaich :
--
nosy: +schlamar
___
Python tracker
<https://bugs.python.org/issue35596>
___
___
Python-bugs-list mailing list
Unsubscribe:
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 p
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
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
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.o
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
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
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
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
Change by Marc Adam Anderson :
--
nosy: -marcadam
___
Python tracker
<https://bugs.python.org/issue1154351>
___
___
Python-bugs-list mailing list
Unsubscribe:
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/issue34
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"
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
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
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 movin
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
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
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
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
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
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/issue26
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
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
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
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.
Marc-Andre Lemburg <m...@egenix.com> added the comment:
Thanks, Serhiy.
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue20087>
___
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
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
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 releas
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 indi
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
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 __ini
Marc-Andre Lemburg <m...@egenix.com> added the comment:
Sounds like a good compromise :-)
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
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 tracke
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
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
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 DL
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
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,
Change by Marc Le Roy <mleroy...@gmail.com>:
--
nosy: +mleroy003
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue29753>
___
__
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 ex
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
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.
-
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 be
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 S
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?
Y
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 includ
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 c
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.cl
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 betwe
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.)
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/i
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
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 FieldStor
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
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 parti
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/i
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 "
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/i
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
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
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
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
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
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
Marc Schlaich added the comment:
I opened a PR on GitHub, please review.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26434>
___
__
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
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>
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
201 - 300 of 2192 matches
Mail list logo
