Xavier Morel added the comment:
PS: "platform.system()" also documents `Java` as a value which doesn't seem to
make that much sense, however it's an open set so probably less of an issue /
source of confusion.
--
___
Py
New submission from Xavier Morel :
os.name is defined as:
> The following names have currently been registered: 'posix', 'nt', 'java'.
In my understanding, the value `'java'` is for the benefit of jython, which is
rather poorly. Other third-party
Xavier Morel added the comment:
> True is a boolean so ~True should return False according to me.
That's be a BC break for no reason: if you want to invert a boolean you can
just `not` it.
> True is not the same as 1
For historical reasons, in Python it is:
>>> bool.m
New submission from Xavier Morel :
concurrent.futures.Future currently has the note:
> Future instances are created by Executor.submit() and should not be created
> directly except for testing.
That seems like a shame as futures are useful concurrency construct and having
to rebuil
New submission from francois-xavier callewaert :
```
>>> import logging
>>> logging.getLogger().handlers[0].setFormatter(logging.Formatter(fmt='{asctime}
>>> {message}',
Xavier Morel added the comment:
> If working Python 3 program suddenly became emitting BytesWarning it will
> confuse users.
Oh yeah no I meant making it a normal warning, without needing the `-b` flag,
not enabling it by default.
Because controlling / configuring warnings can b
Xavier Morel added the comment:
And though I did not check, I expect the `-b` flag exists mostly because of the
performance impact of the warning any time bytes are checked for equality, but
surely that impact would be limited and probably not very relevant for the
stringification of bytes
Xavier Morel added the comment:
> I am not against documenting the behavior of -b and BytesWarning clearly. I
> don't think that anyone would be against. Just somebody have to provide a PR.
Right but what about the ability to enable warning on stringification without
enabling the
Xavier Morel added the comment:
Serhiy an other question (because I've encountered it *again*), do you think
it'd be possible to split out the specific warning of stringifying (but *not*
explicitely repr-ing) a bytes instance from everything else?
There are use-cases for it, b
New submission from Xavier Morel :
Python code uses a fair amount of globals, and sometimes there's no good choice
but to do dodgy things and temporarily update global state for one reason or
another e.g. redirect a standard fd or stream (cf redirect_stdout),
monkey-patch a built
Xavier Morel added the comment:
> But if we allow for ellipsis, then would we not also have to start allowing
> characters like ≥ and ≤ in Python?
No, they're not defined as canonically equivalent to >= and <= by the Unicode
specification:
>>> u
New submission from Xavier Morel :
In 3.4 (resp. 3.5), `redirect_stdout` and `redirect_stderr` were added to
provide easy and reentrant stream redirection. Although that is documented, it
seems like a waste that they only redirect the high-level `sys.std*` streams:
those are already pretty
Xavier Morel added the comment:
> In normal circumstances you should never deal with BytesWarning. The -b
> option is only used for testing your program for some possible bugs caused by
> migration from Python 2. If your program always worked only with Python 3,
> the -b optio
New submission from Xavier Morel :
When triggering warnings, it's possible to pass in a `stacklevel` in order to
point to a more informative cause than the `warnings.warn` call.
For instance `stacklevel=2` is a common one for DeprecationWarning in order to
mark the call itself as depre
Xavier Morel added the comment:
Addendum: is there a way to force `-b` from within the running Python program?
--
___
Python tracker
<https://bugs.python.org/issue43
New submission from Xavier Morel :
When setting `BytesWarning` programmatically (via the warnings API), though the
`warnings.filters` value matches what's obtained via `python -b` and an
explicit `warnings.warn` trigger will trigger, "native" triggers of the warning
fail to t
Change by Xavier Morel :
--
title: TOS-behaviour documentation is -> TOS-behaviour documentation is
inconsistent
___
Python tracker
<https://bugs.python.org/issu
New submission from Xavier Morel :
I was looking at the disassembly of a fairly straightforward listcomp:
[e for e in s if e[0]]
1 0 BUILD_LIST 0
2 LOAD_FAST0 (.0)
>>4 FOR_ITER16 (to 22)
Xavier Hausherr added the comment:
Attached PR fix the issue.
--
___
Python tracker
<https://bugs.python.org/issue42892>
___
___
Python-bugs-list mailin
New submission from Xavier Hausherr :
Following this issue: https://bugs.python.org/issue33972
Same bug apply to email.message.get_body() with attached email example and the
following code:
from email.policy import default
import email
with open
Xavier Hausherr added the comment:
The problem still occurs with the _find_body
method. The "part.is_attachment()" method can trigger an AttributeError too
"AttributeError: 'str' object has no attribute 'is_attachment'"
https://github.com/python/cp
Xavier Morel added the comment:
Oh I now see you've created a PR to do essentially that, nm.
--
___
Python tracker
<https://bugs.python.org/issue42644>
___
___
Xavier Morel added the comment:
> I think that patching logging.disable to raise a type error immediately would
> be welcome
FWIW `logging` has a built-in checker / converter[0] which is already used in a
bunch of places (e.g. the aforementioned setLevel), it could just be added
Xavier Morel added the comment:
The problem seems to be in the user code? As you were told by "Carreau",
loggin.disable takes a logging level (an integer), since you're giving it a
string which it dutifully stores, it blows up at the next logging call which
happens to be in
Xavier Morel added the comment:
> What exactly do you do with a path argument?
Because they mention "convert[ing] the string to a path", I would expect an
output of `pathlib.Path`, optionally checked for existence / non-existence and
/ or kind (file, directory, symlink, ...).
Xavier Morel added the comment:
Tried patterning the PR after the one which originally added the warning.
Wasn't too sure how the news item was supposed to be generated, and grepping
the repository didn't reveal any clear script doing that, so I made up a date
and copied an exist
Change by Xavier Morel :
--
pull_requests: +22532
pull_request: https://github.com/python/cpython/pull/23665
___
Python tracker
<https://bugs.python.org/issue42
Xavier Morel added the comment:
I was preparing to open the PR but now I'm doubting: should I open the PR
against master and miss islington will backport it, or should I open the PR
against 3.9?
--
___
Python tracker
<https://bugs.py
Xavier Morel added the comment:
> Do you want to submit a PR for this?
Sure. Do you think the code I proposed would be suitable?
> * The current logic matches the logic before the warning was added.
> * The proposed logic matches what the code will do after the
> deprecatio
New submission from Xavier Morel :
In 3.9, using `random.sample` on sets triggers
DeprecationWarning: Sampling from a set deprecated
since Python 3.9 and will be removed in a subsequent version.
*However* it also triggers on types which implement *both* Sequence and Set,
despite Sequence
Xavier Morel added the comment:
Apparently it's at least a possibility on DDG's side
(https://duckduckgo.com/search_box), don't know how easy it'd be to integrate
in sphinx, or whether a hard dependency on an external search engine is
ac
New submission from Xavier Morel :
I expect it simply uses sphinx and I don't know if sphinx's search is easily
customisable but the experience is really terrible when looking for the doc of
a specific thing, *especially* when that thing is or is related to a builtin,
which I'
Xavier Morel added the comment:
The 3.9 changelog mentions WITH_EXCEPT_FINISH but that seems to have ultimately
been called WITH_EXCEPT_START, maybe it shoudl be updated also?
--
nosy: +xmorel
___
Python tracker
<https://bugs.python.
Xavier Morel added the comment:
Should I close this since I believe 2.7 is not supported anymore?
--
___
Python tracker
<https://bugs.python.org/issue24
Xavier Morel added the comment:
@rhettinger checking software against 3.9 there's a little issue with the way
the check is done: if passed something which is *both* a sequence and a set
(e.g. an ordered set), `random.sample` will trigger a warning, which I don't
think is correct.
Xavier Morel added the comment:
I have not noticed anything, I was just looking at the bytecode changes and
stumbled upon this oddity. Though I would expect a small slowdown as every
fn(**kw) would now incur an extra dict copy, unless there’s something in
call_function_ex which copies the
New submission from Xavier Morel :
Following bpo-39320 the highly specialised bytecode for vararg calls were
replaced by simpler ones, but there seems to be at least one area where the
generated bytecode regressed for possibly no reason?
In Python 3.8, foo(**var) compiles to:
0 LOAD_GLOBAL
New submission from Xavier Morel :
Warning actions allow deduplicating warning triggers based on category
("once"), category + file ("module") and category + exact location ("default").
One thing which is missing is support for a single location generating
Xavier Morel added the comment:
Maybe something along the lines of "names other than arguments and function
locals", or "names of the symbols used in the code object, other than arguments
and function locals"? This is still slightly confusing because in the case of
a
Xavier de Gaye added the comment:
> Perhaps we should should test whether the exception happened there and not
> drop in the debugger in that case?
The same kind of problem occurs for any post-mortem debugging raised by an
uncaught exception in the user code: the backtrace displayed
Xavier de Gaye added the comment:
In Kerrick's example ast.literal_eval('') could be ast.literal_eval(some_code)
instead where some_code is a string containing dynamically generated Python
code. pdb post-mortem debugging must allow finding the syntax error in this
code. The
Change by Xavier Fernandez :
--
pull_requests: +19740
pull_request: https://github.com/python/cpython/pull/20491
___
Python tracker
<https://bugs.python.org/issue38
New submission from Xavier :
Given a .zip file with more than one inner file, when reading those inner files
using zipfile.Path the zip module closes the .zip file prematurely, causing an
error.
Given the following code (example zipfile is attached, but any should work).
with
Xavier de Gaye added the comment:
> Is that epic line automatically generated?
When cross compiling it is generated by the configure script and configure
replaces the right hand side of "PYTHON_FOR_BUILD=@PYTHON_FOR_BUILD@" of
Makefile.pre.in with the generated value into Mak
Xavier de Gaye added the comment:
Steve wrote:
> In my build, I've set PYTHON_FOR_BUILD=python3.8
This will not work, PYTHON_FOR_BUILD when cross-compiling is set by configure
as:
PYTHON_FOR_BUILD='_PYTHON_PROJECT_BASE=$(abs_builddir)
_PYTHON_HOST_PLATFORM=$(_PYTHON_
Change by Xavier Robin :
--
nosy: +Xavier Robin
___
Python tracker
<https://bugs.python.org/issue9>
___
___
Python-bugs-list mailing list
Unsubscribe:
Xavier de Gaye added the comment:
This fixed the bug.
To reproduce the bug, substitute the "from _lzma import *" statement with
"raise ImportError"
in Lib/lzma.py to simulate that the _lzma module is missing and run the test.py
script written an
Xavier de Gaye added the comment:
In msg360620 Serhiy wrote:
> When the interpreter encounters "import foo" in bar.py, the import machinery
> takes the module foo from sys.modules.
> So you break an infinite cycle and can import modules with cyclic
> dependencies.
The
Xavier de Gaye added the comment:
PYTHON_FOR_BUILD does not use PYTHONPATH in the implementation of (closed) PR
17420 and should fix the current issue as a side effect.
FWIW, PR 17420 fixes cross-compilation of third-party extension modules by
replacing the complex PYTHON_FOR_BUILD command
Xavier de Gaye added the comment:
As a workaround insert the following hard-coded breakpoint before the import
statement and run your script with python, i.e. 'python myhome.py' instead of
'python -m pdb myhome.p'.
from pdb import Pdb; Pdb(skip=['importlib*']
Change by Xavier de Gaye :
--
nosy: -xdegaye
___
Python tracker
<https://bugs.python.org/issue31114>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Xavier de Gaye :
--
resolution: -> works for me
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Xavier de Gaye :
--
nosy: -xdegaye
___
Python tracker
<https://bugs.python.org/issue26859>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Xavier de Gaye :
--
nosy: -xdegaye
___
Python tracker
<https://bugs.python.org/issue26971>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Xavier de Gaye :
--
nosy: -xdegaye
___
Python tracker
<https://bugs.python.org/issue22724>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Xavier de Gaye :
--
nosy: -xdegaye
___
Python tracker
<https://bugs.python.org/issue28125>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Xavier de Gaye :
--
nosy: -xdegaye
___
Python tracker
<https://bugs.python.org/issue28207>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Xavier de Gaye :
--
nosy: -xdegaye
___
Python tracker
<https://bugs.python.org/issue28542>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Xavier de Gaye :
--
nosy: -xdegaye
___
Python tracker
<https://bugs.python.org/issue20211>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Xavier de Gaye :
--
nosy: -xdegaye
___
Python tracker
<https://bugs.python.org/issue29267>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Xavier de Gaye :
--
resolution: -> not a bug
stage: needs patch -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Xavier de Gaye :
--
nosy: -xdegaye
___
Python tracker
<https://bugs.python.org/issue32202>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Xavier de Gaye :
--
nosy: -xdegaye
___
Python tracker
<https://bugs.python.org/issue26855>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Xavier de Gaye :
--
nosy: -xdegaye
___
Python tracker
<https://bugs.python.org/issue32203>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Xavier de Gaye :
--
nosy: -xdegaye
___
Python tracker
<https://bugs.python.org/issue13886>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Xavier de Gaye :
--
nosy: -xdegaye
___
Python tracker
<https://bugs.python.org/issue31046>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Xavier de Gaye :
--
nosy: -xdegaye
___
Python tracker
<https://bugs.python.org/issue35953>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Xavier de Gaye :
--
nosy: -xdegaye
___
Python tracker
<https://bugs.python.org/issue26852>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Xavier de Gaye :
--
nosy: -xdegaye
___
Python tracker
<https://bugs.python.org/issue36145>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Xavier de Gaye :
--
nosy: -xdegaye
___
Python tracker
<https://bugs.python.org/issue35997>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Xavier de Gaye :
--
nosy: -xdegaye
___
Python tracker
<https://bugs.python.org/issue36141>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Xavier de Gaye :
--
nosy: -xdegaye
___
Python tracker
<https://bugs.python.org/issue36125>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Xavier de Gaye :
--
nosy: -xdegaye
___
Python tracker
<https://bugs.python.org/issue27640>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Xavier de Gaye :
--
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue36214>
___
___
Pyth
Change by Xavier de Gaye :
--
nosy: -xdegaye
___
Python tracker
<https://bugs.python.org/issue36351>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Xavier de Gaye :
--
nosy: -xdegaye
___
Python tracker
<https://bugs.python.org/issue36361>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Xavier de Gaye :
--
nosy: -xdegaye
___
Python tracker
<https://bugs.python.org/issue28190>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Xavier de Gaye :
--
nosy: -xdegaye
___
Python tracker
<https://bugs.python.org/issue28833>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Xavier de Gaye :
--
nosy: -xdegaye
___
Python tracker
<https://bugs.python.org/issue25172>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Xavier de Gaye :
--
stage: resolved ->
___
Python tracker
<https://bugs.python.org/issue38849>
___
___
Python-bugs-list mailing list
Unsubscrib
Change by Xavier de Gaye :
--
nosy: -xdegaye
___
Python tracker
<https://bugs.python.org/issue38850>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Xavier de Gaye :
--
nosy: -xdegaye
___
Python tracker
<https://bugs.python.org/issue38851>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Xavier de Gaye :
--
nosy: -xdegaye
___
Python tracker
<https://bugs.python.org/issue38840>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Xavier de Gaye :
--
nosy: -xdegaye
___
Python tracker
<https://bugs.python.org/issue38848>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Xavier de Gaye :
--
nosy: -xdegaye
___
Python tracker
<https://bugs.python.org/issue35813>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Xavier de Gaye :
--
nosy: -xdegaye
___
Python tracker
<https://bugs.python.org/issue36758>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Xavier de Gaye :
--
nosy: -xdegaye
___
Python tracker
<https://bugs.python.org/issue36414>
___
___
Python-bugs-list mailing list
Unsubscribe:
Xavier de Gaye added the comment:
Not interested anymore in android stuff.
--
___
Python tracker
<https://bugs.python.org/issue25172>
___
___
Python-bugs-list m
Xavier de Gaye added the comment:
Not interested anymore in android stuff.
--
___
Python tracker
<https://bugs.python.org/issue38850>
___
___
Python-bugs-list m
Xavier de Gaye added the comment:
Not interested anymore in android stuff.
--
stage: needs patch -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/i
Xavier de Gaye added the comment:
Not interested anymore in android stuff.
--
___
Python tracker
<https://bugs.python.org/issue38851>
___
___
Python-bugs-list m
Xavier de Gaye added the comment:
Not interested anymore in android stuff.
--
___
Python tracker
<https://bugs.python.org/issue38848>
___
___
Python-bugs-list m
Xavier de Gaye added the comment:
Not interested anymore in android stuff.
--
___
Python tracker
<https://bugs.python.org/issue38840>
___
___
Python-bugs-list m
Change by Xavier de Gaye :
--
nosy: -xdegaye
___
Python tracker
<https://bugs.python.org/issue38852>
___
___
Python-bugs-list mailing list
Unsubscribe:
Xavier de Gaye added the comment:
get_config_vars() defined in distutils.sysconfig sets 'prefix' and
'exec_prefix' using sys.prefix (resp. sys.exec_prefix) on non nt platforms so
there is no problem. Closing the issue as not a bug.
--
resolution: -> not a
Xavier de Gaye added the comment:
Yes PR GH-17513 does fix the problem.
Thanks Mark.
--
___
Python tracker
<https://bugs.python.org/issue38992>
___
___
Pytho
Change by Xavier de Gaye :
Added file: https://bugs.python.org/file48763/foo.arm64
___
Python tracker
<https://bugs.python.org/issue38992>
___
___
Python-bugs-list mailin
New submission from Xavier de Gaye :
Title: testFsum failure caused by constant folding of a float expression
Description:
Python (Python 3.9.0a1+ heads/master-dirty:ea9835c5d1) is built on a Linux
x86_64. This native interpreter is used to cross-compile Python (using the same
New submission from Xavier de Gaye :
In function finalize_options() of Lib/distutils/command/install.py at
https://github.com/python/cpython/blob/575d0b46d122292ca6e0576a91265d7abf7cbc3d/Lib/distutils/command/install.py#L284
(prefix, exec_prefix) is set using get_config_vars(). This may be
Xavier de Gaye added the comment:
PR 17420 fixes cross-compilation of third-party extension modules.
The PYTHON_PROJECT_BASE environment variable is the path to the directory where
Python has been cross-compiled. It is used by the native python interpreter to
find the target sysconfigdata
1 - 100 of 1614 matches
Mail list logo
