Matthias Bussonnier added the comment:
Just came across that with wanting to use print_exception and got the same idea.
It seem like in print_exception, and format_exception, etype is already ignored
and `type(value)` is used, so I think we could also "just" also ignore tb
(
Changes by Matthias Bussonnier <bussonniermatth...@gmail.com>:
--
pull_requests: +267
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Matthias Bussonnier <bussonniermatth...@gmail.com>:
--
nosy: +mbussonn
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Matthias Bussonnier added the comment:
should be closed by #28026, it now raises an ImportError. I think this can be
closed. Unless one want to change the text in Starting in Python 3.6 it will be
an error
> Starting in Python 3.6 it will be an error
To use the past tense.
--
n
Changes by Matthias Bussonnier <bussonniermatth...@gmail.com>:
--
pull_requests: +240
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Matthias Bussonnier <bussonniermatth...@gmail.com>:
--
pull_requests: +238
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Matthias Bussonnier <bussonniermatth...@gmail.com>:
--
pull_requests: +239
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Matthias Bussonnier <bussonniermatth...@gmail.com>:
--
nosy: +mbussonn
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Matthias Bussonnier added the comment:
Thanks Nick for finding this !
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28814>
___
__
Changes by Matthias Bussonnier <bussonniermatth...@gmail.com>:
--
pull_requests: +211
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Matthias Bussonnier added the comment:
thank you for your work on the AST, I know many developers are looking forward
to improvement and stabilisation with the hope of having it stable (and
documented) in the stdlib at some point.
The recent change in PR 46 now change (at least
Matthias Bussonnier added the comment:
Duplicating my comment of 29463 who was in a race condition with this issue:
thank you for your work on the AST, I know many developers are looking forward
to improvement and stabilisation with the hope of having it stable (and
documented
Changes by Matthias Bussonnier <bussonniermatth...@gmail.com>:
--
pull_requests: +148, 149, 150
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Matthias Bussonnier <bussonniermatth...@gmail.com>:
--
pull_requests: +148, 149
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Matthias Bussonnier <bussonniermatth...@gmail.com>:
--
pull_requests: +148
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
New submission from Matthias Bussonnier:
Around line 1400 of Doc/howto/clinic.rst
``two-pass``
A buffer like ``buffer``. However, a two-pass buffer can only
be written once, and it prints out all text sent to it during
all of processing, even from Clinic blocks *after* the
I've
Matthias Bussonnier added the comment:
> makes the error message longer
Out of curiosity is there a guide as to what is considered a too long error
message ?
Or is there a technical reason like after a certain length strings are not
cached and exception will be slower to construct ?
Matthias Bussonnier added the comment:
> Wouldn't be better to say just "local variable 'xxx' is not set"?
Thank you for responding that fast and for your interest in this issue.
While I think that "local variable 'xxx' is not set" is technically correct, I
think
New submission from Matthias Bussonnier:
Raymond Hettinger reported during PyCon Canada 2016 Keynote (~20m30 sec)
that unbound local error message was inaccurate, it state that :
> local variable 'xxx' referenced before assignment
Though it can be assigned and deleted.
for a toy exam
New submission from Matthias Bussonnier:
A couple of function in importlib are marked as deprecated in the documentation
but do not raise deprecation warnings.
As the same time it would be great to improve some deprecation warnings and
docstring to include the version since when
Changes by Matthias Bussonnier <bussonniermatth...@gmail.com>:
--
nosy: +mbussonn
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Matthias Bussonnier <bussonniermatth...@gmail.com>:
--
pull_requests: +83
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Matthias Bussonnier <bussonniermatth...@gmail.com>:
--
pull_requests: +84
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Matthias Bussonnier added the comment:
See https://github.com/python/cpython/pull/103 that implements Barry's proposed
format.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Changes by Matthias Bussonnier <bussonniermatth...@gmail.com>:
--
pull_requests: +66
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Matthias Bussonnier added the comment:
I'm unsure I understand changing only the default __str__() method. You will
anyway have to format the message differently depending on whether you raise
from a from-import or a from-import-* or any other locations.
AFAIU you "just" need the
Changes by Matthias Bussonnier <bussonniermatth...@gmail.com>:
--
pull_requests: +62
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Matthias Bussonnier <bussonniermatth...@gmail.com>:
--
pull_requests: +62, 63, 64
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Matthias Bussonnier <bussonniermatth...@gmail.com>:
--
pull_requests: +62, 63
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
New submission from Matthias Bussonnier:
profile .rst say:
> Each restriction is either an integer (to select a count of lines), or a
> decimal fraction between 0.0 and 1.0 inclusive (to select a percentage of
> lines), **or a regular expression**
Actually it accept
Matthias Bussonnier added the comment:
Unsure if GitHub PR autolinks here.
I'm attempting part of that at https://github.com/python/cpython/pull/91
AFAICT with my little knowledge of CPython internal, `name` and `path` where
unset for `from ... import`.
I'll be happy to change
Matthias Bussonnier added the comment:
> IPython3 solved this issue by adding special magic functions, but this is not
> a way for CPython.
IPython 5 improve on that with prompt toolkit. It does not break paste, as
prompt_toolkit has a bracketed-past mode, that most terminal emulator s
Matthias Bussonnier added the comment:
> turn my "we should do this" idea into a change we've actually made :)
Looking forward to being able to do this more on GitHub as I am more familiar
with git.
Good luck for the transition, I'm pretty sure there will be some hard time in
Matthias Bussonnier added the comment:
> OK, I'm marking this as closed, since it's as resolved as we can make it
> through a *CPython* change.
Thanks you Nick, I appreciate the time you took to do that. ANd thank you
Berker for the
Changes by Matthias Bussonnier <bussonniermatth...@gmail.com>:
Added file: http://bugs.python.org/file46565/cannonical-doc-for-2.6.patch
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Matthias Bussonnier <bussonniermatth...@gmail.com>:
Added file: http://bugs.python.org/file46564/cannonical-doc-for-2.7.patch
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Matthias Bussonnier added the comment:
Updated patch to take comments into account (added space before /> for
consistency). I'm still unfamiliar with hg so let me know if I did anything
wrong.
--
Added file: http://bugs.python.org/file46563/cannonical-doc-for-3.4plus.pa
Changes by Matthias Bussonnier <bussonniermatth...@gmail.com>:
Removed file: http://bugs.python.org/file46426/cannonical-doc-for-3.4plus.patch
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Matthias Bussonnier added the comment:
Thanks Nick,
I can work on the similar patch for Python 2.7.
I'll wait for the migration to GitHub which IIRC should be soon.
Side question, is there some metrics (like google analytics) to know how much
traffic there is on older Python docs and if it's
Matthias Bussonnier added the comment:
Here is a patch that add a canonical link to the current documentation that
should apply cleanly to 3.4 and above. I can do similar for older versions.
--
keywords: +patch
Added file: http://bugs.python.org/file46426/cannonical-doc
Matthias Bussonnier added the comment:
Does this have to be implemented on the doc build of EOL pythons versions (like
2.6), or can it be a script which is ran once on these old docs ?
One of the issues I had trying to implement that on other projects was that you
don't know in advance what
New submission from Matthias Bussonnier:
the Tokenize module has the following code:
# An undocumented, backwards compatible, API for all the places in the standard
# library that expect to be able to use tokenize with strings
def generate_tokens(readline):
return _tokenize(readline, None
Matthias Bussonnier added the comment:
> I'm sorry, and thanks to finding it.
No worries, that's what nightly are for right ? And I only dug up a failing
tests :-) Thanks to you for writing this !
> [snip]
> This is difficult for key-sharing dict (aka. split table).
I'm not going t
Matthias Bussonnier added the comment:
Oh, also I've bisect it to the compact-dict commit,
and the exact instance of __dict__.pop that fails depends on the machine.
Reliable same location on travis-ci and locally, but travis-ci location and
local differ on where it triggers
New submission from Matthias Bussonnier:
I've been able to reliably trigger dict.pop to raise a system error:
See https://github.com/pytest-dev/pytest/issues/1925
I have issues getting a small test-case that triggers it, though by changing
the pop method of dict to print the returned value
Matthias Bussonnier added the comment:
> [2 nice response]
Thanks for the nice responses, we all know it can be hard to find the right
balance between making a concise comment, and being delicate enough.
Thanks all for your hard work on CPython, and looking forward to have t
Matthias Bussonnier added the comment:
> We regularly close issues that are 1+ year old on Jupyter/IPython or rescope
> the issue to be actionable for contribution.
Sorry if me doing that on IPython/Jupyter recently have put you (willingc) in a
bad position in here, sincere apologie
Matthias Bussonnier added the comment:
Hi guys, the title of the issues is "show address in the **repR**", but the
NEWS file says[1] in the **repL*, which are 2 different things ! :-)
And this patch change the repR so it also affect scripts and unittests.
[1] since https://hg.
Matthias Bussonnier added the comment:
> @mbussonn - I don't see an updated non-tty-checking patch from you?
Sorry for the delay, trying to get back on this.
Please find attached a new patch that does not check whether is is a tty.
Still struggling a bit with HG (looking fwd to migrat
Changes by Matthias Bussonnier <bussonniermatth...@gmail.com>:
--
nosy: +mbussonn
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
New submission from Matthias Bussonnier:
The current documentation version switcher does not allow to get back to the
`python.org/3/..`
and `python.org/dev/...` url who permanently track the stable/developement
release of Python
the attached patch allows that and should permit in the long
Matthias Bussonnier added the comment:
# unittest
(Pending)DeprecationWarning are already enabled if no -W flags are given.
# doctest
We enable the DW in REPL only if originate from `__main__`, this seem to be
painful to do in doctest, as each doctest execute in a module that have
Matthias Bussonnier added the comment:
ok, thanks. I'll remove the is tty ans push docs changes on a new patch.
I'll see if I can figure out how to enable DW by default in unittest and
doctest.
Thanks !
--
___
Python tracker rep
Matthias Bussonnier added the comment:
Would `pty` even work on CI where the terminal itself might not be a TTY ?
subprocess.Popen(['bash', '-c', '''./python.exe -c import sys;
print(sys.stdin.isatty())'''], stdin=subprocess.PIPE, stderr=subprocess.STDOUT)
False
Otherwise, I can
Matthias Bussonnier added the comment:
Astonishingly isatty appear to work on windows:
http://bugs.python.org/issue18553
Up to core python for istty().
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24294
Matthias Bussonnier added the comment:
Hum, working on the automated test. It is slightly annoying as with subprocess
python is not in a tty, so there will be no change in behavior. I'm not sure
how to proceed.
At a minimum, an interactive test should be written and added
Matthias Bussonnier added the comment:
Thanks for accepting the patch. Looking forward to 3.6 ! :-)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24360
Matthias Bussonnier added the comment:
Note that I've signed the CLA, and it has been taken into account, as now I
have a small star agains my name (if it was the limiting factor, we never know).
--
___
Python tracker rep...@bugs.python.org
http
Matthias Bussonnier added the comment:
Namespace(a=1, 'b=2), Namespace(c'=3)
:-) I read that a `prime-b`=2 and `c-prime`=3.
I just feel like having a repr which is closer to the constructor signature is
better, but I guess it's a question of taste. Anyway, both would be fine
Matthias Bussonnier added the comment:
I gave that a shot.
Doing it cleanly in C as the warning module is initialized much earlier.
Though I'm not super used to CPython internals.
Doing just before the repl by using `PyRun_SimpleString` make the patch
relatively small.
--
keywords
Matthias Bussonnier added the comment:
Sure and anyway if you have a huge namespace, things will become unreadable.
But during development/teaching, having object that have a sane
representation is useful, otherwise your brain (well at least mine), choke on
the output and break the flow of my
New submission from Matthias Bussonnier:
The argparse Namespace can be missleading in case where the args names are not
valid identifiers, eg thinks like a closing bracket:
In [5]: Namespace(a=1, **{')':3})
Out[5]: Namespace()=3, a=1)
more funny:
In [3]: Namespace(a=1, **{s:3})
Out[3
Matthias Bussonnier added the comment:
3.5 have `subprocess.run`[1] that is much saner to use, and what you want to
use in most cases. `call` and `check_call` docs even mention run.
[1]: https://docs.python.org/3.5/library/subprocess.html#subprocess.run
--
nosy: +mbussonn
Matthias Bussonnier added the comment:
Minimal changes to the repr seem to work.
I can submit a proper patch.
class N2(Namespace):
def __repr__(self):
type_name = type(self).__name__
arg_strings = []
unarg={}
for arg in self._get_args
Matthias Bussonnier added the comment:
Maybe the __repr__ of _AttributeHolder should be changed so that invalid args
are shown as unpacked dict in the signature ?
Something that would :
argparse.Namespace(**{'foo bar':1})
argparse.Namespace(**{'foo bar':1})
--
nosy: +mbussonn
Matthias Bussonnier added the comment:
Yes, you did find an error. Thanks for reporting it!
Here is a fix with a test case.
Thanks, I was unsure if there would have been side effect or other things to
fix. I would have submitted a patch otherwise.
Thanks
Matthias Bussonnier added the comment:
Hi,
Since the last few patches related to this, I seem to have an issue with
`Python/importdl.c:get_encoded_name` (I guess) sometime returning the name
with a leading dot. This lead to `PyInit_.modulename` being searched which
fails.
My C-foo
Matthias Bussonnier added the comment:
There is an open issue for that: issue 16544. I've talked to Thomas about
merging greentreesnakes to the AST documentation last year and already have a
WIP patch
Ah, Thanks for the link, I see if I can rotate my chair 120deg clockwise and
give
Matthias Bussonnier added the comment:
Hi Carol,
Matthias, Did you wish to mark this issue for additional Documentation and as
a behavior change request (warning of signature change until 3.6) in addition
to Devguide?
Hum, probably, I'm not super familiar with this bug tracker and it use
New submission from Matthias Bussonnier:
The `ast.Call/_ast.Call` signature, changed on May 5th
(https://hg.python.org/cpython/rev/95886) which causes some error in package
using ast
(https://bitbucket.org/pytest-dev/pytest/issue/744/pytest-assert-rewriting-broken-with-python#).
There does
201 - 270 of 270 matches
Mail list logo
