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
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 t
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
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 p
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
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 getsourc
Pekka Klärck 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 occur with Pytho
Pekka Klärck 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
registering Str
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
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
New submission from Pekka Klärck :
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ä
>>> print(
Pekka Klärck 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 hopin
Pekka Klärck 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
good idea with them to use `
New submission from Pekka Klärck :
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 warning:
N
Change by Pekka Klärck :
--
assignee: -> docs@python
components: +Documentation
nosy: +docs@python
___
Python tracker
<https://bugs.python.org/issu
Pekka Klärck 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 don't know
New submission from Pekka Klärck :
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 encoding. This
is especially
Pekka Klärck 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 submit this as an enhancement r
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)` return
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
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
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:
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:
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:
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`, `__ori
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 ou
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
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
Pekka Klärck 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 not also Scripts
directory
Pekka Klärck 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 it.
Not
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 ntpat
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
Pyt
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.
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#he
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: Instal
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
36 matches
Mail list logo
