[issue26395] asyncio does not support yielding from recvfrom (socket/udp)

[Martin Panter]

Martin Panter added the comment:

If your event loop supports it, maybe you could use add_reader() etc as a 
workaround (roughly based off a different function of my own; this version 
completely untested):

async def sock_recvfrom(nonblocking_sock, *pos, loop, **kw):
while True:
try:
return nonblocking_sock.recvfrom(*pos, **kw)
except BlockingIOError:
future = Future(loop=loop)
loop.add_reader(nonblocking_sock.fileno(), future.set_result, None)
try:
await future
finally:
loop.remove_reader(nonblocking_sock.fileno())

I’m not very experienced with asyncio, but I imagine having general-purpose 
loop.wait_readable(file_descriptor) etc methods would make writing these kind 
of functions easier.

--
nosy: +martin.panter

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21042] ctypes.util.find_library() should return full pathname instead of filename in linux

[Martin Panter]

Martin Panter added the comment:

Tamás, it might be a good idea for you to sign a contributor agreement 
.

I compiled Python in 32-bit mode and tried your v2 patch out, which found the 
wrong library as I predicted. Then I tried your new regex and it picked out the 
correct line. I had to edit it to get it to extract just the filename from the 
line:

r'lib%s\.[^\s]+\s\(%s(?:,\s.*)?\)\s=>\s(.*)' % (re.escape(name), abi_type)

I factored out the closing bracket from the comma + space bit, moved the group 
brackets to the end to extract the filename, and made it a raw string.

Without the patch, in 32-bit mode it will find 64-bit-only libraries:

>>> find_library("m")  # 32- and 64-bit available
'libm.so.6'
>>> find_library("tcl8.6")  # Only 64-bit version available!
'libtcl8.6.so'

With my edited regex:

>>> find_library("m")
'/usr/lib32/libm.so.6'
>>> find_library("tcl8.6") is None  # No 32-bit version found
True

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26397] Tweak importlib Example of importlib.import_module() to use importlib.util.module_from_spec()

[Brett Cannon]

Changes by Brett Cannon :


--
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26397] Tweak importlib Example of importlib.import_module() to use importlib.util.module_from_spec()

[Roundup Robot]

Roundup Robot added the comment:

New changeset f2a089d68297 by Brett Cannon in branch 'default':
Issue #26397: Update an importlib example to use util.module_from_spec() 
instead of create_module()
https://hg.python.org/cpython/rev/f2a089d68297

--
nosy: +python-dev

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26186] LazyLoader rejecting use of SourceFileLoader

[Brett Cannon]

Brett Cannon added the comment:

This has been resolved by removing the check (the docs have always said the 
method was ignored, so that will just continue). I also did separate commit to 
list that BuiltinImporter and ExtensionFileLoader won't work (they would need 
to be updated to return a module subclass to work).

I'm leaving this issue open to decide if I want to add an explicit check in 
importlib.util.LazyLoader.create_module() to verify that None is returned in 
Python 3.5 (I probably will, but I want to think about on it for a little bit).

--
resolution:  -> fixed
stage: test needed -> resolved

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26186] LazyLoader rejecting use of SourceFileLoader

[Roundup Robot]

Roundup Robot added the comment:

New changeset 9f1e680896ef by Brett Cannon in branch '3.5':
Issue #26186: Remove an invalid type check in
https://hg.python.org/cpython/rev/9f1e680896ef

New changeset 86fc6cdd65de by Brett Cannon in branch 'default':
Merge for issue #26186
https://hg.python.org/cpython/rev/86fc6cdd65de

--
nosy: +python-dev

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26388] Disabling changing sys.argv[0] with runpy.run_module(...alter_sys=True)

[Mike Kaplinskiy]

Changes by Mike Kaplinskiy :


--
keywords: +patch
Added file: http://bugs.python.org/file41981/patch.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26221] awaiting asyncio.Future swallows StopIteration

[Guido van Rossum]

Guido van Rossum added the comment:

I think TypeError is fine. I would make the message a bit longer to
explain carefully what's the matter.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26221] awaiting asyncio.Future swallows StopIteration

[Chris Angelico]

Chris Angelico added the comment:

POC patch, no tests. Is TypeError right? Should it be ValueError, since the 
notional type is "Exception"?

--
keywords: +patch
Added file: http://bugs.python.org/file41980/no_stop_iter.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26397] Tweak importlib Example of importlib.import_module() to use importlib.util.module_from_spec()

[Brett Cannon]

New submission from Brett Cannon:

The example uses `spec.loader.create_module()` where it should be using 
`util.module_from_spec(spec)`.

--
assignee: brett.cannon
components: Documentation
messages: 260589
nosy: brett.cannon
priority: normal
severity: normal
stage: needs patch
status: open
title: Tweak importlib Example of importlib.import_module() to use 
importlib.util.module_from_spec()
versions: Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26395] asyncio does not support yielding from recvfrom (socket/udp)

[Simon Bernier St-Pierre]

Simon Bernier St-Pierre added the comment:

I want to have a loop that receives data like this:

socket = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
socket.bind(('0.0.0.0', port))
socket.setblocking(False)
while True:
data, addr = await loop.sock_recvfrom(sock, 4096)
# process packet

It's pretty similar to what the blocking code would look like, but it allows me 
to keep everything on a single thread without blocking. It could be done with 
the Protocol API, but I'd rather use the shiny new async/await API.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26396] Create json.JSONType

[Brett Cannon]

New submission from Brett Cannon:

See https://github.com/python/typing/issues/182 for the full details, but it 
should be:

JSONType = t.Union[str, int, float, bool, None, t.Dict[str, t.Any], t.List[Any]]

--
assignee: brett.cannon
components: Library (Lib)
messages: 260587
nosy: brett.cannon, gvanrossum
priority: low
severity: normal
stage: needs patch
status: open
title: Create json.JSONType
type: enhancement
versions: Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26395] asyncio does not support yielding from recvfrom (socket/udp)

[Guido van Rossum]

Guido van Rossum added the comment:

I won't make you go through the PEP process, but I do think it's a bad
idea to add this. After all datagrams aren't guaranteed to arrive, so,
whil I don't know what protocol you're trying to implement, I think
you're probably better off writing the whole thing as a
DatagramProtocol subclass that handles all incoming packets.

If you need help writing your app's code it's probably better to ask
around on a mailing list.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26395] asyncio does not support yielding from recvfrom (socket/udp)

[Simon Bernier St-Pierre]

Simon Bernier St-Pierre added the comment:

That could work. I came up with this

class MyProtocol(aio.DatagramProtocol):
def __init__(self, fut):
self._fut = fut

def datagram_received(self, data, addr):
self.fut.set_result((data, addr))

fut = aio.Future()
loop.create_datagram_endpoint(lambda: MyProtocol(fut), ...)
yield from fut

1. Is there a better way of sharing the future between the protocol and the 
main function?
2. This might be inefficient because I have to create a new endpoint every time 
I want to receive a packet. I might be able to implement a scheme where I give 
the protocol a new future after every packet, but it's kind of cumbersome.

If I wrote the patch to make sock_recvfrom work, can it get merged or must it 
go through the PEP process?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26221] awaiting asyncio.Future swallows StopIteration

[Guido van Rossum]

Guido van Rossum added the comment:

OK, since eventually there won't be a way to inject StopIteration into
a Future anyway (it'll always raise RuntimeError once PEP 479 is the
default behavior) we should just reject this in set_exception().

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26000] Crash in Tokenizer - Heap-use-after-free

[Sean Gillespie]

Sean Gillespie added the comment:

Is anyone currently working on this? If not, I'd like to try and fix this. I've 
debugged this a little and think I have an idea of what's going on.

--
nosy: +swgillespie

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26395] asyncio does not support yielding from recvfrom (socket/udp)

[Guido van Rossum]

Guido van Rossum added the comment:

You should be able to do this by calling create_datagram_endpoint(), passing it 
a custom DatagramProtocol subclass whose datagram_received() stores the data in 
the result of a Future. You can then wait for the Future to wait for the data 
(assuming it ever arrives :-).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24872] Add /NODEFAULTLIB:MSVCRT to _msvccompiler

[Mark Mikofski]

Mark Mikofski added the comment:

still have the `link.exe` 1561 error without `extra_args=['/DLL']` issue. is 
there a patch? It goes in `distutils._msvccompiler` right?

--
nosy: +bwanamarko

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26395] asyncio does not support yielding from recvfrom (socket/udp)

[Simon Bernier St-Pierre]

New submission from Simon Bernier St-Pierre:

I want to receive data on a UDP socket that was bound, without blocking the 
event loop. I've looked through the asyncio docs, and I haven't found a way of 
doing that using the coroutine API (yield from/await).

There is a sock_recv method on BaseEventLoop which is a coroutine, it seems 
like sock_recvfrom was never implemented.

I don't have a patch for this right now, I wanted to know what people thought 
of adding support for this.

--
components: asyncio
messages: 260580
nosy: Simon Bernier St-Pierre, gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: asyncio does not support yielding from recvfrom (socket/udp)
versions: Python 3.5

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21042] ctypes.util.find_library() should return full pathname instead of filename in linux

[Tamás Bence Gedai]

Tamás Bence Gedai added the comment:

What do you think about this regex?

'(lib%s\.[^\s]+\s\(%s(?:\)|,\s.*\))\s=>\s.*)' % (re.escape(name), abi_type))

It works on 64 bit, just like before, but I could not test it on 32 bit. I'll 
add tests soon.

I looked for documentation on ldconfig, but could not find anything useful.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26385] the call of tempfile.NamedTemporaryFile fails and leaves a file on the disk

[Martin Panter]

Martin Panter added the comment:

I think patch 3 is good for Python 3, thankyou. For Python 2, the test will 
have to be adjusted. From memory, mode='wr' is accepted without an exception, 
and mode=2 triggers an early error (so we never trigger the bug).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26221] awaiting asyncio.Future swallows StopIteration

[Chris Angelico]

Chris Angelico added the comment:

Ultimately, it's the exact same thing that PEP 479 is meant to deal with - 
raising StopIteration is functionally identical to returning. I don't use 
asyncio enough to be certain, but I'm not aware of any good reason to inject a 
StopIteration into it; maybe an alternative solution is to add a check in 
set_exception "if isinstance(exception, StopIteration): raise DontBeAFool"?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26367] importlib.__import__ does not fail for invalid relative import

[Brett Cannon]

Brett Cannon added the comment:

Thanks for the patch, Manuel!

--
resolution:  -> fixed
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26367] importlib.__import__ does not fail for invalid relative import

[Roundup Robot]

Roundup Robot added the comment:

New changeset e523efd47418 by Brett Cannon in branch '3.5':
Issue #26367: Have importlib.__init__() raise RuntimeError when
https://hg.python.org/cpython/rev/e523efd47418

New changeset 8f72bf88f471 by Brett Cannon in branch 'default':
Merge for issue #26367
https://hg.python.org/cpython/rev/8f72bf88f471

--
nosy: +python-dev

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26221] awaiting asyncio.Future swallows StopIteration

[Guido van Rossum]

Guido van Rossum added the comment:

Chris, can you help out here? I still don't understand the issue here. Since 
"from __future__ import generator_stop" only works in 3.5+ it would not work in 
Python 3.3/3.4 (supported by upstream asyncio with literally the same source 
code currently). If there's no use case for f.set_exception(StopIteration) 
maybe we should just complain about that?

--
nosy: +Rosuav

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26307] no PGO for built-in modules with `make profile-opt`

[Brett Cannon]

Changes by Brett Cannon :


--
stage:  -> needs patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24915] Profile Guided Optimization improvements (better training, llvm support, etc)

[Brett Cannon]

Brett Cannon added the comment:

Please add the fix to the issue that reported the problem so that the fix can 
be tracked with the bug report.

--
resolution:  -> fixed
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26394] Have argparse provide ability to require a fallback value be present

[Brett Cannon]

Changes by Brett Cannon :


--
title: argparse: Add set_values() function to complement set_defaults() -> Have 
argparse provide ability to require a fallback value be present

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26394] argparse: Add set_values() function to complement set_defaults()

[Brett Cannon]

Brett Cannon added the comment:

To paraphrase Michael, he wants a way to tell argparse that an argument has to 
be supplied either from the command-line or some other mechanism (e.g., envvar, 
config file, etc.), but that if the value cannot be found in either situation, 
argparse fails saying the value is missing. This is different from a default 
value and making something optional as argparse has no way to signal that a 
default value isn't available, forcing the user to do the actual check 
externally to argparse itself. All of this stems from the fact that argparse's 
default argument stuff happens prior to parsing sys.argv and determining what 
is missing.

What this probably requires is a new keyword-only argument like `fallback` 
which is a callable which is only called if an accompanying value isn't found 
from sys.argv and which can raise some specific exception to signal that the 
fallback value couldn't be determined on top of missing from sys.argv.

--
nosy: +brett.cannon
stage:  -> test needed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26389] Expand traceback module API to accept just an exception as an argument

[Brett Cannon]

Brett Cannon added the comment:

So Terry's right that in my haste to write down the idea I contradicted myself. 
I do want to tweak the APIs in the traceback module to accept only an 
exception. The question is whether we need entirely new functions or if the 
pre-existing ones can be updated to work with just an exception.

And if we were to tweak the existing functions instead of add new ones, I would 
do it by making all arguments optional and adding a new keyword-only argument 
called `exc` that took the exception. Either `exc` would be set or the old 
arguments would need to all be set, and it would be an error to set both sets 
of arguments. And when the old arguments were taken away then all arguments for 
those functions would become keyword-only.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26336] Expose regex bytecode as attribute of compiled pattern object

[Jonathan Goble]

Jonathan Goble added the comment:

Noting for the record that, as I had brought up on python-ideas [1], in 
addition to simply exposing the raw code, it would be nice to have a public 
constructor for the compiled pattern type and a 'dis'-like module for support. 
The former would enable optimizers, and the latter would simplify programmatic 
analysis.

[1] 
https://mail.python.org/pipermail/python-ideas/2016-February/thread.html#38488

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26394] argparse: Add set_values() function to complement set_defaults()

[Michael Herold]

New submission from Michael Herold:

argparse has at least three features to set defaults (default=, set_defaults(), 
 argument_default=). However, there is no feature to set the values of 
arguments.

The difference is, that a required argument has to be specified, also if a 
default value exists. Thus, a clean way to set values from config files or env 
variables does not exist without making all arguments optional.

See for example 
,
 where it becomes clear that no general solution for all actions exists. As a 
result, people also start to mess around with the args parameter of 
parse_args(). Even ConfigArgParse (used by Let's Encrypt) seems to fail in 
doing this properly.

So please add a set_values() function, similar to set_defaults(). The 
predefined value should be treated as if it had been entered on the command 
line. If the value has also been supplied via the command line, the predefined 
value is overwritten.

--
components: Library (Lib)
messages: 260568
nosy: quabla
priority: normal
severity: normal
status: open
title: argparse: Add set_values() function to complement set_defaults()
type: enhancement
versions: Python 3.5

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4928] Problem with tempfile.NamedTemporaryFile

[Eryk Sun]

Eryk Sun added the comment:

Maybe a note could be added to suggest using a SIGTERM signal handler (e.g. the 
handler could raise a SIGTERM exception):

POSIX: The file will not be deleted if the process is terminated abruptly by a 
signal. A process may register a SIGTERM handler to ensure that the file is 
deleted, but SIGKILL cannot be handled. Windows: the file will be deleted when 
it is closed, even if the process is terminated.

Note that for Windows it is possible to make the file permanent, but it's 
probably not common enough to bother with documenting this. Currently the 
documentation states that "[w]hether the name can be used to open the file a 
second time, while the named temporary file is still open, varies across 
platforms (it can be so used on Unix; it cannot on Windows NT or later)". 
Actually on Windows the file can be opened again while the named temporary file 
is still open. You can use an opener that calls os.open with the O_TEMPORARY 
flag. But the opener can also call _winapi.CreateFile with read, write, and 
delete sharing. If DELETE access is requested this handle can be used to make 
the file permanent via SetFileInformationByHandle.

--
assignee:  -> docs@python
components: +Documentation
nosy: +docs@python, eryksun
versions: +Python 3.5, Python 3.6 -Python 3.1, Python 3.2

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26385] the call of tempfile.NamedTemporaryFile fails and leaves a file on the disk

[SilentGhost]

SilentGhost added the comment:

Here is the updated patch including fixes for except and order of deletion.

--
Added file: http://bugs.python.org/file41979/issue26385_3.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26385] the call of tempfile.NamedTemporaryFile fails and leaves a file on the disk

[Eryk Sun]

Eryk Sun added the comment:

> By your explanation, it sounds like it would be better 
> to call unlink() before close().

Sorry, I was responding in general, because I thought you meant unlink would 
fail like it would for most open files on Windows, because the CRT normally 
doesn't open files with delete sharing. But I see what you meant now. Yes, the 
order needs to be reversed as unlink() and then close() for this to work. Doing 
the close first does raise a FileNotFoundError.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26392] socketserver.BaseServer.close_server should stop serve_forever

[Aviv Palivoda]

Aviv Palivoda added the comment:

I see your point about the server_close purpose and I changed the patch to 
simulate the behavior of closed file (raising ValueError when operating on 
closed file).
I don't think that this should be an enhancement as what i try to do is return 
the behavior as it was before the change to the selectors module. When closing 
the socket using server_close at the next serve_forever loop you would have 
gotten ValueError for bad file descriptor to select. In the current 
implementation we actually keep on pulling on a already free resource.
I know that the user should call shutdown before the server_close but i think 
that as you said the behavior should simulate closed file. When someone will 
try to use any other function of a closed file he will receive a ValueError.

--
Added file: 
http://bugs.python.org/file41978/socketserver_close_stop_serve_forever2.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26221] awaiting asyncio.Future swallows StopIteration

[Ian Kelly]

Ian Kelly added the comment:

Chris Angelico suggested on python-list that another possibly useful thing to 
do would be to add a "from __future__ import generator_stop" to 
asyncio/futures.py. This would at least have the effect of causing "await 
future" to raise a RuntimeError instead of silently returning None if a 
StopIteration is set on the future. Future.__iter__ is the only generator in 
the file, so this change shouldn't have any other effects.

--
title: asynco run_in_executor swallows StopIteration -> awaiting asyncio.Future 
swallows StopIteration

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue13354] tcpserver should document non-threaded long-living connections

[Bas Wijnen]

Bas Wijnen added the comment:

Thank you for your fast response as well.

I overlooked that paragraph indeed.  It doesn't mention anything about avoiding 
a socket shutdown however.  Keeping a list of requests isn't very useful if all 
the sockets in the list are closed. ;-)

So I would indeed suggest an addition: I would change this paragraph:

These four classes process requests synchronously; each request must be 
completed before the next request can be started. This isn’t suitable if each 
request takes a long time to complete, because it requires a lot of 
computation, or because it returns a lot of data which the client is slow to 
process. The solution is to create a separate process or thread to handle each 
request; the ForkingMixIn and ThreadingMixIn mix-in classes can be used to 
support asynchronous behaviour.

into:

By default, these four classes process requests synchronously; each request 
must be completed before the next request can be started. This isn’t suitable 
if each request takes a long time to complete, because it requires a lot of 
computation, or because it returns a lot of data which the client is slow to 
process, or because the information that should be sent to the client isn't 
available yet when the request is made. One possible solution is to create a 
separate process or thread to handle each request; the ForkingMixIn and 
ThreadingMixIn mix-in classes can be used to support asynchronous behaviour. 
Another option is to store the socket for later use, and disable the shutting 
down of the socket by overriding process_request with an function that only 
calls finish_request, and not shutdown_request. In that case, the socket must 
be shut down by the program when it is done with it.

At the end of the last paragraph you refer to, it should also be mentioned that 
the program must do something to prevent the socket from being shut down.  In 
the description of process_request, it would probably also be useful to add 
that the default implementation (as opposed to *MixIn) calls shutdown_request() 
after finish_request().

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com