Philippe Ombredanne added the comment:
Sorry, my comment was at best nonsensical gibberish!
I meant to say that this warning message should include the actual regex at
fault; otherwise it is hard to fix when the regex in question comes from some
data structure like a list; then the line
Philippe Ombredanne added the comment:
FWIW, this warning is annoying because it is hard to fix in the case where the
regex are source from data: the warning message does not include the regex at
fault; it should otherwise the warning is noisy and ineffective IMHO.
--
nosy
Philippe Ombredanne added the comment:
Actually this is problematic on multiples counts:
1. the behaviour changes and this is a regression
2. even if that new buggy behaviour was the one to use, it should not give
preference to knownfiles ovr init-provided files, but at least take
Philippe Ombredanne added the comment:
The changes introduced by this ticket in
https://github.com/python/cpython/commit/9fc720e5e4f772598013ea48a3f0d22b2b6b04fa#r45794801
are problematic.
I discovered this from having tests failing when testing on Python 3.7 and up
The bug is that calling
Philippe Ombredanne added the comment:
So the other locations to add docs would be petinetially
- https://docs.python.org/3/library/os.html?#os.add_dll_directory
- https://docs.python.org/3/extending/windows.html
- https://docs.python.org/3/faq/windows.html#is-a-pyd-file-the-same-as-a-dll
Change by Philippe Ombredanne :
--
keywords: +patch
pull_requests: +21411
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/22372
___
Python tracker
<https://bugs.python.org/issu
Philippe Ombredanne added the comment:
> I wouldn't refuse a docs PR to add a short section pointing to
> this page and explaining its relevance:
> https://docs.microsoft.com/cpp/build/reference/dependents
Steve,
would you see this as a note in
https://docs.python.org/3/library/ct
Philippe Ombredanne added the comment:
Eric Smith, you wrote:
> My understanding is that Windows doesn't tell you which DLL is missing. I
> think the best we could do is append something to the error message saying
> "or one its dependencies".
If we have such an error
Philippe Ombredanne added the comment:
>From https://bugs.python.org/issue41836 closed as a dupe of this:
When the dependency of a DLL is missing (at least on Windows) the error "
OSError: [WinError 126] The specified module could not be found" is raised when
calling ctypes.
Philippe Ombredanne added the comment:
Eric, Thanks!
This is IMHO a dupe of https://bugs.python.org/issue25655 in earnest. So I am
closing this in favor of that and will carry over comments there
--
components: -Windows
resolution: -> duplicate
stage: -> resolved
status
New submission from Philippe Ombredanne :
When the dependency of a DLL is missing (at least on Windows) the error "
OSError: [WinError 126] The specified module could not be found" is raised when
calling ctypes.CDLL(dll_path) even when this "dll_path" exists... because t
Philippe Ombredanne added the comment:
Şahin Kureta you wrote:
> I know it is not finalized and released yet but are you going to
> implement Version 14.0.0 of the Unicode Standard?
> It finally solves the issue of Turkish lower/upper case 'I' and 'i'.
Thank you for the pointer!
Philippe Ombredanne added the comment:
Thank for the (re) explanation. Unicode is tough!
Basically this is the issue i have really in the end with the folding: what
used to be a proper alpha string is not longer one after a lower() because the
second codepoint is a punctuation and I use
Philippe Ombredanne added the comment:
There is a weird thing though (using Python 3.6.8):
>>> [x.lower() for x in 'İ']
['i̇']
>>> [x for x in 'İ'.lower()]
['i', '̇']
I would expect that the results would be the same in both cases. (And this is a
source of a bug for
14 matches
Mail list logo
