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
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 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 Morel added the comment:
> Fair enough. So we can just add a sentence informing readers that
`meta_path`, by default, holds entries to handle the standard kinds of
modules (.py files, extension modules…).
Yeah that's basically what I meant, talking about a "warning" in
Xavier Morel added the comment:
> A warning is probably too strong. Also, it's easy to check sys.meta_path at
> the interpreter prompt, so I'm not sure it's worth mentioning at all.
It's easy if you think of it and did not miss a small bit of the Python 3.3
releas
Xavier Morel added the comment:
> I'm fine with adding a note to the Python 2 docs, but putting it in Python 3
> seems to be going in the wrong direction as having sys.meta_path not be empty
> is how Python will be going forward.
I don't think putting a note is any hin
Xavier Morel added the comment:
Should I close this since the PR was merged?
--
___
Python tracker
<http://bugs.python.org/issue29920>
___
___
Python-bugs-list m
Xavier Morel added the comment:
And it turns out the change was noted in the Python 3.3 release notes[0] though
not all the consequences were spelled out (and the meta_path and path_hooks
documentations were not changed)
[0] https://docs.python.org/3/whatsnew/3.3.html#visible-changes
Xavier Morel added the comment:
Addendum: the warning was present (in the documentation) until Python 3.5, even
though Python 3.3 is apparently where the "default finders" were moved to
meta_path:
> python3.2 -c 'import sys;print(sys.meta_path)'
[]
> pyth
New submission from Xavier Morel:
Encountered this issue porting Python 2 code manipulating meta_path to Python 3.
In Python 2, meta_path is empty by default and its documentation specifically
notes that:
> sys.meta_path is searched before any implicit default finders or sys.path.
A
Changes by Xavier Morel :
--
pull_requests: -747
___
Python tracker
<http://bugs.python.org/issue29920>
___
___
Python-bugs-list mailing list
Unsubscribe:
Xavier Morel added the comment:
PR targetted to master rather than 2.7
--
pull_requests: +748
___
Python tracker
<http://bugs.python.org/issue29920>
___
___
Pytho
New submission from Xavier Morel:
Currently, cgitb documents the hook (enable) and somewhat unclearly the ability
to dump the HTML traceback to stdout, but despite that being technically
available it does not document the ability to dump the traceback to a string as
either text or html
New submission from Xavier Morel:
It looks to be fixed in 3.3 and up, but in Python 2.7
import ast
m = ast.Module(body=[
ast.Expr(value=ast.Name(id='foo', ctx=ast.Store()))
])
ast.fix_missing_locations(m)
code = compile(m, '', mode='exe
Changes by Xavier Morel :
--
nosy: +xmorel
___
Python tracker
<http://bugs.python.org/issue21590>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Xavier Morel :
--
nosy: +xmorel
___
Python tracker
<http://bugs.python.org/issue14776>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Xavier Morel :
--
nosy: +xmorel
___
Python tracker
<http://bugs.python.org/issue13405>
___
___
Python-bugs-list mailing list
Unsubscribe:
Xavier Morel added the comment:
Correction: csv also seems to raise csv.Error if the file contains NUL bytes:
Error: line contains NULL byte
--
___
Python tracker
<http://bugs.python.org/issue15
New submission from Xavier Morel:
In both Python 2.7 and Python 3.x, csv.Error is documented as:
Raised by any of the functions when an error is detected.
As far as I can tell from using the module and looking at the code, this is
completely incorrect. There is actually a single instance
Xavier Morel added the comment:
completion for list item 4:
> although it would definitely make the "raw text" (in-rst) much harder to read
> compared to the current table (which can be used from the rst source without
> compiling)
--
___
Xavier Morel added the comment:
Had some time to play with this today, here's a draft matrix of actions and
add_argument parameters which is pretty readable, but:
* It's incredibly not helpful for people who don't know argparse
* I tried adding effects descriptions in the c
Xavier Morel added the comment:
> The "Parameters" column would span multiple lines, with one parameter and a
> brief description of the parameter on each line.
I started looking into that, and it turns out that's more annoying than
expected: a bunch of parameters are s
Xavier Morel added the comment:
> My specific suggestion is to have a dedicated "Quick Reference" section
> before the first example.
OK, that looks like a good plan.
--
___
Python tracker
<http://bugs.py
Xavier Morel added the comment:
Creating the tables should not be too hard, especially using e.g. org-mode, but:
1. Where should those tables live? The argparse documentation is pretty big and
there's no completely obvious place. I would guess table 1. could just replace
the li
New submission from Xavier Morel :
In Python 3, "..." became useable as a normal expression, and translates into
an ellipsis instance.
Unicode defines an ellipsis character "…" (U+2026 HORIZONTAL ELLIPSIS) which is
canonically equivalent to a 3-sequence of FULL STOP [U+00
Changes by Xavier Morel :
Added file: http://bugs.python.org/file21854/sphinx-features
___
Python tracker
<http://bugs.python.org/issue11979>
___
___
Python-bugs-list m
New submission from Xavier Morel :
First patch fixes a typo ("the reads a reply" -> "then reads a reply") and — I
believe — improves the wording of a pair of sentences.
Second patch makes use of Sphinx's ``:abbr:`` role, and removes some period
which I think a
Xavier Morel added the comment:
> Only "document and formalize" the parts that are well thought out.
I don't believe I have the knowledge, right or ability to make that call for
any module or package but a pair of extremely obvious ones (http.server seems a
pretty good
Xavier Morel added the comment:
Barry, do I correctly understand your comment to mean I should write end-to-end
tests of the CLI (until reaching the already tested "meat" of smtpd), not just
the CLI options parsing?
--
___
Python trac
Xavier Morel added the comment:
One more note I forgot previously: the conversion of as much scripts as
possible to argparse would be for three reasons:
* Make behavior consistent across the board (e.g. -h/--help)
* Make CLI documentation format consistent across the board either so users
Xavier Morel added the comment:
> any of the undocumented command-line interfaces are intentionally
> undocumented -- they were there for the convenience of the developer for
> exercising the module as it was being developed and are not part of the
> official API.
I can understa
Xavier Morel added the comment:
> Do tests currently exist for smtpd run as a script?
I have to confess I didn't think to check.
> If not, our experience with converting compileall to argparse indicates a
> thorough test suite is needed (and even so we missed some things we had
Xavier Morel added the comment:
Second patch: documenting smtpd-as-a-script in the module's rst
--
Added file: http://bugs.python.org/file20813/smtpd-as-script-doc.diff
___
Python tracker
<http://bugs.python.org/is
New submission from Xavier Morel :
argparse has been merged to the standard library in 3.2, and (tell me if I'm
wrong) would therefore be the "best-practices" way to parse command-line
arguments.
Numerous stdlib modules can be used as scripts, but they tend to have ad-hoc
do
66 matches
Mail list logo
