[issue14678] Update zipimport to support importlib.invalidate_caches()
Chris Wilcox added the comment: That is my thinking as well after rooting around a bit. I unfortunately am not knowledgable enough here to be 100% sure it is complete. -- ___ Python tracker <https://bugs.python.org/issue14678> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39601] brace escapes are not working in formatted string literal format specifications
Chris Wilcox added the comment: Thanks Eric. That is very handy. I had made a test case earlier on a branch. Attached as a patch here if helpful. I haven't tried to fix this yet, but would be interested if it is something that makes sense to address. -- keywords: +patch Added file: https://bugs.python.org/file48891/test_case.patch ___ Python tracker <https://bugs.python.org/issue39601> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39601] brace escapes are not working in formatted string literal format specifications
Chris Wilcox added the comment:
Double curly braces do not indicate to not process the inner content. They
indicate to include a literal curly brace. That said, I think there may be
something not quite correct.
I came up with an example based on the example in the format specifiers section
of the PEP.
>From the PEP.
```
>>> width = 10
>>> precision = 4
>>> value = decimal.Decimal('12.34567')
>>> f'result: {value:{width}.{precision}}'
'result: 12.35'
```
The template in this instance is "10.4"
If we leave the sample the same, but don't wrap width or precision in single
curly braces,
```
>>> f'result: {value:width.precision}'
```
I would expect the template "width.precision".
Further, I would expect
```
>>> f'result: {value:{{width}}.{{precision}}}'
```
to have a template of "{width}.{precision}". This is not the case.
Here is some code that should demonstrate this.
```
class Decimal:
def __init__(self, value):
pass
def __format__(self, template):
return template
width = 10
precision = 4
value = Decimal('12.34567')
print("Expect Template to be '10.4' (TRUE)")
print(f'result0: {value:{width}.{precision}}')
print("Expect Template to be 'width.precision' (TRUE)")
print(f'result1: {value:width.precision}')
print("Expect Template to be '{width}.{precision}' (FALSE)")
print(f'result2: {value:{{width}}.{{precision}}}') # ACTUAL: {10}.{4}
```
--
___
Python tracker
<https://bugs.python.org/issue39601>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9305] Don't use east/west of UTC in date/time documentation
Chris Wilcox added the comment: Are you still working on this Ajay Mahato? -- nosy: +crwilcox ___ Python tracker <https://bugs.python.org/issue9305> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14678] Update zipimport to support importlib.invalidate_caches()
Chris Wilcox added the comment: What work remains to be done for this issue? -- nosy: +crwilcox ___ Python tracker <https://bugs.python.org/issue14678> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39601] brace escapes are not working in formatted string literal format specifications
Chris Wilcox added the comment:
The attached code implements `__format__` on the `Collections` class. In case
1, the template passed to `__format__` is "{v.name}: {v.email}|". In case 2, a
name error will occur while processing the f string and v will not be found as
no object 'v' exists in locals or globals.
In reviewing PEP 0498, https://www.python.org/dev/peps/pep-0498/, I think the
difference is in what object is being formatted.
In case 1 of the attached code, the collection is being formatted. In case 2
where f-strings are used, 'v' is being formatted. Because v doesn't exist in
this context, it fails. I found this in the PEP and I think it is what is going
on here.
```
Note that __format__() is not called directly on each value. The actual code
uses the equivalent of type(value).__format__(value, format_spec), or
format(value, format_spec). See the documentation of the builtin format()
function for more details.
```
--
nosy: +crwilcox
___
Python tracker
<https://bugs.python.org/issue39601>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33941] datetime.strptime not able to recognize invalid date formats
Chris Wilcox added the comment:
I looked a bit at _strptime.py and the corresponding tests and thought I would
share my notes.
The regular expressions clearly allow non-zero padded values for both %d and %m
matches. There is one test where the following is run: time.strptime("Mar 1",
"%b %d"). So it seems intentional that %d and %m allow non-zero padded values.
It also just occurred to me that the example '181223' isn't ambiguous as %Y
requires 4 digits and months cannot be more than 12. So it seems to me this
could only be Y=1812,M=2,D=3.
There do exist cases in which they are truly ambiguous for non-zero padded
values. For instance, 2018111 could potentially be 2018-Nov-1 or 2018-Jan-11.
Python will deterministically take the most possible for the next value, so
this will be November 11, 2018. Though, there is really no reason I can figure
that can be assumed.
The edits required to stop allowing non-zero padded values were pretty
straightforward and only one unit test (one that verifies 'Mar 1' comes after
'Feb 29') had to be altered. That may point more to a need to add additional
tests though than an endorsement that no one is using single digit day or month
values.
--
___
Python tracker
<https://bugs.python.org/issue33941>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33941] datetime.strptime not able to recognize invalid date formats
Chris Wilcox added the comment:
As %m and %d denote zero padded forms of month and day it seems to me this
shouldn't match. Executing a small c program `char* ret = strptime("181223",
"%Y%m%d", &tm);` confirms that this is considered invalid to c. The datetime
docs indicate that the behavior should match C89 so I would expect python to
return ValueError here as well.
https://docs.python.org/3/library/datetime.html#strftime-strptime-behavior
--
components: +Library (Lib) -Tests
nosy: +crwilcox
versions: +Python 2.7
___
Python tracker
<https://bugs.python.org/issue33941>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31298] Error when calling numpy.astype
Chris Wilcox added the comment: I may be wrong, but this seems like it could be an issue with NumPy. There are similar issues on their GitHub around crashes on astype. It probably wouldn't hurt to file this over there as well. https://github.com/numpy/numpy/issues -- nosy: +crwilcox ___ Python tracker <http://bugs.python.org/issue31298> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30581] os.cpu_count() returns wrong number of processors on system with > 64 logical processors
Changes by Chris Wilcox : -- pull_requests: +3312 ___ Python tracker <http://bugs.python.org/issue30581> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30581] os.cpu_count() returns wrong number of processors on system with > 64 logical processors
Chris Wilcox added the comment: I was reviewing the docs for the os module and cpu_count should always return the number of cpus on the system, not the usable CPUs. GetMaximumProcessorCount returns a simulated count in WoW64. I have reached back out to the Windows API dev and will see if GetLogicalProcessorInformationEx will allow us to do this. He had thought that my solution that way had other limitations under WoW64. -- ___ Python tracker <http://bugs.python.org/issue30581> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30581] os.cpu_count() returns wrong number of processors on system with > 64 logical processors
Chris Wilcox added the comment: I am going to work on this if no one else has started. -- nosy: +crwilcox ___ Python tracker <http://bugs.python.org/issue30581> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25874] Add notice that XP is not supported on Python 3.5+
New submission from Chris Wilcox: This is a documentation change to make it easier to discover that XP is not a supported OS. Content was taken from the 'whats new' section and added to the top of the main article. -- assignee: docs@python components: Documentation files: add-supported-versions-section-windows.diff keywords: patch messages: 256473 nosy: crwilcox, docs@python priority: normal severity: normal status: open title: Add notice that XP is not supported on Python 3.5+ type: enhancement versions: Python 3.5, Python 3.6 Added file: http://bugs.python.org/file41319/add-supported-versions-section-windows.diff ___ Python tracker <http://bugs.python.org/issue25874> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
