[issue37229] bisect: Allow a custom compare function
New submission from G :
All of bisect's functions (insort_{left,right}, bisect_{left,right}) can only
use comparison of objects via __lt__.
They should support providing a custom comparison function.
--
components: Library (Lib)
messages: 345216
nosy: gpery
priority: normal
severity: normal
status: open
title: bisect: Allow a custom compare function
type: behavior
___
Python tracker
<https://bugs.python.org/issue37229>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37229] bisect: Allow a custom compare function
Change by G : -- keywords: +patch pull_requests: +13837 stage: -> patch review pull_request: https://github.com/python/cpython/pull/13970 ___ Python tracker <https://bugs.python.org/issue37229> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4356] Add "key" argument to "bisect" module functions
G added the comment: I opened a relevant PR, https://github.com/python/cpython/pull/11781. I believe a key parameter is inferior to a comparison callback. The former is a specific case of the latter, and in my use case would force me to create another class to serve as a comparator for my objects, at which point I might as well wrap them and add __lt__. Furthermore, I believe this is more in-line with similar standard functions in other languages such as C++ (std::sort), Java (PriorityQueue) or Rust (slice.sort_by). -- nosy: +gpery ___ Python tracker <https://bugs.python.org/issue4356> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4356] Add "key" argument to "bisect" module functions
G added the comment: I did, thanks! -- ___ Python tracker <https://bugs.python.org/issue4356> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37229] bisect: Allow a custom compare function
G added the comment: What do you propose to do for objects outside your project? Replace their __lt__ method with a context manager which replaces the original implementation, for lists at a time? __lt__ is not good enough as a one-way-to-do-it solution. issue4356 is also a good-enough solution for me, but __lt__ definitely isn't. -- resolution: rejected -> status: closed -> open ___ Python tracker <https://bugs.python.org/issue37229> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34353] stat's python implementation of filemode (fallback) doesn't behave like the C implementation
New submission from G : stat.py (Lib/stat.py)'s implementation of filemode doesn't account for socket-type files, while _stat (Modules/_stat.c) does, using S_IFSOCK. -- components: Library (Lib) messages: 323248 nosy: gpery priority: normal severity: normal status: open title: stat's python implementation of filemode (fallback) doesn't behave like the C implementation type: behavior versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue34353> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34353] stat's python implementation of filemode (fallback) doesn't behave like the C implementation
Change by G : -- keywords: +patch pull_requests: +8193 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue34353> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25575] idle not working
New submission from G: I'm teaching Python in a computer lab with 28, new this Sept., Mac Minis. One of the machines will run from the command line in Terminal but will not run using IDLE. I'm using the turtle module for graphics. I've attached a screen snap of the code and error message. The top part of the image shows error message using IDLE. The bottom part of the image shows the same code runs from the command line. I just updated the OS to OSX 11.11.1 and it still did not fix the issue. Any ideas on how to fix it? -- components: IDLE files: Python idle problem.png messages: 254242 nosy: ccgm priority: normal severity: normal status: open title: idle not working type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file40967/Python idle problem.png ___ Python tracker <http://bugs.python.org/issue25575> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25575] idle not working
G added the comment: Hi, Thanks for getting back to me,. I will try this first thing Monday when I'm back at work. George > On Nov 6, 2015, at 8:29 PM, Zachary Ware wrote: > > > Zachary Ware added the comment: > > Check the traceback carefully, it shows exactly where the problem is, though > it's not immediately obvious until it's bitten you a time or two. You are > running /Users/a5/Desktop/z.py which imports turtle, but you have a turtle.py > in /Users/a5/Desktop which is found before the standard library turtle. Your > command line test works because it is run from a different directory. Just > remove or rename /Users/a5/Desktop/turtle.py and it will work. > > There have been other reports about this lately, and there are on-going > discussions about what can be done to try to prevent this situation. > > -- > nosy: +zach.ware > resolution: -> not a bug > stage: -> resolved > status: open -> closed > > ___ > Python tracker > <http://bugs.python.org/issue25575> > ___ -- ___ Python tracker <http://bugs.python.org/issue25575> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25897] Python 3.5.1 and Active Tcl/Tk 8.6.4.1
New submission from G: I have installed one copy of Python 3.5.1 and Tcl/Tk 8.6.4.1 in a high school lab with 28 more computers. Want to be sure I'm doing it correctly. Before the update we were running Python 2.7.10 and always got a warning: Tcl/Tk (8.5.9) may be unstable. I'm still getting the same warning after installing Tcl/Tk 8.6.4.1 . What to I need to do so 3.5.1 sees the correct Tcl/Tk file? What does unstable in this context mean? We had no issues I was aware of. -- files: python update 1.png messages: 256616 nosy: ccgm priority: normal severity: normal status: open title: Python 3.5.1 and Active Tcl/Tk 8.6.4.1 type: behavior versions: Python 3.5 Added file: http://bugs.python.org/file41340/python update 1.png ___ Python tracker <http://bugs.python.org/issue25897> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25897] Python 3.5.1 and Active Tcl/Tk 8.6.4.1
G added the comment: Thank you very much Sent from George Moreno's iPhone > On Dec 17, 2015, at 14:48, SilentGhost wrote: > > > Changes by SilentGhost : > > > -- > components: +IDLE, Macintosh, Tkinter > nosy: +gpolo, ned.deily, ronaldoussoren, serhiy.storchaka > > ___ > Python tracker > <http://bugs.python.org/issue25897> > ___ -- ___ Python tracker <http://bugs.python.org/issue25897> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25897] Python 3.5.1 and Active Tcl/Tk 8.6.4.1
G added the comment: Thank you very much. Sent from George Moreno's iPhone > On Dec 17, 2015, at 15:12, Ned Deily wrote: > > > Ned Deily added the comment: > > Please read the information at the web page linked to in that message you > have been seeing: https://www.python.org/download/mac/tcltk/. As explained > there, the current Pythons downloaded from python.org for OS X dynamically > link with Tcl/Tk 8.5.x, not 8.6.x. You should download and install the > latest ActiveTcl 8.5 version for OS X which is currently 8.5.18.0 from > http://www.activestate.com/activetcl/downloads. You don't need to uninstall > the 8.6.5.1 version that you've already installed; it will be ignored. > > -- > resolution: -> not a bug > stage: -> resolved > status: open -> closed > > ___ > Python tracker > <http://bugs.python.org/issue25897> > ___ -- ___ Python tracker <http://bugs.python.org/issue25897> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46089] Problems with AF_PACKET sockets
New submission from G. Allard :
For educational purposes, I'm developing my own IP stack in Python. It's going
well but I'm stuck at a low level.
I need to implement the following (simple) task:
- open an AF_PACKET socket (socket.socket)
- bind it to a specific interface (socket.bind)
Python code would look like this:
- sock = socket.socket( socket.AF_PACKET, socket.SOCK_RAW, socket.htons(
ETH_P_ALL))
- sock.setblocking( False)
- sock.bind(( 'eth0', socket.htons( ETH_P_ALL)))
It does not work. bind always return "TypeError: AF_PACKET address must be a
tuple of two to five elements"
I spent many days on that problem. No success.
Desperate, I tried to verify it wasn't a kernel problem. I wrote the C version
of the above snippet.
- sock = socket( AF_PACKET, SOCK_RAW | SOCK_NONBLOCK, htons( 3));
- struct sockaddr_ll addr = {0};
addr.sll_family = AF_PACKET;
addr.sll_ifindex = 2; /* index of 'eth0' */
addr.sll_protocol = htons( ETH_P_ALL);
- bind( sock, (struct sockaddr*) &addr, sizeof( addr));
I'm not an expert in C programming but it worked on first try.
First problem is that AF_PACKET sockets are broken in Python.
Second problem is inadequate documentation.
Following issue ID 25041, some documentation has been added but there is still
lot of room for improvements.
For example:
- recvfrom return 2 values. The first is the binary packet and the second one
is a 5 member structure. The first member of the structure is the interface
name. The 5th member if the MAC address (assuming the interface is an Ethernet
NIC). The 3rd one is a protocol number (the data-link protocol) whose data is
in front of the returnet packet (for WiFi packets, we will see Radiotap
protocol at that level).
That's a whole new world for documentors.
- socket.bind() parameter is documented to be an address. For AF_PACKET, the
address is documented in "Socket Families" section. Definition is vague. The
'proto' description would be easier to understand with "An integer (in
network-byte-order) representing the low level protocol (enumerated in
linux/if_ether.h) or ETH_P_ALL for all protocols. This parameter is only used
for filtering inbound packets."
IMO 'pkttype', 'hatype', 'addr' are there to document the information returned
by recvfrom(). It's written they are "optional" but I think it's not correct.
- Working examples of AF_PACKET must be provided, possibly in a HOWTO.
When it's easier to program in C, it should tell you there is a problem on
Python side.
--
assignee: docs@python
components: Documentation
messages: 408638
nosy: docs@python, gallard
priority: normal
severity: normal
status: open
title: Problems with AF_PACKET sockets
type: enhancement
versions: Python 3.8
___
Python tracker
<https://bugs.python.org/issue46089>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46089] Problems with AF_PACKET sockets
G. Allard added the comment: Next 3 steps must be (in decreasing priorities): - fix the code - write a mini-howto. It will be used for test purposes - write documentation (a Howto/tutorial) For the 3rd step, I would accept to join a team. -- ___ Python tracker <https://bugs.python.org/issue46089> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35228] Index search in CHM help crashes viewer
Charles G. added the comment: My previous Windows version (Win 10 1803) does not have this crashing problem. It only crashed after upgrading to 21H1. So I replaced hhctrl.ocx in system32 (Win 10 21H1) with hhctrl.ocx from Windows.old. 2019/03/19 11:45 696.320 hhctrl.ocx 2021/09/23 03:29 729.600 hhctrl.ocx.old -- nosy: +Charles G. ___ Python tracker <https://bugs.python.org/issue35228> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44152] .isupper() does not support Polytonic Greek (but .islower() does)
New submission from E G : Δημοϲθενικοί starts with an upper-case delta. 'Δημοϲθενικοί'.isupper() should yield "True". Ἀεὶ also fails this test: it begins with a capital Alpha with a breathing. εἰϲ is properly parsed: isupper() is False and islower() is True. Despite the problem with .isupper(), .capitalize() does seem to work properly: 'ὦ' --> 'Ὦ' and 'ἂν' --> 'Ἂν' a transcript follows Python 3.9.5 (default, May 4 2021, 03:36:27) Greek vs .isupper(): seems like .islower() is properly implemented but that .isupper() is not >>> 'ζῳώδηϲ'.islower() True >>> 'Δημοϲθενικοί'.islower() False >>> 'Δημοϲθενικοί'.isupper() False >>> x = 'Ἀεὶ' >>> x.islower() False >>> x.isupper() False >>> x = 'εἰϲ' >>> x.isupper() False >>> x.islower() True >>> x = 'ἂν' >>> x.islower() True >>> x.isupper() False >>> x= 'ὦ' >>> x.isupper() False >>> x.islower() True >>> x.capitalize() 'Ὦ' >>> 'ἂν'.capitalize() 'Ἂν' -- messages: 393759 nosy: egun priority: normal severity: normal status: open title: .isupper() does not support Polytonic Greek (but .islower() does) type: behavior versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue44152> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44152] [not a bug] .isupper() does not support Polytonic Greek (but .islower() does)
E G added the comment: Oops: this is not a bug. The isupper() method tests ALL chars. Only the first char in the examples was a capital. All of the logic/tests succeed. Sorry for the error. Thanks to Serhiy S. for swift attention on this. -- resolution: -> not a bug title: .isupper() does not support Polytonic Greek (but .islower() does) -> [not a bug] .isupper() does not support Polytonic Greek (but .islower() does) ___ Python tracker <https://bugs.python.org/issue44152> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44711] Optimize type check in pipes.py
New submission from Anton G. :
When I did some work on typeshed I found some weird syntax in pipes.py.
if type(cmd) is not type(''):
which can easily be changed to
if not isinstance(cmd, str):
There are two occurrences and I will directly create the PR :)
--
components: Library (Lib)
messages: 397995
nosy: anton.gruebel
priority: normal
severity: normal
status: open
title: Optimize type check in pipes.py
type: performance
___
Python tracker
<https://bugs.python.org/issue44711>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45555] Object stays alive for weak reference if an exception happens in constructor
New submission from Matias G : Hi Python developers, I stumbled on a weird behavior, which might be a bug actually. I am surprised by the output of the following piece of code: ``` import weakref refs = [] class A: def __init__(self): refs.append(weakref.ref(self)) #raise RuntimeError() <<< enable this line of code and be surprised! try: A() finally: print(refs[0]()) ``` The code prints None ; but, if the RuntimeError exception is raised in the constructor, we find the object in the final print. It is not dereferenced properly, as it seems: ``` <__main__.A object at 0x7f4b6cf23ed0> Traceback (most recent call last): File "/tmp/test.py", line 11, in A() File "/tmp/test.py", line 8, in __init__ raise RuntimeError() RuntimeError ``` I tried adding `gc.collect()` with no luck. Am I doing something wrong ? Thanks in advance -- components: Interpreter Core messages: 404606 nosy: guijarro priority: normal severity: normal status: open title: Object stays alive for weak reference if an exception happens in constructor type: behavior versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue4> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45555] Object stays alive for weak reference if an exception happens in constructor
Matias G added the comment: About the reference in exception: I thought that Python 3 didn't have the need for `sys.exc_clear()` (which has been removed), specifically for this kind of problem. The code I use is in fact more complex than the small snippet I posted here to reproduce the (presumed) bug ; what I see, is that the reference is **never** removed. The weakref cannot die. My program is a REPL, I want exceptions to bubble up to users, so catching it before it reaches the user layer is not so great. -- ___ Python tracker <https://bugs.python.org/issue4> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42615] Redundant jump instructions due to deleted unreachable bytecode blocks
New submission from Om G : During optimization, the compiler deletes blocks that are marked as unreachable. In doing so, it can render jump instructions that used to jump over the now-deleted blocks redundant, since simply falling through to the next non-empty block is now equivalent. An example of a place where this occurs is around "if condition: statement; else: break" style structures (see attached proof of concept code below), but this is a general case and could occur in other places. Tested on the latest 3.10 branch including all recent compile.c changes. -- files: jmptest.py messages: 382834 nosy: OmG priority: normal severity: normal status: open title: Redundant jump instructions due to deleted unreachable bytecode blocks type: performance versions: Python 3.10 Added file: https://bugs.python.org/file49664/jmptest.py ___ Python tracker <https://bugs.python.org/issue42615> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42615] Redundant jump instructions due to deleted unreachable bytecode blocks
Change by Om G : -- keywords: +patch pull_requests: +22591 stage: -> patch review pull_request: https://github.com/python/cpython/pull/23733 ___ Python tracker <https://bugs.python.org/issue42615> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42615] Redundant jump instructions due to deleted unreachable bytecode blocks
Change by Om G : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue42615> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41647] MutableMapping ".setdefault()" to return default value via __getitem__
New submission from Matias G : Hi, This is more a question/proposal than a real issue. I apologize in advance if this has already been debated or if it is not relevant. I noticed `setdefault` method of mutable mapping objects is returning the default value as passed in the call, when applicable, without passing through `__getitem__`. I think it would be more "symmetric" if it would return the default value set by `__setitem__` via `__getitem__`. This would handle the case of a custom MutableMapping defining a custom behaviour of `__setitem__` and `__getitem__`. Of course, in my case finally I overloaded `setdefault` to do this, but it might be worth in general, at least for the MutableMapping class. Thanks, Matias. -- messages: 375984 nosy: guijarro priority: normal severity: normal status: open title: MutableMapping ".setdefault()" to return default value via __getitem__ type: enhancement versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue41647> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41753] subprocess.run on windows does not convert path to string
New submission from Kaushik G : a call of the form `subprocess.run([x, y, z])` where one of the elements is a `pathlib.Pat`h fails on windows because the path is not converted to a string as it should. This works fine (as expected) on macOS and Linux. A typical error message is: `TypeError: argument of type 'WindowsPath' is not iterable` -- components: Windows messages: 376651 nosy: kaushik.ghose, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: subprocess.run on windows does not convert path to string type: behavior versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue41753> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41753] subprocess.run on windows does not convert path to string
Kaushik G added the comment: Thank you for your response. There are two concerns I have here. 1. Python's promise of being straightforward. In MOST cases pathlib.Path objects do the right thing, casting to a string such that pathlib.Path is a drop in replacement. This exception is unexpected. 2. Cross platform consistency. Looks like this works on macOS and Linux. Why should it fail on Windows? Thanks! -- ___ Python tracker <https://bugs.python.org/issue41753> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4356] Add "key" argument to "bisect" module functions
Kevin G added the comment: Can anyone add "reverse" support? Key and reverse support are both functional requirement. -- nosy: +flyingosprey ___ Python tracker <https://bugs.python.org/issue4356> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37344] plistlib doesn't skip whitespace in XML format detection
New submission from Shane G : plistlib in Python 3.7.3 (and earlier) does not autodetect plist data as XML if it contains whitespace before the "https://github.com/python/cpython/blob/3.7/Lib/plistlib.py#L493 -- messages: 346089 nosy: shaneg priority: normal severity: normal status: open title: plistlib doesn't skip whitespace in XML format detection type: behavior versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue37344> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37344] plistlib doesn't skip whitespace in XML format detection
Shane G added the comment: This issue was created because I ran across a plist like this when parsing entitlements in an IPA. I assume that this happened by some unusual step in the toolchain when building the application. To some other points: * agreed lstrip()ing just the key would not work (unfortunately I suggested this before actually coding up a workaround for my case). * agreed that binary plists should not have any stripping. * I have not tried testing apple tools (e.g. plutil) against XML plists with BOMs before any leading whitespace. -- ___ Python tracker <https://bugs.python.org/issue37344> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37806] Infinite recursion with typing.get_type_hints
New submission from Valerio G : I encountered one condition where calling get_type_hints causes infinite recursion when dealing with forward declaration and cyclic types. Here's an example: from typing import Union, List, get_type_hints ValueList = List['Value'] Value = Union[str, ValueList] class A: a: List[Value] get_type_hints(A, globals(), locals()) This reaches the recursion limit as of 3.8.0b2. It seems that the combining _GenericAlias with ForwardRef is what triggers this condition: ForwardRef._evaluate sets __forward_value__ on its first call on a given instance _GenericAlias tries to compare its args post evaluation If one of the arguments is a previously evaluated forward reference containing a cycle, then it will infinitely recurse in the hash function when building a frozen set for the comparison. The above is, of course, a very artificial example, but I can imagine this happening a lot in code with trees or similar structures. My initial reproduction case was using _eval_type to resolve forward references returned by get_args (side note: it would be nice to have a public function to do that). -- components: Library (Lib) messages: 349330 nosy: vg0377467 priority: normal severity: normal status: open title: Infinite recursion with typing.get_type_hints versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue37806> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37806] Infinite recursion with typing.get_type_hints
Change by Valerio G : -- type: -> crash ___ Python tracker <https://bugs.python.org/issue37806> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31222] datetime.py implementation of .replace inconsistent with C implementation
New submission from Paul G: In the .py implementation of datetime.replace (and date.replace and time.replace), the new datetime is created using the datetime type: https://github.com/python/cpython/blob/master/Lib/datetime.py#L1578 But in the C source, it is created from type(self): https://github.com/python/cpython/blob/master/Modules/_datetimemodule.c#L5046 I think the second should be the preferred behavior, so the datetime.py source should be updated to reflect that it's calling self.__class__(...) rather than datetime(...). I can prepare a PR if this would be desirable. (That said, I'm not 100% clear under what circumstances the code in datetime.py is actually *used*, so I'm not sure how to write tests for it - is datetime.py essentially documentation, or is there a way to explicitly fall back to it?) Per this issue on the pypy3 tracker: https://bitbucket.org/pypy/pypy/issues/2635/datetimereplace-always-returns -- components: Interpreter Core messages: 300377 nosy: p-ganssle priority: normal severity: normal status: open title: datetime.py implementation of .replace inconsistent with C implementation versions: Python 3.5, Python 3.6, Python 3.7 ___ Python tracker <http://bugs.python.org/issue31222> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31222] datetime.py implementation of .replace inconsistent with C implementation
Paul G added the comment: @r.david.murray In the other thread, you mention that the full test suite is run against the C and Python implementations, so that answers the question of how to write the tests. I think treating it as an enhancement in Python 3.7 makes a reasonable amount of sense - it's clearly under-specified at the moment and people are probably relying on the CPython behavior (dateutil definitely is in the latest stable release, but not on master). Saying "it's implementation-specific before Python 3.7 but in Python 3.7+, the spec says it should use self(type)" is fine by me. It's not particularly hard to work around if you're subclassing datetime anyway. Among the major libraries that provide their own datetime objects: - Arrow seems to use composition (https://github.com/crsmithdev/arrow/blob/master/arrow/arrow.py) - pendulum subclasses, but implements their own "replace": https://github.com/sdispater/pendulum/blob/master/pendulum/pendulum.py#L25 - delorean uses composition: https://github.com/myusuf3/delorean/blob/master/delorean/dates.py#L174 - maya uses composition: https://github.com/kennethreitz/maya/blob/master/maya/core.py#L72 I'd say for the most part it's not a major issue to change it even as a bugfix, particularly if the line we're going with is "it was always implementation-specific", but there's also no rush. -- ___ Python tracker <http://bugs.python.org/issue31222> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31956] Add start and stop parameters to the array.index()
Ryan G. added the comment: This functionality is useful to me. Is this issue still alive? If not, how can I help? -- nosy: +Ryan G. ___ Python tracker <https://bugs.python.org/issue31956> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30010] Initial bytes to BytesIO cannot be seeked to
New submission from Samuli G: The initial bytes provided for the BytesIO constructor are lost when the stream is written to. Seeking to offset zero, and then getting the value of the entire buffer results of getting only the bytes that have been appended by calling "write". -- components: IO files: bytesio_bug.py messages: 291254 nosy: Samuli G priority: normal severity: normal status: open title: Initial bytes to BytesIO cannot be seeked to type: behavior versions: Python 3.6 Added file: http://bugs.python.org/file46784/bytesio_bug.py ___ Python tracker <http://bugs.python.org/issue30010> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30361] Docs example: converting mixed types to floating point
Changes by G Young : -- pull_requests: +1797 ___ Python tracker <http://bugs.python.org/issue30361> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29596] Unfinished sentense in howto/clinic.rst
Changes by G Young : -- pull_requests: +1801 ___ Python tracker <http://bugs.python.org/issue29596> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29510] gitignore settings files for Eclipse IDE
Changes by G Young : -- pull_requests: +1873 ___ Python tracker <http://bugs.python.org/issue29510> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29596] Unfinished sentence in howto/clinic.rst
Changes by G Young : -- pull_requests: +2041 ___ Python tracker <http://bugs.python.org/issue29596> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29596] Unfinished sentence in howto/clinic.rst
Changes by G Young : -- pull_requests: +2042 ___ Python tracker <http://bugs.python.org/issue29596> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35100] urllib.parse.unquote_to_bytes: needs "escape plus" option
Change by andrew-g : -- keywords: +patch pull_requests: +12331 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue35100> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35100] urllib.parse.unquote_to_bytes: needs "escape plus" option
andrew-g added the comment: pinging the issue to try get the PR reviewed -- nosy: +andrew-g ___ Python tracker <https://bugs.python.org/issue35100> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36706] Python script on startup stucks at import
New submission from serge g : I am not sure if it is python's issue (correct me if this is wrong place for report). But sometimes (probably every 3-4 attempt) when I run script, interpreter just stucks for some time (0.5-3 minutes) and then actually runs the script normally. To figure out what happens I increased verbosity (python -vv) and actually python hangs on import on this line: ... # trying /home/2kg/spider/venv/lib/python3.7/site-packages/cryptography/hazmat/primitives/kdf/scrypt.abi3.so # trying /home/2kg/spider/venv/lib/python3.7/site-packages/cryptography/hazmat/primitives/kdf/scrypt.so # trying /home/2kg/spider/venv/lib/python3.7/site-packages/cryptography/hazmat/primitives/kdf/scrypt.py # /home/2kg/spider/venv/lib/python3.7/site-packages/cryptography/hazmat/primitives/kdf/__pycache__/scrypt.cpython-37.pyc matches /home/2kg/spider/venv/lib/python3.7/site-packages/cryptography/hazmat/primitives/kdf/scrypt.py # code object from '/home/2kg/spider/venv/lib/python3.7/site-packages/cryptography/hazmat/primitives/kdf/__pycache__/scrypt.cpython-37.(pyc' (here >>>>>) import 'cryptography.hazmat.primitives.kdf.scrypt' # <_frozen_importlib_external.SourceFileLoader object at 0x7f5c6e3c73c8> import 'cryptography.hazmat.backends.openssl.backend' # <_frozen_importlib_external.SourceFileLoader object at 0x7f5c6c129c88> import 'cryptography.hazmat.backends.openssl' # <_frozen_importlib_external.SourceFileLoader object at 0x7f5c6d30d240> # trying /home/2kg/spider/venv/lib/python3.7/site-packages/cryptography/x509/UnsupportedExtension.cpython-37m-x86_64-linux-gnu.so # trying /home/2kg/spider/venv/lib/python3.7/site-packages/cryptography/x509/UnsupportedExtension.abi3.so # trying /home/2kg/spider/venv/lib/python3.7/site-packages/cryptography/x509/UnsupportedExtension.so # trying /home/2kg/spider/venv/lib/python3.7/site-packages/cryptography/x509/UnsupportedExtension.py # trying /home/2kg/spider/venv/lib/python3.7/site-packages/cryptography/x509/UnsupportedExtension.pyc ... I had version 3.5 installed before and didn't notice such issue. Other scripts from my project suffer from this symptom as well. My configuration is: debian 9 python 3.7.3 [GCC 6.3.0 20170516] on linux cryptography module – version 2.6.1 -- components: Library (Lib) messages: 340722 nosy: serge g priority: normal severity: normal status: open title: Python script on startup stucks at import type: performance versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue36706> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29406] asyncio SSL contexts leak sockets after calling close with certain Apache servers
Change by Angie G : -- components: +Build, SSL type: resource usage -> performance ___ Python tracker <https://bugs.python.org/issue29406> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31729] multiprocesssing.Pool.map_async() undocumented
New submission from g...@nlc.co.nz : To monitor how much of my multiprocess.Pool is completed I am forced to use undocumented features which I fear mat changed in the future. Especially result._number_left which looks like a private variable. Can you please document the result from Pool.map_async() and make the _number_left a proper method, e.g result.number_completed() result = pool.map_async(process_employee, gen_emps, chunksize=1) while not result.ready(): left = result._number_left It is not possible to pass Pipes, Queues or Shared memory to Pool workers in order for them to signal back to the master when them have completed a job. -- components: Library (Lib) messages: 303918 nosy: g...@nlc.co.nz priority: normal severity: normal status: open title: multiprocesssing.Pool.map_async() undocumented type: enhancement versions: Python 2.7 ___ Python tracker <https://bugs.python.org/issue31729> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31730] list unhashable, can not be use as key to dict
New submission from g...@nlc.co.nz : A list can no be used as the key to a dict, apparently because it is "unhashable": TypeError: unhashable type: 'list'. The code must exist to hash object like this a tuple is hashable and can be constructed from a list. -- components: Interpreter Core messages: 303919 nosy: g...@nlc.co.nz priority: normal severity: normal status: open title: list unhashable, can not be use as key to dict type: enhancement versions: Python 2.7 ___ Python tracker <https://bugs.python.org/issue31730> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31729] multiprocesssing.pool.AsyncResult undocumented field
Change by g...@nlc.co.nz : -- title: multiprocesssing.Pool.map_async() undocumented -> multiprocesssing.pool.AsyncResult undocumented field ___ Python tracker <https://bugs.python.org/issue31729> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31800] datetime.strptime: Support for parsing offsets with a colon
Paul G added the comment: This seems very useful to me. I very frequently advise people *against* using dateutil.parser (despite my conflict of interest as maintainer of dateutil) for well-known formats, but the problem frequently comes up of, "what should I do when I have date created by isoformat()?", to which there's no clean satisfying answer other than, "use dateutil.parser even though you know the format." I think the strptime page that Mario linked to is evidence that the %z directive is *intended* to match against -HH:MM, and so that might be the most "standard" solution. That said, I somewhat prefer the granularity of the GNU date extensions %z, %:z and %::z, since this allows downstream users to be stricter about what they are willing to accept. I think either approach is defensible, but that *something* should be done soon, preferably for the 3.7 release. -- nosy: +p-ganssle ___ Python tracker <https://bugs.python.org/issue31800> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1296434] Call by object reference sometimes call by value
Alan G added the comment: Lol! After four years I could hardly claim to care anymore... -- ___ Python tracker <http://bugs.python.org/issue1296434> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27509] Some tests breaks PGO build on Windows
New submission from Charles G.: Environment: Python 3.5.2 Visual Studio 2015 Update 2 Windows 7 amd64 I tried to build python with pgo (build.bat --pgo) but found that no python35!1.pgc or python!1.pgc was created. Then I run the tests one by one while checking the existence of python35!1.pgc and found that these tests when run prevents above pgcs from being created: test_concurrent_futures test_faulthandler test_multiprocessing_main_handling test_multiprocessing_spawn test_os test_subprocess I'm not sure of the reason why no pgc is produced when running these tests. -- components: Windows messages: 270374 nosy: Charles G., paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Some tests breaks PGO build on Windows type: compile error versions: Python 3.5 ___ Python tracker <http://bugs.python.org/issue27509> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27509] Some tests breaks PGO build on Windows
Charles G. added the comment: Community Edition. PGO is available in the Community Edition since at least VS 2012. -- ___ Python tracker <http://bugs.python.org/issue27509> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27509] Some tests breaks PGO build on Windows
Charles G. added the comment: The compiler itself supports PGO in the Community Edition. I'm not sure about the IDE (not using it). Since I compiled python using the batch file (with msbuild) so it is not limited by the features of the IDE. -- ___ Python tracker <http://bugs.python.org/issue27509> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27509] Some tests breaks PGO build on Windows
Charles G. added the comment: Tried with Visual Studio Community 2015 Update 3 with same result. -- ___ Python tracker <http://bugs.python.org/issue27509> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27663] Inconsistent CSV Writer Behaviour
New submission from G Young: When writing scientific notation to CSV with custom line-terminators, the behaviour is inconsistent depending on the line-terminator you use. In the file provided, two different line-terminator result in one quoting the number as a string and the other not. IMO the second example is correct, but I don't understand why the behaviours should be any different. -- components: IO files: bug.py messages: 271779 nosy: G Young priority: normal severity: normal status: open title: Inconsistent CSV Writer Behaviour versions: Python 3.5 Added file: http://bugs.python.org/file43963/bug.py ___ Python tracker <http://bugs.python.org/issue27663> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27663] Inconsistent CSV Writer Behaviour
G Young added the comment: That doesn't make sense to me. Can you explain how that is intended behaviour? I just changed from '-' to '?' in the lineterminator. -- ___ Python tracker <http://bugs.python.org/issue27663> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27663] Inconsistent CSV Writer Behaviour
G Young added the comment: Second time around does the charm. I see the hidden "-" in the scientific notation is causing this. Thanks! -- ___ Python tracker <http://bugs.python.org/issue27663> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17212] os.path.isfile() in Python 3.3 sometimes fails
New submission from G. Poore: os.path.isfile() sometimes incorrectly reports that a file does not exist under Python 3.3 (only tested under Windows). This may be encoding related. The issue only appears under a very particular set of circumstances; see comments in the attached script. The attached script demonstrates the issue by testing for an arbitrary file x.txt (you will need to create a file with that name for the test script to work). -- components: Library (Lib) files: os-path-issue-3-3.py messages: 182188 nosy: gpoore priority: normal severity: normal status: open title: os.path.isfile() in Python 3.3 sometimes fails type: behavior versions: Python 3.3 Added file: http://bugs.python.org/file29082/os-path-issue-3-3.py ___ Python tracker <http://bugs.python.org/issue17212> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26573] Method Parameters can be Accepted as Keyword Arguments?
G Young added the comment: Google indicates that this is indeed a feature of the language. Sorry about that! I guess that was a miscommunication on the PR-end. -- status: open -> closed ___ Python tracker <http://bugs.python.org/issue26573> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26573] Method Parameters can be Accepted as Keyword Arguments?
New submission from G Young: This issue arose as we were making changes to the 'pandas' library. I am not sure if this is a bug or feature, but it definitely did not cross anyone's minds when discussing the PR at hand. I have attached a code sample to illustrate the "bug" that I have run successfully on Python 2.7 and Python 3.4. -- components: Interpreter Core files: bug.py messages: 261862 nosy: G Young priority: normal severity: normal status: open title: Method Parameters can be Accepted as Keyword Arguments? type: behavior versions: Python 2.7, Python 3.4 Added file: http://bugs.python.org/file42178/bug.py ___ Python tracker <http://bugs.python.org/issue26573> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28601] Ambiguous datetime comparisons should use == rather than 'is' for tzinfo comparison
New submission from Paul G:
According to PEP495
(https://www.python.org/dev/peps/pep-0495/#aware-datetime-equality-comparison)
datetimes are considered not equal if they are an ambiguous time and have
different zones. However, currently "interzone comparison" is defined /
implemented as the zones being the same object rather than the zones comparing
equal.
One issue with this is that it actually breaks backwards compatibility of the
language, because there doesn't seem to be a way to provide a
(backwards-compatible) class that implements folding behavior and has
equivalent dates compare equal. An example using python-dateutil:
```
from datetime import datetime
from dateutil import tz
NYC = tz.gettz('America/New_York')
ET = tz.gettz('US/Eastern')
dt = datetime(2011, 11, 6, 5, 30, tzinfo=tz.tzutc()) # This is 2011-11-06 01:30
EDT-4
dt_edt = dt.astimezone(ET)
dt_nyc = dt.astimezone(NYC)
print(dt_nyc == dt_edt)
```
In Python 3.5 that will return True, in Python 3.6 it will return False, even
though 'US/Eastern' and 'America/New_York' are the same zone. In this case, I
might be able to enforce that these time zones are singletons so that `is`
always returns True (though this may have other negative consequences for
utility), but even that solution would fall apart for things like `tzrange` and
`tzstr`, where you can know that the `dt.utcoffset()`s are going to be
identical for ALL values of `dt`, but you can't force the objects to be
identical.
I would suggest that it be changed to use `__eq__` to determine whether two
`tzinfo` objects are the same zone, as this will allow tzinfo providers to
create `tzinfo` objects with a consistent behavior between versions in this
edge case.
--
components: Library (Lib)
messages: 280003
nosy: belopolsky, p-ganssle
priority: normal
severity: normal
status: open
title: Ambiguous datetime comparisons should use == rather than 'is' for tzinfo
comparison
type: behavior
versions: Python 3.6, Python 3.7
___
Python tracker
<http://bugs.python.org/issue28601>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28602] `tzinfo.fromutc()` fails when used for a fold-aware tzinfo implementation
New submission from Paul G:
After PEP-495, the default value for non-fold-aware datetimes is that they
return the DST side, not the STD side (as was the assumption before PEP-495).
This invalidates an assumption made in `tz.fromutc()`. See lines 991-1000 of
datetime.py:
dtdst = dt.dst()
if dtdst is None:
raise ValueError("fromutc() requires a non-None dst() result")
delta = dtoff - dtdst
if delta:
dt += delta
dtdst = dt.dst()
if dtdst is None:
raise ValueError("fromutc(): dt.dst gave inconsistent "
"results; cannot convert")
Line 997
(https://github.com/python/cpython/blob/be8de928e5d2f1cd4d4c9c3e6545b170f2b02f1b/Lib/datetime.py#L997)
assumes that an ambiguous datetime will return the STD side, not the DST side,
and as a result, if you feed it a date in UTC that should resolve to the STD
side, it will actually return 1 hour (or whatever the DST offset is) AFTER the
ambiguous date that should be returned.
If 997 is changed to:
dtdst = dt.replace(fold=1).dst()
That will not affect fold-naive zones (which are instructed to ignore the
`fold` parameter) and restore the original behavior. This will allow fold-aware
timezones to be implemented as a wrapper around `fromutc()` rather than a
complete re-implementation, e.g.:
class FoldAwareTzInfo(datetime.tzinfo):
def fromutc(self, dt):
dt_wall = super(FoldAwareTzInfo, self).fromutc(dt)
is_fold = self._get_fold_status(dt, dt_wall)
return dt_wall.replace(fold=is_fold)
--
messages: 280007
nosy: belopolsky, p-ganssle, tim.peters
priority: normal
severity: normal
status: open
title: `tzinfo.fromutc()` fails when used for a fold-aware tzinfo implementation
type: behavior
versions: Python 3.6, Python 3.7
___
Python tracker
<http://bugs.python.org/issue28602>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28602] `tzinfo.fromutc()` fails when used for a fold-aware tzinfo implementation
Paul G added the comment: Of the `tzinfo` implementations provided by `python-dateutil`, `tzrange`, `tzstr` (GNU TZ strings), `tzwin` (Windows style time zones) and `tzlocal` all satisfy this condition. These are basically all implementations of default system time zone information. With current implementations `tzfile` and `tzical` also use the invariant algorithm, though theoretically there are edge cases where this will cause problems, and those should have their `fromutc()` adjusted. In any case, I can't think of a single actual downside to this change - all it does is preserve the original behavior of `fromutc()`. As currently implemented, the algorithm is simply wrong when `dst()` is affected by `fold`, and this change would have no effect on zones where `dst()` is *not* affected by fold. -- ___ Python tracker <http://bugs.python.org/issue28602> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28602] `tzinfo.fromutc()` fails when used for a fold-aware tzinfo implementation
Paul G added the comment: > After all, how much effort would it save for you in dateutil if you could > reuse the base class fromutc? Realistically, this saves me nothing since I have to re-implement it anyway in in all versions <= Python 3.6 (basically just the exact same algorithm with line 997 replaced with enfold(dt, fold=1) rather than dt.replace(fold=1), but I'd rather it fall back to the standard `fromutc()` in fold-aware versions of Python 3.6. That said, I don't see how it's a big can of worms to open. If you're going to provide `fromutc()` functionality, it should not be deliberately broken. As I mentioned above, I see no actual downside in having `fromutc()` actually work as advertised and as intended. -- ___ Python tracker <http://bugs.python.org/issue28602> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28641] Describe PEP 495 features in "What's New in Python 3.6" document
Paul G added the comment:
I've never written a "What's New" before, but here are the main things I took
away from implementing a PEP 495-compliant tzinfo class:
- The `fold` attribute is the SECOND occurrence of the time, not the first
occurrence of the time. In my first pass solution of this, I had this inverted,
so I would say it's worth making it very clear which is which, maybe with an
example (I'm using full zone names here like those returned by
`dateutil.tz.tzwin`):
>>> datetime(2011, 11, 6, 1, 30, fold=0, tzinfo=US_EASTERN).tzname()
'Eastern Daylight Time'
>>> datetime(2011, 11, 6, 1, 30, fold=1, tzinfo=US_EASTERN).tzname()
'Eastern Standard Time'
- Because the default for "fold" is 0, the default for "unspecified" fold has
changed from being on the STD side to being on the DST side:
>>> datetime(2011, 11, 6, 1, 30, tzinfo=US_EASTERN_NO495).tzname()
'EST'
>>> datetime(2011, 11, 6, 1, 30, tzinfo=US_EASTERN_PEP495).tzname()
'EDT'
- It is now best practices to implement your own `fromutc()` (I got the
impression that in the past it was encouraged that you generally just wrote a
`utcoffset()` and `dst()` function.
- Comparisons of datetimes have changed such that inter-zone comparisons
representing the same wall time and offset will now fail during ambiguous times
(depending on the resolution of #28601, the exact semantics of what is an
inter-zone comparison should be clarified):
>>> dt1 = datetime(2016, 11, 6, 1, 30, fold=1, tzinfo=US_EASTERN)
>>> dt2 = datetime(2016, 11, 6, 1, 30, fold=0, tzinfo=US_CENTRAL)
>>> dt1 == dt2
False
I think the remainder of my insights would have to do with
backwards-compatibility and I'm not sure how much relevance they have to
"What's New".
With regards to the documentation, here are my notes:
- One thing that should be made more clear is that arithmetic operations wipe
out the `fold` attribute - this behavior and the reasoning behind it should
probably be clear in the section on datetime operations, because I think people
will be confused by this:
>>> from datetime import datetime, timedelta
>>> from dateutil import tz
>>> dt = datetime(2011, 11, 6, 1, 30, fold=1, tz=gettz('US/Eastern')
>>> dt.tzname()
'EST'
>>> (dt + timedelta(minutes=1)).tzname()
'EDT'
- Not related to the changes in 3.6, but it might also be worth clarifying that
`datetime.astimezone()` with no arguments returns a datetime with a fixed
offset zone, NOT the local zone (it's somewhat clear, but it could be more
explicit):
>>> dt.astimezone().tzname()
2011-11-06 01:30:00-5:00
>>> dt.astimezone() - timedelta(hours=5)
2011-11-05 20:30:00-05:00
>>> dt.astimezone(tz.tzlocal())
2011-11-06 01:30:00-5:00
>>> dt.astimezone(tz.tzlocal()) - timedelta(hours=5)
2011-11-05 20:30:00-04:00
- In the section on "working with datetime objects", GMT1 and GMT2 objects
don't support the `fold` attribute. That might be confusing (though there are
fold-aware tzinfo objects later in the documentation).
- In the section on time.tzname(), the example defines its own GMT1 time zone.
It might be clearer to just define GMT1 = datetime.timezone(timedelta(hours=1),
"Europe/Prague') rather than create a new fixed offset tzinfo.
- The "most implementations of dst() will probably look like one of these two"
section should be updated to reflect `fold`, maybe something like this:
def dst(self, dt):
# Code to set dston and dstoff to the time zone's DST
# transition times based on the input dt.year, and expressed
# in standard local time.
dt_naive = dt.replace(tzinfo=None)
if dston <= dt_naive < dstoff:
if dt_naive < dston + timedelta(hours=1) and dt.fold:
return timedelta(0)
else:
return timedelta(hours=1)
else:
return timedelta(0)
- The tzinfo.fromutc(dt) documentation suggests that this method is capable of
handling non-fixed offset zones. Per #28602, it seems that it should be made
clear that all zones implementing `fold` support should implement their own
`fromutc` method, as there is a deliberate bug in the algorithm when folds are
supported.
- This may be slightly confusing: "Note that the datetime instances that differ
only by the value of the fold attribute are considered equal in comparisons.",
because when I first read this, I assumed it meant that datetime(2011, 11, 6,
1, 30, tzinfo=US_EASTERN) == datetime(2011, 11, 6, 1, 30, fold=1,
tzinfo=US_EASTERN), but in fact it either means that *unambiguous* datetimes
that di
[issue11457] os.stat(): add new fields to get timestamps as Decimal objects with nanosecond resolution
Changes by Eric G. Barron : -- nosy: +ericography ___ Python tracker <http://bugs.python.org/issue11457> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39380] ftplib uses latin-1 as default encoding
Change by Sebastian G Pedersen : -- components: Library (Lib) nosy: SebastianGPedersen priority: normal severity: normal status: open title: ftplib uses latin-1 as default encoding type: behavior versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue39380> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39380] ftplib uses latin-1 as default encoding
Change by Sebastian G Pedersen : -- keywords: +patch pull_requests: +17443 stage: -> patch review pull_request: https://github.com/python/cpython/pull/18048 ___ Python tracker <https://bugs.python.org/issue39380> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39438] better handling of foreign signal handlers in signal.signal
New submission from Steven G. Johnson :
In embedded Python, if the embedding code sets a signal handler (e.g. for
SIGINT), then signal.getsignal(SIGINT) returns None. However,
signal.signal(SIGINT, signal.getsignal(SIGINT)) throws a TypeError, even though
it should logically be a no-op. This behavior is all implemented in
Modules/signalmodule.c and seems to have been around since 2.7 at least.
(Background: We observed this in Julia, which embeds Python in order to call
Python code, where matplotlib code that temporarily set signal(SIGINT, SIG_DFL)
led to an exception when it tried to restore the original signal handler. See
https://github.com/JuliaPy/PyPlot.jl/issues/459)
The C program below exhibits this problem [it sets its own SIGINT handler and
then starts up Python to execute signal(SIGINT,getsignal)]. Running it
results in "TypeError: signal handler must be signal.SIG_IGN, signal.SIG_DFL,
or a callable object"
Recommended changes:
1) if Handlers[signalnum].func == NULL, then signal(signalnum, None) should be
a no-op, returning None. This will allow signal(signalnum,
getsignal(signalnum)) to always succeed (as a no-op).
2) if Handlers[signalnum].func == NULL, then signal(signalnum, SIG_DFL) should
be a no-op, returning None. That is, the default signal handler should be the
foreign signal handler if one is installed.
3) The signal-handling documentation should warn against overriding the signal
handler for any signalnum where getsignal(signalnum) returns None (i.e. a
foreign signal handler), since there is no way to restore the original signal
handler afterwards. Anyway, you should be cautious about overriding signal
handlers that don't come from Python.
test code that throws a TypeError (compile and link with libpython):
#include
#include
#include
void myhandler(int sig) { printf("got signal %d\n", sig); }
int main(void)
{
signal(SIGINT, myhandler);
Py_InitializeEx(0);
PyRun_SimpleString("import signal\n"
"old_signal = signal.getsignal(signal.SIGINT)\n"
"signal.signal(signal.SIGINT, old_signal)\n"
"print(old_signal)\n");
Py_Finalize();
return 0;
}
------
components: Library (Lib)
messages: 360578
nosy: Steven G. Johnson
priority: normal
severity: normal
status: open
title: better handling of foreign signal handlers in signal.signal
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issue39438>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39380] ftplib uses latin-1 as default encoding
Sebastian G Pedersen added the comment: Thank you for the feedback. I will elaborate a little bit on the reasons and thoughts behind the pull request: Since RFC 2640, the industry standard within FTP Clients is UTF-8 (see e.g. FileZilla here: https://wiki.filezilla-project.org/Character_Encoding, or WinSCP here: https://winscp.net/eng/docs/faq_utf8). Given this, I believe the majority of the users that have not investigated the code wrongly assumes UTF-8 encoding for ftplib as well (as it is now). I am new to contributing, and not sure, how much deprecation warnings are used (I simply followed the previous encoding change on ftplib), so I will change it based on the feedback. However, shouldn't it be a FutureWarning, so it will be reported by default at initialisation? -- ___ Python tracker <https://bugs.python.org/issue39380> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39380] ftplib uses latin-1 as default encoding
Sebastian G Pedersen added the comment: Thanks again for the engagement. I am also in favor of adding the encoding to the constructor. However, following Giampaolo's comment, that utf-8 is standard and has been for a long time (and the RFC dating back to year 1999), I am also in favor of changing the default encoding in the same PR. As mentioned in the previous comments, most users use ASCII and will not be affected by this anyway - which is probably also why this issue hasn't been raised before. Please let me know your thoughts on this. -- ___ Python tracker <https://bugs.python.org/issue39380> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39380] ftplib uses latin-1 as default encoding
Sebastian G Pedersen added the comment: Yes, I will update the PR before the end of next week. -- ___ Python tracker <https://bugs.python.org/issue39380> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40900] uuid module build fix on FreeBSD proposal
Change by Danilo G. Baio : -- nosy: +dbaio ___ Python tracker <https://bugs.python.org/issue40900> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30744] Local variable assignment is broken when combined with threads + tracing + closures
Changes by Xavier G. Domingo : -- nosy: +xgdomingo ___ Python tracker <http://bugs.python.org/issue30744> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29304] dict: simplify lookup functions
Changes by Xavier G. Domingo : -- nosy: +xgdomingo ___ Python tracker <http://bugs.python.org/issue29304> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17960] Clarify the required behaviour of locals()
Changes by Xavier G. Domingo : -- nosy: +xgdomingo ___ Python tracker <http://bugs.python.org/issue17960> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29988] (async) with blocks and try/finally are not as KeyboardInterrupt-safe as one might like
Changes by Xavier G. Domingo : -- nosy: +xgdomingo ___ Python tracker <http://bugs.python.org/issue29988> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29960] _random.Random state corrupted on exception
New submission from Bryan G. Olson: Demo: Run the Python library's test_random.py under the Python debugger and check the generator at the start of test_shuffle(): C:\bin\Python36>python -m pdb Lib\test\test_random.py > c:\bin\python36\lib\test\test_random.py(1)() -> import unittest (Pdb) break 61 Breakpoint 1 at c:\bin\python36\lib\test\test_random.py:61 (Pdb) continue .> c:\bin\python36\lib\test\test_random.py(61)test_shuffle() -> shuffle = self.gen.shuffle (Pdb) list 56 # randomness source is not available. 57 urandom_mock.side_effect = NotImplementedError 58 self.test_seedargs() 59 60 def test_shuffle(self): 61 B-> shuffle = self.gen.shuffle 62 lst = [] 63 shuffle(lst) 64 self.assertEqual(lst, []) 65 lst = [37] 66 shuffle(lst) (Pdb) p self.gen.getrandbits(31) 2137781566 (Pdb) p self.gen.getrandbits(31) 2137781566 (Pdb) p self.gen.getrandbits(31) 2137781566 (Pdb) p self.gen.getrandbits(31) 2137781566 (Pdb) p self.gen.getrandbits(31) 2137781566 That's not random. Diagnosis: The order in which test functions run is the lexicographic order of their names. Thus unittest ran test_setstate_middle_arg() before running test_shuffle(). test_setstate_middle_arg() did some failed calls to _random.Random.setstate(), which raised exceptions as planned, but also trashed the state of the generator. test_random.py continues to use the same instance of _random.Random after setstate() raises exceptions. The documentation for Random.setstate() does not specify what happens to the state of the generator if setstate() raises an exception. Fortunately the generator recommended for secure applications, SystemRandom, does not implement setstate(). Solution: The fix I prefer is a small change to random_setstate() in _randommodule.c, so that it does not change the state of the generator until the operation is sure to succeed. -- components: Library (Lib) messages: 290977 nosy: bryangeneolson priority: normal severity: normal status: open title: _random.Random state corrupted on exception type: behavior versions: Python 3.7 ___ Python tracker <http://bugs.python.org/issue29960> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29960] _random.Random state corrupted on exception
Bryan G. Olson added the comment: I'm going through https://docs.python.org/devguide/pullrequest.html and would like to be assigned this issue. -- ___ Python tracker <http://bugs.python.org/issue29960> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29960] _random.Random state corrupted on exception
Changes by Bryan G. Olson : -- pull_requests: +1135 ___ Python tracker <http://bugs.python.org/issue29960> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29960] _random.Random state corrupted on exception
Changes by Bryan G. Olson : -- pull_requests: +1181 ___ Python tracker <http://bugs.python.org/issue29960> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17852] Built-in module _io can loose data from buffered files at exit
Changes by Xavier G. Domingo : -- nosy: +xgdomingo ___ Python tracker <http://bugs.python.org/issue17852> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32561] Add API to io objects for non-blocking reads/writes
Change by Xavier G. Domingo : -- nosy: +xgdomingo ___ Python tracker <https://bugs.python.org/issue32561> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31122] SSLContext.wrap_socket() throws OSError with errno == 0
Change by Xavier G. Domingo : -- nosy: +xgdomingo ___ Python tracker <https://bugs.python.org/issue31122> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22499] [SSL: BAD_WRITE_RETRY] bad write retry in _ssl.c:1636
Change by Xavier G. Domingo : -- nosy: +xgdomingo ___ Python tracker <https://bugs.python.org/issue22499> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30491] Add a lightweight mechanism for detecting un-awaited coroutine objects
Change by Xavier G. Domingo : -- nosy: +xgdomingo ___ Python tracker <https://bugs.python.org/issue30491> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32623] Resize dict on del/pop
Change by Xavier G. Domingo : -- nosy: +xgdomingo ___ Python tracker <https://bugs.python.org/issue32623> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32637] Android: set sys.platform to android
Change by Xavier G. Domingo : -- nosy: +xgdomingo ___ Python tracker <https://bugs.python.org/issue32637> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32703] 'async with' somehow suppresses unawaited coroutine warnings
Change by Xavier G. Domingo : -- nosy: +xgdomingo ___ Python tracker <https://bugs.python.org/issue32703> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32590] Proposal: add an "ensure(arg)" builtin for parameter validation
Change by Xavier G. Domingo : -- nosy: +xgdomingo ___ Python tracker <https://bugs.python.org/issue32590> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32810] Expose ags_gen and agt_gen in asynchronous generators
Change by Xavier G. Domingo : -- nosy: +xgdomingo ___ Python tracker <https://bugs.python.org/issue32810> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32767] Mutating a list while iterating: clarify the docs
Change by Xavier G. Domingo : -- nosy: +xgdomingo ___ Python tracker <https://bugs.python.org/issue32767> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24255] Replace debuglevel-related logic with logging
Change by Xavier G. Domingo : -- nosy: +xgdomingo ___ Python tracker <https://bugs.python.org/issue24255> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32751] wait_for(future, ...) should wait for the future (even if a timeout occurs)
Change by Xavier G. Domingo : -- nosy: +xgdomingo ___ Python tracker <https://bugs.python.org/issue32751> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19495] context manager for measuring duration of blocks of code
Change by Xavier G. Domingo : -- nosy: +xgdomingo ___ Python tracker <https://bugs.python.org/issue19495> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31901] atexit callbacks should be run at subinterpreter shutdown
Change by Xavier G. Domingo : -- nosy: +xgdomingo ___ Python tracker <https://bugs.python.org/issue31901> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32226] Implement PEP 560: Core support for typing module and generic types
Change by Xavier G. Domingo : -- nosy: +xgdomingo ___ Python tracker <https://bugs.python.org/issue32226> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32292] Building fails on Windows
Change by Xavier G. Domingo : -- nosy: +xgdomingo ___ Python tracker <https://bugs.python.org/issue32292> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24085] large memory overhead when pyc is recompiled
Jonathan G. Underwood added the comment:
Seeing a very similar problem - very high memory useage during byte compilation.
Consider the very simple code in a file:
```
def test_huge():
try:
huge = b'\0' * 0x1 # this allocates 4GB of memory!
except MemoryError:
print('OOM')
```
Running this sequence of commands shows that during byte compilation, 4 GB
memory is used. Presumably this is because of the `huge` object - note of
course the function isn't actually executed.
```
valgrind --tool=massif python memdemo.py
ms_print massif.out.7591 | less
```
You'll need to replace 7591 with whatever process number valgrind reports.
Is there any hope of fixing this? It's currently a problem for me when running
tests on Travis, where the memory limit is 3GB. I had hoped to use a
conditional like the above to skip tests that would require more memory than is
available. However, the testing is killed before that simply because the byte
compilation is causing an OOM.
--
nosy: +jonathan.underwood
___
Python tracker
<https://bugs.python.org/issue24085>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24085] large memory overhead when pyc is recompiled
Jonathan G. Underwood added the comment: Thanks to both Serhiy Storchaka and David Murray - indeed you're both correct, and that is the issue in 21074, and the workaround from there of declaring a variable for that size fixes the problem. -- ___ Python tracker <https://bugs.python.org/issue24085> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33515] subprocess.Popen on a Windows batch file always acts as if shell=True
Change by Sergey G. Brester : -- keywords: +patch pull_requests: +8375 stage: needs patch -> patch review ___ Python tracker <https://bugs.python.org/issue33515> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
