New submission from Pekka Klärck :
The docs of inspect.getsourcefile [1] mention the function can raise TypeError,
but there's nothing about the function possibly returning None. This caused a
bug in our project [2].
If I understand the code [3] correctly, None is returned if getsourcefile
Pekka Klärck added the comment:
I'd say `_attributes` is already exposed as defining it in your own node
affects many of the functions in the ast module. For example, `ast.dump(node,
include_attributes=True)` makes no sense otherwise.
Whatever was the reason for the leading underscore must
Pekka Klärck added the comment:
I know attributes starting with an underscore are typically considered private,
but the already mentioned `_fields` clearly isn't and, for example,
`namedtuple` has several methods like `_asdict()` and `_replace()` that are
documented to be part of the public
Pekka Klärck added the comment:
Based on the `ast` source code there are also other functions that use the
undocumented `_attributes` attribute:
- copy_location
- fix_missing_locations
- increment_lineno
--
___
Python tracker
<ht
New submission from Pekka Klärck :
We have implemented an ast for our own tool so that we extend Python's standard
`ast.AST`. When using `ast.dump(node, include_attributes=True)`, we were
surprised to notice that line numbers weren't dumped although the docs of
`ast.dump()` said they should
Pekka Klärck added the comment:
First of all, thanks Raymond for the revival. Secondly, I agree with Josh that
there are better ways to handle my original use case (e.g.
`functools.singledispatch`) but `__subclasses__()` preserving the definition
order could nevertheless be useful in other
Pekka Klärck added the comment:
I encountered this issue because Robot Framework -- a generic Python based test
automation framework -- supports evaluating Python expressions and this issue
was reported for us:
https://github.com/robotframework/robotframework/issues/3207
Pekka Klärck added the comment:
More ways to be bitten by this strange behavior:
>>> d = {'a': 1, 'b': 2}
>>> eval('[x[k] for k in x]', {}, {'x': d})
Traceback (most recent call last):
File "", line 1, in
File "", line 1, in
Pekka Klärck added the comment:
Haven't created a PR yet. Go ahead and great one if you have time Luna! We'd
need a decision about this too, but if the decision is no, then it would
nevertheless be a good idea to mention in the docs that the order is not
guaranteed
Pekka Klärck added the comment:
My use case was implementing conversion of strings to different objects based
on type information got from function arguments. Initially I had a converter
class with methods for each conversion (e.g. `_convert_bool`, `_convert_int`)
but this class got so big
New submission from Pekka Klärck :
I had a use case where `MyClass.__subclasses__()` returning classes in the
definition order would have made the code simpler. They seemed to be returned
in that order, but because the docs didn't say anything about it [1] I did some
searching to find out can
Pekka Klärck added the comment:
You are obviously right with how `__instancecheck__` and `__subclasscheck__`
work. We'd either need something like `__rinstancecheck__` and
`__rsubclasscheck__` or `isinstance` and `issubclass` needed to handle this
using `types.resolve_bases`, `__origin__
Pekka Klärck added the comment:
Just noticed this myself when testing with Python 3.5-3.7:
>>> from decimal import Decimal
>>> d = Decimal('foo')
Traceback (most recent call last):
File "", line 1, in
decimal.InvalidOperation: []
With
Pekka Klärck added the comment:
My concerns with the behavior of `__origin__` possibly changing in the future
seem to valid. In Python 3.5 and 3.6 the behavior is
List.__origin__ is None
List[int].__origin__ is List
while in Python 3.7
List.__origin is list
List[int
Pekka Klärck added the comment:
While studying the types in the typing module more, I noticed they have a
special `__origin__` attribute which seems to contain the "real" type they
represent. I was able to make my type conversion code to work by adding these
lines:
if has
Pekka Klärck added the comment:
Thanks for the PEP-560 reference. It explains the reasoning for the underlying
changes, performance, and also mentions backwards incompatibility problems,
including `issubclass(List[int], List)` causing a TypeError. It doesn't mention
that `issubclass(List
Pekka Klärck added the comment:
Basically I'd like to get answers to these two questions:
1. Are the changes deliberate and covered by the fact that typing is a
provisional module, or could the old functionality be restored?
2. If we cannot get the old functionality back, is there some other
New submission from Pekka Klärck :
= Introduction =
In Python 3.5 and 3.6 types defined in the typing module are instances of
`type` and also subclasses of the "real" type they represent. For example, both
`isinstance(typing.List, type)` and `issubclass(typing.List, list)` re
Pekka Klärck <pekka.kla...@gmail.com> added the comment:
I didn't submit this as a bug report but as an enhancement request. From
usability point of view, saying that results differ but you just cannot see the
difference is not very helpful.
The exact reason I didn't
New submission from Pekka Klärck <pekka.kla...@gmail.com>:
It is possible to use `subprocess.run()` with the system's default encoding by
using `universal_newlines=True`. This is very handy, but it's not at all
obvious (at least for me) that setting such option has effect on en
Pekka Klärck <pekka.kla...@gmail.com> added the comment:
My goal is to read stdout. It's good to hear `subprocess.run()` is
deadlock-safe and I can use it safely. Making the docs explicit about it so
that others know it's safe would in my opinion be a good idea as well.
Casual users
Change by Pekka Klärck <pekka.kla...@gmail.com>:
--
assignee: -> docs@python
components: +Documentation
nosy: +docs@python
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
New submission from Pekka Klärck <pekka.kla...@gmail.com>:
I'm porting old scripts from Python 2.7 to 3.6 and plan to change
`subprocess.call()` to `subprocess.run()` at the same time. When using `call()`
I've used `tempfile.TemporaryFile` as stdout because it's documentation has
this w
Pekka Klärck <pekka.kla...@gmail.com> added the comment:
Thanks for pointing out `ascii()`. Seems to do exactly what I want.
`repr()` showing combining characters would, in my opinion, still be useful to
avoid problems like I demonstrated with unittest and pytest. I doubt it's a
goo
Pekka Klärck <pekka.kla...@gmail.com> added the comment:
Forgot to mention that this doesn't affect Python 2:
>>> a = u'hyv\xe4'
>>> b = u'hyva\u0308'
>>> print(repr(a))
u'hyv\xe4'
>>> print(repr(b))
u'hyva\u0308'
In addition to hoping `repr()` wou
New submission from Pekka Klärck <pekka.kla...@gmail.com>:
If I have two strings that look the same but have different Unicode form, it's
very hard to see where the problem actually is:
>>> a = 'hyv\xe4'
>>> b = 'hyva\u0308'
>>> print(a)
hyvä
>>> prin
New submission from Pekka Klärck:
Documentation of `hex()` on Python 2 says that custom objects need to implement
`__index__` to support it. Based on my tests that doesn't work but `__hex__` is
needed instead. Docs are at
https://docs.python.org/2/library/functions.html?highlight=hex#hex
New submission from Pekka Klärck:
For example:
E:\>py -3.6 -c "import datetime; datetime.datetime.fromtimestamp(42)"
Traceback (most recent call last):
File "", line 1, in
OSError: [Errno 22] Invalid argument
Works fine at least with Python 2.6-2.7 and 3.3-3.5.
Pekka Klärck added the comment:
For me this isn't too high priority. I typically install Python for all users
on Windows anyway, and recommend that also for my clients. I just tested this
RC to see how (ensure)pip works in practice, decided to install only for the
current user, was very happy
New submission from Pekka Klärck:
To reproduce:
1) Download and run Python 2.7.9rc1 Windows installer.
2) Select Install just for me.
3) Enable Add python.exe to Path.
=
Expected: Current user PATH edited.
Actual: System PATH edited.
--
components: Installation
messages: 231734
nosy
New submission from Pekka Klärck:
If you add a directory into PATH on Windows so that the directory is in quotes,
subprocess does not find executables in it. They are found by the operating
system, though, at least when run on the command prompt.
To reproduce:
C:\python --version
Python
Pekka Klärck added the comment:
It seems that joining UNC path to a directory root fails:
Python 2.7.3 (default, Sep 26 2012, 21:51:14)
[GCC 4.7.2] on linux2
Type help, copyright, credits or license for more information.
from ntpath import join
join('c:\\', 'server\\mount\\dir')
'c
Pekka Klärck pekka.kla...@gmail.com added the comment:
I found about this enhancement via Python Insider blog post [1] that also asked
adding comments to this issue. Here are mine:
1) Great to see that this is finally done!
2) Is only Python installation directory added into PATH? Why
Pekka Klärck pekka.kla...@gmail.com added the comment:
Being on by default would just be easier. If it's off, we still need to
separately instruct users to turn it on. That's obviously a lot easier than
instruction them to change environment variables, so I don't feel too strongly
about
Pekka Klärck pekka.kla...@gmail.com added the comment:
The same problem that caused problems to py.test caused problems also to Robot
Framework:
http://code.google.com/p/robotframework/issues/detail?id=1079
I was surprised to notice this issue was closed as invalid although the problem
didn't
Pekka Klärck pekka.kla...@gmail.com added the comment:
@vinay.sajip the problem is that many tools that don't do anything with logging
module intercept sys.stdout and sys.stderr. Such tools typically aren't even
aware of libraries they use (or test) using logging and much less about them
36 matches
Mail list logo
