date:20171102

On Thu, Nov 2, 2017 at 12:42 PM, bartc  wrote:
> But if people prefer a different keyword, then why not? I think 'then' can
> be used, without impacting its use as an identifier, because it will always
> be followed by ":". Of course you would need to allow both "else" and "then"
> for backwards compatibility.

No, it can't. Contextually-sensitive keywords are a road to major
confusion. It's been done before, but usually (always?) as a migration
plan towards full keyword status; most recently, 'async' and 'await'
were brought in that way:

Python 3.5.3 (default, Jan 19 2017, 14:11:04)
[GCC 6.3.0 20170118] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> async def foo():
...  pass
...
>>> async = 1
>>>

Python 3.7.0a2+ (heads/master:4f469c0966, Nov  2 2017, 18:04:12)
[GCC 6.3.0 20170516] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> async def foo():
...  pass
...
>>> async = 1
  File "", line 1
async = 1
  ^
SyntaxError: invalid syntax

>From Python 3.4 to Python 3.7, async changes from being an identifier
to being a keyword. The only reason it's a "soft keyword" for 3.5 and
3.6 is for the sake of transition - it's not a means of avoiding the
costs of keyword creation. The proposal for async functions had to
justify the creation of two keywords.

Additionally, the notion of having both "else" and "then" is even
worse: everyone has to learn BOTH keywords, and figure out when to use
each. For compatibility with older Python versions, most people will
use "else", but some will go with "then" because it's the new and
trendy option.

Ugh. I deal with this sort of thing in JavaScript. I don't want to
have it in Python too.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: install on host not connected to the internet and no local proxy

On Thu, Nov 2, 2017 at 5:50 PM, Noah  wrote:
> Hi,
>
> I am trying to install a python package with about 80 dependencies on a
> server that is not connected to the internet and has no local proxy.  I can
> ssh to it via VPN.
>
> I was able to find python bundle and download the tarballs for all the main
> python package and all the tarballs for the subsequent dependencies.They
> reside in the same directory on the isolated server.
>
> Does anybody have some recommendations on how to install the main package
> and that process triggers the installation of all the dependencies from
> their corresponding tar.gz file?  I cant seem to figure out how to do that
> easily with pip.

Hmm. The first thing that comes to my mind is a virtual environment.
I'm assuming here that you have a local system that has the same CPU
architecture and Python as the main server, and which *does* have an
internet connection; if that's not the case, it'll be more
complicated. But in theory, this should work:

local$ python3 -m venv env
local$ source env/bin/activate
local$ pip install -r requirements.txt

At this point, you have a directory called "env" which contains all
the packages listed in your requirements.txt file (you DO have one of
those, right?) and everything those packages depend on. Then SSH to
your server, and set up an equivalent environment:

server$ python3 -m venv env
server$ source env/bin/activate

Copy in the contents of env/lib/pythonX.Y/site-packages (where X.Y is
your Python version, eg python3.7 on my system), and then try
importing stuff. In theory, you should be able to load everything in
just fine.

If that doesn't work, you might have to manually run setup.py for each
of your eighty dependencies, and possibly all of their dependencies
too. I'd definitely try the venv transfer before going to that level
of tedium.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: replacing `else` with `then` in `for` and `try`

2017-11-02 Thread Alexey Muranov


On Thu, 2017-11-02 at 08:29 +1100, Chris Angelico wrote:
> On Thu, Nov 2, 2017 at 8:23 AM, Ned Batchelder 

> > wrote:

> >
> >
> > Apart from the questions of backward compatibility etc (Python is
> > unlikely
> > to ever go through another shift like the 2/3 breakage), are you
> > sure "then"
> > is what you mean?  This won't print "end":
> >
> > for i in range(10):
> > print(i)
> > else:
> > print(end)

>
> Well, it'll bomb with NameError when it tries to look up the *name*
> end. But it will run that line of code - if you quote it, it will
> work.


You see how people are confused over "for ... else".

Alexey.

--
https://mail.python.org/mailman/listinfo/python-list

Re: replacing `else` with `then` in `for` and `try`

2017-11-02 Thread Alexey Muranov

On Wed, 2017-11-01 at 21:30 +, Stefan Ram wrote:

>
>   In languages like Algol 68, »then« is used for a clause
>   that is to be executed when the main condition of an
>   if-statement /is/ true, so this might cause some confusion.
>

sure, and `else` is used for a clause that is to be executed when the 
main condition of `if` is false.

So, in

   try:
   do_something
   except:
   catch_exception
   else:
   continue_doing_something

when no exception occurs in `do_something`, is `do_something` more 
true, or more false?

Alexey.

--
https://mail.python.org/mailman/listinfo/python-list

Re: replacing `else` with `then` in `for` and `try`


On 11/1/2017 5:12 PM, Alexey Muranov wrote:

what do you think about the idea of replacing "`else`" with "`then`" in 
the contexts of `for` and `try`?


This idea has been argued to death more than once before.  I am opposed 
on both logical and practical grounds, but will not repeat myself for 
the fourth or fifth time.


--
Terry Jan Reedy

--
https://mail.python.org/mailman/listinfo/python-list

Re: replacing `else` with `then` in `for` and `try`

2017-11-02 Thread Alexey Muranov

On Thu, 2017-11-02 at 08:21 +1100, Chris Angelico wrote:

>
>
With try/except/else, it's "do this, and if an exception happens, do 
this, else do this". So else makes perfect sense.

Indeed, i forgot about `except`.  I agree that 
"try/then/except/finally" would be better than 
"try/except/then/finally", but "try/except/else/finally" does not make 
a perfect sense IMHO.

Alexey.

--
https://mail.python.org/mailman/listinfo/python-list

Re: replacing `else` with `then` in `for` and `try`

On Thu, Nov 2, 2017 at 7:05 PM, Alexey Muranov  wrote:
> On Wed, 2017-11-01 at 21:30 +, Stefan Ram wrote:
>>
>> >
>> >   In languages like Algol 68, »then« is used for a clause
>> >   that is to be executed when the main condition of an
>> >   if-statement /is/ true, so this might cause some confusion.
>> >
>
>
> sure, and `else` is used for a clause that is to be executed when the main
> condition of `if` is false.
>
> So, in
>
>try:
>do_something
>except:
>catch_exception
>else:
>continue_doing_something
>
> when no exception occurs in `do_something`, is `do_something` more true, or
> more false?

It's neither. It didn't happen. That's the whole point of exceptions -
they aren't about normal flow and normal values, they are
fundamentally different. But if you like, consider this kind of model:

caught_exception = catch {{{
do_something
}}}
if caught_exception is not None:
handle_exception
else:
continue_doing_something

The caught exception is either a thing, or not a thing.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: replacing `else` with `then` in `for` and `try`

On Thu, 2 Nov 2017 12:49 pm, Skip Montanaro wrote:

> I don't know. The word "then" doesn't connote different ways of exiting a
> loop to me ("else" doesn't really either, I will grant you that, but it's
> what we have). Here's how I would read things:
> 
>- *while* some condition holds, execute the loop, possibly breaking out,
>*then* do some finishing work
>- *for* each element in some sequence, execute the loop, possibly
>breaking out, *then* do some finishing work

And that is exactly the behaviour of the for...else and while...else
construct. You're reading it correctly.

When you say "possibly breaking out", I assume you mean breaking out of the
*entire* compound statement, because the alternative would be just silly. The
alternative would be exactly equivalent to just following the loop with some
unindented code:

while condition:
block
# on break we jump to here
finishing

In that case, it makes no sense to include a do-nothing "else" or "then"
keyword.

To put it another way, if we are trying to infer the semantics of a statement,
and can interpret it in one of two ways:

- it does something

- it does nothing

then (with special case) of `pass`, we should always assume the first case,
thus resolving the ambiguity in favour of "Guido isn't an idiot who added a
pointless keyword" :-)

> In neither case does it seem to me that you execute the finishing work only
> if you break out of the loop, but not if the loop terminates when the while
> condition becomes false or the for loop's sequence is exhausted.

If I'm reading you correctly, I think you are confused about the `else`
clause. It is incorrect to say that the `else` clause runs "only if you break
out of the loop" (as you say). The `else` clause runs *after* the loop
completes, but NOT if you jump out with break/return/raise.

If we don't jump out of the loop, the else block is equivalent to just
following the loop with unindented code:

for x in sequence:
block
else:
follows

is equivalent to:

for x in sequence:
block
follows

Hence, in the absence of any early exit from the loop, the `else` block
behaves more like an *then* rather than an "else". The behaviour of `else`
confused me utterly until I realised that the semantics of the compound
for...else was the loop to execute, then the `else` block.

So why even bother with `else`?

Unlike the second case, the `else` block is part for the compound for/while
statement. And so `break` doesn't just exit the loop, it exits the whole
compound statement, jumping past the `else`:

for x in sequence:
block
else:
follows
# break jumps to here
more code

The motive for allowing this pattern is described here:

https://shahriar.svbtle.com/pythons-else-clause-in-loops

> You might
> consider that while/then or for/then actually reads too much like English,
> fooling you into interpreting it as English, opening you up to ambiguity.

If you interpret it as English, it works fine. You run the loop, then you run
the "then" clause. If you jump out of the loop (whether by return, raise or
break) you jump out of the *entire* statement, not just the loop part.

There's no ambiguity because we can assume Guido wouldn't introduce a
pointless block keyword that does literally nothing except require an indent.

> You might argue that "else" doesn't either, but it has the strangely nice
> property of actually being a bit clumsier to read, forcing the reader to
> learn and apply the precise rules of the programming language instead of
> infer the more ambiguous rules of English.

If only that were true... 

There's a simple, obvious, but sadly WRONG plain English interpretation of
for...else, namely that the `else` clause runs if the for sequence was empty:

for x in L:
pass
else:
# This is wrong!
print("L is empty")

and similar for while. That lead me astray for the longest time! And I'm not
the only one.

> English and other natural languages aren't precise enough to serve as
> programming languages. 

Hmmm... I think Hypertalk might have something to say about that.

And Inform7 I think would laugh in your face :-)

-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

-- 
https://mail.python.org/mailman/listinfo/python-list

A use-case for for...else with no break

Occasionally it is useful to loop over a bunch of stuff in the interactive
interpreter, printing them as you go on a single line:

for x in something():
print(x, end='')

If you do that, the prompt overwrites your output, and you get a mess:


py> for x in "abcdefgh":
... print(x, end='')
...
py> efghpy>


"For ... else" to the rescue!

py> for char in "abcdefgh":
... print(char, end='')
... else:
... print()
...
abcdefgh
py> 




-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: install on host not connected to the internet and no local proxy

2017-11-02 Thread Paul Moore

On 2 November 2017 at 07:17, Chris Angelico  wrote:
> On Thu, Nov 2, 2017 at 5:50 PM, Noah  wrote:
>> Hi,
>>
>> I am trying to install a python package with about 80 dependencies on a
>> server that is not connected to the internet and has no local proxy.  I can
>> ssh to it via VPN.
>>
>> I was able to find python bundle and download the tarballs for all the main
>> python package and all the tarballs for the subsequent dependencies.They
>> reside in the same directory on the isolated server.
>>
>> Does anybody have some recommendations on how to install the main package
>> and that process triggers the installation of all the dependencies from
>> their corresponding tar.gz file?  I cant seem to figure out how to do that
>> easily with pip.
>
> Hmm. The first thing that comes to my mind is a virtual environment.
> I'm assuming here that you have a local system that has the same CPU
> architecture and Python as the main server, and which *does* have an
> internet connection; if that's not the case, it'll be more
> complicated. But in theory, this should work:
>
> local$ python3 -m venv env
> local$ source env/bin/activate
> local$ pip install -r requirements.txt
>
> At this point, you have a directory called "env" which contains all
> the packages listed in your requirements.txt file (you DO have one of
> those, right?) and everything those packages depend on. Then SSH to
> your server, and set up an equivalent environment:
>
> server$ python3 -m venv env
> server$ source env/bin/activate
>
> Copy in the contents of env/lib/pythonX.Y/site-packages (where X.Y is
> your Python version, eg python3.7 on my system), and then try
> importing stuff. In theory, you should be able to load everything in
> just fine.
>
> If that doesn't work, you might have to manually run setup.py for each
> of your eighty dependencies, and possibly all of their dependencies
> too. I'd definitely try the venv transfer before going to that level
> of tedium.

Alternatively, you can do (on your internet-connected system)

mkdir wheels
pip wheel --wheel-directory wheels -r requirements.txt

This will create a set of .whl files in the directory "wheels". You
can copy that directory to the target machine and (assuming the two
machines do have the same architecture/OS) on that machine do

pip install --no-index --find-links wheels -r requirements.txt

This will tell pip to not use PyPI (and so not need the internet) and
to satisfy the requirements using only the wheel files in the "wheels"
directory.

Paul
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: replacing `else` with `then` in `for` and `try`

On Thu, 2 Nov 2017 09:04 pm, Steve D'Aprano wrote:

> then (with special case) of `pass`

That should read "then except for the special case of `pass`".

Sorry.


-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: replacing `else` with `then` in `for` and `try`

2017-11-02 Thread Ben Bacarisse

Steve D'Aprano  writes:

> On Thu, 2 Nov 2017 12:50 pm, Ben Bacarisse wrote:
>
>> Steve D'Aprano  writes:
>> 
>>> On Thu, 2 Nov 2017 08:12 am, Alexey Muranov wrote:
>>>
 what do you think about the idea of replacing "`else`" with "`then`" in
 the contexts of `for` and `try`?
> [...]
>> Re-using finally would not need a new keyword and might be close enough
>> in meaning.
>
> Reusing finally would be *completely* wrong.
>
> The semantics of `finally` is that it should be executed no matter[1] how you
> exit the previous block. E.g. if we write:
>
>
> try:
> return 1
> finally:
> print("exiting")
>
>
> then "exiting" is printed. Replace the return with a raise, and the same
> applies. Reusing `finally` in for and while loops would imply the similar
> behaviour:
>
>
> for i in range(100):
> return i
> finally:
> print("exiting")
>
>
> should print "exiting", when in fact it does not. Likewise if you replace the
> return with a break.

Sure, but your argument seemed to that else has entirely the wrong
meaning (I certainly to a double take when I have to remember what it
means) and, in that context, finally has a meaning closer to what you
want.  The problem that it carries different meanings when added to
different statements is already the case with else -- it's an
alternative to an if and not an alternative to a loop.


-- 
Ben.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: replacing `else` with `then` in `for` and `try`

On Thu, 2 Nov 2017 10:09 pm, Ben Bacarisse wrote:

> Sure, but your argument seemed to that else has entirely the wrong
> meaning (I certainly to a double take when I have to remember what it
> means) and, in that context, finally has a meaning closer to what you
> want.

That's an argument about whether "yellow" or "purple" is closer in meaning to
the word we actually want, "spicy" :-)



-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: right list for SIGABRT python binary question ?

2017-11-02 Thread Karsten Hilbert

On Wed, Nov 01, 2017 at 04:28:02PM +, Grant Edwards wrote:

> >>I understand. Thank you for the explanation. This may seem
> >>like a dumb question: the actual address that gets corrupted
> >>varies from run to run (it may be the same "place" in the
> >
> > Since the process virtual memory space should be the same on each run
> 
> Not with modern OS kernels:
> 
> https://en.wikipedia.org/wiki/Address_space_layout_randomization

I feared as much. However, I discovered that during
subsequent runs the address seems stable due to shared
libraries being preloaded: On the first run the affected code
is loaded at some randomized address and the corruption is
hit at a certain address giving me the value to watch on
during subsequent runs, as long as the affected code is not
evicted from being preloaded the address is stable.

I have posted backtraces taken from the address being
watched. Does that help any at all ?

Thanks,
Karsten
-- 
GPG key ID E4071346 @ eu.pool.sks-keyservers.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346
-- 
https://mail.python.org/mailman/listinfo/python-list

Rise of Iot Application Has Opened a Potential Avenue of Application for Mobility Sharing Market 2025

2017-11-02 Thread sayalitip

FREE| Sample Copy is available at https://tinyurl.com/ybhr3gaj

Mobility sharing is a term that is used to describe the transportation services 
that are shared among users. This includes public transit, taxis and limos, 
bike sharing, car sharing, ride sharing, scooter sharing, shuttle services 
among others. Increasing demographics is one of the major driver for the growth 
of the mobility sharing market.Consumer culture and scarce of resources are 
some of the factors that are driving the growth of these market in the coming 
years.
Some of the key players influencing the market are Robert Bosch GmbH, Uber 
Technologies Inc., Spinlister, Lyft, Tamyca GmbH, Delphi Automotive GmbH, Denso 
Corporation, Intel Corporation, Tomtom NV and Didi Chuxing.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: A use-case for for...else with no break

2017-11-02 Thread Alberto Berti

> "Steve" == Steve D'Aprano  writes:

py> for x in "abcdefgh":
Steve> ... print(x, end='')
Steve> ...
py> efghpy>


Steve> "For ... else" to the rescue!

py> for char in "abcdefgh":
Steve> ... print(char, end='')
Steve> ... else:
Steve> ... print()
Steve> ...
Steve> abcdefgh
py> 

else doesn't seem to bring any advantage over:

for char in "abcdefgh":
print(char, end='')
print()

-- 
https://mail.python.org/mailman/listinfo/python-list

Reading a remove csv file

2017-11-02 Thread ROGER GRAYDON CHRISTMAN

 Just a quick question on how best to read a remote CSV file.
So far, I tried:

filelink = urllib.request.urlopen(path)
dictread = csv.DictReader(filelink)
for row in dictread:...
But I'm running into the difference between strings and bytes.
I'd like to squeeze a note that talks about the utf-8 encoding,
but although I find that as an option for a local file (with open())
I did not see that on my first glance at the two functions above.

Is there an easy way to read a remove CSV file with utf-8 encoding
without copying the whole file locally first?

Roger Christman
Pennsylvania State University
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: A use-case for for...else with no break

2017-11-02 Thread Wolfgang Maier


On 11/02/2017 12:45 PM, Alberto Berti wrote:

"Steve" == Steve D'Aprano  writes:


 py> for x in "abcdefgh":
 Steve> ... print(x, end='')
 Steve> ...
 py> efghpy>


 Steve> "For ... else" to the rescue!

 py> for char in "abcdefgh":
 Steve> ... print(char, end='')
 Steve> ... else:
 Steve> ... print()
 Steve> ...
 Steve> abcdefgh
 py>

else doesn't seem to bring any advantage over:

for char in "abcdefgh":
 print(char, end='')
print()



Try running it interactively and you'll see,
wolfgang

--
https://mail.python.org/mailman/listinfo/python-list

Re: replacing `else` with `then` in `for` and `try`

2017-11-02 Thread Ben Bacarisse

Steve D'Aprano  writes:

> On Thu, 2 Nov 2017 10:09 pm, Ben Bacarisse wrote:
>
>> Sure, but your argument seemed to that else has entirely the wrong
>> meaning (I certainly to a double take when I have to remember what it
>> means) and, in that context, finally has a meaning closer to what you
>> want.
>
> That's an argument about whether "yellow" or "purple" is closer in meaning to
> the word we actually want, "spicy" :-)

I note the smiley, but it was in fact an argument that "finally" is
closer to "and afterwards" than "else" is :-)

-- 
Ben.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Code Snippets

2017-11-02 Thread Rhodri James


On 01/11/17 18:57, Stefan Ram wrote:

Ned Batchelder  writes:

You should not optimize for the shortest time to paste a line of code.Â
You should take time and care writing your code, so that it reads best
and runs best.Â  If you needed another os function, would you have two
__import__("os") in your code? Ugh.


   I make a distinction between two kinds of code:

   1.) Quick-and-dirty code (rapid prototyping)

   One just wants to find out something using Python code.
   The code might be written into the Shell and not be saved,
   or only be saved temporarily. For example, what the sum of
   5412 and 2141 is, or whether an idea for a program code
   works at all.

   The snippets are also intended for such code.

   2.) Library-grade code

   This is code that might be around for a longer time and
   might be maintained in the future. It even is possible that
   it will become part of a library.

   It is possible that qnd-code might evolve into lg-code.
   In this case, it is still possible to remove all »__imports__«.

   Your comments might apply more to lg-code than to qnd-code.


The bad thing here is that you are training yourself in a coding style 
(quick and dirty) that ought to be rejected in any code that isn't 
completely ephemeral.  And in my experience, most "throw-away" code 
isn't thrown away.


--
Rhodri James *-* Kynesim Ltd
--
https://mail.python.org/mailman/listinfo/python-list

Re: A use-case for for...else with no break

2017-11-02 Thread Alberto Berti

> "Wolfgang" == Wolfgang Maier  
> writes:

   Wolfgang> Try running it interactively and you'll see,
   Wolfgang> wolfgang

I've tried but my muscolar memory failed me... i've issued a C-c C-c
that usually would have sent the region of text to the interpreter
session (when done from python-mode opened files in emacs)  but instead
i was in gnus and it sent the half prepared email :-)

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: matplot plot hangs

2017-11-02 Thread Tim Williams

On Wednesday, November 1, 2017 at 6:30:27 PM UTC-4, Andrew Z wrote:
> nope. it doesnt:
> 
> I added print-s after each line and that produced:
> [az@hp src]$ cat ./main1.py
> import matplotlib.pyplot as plt
> print("imported")
> plt.plot([1,2,4,1])
> print("plot is done")
> plt.show()
> print("show is done")
> 
> [az@hp src]$ python3.5 ./main1.py
> imported
> ^C^Z
> [1]+  Stopped python3.5 ./main1.py
> 
> 
> On Wed, Nov 1, 2017 at 9:31 AM, Vlastimil Brom 
> wrote:
> 
> > 2017-11-01 13:49 GMT+01:00 Andrew Z :
> > > Wolfgang,
> > >  I tried to ran from ide with no rwsults, so now im trying from a
> > terminal
> > > in xwindow.
> > > The .plot is the last line in the script and it does hang trying to
> > execute
> > > it.
> > >
> > >
> > > On Nov 1, 2017 05:44, "Wolfgang Maier" <
> > > [email protected]> wrote:
> > >
> > > On 01.11.2017 00:40, Andrew Z wrote:
> > >
> > >> hello,
> > >>   learning python's plotting by using matplotlib with python35 on
> > fedora 24
> > >> x86.
> > >>
> > >> Installed matplotlib into user's directory.
> > >> tk, seemed to work -
> > >> http://www.tkdocs.com/tutorial/install.html#installlinux - the window
> > >> shows
> > >> up just fine.
> > >> but when trying to run the simple plot (
> > >> https://matplotlib.org/examples/pylab_examples/simple_plot.html) the
> > >> script
> > >> is hanging on;
> > >>
> > >> plt.plot(t, s)
> > >>
> > >> attempts to
> > >> matplotlib.interactive(True) didn't bring anything,
> > >>
> > >>
> > > Hi Andrew,
> > >
> > > From which environment are you trying to run the example? In the
> > terminal,
> > > from within some IDE, inside a jupyter notebook?
> > >
> > > Are you sure the script "is hanging on plt.plot(t, s)" and not after
> > that?
> > >
> > > Best,
> > > Wolfgang
> > >
> > > --
> > Hi,
> > sorry if it is too trivial, just to make sure, do you have a call to
> > "show()" the resulting plot in the code?
> >
> > An elementary plotting code might be e.g.:
> >
> > import matplotlib.pyplot as plt
> > plt.plot([1,2,4,1])
> > plt.show()
> >
> > Does this work in your environment?
> >
> > It was not quite clear, what do you plan with interactive drawing, or
> > whether you are using e.g. plt.interactive(True) already - this might
> > be a problem as there could be collisions or the plot window is closed
> > after the standalone script finishes.
> >
> > hth,
> >  vbr
> > --
> > https://mail.python.org/mailman/listinfo/python-list
> >

Have you tried 

plt.show(block=False)
?
-- 
https://mail.python.org/mailman/listinfo/python-list

Worldwide Latest new Feature Automotive Power Electronics 2017 by Technology and news

2017-11-02 Thread karishmamtip

Automotive Power Electronics are the devices installed and used for controlling 
the high voltage and converting varied electric power in a most proficient way. 
These devices also helps in monitoring a power consumption in an optimized 
manner. One of the major driver for the growth of Automotive Power Electronics 
market is the rapid growth in the electric vehicles owing to the reasons that 
electric vehicle use batteries and doesn't harm the environment.

FREE Sample Copy is Available  https://tinyurl.com/yb5guadz


Important Market Players : Infineon Technologies AG, Renesas Electronics 
Corporation, Vishay Intertechnology Inc., Robert Bosch GmbH, Mitsubishi 
Electric Corporation, Qualcomm Technologies Inc., ON Semiconductor Corporation, 
NXP Semiconductors, GAN Systems Inc., and Rohm Corporation ltd.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: A use-case for for...else with no break

On Thu, 2 Nov 2017 10:45 pm, Alberto Berti wrote:

>> "Steve" == Steve D'Aprano  writes:
> 
> py> for x in "abcdefgh":
> Steve> ... print(x, end='')
> Steve> ...
> py> efghpy>
> 
> 
> Steve> "For ... else" to the rescue!
> 
> py> for char in "abcdefgh":
> Steve> ... print(char, end='')
> Steve> ... else:
> Steve> ... print()
> Steve> ...
> Steve> abcdefgh
> py>
> 
> else doesn't seem to bring any advantage over:
> 
> for char in "abcdefgh":
> print(char, end='')
> print()

Have you tried it in the interactive interpreter?


py> for char in "abcdefgh":
... print(char, end='')
... print()
  File "", line 3
print()
^
SyntaxError: invalid syntax




-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

-- 
https://mail.python.org/mailman/listinfo/python-list

Worldwide Latest new Feature Automotive Power Electronics 2017 by Technology and news

2017-11-02 Thread karishmamtip

Automotive Power Electronics are the devices installed and used for controlling 
the high voltage and converting varied electric power in a most proficient way. 
These devices also helps in monitoring a power consumption in an optimized 
manner. One of the major driver for the growth of Automotive Power Electronics 
market is the rapid growth in the electric vehicles owing to the reasons that 
electric vehicle use batteries and doesn't harm the environment.

FREE Sample Copy is Available  https://tinyurl.com/yb5guadz


Important Market Players : Infineon Technologies AG, Renesas Electronics 
Corporation, Vishay Intertechnology Inc., Robert Bosch GmbH, Mitsubishi 
Electric Corporation, Qualcomm Technologies Inc., ON Semiconductor Corporation, 
NXP Semiconductors, GAN Systems Inc., and Rohm Corporation ltd.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Reading a remove csv file

2017-11-02 Thread Peter Otten

ROGER GRAYDON CHRISTMAN wrote:

>  Just a quick question on how best to read a remote CSV file.
> So far, I tried:
> 
> filelink = urllib.request.urlopen(path)
> dictread = csv.DictReader(filelink)
> for row in dictread:...
> But I'm running into the difference between strings and bytes.
> I'd like to squeeze a note that talks about the utf-8 encoding,
> but although I find that as an option for a local file (with open())
> I did not see that on my first glance at the two functions above.
> 
> Is there an easy way to read a remove CSV file with utf-8 encoding
> without copying the whole file locally first?

Try wrapping the resqponse, it should be sufficiently file-like:

response = urllib.request.urlopen(...)
stream = io.TextIOWrapper(response, newline="", encoding="utf-8")
rows = csv.DictReader(stream)


-- 
https://mail.python.org/mailman/listinfo/python-list

FW: Reading a remove csv file

2017-11-02 Thread ROGER GRAYDON CHRISTMAN

I have a partial answer to my own question:
This seems to work for me:

---
link = urllib.request.urlopen(urlpath)
data = link.read().decode('utf-8').split('\n')

reader = csv.DictReader(data)
for row in reader:
---

I think here my concern is that now 'data' is now a variable
in my program's memory (all of the data),
instead of streamlike.   I suppose I did read
somewhere about setting a stream option.

Roger Christman
Pennsylvania State University

 Forwarded Message 


 Just a quick question on how best to read a remote CSV
file.


So far, I
tried:




filelink =
urllib.request.urlopen(path)


dictread =
csv.DictReader(filelink)


for row in
dictread:
...


But I'm running
into the difference between strings and bytes.


I'd
like to squeeze a note that talks about the utf-8
encoding,


but although I find that as an option for a
local file (with open())


I did not see that on my
first glance at the two functions
above.




Is there an easy way to read a
remove CSV file with utf-8 encoding


without copying
the whole file locally first?




Roger
Christman


Pennsylvania State University
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: replacing `else` with `then` in `for` and `try`

2017-11-02 Thread Jerry Hill

On Wed, Nov 1, 2017 at 5:12 PM, Alexey Muranov 
wrote:

> what do you think about the idea of replacing "`else`" with "`then`" in
> the contexts of `for` and `try`?
>

I wish the core python developers had done it 20 years ago.  Given that
python is a relatively mature language at this point, I don't expect that
it will ever change.

-- 
Jerry
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: replacing `else` with `then` in `for` and `try`

2017-11-02 Thread Jon Ribbens

On 2017-11-01, Alexey Muranov  wrote:
> what do you think about the idea of replacing "`else`" with "`then`" in 
> the contexts of `for` and `try`?
>
> It seems clear that it should be rather "then" than "else."  Compare 
> also "try ... then ... finally" with "try ... else ... finally".
>
> Currently, with "else", it is almost impossible to guess the meaning 
> without looking into the documentation.

Why would we want to make the language worse? It is fairly obvious
what 'else' means, whereas 'then' has an obvious meaning that is in
fact the opposite of what it would actually do. It seems clear that
'else' is the correct word (or at least, far better than 'then').

Maybe the change should be that it is a syntax error to use a
'for/while...else' with no 'break'.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: replacing `else` with `then` in `for` and `try`

2017-11-02 Thread breamoreboy

On Wednesday, November 1, 2017 at 9:14:05 PM UTC, Alexey Muranov wrote:
> Hello,
> 
> what do you think about the idea of replacing "`else`" with "`then`" in 
> the contexts of `for` and `try`?
> 
> It seems clear that it should be rather "then" than "else."  Compare 
> also "try ... then ... finally" with "try ... else ... finally".
> 
> Currently, with "else", it is almost impossible to guess the meaning 
> without looking into the documentation.
> 
> Off course, it should not be changed in Python 3, maybe in Python 4 or 
> 5, but in Python 3 `then` could be an alias of `else` in these contexts.
> 
> Alexey.

It has been discussed before.  I believe the chances of it ever happening are 
roughly zero.

There's a good write up on the subject here 
http://python-notes.curiousefficiency.org/en/latest/python_concepts/break_else.html

--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence
-- 
https://mail.python.org/mailman/listinfo/python-list

Python Packages Error - Unresolved

2017-11-02 Thread Hinds, Megan

Hi there,

I was hoping you could help, as I have tried many different websites on this
query and even asked the question on stackflow. I have tried many different
types of commands in command prompt with the same error.

I have recently installed Python 3.6. The 32 bit installation (automatically
downloaded to this). I have set the correct environment path variables:
C:\Users\MH\AppData\Local\Programs\Python\Python36-32;C:\Users\MH\AppData\Local\Programs\Python\Python36-32\Scripts;

I am on a work laptop with admin rights.

A few days ago I could install python packages using the following command in
command prompt (in python36-32 directory):

pip install -index-url=http://pypi.python.org/simple -trusted-host
pypi.python.org pandas

I managed to install pillow, cx_Oracle, and a few others previously. But not
pandas and others (see attached file).

I was thinking to move on to anaconda, however, I may see the same error in
installing packages in there (Oracle related packaged that are not in conda).

I would be very grateful for any help.

Thanks,

Megan Hinds

Information in this e-mail and any attachments is confidential, and may not be
copied or used by anyone other than the addressee, nor disclosed to any third
party without our permission. There is no intention to create any legally
binding contract or other binding commitment through the use of this electronic
communication unless it is issued in accordance with the Experian Limited
standard terms and conditions of purchase or other express written agreement
between Experian Limited and the recipient. Although Experian has taken
reasonable steps to ensure that this communication and any attachments are free
from computer viruses, you are advised to take your own steps to ensure that
they are actually virus free.

Experian Ltd is authorised and regulated by the Financial Conduct Authority.
Companies Act information: Registered name: Experian Limited. Registered
office: The Sir John Peace Building, Experian Way, NG2 Business Park,
Nottingham, NG80 1ZZ, United Kingdom. Place of registration: England and Wales.
Registered number: 653331.
--
https://mail.python.org/mailman/listinfo/python-list

Re: Python Packages Error - Unresolved

2017-11-02 Thread Rhodri James


On 02/11/17 11:17, Hinds, Megan wrote:

Hi there,

I was hoping you could help, as I have tried many different websites on this 
query and even asked the question on stackflow. I have tried many different 
types of commands in command prompt with the same error.

I have recently installed Python 3.6. The 32 bit installation (automatically 
downloaded to this). I have set the correct environment path variables: 
C:\Users\MH\AppData\Local\Programs\Python\Python36-32;C:\Users\MH\AppData\Local\Programs\Python\Python36-32\Scripts;

I am on a work laptop with admin rights.

A few days ago I could install python packages using the following command in 
command prompt (in python36-32 directory):


pip install -index-url=http://pypi.python.org/simple  -trusted-host 
pypi.python.org pandas


I managed to install pillow, cx_Oracle, and a few others previously. But not 
pandas and others (see attached file).

I was thinking to move on to anaconda, however, I may see the same error in 
installing packages in there (Oracle related packaged that are not in conda).

I would be very grateful for any help.


I'm afraid the mailing list has stripped your attachments (as well it 
should, since this is also a newsgroup).  Could you repeat them in the 
body of your message?  If they include the exact error messages and any 
traceback, that would be a great help.


--
Rhodri James *-* Kynesim Ltd
--
https://mail.python.org/mailman/listinfo/python-list

Re: replacing `else` with `then` in `for` and `try`

On Fri, 3 Nov 2017 12:39 am, Jon Ribbens wrote:

> On 2017-11-01, Alexey Muranov  wrote:
>> what do you think about the idea of replacing "`else`" with "`then`" in
>> the contexts of `for` and `try`?
>>
>> It seems clear that it should be rather "then" than "else."  Compare
>> also "try ... then ... finally" with "try ... else ... finally".
>>
>> Currently, with "else", it is almost impossible to guess the meaning
>> without looking into the documentation.
> 
> Why would we want to make the language worse? It is fairly obvious
> what 'else' means, 

Yes, obvious and WRONG.

for x in seq:
do_something()
else:
print("seq was empty")

is an obvious, common and wrong interpretation.

> whereas 'then' has an obvious meaning that is in 
> fact the opposite of what it would actually do.

Er... is today opposite day? Because 'then' describes precisely what it
actually does.

Perhaps before we continue, we should ask what you think for...else and
while...else statements do. Just to be sure we are all on the same page here.

> It seems clear that 
> 'else' is the correct word (or at least, far better than 'then').

Not clear at all. The 'for...else' block is a common source of confusion, if
it was clear what it did, people wouldn't so often get it wrong.

> Maybe the change should be that it is a syntax error to use a
> 'for/while...else' with no 'break'.

Only if you want to make the experience of using Python in the interactive
interpreter worse. See my recent post:

"A use-case for for...else with no break"

-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Thread safety issue (I think) with defaultdict

> On Nov 1, 2017, at 4:53 PM, Steve D'Aprano  wrote:
> 
> On Thu, 2 Nov 2017 05:53 am, Israel Brewster wrote:
> 
> [...]
>> So the end result is that the thread that "updates" the dictionary, and the
>> thread that initially *populates* the dictionary are actually running in
>> different processes.
> 
> If they are in different processes, that would explain why the second
> (non)thread sees an empty dict even after the first thread has populated it:
> 
> 
> # from your previous post
>> Length at get AC:  54 ID: 4524152200  Time: 2017-11-01 09:41:24.474788
>> Length At update:  1 ID: 4524152200  Time: 2017-11-01 09:41:24.784399
>> Length At update:  2 ID: 4524152200  Time: 2017-11-01 09:41:25.228853
> 
> 
> You cannot rely on IDs being unique across different processes. Its an
> unfortunately coincidence(!) that they end up with the same ID.

I think it's more than a coincidence, given that it is 100% reproducible. Plus, 
in an earlier debug test I was calling print() on the defaultdict object, which 
gives output like "", where presumably the 
0x1066467f0 is a memory address (correct me if I am wrong in that). In every 
case, that address was the same. So still a bit puzzling.

> 
> Or possibly there's some sort of weird side-effect or bug in Flask that, when
> it shares the dict between two processes (how?) it clears the dict.

Well, it's UWSGI that is creating the processes, not Flask, but that's 
semantics :-) The real question though is "how does python handle such 
situations?" because, really, there would be no difference (I wouldn't think) 
between what is happening here and what is happening if you were to create a 
new process using the multiprocessing library and reference a variable created 
outside that process.

In fact, I may have to try exactly that, just to see what happens.

> 
> Or... have you considered the simplest option, that your update thread clears
> the dict when it is first called? Since you haven't shared your code with us,
> I cannot rule out a simple logic error like this:
> 
> def launch_update_thread(dict):
>dict.clear()
># code to start update thread

Actually, I did share my code. It's towards the end of my original message. I 
cut stuff out for readability/length, but nothing having to do with the 
dictionary in question. So no, clear is never called, nor any other operation 
that could clear the dict.

> 
> 
>> In fact, any given request could be in yet another 
>> process, which would seem to indicate that all bets are off as to what data
>> is seen.
>> 
>> Now that I've thought through what is really happening, I think I need to
>> re-architect things a bit here. 
> 
> Indeed. I've been wondering why you are using threads at all, since there
> doesn't seem to be any benefit to initialising the dict and updating it in
> different thread. Now I learn that your architecture is even more complex. I
> guess some of that is unavailable, due to it being a web app, but still.

What it boils down to is this: I need to update this dictionary in real time as 
data flows in. Having that update take place in a separate thread enables this 
update to happen without interfering with the operation of the web app, and 
offloads the responsibility for deciding when to switch to the OS. There *are* 
other ways to do this, such as using gevent greenlets or asyncio, but simply 
spinning off a separate thread is the easiest/simplest option, and since it is 
a long-running thread the overhead of spinning off the thread (as opposed to a 
gevent style interlacing) is of no consequence.

As far as the initialization, that happens in response to a user request, at 
which point I am querying the data anyway (since the user asked for it). The 
idea is I already have the data, since the user asked for it, why not save it 
in this dict rather than waiting to update the dict until new data comes in? I 
could, of course, do a separate request for the data in the same thread that 
updates the dict, but there doesn't seem to be any purpose in that, since until 
someone requests the data, I don't need it for anything.

> 
> 
>> For one thing, the update thread should be 
>> launched from the main process, not an arbitrary UWSGI worker. I had
>> launched it from the client connection because there is no point in having
>> it running if there is no one connected, but I may need to launch it from
>> the __init__.py file instead. For another thing, since this dictionary will
>> need to be accessed from arbitrary worker processes, I'm thinking I may need 
>> to move it to some sort of external storage, such as a redis database
> 
> That sounds awful. What if the arbitrary worker decides to remove a bunch of
> planes from your simulation, or insert them? There should be one and only one
> way to insert or remove planes from the simulation (I **really** hope it is a
> simulation).

UWSGI uses worker processes to respond to requests from web clients. What can 
and can't be done from a web interface is,

Re: replacing `else` with `then` in `for` and `try`

2017-11-02 Thread Jon Ribbens

On 2017-11-02, Steve D'Aprano  wrote:
> On Fri, 3 Nov 2017 12:39 am, Jon Ribbens wrote:
>> Why would we want to make the language worse? It is fairly obvious
>> what 'else' means, 
>
> Yes, obvious and WRONG.

Nope, obvious and right.

> for x in seq:
> do_something()
> else:
> print("seq was empty")
>
> is an obvious, common and wrong interpretation.

No, it's an obvious bug. You have a 'for...else' with no 'break'.
Like I said, that should probably be a syntax error.

>> whereas 'then' has an obvious meaning that is in 
>> fact the opposite of what it would actually do.
>
> Er... is today opposite day? Because 'then' describes precisely what it
> actually does.

No, 'then' describes the opposite of what it does. The word 'then'
implies something that always happens next, whereas 'else' conveys
the correct meaning, which is something that happens if the course
of the preceding piece of code did not go as expected.

> Perhaps before we continue, we should ask what you think for...else
> and while...else statements do. Just to be sure we are all on the
> same page here.

I think they do what the Python Language Reference sections 8.2
and 8.3 say they do.

>> It seems clear that 'else' is the correct word (or at least, far
>> better than 'then').
>
> Not clear at all. The 'for...else' block is a common source of
> confusion, if it was clear what it did, people wouldn't so often get
> it wrong.

That might be an argument that it is imperfect. It doesn't even begin
to constitute an argument that 'then' would be an improvement.

>> Maybe the change should be that it is a syntax error to use a
>> 'for/while...else' with no 'break'.
>
> Only if you want to make the experience of using Python in the interactive
> interpreter worse. See my recent post:
>
> "A use-case for for...else with no break"

Yes, I saw that. It's possible you are the only person in the world
ever to have done that. It would not make the interactive interpreter
'worse' in the slightest for that silly trick to be lost.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: replacing `else` with `then` in `for` and `try`

2017-11-02 Thread Skip Montanaro

Eh, what can I say? I guess I was paying too much attention to the baseball
game. Yes, "else" handles the "fall off the end" termination, not the "exit
early" termination. My apologies. I do think that having a way to spell "do
this when the loop exits early" makes things clearer. So, perhaps while and
for loops could someday grow except clauses. :-)


On Thu, Nov 2, 2017 at 5:04 AM, Steve D'Aprano 
wrote:

> On Thu, 2 Nov 2017 12:49 pm, Skip Montanaro wrote:
>
> > I don't know. The word "then" doesn't connote different ways of exiting a
> > loop to me ("else" doesn't really either, I will grant you that, but it's
> > what we have). Here's how I would read things:
> >
> >- *while* some condition holds, execute the loop, possibly breaking
> out,
> >*then* do some finishing work
> >- *for* each element in some sequence, execute the loop, possibly
> >breaking out, *then* do some finishing work
>
> And that is exactly the behaviour of the for...else and while...else
> construct. You're reading it correctly.
>
> When you say "possibly breaking out", I assume you mean breaking out of the
> *entire* compound statement, because the alternative would be just silly.
> The
> alternative would be exactly equivalent to just following the loop with
> some
> unindented code:
>
>
> while condition:
> block
> # on break we jump to here
> finishing
>
>
> In that case, it makes no sense to include a do-nothing "else" or "then"
> keyword.
>
> To put it another way, if we are trying to infer the semantics of a
> statement,
> and can interpret it in one of two ways:
>
> - it does something
>
> - it does nothing
>
> then (with special case) of `pass`, we should always assume the first case,
> thus resolving the ambiguity in favour of "Guido isn't an idiot who added a
> pointless keyword" :-)
>
>
> > In neither case does it seem to me that you execute the finishing work
> only
> > if you break out of the loop, but not if the loop terminates when the
> while
> > condition becomes false or the for loop's sequence is exhausted.
>
> If I'm reading you correctly, I think you are confused about the `else`
> clause. It is incorrect to say that the `else` clause runs "only if you
> break
> out of the loop" (as you say). The `else` clause runs *after* the loop
> completes, but NOT if you jump out with break/return/raise.
>
> If we don't jump out of the loop, the else block is equivalent to just
> following the loop with unindented code:
>
>
> for x in sequence:
> block
> else:
> follows
>
>
> is equivalent to:
>
>
> for x in sequence:
> block
> follows
>
>
> Hence, in the absence of any early exit from the loop, the `else` block
> behaves more like an *then* rather than an "else". The behaviour of `else`
> confused me utterly until I realised that the semantics of the compound
> for...else was the loop to execute, then the `else` block.
>
> So why even bother with `else`?
>
> Unlike the second case, the `else` block is part for the compound for/while
> statement. And so `break` doesn't just exit the loop, it exits the whole
> compound statement, jumping past the `else`:
>
> for x in sequence:
> block
> else:
> follows
> # break jumps to here
> more code
>
>
> The motive for allowing this pattern is described here:
>
> https://shahriar.svbtle.com/pythons-else-clause-in-loops
>
>
> > You might
> > consider that while/then or for/then actually reads too much like
> English,
> > fooling you into interpreting it as English, opening you up to ambiguity.
>
> If you interpret it as English, it works fine. You run the loop, then you
> run
> the "then" clause. If you jump out of the loop (whether by return, raise or
> break) you jump out of the *entire* statement, not just the loop part.
>
> There's no ambiguity because we can assume Guido wouldn't introduce a
> pointless block keyword that does literally nothing except require an
> indent.
>
>
> > You might argue that "else" doesn't either, but it has the strangely nice
> > property of actually being a bit clumsier to read, forcing the reader to
> > learn and apply the precise rules of the programming language instead of
> > infer the more ambiguous rules of English.
>
> If only that were true...
>
> There's a simple, obvious, but sadly WRONG plain English interpretation of
> for...else, namely that the `else` clause runs if the for sequence was
> empty:
>
>
> for x in L:
> pass
> else:
> # This is wrong!
> print("L is empty")
>
>
> and similar for while. That lead me astray for the longest time! And I'm
> not
> the only one.
>
>
> > English and other natural languages aren't precise enough to serve as
> > programming languages.
>
> Hmmm... I think Hypertalk might have something to say about that.
>
> And Inform7 I think would laugh in your face :-)
>
>
>
>
> --
> Steve
> “Cheer up,” they said, “things could be worse.” So I cheered up, and sure
> enough, things got worse.
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https:/

Re: replacing `else` with `then` in `for` and `try`

2017-11-02 Thread Wolfgang Maier


On 11/02/2017 06:09 PM, Skip Montanaro wrote:

Eh, what can I say? I guess I was paying too much attention to the baseball
game. Yes, "else" handles the "fall off the end" termination, not the "exit
early" termination. My apologies. I do think that having a way to spell "do
this when the loop exits early" makes things clearer. So, perhaps while and
for loops could someday grow except clauses. :-)



... and even this idea has been discussed before:

https://mail.python.org/pipermail/python-ideas/2017-March/044932.html

There wasn't much enthusiasm about it though because few people (ok, 
maybe even just me) thought it had interesting use cases.


--
https://mail.python.org/mailman/listinfo/python-list

Share unpickleable object across processes

I have a Flask/UWSGI web app that serves up web socket connections. When a web 
socket connection is created, I want to store a reference to said web socket so 
I can do things like write messages to every connected socket/disconnect 
various sockets/etc. UWSGI, however, launches multiple child processes which 
handle incoming connections, so the data structure that stores the socket 
connections needs to be shared across all said processes. How can I do this?

Tried so far:

1) using a multiprocessing Manager(), from which I have gotten a dict(). This 
just gives me "BlockingIOError: [Errno 35] Resource temporarily unavailable" 
errors whenever I try to access the dict object.
2) Using redis/some other third-party store. This fails because it requires you 
to be able to pickle the object, and the web socket objects I'm getting are not 
pickle able.

In C I might do something like store a void pointer to the object, then cast it 
to the correct object type, but that's not an option in python. So how can I 
get around this issue?



---
Israel Brewster
Systems Analyst II
Ravn Alaska
5245 Airport Industrial Rd
Fairbanks, AK 99709
(907) 450-7293
---




-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Thread safety issue (I think) with defaultdict

On Fri, Nov 3, 2017 at 3:27 AM, Israel Brewster  wrote:
>
> Actually, that saying is about regular expressions, not threads :-) . In the 
> end, threads are as good a way as handling concurrency as any other, and 
> simpler than many. They have their drawbacks, of course, mainly in the area 
> of overhead, and of course only multiprocessing can *really* take advantage 
> of multiple cores/CPU's on a machine, but unlike regular expressions, threads 
> aren't ugly or complicated. Only the details of dealing with concurrency make 
> things complicated, and you'll have to deal with that in *any* concurrency 
> model.
>

Thank you. I've had this argument with many people, smart people (like
Steven), people who haven't grokked that all concurrency has costs -
that threads aren't magically more dangerous than other options. They
have a few limitations (for instance, you can't viably have more than
a few thousand threads in a process, but you could easily have orders
of magnitude more open sockets managed by asyncio), but for many
situations, they're the perfect representation of program logic.
They're also easy to explain, and then other concurrency models can be
explained in terms of threads (eg async functions are like threads but
they only switch from thread to thread at an 'await' point).

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Share unpickleable object across processes

On Fri, Nov 3, 2017 at 5:54 AM, Israel Brewster  wrote:
> I have a Flask/UWSGI web app that serves up web socket connections. When a 
> web socket connection is created, I want to store a reference to said web 
> socket so I can do things like write messages to every connected 
> socket/disconnect various sockets/etc. UWSGI, however, launches multiple 
> child processes which handle incoming connections, so the data structure that 
> stores the socket connections needs to be shared across all said processes. 
> How can I do this?
>

You're basically going to need to have a single process that manages
all the socket connections. Do you actually NEED multiple processes to
do your work? If you can do it with multiple threads in a single
process, you'll be able to share your socket info easily. Otherwise,
you could have one process dedicated to managing the websockets, and
all the others message that process saying "please send this to all
processes".

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Share unpickleable object across processes

On Nov 2, 2017, at 12:30 PM, Chris Angelico  wrote:
> 
> On Fri, Nov 3, 2017 at 5:54 AM, Israel Brewster  wrote:
>> I have a Flask/UWSGI web app that serves up web socket connections. When a 
>> web socket connection is created, I want to store a reference to said web 
>> socket so I can do things like write messages to every connected 
>> socket/disconnect various sockets/etc. UWSGI, however, launches multiple 
>> child processes which handle incoming connections, so the data structure 
>> that stores the socket connections needs to be shared across all said 
>> processes. How can I do this?
>> 
> 
> You're basically going to need to have a single process that manages
> all the socket connections. Do you actually NEED multiple processes to
> do your work? If you can do it with multiple threads in a single
> process, you'll be able to share your socket info easily. Otherwise,
> you could have one process dedicated to managing the websockets, and
> all the others message that process saying "please send this to all
> processes".

Ok, that makes sense, but again: it's UWSGI that creates the processes, not me. 
I'm not creating *any* processes or threads. Aside from telling UWSGI to only 
use a single worker, I have no control over what happens where. But maybe 
that's what I need to do?

> 
> ChrisA
> -- 
> https://mail.python.org/mailman/listinfo/python-list

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Share unpickleable object across processes

On Nov 2, 2017, at 11:15 AM, Stefan Ram  wrote:
> 
> Israel Brewster  writes:
>> the data structure that stores the socket connections needs
>> to be shared across all said processes.
> 
>  IIRC that's the difference between threads and
>  processes: threads share a common memory.
> 
>  You can use the standard module mmap to share
>  data between processes.
> 
>  If it's not pickleable, but if you can write code
>  to serialize it to a text format yourself, you
>  can share that text representation via, er, sockets.

If I could serialize it to a text format, then I could pickle said text format 
and store it in redis/some other third party store. :-)

> 
>> In C I might do something like store a void pointer to the
>> object, then cast it to the correct object type
> 
>  Restrictions of the OS or MMU even apply to
>  C code.

Sure, I was just talking in general "ideas". I'm not saying I tried it or it 
would work.

> 
>> , but that's not an option in python. So how can I get around
>> this issue?
> 
>  You can always write parts of a CPython program
>  in C, for example, using Cython.

True, but I just need to be able to share this piece of data - I don't want to 
reinvent the wheel just to write an app that uses web sockets!

I *must* be thinking about this wrong. Take even a basic chat app that uses 
websockets. Client a, which connected to process 1, sends a message to the 
server. There are three other clients connected, each of which needs to receive 
said message. Given that the way UWSGI works said clients could have connected 
to any one of the worker processes, how can the server push the message out to 
*all* clients? What am I missing here?

> 
> -- 
> https://mail.python.org/mailman/listinfo/python-list

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Share unpickleable object across processes

On Fri, Nov 3, 2017 at 7:35 AM, Israel Brewster  wrote:
> On Nov 2, 2017, at 12:30 PM, Chris Angelico  wrote:
>>
>> On Fri, Nov 3, 2017 at 5:54 AM, Israel Brewster  
>> wrote:
>>> I have a Flask/UWSGI web app that serves up web socket connections. When a 
>>> web socket connection is created, I want to store a reference to said web 
>>> socket so I can do things like write messages to every connected 
>>> socket/disconnect various sockets/etc. UWSGI, however, launches multiple 
>>> child processes which handle incoming connections, so the data structure 
>>> that stores the socket connections needs to be shared across all said 
>>> processes. How can I do this?
>>>
>>
>> You're basically going to need to have a single process that manages
>> all the socket connections. Do you actually NEED multiple processes to
>> do your work? If you can do it with multiple threads in a single
>> process, you'll be able to share your socket info easily. Otherwise,
>> you could have one process dedicated to managing the websockets, and
>> all the others message that process saying "please send this to all
>> processes".
>
> Ok, that makes sense, but again: it's UWSGI that creates the processes, not 
> me. I'm not creating *any* processes or threads. Aside from telling UWSGI to 
> only use a single worker, I have no control over what happens where. But 
> maybe that's what I need to do?
>

That's exactly what I mean, yeah. UWSGI should be able to be told to
use threads instead of processes. I don't know it in detail, but a
cursory look at the docos suggests that it's happy to use either (or
even both).

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Share unpickleable object across processes

On Nov 2, 2017, at 12:36 PM, Chris Angelico  wrote:
> 
> On Fri, Nov 3, 2017 at 7:35 AM, Israel Brewster  > wrote:
>> On Nov 2, 2017, at 12:30 PM, Chris Angelico  wrote:
>>> 
>>> On Fri, Nov 3, 2017 at 5:54 AM, Israel Brewster  
>>> wrote:
 I have a Flask/UWSGI web app that serves up web socket connections. When a 
 web socket connection is created, I want to store a reference to said web 
 socket so I can do things like write messages to every connected 
 socket/disconnect various sockets/etc. UWSGI, however, launches multiple 
 child processes which handle incoming connections, so the data structure 
 that stores the socket connections needs to be shared across all said 
 processes. How can I do this?
 
>>> 
>>> You're basically going to need to have a single process that manages
>>> all the socket connections. Do you actually NEED multiple processes to
>>> do your work? If you can do it with multiple threads in a single
>>> process, you'll be able to share your socket info easily. Otherwise,
>>> you could have one process dedicated to managing the websockets, and
>>> all the others message that process saying "please send this to all
>>> processes".
>> 
>> Ok, that makes sense, but again: it's UWSGI that creates the processes, not 
>> me. I'm not creating *any* processes or threads. Aside from telling UWSGI to 
>> only use a single worker, I have no control over what happens where. But 
>> maybe that's what I need to do?
>> 
> 
> That's exactly what I mean, yeah. UWSGI should be able to be told to
> use threads instead of processes. I don't know it in detail, but a
> cursory look at the docos suggests that it's happy to use either (or
> even both).

Gotcha, thanks. The hesitation I have there is that the UWSGI config is a user 
setting. Sure, I can set up my install to only run one process, but what if 
someone else tries to use my code, and they set up UWSGI to run multiple? I 
hate the idea of my code being so fragile that a simple user setting change 
which I have no control over can break it. But it is what it is, and if that's 
the only option, I'll just put a note in the readme to NEVER, under any 
circumstances, set UWSGI to use multiple processes when running this app and 
call it good :-)

> 
> ChrisA
> -- 
> https://mail.python.org/mailman/listinfo/python-list 
> 
-- 
https://mail.python.org/mailman/listinfo/python-list

bug in ''.format()

2017-11-02 Thread Ken Kundert

I just encountered this:

>>> '{:0s}'.format('hello')
Traceback (most recent call last):
  File "", line 1, in 
ValueError: '=' alignment not allowed in string format specifier

The exception goes away if I do not specify a width of the string:

>>> '{:s}'.format('hello')
'hello'

My reading of the documentation says I should be able to specify a width
when interpolating a string.

I have tried this in 2.7.13, 3.6.1 and 3.6.2 and it fails in all of them.

Is this a bug or am I confused?
-Ken
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Share unpickleable object across processes

On Fri, Nov 3, 2017 at 8:10 AM, Israel Brewster  wrote:
> Gotcha, thanks. The hesitation I have there is that the UWSGI config is a
> user setting. Sure, I can set up my install to only run one process, but
> what if someone else tries to use my code, and they set up UWSGI to run
> multiple? I hate the idea of my code being so fragile that a simple user
> setting change which I have no control over can break it. But it is what it
> is, and if that's the only option, I'll just put a note in the readme to
> NEVER, under any circumstances, set UWSGI to use multiple processes when
> running this app and call it good :-)

IMO that's not a problem. People have gotten into the bad habit of
assuming that all requests are independent, and that's something that
is OFTEN true, but can leak. That's why some web sites randomly log
you out now and then - because you landed on a different instance of
the web server, and it doesn't have your login (because they messed up
the sharing across nodes). For something like this, where different
clients directly interact with each other, it's entirely reasonable to
demand that they all be handled by a single process.

In MUDs, it's normal to run a single process for all clients. Of
course, MUDs aren't heavy-weight, but it's possible to handle a
thousand concurrent clients without a blip on the CPU monitor. You'd
be surprised how many HTTP clients you can manage on a single process,
as long as you have the RAM for it.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: bug in ''.format()

2017-11-02 Thread MRAB


On 2017-11-02 21:30, Ken Kundert wrote:

I just encountered this:


'{:0s}'.format('hello')

Traceback (most recent call last):
   File "", line 1, in 
ValueError: '=' alignment not allowed in string format specifier

The exception goes away if I do not specify a width of the string:


'{:s}'.format('hello')

'hello'

My reading of the documentation says I should be able to specify a width
when interpolating a string.

I have tried this in 2.7.13, 3.6.1 and 3.6.2 and it fails in all of them.

Is this a bug or am I confused?
-Ken


The docs say this:

"""
When no explicit alignment is given, preceding the width field by a zero 
('0') character enables sign-aware zero-padding for numeric types. This 
is equivalent to a fill character of '0' with an alignment type of '='.

"""

It thinks that the "0" means zero-padding, etc, as explained above. 
(Having an explicit width of 0 is kind of odd anyway, if you think about 
it!)


The solution is to include an alignment character:

>>> '{:<0s}'.format('hello')
'hello'
--
https://mail.python.org/mailman/listinfo/python-list

Re: A use-case for for...else with no break

On 11/2/2017 6:10 AM, Steve D'Aprano wrote:

Occasionally it is useful to loop over a bunch of stuff in the interactive
interpreter, printing them as you go on a single line:

for x in something():
 print(x, end='')

If you do that, the prompt overwrites your output, and you get a mess:

py> for x in "abcdefgh":
... print(x, end='')
...
py> efghpy>

This seems like a bug in how Python interacts with your console.  On 
Windows, in Python started from an icon or in Command Prompt:

>>> for c in 'abc': print(c, end='')
...
abc>>>

IDLE adds \n if needed, so prompts always starts on a fresh line.

>>> for x in 'abcdefgh':
print(x, end='')

abcdefgh
>>>

"For ... else" to the rescue!

py> for char in "abcdefgh":
... print(char, end='')
... else:
... print()
...
abcdefgh
py>

--
Terry Jan Reedy

--
https://mail.python.org/mailman/listinfo/python-list

Re: bug in ''.format()

2017-11-02 Thread Ken Kundert

Sure enough. There is it, right there in the documentation. I did not
read far enough.

My bad.

Thanks!
-Ken
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: FW: Reading a remove csv file


On 11/2/2017 9:18 AM, ROGER GRAYDON CHRISTMAN wrote:

I have a partial answer to my own question:
This seems to work for me:

---
link = urllib.request.urlopen(urlpath)
data = link.read().decode('utf-8').split('\n')

reader = csv.DictReader(data)
for row in reader:
---

I think here my concern is that now 'data' is now a variable
in my program's memory (all of the data),
instead of streamlike.   I suppose I did read
somewhere about setting a stream option.


csv.reader and csv.DictReader are transformation iterators whose first 
argument must be an iterable of string lines.  Given an iterator of 
bytes lines, you just need to interpose a bytes to string iterator  -- 
something like (untested)


def strgen(bytesource, encoding):
for line in bytesource:
yield line.decode(encoding)

with urllib.request.urlopen(urlpath) as link:
lines = strgen(link, 'utf-8')
reader = csv.DictReader(lines)  # plus any other args
for row in reader:
process(row)

Iterators are intended to be chained together like this.

--
Terry Jan Reedy

--
https://mail.python.org/mailman/listinfo/python-list

mimedecode 2.8.0

2017-11-02 Thread Oleg Broytman

Hello!

mimedecode.py

WHAT IS IT

   Mail users, especially in non-English countries, often find that mail
messages arrived in different formats, with different content types, in
different encodings and charsets. Usually this is good because it allows us to
use appropriate format/encoding/whatever. Sometimes, though, some unification
is desirable. For example, one may want to put mail messages into an archive,
make HTML indices, run search indexer, etc. In such situations converting
messages to text in one character set and skipping some binary attachments is
much desirable.

   Here is the solution - mimedecode.py.

   This is a program to decode MIME messages. The program expects one input
file (either on command line or on stdin) which is treated as an RFC822
message, and decodes to stdout or an output file. If the file is not an RFC822
message it is just copied to the output one-to-one. If the file is a simple
RFC822 message it is decoded as one part. If it is a MIME message with multiple
parts ("attachments") all parts are decoded. Decoding can be controlled by
command-line options.


Version 2.8.0 (2017-11-03)

   Python 3.

   Stop supporting Python 2.6.

   Code cleanup: fixed flake8 errors and warnings.

   Pushed to GitHub. Tests at Travis.


WHERE TO GET
   Home page: http://phdru.name/Software/Python/#mimedecode
git clone https://github.com/phdru/mimedecode.git
git clone http://git.phdru.name/mimedecode.git
git clone  git://git.phdru.name/mimedecode.git

   Requires: Python 2.7 or Python 3.4+, m_lib.defenc 1.0+.
   Tests require: tox, m_lib 3.1+.

   Recommends: configured mailcap database.

   Documentation: http://phdru.name/Software/Python/mimedecode.html
  (also included in the package in html, man and txt formats).


AUTHOR
   Oleg Broytman 

COPYRIGHT
   Copyright (C) 2001-2017 PhiloSoft Design.

LICENSE
   GPL

Oleg.
-- 
 Oleg Broytmanhttp://phdru.name/[email protected]
   Programmers don't die, they just GOSUB without RETURN.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Share unpickleable object across processes

On Fri, Nov 3, 2017 at 11:00 AM, Dennis Lee Bieber
 wrote:
> On Thu, 2 Nov 2017 12:32:35 -0800, Israel Brewster 
> declaimed the following:
>
>
>>
>>I *must* be thinking about this wrong. Take even a basic chat app that uses 
>>websockets. Client a, which connected to process 1, sends a message to the 
>>server. There are three other clients connected, each of which needs to 
>>receive said message. Given that the way UWSGI works said clients could have 
>>connected to any one of the worker processes, how can the server push the 
>>message out to *all* clients? What am I missing here?
>>
>
> This is beginning to sound like a form of publisher/subscriber system.
>
> http://learning-0mq-with-pyzmq.readthedocs.io/en/latest/pyzmq/patterns/pubsub.html
>
> Though I have to admit I don't quite see how to set up bidirectional
> communication. Having the workers subscribe to receive data from a single
> publisher is the easier part -- but how a worker can send data to the
> publisher for distribution is not clear; the distribution process can't
> subscribe to every worker automatically... Perhaps something using
>
> http://learning-0mq-with-pyzmq.readthedocs.io/en/latest/pyzmq/devices/forwarder.html
>
> with each worker making both publisher and subscriber connections. That
> could let a worker publish to the forwarder, which then distributes to all
> subscribed workers. Might need some way to identify one's own message
> (perhaps each worker has a topic, and filters its own topic out of the
> return stream).

Websockets are perfect for this sort of thing. It's not difficult
but you need to have all the clients managed by a single central hub,
which is the exact problem the OP faced.

Here's a simple websocket app that does this sort of thing:

https://github.com/Rosuav/monopoly-open-bid/blob/master/server.py

It depends on running a single process to handle every client, and
then simply maintains an in-memory list of concurrent clients. (This
uses asyncio, but equivalent models using threads are also possible.)

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: what exactly does type.call do?

2017-11-02 Thread Jason Maldonis

Thanks for your response.

I'm confident that my use case for this metaclass is correct for what I'm
trying to do. I've been using them for a few years now, but sparingly
because as you said they are almost always unnecessary. I simplified my
example significantly for discussion -- I'm not actually using a Singleton,
but it's an easy situation to think about.

I'd like to ask a couple follow up questions here:

By using...

@classmethod
def normal_constructor(cls, *args, **kwargs):
return type.__call__(cls, *args, **kwargs)   # Aside: Yes, the `cls`
does need to be in here

... I'm assuming that there are no inherited metaclasses. I'm explicitly
saying, "No matter what the super() functionality for creating the class
is, always use `type`.__call__'s functionality".  That seems
wrong/unpythonic to me, or at least inconsistent with how non-metaclass
inheritance works in python (ie you are encouraged to use `super()` when
using single inheritance).

Because of that, my guess is...

@classmethod
def normal_constructor(cls, *args, **kwargs):
return super(cls).__call__(cls, *args, **kwargs)
# or maybe it should be:
return super(my_metaclass, cls).__call__(cls, *args, **kwargs)

... is closer to the correct approach because it will properly hit the
`__call__` method of the metaclass's parent class (which will often ey
`type`'s `__call__` method if the metaclass doesn't inherit from any other
metaclass).  However, I've never seen anything like that after years of
working with / reading about metaclasses.

Does that help redefine my question a little bit? You said all three look
"weird and scary", but I don't know why. Can you explain that a bit
please?  The 3rd example I gave (using `cls.__new__` and `self.__init__`) I
agree is a bit weird and scary, and in my opinion that's because I am
assuming what the correct sequence of calls is for how classes are normally
instantiated. So I'm the least thrilled with that one. I feel like using
super is the correct choice -- for the reasons I listed above -- but I
would like a more expert opinion (and I'd like to learn why :)).

Thanks!
Jason

On Thu, Nov 2, 2017 at 12:28 AM, Steve D'Aprano 
wrote:

> On Thu, 2 Nov 2017 10:13 am, Jason Maldonis wrote:
>
> > Hi everyone,
> >
> > I want to use a metaclass to override how class instantiation works. I've
> > done something analogous to using the Singleton metaclass from the
> Python3
> > Cookbook example.
>
> In my opinion, nine times out of ten, using a metaclass for something like
> that is overkill.
>
> (And that's putting aside the fact that 999 out of a thousand, using a
> Singleton is the wrong solution, no matter what the question is.)
>
>
> > However, I want to provide a classmethod that allows for "normal" class
> > instantiation that prevents this metaclass from being used.
>
> To me, that strongly suggests that a metaclass is the wrong solution.
>
>
> > To do that, I think I just make a @classmethod constructor function.
> > However, I can imagine a few different ways of writing this:
> >
> > @classmethod
> > def normal_constructor(cls, *args, **kwargs):
> > return type.__call__(*args, **kwargs)
>
> Untested, but I think that should be:
>
> return type.__call__(cls, *args, **kwargs)
>
>
> > @classmethod
> > def normal_constructor(cls, *args, **kwargs):
> > return super(???).__call__(*args, **kwargs)  # I'm not sure what
> should
> > go in the super here  (I'm using python3)
> >
> > @classmethod
> > def normal_constructor(cls, *args, **kwargs):
> > self = cls.__new__(cls)
> > self.__init__(*args, **kwargs)
> > return self
> >
> > Is one of these correct? Or do they all do the same thing?
>
> None of them look "correct", they all look "weird and scary" :-)
>
> If I had to pick one of these three -- and I hope that I would not -- I'd
> pick
> the first one.
>
>
> > I was looking for documentation for what exactly `type.__call__` does so
> > that I can emulate it,
>
> And then if type.__call__ changes, your emulation will be wrong.
>
>
> > but I wasn't able to find any docs explicitly
> > detailing what that method does. If someone knows where this info is that
> > would be great too.
>
>
>
> --
> Steve
> “Cheer up,” they said, “things could be worse.” So I cheered up, and sure
> enough, things got worse.
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: A use-case for for...else with no break

On Fri, 3 Nov 2017 09:20 am, Terry Reedy wrote:

> This seems like a bug in how Python interacts with your console. On 
> Windows, in Python started from an icon or in Command Prompt:
> 
>  >>> for c in 'abc': print(c, end='')
> ...
> abc>>>

That's still unfortunate: the prompt is immediately after the output, rather
than starting on a new line.

> IDLE adds \n if needed, so prompts always starts on a fresh line.
> 
>  >>> for x in 'abcdefgh':
> print(x, end='')
> 
> abcdefgh
>  >>>

The prompts and the output aren't aligned -- the prompts are indented by an
additional space. Is that intentional?

Does IDLE do this only when writing to an actual console? Because if it does
so even when output is redirected to a file, adding an extra, unexpected
newline would be a bug in IDLE.

In any case, in the interactive interpreter there are times one wishes to
follow a loop with additional code that executes immediately after the loop,
and have them do so *together* without a prompt in between. It might not even
be because you care about the output: you might be timing something, and
don't want it to pause and wait for you to type the following code.

But you cannot write this:

py> for x in seq:
... do_this()
... do_that()

as the interpreter in interactive mode requires a blank line to terminate the
indented block. But if you include such a blank:

py> for x in seq:
... do_this()
...
py> do_that()

the output of "do_this()" is separated from the output of "do_that()", which
may be inconvenient.

Another work around is:

if True:
for x in seq:
do_this()
do_that()

-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Thread safety issue (I think) with defaultdict

On Fri, 3 Nov 2017 07:24 am, Chris Angelico wrote:

> On Fri, Nov 3, 2017 at 3:27 AM, Israel Brewster 
> wrote:
>>
>> Actually, that saying is about regular expressions, not threads :-) . In
>> the end, threads are as good a way as handling concurrency as any other,
>> and simpler than many. They have their drawbacks, of course, mainly in the
>> area of overhead, and of course only multiprocessing can *really* take
>> advantage of multiple cores/CPU's on a machine, but unlike regular
>> expressions, threads aren't ugly or complicated. Only the details of
>> dealing with concurrency make things complicated, and you'll have to deal
>> with that in *any* concurrency model.
>>
> 
> Thank you. I've had this argument with many people, smart people (like
> Steven), people who haven't grokked that all concurrency has costs -

Of course I grok that all concurrency has costs. Apart from comparatively rare
cases of "embarrassingly parallel" algorithms, any form of concurrent or
parallel processing is significantly harder than sequential code.


> that threads aren't magically more dangerous than other options.

There's nothing magical about it.

Threads are very much UNMAGICALLY more dangerous than other options because
they combine:

- shared data; and

- non-deterministic task switching.

Having both together is clearly more dangerous than only one or the other:

- async: shared data, but fully deterministic task switching;

- multiprocessing: non-deterministic task switching, but by default
  fully isolated data.




-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: replacing `else` with `then` in `for` and `try`

On Fri, 3 Nov 2017 03:31 am, Jon Ribbens wrote:

> On 2017-11-02, Steve D'Aprano  wrote:
>> On Fri, 3 Nov 2017 12:39 am, Jon Ribbens wrote:
>>> Why would we want to make the language worse? It is fairly obvious
>>> what 'else' means,
>>
>> Yes, obvious and WRONG.
> 
> Nope, obvious and right.
>
>> for x in seq:
>> do_something()
>> else:
>> print("seq was empty")
>>
>> is an obvious, common and wrong interpretation.
> 
> No, it's an obvious bug. You have a 'for...else' with no 'break'.
> Like I said, that should probably be a syntax error.

It should absolutely not be a syntax error. There's no reason for it to be a
syntax error, except to satisfy some arrogant and foolish idea of purity.

There are uncountable ways of writing code which is seemingly "pointless", and
we don't make it a syntax error. Sometimes it is even useful. A for...else
with no break should no more be a syntax error than "if True".

>>> whereas 'then' has an obvious meaning that is in
>>> fact the opposite of what it would actually do.
>>
>> Er... is today opposite day? Because 'then' describes precisely what it
>> actually does.
> 
> No, 'then' describes the opposite of what it does. The word 'then'
> implies something that always happens next, 

Right, which is what happens with the for...else block.

The else block is executed after the for loop, unless you jump out of the
statement using return, raise or break. The flow is:

# this is what actually happens
loop
then `else` block

rather than:

# this is incorrect
loop
else (otherwise) `else` block

which implies that that `else` block runs if the loop did not.

> whereas 'else' conveys 
> the correct meaning, which is something that happens if the course
> of the preceding piece of code did not go as expected.

That's not what happens. This is WRONG:

for x in sequence:
...
else:
print("something unexpected happened")

Apart from the impossibility of deciding what "unexpected" means in general,
the behaviour is the opposite. The `else` clause executes immediately after
you fall out the bottom of the for-loop, NOT conditional on some event
(whether unexpected or not).

>>> Maybe the change should be that it is a syntax error to use a
>>> 'for/while...else' with no 'break'.
>>
>> Only if you want to make the experience of using Python in the interactive
>> interpreter worse. See my recent post:
>>
>> "A use-case for for...else with no break"
> 
> Yes, I saw that. It's possible you are the only person in the world
> ever to have done that. It would not make the interactive interpreter
> 'worse' in the slightest for that silly trick to be lost.

Just because you personally haven't used this technique doesn't make it
a "silly trick".

And while I thank you for the complement that I am the cleverest and most
insightful Python coder in the world, I'm sure I'm not. If I could think of
this technique, I daresay that many other people who are much smarter than me
have done so too.

-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

-- 
https://mail.python.org/mailman/listinfo/python-list

Key Press Not Working

2017-11-02 Thread brandon wallace


 
I am trying to catch a key press but it is not working. How can I fix this 
code? There is no error message so there is no error message to do a search on.
I am using Python3.5 64-bit inside the terminal.

while True:
key = input("Enter a letter: ")
if key == ord('q'):
 break
 
 The loop keeps running even though I have pressed the letter 'q'.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Key Press Not Working

2017-11-02 Thread MRAB

On 2017-11-03 02:40, brandon wallace wrote:

I am trying to catch a key press but it is not working. How can I fix this code? There is no error message so there is no error message to do a search on.

I am using Python3.5 64-bit inside the terminal.

while True:
 key = input("Enter a letter: ")
 if key == ord('q'):
  break

  The loop keeps running even though I have pressed the letter 'q'.

It's waiting for you to press Enter.

'input' is for inputting a line. It returns a string.

>>> s = input("Enter a line: ")
Enter a line: foo
>>> s
'foo'
--
https://mail.python.org/mailman/listinfo/python-list

Re: Invoking return through a function?

2017-11-02 Thread Rustom Mody

On Tuesday, October 31, 2017 at 11:05:30 AM UTC+5:30, Steve D'Aprano wrote:
> On Tue, 31 Oct 2017 02:26 pm, Rustom Mody wrote:
> 
> > My own feeling about lisp-macros is conflicted:
> > - They are likely the most unique feature of lisp, putting it at the top of
> > the blub-language tower
> > - They are the single reason Lisp can never succeed like mainstream
> > languages: Any significant Lisp sub-ecosystem will inevitably develop a
> > macro set which succinctly and precisely expresses its needs but is arcane
> > and incomprehensible to someone from another sub-ecosystem.
> 
> Well said. That's one of the disadvantages of Forth as well: since Forth
> allows you to define your own control-structures, even the structure of the
> code can be unfamiliar.
> 
> Another way to put it might be that any sufficiently complex Lisp program
> doesn't look like Lisp any more.

It seems we agree on the facts but not the accounting

Facts: A fixed syntax language (C, Java, Python etc) is likely to have
similar looking programs across a wide spectrum of applications as compared to
a syntax-definable-at-runtime language like Lisp

Accounting: You seem to count this as advantage to fixed-syntax?

Note that if you carry this principle all the way, any application whatever 
running on an x86 will be running x86 instructions; which look more uniform 
than 
the diverse hl-languages  that produced them.



> 
> Except perhaps for the myriad parentheses *wink* 

Not so: reader-macros can change lisp all the way to the lexical level
And used to do things like html-templating, sql-embedding etc
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: A use-case for for...else with no break

On 11/2/2017 8:53 PM, Steve D'Aprano wrote:

On Fri, 3 Nov 2017 09:20 am, Terry Reedy wrote:

This seems like a bug in how Python interacts with your console. On
Windows, in Python started from an icon or in Command Prompt:

  >>> for c in 'abc': print(c, end='')
...
abc>>>

That's still unfortunate: the prompt is immediately after the output, rather
than starting on a new line.

I agree.  It is just less bad than backspacing into user output first. 
It is easy for IDLE to detect if the prompt needs a \n prefix.  I am 
guessing that this is harder on consoles, and OS dependent.

IDLE adds \n if needed, so prompts always starts on a fresh line.

  >>> for x in 'abcdefgh':
print(x, end='')

abcdefgh
  >>>

The prompts and the output aren't aligned -- the prompts are indented by an
additional space. Is that intentional?

A copy-paste error (I rechecked) that I should have noticed.

Does IDLE do this only when writing to an actual console?

IDLE does this when Python writes to its Shell via stdout or stderr.

Because if it does
so even when output is redirected to a file, adding an extra, unexpected
newline would be a bug in IDLE.

IDLE compiles and execs your code.  During the exec call, IDLE only sees 
output sent to its stdout/stderr replacements.  If your code sends 
output to a file it opens, IDLE is not involved.

--
Terry Jan Reedy

--
https://mail.python.org/mailman/listinfo/python-list

Re: Thread safety issue (I think) with defaultdict

2017-11-02 Thread Rustom Mody

On Friday, November 3, 2017 at 6:28:28 AM UTC+5:30, Steve D'Aprano wrote:
> On Fri, 3 Nov 2017 07:24 am, Chris Angelico wrote:
> 
> > On Fri, Nov 3, 2017 at 3:27 AM, Israel Brewster wrote:
> >>
> >> Actually, that saying is about regular expressions, not threads :-) . In
> >> the end, threads are as good a way as handling concurrency as any other,
> >> and simpler than many. They have their drawbacks, of course, mainly in the
> >> area of overhead, and of course only multiprocessing can *really* take
> >> advantage of multiple cores/CPU's on a machine, but unlike regular
> >> expressions, threads aren't ugly or complicated. Only the details of
> >> dealing with concurrency make things complicated, and you'll have to deal
> >> with that in *any* concurrency model.
> >>
> > 
> > Thank you. I've had this argument with many people, smart people (like
> > Steven), people who haven't grokked that all concurrency has costs -
> 
> Of course I grok that all concurrency has costs. Apart from comparatively rare
> cases of "embarrassingly parallel" algorithms, any form of concurrent or
> parallel processing is significantly harder than sequential code.
> 
> 
> > that threads aren't magically more dangerous than other options.
> 
> There's nothing magical about it.
> 
> Threads are very much UNMAGICALLY more dangerous than other options because
> they combine:
> 
> - shared data; and
> 
> - non-deterministic task switching.

… which is to say «bad mix of imperative programming and concurrency»



«The world is concurrent» [Joe Armstrong creator of Erlang]

If you get up from your computer just now for a coffee, it does not mean I have
to at the same time. More pertinently, it would be rather wasteful if the
billion+ transistors of an i7 waited for each other rather than switching 
independently.

The problem is that von Neumann preferred to simplify the programming task 
along 
the lines nowadays called "imperative programming"… after whom we get the
terms "von Neumann model", "von Neumann machine" etc

IOW threads are a particularly extreme example of the deleterious effects
of stuffing the world into the mold of someone's (von Neumann's) brain.

ie shared data + task switching = combinatorially explosive results

Take your own statement «any form of concurrent or parallel processing is
significantly harder than sequential code» 

and apply it to the abc of imperative programming:

Problem: Interchange values of variables x and y

Layman answer:
x = y
y = x

[Ignore for a moment that python has an answer that is almost identical to the 
above and is correct: x,y = y,x]

"Correct" answer:
temp = x
x = y
y = temp

Correct? Really???
Or is that being trained to "think like a programmer" means learning to 
convolute our brains into an arbitrary and unnecessary sequentiality?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Thread safety issue (I think) with defaultdict

On Fri, 3 Nov 2017 02:19 pm, Rustom Mody wrote:

> «The world is concurrent» [Joe Armstrong creator of Erlang]


And the world is extremely complex, complicated and hard to understand.

The point of programming is to simplify the world, not emulate it in its full
complexity.



-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Thread safety issue (I think) with defaultdict