Re: Operator Precedence/Boolean Logic

[Steven D'Aprano]

On Thursday 23 June 2016 16:34, Andreas Röhler wrote:

> Indeed, why should the result of 4 - 4 have a different truth-value than
> 4 - 3 ?

Because 4-4 is zero, which is "nothing", while 4-3 is one, which is 
"something".

You might as well ask why False and True have different truth values. 
Ironically, in a manner of speaking you *did* ask that, since 4-3 == True and 
4-4 == False.


-- 
Steve

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

Re: Operator Precedence/Boolean Logic

[Christian Gollwitzer]

Am 23.06.16 um 05:12 schrieb Larry Hudson:

On 06/22/2016 12:42 AM, Lawrence D’Oliveiro wrote:

I feel that’s a needlessly complicated rule. It would have been
simpler if boolean operators (and conditional expressions like in
if-statements and while-statements) only allowed values of boolean
types. But that’s one of the few warts in the design of Python...



Wart??  I *strongly* disagree.  I find it one of the strengths of
Python, it enhances Python's expressiveness.  Of course, everyone is
entitled to their own opinion...and this is mine.


https://xkcd.com/1172/

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

Re: Operator Precedence/Boolean Logic

[Steven D'Aprano]

On Thursday 23 June 2016 14:47, Lawrence D’Oliveiro wrote:

> On Thursday, June 23, 2016 at 3:12:52 PM UTC+12, Larry Hudson wrote:
>> On 06/22/2016 12:42 AM, Lawrence D’Oliveiro wrote:
>>> * boolean operators don’t have to operate on boolean values. The
>>>   language spec
>>>   
>>>   says:
>>>
>>> “...the following values are interpreted as false: False, None, numeric
>>> zero of all types, and empty strings and containers (including strings,
>>> tuples, lists, dictionaries, sets and frozensets). All other values are
>>> interpreted as true.”
>>>
>>> I feel that’s a needlessly complicated rule.

As I described in my earlier email, it isn't complicated, at least not the way 
builtins are modelled.


>>> It would have been simpler if
>>> boolean operators (and conditional expressions like in if-statements and
>>> while-statements) only allowed values of boolean types. But that’s one of
>>> the few warts in the design of Python...
>> 
>> Wart??  I *strongly* disagree.  I find it one of the strengths of Python,
>> it enhances Python's expressiveness.
> 
> Tightening it up would rule out a whole class of common errors,

Hardly common. The only two exceptions I've seen are:

- people surprised by midnight being false, but that is fixed in 3.5; 
- people surprised that empty or exhausted iterables don't evaluate as false

and the first of those is pretty rare.

But even if you were right, and I disagree that you are, "fixing" this would 
break backwards compatibility and cause vast amounts of working code to stop 
working. That is much worse than the "problem".


> from
> misunderstanding (or forgetting) the rule about what exactly gets interpreted
> as true and what as false 
> .

Or... we could fix time objects, as was done.


-- 
Steve

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

Re: Request for opinions: A cross language development tool

[Laurent Pointal]

Tal Zion wrote:

> Bridge compiles Python modules into native code, 

What is "native", really microprocessor executable binary ? How do you adapt 
to diversity?

> which requires us to
> support Python *language* features (for, while, class, generators, etc)
> but it reuses CPython's libraries (list, dict, str, etc) 

Hum, "etc" is important here, CPython libraries makes Python power 
("batteries included"). And running such code on client side have 
*important* security concerns… I won't see people allowing automatically 
loaded Python scripts (or their binaries) execution on their system as is 
without a security layer.

> so we don't
> implement those, and it also uses CPython's ast module in order to parse
> Python code. So once we are done supporting all of the language
> features, any Python code should work. 

Supporting features is not only parsing code, it's providing same execution 
semantic. And its a reason it would be more complicated to use exactly same 
execution kernel to run other languages.

> Currently we have quite a few
> language features to implement, but we're working on it =) We're
> targeting Python 3.5.

You seem to start a new, potentially complex project (devil is in details), 
ignoring other works which already did same job:

Apart from ironpython, parrot, jython, already listed, you can look at:
 
Brython to run Python with a JavaScript/ECMAScript engine
http://brython.info/

MicroPython to run Python on small embedded systems
https://micropython.org/

Also look at https://wiki.python.org/moin/WebBrowserProgramming where there 
are many other projects of that kind.

You want Python on the web browser, try to produce asm.js code, you will 
benefit of all work done on JavaScript engines, and of security layers. 
But… you will have to rewrite the batteries into pure Python mixed with 
asm.js code, this is huge work.

Bon courage.

A+
L.Pointal.

> 
> Tal
> 
> On 06/21/2016 08:36 PM, Chris Angelico wrote:
>> On Wed, Jun 22, 2016 at 12:06 AM, Tal Zion  wrote:
>>> * Bridge makes Python faster: Python code compiled through Bridge is
>>> compiled to native code. Because we are leveraging LLVM's many
>>> optimizations, Python code will run faster than ever.
>> Can you run *any* Python program through Bridge? Absolutely anything?
>> Can you guarantee language compatibility?
>>
>> And if you can - what version of Python are you compatible with?
>>
>> ChrisA

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

Re: Operator Precedence/Boolean Logic

[Antoon Pardon]

Op 23-06-16 om 05:59 schreef Steven D'Aprano:
> On Thu, 23 Jun 2016 01:12 pm, Larry Hudson wrote:
>
>> On 06/22/2016 12:42 AM, Lawrence D’Oliveiro wrote:
>> [snip]
>>> I feel that’s a needlessly complicated rule. It would have been simpler
>>> if boolean operators (and conditional expressions like in if-statements
>>> and while-statements) only allowed values of boolean types. But that’s
>>> one of the few warts in the design of Python...
>>>
>> Wart??  I *strongly* disagree.  I find it one of the strengths of Python,
>> it enhances Python's
>> expressiveness.  Of course, everyone is entitled to their own
>> opinion...and this is mine.
> Allowing any value as a truth value is just applying the principle of
> duck-typing to booleans.

What does that mean? As far as I understood, duck typing was that you
could define any class with the same attributes and methods as an other,
often a built in, at which point you could substitute instance of this
new class anywhere you originally expected instance of the old class.

My experience is that this doesn't work with booleans. When I need
real booleans, encountering whatever else that can act like a boolean,
is more often than not an indication something went wrong but the
detection of it going wrong is delayed, because almost everything
can act like a boolean. It is why I have sometime found the need
to write:

if flag is True:

Because flag needed to be True, not truthy.

-- 
Antoon Pardon


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

Re: Operator Precedence/Boolean Logic

[Antoon Pardon]

Op 23-06-16 om 09:05 schreef Steven D'Aprano:
> On Thursday 23 June 2016 16:34, Andreas Röhler wrote:
>
>> Indeed, why should the result of 4 - 4 have a different truth-value than
>> 4 - 3 ?
> Because 4-4 is zero, which is "nothing", while 4-3 is one, which is 
> "something".

No zero is not nothing. If zere is nothing and an empty list is nothing,
I would expect zero to be an empty list or that they could be used 
interchangebly.

For instance in a project of mine polling for information and
receiving an empty list is different from receiving None. An empty
list means there is currently no information available. None means
The information streams came to an end.

I rarely need tests where any truthy value will branch in one
direction and any falsy value in the other. So IMO it is more
hassle than it is worth.

-- 
Antoon.


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

Re: Operator Precedence/Boolean Logic

[Marko Rauhamaa]

Antoon Pardon :

> It is why I have sometime found the need to write:
>
> if flag is True:
>
> Because flag needed to be True, not truthy.

Then, you have found the correct idiom for your rare need. You might
even want to consider:

   if flag is UP:
   ...
   elif flag is DOWN:
   ...
   else:
   assert flag is HALFMAST
   ...


I don't particularly like Python's falsey/truthy semantics, but I can
live with it. The biggest problem I have with it is the absence of an
emptiness predicate. I'd like to be able to write:

if not leftover.empty():
...

or even:

if not empty(leftover):
...

rather than having to say:

if not leftover:
...

or:

if len(leftover) > 0:# no, I'd never write this
...


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

Re: Operator Precedence/Boolean Logic

[Andreas Röhler]

On 23.06.2016 09:05, Steven D'Aprano wrote:

On Thursday 23 June 2016 16:34, Andreas Röhler wrote:


Indeed, why should the result of 4 - 4 have a different truth-value than
4 - 3 ?

Because 4-4 is zero, which is "nothing",


Hmm,  water freezes at zero degree celsius, because there is no temperature?


  while 4-3 is one, which is
"something".

You might as well ask why False and True have different truth values.
Ironically, in a manner of speaking you *did* ask that, since 4-3 == True and
4-4 == False.




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

Re: Operator Precedence/Boolean Logic

[Andreas Röhler]

On 23.06.2016 10:17, Antoon Pardon wrote:

Op 23-06-16 om 09:05 schreef Steven D'Aprano:

On Thursday 23 June 2016 16:34, Andreas Röhler wrote:


Indeed, why should the result of 4 - 4 have a different truth-value than
4 - 3 ?

Because 4-4 is zero, which is "nothing", while 4-3 is one, which is
"something".

No zero is not nothing. If zere is nothing and an empty list is nothing,
I would expect zero to be an empty list or that they could be used 
interchangebly.




There is a fundamental diff between zero and emptiness.

Zero is just a relation in the realm of integers. It tells being in the 
midst between positiv and negativ infinity.
Number one tells being one unit towards positiv infinity in relation to 
negativ infinity. And so on.


Whilst emptiness tells about non-existence.
--
https://mail.python.org/mailman/listinfo/python-list

Re: Break and Continue: While Loops

[Steven D'Aprano]

On Thursday 23 June 2016 14:17, Elizabeth Weiss wrote:

> CODE #2:
> 
> i=0
> while True:
>i=i+1
>   if i==2:
>  print("Skipping 2")
>  continue
>   if i==5:
>  print("Breaking")
>  break
>print(i)
> 
> --
> 
> Questions:
> 1. what does the word True have to do with anything here?

Consider:

"while the pasta is too hard to eat, keep boiling it"

"while you are feeling sick, stay in bed and drink plenty of fluids"

"While" repeatedly takes a condition, decides if it is true or false, and then 
decides what to do. If you give it a condition True, that's *always* true, so 
it repeats forever unless you use "break" to escape from the loop.


> 2. i=i+1- I never understand this. Why isn't it i=i+2?

i = i + 1 increase i by one each time around the loop:

i = 0, then 1, then 2, then 3, then 4...

If you used i = i+2, it would increase by two each time around the loop:

i = 0, then 2, then 4, then 6, then ...


> 3. Do the results not include 2 of 5 because we wrote if i==2 and if i==5?
> 4. How is i equal to 2 or 5 if i=0?

i starts off as 0. But then you increase it by 1 each time around the loop.


Can I ask, have you learned about for loops yet? There seems to be a fashion 
among some teachers and educators to teach while loops before for loops. I 
think that is a terrible idea, while loops are so much more complicated than 
for loops.

Try this example instead:

for i in [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]:
if i == 2:
print("skipping")
continue
if i == 5:
print("breaking")
break
print("i =", i)


The main thing you need to know to understand this is that the line "for i in 
..." sets i=0, then runs the indented block under it, then sets i=1 and runs 
the indented block, then sets i=2, and so forth. Run the code and see if it 
makes sense to you. Feel free to ask as many questions as you like!


The line "for i in [0, 1, 2, ..." is a bit wordy and verbose. Can you imagine 
if you wanted to loop 1000 times? Fortunately Python has an abbreviated 
version:

for i in range(10):
if i == 2:
print("skipping")
continue
if i == 5:
print("breaking")
break
print("i =", i)



-- 
Steve

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

Re: Operator Precedence/Boolean Logic

[Steven D'Aprano]

On Thursday 23 June 2016 18:17, Antoon Pardon wrote:

> No zero is not nothing.

I think you have just disagreed with about four thousand years of 
mathematicians and accountants.

In fact, mathematicians were so hung up about zero being nothing, that it took 
about three thousand years before they accepted zero as a number (thanks to 
Indian mathematicians, via Arab mathematicians).

> If zere is nothing and an empty list is nothing,
> I would expect zero to be an empty list or that they could be used
> interchangebly.

You must have real trouble with statically typed languages then. Some of them 
won't even let you add 0.0 + 1 (since 0.0 is a float and 1 is an int).

> For instance in a project of mine polling for information and
> receiving an empty list is different from receiving None.

Okay. How is this relevant to the question of bools? If Python had "real bools" 
(in, say, the Pascal sense) you would still need to distinguish None from an 
empty list:

if info is None:
   print("done")
elif info:  # duck-typing version
# "real bools" version uses "info != []" instead
   print("processing...")
else:
   print("nothing to process")


In fact, in this case chances are you probably don't even care to distinguish 
between empty and non-empty lists. What (I imagine) you probably care about is 
None versus any list:

if info is None:
   print("done")
else:
for item in info:
print("processing...")


> I rarely need tests where any truthy value will branch in one
> direction and any falsy value in the other.

That's reasonable. Few people do, except in the general case that they write 
some code that accepts any arbitrary truthy value. But more often, you expect 
that you are inspecting an object of some specific type, say, a sequence (list, 
tuple, deque, etc):

if seq:
process()
else:
handle_empty_case()


or a mapping (dict, UserDict, etc):

if mapping:
process()
else:
handle_empty_case()


or a Widget:

if widget:
process()
else:
handle_empty_case()


where you ask the object in question whether or not it should be considered 
empty ("nothing") or not ("something"), rather than having to call a type-
specific piece of code for each one:

if len(seq) == 0: ...

if mapping.isempty(): ...

if widget.isnullwidget(): ...



It's just duck-typing. Bools have certain behaviour in certain contexts, and 
*all* objects get the opportunity to quack like a bool in that context.



-- 
Steve

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

Re: Operator Precedence/Boolean Logic

[Lawrence D’Oliveiro]

On Thursday, June 23, 2016 at 8:17:02 PM UTC+12, Marko Rauhamaa wrote:
> if len(leftover) > 0:# no, I'd never write this
> ...

I regularly write “len(leftover) != 0”. Why not?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Operator Precedence/Boolean Logic

[Antoon Pardon]

Op 23-06-16 om 10:16 schreef Marko Rauhamaa:
> I don't particularly like Python's falsey/truthy semantics, but I can
> live with it. The biggest problem I have with it is the absence of an
> emptiness predicate. I'd like to be able to write:
>
> if not leftover.empty():
> ...
>
> or even:
>
> if not empty(leftover):
> ...
>
> rather than having to say:
>
> if not leftover:
> ...
>
> or:
>
> if len(leftover) > 0:# no, I'd never write this
> ...

Well if I have to test for emptyness, I always write

   if len(seq) > 0:

Because this will throw an exception when len can't
apply to seq and so this will catch possible bugs
sooner than writing:

  if not seq.

-- 
Antoon Pardon


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

Re: Request for opinions: A cross language development tool

[Marko Rauhamaa]

Laurent Pointal :

> Tal Zion wrote:
>> Bridge compiles Python modules into native code, 
>
> What is "native", really microprocessor executable binary ? How do you
> adapt to diversity?

They don't need to adapt to different CPU types. They can list supported
targets. Also, they could generate, say, C code to achieve a great level
of portability.

> And running such code on client side have *important* security
> concerns

That's no different for any C program running on your system. It has
access to *everything* in the vast collection of OS libraries through
direct linking and dlopen(3).

In fact, that's no different for any interpreted Python module loaded in
from PyPI.

>> so we don't implement those, and it also uses CPython's ast module in
>> order to parse Python code. So once we are done supporting all of the
>> language features, any Python code should work.
>
> Supporting features is not only parsing code, it's providing same
> execution semantic.

I think that's where the native code comes in.

> You seem to start a new, potentially complex project (devil is in
> details), ignoring other works which already did same job:

Let them. Some of the greatest things have come about that way.

> this is huge work.
>
> Bon courage.

That's the attitude!


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

Re: Operator Precedence/Boolean Logic

[Marko Rauhamaa]

Lawrence D’Oliveiro :

> On Thursday, June 23, 2016 at 8:17:02 PM UTC+12, Marko Rauhamaa wrote:
>> if len(leftover) > 0:# no, I'd never write this
>> ...
>
> I regularly write “len(leftover) != 0”. Why not?

The __len__ method is not guaranteed to execute in O(1). See:

   https://docs.python.org/3/reference/datamodel.html?highlig
   ht=__len__#object.__len__>


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

Re: Operator Precedence/Boolean Logic

[Steven D'Aprano]

On Thursday 23 June 2016 18:32, Andreas Röhler wrote:

> There is a fundamental diff between zero and emptiness.

In English, "emptiness" implies a container (real or figurative). The container 
is not "something or nothing", it is the *contents* being referred to.

"This shopping bag is empty" doesn't mean the shopping bag is nothing. It means 
that the set of items in the bad is the null set, i.e. there are ZERO items in 
the bag.

"My fridge is empty" doesn't mean that the fridge is nothing. It means that the 
set of items in the fridge is the null set, i.e. there are ZERO items in the 
fridge.

"That guy's head is empty" doesn't mean his head is nothing, it means that the 
set of thoughts in his head is the null set, i.e. he has ZERO thoughts. (This, 
of course, should be read figuratively, not literally.)


> Zero is just a relation in the realm of integers. It tells being in the
> midst between positiv and negativ infinity.

No, zero is not "a relation". It is an integer, and a very special one.

- zero is neither positive nor negative;
- zero is the additive identity: n+0 == n
- zero is multiplicative nullity;  n*0 == 0
- division by zero is undefined.

It is an artifact of the way we draw the number line (a *picture*) that zero is 
halfway between positive and negative:

<--+>
  -4   -3   -2   -101234

We could have draw it like this, with zero at the extreme left hand end:


  -3 /
 -2 /
-1 /
0 +
 1 \
  2 \
   3 \

although that would make graphing look a bit weird. 

(That's what we do with the extended Reals: we bend the number line around in a 
circle, with 0 at one pole and ±infinity at the other.)

But don't confuse the concrete representation of numbers on a line with the 
abstract numbers themselves.

In practical sense, there is a difference between having zero sheep and having 
one sheep, two sheep, three sheep, ... and of course nobody has even actually 
had negative one sheep.


> Number one tells being one unit towards positiv infinity in relation to
> negativ infinity. And so on.
> 
> Whilst emptiness tells about non-existence.

We can derive arithmetic from set theory. Zero is very special: it is defined 
as the empty set:

0: {}

The successor of zero (namely, one) is the set of all empty sets:

1: {{}}

Two is the set of zero and one:

2 = {{}, {{}}}

and so forth.



-- 
Steve

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

Re: Operator Precedence/Boolean Logic

[Antoon Pardon]

Op 23-06-16 om 10:48 schreef Steven D'Aprano:
> On Thursday 23 June 2016 18:17, Antoon Pardon wrote:
>
>> No zero is not nothing.
> I think you have just disagreed with about four thousand years of 
> mathematicians and accountants.

I don't care. In modern mathematics, zero is usaly defined as the
empty set. The empty set contains nothing, but it isn't nothing
itself. Otherwise the empty set would be the same as the set
containing the empty set, since they both would contain the same,
being nothing.

So modern mathematics seems to agree with me and that is enough
for me.

>> If zere is nothing and an empty list is nothing,
>> I would expect zero to be an empty list or that they could be used
>> interchangebly.
> You must have real trouble with statically typed languages then. Some of them 
> won't even let you add 0.0 + 1 (since 0.0 is a float and 1 is an int).

Your conclusion is a non sequitur.
 

>> For instance in a project of mine polling for information and
>> receiving an empty list is different from receiving None.
> Okay. How is this relevant to the question of bools? If Python had "real 
> bools" 
> (in, say, the Pascal sense) you would still need to distinguish None from an 
> empty list:

It illustrates the distinction python makes into truthy and falsy, is often
enough inadequate.

A language with real bools would force you to write out the actual expression
you want and wouldn't tempt you to write something you think will work out
fine.

The zen of python states that explicit is better than implicit, but the
"boolean" semantics of python seem to encourage people to rely on a
lot of implicit things that are going on.

-- 
Antoon Pardon.

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

Re: Operator Precedence/Boolean Logic

[Antoon Pardon]

Op 23-06-16 om 11:10 schreef Marko Rauhamaa:
> Lawrence D’Oliveiro :
>
>> On Thursday, June 23, 2016 at 8:17:02 PM UTC+12, Marko Rauhamaa wrote:
>>> if len(leftover) > 0:# no, I'd never write this
>>> ...
>> I regularly write “len(leftover) != 0”. Why not?
> The __len__ method is not guaranteed to execute in O(1). See:
>
>https://docs.python.org/3/reference/datamodel.html?highlig
>ht=__len__#object.__len__>

As far as I can see, neither is the __bool__ method.

-- 
Antoon.

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

Re: Operator Precedence/Boolean Logic

[Steven D'Aprano]

On Thursday 23 June 2016 17:58, Antoon Pardon wrote:

> Op 23-06-16 om 05:59 schreef Steven D'Aprano:
>> On Thu, 23 Jun 2016 01:12 pm, Larry Hudson wrote:
>>
>>> On 06/22/2016 12:42 AM, Lawrence D’Oliveiro wrote:
>>> [snip]
 I feel that’s a needlessly complicated rule. It would have been simpler
 if boolean operators (and conditional expressions like in if-statements
 and while-statements) only allowed values of boolean types. But that’s
 one of the few warts in the design of Python...

>>> Wart??  I *strongly* disagree.  I find it one of the strengths of Python,
>>> it enhances Python's
>>> expressiveness.  Of course, everyone is entitled to their own
>>> opinion...and this is mine.
>> Allowing any value as a truth value is just applying the principle of
>> duck-typing to booleans.
> 
> What does that mean? As far as I understood, duck typing was that you
> could define any class with the same attributes and methods as an other,
> often a built in, at which point you could substitute instance of this
> new class anywhere you originally expected instance of the old class.

But you only need to implement the behaviour you need, not the entire Duck 
interface. If you only need quack(), you don't need to implement swim(), or 
provide an actual Duck, any object capable of quacking will do.

To decide on a branch, you don't need an actual bool, anything capable of 
acting like a bool will do. As a language design, ALL objects are capable of 
acting like a bool. Python has a specific protocol in place for deciding 
whether an object quacks like a bool:

if the object defines __len__:
   if it returns 0, then the object is false;
   else the object is true
elif the object defines __nonzero__ (__bool__ in Python 3)
if it returns a true value, then the object is true
else the object is false
else
# neither __len__ nor __nonzero__ is defined
the object is true


> My experience is that this doesn't work with booleans. When I need
> real booleans, encountering whatever else that can act like a boolean,
> is more often than not an indication something went wrong but the
> detection of it going wrong is delayed, because almost everything
> can act like a boolean. It is why I have sometime found the need
> to write:
> 
> if flag is True:
> 
> Because flag needed to be True, not truthy.

I find this hard to believe. Why do you care if somebody passes you 1 or "T" as 
the flag instead of True? And if they do pass something other than True, you 
don't get an exception, you simply take the false branch.

Somehow I doubt that you write three-state logic everywhere:

if flag is True: ...
elif flag is False: ...
else: ...


By the way, it is a particular error of folks using so-called "real bools" to 
compare something you already know is a bool against True. I used to see it all 
the time in my Pascal days, where people would define a boolean flag then write 
"if flag == True". Given:

assert isinstance(flag, bool)

then writing 

flag is True

returns a bool. So how do you test a bool? By comparing it to True:

flag is True is True

But that also returns a bool, so you must enter an infinite regress:

flag is True is True is True is True... # help me, where do I stop???

The right answer, of course, is to stop *right at the beginning*. Stopping at 
Step 2 is silly and pointless. Since you know flag is a True or False value, 
then you just write:

flag

And the same applies to true and false values.




-- 
Steve

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

Re: Operator Precedence/Boolean Logic

[Lawrence D’Oliveiro]

On Thursday, June 23, 2016 at 9:11:05 PM UTC+12, Marko Rauhamaa wrote:
> Lawrence D’Oliveiro:
> 
>> On Thursday, June 23, 2016 at 8:17:02 PM UTC+12, Marko Rauhamaa wrote:
>>> if len(leftover) > 0:# no, I'd never write this
>>> ...
>>
>> I regularly write “len(leftover) != 0”. Why not?
> 
> The __len__ method is not guaranteed to execute in O(1).

So what is?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Operator Precedence/Boolean Logic

[Marko Rauhamaa]

Steven D'Aprano :

> On Thursday 23 June 2016 18:32, Andreas Röhler wrote:
>
>> There is a fundamental diff between zero and emptiness.
>
> In English, "emptiness" implies a container (real or figurative). The
> container is not "something or nothing", it is the *contents* being
> referred to.
>
> "This shopping bag is empty" doesn't mean the shopping bag is nothing.
> It means that the set of items in the bad is the null set, i.e. there
> are ZERO items in the bag.

I once read this puzzle in a book:

   There was a shipwreck in the middle of an ocean. The ship and the
   cargo were lost, but five sailors managed to swim to the beach of a
   nearby island. After quick scouting, the sailors realized they were
   on a tiny desert island with lots of coconut trees loaded with
   coconuts.

   The sailors set out to collect all coconuts they could find. After
   several hours, they had finished the job and made a sizeable pile of
   coconuts on the beach. They were exhausted and it was getting dark so
   they agreed to divide the pile evenly between each other on the
   following morning. They camped on the beach for the night.

   One of the sailors couldn't sleep. Would the others give him his
   share? What if they overpowered him and left him without coconuts? He
   sneaked to the pile of coconuts, split the big pile evenly into five
   smaller piles. One was left over, he threw it to a monkey that was
   watching nearby. He took his fifth, carried the coconuts to a secret
   location, and put the rest of the coconuts in a single pile so others
   wouldn't notice the loss. He went back to the camp and fell sound
   asleep.

   Another sailer woke up. What if he wouldn't get his share of the
   coconuts? He went to the big pile, divided it evenly into five
   smaller piles (one coconut was left over -- he threw it to the
   monkey), hid his share, put the big pile back together, and went to
   sleep.

   Before dawn, each of the sailors had gone through the same exercise.
   When they woke up, they went to the pile. Everyone noticed the pile
   had shrunk during the night but nobody mentioned it. They divided the
   pile evenly between the five. One coconut was left over and they
   threw it to the monkey.

   How many coconuts were there in the pile originally?


The book went on to find the answer(s), but gave also this interesting
side solution:

   The pile originally had -4 coconuts. The first sailor threw one to
   the monkey, leaving -5 coconuts in the pile. He took his share (-1
   coconut) out and put the remaining -4 coconuts back in the big pile.

   And so on.


Ridiculous? It was this line of thinking that led Paul Dirac to predict
the existence of antimatter.


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

Re: Operator Precedence/Boolean Logic

[Andreas Röhler]

On 23.06.2016 11:17, Steven D'Aprano wrote:

[ ... ]
We can derive arithmetic from set theory.


IMO not, resp. not really. But that would make a another item, pretty 
off-topic from Python.


Should you know a place where to continue, would like to follow up.

Thanks BTW.


  Zero is very special: it is defined
as the empty set:

0: {}

The successor of zero (namely, one) is the set of all empty sets:

1: {{}}

Two is the set of zero and one:

2 = {{}, {{}}}

and so forth.





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

Re: Break and Continue: While Loops

[alister]

On Wed, 22 Jun 2016 21:17:03 -0700, Elizabeth Weiss wrote:

> CODE #1:
> 
> i=0 while 1==1:
>print(i)
>i=i+1 if i>=5:
>  print("Breaking") break
> 
> --
> I understand that i=0 and i will only be printed if 1=1 The results of
> this is 0
> 1
> 2
> 3
> 4
> Breaking
> 
> Why is Breaking going to be printed if i only goes up to 4? It does say
> if i>=5? Shouldn't this mean that the results should be:
> 0
> 1
> 2
> 3
> 4
> 5
> 
> CODE #2:
> 
> i=0 while True:
>i=i+1
>   if i==2:
>  print("Skipping 2")
>  continue
>   if i==5:
>  print("Breaking") break
>print(i)
> 
> --
> 
> Questions:
> 1. what does the word True have to do with anything here?
> 2. i=i+1- I never understand this. Why isn't it i=i+2?
> 3. Do the results not include 2 of 5 because we wrote if i==2 and if
> i==5?
> 4. How is i equal to 2 or 5 if i=0?
> 
> Thanks for all of your help!

unrelated to your question

while 1==1

Don't do this.

code 2 you correctly use while True

to see the problem with your code
try following it through line by line with a pen & paper
writing the value for I each time it is changed.
(this is known in the trade as a "Dry Run")





-- 
Fame is a vapor; popularity an accident; the only earthly certainty is
oblivion.
-- Mark Twain
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Operator Precedence/Boolean Logic

[Marko Rauhamaa]

Lawrence D’Oliveiro :

> On Thursday, June 23, 2016 at 9:11:05 PM UTC+12, Marko Rauhamaa wrote:
>> The __len__ method is not guaranteed to execute in O(1).
>
> So what is?

The __bool__ method is the appropriate place to implement an efficient
emptiness check. It might not be O(1) but it will be the most efficient
way to check for emptiness, or the class is badly implemented.


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

Re: Operator Precedence/Boolean Logic

[Marko Rauhamaa]

Antoon Pardon :

> Op 23-06-16 om 11:10 schreef Marko Rauhamaa:
>> The __len__ method is not guaranteed to execute in O(1). See:
>>
>>https://docs.python.org/3/reference/datamodel.html?highlig
>>ht=__len__#object.__len__>
>
> As far as I can see, neither is the __bool__ method.

Correct, but in the absence of an __empty__ method, __bool__ gives the
class the best opportunity to check for emptiness quickly.

This is not only a theoretical concern. It's quite common for data
structures not to maintain an element count because it's extra baggage
that's not always needed and any application could keep a track of.
However, an emptiness check is often trivial.


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

Re: Operator Precedence/Boolean Logic

[Andreas Röhler]

On 23.06.2016 11:46, Marko Rauhamaa wrote:


Ridiculous? It was this line of thinking that led Paul Dirac to predict
the existence of antimatter.


Marko


Yeah. Maybe we could construct examples already using antagonistic 
charges of electrons?

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

Re: Break and Continue: While Loops

[BartC]

On 23/06/2016 05:17, Elizabeth Weiss wrote:

CODE #1:



i=0
while True:
   i=i+1
  if i==2:
 print("Skipping 2")
 continue
  if i==5:
 print("Breaking")
 break
   print(i)

--

Questions:
2. i=i+1- I never understand this. Why isn't it i=i+2?
3. Do the results not include 2 of 5 because we wrote if i==2 and if i==5?
4. How is i equal to 2 or 5 if i=0?


i=0 doesn't mean that 'i' is equal to 0.

In Python, "=" means 'assignment'. Something more like this:

  SET i to 0

i=i+1 means:

  SET i to i+1

'i' is a name for some value. The value of 'i' can change, usually 
through assignments. If 'i' currently has the value 37, then:


  SET i to i+1

will now store i+1 (ie. 38) into 'i'. Repeating that will set 'i' to 39 
and so on.


To test if 'i' has a certain value, then '==' is used (to distinguish it 
from '=' which means SET).


So i==37 will give True if i currently has a value of 37, or False 
otherwise. This is used in your code:


  if i==2:
 print ("Skipping 2")
 continue

The indented lines are executed when i has the value 2.

> 1. what does the word True have to do with anything here?

The 'while' statement (like others such as 'if') takes an expression 
that should give True or False. If True, the loop is executed once more.


Actually pretty much any expression can be used, because Python can 
interpret almost anything as either True or False. Don't ask for the 
rules because they can be complicated, but for example, zero is False, 
and any other number is True. I think.


Anyway, your code is doing an endless loop. Python doesn't have a 
dedicated statement for an endless loop, so you have to use 'while True' 
or 'while 1'.


(Well, the loop is only endless until you do an explicit exit out of it, 
such as using 'break'.)


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

Re: Operator Precedence/Boolean Logic

[Antoon Pardon]

Op 23-06-16 om 11:39 schreef Steven D'Aprano:
> On Thursday 23 June 2016 17:58, Antoon Pardon wrote:
>
>> Op 23-06-16 om 05:59 schreef Steven D'Aprano:
>>> On Thu, 23 Jun 2016 01:12 pm, Larry Hudson wrote:
>>>
 On 06/22/2016 12:42 AM, Lawrence D’Oliveiro wrote:
 [snip]
> I feel that’s a needlessly complicated rule. It would have been simpler
> if boolean operators (and conditional expressions like in if-statements
> and while-statements) only allowed values of boolean types. But that’s
> one of the few warts in the design of Python...
>
 Wart??  I *strongly* disagree.  I find it one of the strengths of Python,
 it enhances Python's
 expressiveness.  Of course, everyone is entitled to their own
 opinion...and this is mine.
>>> Allowing any value as a truth value is just applying the principle of
>>> duck-typing to booleans.
>> What does that mean? As far as I understood, duck typing was that you
>> could define any class with the same attributes and methods as an other,
>> often a built in, at which point you could substitute instance of this
>> new class anywhere you originally expected instance of the old class.
> But you only need to implement the behaviour you need, not the entire Duck 
> interface. If you only need quack(), you don't need to implement swim(), or 
> provide an actual Duck, any object capable of quacking will do.
>
> To decide on a branch, you don't need an actual bool, anything capable of 
> acting like a bool will do. As a language design, ALL objects are capable of 
> acting like a bool. Python has a specific protocol in place for deciding 
> whether an object quacks like a bool:

But an object acting like a bool, doesn't mean this bool behaviour makes the
disctinction you actually need. Python tempts people to rely on those truthy
values, because it saves typing is pythonic and it works for the moment and
then something unexpected gets passed through and you find yourself chasing
a very illusive bug. 

>> My experience is that this doesn't work with booleans. When I need
>> real booleans, encountering whatever else that can act like a boolean,
>> is more often than not an indication something went wrong but the
>> detection of it going wrong is delayed, because almost everything
>> can act like a boolean. It is why I have sometime found the need
>> to write:
>>
>> if flag is True:
>>
>> Because flag needed to be True, not truthy.
> I find this hard to believe. Why do you care if somebody passes you 1 or "T" 
> as 
> the flag instead of True? And if they do pass something other than True, you 
> don't get an exception, you simply take the false branch.
>
> Somehow I doubt that you write three-state logic everywhere:

Since I wrote above the I *sometimes* found this need. You may
safely assume I don't write it everywhere.

>
> if flag is True: ...
> elif flag is False: ...
> else: ...
>
>
> By the way, it is a particular error of folks using so-called "real bools" to 
> compare something you already know is a bool against True. I used to see it 
> all 
> the time in my Pascal days, where people would define a boolean flag then 
> write 
> "if flag == True". Given:
>
> assert isinstance(flag, bool)

But of course if one would show such a line in code on this
list, it would illicit a lot of comments on how unpythonic this
this is and that you really shouldn't, and that you should realy
rely on an exception being thrown when what you are provided
doesn't work.

You come here with a remark depending on not using duck typing
when you start your contribution with defending duck typing.

-- 
Antoon.

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

RE: Guys, can you please share me some sites where we can practice python programs for beginners and Intermediate.

[Joe Gulizia]

From: Python-list  on 
behalf of Pushpanth Gundepalli 
Sent: Thursday, June 23, 2016 12:35 AM
To: python-list@python.org
Subject: Re: Guys, can you please share me some sites where we can practice 
python programs for beginners and Intermediate.

On Tuesday, June 21, 2016 at 4:33:28 PM UTC+5:30, Pushpanth Gundepalli wrote:
> Guys, can you please share me some sites where we can practice python 
> programs for beginners and Intermediate.

Thank you for ur valuable suggestions.. Actually i have done practising the 
exercises on codeacademy, codingbat. But the thing is that i want to do a live 
project which wil help me to enchance my skills more.. I'm happy tht I'm able 
to understand and write small lines of code(i think it is a small achivement 
for me and it boost my confidence).. but i need to improve more on 
programming.. Also pls help me out on how I can get some real time projects to 
practice!!
--
https://mail.python.org/mailman/listinfo/python-list







Computer Science Circles - University of Waterloo

http://cscircles.cemc.uwaterloo.ca

Almost any open source project welcomes volunteersI'd start with FSF.org 
(Free Software Foundation) or EFSF (European FSF) https://fsfe.org/

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

Re: Operator Precedence/Boolean Logic

[Antoon Pardon]

Op 23-06-16 om 11:53 schreef Marko Rauhamaa:
> Antoon Pardon :
>
>> Op 23-06-16 om 11:10 schreef Marko Rauhamaa:
>>> The __len__ method is not guaranteed to execute in O(1). See:
>>>
>>>https://docs.python.org/3/reference/datamodel.html?highlig
>>>ht=__len__#object.__len__>
>> As far as I can see, neither is the __bool__ method.
> Correct, but in the absence of an __empty__ method, __bool__ gives the
> class the best opportunity to check for emptiness quickly.
>
> This is not only a theoretical concern. It's quite common for data
> structures not to maintain an element count because it's extra baggage
> that's not always needed and any application could keep a track of.
> However, an emptiness check is often trivial.

Maybe something like this:

def empty(sq):
try:
iter(sq).next()
except StopIteration:
return False
except:
raise TypeError
else:
return True

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

Re: Operator Precedence/Boolean Logic

[Marko Rauhamaa]

Antoon Pardon :

> Op 23-06-16 om 11:53 schreef Marko Rauhamaa:
> Maybe something like this:
>
> def empty(sq):
> try:
> iter(sq).next()
> except StopIteration:
> return False
> except:
> raise TypeError
> else:
> return True

That may or may not be as effective as a boolean check. The point is,
Python has already declared that __bool__ is the canonical emptiness
checker. You could even say that it's the principal purpose of the
__bool__ method.


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

Re: Operator Precedence/Boolean Logic

[Antoon Pardon]

Op 23-06-16 om 12:59 schreef Marko Rauhamaa:
> Antoon Pardon :
>
>> Op 23-06-16 om 11:53 schreef Marko Rauhamaa:
>> Maybe something like this:
>>
>> def empty(sq):
>> try:
>> iter(sq).next()
>> except StopIteration:
>> return False
>> except:
>> raise TypeError
>> else:
>> return True
> That may or may not be as effective as a boolean check. The point is,
> Python has already declared that __bool__ is the canonical emptiness
> checker. You could even say that it's the principal purpose of the
> __bool__ method.

I think it is wrong to say __bool__ is the canonical emptiness checker.
It can be used for anything where you somehow think it is reasonable
to make a distinction between truthy and falsy. Even when talking
about emptyness doesn't make sense.

The function above at least raises an exception in a lot of cases
where the class provides booly behaviour yet emptyness wouldn't make
sense.

Would it be worth while? That you have to decide for yourself.

-- 
Antoon. 
 

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

Re: Break and Continue: While Loops

[Chris Angelico]

On Thu, Jun 23, 2016 at 8:15 PM, BartC  wrote:
> Actually pretty much any expression can be used, because Python can
> interpret almost anything as either True or False. Don't ask for the rules
> because they can be complicated, but for example, zero is False, and any
> other number is True. I think.

The rules are very simple. Anything that represents "something" is
true, and anything that represents "nothing" is false. An empty
string, an empty list, an empty set, and the special "None" object
(generally representing the absence of some other object) are all
false. A string with something in it (eg "Hello"), a list with
something in it (eg [1,2,4,8]), etc, etc, are all true.

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

Re: Operator Precedence/Boolean Logic

[Chris Angelico]

On Thu, Jun 23, 2016 at 7:23 PM, Antoon Pardon
 wrote:
> I don't care. In modern mathematics, zero is usaly defined as the
> empty set. The empty set contains nothing, but it isn't nothing
> itself. Otherwise the empty set would be the same as the set
> containing the empty set, since they both would contain the same,
> being nothing.

Zero is *the cardinality of* the empty set. The set containing the
empty set has a cardinality of 1.

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

Re: Break and Continue: While Loops

[Jon Ribbens]

On 2016-06-23, Chris Angelico  wrote:
> On Thu, Jun 23, 2016 at 8:15 PM, BartC  wrote:
>> Actually pretty much any expression can be used, because Python can
>> interpret almost anything as either True or False. Don't ask for the rules
>> because they can be complicated, but for example, zero is False, and any
>> other number is True. I think.
>
> The rules are very simple. Anything that represents "something" is
> true, and anything that represents "nothing" is false. An empty
> string, an empty list, an empty set, and the special "None" object
> (generally representing the absence of some other object) are all
> false. A string with something in it (eg "Hello"), a list with
> something in it (eg [1,2,4,8]), etc, etc, are all true.

Exactly. This is a major everyday strength of Python in my view.

I seem to recall that Java originally insisted that only booleans
(excluding even Booleans, which are a different thing because of
course they are) could be checked for truth and it was one of
Java's significant warts.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Operator Precedence/Boolean Logic

[Jussi Piitulainen]

Antoon Pardon writes:

> Op 23-06-16 om 12:59 schreef Marko Rauhamaa:
>> Antoon Pardon :
>>
>>> Op 23-06-16 om 11:53 schreef Marko Rauhamaa:
>>> Maybe something like this:
>>>
>>> def empty(sq):
>>> try:
>>> iter(sq).next()
>>> except StopIteration:
>>> return False
>>> except:
>>> raise TypeError
>>> else:
>>> return True
>> That may or may not be as effective as a boolean check. The point is,
>> Python has already declared that __bool__ is the canonical emptiness
>> checker. You could even say that it's the principal purpose of the
>> __bool__ method.
>
> I think it is wrong to say __bool__ is the canonical emptiness checker.
> It can be used for anything where you somehow think it is reasonable
> to make a distinction between truthy and falsy. Even when talking
> about emptyness doesn't make sense.
>
> The function above at least raises an exception in a lot of cases
> where the class provides booly behaviour yet emptyness wouldn't make
> sense.

It also *changes* many things where emptiness *would* make sense. In
particular, it can first *make* a thing empty and then happily declare
it not empty. Not good.

Is "sq" mnemonic for something?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Operator Precedence/Boolean Logic

[Antoon Pardon]

Op 23-06-16 om 13:45 schreef Chris Angelico:
> On Thu, Jun 23, 2016 at 7:23 PM, Antoon Pardon
>  wrote:
>> I don't care. In modern mathematics, zero is usaly defined as the
>> empty set. The empty set contains nothing, but it isn't nothing
>> itself. Otherwise the empty set would be the same as the set
>> containing the empty set, since they both would contain the same,
>> being nothing.
> Zero is *the cardinality of* the empty set. The set containing the
> empty set has a cardinality of 1.

In modern set theory where the integers are defined as specific kind
of sets, zero *is* the empty set.

-- 
Antoon.

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

Re: Operator Precedence/Boolean Logic

[Chris Angelico]

On Thu, Jun 23, 2016 at 10:05 PM, Jussi Piitulainen
 wrote:
> Is "sq" mnemonic for something?

Presumably "sequence", which fits the other assumption that you noted:
that calling 'iter' on it will produce a non-destructive iterator.

I hope that code is never used on older Pythons that don't have
exception chaining, given that it has a bare except in it. Actually, I
hope that code is never used at all.

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

Re: Operator Precedence/Boolean Logic

[Andreas Röhler]

On 23.06.2016 14:08, Antoon Pardon wrote:

Op 23-06-16 om 13:45 schreef Chris Angelico:

On Thu, Jun 23, 2016 at 7:23 PM, Antoon Pardon
 wrote:

I don't care. In modern mathematics, zero is usaly defined as the
empty set. The empty set contains nothing, but it isn't nothing
itself. Otherwise the empty set would be the same as the set
containing the empty set, since they both would contain the same,
being nothing.

Zero is *the cardinality of* the empty set. The set containing the
empty set has a cardinality of 1.

In modern set theory where the integers are defined as specific kind
of sets, zero *is* the empty set.



Modes are like waves. If one wave arrives being "modern", lets watch out 
for the next.


There not just one set-theory, math is neither revealed nor received on 
some mount - even if the notion of truth has some theological 
connotations ;)

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

not able to install mysqldb-python

[Arshpreet Singh]

I am trying to run django project in virtual environment. it needs mysql 
database library but when I try to install that it returns the error that 
configparser is not installed but I have installed configparser still the error 
remains same, is this ubuntu bug?


(env) ubuntu@ip-:~/clearapp$ pip install ConfigParser
Requirement already satisfied (use --upgrade to upgrade): ConfigParser in 
./env/lib/python3.4/site-packages
(env) ubuntu@ip-172-31-56-59:~/clearapp$ pip install configparser
Requirement already satisfied (use --upgrade to upgrade): configparser in 
./env/lib/python3.4/site-packages
(env) ubuntu@ip-172-31-56-59:~/clearapp$ pip install MySQL-python
Collecting MySQL-python
  Using cached MySQL-python-1.2.5.zip
Complete output from command python setup.py egg_info:
Traceback (most recent call last):
  File "", line 1, in 
  File "/tmp/pip-build-rrhl9079/MySQL-python/setup.py", line 13, in 
from setup_posix import get_config
  File "/tmp/pip-build-rrhl9079/MySQL-python/setup_posix.py", line 2, in 

from ConfigParser import SafeConfigParser
ImportError: No module named 'ConfigParser'


Command "python setup.py egg_info" failed with error code 1 in 
/tmp/pip-build-rrhl9079/MySQL-python/
(env) ubuntu@ip-172-31-56-59:~/clearapp$ 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Operator Precedence/Boolean Logic

[Steven D'Aprano]

On Thu, 23 Jun 2016 08:21 pm, Antoon Pardon wrote:

> Op 23-06-16 om 11:39 schreef Steven D'Aprano:
[...]
>> To decide on a branch, you don't need an actual bool, anything capable of
>> acting like a bool will do. As a language design, ALL objects are capable
>> of acting like a bool. Python has a specific protocol in place for
>> deciding whether an object quacks like a bool:
> 
> But an object acting like a bool, doesn't mean this bool behaviour makes
> the disctinction you actually need. 

Um... okay?

I'm not really sure I understand the point you think your making. Lists and
tuples can be exchanged in many duck-typing situations, but if you need
something with an in-place sort method, you can't use a tuple. That's a
given. If you need some feature that isn't offered by truthiness, you can't
use truthiness to detect that feature. It seems hardly worth mentioning.


> Python tempts people to rely on those 
> truthy values, because it saves typing is pythonic and it works for the
> moment and then something unexpected gets passed through and you find
> yourself chasing a very illusive bug.

You keep saying that, but I've never seen it happen. I've seen cases where
people have been surprised by the unexpected truthiness of an object ("I
expected an exhausted iterator to be false, but it was true"), but that's
not what you seem to be describing.

To be honest, I'm not sure what you are describing. Your explanation is
maddeningly vague. Since bools offer a *very small* API (beyond what they
also offer as a subclass of int), I cannot imagine what unexpected thing
you might get passed in that leads to "a very illusive bug".

The bottom line is, bools offer only a single major API[1]: are they truthy,
or falsey? What else can do you with them? Nothing. They support
conditional branches, and boolean operators "or" and "and". That's all.
They don't have methods to call, or attributes to set. You can use a bool
to take the if branch, or the else branch, and that's effectively all.

Since *all* objects support that same bool API, what can you *possibly* be
passed in place of a bool that fails to work?

I acknowledge, cheerfully, that there might be a mismatch between what you
expect and what the object actually does. "I expect empty containers to be
falsey, and non-empty ones to be truthy; but this RedBlackTree object is
always false even if it has many items; and this SortedDict is always true
even when it is empty."

That's a nuisance and a pain when it happens, but it's arguably a bug in the
object or at least a misfeature, and besides that's the risk when you
duck-type. You're trusting the object that you get to behave like the
object you expect, or it will break things.

(An object with a misbehaving __bool__ is no better or worse than an object
with a misbehaving sort() method, or __add__ method.)

So I'm not really sure what you are trying to describe. I guess it might be
something like this:

def spam(alist):
if alist:
process(alist)
else:
print("empty list")


If you pass 1 instead of an actual list, then you don't get an error until
somewhere inside process(). Potentially far, far away. So you want to
write:

def spam(alist):
if len(alist):
process(alist)  # requires an actual list
else:
print("empty list")


and now calling spam(1) will raise immediately. Great.

But that's not really anything to do with *bools* specifically. If you call
spam() with a dict, or a set, or a tuple, or a RedBlackTree, any other
object with a length, you're no better off. If you absolutely need a list,
and nothing else, then you have to type-check.

In practice, I don't see how truthy/falsey objects lead to more or worse
bugs than any other form of dynamic typing.

To me, your position is equivalent to saying that dynamic typing and
duck-typing is really great, except for len(). len() should absolutely only
work on lists, and nothing else, so any time you want to get the length of
an object, you must work with real lists, not listy sequences:

if len(list(mystring)) > 20: ...

print(len(list(mydict.keys())), "items")


etc. Substitute "bool" for "len" and you might understand how I feel about
your position.


[...]
>> Somehow I doubt that you write three-state logic everywhere:
> 
> Since I wrote above the I *sometimes* found this need. You may
> safely assume I don't write it everywhere.

Fair enough.




[1] I exclude minor things like repr(True), and the fact that they are
subclassed from int.
 

-- 
Steven

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

Re: not able to install mysqldb-python

[INADA Naoki]

Try this
https://pypi.python.org/pypi/mysqlclient

On Thu, Jun 23, 2016 at 9:11 PM, Arshpreet Singh  wrote:
> I am trying to run django project in virtual environment. it needs mysql 
> database library but when I try to install that it returns the error that 
> configparser is not installed but I have installed configparser still the 
> error remains same, is this ubuntu bug?
>
>
> (env) ubuntu@ip-:~/clearapp$ pip install ConfigParser
> Requirement already satisfied (use --upgrade to upgrade): ConfigParser in 
> ./env/lib/python3.4/site-packages
> (env) ubuntu@ip-172-31-56-59:~/clearapp$ pip install configparser
> Requirement already satisfied (use --upgrade to upgrade): configparser in 
> ./env/lib/python3.4/site-packages
> (env) ubuntu@ip-172-31-56-59:~/clearapp$ pip install MySQL-python
> Collecting MySQL-python
>   Using cached MySQL-python-1.2.5.zip
> Complete output from command python setup.py egg_info:
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "/tmp/pip-build-rrhl9079/MySQL-python/setup.py", line 13, in 
> 
> from setup_posix import get_config
>   File "/tmp/pip-build-rrhl9079/MySQL-python/setup_posix.py", line 2, in 
> 
> from ConfigParser import SafeConfigParser
> ImportError: No module named 'ConfigParser'
>
> 
> Command "python setup.py egg_info" failed with error code 1 in 
> /tmp/pip-build-rrhl9079/MySQL-python/
> (env) ubuntu@ip-172-31-56-59:~/clearapp$
> --
> https://mail.python.org/mailman/listinfo/python-list



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

Re: Operator Precedence/Boolean Logic

[Random832]

On Thu, Jun 23, 2016, at 02:34, Andreas Röhler wrote:
> Indeed, why should the result of 4 - 4 have a different truth-value
> than 4 - 3 ? This implementation seems to be a legacy from languages
> without boolean types.

A set which included Python until version 2.3.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Operator Precedence/Boolean Logic

[Antoon Pardon]

Op 23-06-16 om 14:37 schreef Steven D'Aprano:

> So I'm not really sure what you are trying to describe. I guess it might be
> something like this:
>
> def spam(alist):
> if alist:
> process(alist)
> else:
> print("empty list")
>
>
> If you pass 1 instead of an actual list, then you don't get an error until
> somewhere inside process(). Potentially far, far away. So you want to
> write:
>
> def spam(alist):
> if len(alist):
> process(alist)  # requires an actual list
> else:
> print("empty list")
>
>
> and now calling spam(1) will raise immediately. Great.
>
> But that's not really anything to do with *bools* specifically. If you call
> spam() with a dict, or a set, or a tuple, or a RedBlackTree, any other
> object with a length, you're no better off. If you absolutely need a list,
> and nothing else, then you have to type-check.

Yes it has to do with the booly nature of python objects. The fact that your
examples still allows for bugs, doesn't contradict it already cathes a lot
of bugs. So yes I'm better of even if I am not completly save. Encouraging
the user to write explicit test, will detect bugs sooner and will make
it more probable the code behaves as expected even when the tests are done
one an unexpected kind of object.

> In practice, I don't see how truthy/falsey objects lead to more or worse
> bugs than any other form of dynamic typing.

Sure, this from a language that states that explicit is better than implicit.
The truthy/falsy objects encourage people to be implicit and thus allowing
a lot of things to pass that were originally not though off.

> To me, your position is equivalent to saying that dynamic typing and
> duck-typing is really great, except for len(). len() should absolutely only
> work on lists, and nothing else, so any time you want to get the length of
> an object, you must work with real lists, not listy sequences:
>
> if len(list(mystring)) > 20: ...
>
> print(len(list(mydict.keys())), "items")
>
>
> etc. Substitute "bool" for "len" and you might understand how I feel about
> your position.

IMO, bool is like you would give any object a lengthy nature and so having any
object also behave like a tuple with the object as it's only item. Then bool and
len would be similar. 

-- 
Antoon.

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

Re: Operator Precedence/Boolean Logic

[Random832]

On Thu, Jun 23, 2016, at 08:37, Steven D'Aprano wrote:
> You keep saying that, but I've never seen it happen. I've seen cases
> where people have been surprised by the unexpected truthiness of an
> object ("I expected an exhausted iterator to be false, but it was
> true"), but that's not what you seem to be describing.

I suspect that he's referring to cases like
http://bugs.python.org/issue4945 where a set of flags that are expected
to be bool under normal circumstances are interchangeably tested with
==, is, boolean checks, and the inversion of any of those.

If you test with "== True", then you treat 2 as non-truthy. If you test
with "is True", then you treat 1 as non-truthy. And the reverse of
either may treat 0 as truthy. If you mix and match any truth-test (e.g.
"== True") with anything that is not its opposite ("!= True", not e.g.
"== False") you may end up with situations where neither branch was
taken and your result is an unexpected state.

I don't actually agree with him that the object being passed in can be
blamed for this class of error.

It also occurs to me you could conceivably run into problems if you use
a passed-in mutable object as a flag to be tested multiple times.

> The bottom line is, bools offer only a single major API[1]: are they
> truthy, or falsey? What else can do you with them? Nothing. They
> support conditional branches, and boolean operators "or" and "and".
> That's all. They don't have methods to call, or attributes to set. You
> can use a bool to take the if branch, or the else branch, and that's
> effectively all.

Don't forget, they're integers valued 0 and 1. So you can multiply it by
a number to get 0 or that number. I recently did so (in a code golf
challenge, not serious code). You can sum an iterable of them to get a
count of true items.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Can math.atan2 return INF?

[Ben Bacarisse]

Steven D'Aprano  writes:

> On Thu, 23 Jun 2016 05:17 am, Ben Bacarisse wrote:
>
>> pdora...@pas-de-pub-merci.mac.com (Pierre-Alain Dorange) writes:
>> 
>>> Ben Bacarisse  wrote:
>>>
   >>> math.atan2(INF, INF)
   0.7853981633974483
 
 I would have expected NaN since atan2(INF, INF) could be thought of as
 the limit of atan2(x, y) which could be any value in the range.  And I'd
 have guessed atan2(0, 0) would have been NaN too but
>>>
>>> i'm not a math expert, but the limit of atan2 would be 45°, so pi/4
>>> radians (0,7854).
>>> As x,y are coordinates, the both infinite would tend toward 45°.
>> 
>> The limit of atan2(x, x) is as you describe, but there is no reason to
>> pick that one case.
>
> Given:
>
> x = INF
> y = INF
> assert x == y
>
> there is a reason to pick atan2(y, x) = pi/4:
>
> Since x == y, the answer should be the same as for any other pair of x == y.
>
> It might not be a *great* reason, but it's a reason.

...provided you consider atan2(0, 0) == 0 to be a bug!

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

Re: Can math.atan2 return INF?

[Ben Bacarisse]

Steven D'Aprano  writes:

> On Thursday 23 June 2016 14:40, Dan Sommers wrote:
>
>>> Since x == y, the answer should be the same as for any other pair of x == y.
>> 
>> When x == y == 0, then atan2(y, x) is 0.

I see just added noise by making the same comment before reading the
rest of the thread.  Sorry.

> /s/any other pair of x == y/any other pair of x y except for zero/
>
> :-P
>
>
> Zero is exceptional in many ways.

whereas infinity...  :-)

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

Re: Can math.atan2 return INF?

[alister]

On Thu, 23 Jun 2016 15:39:43 +0100, Ben Bacarisse wrote:

> Steven D'Aprano  writes:
> 
>> On Thursday 23 June 2016 14:40, Dan Sommers wrote:
>>
 Since x == y, the answer should be the same as for any other pair of
 x == y.
>>> 
>>> When x == y == 0, then atan2(y, x) is 0.
> 
> I see just added noise by making the same comment before reading the
> rest of the thread.  Sorry.
> 
>> /s/any other pair of x == y/any other pair of x y except for zero/
>>
>> :-P
>>
>>
>> Zero is exceptional in many ways.
> 
> whereas infinity...  :-)

which infinity. There are many - some larger than others 



-- 
| |-sshd---tcsh-+-dpkg-buildpacka---rules---sh---make---make---sh---
make---sh---make---sh---make---sh---make---sh---make
-- While packaging XFree86 for Debian GNU/Linux
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Guys, can you please share me some sites where we can practice python programs for beginners and Intermediate.

[Cousin Stanley]

DFS wrote:

> Here's a fun one: scraping data off a website, 
> and storing it in a SQLite database file.
> 

  After testing your example code here I found 
  that the length of the  categories  list
  was 1 less than the  terms  list after applying
  dropwords in the  terms  list comprehension  

  The subsequent len comparison then failed
  and no data was inserted into the data base  

  As a fix I added an extra category 

category.append( 'didly' )
  
  Subsequently, data was inserted
  with a single extra category 
  for the  last  term in terms  
  

  Thanks for posting the example code 


-- 
Stanley C. Kitching
Human Being
Phoenix, Arizona

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

Re: Operator Precedence/Boolean Logic

[Chris Angelico]

On Thu, Jun 23, 2016 at 10:37 PM, Steven D'Aprano  wrote:
> I acknowledge, cheerfully, that there might be a mismatch between what you
> expect and what the object actually does. "I expect empty containers to be
> falsey, and non-empty ones to be truthy; but this RedBlackTree object is
> always false even if it has many items; and this SortedDict is always true
> even when it is empty."
>
> That's a nuisance and a pain when it happens, but it's arguably a bug in the
> object or at least a misfeature...

As evidenced by the change to time truthiness, yes, that's the
object's fault. If your RedBlackTree object were always *true*, I'd
call it a missing feature ("please add a __bool__ that distinguishes
empty trees from trees with content"), but always *false* would be a
bug. A SortedDict implies by its name that it should be extremely
dict-like, so that would be a strong argument for its truthiness to
follow a dict's. Either way, the misbehaviour gets pointed back at the
object in question.

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

Re: Break and Continue: While Loops

[BartC]

On 23/06/2016 12:39, Chris Angelico wrote:

On Thu, Jun 23, 2016 at 8:15 PM, BartC  wrote:

Actually pretty much any expression can be used, because Python can
interpret almost anything as either True or False. Don't ask for the rules
because they can be complicated, but for example, zero is False, and any
other number is True. I think.


The rules are very simple. Anything that represents "something" is
true, and anything that represents "nothing" is false. An empty
string, an empty list, an empty set, and the special "None" object
(generally representing the absence of some other object) are all
false. A string with something in it (eg "Hello"), a list with
something in it (eg [1,2,4,8]), etc, etc, are all true.


Maybe I was thinking of 'is' where sometimes the results are unintuitive.

But even with ordinary conditionals, False is False, but [False] is 
True. And [] is False, while [[]] is True. A class instance is always 
True, even when empty. And then "False" is True as well!


--
Bartc

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

Re: Break and Continue: While Loops

[Chris Angelico]

On Fri, Jun 24, 2016 at 1:52 AM, BartC  wrote:
> On 23/06/2016 12:39, Chris Angelico wrote:
>>
>> On Thu, Jun 23, 2016 at 8:15 PM, BartC  wrote:
>>>
>>> Actually pretty much any expression can be used, because Python can
>>> interpret almost anything as either True or False. Don't ask for the
>>> rules
>>> because they can be complicated, but for example, zero is False, and any
>>> other number is True. I think.
>>
>>
>> The rules are very simple. Anything that represents "something" is
>> true, and anything that represents "nothing" is false. An empty
>> string, an empty list, an empty set, and the special "None" object
>> (generally representing the absence of some other object) are all
>> false. A string with something in it (eg "Hello"), a list with
>> something in it (eg [1,2,4,8]), etc, etc, are all true.
>
>
> But even with ordinary conditionals, False is False, but [False] is True.
> And [] is False, while [[]] is True. A class instance is always True, even
> when empty. And then "False" is True as well!

[False] is a list with something in it. So is [[]]. "False" is a
string with something in it, and honestly, if you think that ought to
come out falsey, you're asking for magic. I don't know what you mean
by a "class instance", or how it would be empty, but if you're
creating a custom class and it might sometimes represent emptiness,
you need to define either __len__ or __bool__ so the interpreter can
understand what you mean by "empty".

> Maybe I was thinking of 'is' where sometimes the results are unintuitive.
>

Not at all. The 'is' operator tells you whether the left and right
operands are the same object. That's it. Maybe you have unintuitive
situations where you don't realize you have the same object (or don't
realize you have different objects), but the operator itself still has
one very simple rule to follow.

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

Re: Guys, can you please share me some sites where we can practice python programs for beginners and Intermediate.

[Cousin Stanley]

DFS wrote:

> On 6/23/2016 11:11 AM, Cousin Stanley wrote:
>> DFS wrote:
>>
>>> Here's a fun one: scraping data off a website,
>>> and storing it in a SQLite database file.
>>> 
>>
>>   After testing your example code here I found
>>   that the length of the  categories  list
>>   was 1 less than the  terms  list after applying
>>   dropwords in the  terms  list comprehension 
>>
>>   The subsequent len comparison then failed
>>   and no data was inserted into the data base 
>>
>>   As a fix I added an extra category 
>>
>> category.append( 'didly' )
>>
>>   Subsequently, data was inserted
>>   with a single extra category
>>   for the  last  term in terms 
> 
> 
> Strange!  After dropwords, the list lengths match 
> for me (both are 152).
> 

  Found 153 for terms and 152 for categories,
  so I appended 1 to categories ...

> So in your table, is 'didly' now the category for the last term

> 'Rendering'?  Mine is 'Technical', as it is on the source webpage.

  Last 5 printed from the final loop 
  just before the db insert  


Passphrase , Technical
Passcode , Technical
Touchpad , Hardware
Rendering , Technical
Terms of Use , didly

> 
> I usually put list length tests in place, 
> not sure what happened here.

  Possibly a copy/paste difference
  on my end 
 

-- 
Stanley C. Kitching
Human Being
Phoenix, Arizona

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

Re: Operator Precedence/Boolean Logic

[Steven D'Aprano]

On Thu, 23 Jun 2016 11:26 pm, Random832 wrote:

> On Thu, Jun 23, 2016, at 08:37, Steven D'Aprano wrote:
>> You keep saying that, but I've never seen it happen. I've seen cases
>> where people have been surprised by the unexpected truthiness of an
>> object ("I expected an exhausted iterator to be false, but it was
>> true"), but that's not what you seem to be describing.
> 
> I suspect that he's referring to cases like
> http://bugs.python.org/issue4945 where a set of flags that are expected
> to be bool under normal circumstances are interchangeably tested with
> ==, is, boolean checks, and the inversion of any of those.
> 
> If you test with "== True", then you treat 2 as non-truthy. If you test
> with "is True", then you treat 1 as non-truthy. And the reverse of
> either may treat 0 as truthy. If you mix and match any truth-test (e.g.
> "== True") with anything that is not its opposite ("!= True", not e.g.
> "== False") you may end up with situations where neither branch was
> taken and your result is an unexpected state.

Yeah, we can write crap code in Python if you try :-)

> I don't actually agree with him that the object being passed in can be
> blamed for this class of error.

Nor do I. I think that's a clear case where the solution is to stop writing
awful code.

We've all gone through a period were the nicest thing one might say about
our coding is "you don't really understand what you are doing". Some of my
earliest code was nearly as bad. 


> It also occurs to me you could conceivably run into problems if you use
> a passed-in mutable object as a flag to be tested multiple times.

Indeed, but I expect that's more of a theoretical risk than a practical
risk. And, who knows, somebody might find a use for it, to win a bet, for a
code golf competition, or just because they like writing "clever" code:

flag = []
if condition:
flag.append(None)
else:
flag.pop()

Could be useful. But beware of overly clever code.


>> The bottom line is, bools offer only a single major API[1]: are they
>> truthy, or falsey? What else can do you with them? Nothing. They
>> support conditional branches, and boolean operators "or" and "and".
>> That's all. They don't have methods to call, or attributes to set. You
>> can use a bool to take the if branch, or the else branch, and that's
>> effectively all.
> 
> Don't forget, they're integers valued 0 and 1. So you can multiply it by
> a number to get 0 or that number. I recently did so (in a code golf
> challenge, not serious code). You can sum an iterable of them to get a
> count of true items.

I would never forget they're also ints. I think I even mentioned that in the
footnote.




-- 
Steven

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

Re: Can math.atan2 return INF?

[Steven D'Aprano]

On Fri, 24 Jun 2016 01:04 am, alister wrote:

> which infinity. There are many - some larger than others

China has just announced a new supercomputer that is so fast it can run an
infinite loop in 3.7 seconds.


-- 
Steven

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

Re: Can math.atan2 return INF?

[Pierre-Alain Dorange]

Dan Sommers  wrote:

> > Given:
> > 
> > x = INF
> > y = INF
> > assert x == y
> > 
> > there is a reason to pick atan2(y, x) = pi/4:
> > 
> > Since x == y, the answer should be the same as for any other pair of x == y.
> 
> When x == y == 0, then atan2(y, x) is 0.

This is the only solution (0) where atan2 return sometime else than
pi/4. And INF is not 0, it can be lot of values, but not zero.

Yes x=INF and y=INF do not mean x=y (in math world) but INF is a
frontier that can be reach, so it tend to the maximum value. So the
tendancy is always atan2(y,x) tend to pi/4 if you looks at lot od y and
x that will be grater and greater each time : the final frontier would
always be pi/4, even if t take a long time to reach it.

-- 
Pierre-Alain Dorange

Ce message est sous licence Creative Commons "by-nc-sa-2.0"

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

Re: Setting up Python WinXP

[Michael Smolen]

Zach and friends:
I am beginning to learn how to install something like Linux Mint on an old 
box from about 2006. That will be my programming machine for Python and 
Perl. I can't abandon XP because other projects are in process and my old 
brain can't handle converting everything at this time. Progress is great 
until it passes you long ago, then you just have to stay afloat. Gulp, gulp, 
gulp... thanks.

mike
- Original Message - 
From: "Zachary Ware" 

To: 
Cc: "Michael Smolen" <8smo...@tds.net>
Sent: Wednesday, June 22, 2016 11:19 AM
Subject: Re: Setting up Python WinXP


Hi Michael,

On Wed, Jun 22, 2016 at 11:41 AM, Michael Smolen <8smo...@tds.net> wrote:

Folks:
I can't wait to start programming with Python.


Welcome to Python!


However, I am having difficulty installing on my XP operating system.


This unsolicited advice is rather beside the point, but I would highly
recommend moving away from XP if you have any say in the matter.
Linux Mint (or other distro of your choice) is easy to install and
use, is free in whatever sense of the word you'd like to use, and will
be much more secure than XP, which is no longer supported by Microsoft
(this is why it's not supported by Python 3.5+, either).  An upgrade
to a newer version of Windows is also a good idea, but more costly.


I downloaded Python-3.4.5ci


I'm not sure what you mean by 3.4.5ci; do you mean 3.4.5rc1?  3.4.5rc1
is pre-release software; 3.4.5 will be released in a week or so.
However, it won't include binary installers for Windows since Python
3.4 is now in security-fix-only mode.

as that seems like the version that will run on my operating system. The 
latest version will not as per mention on the website. I downloaded the 
compacted version  (*.tar), converted it to a *.tgz and extracted the 
software into a folder Python-3.4.5ci. That subdirectory contains numerous 
files (11) and 13 subdirectories. The README file states that "On Windows, 
see PCbuild/readme.txt.". That link was not found.


So, I am clueless on what I need to do to successfully install Python3.4 
on my computer. Any advice would be greatly appreciated.


If you're stuck with XP, stick with Python 3.4.4, and download the
installer from here:
https://www.python.org/ftp/python/3.4.4/python-3.4.4.msi

Hope this helps,
--
Zach 


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

Re: Can math.atan2 return INF?

[Pierre-Alain Dorange]

Steven D'Aprano  wrote:

> > which infinity. There are many - some larger than others
> 
> China has just announced a new supercomputer that is so fast it can run an
> infinite loop in 3.7 seconds.

Near a black hole 3.7 seconds can last an infinite time...

-- 
Pierre-Alain Dorange

Ce message est sous licence Creative Commons "by-nc-sa-2.0"

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

Re: Can math.atan2 return INF?

[Marko Rauhamaa]

pdora...@pas-de-pub-merci.mac.com (Pierre-Alain Dorange):

> Steven D'Aprano  wrote:
>> China has just announced a new supercomputer that is so fast it can
>> run an infinite loop in 3.7 seconds.
>
> Near a black hole 3.7 seconds can last an infinite time...

Which phenomenon prevents a black hole from ever forming. Yet
astronomers keep telling us they are all over the place.

   Oppenheimer and his co-authors interpreted the singularity at the
   boundary of the Schwarzschild radius as indicating that this was the
   boundary of a bubble in which time stopped. This is a valid point of
   view for external observers, but not for infalling observers. Because
   of this property, the collapsed stars were called "frozen stars",
   because an outside observer would see the surface of the star frozen
   in time at the instant where its collapse takes it inside the
   Schwarzschild radius.
   https://en.wikipedia.org/wiki/Black_hole>

Note that the "valid point of view for external observers" is the only
valid scientific point of view.


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

Re: Break and Continue: While Loops

[John Gordon]

In <639b00e0-7b9d-4ed4-96ad-6afbcd536...@googlegroups.com> Elizabeth Weiss 
 writes:

> i=0
> while 1==1:
>print(i)
>i=i+1
>if i>=5:
>  print("Breaking")
>  break

> Why is Breaking going to be printed if i only goes up to 4?

Your code prints i and THEN adds one to it.

So i is 4, it gets printed, then 1 is added to it, so it becomes 5
and then the loop exits.

-- 
John Gordon   A is for Amy, who fell down the stairs
gor...@panix.com  B is for Basil, assaulted by bears
-- Edward Gorey, "The Gashlycrumb Tinies"

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

RE: not able to install mysqldb-python

[Joaquin Alzola]

>ImportError: No module named 'ConfigParser'
 It is telling you the error
This email is confidential and may be subject to privilege. If you are not the 
intended recipient, please do not copy or disclose its content but contact the 
sender immediately upon receipt.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Setting up Python WinXP

[Joel Goldstick]

On Thu, Jun 23, 2016 at 1:11 PM, Michael Smolen <8smo...@tds.net> wrote:
> Zach and friends:
> I am beginning to learn how to install something like Linux Mint on an old
> box from about 2006. That will be my programming machine for Python and
> Perl. I can't abandon XP because other projects are in process and my old
> brain can't handle converting everything at this time. Progress is great
> until it passes you long ago, then you just have to stay afloat. Gulp, gulp,
> gulp... thanks.
> mike
> - Original Message - From: "Zachary Ware"
> 
> To: 
> Cc: "Michael Smolen" <8smo...@tds.net>
> Sent: Wednesday, June 22, 2016 11:19 AM
> Subject: Re: Setting up Python WinXP
>
>
>
> Hi Michael,
>
> On Wed, Jun 22, 2016 at 11:41 AM, Michael Smolen <8smo...@tds.net> wrote:
>>
>> Folks:
>> I can't wait to start programming with Python.
>
>
> Welcome to Python!
>
>> However, I am having difficulty installing on my XP operating system.
>
>
> This unsolicited advice is rather beside the point, but I would highly
> recommend moving away from XP if you have any say in the matter.
> Linux Mint (or other distro of your choice) is easy to install and
> use, is free in whatever sense of the word you'd like to use, and will
> be much more secure than XP, which is no longer supported by Microsoft
> (this is why it's not supported by Python 3.5+, either).  An upgrade
> to a newer version of Windows is also a good idea, but more costly.
>
>> I downloaded Python-3.4.5ci
>
>
> I'm not sure what you mean by 3.4.5ci; do you mean 3.4.5rc1?  3.4.5rc1
> is pre-release software; 3.4.5 will be released in a week or so.
> However, it won't include binary installers for Windows since Python
> 3.4 is now in security-fix-only mode.
>
>> as that seems like the version that will run on my operating system. The
>> latest version will not as per mention on the website. I downloaded the
>> compacted version  (*.tar), converted it to a *.tgz and extracted the
>> software into a folder Python-3.4.5ci. That subdirectory contains numerous
>> files (11) and 13 subdirectories. The README file states that "On Windows,
>> see PCbuild/readme.txt.". That link was not found.
>>
>> So, I am clueless on what I need to do to successfully install Python3.4
>> on my computer. Any advice would be greatly appreciated.
>
>
> If you're stuck with XP, stick with Python 3.4.4, and download the
> installer from here:
> https://www.python.org/ftp/python/3.4.4/python-3.4.4.msi
>
> Hope this helps,
> --
> Zach
> --
> https://mail.python.org/mailman/listinfo/python-list

Linux works well on old machines.  However, Lubuntu is a scaled down
Ubuntu version designed to run on older hardware (the GUI isn't as
fancy). and I am using it on a dell from 2008 with 4gigs ram.  Works
fine.  You can download the image and burn to cd or usb stick --
whichever your machine will allow you to boot from.  You'll be up in
an hour or so

-- 
Joel Goldstick
http://joelgoldstick.com/blog
http://cc-baseballstats.info/stats/birthdays
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Can math.atan2 return INF?

[Ben Bacarisse]

alister  writes:

> On Thu, 23 Jun 2016 15:39:43 +0100, Ben Bacarisse wrote:
>
>> Steven D'Aprano  writes:
>> 
>>> On Thursday 23 June 2016 14:40, Dan Sommers wrote:
>>>
> Since x == y, the answer should be the same as for any other pair of
> x == y.
 
 When x == y == 0, then atan2(y, x) is 0.
>> 
>> I see just added noise by making the same comment before reading the
>> rest of the thread.  Sorry.
>> 
>>> /s/any other pair of x == y/any other pair of x y except for zero/
>>>
>>> :-P
>>>
>>>
>>> Zero is exceptional in many ways.
>> 
>> whereas infinity...  :-)
>
> which infinity. There are many - some larger than others

The one in the post up thread now (sadly) snipped.  It's not a
mathematical infinity at all but a particular floating point
representation that results from float("inf").  However it is still just
as "exceptional in many ways" as zero.  (Sorry if you were making a joke
and I didn't get it.)

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

Pandas to CSV and .dbf

[David Shi via Python-list]

Has anyone tested on Pandas to CSV and .dbf lately?
I am looking for proven, tested examples to output Panda Data Frame to CSV and 
dbf files.
Looking forward to hearing from you.
Regards.
David
-- 
https://mail.python.org/mailman/listinfo/python-list

Which one is the best XML-parser?

[David Shi via Python-list]

Which one is the best XML-parser?
Can any one tell me?
Regards.
David
-- 
https://mail.python.org/mailman/listinfo/python-list

Which one is the best JSON parser?

[David Shi via Python-list]

Can any one tell me?
Regards.
David
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Which one is the best JSON parser?

[MRAB]

On 2016-06-23 21:58, David Shi via Python-list wrote:

Can any one tell me?
Regards.
David


There's one in the standard library.

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

Re: the global keyword:

[Steven D'Aprano]

On Wed, 22 Jun 2016 07:24 pm, BartC wrote:

[...]
> But even if it worked, I don't think this two-parter counts as a 'global
> variable' as it is understood. I might as well just create my own G
> module containing:
> 
>  BDFL="GvR"
> 
> and import it in both A and B. Then I can also write G.BDFL in those
> modules. But remember the point was avoid having to write Test.test_var.

The question "Does Python have global variables?" depends on what you mean
by "global variable". That makes it a dispute about definitions, and we
know how they go:

http://lesswrong.com/lw/np/disputing_definitions/


So what do *I* mean by global variables?

To me, a global variable is a variable which is scoped to a level wider than
any single function, i.e. module scope, or whole-application scope. That
is, the variable must be visible to more than one function, or more than
one module.

But further, you must be able to *assign* to that variable with a simple
assignment, without explicitly prefixing the variable with a namespace:

foo = 1

It is okay if you have to declare that the variable is global before
assigning to it.

So to me, Python has module globals, because you can have two functions in
the one module which both assign to the same variable:

def spam():
global x
x = 1

def ham():
global x
x = 2

x is a global variable. But Python *doesn't* have application-wide globals,
because although you can access a variable across multiple modules at the
same time, you cannot do so without using the fully-qualified name module.x
rather than just x.

(To be precise, for the builtins module specifically, you can *read* the
value of the variable using just x, but you cannot *assign* to it unless
you use the fully-qualified name builtins.x.)


If Rick wishes to argue for a different definition of "global variable",
Rick should explain what his definition is, and why we should prefer it to
mine.



-- 
Steven

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

Re: the global keyword:

[Chris Angelico]

On Fri, Jun 24, 2016 at 11:00 AM, Steven D'Aprano  wrote:
> To me, a global variable is a variable which is scoped to a level wider than
> any single function, i.e. module scope, or whole-application scope. That
> is, the variable must be visible to more than one function, or more than
> one module.

... and not part of a closure, because they're not global. (I'd also
say "nor part of an object", but objects in Python have attributes
accessed using 'self.', so your other check removes that. But in C++,
that would need to be another criterion.)

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

Re: the global keyword:

[eryk sun]

On Fri, Jun 24, 2016 at 1:00 AM, Steven D'Aprano  wrote:
> To be precise, for the builtins module specifically, you can *read* the
> value of the variable using just x, but you cannot *assign* to it unless
> you use the fully-qualified name builtins.x.

FWIW, you can execute code in any dict:

>>> import builtins
>>> exec(r'''
... foo = 'bar'
... ''', vars(builtins))
>>> builtins.foo
'bar'

The frame for an unoptimized CPython code object (used for modules and
the class statement) uses f_builtins, f_globals, and f_locals dicts
(or possibly a mapping in the case of f_locals) respectively for its
builtin, global, and local scopes. The frame for an optimized code
object uses a fast locals array instead of f_locals, in which case the
locals() function stores a snapshot of the locals to the f_locals
dict. A frame may also have a freevars array, which has cell objects
for closures (i.e. the nonlocal scope). For optimized code (i.e. a
function, but not a class body), locals() also includes a snapshot of
nonlocals, even though this doesn't make literal sense.

The above example executes code with all 3 scopes set to the same
dict. For example:

>>> exec(r'''
... import sys
... f = sys._getframe()
... print(f.f_builtins is f.f_globals is f.f_locals)
... ''', vars(builtins))
True

The CPython VM doesn't have an operation to store to the builtin
scope, since the language doesn't have a statement such as "builtin"
to declare a variable in this scope. The builtin scope is used as a
fallback for operations such as LOAD_NAME and LOAD_GLOBAL -- for
loading constants such as built-in functions, exceptions, __debug__,
and also the "_" attribute that gets updated by sys.displayhook.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Which one is the best XML-parser?

[dieter]

David Shi via Python-list  writes:

> Which one is the best XML-parser?

"best" is not an absolute term but depends on criteria/conditions.


There are essentially two kinds of parsers: incremental parsers
which parse the structure and report events for everything they see
and non-incremental parses which transform the complete XML
into a data structure.

You want an incremental parser if the XML documents are so huge that
you must process them incrementally rather than have a data structure
representing the whole document (in memory). Incremental parsers
for XML are usually called "SAX" parsers.

If your XML documents have moderate size, you might prefer
a non-incremental parser.


Personally, I like "lxml" (a binding to the "libxml2" C-library).
It supports a lot of features: besides simple parsing, it supports
verification against XML-schema and DTDs, XPath and XSLT-transforms.
This means, with one XML tool you can handle all tasks typically
encoutered with XML processing.

However, "lxml" depends on an external C-library ("libxml2").
Therefore, it might be considered more difficult to install
than "pure python" XML parsers.

These examples show: "best" depends on your situation, your tasks
and your preferences.


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