[issue40838] inspect.getsourcefile documentation doesn't mention it can return None
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 cannot determine the original source file of the file returned by getfile. That's understandable but should definitely be documented. Raising TypeError that getfile itself may raise might be even better, but such a backwards incompatible API change is probably not worth the effort. While looking at the code, I also noticed there's getabsfile [4] that uses getfile if getsourcefile returns None. That looks handy but since the function isn't included in the inspect module documentation [5] using it feels pretty risky. [1] https://docs.python.org/3/library/inspect.html#inspect.getsourcefile [2] https://github.com/robotframework/robotframework/issues/3587 [3] https://github.com/python/cpython/blob/3.8/Lib/inspect.py#L692 [4] https://github.com/python/cpython/blob/3.8/Lib/inspect.py#L714 [5] https://bugs.python.org/issue12317 -- messages: 370547 nosy: pekka.klarck priority: normal severity: normal status: open title: inspect.getsourcefile documentation doesn't mention it can return None ___ Python tracker <https://bugs.python.org/issue40838> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38765] `ast.AST._attributes` is used by `ast.dump()` but not documented
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 be the same reason that added the underscore to `_fields`. That attribute is already documented. -- ___ Python tracker <https://bugs.python.org/issue38765> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38765] `ast.AST._attributes` is used by `ast.dump()` but not documented
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 API. `_attributes` clearly is part of the API as well but it isn't at all documented. -- ___ Python tracker <https://bugs.python.org/issue38765> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38765] `ast.AST._attributes` is used by `ast.dump()` but not documented
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 <https://bugs.python.org/issue38765> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38765] `ast.AST._attributes` is used by `ast.dump()` but not documented
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 be and we had set both `lineno` and `end_lineno` attributes to our nodes. Looking at the implementation of `ast.dump()` revealed that `include_attributes=True` alone wasn't enough, the node also needed to have `_attributes` attribute similarly as it needs to have `_fields` for `ast.dump()` to be able to dump also child nodes. The problem is that `_attributes` isn't documented at all. Related to that, `ast.dump()` using `_fields` isn't documented either, but at least `_fields` is mentioned in the docs otherwise. Relevant links to `ast.dump()` docs and to the source code below. `ast.AST` documents the `_fields` attribute but doesn't mention similar `_attributes`: https://docs.python.org/3/library/ast.html#ast.AST `ast.dump()` documents the `include_attributes` argument but doesn't mention that `_attributes` is needed (or that `_fields` needs to be set correctly to get child notes dumped): https://docs.python.org/3/library/ast.html#ast.dump `ast.dump()` source code shows that the undocumented `_attributes` needs to be set in addition to using `include_attributes=True`: https://github.com/python/cpython/blob/3.8/Lib/ast.py#L123 -- messages: 356362 nosy: pekka.klarck priority: normal severity: normal status: open title: `ast.AST._attributes` is used by `ast.dump()` but not documented ___ Python tracker <https://bugs.python.org/issue38765> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34805] Explicitly specify `MyClass.__subclasses__()` returns classes in definition order
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 cases. The main reason I proposed this issue was to get the behavior documented one way or the other. I'd prefer the current behavior if it doesn't cause any/much extra work nor or later. It's hard for me to see why subclasses weren't stored in a dict in the future, but problem assigning to `__bases__` pointed out by Josh might be worth a though. Not sure is it OK to just consider this kind of side effects OK in such a niche case, should the related code be changed, or is this big enough problem to prevent preserving subclass order in the first place. Anyway, if the decision is to preserve the order, I'd say a test making sure the order is actually preserved would be needed in addition to the doc change. If the decision is to keep the order undefined, then the docs should preferably be updated anyway to make the situation clear. -- ___ Python tracker <https://bugs.python.org/issue34805> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36300] eval of comprehension cannot access local variables
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 -- ___ Python tracker <https://bugs.python.org/issue36300> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36300] eval of comprehension cannot access local variables
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
File "", line 1, in
NameError: name 'x' is not defined
>>>
>>> def f():
... x = {'a': 1, 'b': 2}
... return eval('[x[k] for k in x]')
...
>>> f()
Traceback (most recent call last):
File "", line 1, in
File "", line 3, in f
File "", line 1, in
File "", line 1, in
NameError: name 'x' is not defined
In both of the above cases changing
eval('[x[k] for k in x]')
to
eval('[v for v in x.values()]')
avoids the problem. There are no problems when using
[x[k] for k in x]
without `eval()` either. I'd prefer this to be changed, but there should at
least be a note in the documentation of `eval()` about this.
--
nosy: +pekka.klarck
___
Python tracker
<https://bugs.python.org/issue36300>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34805] Explicitly specify `MyClass.__subclasses__()` returns classes in definition order
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. -- ___ Python tracker <https://bugs.python.org/issue34805> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34805] Explicitly specify `MyClass.__subclasses__()` returns classes in definition order
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 that I decided to split each converter into a separate class (e.g. `BooleanConverter`, `IntegerConverter`) with a common base class. The base class also has a `converter_for` classmethod that is a factory that returns a concrete converter for a certain type. For the factory to be able to return a correct converter, it obviously needs to know what converters exist and what types they handle. My first idea was to simply go through `cls.__subclasses__()` and return the first one that handles the specified type, but because order matters for us this doesn't work. The reason order matters is that we handle both Boolean and integer types, and `bool` being a subclass of `int` means we need to handle the former first. Because I couldn't use `cls.__subclasses__()`, I needed to implement a custom way for the converters to register themselves. That wasn't particularly complicated but some extra work anyway. The code I wrote happens to be open source and visible at [1] if you are interested to look it more closely. The `@TypeConverter.register` stuff could have been avoided is `cls.__subclasses__()` were ordered. It could also be removed once we drop Python 3.5 support *if* order is guaranteed to be preserved going forward. [1] https://github.com/robotframework/robotframework/blob/master/src/robot/running/arguments/typeconverters.py -- ___ Python tracker <https://bugs.python.org/issue34805> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34805] Explicitly specify `MyClass.__subclasses__()` returns classes in definition order
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 I trust the order to stay the same also in the future. Based on my searches it seems that prior to Python 3.5 the information was stored in a list and that preserved the order. In Python 3.5 the information was stored into a dict for performance reasons as part of issue 17936 [2]. Back then dicts weren't ordered, so the order is undefined in Python 3.5, but in Python 3.6+ the order is again preserved. In practice Python 3.5 is the only current version where the order of `__subclasses__()` is not defined. My proposal is to make the current, and old, behavior of returning classes from `__subclassses__()` in definition order explicit. If nobody has anything against that, I'd be willing to provide a pull request updating docs and adding unit tests making sure the order is not messed up in the future. Let me also know if even this kind of simple changes would need to go through python-ideas or python-dev. The PEP process feels overkill when there are no code changes required. PS: I know both Antoine and Guido commented issue 17936 [3] that they don't know any use cases for the order. I can explain my use case if someone is interested. [1] https://docs.python.org/3/library/stdtypes.html?highlight=__subclasses__#class.__subclasses__ [2] https://bugs.python.org/issue17936 [3] https://bugs.python.org/issue17936#msg189959 -- messages: 326420 nosy: pekka.klarck priority: normal severity: normal status: open title: Explicitly specify `MyClass.__subclasses__()` returns classes in definition order ___ Python tracker <https://bugs.python.org/issue34805> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34568] Types in `typing` not anymore instances of `type` or subclasses of "real" types
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__`, or something else. It's unfortunate that `__origin__` cannot be considered to be part of the stable API and that no other suitable API exists. I don't want to add an external dependency only to handle this situation, so I guess I'll just use `__origin__` with Python 3.7+. Hopefully it isn't changed in 3.7 minor versions and hopefully a public API exists in 3.8. -- ___ Python tracker <https://bugs.python.org/issue34568> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26208] decimal C module's exceptions don't match the Python version
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 Python 2.7 I get this error instead:
decimal.InvalidOperation: Invalid literal for Decimal: 'foo'
I'm writing type conversion code and was planning to include the error message
by Python along with some higher level explanation when reporting errors.
`[]` would be such a strange message that I
need to make a special case with decimal.
--
nosy: +pekka.klarck
___
Python tracker
<https://bugs.python.org/issue26208>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34568] Types in `typing` not anymore instances of `type` or subclasses of "real" types
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].__origin__ is list Is it likely that this is going to change again or can I rely on the current behavior with Python 3.7+? -- ___ Python tracker <https://bugs.python.org/issue34568> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34568] Types in `typing` not anymore instances of `type` or subclasses of "real" types
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 hasattr(type_, '__origin__'): type_ = type_.__origin__ All our tests pass with this simple fix, but I'm slightly worried using it because `__origin__` doesn't seem to be documented. This means I'm not sure is my usage OK and, more importantly, makes me worried that another change in typing changes the behavior or removes the attribute altogether. Hopefully someone with more insight on this can comment my worries. Perhaps the attribute should also be documented as discussed earlier: https://github.com/python/typing/issues/335 I'd also be a little bit happier with the above fix if I could write it like if isinstance(type_, typing.SomeBaseType): type_ = type_.__origin__ but apparently types in the typing module don't have any public base class. I guess odds that some unrelated class would have `__origin__` defined is small enough that using `hasattr(type_, '__origin__')` is safe. -- ___ Python tracker <https://bugs.python.org/issue34568> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34568] Types in `typing` not anymore instances of `type` or subclasses of "real" types
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, list)` also raises a TypeError, though, nor that `isinstance(List, type)` now returns False. I understand changing the implementation for performance reason, but I don't understand why that would require changing the behavior of `isinstance` and `issubclass`. The PEP explicitly mentions that the new `types.resolved_base` isn't called by them without explaining why. I guess that could be for performance reasons, but even then types in the typing could themselves implement `__instancecheck__` and `__subclasscheck__` and retain the old behavior. Or is there some actual reason for changing the behavior? -- ___ Python tracker <https://bugs.python.org/issue34568> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34568] Types in `typing` not anymore instances of `type` or subclasses of "real" types
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 way to reliable detect is an annotation a type defined in the typing module? This should cover both the `List` and `List[int]` cases. -- ___ Python tracker <https://bugs.python.org/issue34568> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34568] Types in `typing` not anymore instances of `type` or subclasses of "real" types
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 true. In Python 3.7 the former returns false and the latter causes a TypeError. I could find anything related to these changes in the Python 3.7 release notes or from the documentation of the typing module. I explain my use case and the problems these changes have caused below. = Use case = I'm implementing automatic argument conversion to Robot Framework, a generic open source test automation framework, based on function annotations. The idea is that if a user has defined a keyword like def example(arg: int): # ... we can convert argument passed in plain text test data like Example42 into the correct type automatically. For more details see this issue in our tracker: https://github.com/robotframework/robotframework/issues/2890 = Problem 1 = I have implemented converters for different types and use annotations to find out the expected type for each argument. To exclude non-type annotations, my code uses `isinstance(annotation, type)` but in Python 3.7 this excludes also types defined in the typing module. I could apparently use `isinstance(annoation, (type, typing._GenericAlias))`, but touching private parts like is fragile and feels wrong in general. = Problem 2 = Each converter I've implemented is mapped to a certain type (e.g. `list`) and, when applicable, also to an abc (e.g. `collections.abc.MutableSequence`). When finding a correct converter for a certain type, the code uses an equivalent of `issubclass(type_, (converter.type, converter.abc))`. In Python 3.5 and 3.6 this works also if the used type is defined in the typing module but with Python 3.7 it causes a TypeError. I guess I could handle the types in the typing module by explicitly mapping converters also to these types (e.g. `typing.List`) and then using something like `type_ is converter.typing`. The problem is that although it would work with types like `List`, it wouldn't work if types are used like `List[int]`. -- messages: 324518 nosy: pekka.klarck priority: normal severity: normal status: open title: Types in `typing` not anymore instances of `type` or subclasses of "real" types ___ Python tracker <https://bugs.python.org/issue34568> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33317] `repr()` of string in NFC and NFD forms does not differ
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 submit this as an enhancement request for unittest,
pytest, and all other modules/tools being affected is that "I'm not sure if
there's a good way to detect whether two unicode strings are going to display
confusingly similarly". Enhancing `repr()` would be a logical solution to this
problem.
Finally, would any harm be done if `repr('hyva\u0308')` would be changed to
`'hyva\\u0308'`? I don't see it being any different than `repr('foo\x00')`
being `'foo\\x00'`; in both cases you can `eval()` the result to get the
original value back like `repr()` is supposed to do when possible. Most
importantly, the result would show that the value actually contains like you
generally expect `repr()` to do.
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33317>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33339] Using default encoding with `subprocess.run()` is not obvious
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 encoding. This is especially true when the docs don't explain this explicitly: """If encoding or errors are specified, or universal_newlines is true, file objects for stdin, stdout and stderr are opened in text mode using the specified encoding and errors or the io.TextIOWrapper default.""" This is such a useful feature that it ought to be documented better, preferably with an example. >From code reading point of view, I would also consider `encoding=True` to be >more explicit that `universal_newlines=True`. I can submit a separate issue >about that if others feel the same. -- messages: 315652 nosy: pekka.klarck priority: normal severity: normal status: open title: Using default encoding with `subprocess.run()` is not obvious ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue9> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33319] `subprocess.run` documentation doesn't tell is using `stdout=PIPE` safe
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 don't know `run()` it uses `communicate()`, not `wait()`, internally, or even that this would mean it cannot deadlock. The current situation when the docs say that `call()` shouldn't be used with `stdout=PIPE` and that `call(...)` is equivalent to `run(...).returncode` indicates `stdout=PIPE` is unsafe with `run()` as well. A separate questions is that if `call(...)` is equivalent to `run(...).returncode`, should it also be implemented that way. Based on this discussion it would avoid the problem with `stdout=PIPE` also in that case. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33319> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33319] `subprocess.run` documentation doesn't tell is using `stdout=PIPE` safe
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.python.org/issue33319> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33319] `subprocess.run` documentation doesn't tell is using `stdout=PIPE` safe
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 warning: Note: Do not use stdout=PIPE or stderr=PIPE with this function. The child process will block if it generates enough output to a pipe to fill up the OS pipe buffer as the pipes are not being read from. Interestingly there is no such note in the docs of `run()`, and based on my (possibly inadequate) testing I couldn't get it to hang either. I'm still somewhat worried about using `stdout=PIPE` with it because the docs don't explicitly say it would be safe. I'm especially worried because the docs of `call()` nowadays say that it's equivalent to `run(...).returncode`. If that's the case, then I would expect the warning in `call()` to apply also to `run()`. Or is the warning nowadays outdated altogether? -- messages: 315510 nosy: pekka.klarck priority: normal severity: normal status: open title: `subprocess.run` documentation doesn't tell is using `stdout=PIPE` safe ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33319> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33317] `repr()` of string in NFC and NFD forms does not differ
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 good idea with them to use `ascii()` instead of `repr()` by default because on Python 3 the latter generally works much better with non-ASCII text. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33317> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33317] `repr()` of string in NFC and NFD forms does not differ
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()` would be enhanced in future Python 3 versions,
I'm also looking for a way how to show differences between strings that look
the same but are different. Currently the best I've found is this:
>>> print('hyva\u0308'.encode('unicode_escape').decode('ASCII'))
hyva\u0308
--
versions: +Python 3.4, Python 3.5, Python 3.6
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33317>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33317] `repr()` of string in NFC and NFD forms does not differ
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ä
>>> print(b)
hyvä
>>> a == b
False
>>> print(repr(a))
'hyvä'
>>> print(repr(b))
'hyvä'
This affects, for example, test automation frameworks using `repr()` in error
reporting. For example, both unittest and pytest report
`self.assertEqual('hyv\xe4', 'hyva\u0308')` like this:
AssertionError: 'hyvä' != 'hyvä'
- hyvä
+ hyvä
Because the NFC form is used by strings by default, I would propose that
`repr()` would show the decomposed form if the string is in NFD. In practice
I'd like `repr('hyva\0308')` to yield `'hyva\0308'`.
--
messages: 315504
nosy: pekka.klarck
priority: normal
severity: normal
status: open
title: `repr()` of string in NFC and NFD forms does not differ
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue33317>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29329] Incorrect documentation for custom `hex()` support on Python 2
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 and here's an example session: Python 2.7.6 (default, Oct 26 2016, 20:30:19) [GCC 4.8.4] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class Hex(object): ... def __index__(self): ... return 255 ... >>> hex(Hex()) Traceback (most recent call last): File "", line 1, in TypeError: hex() argument can't be converted to hex >>> >>> class Hex(object): ... def __hex__(self): ... return hex(255) ... >>> hex(Hex()) '0xff' Assuming this is fixed, should probably note that with Python 3 you actually *need* to implement `__index__` and `__hex__` has no effect. -- messages: 285832 nosy: pekka.klarck priority: normal severity: normal status: open title: Incorrect documentation for custom `hex()` support on Python 2 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29329> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29097] datetime.fromtimestamp(t) when 0 <= t <= 86399 fails on Python 3.6
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. Only tested on Windows (missing deadsnakes for easy Linux testing). I was also surprised to get OSError in general, but apparently fromtimestamp uses that instead of ValueError nowadays in some error situations. -- messages: 284199 nosy: pekka.klarck priority: normal severity: normal status: open title: datetime.fromtimestamp(t) when 0 <= t <= 86399 fails on Python 3.6 versions: Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29097> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22953] Windows installer configures system PATH also when installing only for current user
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 to notice that there's an option to set PATH, and then decided to submit an issue when I noticed the system PATH was updated. Because setting PATH is opt-in, and because 2.7 installer apparently requires admin rights and thus always can updated system PATH, I doubt this problem is going to actually matter to anyone. Great to hear 3.5 will have real only for me option. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22953 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22953] Windows installer configures system PATH also when installing only for current user
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: pekka.klarck priority: normal severity: normal status: open title: Windows installer configures system PATH also when installing only for current user versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22953 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17023] Subprocess does not find executable on Windows if it is PATH with quotes
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 2.7.3
C:\type test\script.bat
@echo off
echo hello
C:\set ORIG=%PATH%
C:\set PATH=%ORIG%;test
C:\script.bat
hello
C:\python -c from subprocess import call; call('script.bat')
hello
C:\set PATH=%ORIG%;test
C:\script.bat
hello
C:\python -c from subprocess import call; call('script.bat')
Traceback (most recent call last):
File string, line 1, in module
File C:\Python27\lib\subprocess.py, line 493, in call
return Popen(*popenargs, **kwargs).wait()
File C:\Python27\lib\subprocess.py, line 679, in __init__
errread, errwrite)
File C:\Python27\lib\subprocess.py, line 896, in _execute_child
startupinfo)
WindowsError: [Error 2] The system cannot find the file specified
I don't think you ever need those quotes, even if the directory would have
spaces, but it is very confusing that the behavior is different on the command
prompt and with subprocess. Additionally, Linux does not suffer from this
problem:
$ python --version
Python 2.7.3
$ cat test/script.sh
#!/bin/sh
echo hello
$ PATH=$PATH:test script.sh
hello
$ PATH=$PATH:test python -c from subprocess import call; call('script.sh')
hello
$ PATH=$PATH:test script.sh
hello
$ PATH=$PATH:test python -c from subprocess import call; call('script.sh')
hello
--
messages: 180520
nosy: pekka.klarck
priority: normal
severity: normal
status: open
title: Subprocess does not find executable on Windows if it is PATH with quotes
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17023
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1209447] os.path.join() fails if 2nd arg is a UNC path
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:server\\mount\\dir'
When the first argument contains also something else everything works fine:
join('c:\\dir', 'server\\mount\\dir')
'server\\mount\\dir'
I would say this is a bug. Obviously fixing this changes behavior, but I have
hard time believing that anyone relies on the current buggy output.
On the other hand, I was today reported a bug in my software that was caused by
this. Funny thing was that the bug was in code that was added as a workaround
for issue #3426 (i.e. use `join(os.getcwdu(), path)` instead of `abspath(path)`
when path is Unicode). Luckily adding another workaround for this issue is
pretty easy.
--
nosy: +pekka.klarck
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1209447
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3561] Windows installer should add Python and Scripts directories to the PATH environment variable
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 not also Scripts directory under it as originally requested in this issue? As a developer of a Python based test automation tool, just adding Python into PATH doesn't help us because our tool's launcher scripts still aren't found unless PATH is manually edited. 3) I would also prefer this to be on by default. [1] http://blog.python.org/2012/05/recent-windows-changes-in-python-33.html -- nosy: +pekka.klarck ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3561 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3561] Windows installer should add Python and Scripts directories to the PATH environment variable
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 it. Not adding Scripts into PATH, on the other hand, would make this enhancement pretty useless for us. If it's considered confusing that the installer adds a directory it doesn't create into PATH, perhaps the installer could be changed to also create that directory. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3561 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6333] logging: ValueError: I/O operation on closed file
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 occur with Python 2.7 anymore. After a little more digging I noticed that the proposed fix has actually been done in r84282 as part of fixing issue 9051. The fix doesn't check for `closed` attribute but instead silences possible ValueError. We also noticed a variation of the problem: If the registered handler ever tries to write anything to its stream you also get an exception. We decided to silence all these errors with this code: import logging logging.raiseExceptions = False Finally, I consider it a separate bug that logging.StreamHandler uses sys.stderr by default. It should use sys.__stderr__ instead. -- nosy: +pekka.klarck ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6333 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6333] logging: ValueError: I/O operation on closed file
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 registering StreamHandler using sys.stderr. It's great that nowadays you don't always get ValueError at exit anymore. Now you only get them if the StreamHandler itself tries to use the stream after sys.stderr is restored and the intercepting stream closed. Typically this only happens in error situations so the problem isn't so severe. IMHO nobody should ever register StreamHandler with sys.stderr because you cannot be sure has someone intercepted it or not. There's a strong convention that sys.__stderr__ should not be intercepted so using it is safe. I strongly believe StreamHandler should be changed to use sys.__stderr__ by default. That shouldn't cause problems because a) if sys.stderr isn't intercepted sys.stderr is sys.__stderr__, and b) if sys.stderr is intercepted you most likely already have problems. I know stuff like this cannot be changed other than in major releases and there should perhaps even be a deprecation period. I also acknowledge that it might be too much work to be worth the effort. Mentioning this issue in the docs might be a good idea nevertheless. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6333 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
