[issue39211] Change in http.server default IP behavior?
Change by Shane : -- type: -> behavior ___ Python tracker <https://bugs.python.org/issue39211> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39211] Change in http.server default IP behavior?
New submission from Shane : It seems to me that the direct invocation behavior for http.server changed, probably with Python 3.8 (I'm currently using 3.8.1 on Windows 10). On 3.7.X I was able to use it as described in the docs (https://docs.python.org/3/library/http.server.html) > python -m http.server 8000 and it would default to whatever IP address was available. Now, in order for it to function at all (not return "This site can’t be reached" in Chrome), I have to bind it to a specific IP address (say, 127.0.0.1, sticking with the docs example). > python -m http.server 8000 --bind 127.0.0.1 At which point it works fine. So it's still quite usable for this purpose, though I was surprised and -simple as the solution is- the solution is less simple when you don't know it! Was this an intended change? Something something security, perhaps? If so, should it be noted in the "What's new" of the docs? And of course, there's always the slight possibility that some aspect of Windows or Chrome behavior changed, but based on the termal's response I don't think that's the case. Thanks, -- messages: 359299 nosy: Shane Smith priority: normal severity: normal status: open title: Change in http.server default IP behavior? versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue39211> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39211] Change in http.server default IP behavior?
Shane added the comment: For the basic invocation: >python -m http.server 8080 Serving HTTP on :: port 8080 (http://[::]:8080/) ... It just sits there, because I can't access it (http://[::]:8080/ is not a valid address, so far as I know, and inserting my IP address doesn't find it either). If I bind it to an IP address, it works as expected (using 127.0.0.1 from the docs, for the sake of consistency). For the following messages, I'm starting up the server in my user directory, browsing to http://127.0.0.1:8080/ in Chrome, and following the Documents link. >python -m http.server 8080 --bind 127.0.0.1 Serving HTTP on 127.0.0.1 port 8080 (http://127.0.0.1:8080/) ... 127.0.0.1 - - [04/Jan/2020 15:15:18] "GET / HTTP/1.1" 200 - 127.0.0.1 - - [04/Jan/2020 15:15:18] code 404, message File not found 127.0.0.1 - - [04/Jan/2020 15:15:18] "GET /favicon.ico HTTP/1.1" 404 - 127.0.0.1 - - [04/Jan/2020 15:15:28] "GET /Documents/ HTTP/1.1" 200 - -- ___ Python tracker <https://bugs.python.org/issue39211> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39211] Change in http.server default IP behavior?
Shane added the comment: A small update: Using the direct invocation: > python -m http.server 8000 Serving HTTP on :: port 8080 (http://[::]:8080/) ... Is NOT accessible at the following addresses: http://[::]:8080/ # most surprising, because this is where it tells you to go http://:8080/ # this was the Python <= 3.7 behavior, as I used it anyhow But it IS accessible at the following addresses: http://[::1]:8080/ http://localhost:8080/ There may be others I don't know about. I recognize that my difficulties likely arise from a lack of familiarity with internet protocols, as this isn't something I use with any kind of regularity. But I do think it's possible (and desirable) for the method to be as casual-friendly as it was in Python 3.7. Specifically, the direct invocation tells the user they can go to http://[::]:8080/, which they cannot. They CAN go to http://[::1]:8080/. Should this instead be the message returned on direct invocation? So far as I can tell, this is still a behavior change, as the old behavior was accessible from your IP address and therefore visible to other computers on the network (I assume localhost is not). But it would at least do what it says on the tin. -- ___ Python tracker <https://bugs.python.org/issue39211> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39211] Change in http.server default IP behavior?
Shane added the comment: Jason, thank you for the primer. > Nevertheless, when I tried the same thing on my Windows machine, I got a > different outcome. The server bound to [::0] but was unreachable on > http://127.0.0.1:8000. Perhaps it's an issue with IPv4 addresses in general for Python 3.8 on Windows when they are not directly bound during invocation of the server. I used to be able to reach the server with http://:8080/ (this was my initial surprise), but now this behavior doesn't work for me. However, on further testing http://:8080/ DOES work. -- status: pending -> open ___ Python tracker <https://bugs.python.org/issue39211> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39211] Change in http.server default IP behavior?
Shane added the comment: Based on my understanding, your fix should do it. -- stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue39211> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36172] csv module internal consistency
New submission from Shane :
It occurred to me there is a slight mismatch in the behavioral consistency of
the csv module (at least on Windows, Python 3.X). Specifically, csv.writer()
and csv.reader() treat the line terminator slightly differently. To boil it
down to a concise example:
#==
import csv
data = [[1, 2, 3], [4, 5, 6]]
with open('test.csv', 'w') as fout:
csv.writer(fout).writerows(data)
with open('test.csv', 'r') as fin:
data2 = list(csv.reader(fin))
print(data, data2, sep='\n')
>>>
[[1, 2, 3], [4, 5, 6]]
[['1', '2', '3'], [], ['4', '5', '6'], []]
#==
So because csv.writer() uses lineterminator = '\r\n', data and data2 have a
different structure (data2 has empty rows). To me this seems undesirable, so I
always go out of my way to use lineterminator = '\n'.
#==
import csv
data = [[1, 2, 3], [4, 5, 6]]
with open('test.csv', 'w') as fout:
csv.writer(fout, lineterminator='\n').writerows(data)
with open('test.csv', 'r') as fin:
data2 = list(csv.reader(fin))
print(data, data2, sep='\n')
>>>
[[1, 2, 3], [4, 5, 6]]
[['1', '2', '3'], ['4', '5', '6']]
#==
Then the input and output have the same structure. I assume there was a reason
lineterminator = '\r\n' was chosen as default, but for me there is no benefit
wrt csv files. It seems like we would be better off with the more consistent,
"reversible" behavior.
Alternatively, the default behavior of csv.reader() could be changed. But in
either case, I feel like their default behaviors should be in alignment.
Thoughts? Thanks for reading.
--
messages: 337042
nosy: Shane Smith
priority: normal
severity: normal
status: open
title: csv module internal consistency
type: behavior
___
Python tracker
<https://bugs.python.org/issue36172>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36172] csv module internal consistency
Shane added the comment: Thank you both for having a look. I just find that these sort of gotchas rather annoying (nonsensical mental burden of having to memorize behavior that does not behave like most other features for "hysterical raisins"). I think making the documentation more visible would be far better than nothing. Currently, help(csv) does not even mention the newline parameter as an available option in any context, nor does help(csv.writer). I think ideally, the user should be able to rely on a given module's help documentation for most things without having to leave the interpreter to consult the manual. Thoughts? -- ___ Python tracker <https://bugs.python.org/issue36172> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36592] is behave different for integers in 3.6 and 3.7
Shane added the comment: This is the sort of thing that makes me avoid "is" in favor of "==" for most applications. Understanding when two objects point to the same memory requires a deeper understanding of the underlying code than I usually want to delve into. Anyway, I find it interesting that for 3.7.3: >>> a, b = 256, 256 >>> a is b True >>> a, b = 257, 257 >>> a is b False So 2**8 is a magic number, for whatever reason. I'll be sticking with "=="... -- nosy: +Shane Smith -eric.smith type: behavior -> ___ Python tracker <https://bugs.python.org/issue36592> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36595] Text Search in Squeezed Output Viewer
New submission from Shane : Would it be possible to enhance IDLE's new Squeezed Output Viewer (which I LOVE, btw), with a text search feature? If I'm in a module's help documentation, I'm usually looking for something, and I often end up copying the text into notepad and searching for it there. Seems like text search would be a useful feature. Thanks for reading, -- assignee: terry.reedy components: IDLE messages: 339906 nosy: Shane Smith, terry.reedy priority: normal severity: normal status: open title: Text Search in Squeezed Output Viewer type: enhancement ___ Python tracker <https://bugs.python.org/issue36595> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36592] is behave different for integers in 3.6 and 3.7
Shane added the comment: Well, then I guess that explains it! Still, like I said, I tend to shy away from features that require such a deep understanding of the implementation in order to avoid "gotchas". "is" does have its uses, but for me they very very rarely come up. -- ___ Python tracker <https://bugs.python.org/issue36592> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35250] Minor parameter documentation mismatch for turtle
New submission from Shane : I noticed a slight mismatch in the parameter documentation for one of turtle's functions. onclick() accepts the parameters (fun, btn, add), but the documentation describes the parameters (fun, num, add). A minor issue, to be sure, but I wanted to point it out since I just noticed it. I'm using Python 3.7.1 but I suspect it's not isolated to that. >>> help(turtle.Turtle().onclick) Help on method onclick in module turtle: onclick(fun, btn=1, add=None) method of turtle.Turtle instance Bind fun to mouse-click event on this turtle on canvas. Arguments: fun -- a function with two arguments, to which will be assigned the coordinates of the clicked point on the canvas. num -- number of the mouse-button defaults to 1 (left mouse button). add -- True or False. If True, new binding will be added, otherwise it will replace a former binding. -- assignee: docs@python components: Documentation messages: 329932 nosy: Shane Smith, docs@python priority: normal severity: normal status: open title: Minor parameter documentation mismatch for turtle ___ Python tracker <https://bugs.python.org/issue35250> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35256] The Console of Python 3.7.0.
Shane added the comment: I suspect the author simply does not realize lists are mutable in Python. -- nosy: +Shane Smith ___ Python tracker <https://bugs.python.org/issue35256> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12659] Add tests for packaging.tests.support
Changes by shane moore : -- nosy: +shane.moore ___ Python tracker <http://bugs.python.org/issue12659> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17123] Add OCSP support to ssl module
Change by Shane Harvey : -- nosy: +ShaneHarvey ___ Python tracker <https://bugs.python.org/issue17123> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34932] Add macOS TCP_KEEPALIVE to available socket options
Change by Shane Harvey : -- nosy: +ShaneHarvey nosy_count: 3.0 -> 4.0 pull_requests: +23829 pull_request: https://github.com/python/cpython/pull/25079 ___ Python tracker <https://bugs.python.org/issue34932> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43626] SIGSEV in PyErr_SetObject
Shane Harvey added the comment: This issue was resolved in https://jira.mongodb.org/browse/PYTHON-2621 The cause of the segfault was determined to be gevent 1.3.4 (2018) and/or greenlet 0.4.13 (2018). When the reporter upgraded to gevent==21.1.2 and greenlet==1.0 the segfault went away. -- nosy: +ShaneHarvey ___ Python tracker <https://bugs.python.org/issue43626> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34932] Add macOS TCP_KEEPALIVE to available socket options
Shane Harvey added the comment: I opened a PR to add the socket.TCP_KEEPALIVE flag *on macOS only*. I don't see a reason to add it on Windows since as far as I can tell, TCP_KEEPALIVE is completely undocumented there. Besides there are already two ways to configure keepalive times on Windows (using sock.ioctl+SIO_KEEPALIVE_VALS and using sock.setsockopt+TCP_KEEPIDLE), I don't think we should add a third way. See https://github.com/python/cpython/pull/25079 -- ___ Python tracker <https://bugs.python.org/issue34932> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10551] mimetypes read from the registry should not overwrite standard mime mappings
Shane Harvey added the comment: This issue says "mimetypes read from the registry should not overwrite standard mime mappings". Was this change ever made? the following issue claims that the "HKEY_CLASSES_ROOT\.js\Content Type" registry can still overrides ".js" files: https://bugs.python.org/issue43975? -- nosy: +ShaneHarvey ___ Python tracker <https://bugs.python.org/issue10551> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39232] asyncio crashes when tearing down the proactor event loop
Shane Mai added the comment:
I added some code to wait for all tasks completion before exit:
currentTask = asyncio.current_task()
for t in asyncio.all_tasks():
if currentTask != t:
await t
and still got the exception
Then I think it created additional thread somewhere and created an event_loop
inside it. To dig it out I sub-classed threading.Thread. I also wait for all
tasks in all threads before exiting:
loops: list[asyncio.AbstractEventLoop] = []
class MyThread(threading.Thread):
def start(self):
global loops
loops.append(asyncio.get_event_loop())
super().start()
async def func1():
async with aiohttp.ClientSession() as session:
async with session.get('https://www.okex.com/api/v5/public/time') as
resp:
print(resp.status)
print(await resp.json())
threading.Thread = MyThread
import aiohttp
async def main():
global loops
loops.append(asyncio.get_running_loop())
print(sys.argv)
task = asyncio.create_task(func1())
await task
print('done.')
currentTask = asyncio.current_task()
for loop in loops:
for t in asyncio.all_tasks(loop):
if currentTask != t:
await t
print('done2.')
#await asyncio.sleep(1)
#if __file__ == '__main__':
asyncio.run(main())
Then I found out the thread is created inside _loop.getaddrinfo: (files are
from python 3.9.6)
File aiohttp\resolver.py, line 31, in ThreadedResolver.resolve
FILE asyncio\base_events.py, line 856, in
BaseEventLoop(ProactorEventLoop).getaddrinfo
And it is strange that another thread is created when program exit:
FILE asyncio\base_events.py, line 563, in
BaseEventLoop(ProactorEventLoop).shutdown_default_executor
But sad it seems vscode cannot break a __del__ call. If I break somewhere else
first then it would not crash:(
--
nosy: +machine.gw
___
Python tracker
<https://bugs.python.org/issue39232>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38890] A subprocess.Popen created with creationFlags=DETACHED_PROCESS on Windows should not emit a ResourceWarning
New submission from Shane Harvey :
In https://bugs.python.org/issue26741 Popen was changed to emit a
ResourceWarning in __del__ if the process is still running. However, when
running a daemon/detached process it is completely valid to delete a Popen
object before the process is complete.
On Windows, a daemon process can be created by using the DETACHED_PROCESS
option, eg:
import subprocess
DETACHED_PROCESS = getattr(subprocess, 'DETACHED_PROCESS', 0x0008)
popen = subprocess.Popen(args, creationflags=DETACHED_PROCESS)
print('Running daemon process: ', popen.pid)
del popen
Unfortunately, the above will emit the warning:
C:\python\Python37\lib\subprocess.py:839: ResourceWarning: subprocess 840 is
still running
ResourceWarning, source=self)
Running daemon process: 3212
This makes it complicated to run a daemon process without emitting the resource
warning. The best solution I've got is to manually set the Popen.returncode to
circumvent the warning, ie:
popen = subprocess.Popen(args, creationflags=DETACHED_PROCESS)
print('Running daemon process: ', popen.pid)
# Set the returncode to avoid erroneous warning:
# "ResourceWarning: subprocess XXX is still running".
popen.returncode = 0
del popen
Running the attached script on Windows only one warning is emitted:
$ python.exe -Wall test_daemon_win.py
C:\python\Python37\lib\subprocess.py:839: ResourceWarning: subprocess 3584 is
still running
ResourceWarning, source=self)
Running daemon process: 3584
Running daemon process: 1012
I propose that Popen should not raise the resource warning when the
creationFlags includes DETACHED_PROCESS.
--
components: Library (Lib)
files: test_daemon_win.py
messages: 357237
nosy: ShaneHarvey
priority: normal
severity: normal
status: open
title: A subprocess.Popen created with creationFlags=DETACHED_PROCESS on
Windows should not emit a ResourceWarning
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file48738/test_daemon_win.py
___
Python tracker
<https://bugs.python.org/issue38890>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14303] Incorrect documentation for socket.py on linux
New submission from Shane Hansen : The python docs state that for socket.makefile "The file object references a dup()ped version of the socket file descriptor, so the file object and socket object may be closed or garbage-collected independently." In fact for socket.py dup() is never called, and no additional files are opened. Instead an object is returned which uses the original socket and does buffering. For me, this is the desired behaviour, but just thought I'd mention the docs were off. -- assignee: docs@python components: Documentation, IO files: test.py messages: 155768 nosy: Shane.Hansen, docs@python, georg.brandl, pitrou priority: normal severity: normal status: open title: Incorrect documentation for socket.py on linux type: behavior versions: Python 2.6, Python 2.7 Added file: http://bugs.python.org/file24843/test.py ___ Python tracker <http://bugs.python.org/issue14303> ___ ___ Python-bugs-list mailing list Unsubscribe: http://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
[issue31107] copyreg does not properly mangle __slots__ names
New submission from Shane Harvey:
This line in copyreg._slotnames does not properly calculate mangled attribute
names:
https://github.com/python/cpython/blob/v3.6.2/Lib/copyreg.py#L131
The problem is that it does not strip leading underscores from the class name:
>>> class _LeadingUnderscoreClassName(object):
... __slots__ = ("__bar",)
...
>>> import copy_reg
>>> copy_reg._slotnames(_LeadingUnderscoreClassName)
['__LeadingUnderscoreClassName__bar']
The result is that copy, pickle, and anything else that relies on _slotnames()
do not work on classes with leading underscores and private __slots__. This bug
is present in all versions of Python.
--
components: Library (Lib)
messages: 299665
nosy: Shane Harvey
priority: normal
severity: normal
status: open
title: copyreg does not properly mangle __slots__ names
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7
___
Python tracker
<http://bugs.python.org/issue31107>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31107] copyreg does not properly mangle __slots__ names
Changes by Shane Harvey : -- versions: -Python 3.7 ___ Python tracker <http://bugs.python.org/issue31107> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31107] copyreg does not properly mangle __slots__ names
Changes by Shane Harvey : -- pull_requests: +3038 ___ Python tracker <http://bugs.python.org/issue31107> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31107] copyreg does not properly mangle __slots__ names
Changes by Shane Harvey : -- pull_requests: +3039 ___ Python tracker <http://bugs.python.org/issue31107> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1322] Deprecate platform.dist() and platform.linux_distribution() functions
Shane Harvey added the comment: When are these functions going to be deprecated? In 3.5, 3.6, and master they still raise PendingDeprecationWarning, not DeprecationWarning: https://github.com/python/cpython/blob/v3.5.3/Lib/platform.py#L305-L306 https://github.com/python/cpython/blob/v3.6.2/Lib/platform.py#L304-L305 https://github.com/python/cpython/blob/5c4b0d0/Lib/platform.py#L304-L305 -- nosy: +ShaneHarvey ___ Python tracker <http://bugs.python.org/issue1322> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36061] zipfile does not handle arcnames with non-ascii characters on Windows
New submission from Shane Lee : Python 2.7.15 (probably affects newer versions as well) Given an archive with any number of files inside that have non-ascii characters in their filename `zipfile` will crash when extracting them to the file system. ``` Traceback (most recent call last): File "c:\dev\salt\salt\modules\archive.py", line 1081, in unzip zfile.extract(target, dest, password) File "c:\python27\lib\zipfile.py", line 1028, in extract return self._extract_member(member, path, pwd) File "c:\python27\lib\zipfile.py", line 1069, in _extract_member targetpath = os.path.join(targetpath, arcname) File "c:\python27\lib\ntpath.py", line 85, in join result_path = result_path + p_path UnicodeDecodeError: 'ascii' codec can't decode byte 0x82 in position 3: ordinal not in range(128) ``` -- components: Windows files: test.zip messages: 336172 nosy: Shane Lee, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: zipfile does not handle arcnames with non-ascii characters on Windows type: behavior versions: Python 2.7 Added file: https://bugs.python.org/file48159/test.zip ___ Python tracker <https://bugs.python.org/issue36061> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27603] Migrate IDLE context menu items to shell extension
Shane Smith added the comment: Would it be possible to allow the user to select whether they'd prefer a nested or flat context menu at install? I believe it went to nested as a result of issue23546. Unless there are a large number of installations (arbitrarily... perhaps 4 or more), the nested menu is a pain for a user like me who wants to open .py files in IDLE more than any other action. (If I may quote the fifth line of The Zen of Python... "Flat is better than nested.") With a little research, it was a fairly easy registry hack to de-nest the context menu. Still, a lot of people don't like to mess around in the registry, and user choice is usually a good thing. Thoughts? ------ nosy: +Shane Smith ___ Python tracker <http://bugs.python.org/issue27603> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27603] Migrate IDLE context menu items to shell extension
Shane Smith added the comment: Hi Vedran, that seems to now be the default behavior, regardless of previous installs (my 3.6 was a clean install, and it's still nested). Kind of a pain if you want to edit with IDLE frequently. While we wait for a more integrated solution, the hackish way to restore desired behavior is to run a .bat file containing: REG DELETE "HKEY_CLASSES_ROOT\Python.File\shell\editwithidle" Then run a .reg file (also just a text file with altered extension so windows knows what to do with it) with: Windows Registry Editor Version 5.00 [HKEY_CLASSES_ROOT\Python.File\shell\Edit with IDLE 3.6\command] @="\"C:\\Program Files\\Python36\\pythonw.exe\" -m idlelib \"%L\" %*" -- ___ Python tracker <http://bugs.python.org/issue27603> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27603] Migrate IDLE context menu items to shell extension
Shane Smith added the comment: I'm fine with a single implementation, so long as the implementation is what's best for the majority of users. Not my intent to increase the burden of work. So, let me ask the question alluded to in my first post: when is a nested menu actually desirable? I would argue that the vast majority of users have one or two versions of Python installed at any given time. And for that number, a flat menu is certainly preferred. The X.Y version numbering in the context menu introduced as a result of issue23546 solves said issue. I'm merely suggesting de-nesting the menu. -- ___ Python tracker <http://bugs.python.org/issue27603> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27603] Migrate IDLE context menu items to shell extension
Shane Smith added the comment: Since you're a developer, I'm sure you need a lot of versions installed so you can check for backwards combatibility (spelling intentional). But until recently, only the most recent IDLE was in the context menu, so I'm guessing your workflow for that checking doesn't depend on the context menu. (I liked the old way, BTW, but I can see how someone might not). But so long as you're doing it the current way, it remains easily hacked back to the way I like it, so I don't have a whole lot to complain about. Carry on, good sir. -- ___ Python tracker <http://bugs.python.org/issue27603> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27805] In Python 3, open('/dev/stdout', 'a') raises OSError with errno=ESPIPE
New submission from Shane Hathaway:
With Python 2, the following call worked:
open('/dev/stdout', 'a')
Users of Supervisor have been depending on that for a long time.
With Python 3.5, this is what happens:
>>> open('/dev/stdout', 'a')
Traceback (most recent call last):
File "", line 1, in
OSError: [Errno 29] Illegal seek
Presumably, this happens because Python 3 opens the file in 'w' mode and seeks
to the end, while Python 2 passed the 'a' flag directly to the underlying C
library; the underlying library is apparently smart enough to treat 'a' and 'w'
identically when opening character device files and FIFOs.
It's a nasty little surprise for those upgrading from Python 2.
--
components: IO
messages: 273158
nosy: hathawsh
priority: normal
severity: normal
status: open
title: In Python 3, open('/dev/stdout', 'a') raises OSError with errno=ESPIPE
versions: Python 3.5
___
Python tracker
<http://bugs.python.org/issue27805>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27805] In Python 3, open('/dev/stdout', 'a') raises OSError with errno=ESPIPE
Shane Hathaway added the comment:
Thanks for the analysis. I have already started a pull request to fix this in
Supervisor, but I also thought this change to Python might be gratuitous and
accidental. It seems like open('/dev/stdout', 'a') ought to work the same as
Python 2. If not, the Python documentation should warn people that using 'a'
with character devices and FIFOs will cause an OSError.
--
___
Python tracker
<http://bugs.python.org/issue27805>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
