date:20160220

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

2016-02-20 Thread 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

Re: How the heck does async/await work in Python 3.5

2016-02-20 Thread Paul Rubin

Steven D'Aprano  writes:
> "But frankly the stuff I'm seeing in this thread makes me sad for
> *literally every programming language in existence except for Erlang
> and maybe one or two others*, which altogether about six people use in
> total..."

Erlang microtasks are more a matter of the runtime environment than the
language.  It might be possible to have something like it in PyPy.

Other languages typically do concurrency with something like:

  1. threads - various hazards that can be avoided if you're careful
  2. callback chaining like in node.js - gets messy if the program
 is complicated, but conceptually simple
  3. explicit state machines with something like libevent in C --
 same as #2, simple but tedious
  4. lightweight threads/tasks like in GHC and Erlang -- very nice though
 requires a sophisticated runtime system
  5. cooperative multasking (small RTOS's, Forth, etc): simple, but
 apparently bug-prone when the program gets complicated

Python's async stuff seems to combine various of the above approaches
and (while I'm not saying it's objectively bad) the experiences I've had
with it so far have been confusing and unpleasant.  I do want to put
some effort into understanding asyncio, but so far threads have worked
ok for me.

OK Web Server (uses a separate C++ process for each page on the site)
looked straightforward and fast, though makes some architectural
impositions.

http://seastar-project.org/ seems interesting but I don't understand it
at the moment.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Considering migrating to Python from Visual Basic 6 for engineering applications

2016-02-20 Thread Larry Hudson via Python-list

On 02/20/2016 10:38 AM, wrong.addres...@gmail.com wrote:
[snip]

How complicated could this get in Python? Reading the numbers is one thing, and
then placing the values in text boxes of the GUI.

If that is the only object of using these values, there is no conversions necessary. The data
is read as text (strings), and you could simply write them directly into the text boxes. Of
course, this is unlikely -- you surely want the actual numeric values for other purposes. As
already pointed out, if you know in advance what the data types are, the necessary conversions
are trivial. Just slightly more complex if you don't know the types in advance.

OTOH, the conversion from int or float back to strings is also trivial. It's as simple as
writing str(n), where n is an int OR a float -- it works automatically with either. (Data
typing in Python is dynamic, you generally don't need to specify the types.) But if you want
the strings to be in a specific format, this is also possible with a different syntax that lets
you specify the output format. As an example, assume the variable val is 1.97834, and the
formatting string is "${:.2f}".format(val) -- this will give you the string '$1.98'. This
expression breaks down to:

$ -> a literal dollar sign
{} -> a placeholder, it is where the formatted data will be put
: -> what follows is formatting code
.2 -> round to, and print, two decimal places
f -> the data is a float
.format(val) -> the data to format

BTW, this leaves the variable val unchanged -- it is NOT rounded, it still holds its original
precision. It only affects how it is displayed. You CAN round it if you want, but that's an
entirely different function.

Naturally, learning all the formatting codes takes some effort, but it allows defining the
appearance of the resulting strings in a very detailed and complete manner. [Aside: this is
the "new" formatting method. Python also supports an "old" method, which is very much like the
way strings are formatted in the C language.]

Or can I write my own reading subroutines which can then be called like
ReadVBstyle 8, ND, NIN, NT
to make the code more readable?

ABSOLUTELY!! Most Python programming consists of defining the functions and classes needed,
which definitely makes Python more readable. (Classes imply Object Oriented Programming.
Python _allows_ OOP but does not _require_ it -- and is irrelevant here. Ignore anything I say
about classes and OOP!) For your example here, it wouldn't _match_ the BASIC syntax, but would
be used in an equivalent way.

In fact, if you find yourself writing functions (or classes) that could be general-purpose
routines, it is a trivial matter to put them into a personal library which you can then use in
future programs. You don't need to rewrite them, just use them.

Now, in practice, it takes a little care to write them as library functions. That is, the
original version may rely on some details of the original program, so the library version will
need to be tweaked a bit to remove these 'local' dependencies. But this is generally easily
handled through the parameters to the functions. Also they are probably written with a bit more
care to handle error conditions (which Python calls exceptions, Python has very extensive
exception handling). This capability (a personal library) is enormously convenient. While I am
saying 'personal', I really mean library(s) available to everyone involved in a programming
project. No need for anyone to re-invent the wheel! ;-)Python calls them modules rather
than libraries, but it's the same thing.

77 matches

Mail list logo