Re: A certainl part of an if() structure never gets executed.

[Thomas Rachel]

Am 12.06.2013 03:46 schrieb Rick Johnson:

On Tuesday, June 11, 2013 8:25:30 PM UTC-5, nagia@gmail.com wrote:


is there a shorter and more clear way to write this?
i didnt understood what Rick trie to told me.


My example included verbatim copies of interactive sessions within the Python 
command line. You might understand them better if you open the Python command 
line and type each command in one-by-one. Here is an algoritm that explains the 
process:

open_command_window()
whilst learning or debugging:
 type_command()
 press_enter()
 observe_output()
 if self.badder.is_full:
 take_potty_break()
close_command_window()


with command_window():
   whilst learning or debugging:
  type_command()
  press_enter()
  observe_output()
  if self.badder.is_full:
  take_potty_break()

looks nicer.

SCNR


Thomas
--
http://mail.python.org/mailman/listinfo/python-list

Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.]

[88888 Dihedral]

Michael Torrie於 2013年6月20日星期四UTC+8下午2時01分11秒寫道：
> 
>  But since the LISP never really got a form beyond S-expressions,
> 
> leaving us with lots of parenthesis everywhere, Python wins much as the
> 
> Hitchhiker's Guide to the Galaxy wins.

Yep, a list is mutable even it's empty.
But constant integers, floats, strings, and None is immutable.

The  variables in a function of python with default 
parameters which could be mutable or immutable.

def fun1( x, alist=[]):
alist.append(x*x)
return alist   ## valid

def fun2(x, alist=None):
if alist==None: alist=[]
alist.append(x*x)
return alist

# kind of boring to show the name binding mechanism of objects
# in Python in different usages
 




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

Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.]

[Roel Schroeven]

Νίκος schreef:

Στις 18/6/2013 12:05 μμ, ο/η Steven D'Aprano έγραψε:

Names are *always* linked to objects, not to other names.

a = []
b = a  # Now a and b refer to the same list
a = {} # Now a refers to a dict, and b refers to the same list as before


I see, thank you Steven.

But since this is a fact how do you create complicated data structures 
that rely on various variables pointing one to another liek we did in 
C++(cannot recall their names) ?


You almost never need to do that in Python. But if you really want to, 
out of curiosity, you can. For example, you could create a simple singly 
linked list like this:


>>> class Node(object):
def __init__(self, value):
self.value = value
self.next = None


>>> first = Node(1)
>>> second = Node(2)
>>> first.next = second

You could iterate over it like this:

>>> def iterate_linked_list(node):
while node:
yield node.value
node = node.next


>>> for v in iterate_linked_list(first):
print v


--
"People almost invariably arrive at their beliefs not on the basis of
proof but on the basis of what they find attractive."
-- Pascal Blaise

r...@roelschroeven.net

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

Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.]

[Michael Torrie]

On 06/19/2013 11:48 PM, Steven D'Aprano wrote:
> On Wed, 19 Jun 2013 23:16:51 -0600, Michael Torrie wrote:
> 
>> The real power and expressivity of Python comes from embracing the
>> abstractions that Python provides to your advantage.  There's a certain
>> elegance and beauty that comes from such things, which I believe really
>> comes from the elegance and beauty of LISP, some of which manages to
>> shine forth in Python, despite its deficiencies.  When I first learned
>> Python, I was impressed that some of the elegance that I remember from
>> Scheme (how to use lists as a basic type for example) was there, but in
>> a form that appealed to me.
> 
> 
> Well said!

Glad you made sense of it... the bit about LISP and Scheme came out a
wee bit muddled.  In fact thinking about it, perhaps LISPers would say
about Python what a bible passage says about having the form of
Godliness but denying the power thereof!  For example, Python's lambda
functions, and Python's functional programming capabilities in general.
 But since the LISP never really got a form beyond S-expressions,
leaving us with lots of parenthesis everywhere, Python wins much as the
Hitchhiker's Guide to the Galaxy wins.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.]

[Steven D'Aprano]

On Wed, 19 Jun 2013 23:16:51 -0600, Michael Torrie wrote:

> The real power and expressivity of Python comes from embracing the
> abstractions that Python provides to your advantage.  There's a certain
> elegance and beauty that comes from such things, which I believe really
> comes from the elegance and beauty of LISP, some of which manages to
> shine forth in Python, despite its deficiencies.  When I first learned
> Python, I was impressed that some of the elegance that I remember from
> Scheme (how to use lists as a basic type for example) was there, but in
> a form that appealed to me.


Well said!


-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.]

[Michael Torrie]

On 06/19/2013 11:16 PM, Michael Torrie wrote:
> It turns out that lists, hashes (dicts), and classes can pretty much
> do anything with having to much about with C-style pointers and
> such.

Oh wow. Parse error.  should read, "pretty much do anything without
having to muck about with C-style pointers and such."
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.]

[Michael Torrie]

On 06/18/2013 03:51 AM, Νίκος wrote:
> Στις 18/6/2013 12:05 μμ, ο/η Steven D'Aprano έγραψε:
>> Names are *always* linked to objects, not to other names.
>>
>> a = []
>> b = a  # Now a and b refer to the same list
>> a = {} # Now a refers to a dict, and b refers to the same list as before
> 
> I see, thank you Steven.
> 
> But since this is a fact how do you create complicated data structures 
> that rely on various variables pointing one to another liek we did in 
> C++(cannot recall their names) ?
> 

As Steve said Python provides all manner of data structures and the
means to create data structures.  Any data structure (trees, lists, etc)
can all be made easily in Python using Python's basic data structures,
if the built-in data structures are not sufficient.  It turns out that
lists, hashes (dicts), and classes can pretty much do anything with
having to much about with C-style pointers and such.

Do yourself a favor and forget about the low-level stuff in Python for
now.  You'll be more frustrated if you don't.

The real power and expressivity of Python comes from embracing the
abstractions that Python provides to your advantage.  There's a certain
elegance and beauty that comes from such things, which I believe really
comes from the elegance and beauty of LISP, some of which manages to
shine forth in Python, despite its deficiencies.  When I first learned
Python, I was impressed that some of the elegance that I remember from
Scheme (how to use lists as a basic type for example) was there, but in
a form that appealed to me.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: A certainl part of an if() structure never gets executed.

[Chris Angelico]

On Wed, Jun 19, 2013 at 6:55 PM, Steven D'Aprano
 wrote:
> On Wed, 19 Jun 2013 18:21:40 +1000, Chris Angelico wrote:
>
>> You can't reference an object without
>> somewhere having either a name or a literal to start it off.
>
> True, but not necessarily a name bound to the object you are thinking of:
>
> some_function()
>
> gives you an object, but it's not a literal, and "some_function" is not
> the name of the object you end up with.

You start with the object identified by some_function, then you call
it. Same thing. Okay, so according to the Python grammar some of these
things I've been treating as operators aren't classified as them; but
there are still operations done to existing objects to derive other
objects:

> The ways to refer to something are more
> interesting:
>
> * you can refer to a thing directly by referring to it as a literal;
>
> * you can refer to a thing bound to a name by referring to the name;

The two I started with

> * you can refer to a thing in a namespace by referring to the namespace
> in some fashion, followed by a dot, followed by the name in that
> namespace,  e.g. some_object.attribute, __import__('math').pi;

Retrieving an attribute of an object, whether that object be
referenced by name or by function call.

> * you can refer to a thing in a sequence by referring to the sequence in
> some fashion, followed by an index number in square brackets, e.g. seq[3];

Ditto. These can call magic methods; as far as I'm concerned, they're
equivalent to operators. You can apply them to anything.

> * you can refer to a thing that is returned by a callable (function,
> method, type, etc.) by referring in some fashion to that callable object,
> followed by calling it, e.g. functions[9](arg) gives you a reference to
> some object which may not be any of `functions`, `9`, or `arg`.

And same again. You start with functions, 9, and arg, look up two of
them as names, traverse the series of operations, and get back a
result. Or maybe you throw an exception.

>>> class Foo:
def __call__(self):
print("Hello, world!")


>>> foo=Foo()
>>> foo()
Hello, world!

Is foo a function? Kinda. Sorta. We don't care. Is the function call
notation () an operator? Ditto - we don't care. It works like one.
There's little fundamental difference between:

>>> "asdf %d qwer"%5
'asdf 5 qwer'

and

>>> "asdf %d qwer"[5]
'%'

but one of them is called an operator and one's not. Would you say
that percent notation there is another way to reference an object? Is
it a different type of string literal? No. It's a string literal and
an operation done to it. Same with the subscripting, even though
that's not technically an operator. It's not a different way to get an
object. It's an operation on an object.

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

Re: A certainl part of an if() structure never gets executed.

[Steven D'Aprano]

On Wed, 19 Jun 2013 18:21:40 +1000, Chris Angelico wrote:

> You can't reference an object without
> somewhere having either a name or a literal to start it off.

True, but not necessarily a name bound to the object you are thinking of:

some_function()

gives you an object, but it's not a literal, and "some_function" is not 
the name of the object you end up with.

In a sense, you're making a fairly uninteresting claim:

"You cannot refer to an object without referring to something"

which is obviously correct. The ways to refer to something are more 
interesting:

* you can refer to a thing directly by referring to it as a literal;

* you can refer to a thing bound to a name by referring to the name;

* you can refer to a thing in a namespace by referring to the namespace 
in some fashion, followed by a dot, followed by the name in that 
namespace,  e.g. some_object.attribute, __import__('math').pi;

* you can refer to a thing in a sequence by referring to the sequence in 
some fashion, followed by an index number in square brackets, e.g. seq[3];

* you can refer to a thing that is returned by a callable (function, 
method, type, etc.) by referring in some fashion to that callable object, 
followed by calling it, e.g. functions[9](arg) gives you a reference to 
some object which may not be any of `functions`, `9`, or `arg`.


Have I missed any?


-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: A certainl part of an if() structure never gets executed.

[Chris Angelico]

On Wed, Jun 19, 2013 at 6:06 PM, Dave Angel  wrote:
> On 06/19/2013 03:14 AM, Chris Angelico wrote:
>>
>> On Wed, Jun 19, 2013 at 3:42 PM, Dave Angel  wrote:
>>>
>>> Names are *one of* the ways we specify which objects are to be used. (We
>>> can
>>> also specify objects via an container and a subscript or slice, or via an
>>> attribute of another object.  And probably another way or two.)
>>
>>
>> But you always have to bootstrap it with either a name.
>
>
> Whatever bootstrap really means in this context.  But if you have myname[3]
> + myname[5], the two objects being added are identified by a subscript
> operation, not just a name.
>
>> Or a literal.
>
>
> A literal is used to create an object, and acts like a temporary name for
> that object, but once again the object being operated on isn't necessarily
> that one. You can subscript and get attributes from a literal as well.
>
>
>> So those are the only two ways to specify which objects are to be
>> used.
>>
>
> That would be a pretty weak language, and it wouldn't be python.
>
>
> Now if you considered "." and "[" as operators, then I could understand your
> point.  But
>http://docs.python.org/3/reference/lexical_analysis.html#operators
> seems to say differently.
>
> Also see
>http://docs.python.org/3/reference/expressions.html#primaries

They may not quite be "operators" per se, but the fact is that they're
composites built of primitives. You can't reference an object without
somewhere having either a name or a literal to start it off. Your
example starts with the object identified by the name 'myname', and
the objects referenced by the literals 3 and 5, and builds up from
there. Rebinding 'myname' would change that expression, as would
changing the meanings of 3 or 5, though I don't know of any way to do
the latter :)

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

Re: A certainl part of an if() structure never gets executed.

[Dave Angel]

On 06/19/2013 03:14 AM, Chris Angelico wrote:

On Wed, Jun 19, 2013 at 3:42 PM, Dave Angel  wrote:

Names are *one of* the ways we specify which objects are to be used. (We can
also specify objects via an container and a subscript or slice, or via an
attribute of another object.  And probably another way or two.)


But you always have to bootstrap it with either a name.


Whatever bootstrap really means in this context.  But if you have 
myname[3] + myname[5], the two objects being added are identified by a 
subscript operation, not just a name.



Or a literal.


A literal is used to create an object, and acts like a temporary name 
for that object, but once again the object being operated on isn't 
necessarily that one. You can subscript and get attributes from a 
literal as well.



So those are the only two ways to specify which objects are to be
used.



That would be a pretty weak language, and it wouldn't be python.


Now if you considered "." and "[" as operators, then I could understand 
your point.  But

   http://docs.python.org/3/reference/lexical_analysis.html#operators
seems to say differently.

Also see
   http://docs.python.org/3/reference/expressions.html#primaries


--
DaveA
--
http://mail.python.org/mailman/listinfo/python-list

Re: A certainl part of an if() structure never gets executed.

[Νίκος]

Στις 19/6/2013 8:08 πμ, ο/η Tim Roberts έγραψε:

Nick the Gr33k  wrote:


On 16/6/2013 4:55 ??, Tim Roberts wrote:


Nick the Gr33k  wrote:
Because Python lets you use arbitrary values in a Boolean context, the net
result is exactly the same.


What is an arbitrary value? don even knwo what arbitrary means literally
in English.


Basically, it means "any".  In Python, you can use ANY value where a
Boolean is expected.  All types have a Boolean meaning.  For integers, 0 is
false, anything else is true.  For strings, an empty string "" is false,
anything else is true.  For lists, an empty list [] is false, anything else
is true.  For tuples, an empty tuple () is false, anything else is true.
For dicts, an empty dict {} is false, anything else is true.


The argument being returned in an "and" or "or" expression is the one
that *determined' the evaluation of the expression.


That's not exactly how I'd put it, but the statement is correct.  The last
thing it had to evaulate is the result of the expression.


And actually what's being returned is not the argument itself but the
argument's value.


But this is no different than any other programming language.  Expressions
always use the value of their operands, and they always return a value.

The name vs value thing is critical to understanding Python, in my opinion,
and it can be a stumbling block when you're coming from another language.
Here's how I think about it.

Python had two distinct spaces: there is a space for names, and there is a
space for objects (which are values).  Objects live in a nameless, faceless
object cloud.

A name is always bound to some object (which might be the "None" object). A
name always knows its object, but an object never knows what names it is
bound to.

The only things that can be used in expressions and function arguments are
objects.  Names are merely the way we specify which objects to be used.

 a = [3]

That creates a nameless list containing a single integer object with the
value 3.  It then binds the name "a" to that list.  Note that the list has
no clue that it is bound to any names.

 b = a

That binds "b" to the same list.  "b" and "a" are not related in any way,
except that they happen to be bound to the same object.  Note that there is
still only one list.

 a.append(4)

That modifies the list so that it now contains [3,4].  b is bound to the
same list, so if you
 print(b)
you'll see [3,4]

Now, let's say I do this:

 a = [5]

Here's where people get tripped up.  This does not change our original
list.  Instead, it creates a new nameless list containing 5, and binds the
name a to that list.  a and b are no longer bound to the same object.


Thank you very much Tim for the simply and detailed put explanation.

--
What is now proved was at first only imagined!
--
http://mail.python.org/mailman/listinfo/python-list

Re: A certainl part of an if() structure never gets executed.

[Chris Angelico]

On Wed, Jun 19, 2013 at 3:42 PM, Dave Angel  wrote:
> Names are *one of* the ways we specify which objects are to be used. (We can
> also specify objects via an container and a subscript or slice, or via an
> attribute of another object.  And probably another way or two.)

But you always have to bootstrap it with either a name. Or a literal.
So those are the only two ways to specify which objects are to be
used.

(Anyone fanatically devoted to nice red uniforms?)

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

Re: A certainl part of an if() structure never gets executed.

[Dave Angel]

I think this is an excellent description of name binding with mutable 
objects.  I just have one clarification to insert below.


On 06/19/2013 01:08 AM, Tim Roberts wrote:

Nick the Gr33k  wrote:


On 16/6/2013 4:55 ??, Tim Roberts wrote:


Nick the Gr33k  wrote:
Because Python lets you use arbitrary values in a Boolean context, the net
result is exactly the same.


What is an arbitrary value? don even knwo what arbitrary means literally
in English.


Basically, it means "any".  In Python, you can use ANY value where a
Boolean is expected.  All types have a Boolean meaning.  For integers, 0 is
false, anything else is true.  For strings, an empty string "" is false,
anything else is true.  For lists, an empty list [] is false, anything else
is true.  For tuples, an empty tuple () is false, anything else is true.
For dicts, an empty dict {} is false, anything else is true.


The argument being returned in an "and" or "or" expression is the one
that *determined' the evaluation of the expression.


That's not exactly how I'd put it, but the statement is correct.  The last
thing it had to evaulate is the result of the expression.


And actually what's being returned is not the argument itself but the
argument's value.


But this is no different than any other programming language.  Expressions
always use the value of their operands, and they always return a value.

The name vs value thing is critical to understanding Python, in my opinion,
and it can be a stumbling block when you're coming from another language.
Here's how I think about it.

Python had two distinct spaces: there is a space for names, and there is a
space for objects (which are values).  Objects live in a nameless, faceless
object cloud.

A name is always bound to some object (which might be the "None" object). A
name always knows its object, but an object never knows what names it is
bound to.

The only things that can be used in expressions and function arguments are
objects.  Names are merely the way we specify which objects to be used.


Names are *one of* the ways we specify which objects are to be used. 
(We can also specify objects via an container and a subscript or slice, 
or via an attribute of another object.  And probably another way or two.)




 a = [3]

That creates a nameless list containing a single integer object with the
value 3.  It then binds the name "a" to that list.  Note that the list has
no clue that it is bound to any names.

 b = a

That binds "b" to the same list.  "b" and "a" are not related in any way,
except that they happen to be bound to the same object.  Note that there is
still only one list.

 a.append(4)

That modifies the list so that it now contains [3,4].  b is bound to the
same list, so if you
 print(b)
you'll see [3,4]

Now, let's say I do this:

 a = [5]

Here's where people get tripped up.  This does not change our original
list.  Instead, it creates a new nameless list containing 5, and binds the
name a to that list.  a and b are no longer bound to the same object.




--
DaveA
--
http://mail.python.org/mailman/listinfo/python-list

Re: A certainl part of an if() structure never gets executed.

[Tim Roberts]

Nick the Gr33k  wrote:
>
>On 16/6/2013 4:55 ??, Tim Roberts wrote:
>
>> Nick the Gr33k  wrote:
>> Because Python lets you use arbitrary values in a Boolean context, the net
>> result is exactly the same.
>
>What is an arbitrary value? don even knwo what arbitrary means literally 
>in English.

Basically, it means "any".  In Python, you can use ANY value where a
Boolean is expected.  All types have a Boolean meaning.  For integers, 0 is
false, anything else is true.  For strings, an empty string "" is false,
anything else is true.  For lists, an empty list [] is false, anything else
is true.  For tuples, an empty tuple () is false, anything else is true.
For dicts, an empty dict {} is false, anything else is true.

>The argument being returned in an "and" or "or" expression is the one 
>that *determined' the evaluation of the expression.

That's not exactly how I'd put it, but the statement is correct.  The last
thing it had to evaulate is the result of the expression.

>And actually what's being returned is not the argument itself but the 
>argument's value.

But this is no different than any other programming language.  Expressions
always use the value of their operands, and they always return a value.

The name vs value thing is critical to understanding Python, in my opinion,
and it can be a stumbling block when you're coming from another language.
Here's how I think about it.

Python had two distinct spaces: there is a space for names, and there is a
space for objects (which are values).  Objects live in a nameless, faceless
object cloud.

A name is always bound to some object (which might be the "None" object). A
name always knows its object, but an object never knows what names it is
bound to.

The only things that can be used in expressions and function arguments are
objects.  Names are merely the way we specify which objects to be used.

a = [3]

That creates a nameless list containing a single integer object with the
value 3.  It then binds the name "a" to that list.  Note that the list has
no clue that it is bound to any names.

b = a

That binds "b" to the same list.  "b" and "a" are not related in any way,
except that they happen to be bound to the same object.  Note that there is
still only one list.

a.append(4)

That modifies the list so that it now contains [3,4].  b is bound to the
same list, so if you 
print(b)
you'll see [3,4]

Now, let's say I do this:

a = [5]

Here's where people get tripped up.  This does not change our original
list.  Instead, it creates a new nameless list containing 5, and binds the
name a to that list.  a and b are no longer bound to the same object.
-- 
Tim Roberts, t...@probo.com
Providenza & Boekelheide, Inc.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: A certainl part of an if() structure never gets executed.

[Jan Riechers]

On 13.06.2013 20:00, Νικόλαος Κούρας wrote:

 if '-' not in name + month + year:
 cur.execute( '''SELECT * FROM works WHERE clientsID =
(SELECT id FROM clients WHERE name = %s) and MONTH(lastvisit) = %s and
YEAR(lastvisit) = %s ORDER BY lastvisit ASC''', (name, month, year) )
 elif '-' not in name + year:
 cur.execute( '''SELECT * FROM works WHERE clientsID =
(SELECT id FROM clients WHERE name = %s) and YEAR(lastvisit) = %s ORDER
BY lastvisit ASC''', (name, year) )
 elif '-' not in month + year:
 cur.execute( '''SELECT * FROM works WHERE MONTH(lastvisit)
= %s and YEAR(lastvisit) = %s ORDER BY lastvisit ASC''', (month, year) )
 elif '-' not in year:
 cur.execute( '''SELECT * FROM works WHERE YEAR(lastvisit) =
%s ORDER BY lastvisit ASC''', year )


This finally worked!



I spared myself to read the whole thread cause its super long and I find 
it admirable that some people took time to troubleshoot the issue and 
(even) added optimizations of what can be done differently/better.. even 
so it seems there was only a wrong char used in the ifs?..


And as a short note - you should add code which handles the worst-case 
scenario (everthing fails, nothing valid, avoid into code which might 
require variables/data which is not present and so forth..)



But generally speaking:
As a best practice in any language not just Python.
If you have the option to print out evaluations and values, use it!


As rule of thumb for debugging code:
1. Print out what values you get in (from user, in(to) a function)
2a. Test statements and logic either by setting a print (in your case 
inside each if) with something like "if1", "if2", ... "else fired" or 
what you prefer OR do a direct comparison if the evaluation statements 
are not super long (someone mentioned that..)
2b. In case of longer statements/calculations, break them into chunks, 
simplify the problem to smaller ones and try to verify the results as 
possible (being "far apart" and "getting closer" after each time is 
already a good hint in calculations..)
3. If you catch data from a database and you see now results -> print 
out if your search/query even can return anything at all or if your 
query itself has a flaw or similar.


Optional but also useful:
4. On the end of a function, print if the output of the function is as 
expected


This small technique costs minimal time, but brings a brilliant ability:
1. Understand the code flow
2. Understand mistakes
3. Save yourself a big time by searching targeted for code parts which 
are executed..


..and ignore not directly connected code - for example when looking at 
other peoples code without documentation, comments or introduction.

This can spare loads of headaches.

And all this can be done in a couple of minutes..

Jan

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

Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.]

[Chris Angelico]

On Tue, Jun 18, 2013 at 7:51 PM, Νίκος  wrote:
> Στις 18/6/2013 12:05 μμ, ο/η Steven D'Aprano έγραψε:
>
>> Names are *always* linked to objects, not to other names.
>>
>> a = []
>> b = a  # Now a and b refer to the same list
>> a = {} # Now a refers to a dict, and b refers to the same list as before
>
>
> I see, thank you Steven.
>
> But since this is a fact how do you create complicated data structures that
> rely on various variables pointing one to another liek we did in C++(cannot
> recall their names) ?

Why do you need to? Linked lists, trees, and so on are just tools.
They're usually used to implement data structures like mappings,
growable arrays, lists that can have elements inserted into them, etc,
etc. Python does these sorts of things in better ways. You should not
need to worry about memory locations, pointers, etc. Now, if you want
to have one object reference another, that can be done in plenty of
ways. Check the Python tutorial.

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

Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.]

[Νίκος]

Στις 18/6/2013 12:05 μμ, ο/η Steven D'Aprano έγραψε:

Names are *always* linked to objects, not to other names.

a = []
b = a  # Now a and b refer to the same list
a = {} # Now a refers to a dict, and b refers to the same list as before


I see, thank you Steven.

But since this is a fact how do you create complicated data structures 
that rely on various variables pointing one to another liek we did in 
C++(cannot recall their names) ?


--
What is now proved was at first only imagined!
--
http://mail.python.org/mailman/listinfo/python-list

Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.]

[Steven D'Aprano]

On Tue, 18 Jun 2013 11:49:36 +0300, Νίκος wrote:

> Στις 18/6/2013 9:39 πμ, ο/η Larry Hudson έγραψε:
>> Not quite:  a and b _are_ memory addresses,  At the same time, a and b
>> are references to the data (the objects) stored in those memory
>> locations.
>>
>> The distinction is probably more important in languages like C/C++,
>> where the _language_ gives you direct access to, and can manipulate,
>> these memory addresses (through pointers).  Python handles it
>> differently and does not give you this sort of ability, it all occurs
>> "under the hood".  Yes, the id() function will tell you the addresses,
>> but you can't do anything with them other than perhaps compare them.
>> It's really pretty much useless information.
> 
> So, a and b are actual memory addresses.

No, no, no, a thousand times no.


> Does the term of a pointer exist in Python? 

No.


> I mean if print(a) or
> print(b) outputs the object that a and b are linked to, then how do we
> access a's and b's memory locations themselves t create links among
> variables, one pointing to the other and so on?

You cannot. You can only have links between OBJECTS, not between 
VARIABLES. There is no way to have a name "a" set to point to another 
name "b". All you can do is have a name "a" set to refer to the same 
object as "b" has *right now*. If "b" changes to another object, "a" will 
not follow.


> Can a variable point to another variable or variables never point to
> other variables but instead are *only* linked to the objects of those
> var's instead?

Names are *always* linked to objects, not to other names.

a = []
b = a  # Now a and b refer to the same list
a = {} # Now a refers to a dict, and b refers to the same list as before




-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.]

[Νίκος]

Στις 18/6/2013 9:39 πμ, ο/η Larry Hudson έγραψε:

Not quite:  a and b _are_ memory addresses,  At the same time, a and b
are references to the data (the objects) stored in those memory locations.

The distinction is probably more important in languages like C/C++,
where the _language_ gives you direct access to, and can manipulate,
these memory addresses (through pointers).  Python handles it
differently and does not give you this sort of ability, it all occurs
"under the hood".  Yes, the id() function will tell you the addresses,
but you can't do anything with them other than perhaps compare them.
It's really pretty much useless information.


So, a and b are actual memory addresses.

Does the term of a pointer exist in Python?
I mean if print(a) or print(b) outputs the object that a and b are 
linked to, then how do we access a's and b's memory locations themselves 
t create links among variables, one pointing to the other and so on?


Can a variable point to another variable or variables never point to 
other variables but instead are *only* linked to the objects of those 
var's instead?



--
What is now proved was at first only imagined!
--
http://mail.python.org/mailman/listinfo/python-list

Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.]

[Steven D'Aprano]

On Mon, 17 Jun 2013 23:39:10 -0700, Larry Hudson wrote:

> On 06/17/2013 08:50 AM, Simpleton wrote:
>> On 17/6/2013 2:58 μμ, Michael Torrie wrote:
>>
>> a = 5
>> b = a
>>
>> a <---> memory address
>> b <---> memory address
>>
>> I like to think a and b as references to the same memory address
>>
> Not quite:  a and b _are_ memory addresses,  

Not in Python they aren't. a and b are names in a namespace.


> At the same time, a and b
> are references to the data (the objects) stored in those memory
> locations.

Not in Python they aren't. In Python, objects are free to move around 
memory. Not all implementations take advantage of this freedom, but some 
like Jython, IronPython and PyPy do.


> The distinction is probably more important in languages like C/C++,
> where the _language_ gives you direct access to, and can manipulate,
> these memory addresses (through pointers).  Python handles it
> differently and does not give you this sort of ability, it all occurs
> "under the hood".  Yes, the id() function will tell you the addresses,
> but you can't do anything with them other than perhaps compare them. 
> It's really pretty much useless information.

The id() function does not tell you the address of the object, except by 
accident. The id() function gives you an arbitrary ID number for the 
object:


steve@runes:~$ ipy
IronPython 2.6 Beta 2 DEBUG (2.6.0.20) on .NET 2.0.50727.1433
Type "help", "copyright", "credits" or "license" for more information.
>>> id([])
43
>>> id('*')
44


steve@runes:~$ jython
Jython 2.5.1+ (Release_2_5_1, Aug 4 2010, 07:18:19) 
[OpenJDK Client VM (Sun Microsystems Inc.)] on java1.6.0_18
Type "help", "copyright", "credits" or "license" for more information.
>>> id([])
1
>>> id('*')
2



That some implementations happen to use a fixed memory address as the ID 
number is, well, a mere accident of implementation. That's not what id() 
*is*, any more than "id() returns the next value in an integer sequence 
starting from 43" just because that's what IronPython happens to do.



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.]

[Larry Hudson]

On 06/17/2013 08:50 AM, Simpleton wrote:

On 17/6/2013 2:58 μμ, Michael Torrie wrote:

a = 5
b = a

a <---> memory address
b <---> memory address

I like to think a and b as references to the same memory address

Not quite:  a and b _are_ memory addresses,  At the same time, a and b are references to the 
data (the objects) stored in those memory locations.


The distinction is probably more important in languages like C/C++, where the _language_ gives 
you direct access to, and can manipulate, these memory addresses (through pointers).  Python 
handles it differently and does not give you this sort of ability, it all occurs "under the 
hood".  Yes, the id() function will tell you the addresses, but you can't do anything with them 
other than perhaps compare them.  It's really pretty much useless information.


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

Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.]

[Steven D'Aprano]

On Tue, 18 Jun 2013 00:12:34 -0400, Dave Angel wrote:

> On 06/17/2013 10:42 PM, Steven D'Aprano wrote:
>> On Mon, 17 Jun 2013 21:06:57 -0400, Dave Angel wrote:
>>
>>> On 06/17/2013 08:41 PM, Steven D'Aprano wrote:

  

 In Python 3.2 and older, the data will be either UTF-4 or UTF-8,
 selected when the Python compiler itself is compiled.
>>>
>>> I think that was a typo.  Do you perhaps UCS-2 or UCS-4
>>
>> Yes, that would be better.
>>
>> UCS-2 is identical to UTF-16, except it doesn't support non-BMP
>> characters and therefore doesn't have surrogate pairs.
>>
>> UCS-4 is functionally equivalent to UTF-16,
> 
> Perhaps you mean UTF-32 ?


Yes, sorry for the repeated confusion.


>>   as far as I can tell. (I'm
>> not really sure what the difference is.)
>>
>>
> Now you've got me curious, by bringing up surrogate pairs.  Do you know
> whether a narrow build (say 3.2) really works as UTF16, so when you
> encode a surrogate pair (4 bytes) to UTF-8, it encodes a single Unicode
> character into a single UTF-8 sequence (prob.  4 bytes long) ?

In a Python narrow build, the internal storage of strings is equivalent 
to UTF-16: all characters in the Basic Multilingual Plane require two 
bytes:

py> sys.maxunicode
65535
py> sys.getsizeof('π') - sys.getsizeof('')
2

Outside of the BMP, characters are treated as a pair of surrogates:

py> c = chr(0x10F000)  # one character...
py> len(c)  # ...stored as a pair of surrogates
2

Encoding and decoding works fine:

py> c.encode('utf-8').decode('utf-8') == c
True
py> c.encode('utf-8')
b'\xf4\x8f\x80\x80'


The problem with surrogates is that it is possible to accidentally 
separate the pair, which leads to broken, invalid text:

py> c[0].encode('utf-8')
Traceback (most recent call last):
  File "", line 1, in 
UnicodeEncodeError: 'utf-8' codec can't encode character '\udbfc' in 
position 0: surrogates not allowed


(The error message is a little misleading; surrogates are allowed, but 
only if they make up a valid pair.)


Python's handling of UTF-16 is, as far as I know, correct. What isn't 
correct is that the high-level Python string methods assume that two 
bytes == one character, which can lead to surrogates being separated, 
which gives you junk text. Wide builds don't have this problem, because 
every character == four bytes, and neither does Python 3.



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.]

[Dave Angel]

On 06/17/2013 10:42 PM, Steven D'Aprano wrote:

On Mon, 17 Jun 2013 21:06:57 -0400, Dave Angel wrote:


On 06/17/2013 08:41 PM, Steven D'Aprano wrote:


 

In Python 3.2 and older, the data will be either UTF-4 or UTF-8,
selected when the Python compiler itself is compiled.


I think that was a typo.  Do you perhaps UCS-2 or UCS-4


Yes, that would be better.

UCS-2 is identical to UTF-16, except it doesn't support non-BMP
characters and therefore doesn't have surrogate pairs.

UCS-4 is functionally equivalent to UTF-16,


Perhaps you mean UTF-32 ?

 as far as I can tell. (I'm

not really sure what the difference is.)



Now you've got me curious, by bringing up surrogate pairs.  Do you know 
whether a narrow build (say 3.2) really works as UTF16, so when you 
encode a surrogate pair (4 bytes) to UTF-8, it encodes a single Unicode 
character into a single UTF-8 sequence (prob.  4 bytes long) ?




--
DaveA
--
http://mail.python.org/mailman/listinfo/python-list

Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.]

[Marcin Szamotulski]

> While you said to me to forget about memory locations, and that's indeed 
> made things easy to follow i still keep wondering, how Python internally 
> keeping tracks of 'x' and 'y' names as well as their referenced objects 
> (i.e. number 6).

There is an excellent blog post about CPython internals:
http://tech.blog.aknin.name/category/my-projects/pythons-innards/
but it might be difficult to follow if you cannot at least read C.
It explains how python virtual machine works internally, how the opcodes
are evaluated, how the three scopes globals, locals and builins find its
place (and how names are bind).  As far as I understand names are keys
in the scope dictionaries, which are exposed in the python level as
locals(), globals() and the builtin's.  This is how Python tracks names
and their values.  To be more precise, when you do:

>>> a = 1
>>> def f():
...  b=2

in the first line 'a' is added to the globals() dictionary with value 1,
and in the third line 'b' with value 2 is added to the local dictionary
of f.  It is also all explained in the python docs, and it reflects how
python is implemented (at least CPython).

> 
> After all the way i understand memory is as a series of bits like:
> 
> 0100010100001011010101001000100101001001111101001010010
> 
> So from the above binary form:
> 
> what is 'x', what is 'y', how's 'x' and 'y' differ from the actually 
> memory locations that are bound too, and of course what is the actual value.

'x' and 'y' are just strings which are written somewhere in the computer's
memory.

> 
> Its 3 things for me to consider, even in Python id internal level 
> detail. I want to understand this.
> 
> names, memory addresses, memory address's actual values

Names and values are not connected through their memory addresses but
because they live in a higher structure, name is a key and value is a value
of a dictionary (which is also represented in some way at the C level,
namely by PyDictObject ... but for this you need to first learn C, but
please read and understand the Python docs - there is already a lot
there for you ...

Best regards,
Marcin
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.]

[Steven D'Aprano]

On Tue, 18 Jun 2013 02:38:20 +, Steven D'Aprano wrote:

> On Tue, 18 Jun 2013 00:41:53 +, Steven D'Aprano wrote:
> 
>> In Python 3.2 and older, the data will be either UTF-4 or UTF-8,
>> selected when the Python compiler itself is compiled. In Python 3.3,
>> the data will be stored in either Latin-1, UTF-4, or UTF-8, depending
>> on the contents of the string.
> 
> UTF-4? UTF-8?
> 
> Whatever crack I was smoking, it obviously was *bad* crack.
> 
> That should be UTF-8 or UTF-16.

Good lord, that crack is worse than I thought.

UTF-16 and UTF-32. 

Bloody hell. I am ashamed.


-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.]

[Steven D'Aprano]

On Mon, 17 Jun 2013 21:06:57 -0400, Dave Angel wrote:

> On 06/17/2013 08:41 PM, Steven D'Aprano wrote:
>>
>> 
>>
>> In Python 3.2 and older, the data will be either UTF-4 or UTF-8,
>> selected when the Python compiler itself is compiled.
> 
> I think that was a typo.  Do you perhaps UCS-2 or UCS-4

Yes, that would be better.

UCS-2 is identical to UTF-16, except it doesn't support non-BMP 
characters and therefore doesn't have surrogate pairs.

UCS-4 is functionally equivalent to UTF-16, as far as I can tell. (I'm 
not really sure what the difference is.)


-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.]

[Steven D'Aprano]

On Tue, 18 Jun 2013 00:41:53 +, Steven D'Aprano wrote:

> In Python 3.2 and older, the data will be either UTF-4 or UTF-8,
> selected when the Python compiler itself is compiled. In Python 3.3, the
> data will be stored in either Latin-1, UTF-4, or UTF-8, depending on the
> contents of the string.

UTF-4? UTF-8?

Whatever crack I was smoking, it obviously was *bad* crack.

That should be UTF-8 or UTF-16.



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.]

[Dave Angel]

On 06/17/2013 08:41 PM, Steven D'Aprano wrote:




In Python 3.2 and older, the data will be either UTF-4 or UTF-8, selected
when the Python compiler itself is compiled.


I think that was a typo.  Do you perhaps UCS-2 or UCS-4


In Python 3.3, the data will
be stored in either Latin-1, UTF-4, or UTF-8, depending on the contents
of the string.




--
DaveA
--
http://mail.python.org/mailman/listinfo/python-list

Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.]

[Steven D'Aprano]

On Tue, 18 Jun 2013 02:26:39 +0300, Νίκος wrote:

> Στις 18/6/2013 2:09 πμ, ο/η Steven D'Aprano έγραψε:
>> {"a": "Hello world"}
>>
>> Do you see a memory location there? There is no memory location. There
>> is the name, "a", and the object it is associated with, "Hello world".
>> Either the dict, or the string, may move around memory if the
>> underlying memory manager allows it. Obviously any object in Python
>> must be *somewhere* in memory at any specific moment, but that is
>> irrelevant to understanding Python code. It is no more relevant than
>> saying that a dict {'a': 5} is just made up of bits.
> 
> Okey, the easy part was to understand how humans in high level need to
> understand namespaces and assignment (which is not copying but instead
> referencing another name to the same object).
> 
> But i would like to know, what happens internally within the python
> compiler, because obviously memory is involved.

Depends which Python compiler.

CPython, IronPython, PyPy, Jython, Nuitka, Cython, ... ? They all operate 
differently on the inside. Only the high-level Python code has to be the 
same.

Jython works according to the JRE, the Java Runtime Environment. There is 
masses of information about that on the Internet, google for it.

IronPython works according to the .Net runtime environment. Again, google 
for it.

PyPy is a VERY complex but powerful JIT compiler. You can read about it 
on the PyPy blog. Start here: http://morepypy.blogspot.com/

There's not a lot of documentation on how CPython works internally. You 
have to read the C source code. You will need to understand about garbage 
collectors, memory management, the difference between the stack and the 
heap, etc. It's a big area to study. Don't expect anyone to spend the 
days or weeks it will take to explain the whole thing.


> The way some info(i.e. a Unicode string) is saved into the hdd , is the
> same way its being saved into the memory too? Same way exactly?

No. Unicode strings can be stored on disk in any encoding you like. 
Python stores string in memory as objects, which might look something 
like this:

[Type=str, size=42, data=...]

only more complicated. And subject to change -- anything you learn that 
holds for Python 3.3 might not apply for 3.2 or 3.4.

In Python 3.2 and older, the data will be either UTF-4 or UTF-8, selected 
when the Python compiler itself is compiled. In Python 3.3, the data will 
be stored in either Latin-1, UTF-4, or UTF-8, depending on the contents 
of the string.


> While you said to me to forget about memory locations, and that's indeed
> made things easy to follow i still keep wondering, how Python internally
> keeping tracks of 'x' and 'y' names as well as their referenced objects
> (i.e. number 6).

Good question, but I don't have a good answer. It has to do with the 
Python's memory manager, and the garbage collector. I don't know how they 
work.



> After all the way i understand memory is as a series of bits like:
> 
> 0100010100001011010101001000100101001001111101001010010
> 
> So from the above binary form:
> 
> what is 'x', what is 'y', how's 'x' and 'y' differ from the actually
> memory locations that are bound too, and of course what is the actual
> value.
> 
> Its 3 things for me to consider, even in Python id internal level
> detail. I want to understand this.
> 
> names, memory addresses, memory address's actual values


Start here:

https://duckduckgo.com/html/?q=how%20computers%20work



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.]

[Νίκος]

Στις 18/6/2013 2:09 πμ, ο/η Steven D'Aprano έγραψε:

{"a": "Hello world"}

Do you see a memory location there? There is no memory location. There is
the name, "a", and the object it is associated with, "Hello world".
Either the dict, or the string, may move around memory if the underlying
memory manager allows it. Obviously any object in Python must be
*somewhere* in memory at any specific moment, but that is irrelevant to
understanding Python code. It is no more relevant than saying that a dict
{'a': 5} is just made up of bits.


Okey, the easy part was to understand how humans in high level need to 
understand namespaces and assignment (which is not copying but instead 
referencing another name to the same object).


But i would like to know, what happens internally within the python 
compiler, because obviously memory is involved.


The way some info(i.e. a Unicode string) is saved into the hdd , is the 
same way its being saved into the memory too? Same way exactly?


While you said to me to forget about memory locations, and that's indeed 
made things easy to follow i still keep wondering, how Python internally 
keeping tracks of 'x' and 'y' names as well as their referenced objects 
(i.e. number 6).


After all the way i understand memory is as a series of bits like:

0100010100001011010101001000100101001001111101001010010

So from the above binary form:

what is 'x', what is 'y', how's 'x' and 'y' differ from the actually 
memory locations that are bound too, and of course what is the actual value.


Its 3 things for me to consider, even in Python id internal level 
detail. I want to understand this.


names, memory addresses, memory address's actual values

--
What is now proved was at first only imagined!
--
http://mail.python.org/mailman/listinfo/python-list

Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.]

[Steven D'Aprano]

On Mon, 17 Jun 2013 14:34:57 +0300, Simpleton wrote:

> On 17/6/2013 9:51 πμ, Steven D'Aprano wrote:
>> Now, in languages like Python, Ruby, Java, and many others, there is no
>> table of memory addresses. Instead, there is a namespace, which is an
>> association between some name and some value:
>>
>> global namespace:
>>  x --> 23
>>  y --> "hello world"
> 
> First of all thanks for the excellent and detailed explanation Steven.
> 
> As for namespace:
> 
> a = 5
> 
> 1. a is associated to some memory location 

No. a is associated to an object, the int 5, which may be free to move in 
memory (PyPy does this), or may be at a fixed memory location (CPython 
does this). But the association is with the object, not the memory 
location.

The object is a data structure that contains a type (int), a value (5), 
and various methods (e.g. bit_length, to_bytes).


2. the latter holds value 5
> 
> So 'a', is a reference to that memory location, so its more like a name
> to that memory location, yes? Instead of accessing a memory address with
> a use of an integer like "14858485995" we use 'a' instead.

No. We're talking about what the Python interpreter does, not what you 
do. Whether you are programming in C or Python, you still refer to 
variables by name:

a = 5

but what goes on inside the interpreter or compiler is different.


> So is it safe to say that in Python a == &a ? (& stands for memory
> address)

Absolutely not.


> is the above correct?
> 
> I say this because here you said that: Instead, there is a namespace,
> which is anassociation between some name and some value:
> 
> When you say that you mean that a is associated to some value as in
> memory location or to that memory location's address?

No. This has nothing to do with memory locations. Namespaces are dicts. 
Write down a dict:

{"a": "Hello world"}

Do you see a memory location there? There is no memory location. There is 
the name, "a", and the object it is associated with, "Hello world". 
Either the dict, or the string, may move around memory if the underlying 
memory manager allows it. Obviously any object in Python must be 
*somewhere* in memory at any specific moment, but that is irrelevant to 
understanding Python code. It is no more relevant than saying that a dict 
{'a': 5} is just made up of bits.



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.]

[Terry Reedy]

On 6/17/2013 1:17 PM, Νίκος wrote:

On Mon, Jun 17, 2013 at 8:55 AM, Simpleton  wrote:

On 17/6/2013 5:22 μμ, Terry Reedy wrote:



When you interpret Python code, do you put data in locations with
integer addresses?



I lost you here.


Memory in biological brains is not a linear series of bits, or 
characters. How we do associate things is still mostly a puzzle.


Read about holographic memory.


The way some info(i.e. a Unicode string) is saved into the hdd , is the
same way its being saved into the memory too? Same way exactly?


No. A unicode string is a sequence of abstract characters or codepoints. 
They must be encoded somehow to map them to linear byte memory. There 
are still (too) many encodings in use. Most cannot encode *all* unicode 
characters.


CPython is unusual in using one of three different encodings for 
internal unicode strings.



While you said to me to forget about memory locations,


This is excellent advice. One of the *features* of Python is that one 
*can* forget about addresses. One of the *problems* of C is that many 
people *do* forget about memory locations, while virus writers study 
them carefully.


--
Terry Jan Reedy


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

Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.]

[Νίκος]

On 17/6/2013 7:23 μμ, Benjamin Kaplan wrote:

On Mon, Jun 17, 2013 at 8:55 AM, Simpleton  wrote:

On 17/6/2013 5:22 μμ, Terry Reedy wrote:


On 6/17/2013 7:34 AM, Simpleton wrote:


On 17/6/2013 9:51 πμ, Steven D'Aprano wrote:


Now, in languages like Python, Ruby, Java, and many others, there is no
table of memory addresses. Instead, there is a namespace, which is an
association between some name and some value:

global namespace:
  x --> 23
  y --> "hello world"



First of all thanks for the excellent and detailed explanation Steven.

As for namespace:

a = 5

1. a is associated to some memory location
2. the latter holds value 5



This is backwards. If the interpreter puts 5 in a *permanent* 'memory
location' (which is not required by the language!), then it can
associate 'a' with 5 by associating it with the memory location. CPython
does this, but some other computer implementations do not.



Please tell me how do i need to understand the sentence
'a' is being associated with number 5 in detail.

Why don't we access the desired value we want to, by referencing to that
value's memory location directly instead of using namespaces wich is an
indirect call?

i feel we have 3 things here

a , memory address of a stored value, actual stored value


So is it safe to say that in Python a == &a ? (& stands for memory
address)

is the above correct?



When you interpret Python code, do you put data in locations with
integer addresses?



I lost you here.



You're confusing the way in which the CPython interpreter is written
with the way the Python language is defined. Yes, the CPython
interpreter puts 5 into a numbered memory location when creating the
object. But the Nikos Python Interpreter (which is a completely valid,
although quite buggy, Python interpreter that uses your head to
interpret the code) should not be using numbered memory locations.

Forget about memory locations. Memory locations don't exist. Let's use
the pen-and-paper Python interpreter. On the left side of the paper,
we'll write down the names. On the rest of the paper, we'll write down
the objects.

When I do "x =[]", I make a new list (which means I write down []
somewhere in the middle of the page), I create the name "x" (which
means I write down an "x" on the left side of the page), and then I
draw an arrow pointing from the x to the [].
(sorry if my drawing doesn't line up in your email/news client- I'll
try to make it line up correctly with a monospace font)

|  x --> []|
|  |
|  |


Now, When we do y = x, the right side of the equation is evaluated
(which gives us the object currently bound to the name x) and it is
then given the newly created name "y"

|  x --> []|
| ^|
|   y ||


When we do x.append(3), the object that x refers to is modified. This
is seen by both x and y because they point to the same object.


|  x --> [3]   |
| ^|
|   y ||


When I do x = [], a new object is created somewhere else on the page,
and the name x is made to point to the new object. This changes the
arrow. The name "x" is not in any way tied to the location of the [3]
on the page. This doesn't impact "y" which is still pointing at the
same spot it was before


|  x >[] [3]   |
| ^|
|   y ||


That is how Python's object model works. In CPython, objects have
specified memory locations but names do not. In IronPython and Jython,
even that's not guaranteed- the garbage collector can move the objects
around during their lifetime, so while you can trust that a name will
always point to the correct object, you have no guarantee about where
the object is located in the computer's memory.


EXCELLENT EXPLANATION, THANK YOU VERY MUCH.
I AM SAVING THIS TO A .TXT FOR FUTURE REFERENCE.

THAT'S WHY I ASK YOU GUYS FOR HUMAN LIKE EXPLANATIONS.
THIS CANNOT BE FIND WITH SUCH SIMPLE WAY OF PUTTING THIS IN TECH DOCS.

Something else please:

The way some info(i.e. a Unicode string) is saved into the hdd , is the 
same way its being saved into the memory too? Same way exactly?


While you said to me to forget about memory locations, and that's indeed 
made things easy to follow i still keep wondering, how Python internally 
keeping tracks of 'x' and 'y' names as well as their referenced objec

Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.]

[Benjamin Kaplan]

On Mon, Jun 17, 2013 at 8:55 AM, Simpleton  wrote:
> On 17/6/2013 5:22 μμ, Terry Reedy wrote:
>>
>> On 6/17/2013 7:34 AM, Simpleton wrote:
>>>
>>> On 17/6/2013 9:51 πμ, Steven D'Aprano wrote:

 Now, in languages like Python, Ruby, Java, and many others, there is no
 table of memory addresses. Instead, there is a namespace, which is an
 association between some name and some value:

 global namespace:
  x --> 23
  y --> "hello world"
>>>
>>>
>>> First of all thanks for the excellent and detailed explanation Steven.
>>>
>>> As for namespace:
>>>
>>> a = 5
>>>
>>> 1. a is associated to some memory location
>>> 2. the latter holds value 5
>>
>>
>> This is backwards. If the interpreter puts 5 in a *permanent* 'memory
>> location' (which is not required by the language!), then it can
>> associate 'a' with 5 by associating it with the memory location. CPython
>> does this, but some other computer implementations do not.
>
>
> Please tell me how do i need to understand the sentence
> 'a' is being associated with number 5 in detail.
>
> Why don't we access the desired value we want to, by referencing to that
> value's memory location directly instead of using namespaces wich is an
> indirect call?
>
> i feel we have 3 things here
>
> a , memory address of a stored value, actual stored value
>
>>> So is it safe to say that in Python a == &a ? (& stands for memory
>>> address)
>>>
>>> is the above correct?
>>
>>
>> When you interpret Python code, do you put data in locations with
>> integer addresses?
>
>
> I lost you here.
>

You're confusing the way in which the CPython interpreter is written
with the way the Python language is defined. Yes, the CPython
interpreter puts 5 into a numbered memory location when creating the
object. But the Nikos Python Interpreter (which is a completely valid,
although quite buggy, Python interpreter that uses your head to
interpret the code) should not be using numbered memory locations.

Forget about memory locations. Memory locations don't exist. Let's use
the pen-and-paper Python interpreter. On the left side of the paper,
we'll write down the names. On the rest of the paper, we'll write down
the objects.

When I do "x =[]", I make a new list (which means I write down []
somewhere in the middle of the page), I create the name "x" (which
means I write down an "x" on the left side of the page), and then I
draw an arrow pointing from the x to the [].
(sorry if my drawing doesn't line up in your email/news client- I'll
try to make it line up correctly with a monospace font)

|  x --> []|
|  |
|  |


Now, When we do y = x, the right side of the equation is evaluated
(which gives us the object currently bound to the name x) and it is
then given the newly created name "y"

|  x --> []|
| ^|
|   y ||


When we do x.append(3), the object that x refers to is modified. This
is seen by both x and y because they point to the same object.


|  x --> [3]   |
| ^|
|   y ||


When I do x = [], a new object is created somewhere else on the page,
and the name x is made to point to the new object. This changes the
arrow. The name "x" is not in any way tied to the location of the [3]
on the page. This doesn't impact "y" which is still pointing at the
same spot it was before


|  x >[] [3]   |
| ^|
|   y ||


That is how Python's object model works. In CPython, objects have
specified memory locations but names do not. In IronPython and Jython,
even that's not guaranteed- the garbage collector can move the objects
around during their lifetime, so while you can trust that a name will
always point to the correct object, you have no guarantee about where
the object is located in the computer's memory.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.]

[Joel Goldstick]

On Mon, Jun 17, 2013 at 11:55 AM, Simpleton  wrote:

> On 17/6/2013 5:22 μμ, Terry Reedy wrote:
>
>> On 6/17/2013 7:34 AM, Simpleton wrote:
>>
>>> On 17/6/2013 9:51 πμ, Steven D'Aprano wrote:
>>>
 Now, in languages like Python, Ruby, Java, and many others, there is no
 table of memory addresses. Instead, there is a namespace, which is an
 association between some name and some value:

 global namespace:
  x --> 23
  y --> "hello world"

>>>
>>> First of all thanks for the excellent and detailed explanation Steven.
>>>
>>> As for namespace:
>>>
>>> a = 5
>>>
>>> 1. a is associated to some memory location
>>> 2. the latter holds value 5
>>>
>>
>> This is backwards. If the interpreter puts 5 in a *permanent* 'memory
>> location' (which is not required by the language!), then it can
>> associate 'a' with 5 by associating it with the memory location. CPython
>> does this, but some other computer implementations do not.
>>
>
> Please tell me how do i need to understand the sentence
> 'a' is being associated with number 5 in detail.
>
> Why don't we access the desired value we want to, by referencing to that
> value's memory location directly instead of using namespaces wich is an
> indirect call?
>
> i feel we have 3 things here
>
> a , memory address of a stored value, actual stored value
>
>  So is it safe to say that in Python a == &a ? (& stands for memory
>>> address)
>>>
>>> is the above correct?
>>>
>>
>> When you interpret Python code, do you put data in locations with
>> integer addresses?
>>
>
> I lost you here.
>
>
>
> --
> What is now proved was at first only imagined!
> --
> http://mail.python.org/**mailman/listinfo/python-list
>


Read and study this.  Then come back and ask again.  Don't think of
physical representation of memory with actual binary addresses.  Python is
not assembler.  Neither is it C (sometimes called high level assembler)
http://docs.python.org/2/tutorial/classes.html#python-scopes-and-namespaces

-- 
Joel Goldstick
http://joelgoldstick.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.]

[Simpleton]

On 17/6/2013 5:22 μμ, Terry Reedy wrote:

On 6/17/2013 7:34 AM, Simpleton wrote:

On 17/6/2013 9:51 πμ, Steven D'Aprano wrote:

Now, in languages like Python, Ruby, Java, and many others, there is no
table of memory addresses. Instead, there is a namespace, which is an
association between some name and some value:

global namespace:
 x --> 23
 y --> "hello world"


First of all thanks for the excellent and detailed explanation Steven.

As for namespace:

a = 5

1. a is associated to some memory location
2. the latter holds value 5


This is backwards. If the interpreter puts 5 in a *permanent* 'memory
location' (which is not required by the language!), then it can
associate 'a' with 5 by associating it with the memory location. CPython
does this, but some other computer implementations do not.


Please tell me how do i need to understand the sentence
'a' is being associated with number 5 in detail.

Why don't we access the desired value we want to, by referencing to that 
value's memory location directly instead of using namespaces wich is an 
indirect call?


i feel we have 3 things here

a , memory address of a stored value, actual stored value


So is it safe to say that in Python a == &a ? (& stands for memory
address)

is the above correct?


When you interpret Python code, do you put data in locations with
integer addresses?


I lost you here.


--
What is now proved was at first only imagined!
--
http://mail.python.org/mailman/listinfo/python-list

Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.]

[Simpleton]

On 17/6/2013 2:58 μμ, Michael Torrie wrote:

In python just think of assignment as making a name *be* an object.  And
if you assign one name to another name, that makes both names be the
same object.  When names are unbound (either they go out of scope or you
manually unbind them), the objects they are bound to are garbage collected.


"Object" here being the memory location, right?
When we say a = 5

a = an easy way for calling that "fixed memory location" that holds our 
value, instead of calling it in binary format or in hex format.

This is the direct object a is pointing too. Correct?

5 = *this* is the indirect object that a outputs when we print a.

Are the above statements correct Michael?

a = 5
b = a

a <---> memory address
b <---> memory address

I like to think a and b as references to the same memory address



--
What is now proved was at first only imagined!
--
http://mail.python.org/mailman/listinfo/python-list

Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.]

[Terry Reedy]

On 6/17/2013 7:34 AM, Simpleton wrote:

On 17/6/2013 9:51 πμ, Steven D'Aprano wrote:

Now, in languages like Python, Ruby, Java, and many others, there is no
table of memory addresses. Instead, there is a namespace, which is an
association between some name and some value:

global namespace:
 x --> 23
 y --> "hello world"


First of all thanks for the excellent and detailed explanation Steven.

As for namespace:

a = 5

1. a is associated to some memory location
2. the latter holds value 5


This is backwards. If the interpreter puts 5 in a *permanent* 'memory 
location' (which is not required by the language!), then it can 
associate 'a' with 5 by associating it with the memory location. CPython 
does this, but some other computer implementations do not.



So 'a', is a reference to that memory location, so its more like a name
to that memory location, yes? Instead of accessing a memory address with
a use of an integer like "14858485995" we use 'a' instead.

So is it safe to say that in Python a == &a ? (& stands for memory address)

is the above correct?


When you interpret Python code, do you put data in locations with 
integer addresses?


--
Terry Jan Reedy


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

Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.]

[Michael Torrie]

On 06/17/2013 05:34 AM, Simpleton wrote:
> So is it safe to say that in Python a == &a ? (& stands for memory address)
> 
> is the above correct?

It might be partially equivalent inside the interpreter, but it's not
something you should concern yourself with.  And in general, no it's not
safe to say, since Python is a reference-counted, garbage-collected
object system and pointers in C certainly are not.

> I say this because here you said that: Instead, there is a namespace, 
> which is anassociation between some name and some value:
> 
> When you say that you mean that a is associated to some value as in 
> memory location or to that memory location's address?

In python just think of assignment as making a name *be* an object.  And
if you assign one name to another name, that makes both names be the
same object.  When names are unbound (either they go out of scope or you
manually unbind them), the objects they are bound to are garbage collected.

Forget about the details of how the interpreter might doing at a low level.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.]

[Simpleton]

On 17/6/2013 9:51 πμ, Steven D'Aprano wrote:

Now, in languages like Python, Ruby, Java, and many others, there is no
table of memory addresses. Instead, there is a namespace, which is an
association between some name and some value:

global namespace:
 x --> 23
 y --> "hello world"


First of all thanks for the excellent and detailed explanation Steven.

As for namespace:

a = 5

1. a is associated to some memory location
2. the latter holds value 5

So 'a', is a reference to that memory location, so its more like a name 
to that memory location, yes? Instead of accessing a memory address with 
a use of an integer like "14858485995" we use 'a' instead.


So is it safe to say that in Python a == &a ? (& stands for memory address)

is the above correct?

I say this because here you said that: Instead, there is a namespace, 
which is anassociation between some name and some value:


When you say that you mean that a is associated to some value as in 
memory location or to that memory location's address?




--
What is now proved was at first only imagined!
--
http://mail.python.org/mailman/listinfo/python-list

Re: A certainl part of an if() structure never gets executed.

[Michael Weylandt]

On Jun 17, 2013, at 6:17, Νίκος  wrote:

> On 16/6/2013 9:53 μμ, R. Michael Weylandt wrote:
>> On Sun, Jun 16, 2013 at 2:47 PM, Ferrous Cranus  wrote:
>>> On 16/6/2013 2:13 μμ, Jussi Piitulainen wrote:
 
 If, instead of the above, you have
 
 a = 6
 b = a
 b = 5
 
 you will find that b == 5 and a == 6. So b is not the same as a. Else
 one would have changed when the other changed. I would say that a and
 b are different variables. They had the same value, briefly.
>>> 
>>> 
>>> If they were different variables then they would have different memory
>>> addresses and they would act like two different objects.
>>> 
>>> But... both a and b are for a fact mappings for the same memory address as
>>> seen form the following command.
>>> 
>> id(a) == id(b)
>>> True
>>> 
>>> They are like the same object with 2 different names.
>> 
>> This will depend on when the test is run:
>> 
>> a = 6
>> b = a
>> a is b # True
>> 
>> b = 5
>> a is b # False
>> 
>> The latter is false because the binding of "b" to the int 6 was broken
>> in order to bind b to the int 5.
> 
> Very surprising.
> a and b was *references* to the same memory address, it was like a memory 
> address having 2 names to be addresses as.
> 
> b = a name we use to address some memory location, do we agree on that?
> 
> So, b = 6, must have changed the stored value of its mapped memory location, 
> but given you example it seems its changing the mapping of b to some other 
> memory address.
> 
> I don't follow its act of course.

I'm having trouble understanding your grammar in the above, but please re-read 
my note on the dual behavior of `=` here:

http://mail.python.org/pipermail/python-list/2013-June/649990.html

Michael
-- 
http://mail.python.org/mailman/listinfo/python-list

Variables versus name bindings [Re: A certainl part of an if() structure never gets executed.]

[Steven D'Aprano]

On Mon, 17 Jun 2013 08:17:48 +0300, Νίκος wrote:

[...]
>> The latter is false because the binding of "b" to the int 6 was broken
>> in order to bind b to the int 5.
> 
> Very surprising.
> a and b was *references* to the same memory address, it was like a
> memory address having 2 names to be addresses as.
> 
> b = a name we use to address some memory location, do we agree on that?
> 
> So, b = 6, must have changed the stored value of its mapped memory
> location, but given you example it seems its changing the mapping of b
> to some other memory address.
> 
> I don't follow its act of course.


Let me explain how variables work in some other languages, and how they 
work in Python. (And Ruby, and Java, and many others.)

In a language like Pascal, or C, the compiler keeps a table mapping 
variable names to fixed memory addresses, like this:

Variable  Address
  ===
x 10234
y 10238
z 10242


Code like:

x := 42;
y := x + 1;


will get compiled into something that looks like this:

# Pseudo-code
STORE 42 AT ADDRESS 10234;
READ ADDRESS 10234;
STORE (LAST RESULT + 1) AT ADDRESS 10238;


The important thing is that memory addresses are known at compile time, 
and at least in general, variables cannot move around in memory. Another 
important thing is that assignment is copying:

x := y;

becomes:

READ ADDRESS 10234;
STORE (LAST RESULT) AT ADDRESS 10238;

which is equivalent to:

COPY ADDRESS 10234 TO ADDRESS 10238;

If, instead of an integer, x was an array of 1000 integers, all 1000 
integers would need to be copied.

Now, in languages like Python, Ruby, Java, and many others, there is no 
table of memory addresses. Instead, there is a namespace, which is an 
association between some name and some value:

global namespace:
x --> 23
y --> "hello world"


In Python, namespaces are *dicts*, just like those you create with {}.

Code like:

x = 42
y = x + 1


is treated as:

# Pseudocode
create the object 42
bind it to the name 'x'
look up the name 'x'
add 1 to it
bind it to the name 'y'


where "bind" means to change the association in the namespace:

global namespace:
x --> 42
y --> 43


One important thing is that binding does *not* make a copy of the object. 
Assignment is equally fast whether you have one int or a list or a 
million ints. So code like this:

x = y

results in both names 'x' and 'y' being associated to the same object. 
With ints, that's pretty boring, but for mutable objects like lists, it 
means that you get two names for the same list:

py> x = []
py> y = x
py> y.append("Surprise!")
py> x
['Surprise!']


This sort of behaviour is trivial in languages with name-binding 
semantics, like Python, but quite tricky in languages like Pascal. You 
have to explicitly work with pointers or other indirect memory access, 
leading to extra effort and the possibility of serious bugs.

Note also that because you aren't dealing with fixed memory addresses, 
objects are free to be moved in memory for better memory usage and less 
fragmentation. CPython doesn't do this, but PyPy does, and I expect that 
both Jython and IronPython probably do too. So long as the runtime 
environment can (somehow) track when objects are moved, it all works out 
fine.

Another difference is that in C-like languages, variables always have a 
value, even if it's not a useful value. As soon as the compiler decides 
that variable 'z' will be at address 10242, then 'z' has an implied value 
made up of whatever junk happens to be at that address. Some compilers 
will warn you if you try to use a variable without assigning to it first, 
since using junk you happen to find lying around in memory is usually a 
bad thing, but not all compilers.

In contrast, Python doesn't have this issue. If you haven't assigned to 
'z', then there is no such thing as 'z' in your namespace, and trying to 
use it will automatically give you an error:

py> x = z - 1
Traceback (most recent call last):
  File "", line 1, in 
NameError: name 'z' is not defined


There are other differences in regards to passing arguments to functions. 
I've written about that before:

http://mail.python.org/pipermail/tutor/2010-December/080505.html


-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: A certainl part of an if() structure never gets executed.

[Νίκος]

On 16/6/2013 9:53 μμ, R. Michael Weylandt wrote:

On Sun, Jun 16, 2013 at 2:47 PM, Ferrous Cranus  wrote:

On 16/6/2013 2:13 μμ, Jussi Piitulainen wrote:


If, instead of the above, you have

a = 6
b = a
b = 5

you will find that b == 5 and a == 6. So b is not the same as a. Else
one would have changed when the other changed. I would say that a and
b are different variables. They had the same value, briefly.



If they were different variables then they would have different memory
addresses and they would act like two different objects.

But... both a and b are for a fact mappings for the same memory address as
seen form the following command.


id(a) == id(b)

True

They are like the same object with 2 different names.


This will depend on when the test is run:

a = 6
b = a
a is b # True

b = 5
a is b # False

The latter is false because the binding of "b" to the int 6 was broken
in order to bind b to the int 5.


Very surprising.
a and b was *references* to the same memory address, it was like a 
memory address having 2 names to be addresses as.


b = a name we use to address some memory location, do we agree on that?

So, b = 6, must have changed the stored value of its mapped memory 
location, but given you example it seems its changing the mapping of b 
to some other memory address.


I don't follow its act of course.

--
What is now proved was at first only imagined!
--
http://mail.python.org/mailman/listinfo/python-list

Re: Compiling vs interpreting [was Re: A certainl part of an if() structure never gets executed.]

[Chris Angelico]

On Mon, Jun 17, 2013 at 6:02 AM, Steven D'Aprano
 wrote:
> On Sun, 16 Jun 2013 12:31:59 -0700, Mark Janssen wrote:
>>> The line between compilers
>>> and interpreters is quite fuzzy.
>>
>> It shouldn't be.
>
> Of course it should be, because that reflects reality.

It's fuzzy AND it seldom even matters. Compare these three text strings:

"""''

"""'a'*64"""

"""\37\213\b\b*8\276Q\0\3test\0KL\244\f\0\0Ue\264\211@\0\0\0"""

"""\x78\xda\x4b\x4c\xa4\x0c\0\0\x14\x8d\x18\x41"""

Which of these is an interpreted program? I would say: All of them.
And they all produce the same output, a series of 64 copies of the
letter a. The third one is interpreted by gzip(1) and will create a
file called 'test', the fourth is a raw gzip/zlib stream and so is
interpreted by (eg) the Python zlib.decompress() function. They're all
languages, of a sort. Are they interpreted/compiled versions of that
message? Kinda. If you prepend a sfx header to them, do they become
compiled and not interpreted? Doubtful. I don't think you could say
that this ceases to be interpreted:

import zlib
print(zlib.decompress(
"""\x78\xda\x4b\x4c\xa4\x0c\0\0\x14\x8d\x18\x41"""
))

Even if you manually imported the code for zlib.decompress, in a way
that makes it impossible for your cut-down program to actually
compress data (which then breaks the principle quoted from
"Programming in Lua"), it's still fairly clearly being
interpreted/parsed the exact same way.

So it really doesn't matter (so it really doesn't matter (so it really
doesn't matter)). [1]

ChrisA

[1] http://math.boisestate.edu/gas/ruddigore/web_opera/rudd24.html
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Compiling vs interpreting [was Re: A certainl part of an if() structure never gets executed.]

[Steven D'Aprano]

On Sun, 16 Jun 2013 12:31:59 -0700, Mark Janssen wrote:

 Whats the difference of "interpreting " to "compiling" ?
>>>
>>> OK, I give up!
>>
>> Actually, that's a more subtle question than most people think. Python,
>> for example, is a compiled language. (What did you think the "c" in
>> ".pyc" files stood for? and the compile() function>?)
> 
> Careful there.  This terminology is not agreed upon universally

Which is why I said it was a more subtle question than most people think. 
Most people think that there is One True Definition of compiling/
interpreting, usually based on an over-simplified model of program 
execution that was obsolete in the 1970s.

> (that
> is, within the realm of academia where the notion of mastery exists),

The notion of mastery exists in many places, not just academia.


> and unless you are citing an actual reference or publishing one
> yourself, then you may be adding more confusion than illumination. For
> example, I would say that it is an *interpreted language* that gets
> compiled at run-time.

Apart from the contradiction there -- if it is compiled, why do you 
insist on calling it interpreted? -- you would be wrong. Languages are 
neither interpreted nor compiled. Languages are abstract entities that 
describe what syntax is permitted, and what functionality is provided. It 
is only concrete implementations which are interpreted or compiled.

In the case of Python, we have:

CPython: compiled to byte-code for it's own virtual machine;

Jython: compiled to byte-code for the JRE;

IronPython: compiled to byte-code for the .Net runtime;

PyPy: JIT compiler that generates machine code;

Nuitka: static compiler that generates machine code;

etc. So, the answer to the question "Is Python compiled or interpreted?" 
is, "Yes."



[...]
>> And these days, for many types of hardware, even machine-code is often
>> interpreted by a virtual machine on a chip. And even languages which
>> compile to machine-code often use an intermediate platform-independent
>> form rather than targeting pure machine-code.
> 
> Do you have a reference for this?  What language?

https://en.wikipedia.org/wiki/Microcode



>> The line between compilers
>> and interpreters is quite fuzzy.
> 
> It shouldn't be.

Of course it should be, because that reflects reality.


> What is fuzzy is the definition of "interpreter",
> however.  The definition of compiler has only become fuzzy with the
> advent of the personal computer.

Incorrect. Lisp predates the PC, and it is a good example of a language 
with implementations which combine features of compile-to-machine-code 
and execute-high-level-code-at-run-time (i.e. both "compiler" and 
"interpreter" behaviour, at the same time). Lisp is nearly as old as 
Fortran.

Forth is another such language. It's not quite so old as Lisp, but it is 
especially interesting because Forth includes commands to switch from 
"compile mode" to "interpret mode" on the fly. So is it a compiler or an 
interpreter? Yes.


-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Compiling vs interpreting [was Re: A certainl part of an if() structure never gets executed.]

[Mark Janssen]

>>> Whats the difference of "interpreting " to "compiling" ?
>>
>> OK, I give up!
>
> Actually, that's a more subtle question than most people think. Python,
> for example, is a compiled language. (What did you think the "c" in
> ".pyc" files stood for? and the compile() function>?)

Careful there.  This terminology is not agreed upon universally (that
is, within the realm of academia where the notion of mastery exists),
and unless you are citing an actual reference or publishing one
yourself, then you may be adding more confusion than illumination.
For example, I would say that it is an *interpreted language* that
gets compiled at run-time.  Some (*valid*) definitions of "compiler"
mean a strict mapping from the language syntax and lexical definition
to a sequence of bytes that can be fed to a (hardware not virtual)
machine architecture to do perform what is requested.  The face that
an extension ends in the letter "c" is not sufficient evidence, since
file extensions have no strict standard.

> And these days, for many types of hardware, even machine-code is often
> interpreted by a virtual machine on a chip. And even languages which
> compile to machine-code often use an intermediate platform-independent
> form rather than targeting pure machine-code.

Do you have a reference for this?  What language?

> The line between compilers
> and interpreters is quite fuzzy.

It shouldn't be.  What is fuzzy is the definition of "interpreter",
however.  The definition of compiler has only become fuzzy with the
advent of the personal computer.

> Probably the best definition I've seen for the difference between a
> modern compiler and interpreter is this one:
>
> "...the distinguishing feature of interpreted languages is not that they
> are not compiled, but that the compiler is part of the language runtime
> and that, therefore, it is possible (and easy) to execute code generated
> on the fly."

That's reasonable.
-- 
MarkJ
Tacoma, Washington
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: A certainl part of an if() structure never gets executed.

[R. Michael Weylandt]

On Sun, Jun 16, 2013 at 2:47 PM, Ferrous Cranus  wrote:
> On 16/6/2013 2:13 μμ, Jussi Piitulainen wrote:
>>
>> If, instead of the above, you have
>>
>> a = 6
>> b = a
>> b = 5
>>
>> you will find that b == 5 and a == 6. So b is not the same as a. Else
>> one would have changed when the other changed. I would say that a and
>> b are different variables. They had the same value, briefly.
>
>
> If they were different variables then they would have different memory
> addresses and they would act like two different objects.
>
> But... both a and b are for a fact mappings for the same memory address as
> seen form the following command.
>
 id(a) == id(b)
> True
>
> They are like the same object with 2 different names.

This will depend on when the test is run:

a = 6
b = a
a is b # True

b = 5
a is b # False

The latter is false because the binding of "b" to the int 6 was broken
in order to bind b to the int 5.

I might also suggest you restrain from trying to correct respondents
on these matters until you yourself understand them. It's only polite.

Michael
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: A certainl part of an if() structure never gets executed.

[R. Michael Weylandt]

On Sun, Jun 16, 2013 at 2:38 PM, Ferrous Cranus  wrote:
> On 16/6/2013 3:04 μμ, R. Michael Weylandt wrote:
 ## CODE SNIPPET##
 a = 552315251254
 b = a
 c =  552315251254

 a is b # True _on my machine_
>
>>
>> And this pattern continues for any sort of Python object.
 a is c # False _on my machine_
>
> And in mine is also True.
>

What do you mean "also true" here? You can't be "also true" in the
presence of a false. This makes little sense to me...

>
 id(a)
> 140160465571760
 id(b)
> 140160465571760
 id(c)
> 140160465571696
>
> Since all object result to point to actual number 6 why don't all of them
> (a,b,c) bound to the same memory address.

Look at the code they follow. (At least in this email) -- none of them
point to an object with value 6. They all point to a much larger
value.

>
> a and b seem both objects of the same identity, which means they are both
> bound to the same memory address(140160465571760)

Yes

>
> how come c's memory address is different than a's and b's ?
> After all, this is the 3rd object pointing to number 6.

Again, no it's not.

>
> And why not d and e and f and g are all objects of the same memory address?

What are these variables? They are referenced nowhere in any mail
between you and me.

>
>
a and b are the same object, with two different names. (No "if I want"
about it -- the distinction is important)

No idea what you mean by "unbounded memory address" here. (Yes I'm
aware I deleted a fairly meaningless line about it from the context)

>
> No i had no idea thagt was a bult-in help() function.
> So id() is actually the memory address of an object which uniquely
> identifies it.

Yes.


I think part of your confusion is coming from the dual interpretation
of the "=" operator in an expression like:

LHS = RHS

If RHS is some sort of literal, a conforming Python behaves as if
(modulo optimizations described below) a new object is created
according to that literal, put in memory and the name LHS is used to
point to it.

If RHS is a name (as in code such as "a = b"), the Python will find
the object to which "b" refers and add a new reference ("a") to it.

Some information on the CPython specific implementation details:

As part of the startup process, CPython creates some number of small
integers and adds them to the object cache.

Why? Because creating an object (even as simple as an int) is
relatively expensive and small integers are ubiquitous in programming.
This sacrifices some memory for a good deal of speed. But the payoff
becomes less as you go higher: almost all programs will use a 0 or a
2, fewer will use 247. At some point, the pre-creation stops. I
believe this is a compile time option.

Now, to make effective use of this caching, CPython will use a few
tricks to try to identify when one of the small ints appears in the
code. If it can identify it, I will replace the object creation with a
reference to the in-cache object. The exact times when this can happen
are not -- to my knowledge -- documented anywhere.

Now you might ask why Python doesn't realize that, in code like my
code snippet above, it could simply reuse the same int object for a,
b, and c. Conceivably it could, but it would require enormous energies
to check all currently existing objects for one that happens to be
equal to what you need (and is not mutable if that's relevant) and
it's simply faster to create the new int.

Michael
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: A certainl part of an if() structure never gets executed.

[Ferrous Cranus]

On 16/6/2013 2:13 μμ, Jussi Piitulainen wrote:

If, instead of the above, you have

a = 6
b = a
b = 5

you will find that b == 5 and a == 6. So b is not the same as a. Else
one would have changed when the other changed. I would say that a and
b are different variables. They had the same value, briefly.


If they were different variables then they would have different memory 
addresses and they would act like two different objects.


But... both a and b are for a fact mappings for the same memory address 
as seen form the following command.


>>> id(a) == id(b)
True

They are like the same object with 2 different names.
Like i'am a human being and me Greek friends call me "Νίκος" while you 
guys call me "Nick".


That the way i understand it so far.


--
What is now proved was at first only imagined!
--
http://mail.python.org/mailman/listinfo/python-list

Re: A certainl part of an if() structure never gets executed.

[Ferrous Cranus]

On 16/6/2013 3:04 μμ, R. Michael Weylandt wrote:

On Sun, Jun 16, 2013 at 12:06 PM, Ferrous Cranus  wrote:

I appreciate you've returned to your Ferrous Cranus persona for this
interchange. It reminds me not to get hung up on concerns of
futility...


On 16/6/2013 1:42 μμ, R. Michael Weylandt wrote:




## CODE SNIPPET##
a = 552315251254
b = a
c =  552315251254

a is b # True _on my machine_

>
> And this pattern continues for any sort of Python object.
>>> a is c # False _on my machine_

And in mine is also True.


>>> id(a)
140160465571760
>>> id(b)
140160465571760
>>> id(c)
140160465571696

Since all object result to point to actual number 6 why don't all of 
them (a,b,c) bound to the same memory address.


a and b seem both objects of the same identity, which means they are 
both bound to the same memory address(140160465571760)


how come c's memory address is different than a's and b's ?
After all, this is the 3rd object pointing to number 6.

And why not d and e and f and g are all objects of the same memory address?



In fact, b does not go "through" a. The memory address referenced
exists even if the "a" binding is removed using "del a" or some other
mechanism. Imagine this scenario:

[a]
 \
  6
/
[b]

Using the name "a" or "b" simply tells Python where to look for a
value, but the value itself is not associated with "a" or "b".


If i understood you correctly, you say:

unbounded memory address = value of 6

a = pointer to memory address that holds 6
b = pointer to memory address that holds 6

So, a and b, are two objects(two variable names if you want) that are 
bounded to the same memory address. And their value is the address of 
unbounded memory address.

Correct?


what id() does, never heard of that function before.



It seems you've also never heard of Python's "help" function?

Try

help(id)

at your interactive prompt and see what happens.


No i had no idea thagt was a bult-in help() function.
So id() is actually the memory address of an object which uniquely 
identifies it.



--
What is now proved was at first only imagined!
--
http://mail.python.org/mailman/listinfo/python-list

Re: A certainl part of an if() structure never gets executed.

[Steven D'Aprano]

On Sun, 16 Jun 2013 09:22:20 +, Denis McMahon wrote:

>>> Python:
>>>
>>> b = 6
>>> a = b
>>>
>>> In Python, this first puts the value 6 in in a memory location and
>>> points "b" at that memory location, then makes "a" point to the same
>>> memory location as "b" points to.

That may be true in some sense for CPython, the reference implementation, 
but it is not a promise of the language. For example, in PyPy objects are 
free to move around in memory, so you cannot meaningfully speak of 
"putting 6 in a memory location" or having a variable "point to the same 
memory location".

The language promise is that the two names, "a" and "b", both refer to 
the same object. In the same way that, depending on who you ask, "Barack 
Obama", "Mr President", and "Dad" are three names referring to the same 
person. Anything more than that depends on the implementation.


[...]
> For example, in Python
> 
> a = 6
> b = a
> c = 6
> 
> a and b point to one memory location that contains the value 6 c points
> to a different memory location that contains the value 6

Well, maybe it does, maybe it doesn't. This is one area where the 
language does not specify the underlying behaviour. Because ints are 
unchangeable, immutable objects, the implementation is free to cache and 
reuse them if it wants. CPython caches small integers, but not floats. 
Other implementations may cache fewer, or more, immutable objects.

One thing which no Python implementation can do though is re-use 
*mutable* objects.


[...]
> These are really C terms, not Python terms. Stop thinking that C is
> behaving like Python.

This is certainly true!


-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Compiling vs interpreting [was Re: A certainl part of an if() structure never gets executed.]

[Steven D'Aprano]

On Sun, 16 Jun 2013 10:51:31 +, Denis McMahon wrote:

> On Sun, 16 Jun 2013 12:59:00 +0300, Nick the Gr33k wrote:
> 
>> Whats the difference of "interpreting " to "compiling" ?
> 
> OK, I give up!

Actually, that's a more subtle question than most people think. Python, 
for example, is a compiled language. (What did you think the "c" in 
".pyc" files stood for? and the compile() function>?) It is compiled to 
byte-code, which runs on a virtual machine, rather than machine-code, 
which runs on a physical machine. Except PyPy, which *is* compiled to 
machine-code. Except that it doesn't do so at compile time, but on the 
fly at run-time.

And these days, for many types of hardware, even machine-code is often 
interpreted by a virtual machine on a chip. And even languages which 
compile to machine-code often use an intermediate platform-independent 
form rather than targeting pure machine-code. The line between compilers 
and interpreters is quite fuzzy.

Probably the best definition I've seen for the difference between a 
modern compiler and interpreter is this one:

"...the distinguishing feature of interpreted languages is not that they 
are not compiled, but that the compiler is part of the language runtime 
and that, therefore, it is possible (and easy) to execute code generated 
on the fly."
-- Roberto Ierusalimschy, "Programming In Lua", 2nd Edition, p. 63



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: A certainl part of an if() structure never gets executed.

[YBM]

Le 16.06.2013 13:06, Ferrous Cranus a écrit :

what id() does, never heard of that function before.


just type help(id) at Python prompt and stop flooding the group with
superfluous demands.



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

Re: A certainl part of an if() structure never gets executed.

[R. Michael Weylandt]

On Sun, Jun 16, 2013 at 12:06 PM, Ferrous Cranus  wrote:

I appreciate you've returned to your Ferrous Cranus persona for this
interchange. It reminds me not to get hung up on concerns of
futility...

> On 16/6/2013 1:42 μμ, R. Michael Weylandt wrote:
>>>
>>
>> ## CODE SNIPPET##
>> a = 552315251254
>> b = a
>> c =  552315251254
>>
>> a is b # True _on my machine_
>
>
> I accept this if in the premise that, b boils down to actually point to a's
> value, but it has to go through a first to find it, not directly.

You don't get to "accept it on a premise" or not. It's simply a matter of fact.

In fact, b does not go "through" a. The memory address referenced
exists even if the "a" binding is removed using "del a" or some other
mechanism. Imagine this scenario:

[a]
\
 6
   /
[b]

Using the name "a" or "b" simply tells Python where to look for a
value, but the value itself is not associated with "a" or "b" and will
only be removed if both a and b are del'd.

If we remove "a" while keeping "b" alive, we still have a means of
getting to "6" so Python's GC / RefCounter won't remove it. This
implies that the memory can't be solely "owned" by "a".

[a] # Binding gone now or perhaps referring to something else

 6
/
[b]

And this pattern continues for any sort of Python object.

>
>> a is c # False _on my machine_
>
>
> Why false?  These are 2 different memory locations storing the same number.
> This should have been True.

Again, you have the idea that you can use words like "should" here. It
either is or isn't. There's simply no normative claim involved.

>
> what id() does, never heard of that function before.
>

It seems you've also never heard of Python's "help" function?

Try

help(id)

at your interactive prompt and see what happens.

>
> --
> What is now proved was at first only imagined!

Depth of stubbornness?
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: A certainl part of an if() structure never gets executed.

[Mark Lawrence]

On 16/06/2013 12:06, Ferrous Cranus wrote:



what id() does, never heard of that function before.



what google does, never heard of that function before.

--
"Steve is going for the pink ball - and for those of you who are 
watching in black and white, the pink is next to the green." Snooker 
commentator 'Whispering' Ted Lowe.


Mark Lawrence

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

Re: A certainl part of an if() structure never gets executed.

[Jussi Piitulainen]

Nick the Gr33k writes:
> On 16/6/2013 12:22 μμ, Denis McMahon wrote:
> > For example, in Python
> >
> > a = 6
> > b = a
> > c = 6
> >
> > a and b point to one memory location that contains the value 6
> > c points to a different memory location that contains the value 6
> 
> I believe you are mistaken.
> 
> a here is not a pointer but variable,
> which is a memory location that stores value 6.
> 
> b here is a pointer. It's value is the memory location of variable a
> which stores value 6.
> 
> c here is just te same as a , a variable.

b is also just like a.

All the talk about pointers and memory locations is intended to
explain how things do or do not change. (Or, sometimes, how the
behaviour is implemented.)

If, instead of the above, you have

a = 6
b = a
b = 5

you will find that b == 5 and a == 6. So b is not the same as a. Else
one would have changed when the other changed. I would say that a and
b are different variables. They had the same value, briefly.

What does same mean? Think of mutable objects. A dictionary, for
example:

a = dict(x = 3)
b = a
b.update(x = 31)

You will find that the value of a changed when the value of b changed.
It's the same value. Values do not get copied in Python when you pass
them around. This is implemented with pointers and memory locations,
but in Python these implementation details are normally hidden behind
the scenes.

Python is far from unique in this regard.
-- 
http://mail.python.org/mailman/listinfo/python-list

OT: C vs Python terminology (was: A certainl part of an if() structure never gets executed)

[Andreas Perstinger]

On 16.06.2013 08:32, Denis McMahon wrote:

C:

int a, b;
b = 6;
a = b;

In C, this places the numeric value 6 into the memory location identified
by the variable "b",


so far so good.


then copies the value from the location pointed to by "b" into the
location pointed to by "a".


Wrong. Neither "a" nor "b" are pointers, thus they don't point to a 
memory location.

This part should be written as
"then copies the value at the location identified by "b" to the location 
identified by "a".



b is a pointer to a memory location containing the value 6

> a is a pointer to another memory location also containing the value 6

Again, neither "a" nor "b" are pointers.
"b" is the name of a memory location containing the integer value 6.
"a" is the name of another memory location containing the integer value 6.


Python:

b = 6
a = b

In Python, this first puts the value 6 in in a memory location and points
"b" at that memory location, then makes "a" point to the same memory
location as "b" points to.

b is a pointer to a memory location containing the value 6
a is a pointer to the same memory location


I wouldn't use the term "pointer" in context with Python. Using the 
terms from the language reference I would write that as
"In Python, this first creates an integer object with value 6 and then 
binds the name "b" to it. Then it binds the name "a" to the same object.
Thus both "a" and "b" reference the same object, i.e. they are different 
names for the same object."


Bye, Andreas
--
http://mail.python.org/mailman/listinfo/python-list

Re: A certainl part of an if() structure never gets executed.

[Ferrous Cranus]

On 16/6/2013 1:42 μμ, R. Michael Weylandt wrote:


I believe you are mistaken.

a here is not a pointer but variable,
which is a memory location that stores value 6.

b here is a pointer. It's value is the memory location of variable a which
stores value 6.

c here is just te same as a , a variable.

Actually, y'all both might be. This is a bit CPython specific and not
mandated by the language specification.

To Nikos: please don't extrapolate from the examples below. They are a
CPython (the most common implementation of the Python language)
specific detail.

## CODE SNIPPET##
a = 6; b = a; c = 6

id(a)
id(b)
id(c)
## END CODE##

These are all the same, indicating that they all point to the "same 6"
in memory. That's a CPython specific optimization (caching small
integers) which is not guaranteed by the language and changes between
pythons and between compiles.

For example,

## CODE SNIPPET##
a = 552315251254
b = a
c =  552315251254

a is b # True _on my machine_


I accept this if in the premise that, b boils down to actually point to 
a's value, but it has to go through a first to find it, not directly.



a is c # False _on my machine_


Why false?  These are 2 different memory locations storing the same number.
This should have been True.

Looks very weird.

a = memory location storing a value
b = memory location storing a's memory location
c = memory location storing a value, the same value as a


id(a)
id(b)
id(c)
## END CODE##

Note that to compare if two names point to the same "object, you can
use the "is" operator.

a is b
c is a

etc.


what id() does, never heard of that function before.



--
What is now proved was at first only imagined!
--
http://mail.python.org/mailman/listinfo/python-list

Re: A certainl part of an if() structure never gets executed.

[Denis McMahon]

On Sun, 16 Jun 2013 12:59:00 +0300, Nick the Gr33k wrote:

> Whats the difference of "interpreting " to "compiling" ?

OK, I give up!

-- 
Denis McMahon, denismfmcma...@gmail.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: A certainl part of an if() structure never gets executed.

[Mark Lawrence]

On 16/06/2013 11:42, R. Michael Weylandt wrote:




Whats the difference of "interpreting " to "compiling" ?


If only it could be googled Alas, no one has ever written anything
about technology on the internet. Ironic that...

Michael



I'm very sorry but I don't understand the words "googled" and 
"internet".  Could you please explain them?


--
"Steve is going for the pink ball - and for those of you who are 
watching in black and white, the pink is next to the green." Snooker 
commentator 'Whispering' Ted Lowe.


Mark Lawrence

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

Re: A certainl part of an if() structure never gets executed.

[R. Michael Weylandt]

On Sun, Jun 16, 2013 at 10:59 AM, Nick the Gr33k  wrote:
> On 16/6/2013 12:22 μμ, Denis McMahon wrote:
>>
>> For example, in Python
>>
>> a = 6
>> b = a
>> c = 6
>>
>> a and b point to one memory location that contains the value 6
>> c points to a different memory location that contains the value 6
>
>
> I believe you are mistaken.
>
> a here is not a pointer but variable,
> which is a memory location that stores value 6.
>
> b here is a pointer. It's value is the memory location of variable a which
> stores value 6.
>
> c here is just te same as a , a variable.

Actually, y'all both might be. This is a bit CPython specific and not
mandated by the language specification.

To Nikos: please don't extrapolate from the examples below. They are a
CPython (the most common implementation of the Python language)
specific detail.

## CODE SNIPPET##
a = 6; b = a; c = 6

id(a)
id(b)
id(c)
## END CODE##

These are all the same, indicating that they all point to the "same 6"
in memory. That's a CPython specific optimization (caching small
integers) which is not guaranteed by the language and changes between
pythons and between compiles.

For example,

## CODE SNIPPET##
a = 552315251254
b = a
c =  552315251254

a is b # True _on my machine_
a is c # False _on my machine_

id(a)
id(b)
id(c)
## END CODE##

Note that to compare if two names point to the same "object, you can
use the "is" operator.

a is b
c is a

etc.

>
>>> A pointer = a variable that has as a value a memory address a variable =
>>> a memory address that has as a value the actual value we want to store.
>>
>>
>> These are really C terms, not Python terms. Stop thinking that C is
>> behaving like Python.
>
>
>
> I think it behaves the same way, but lets here from someone else too.

I understand the Greeks invented democracy and all that, but facts
aren't subject to it.

>
> Whats the difference of "interpreting " to "compiling" ?

If only it could be googled Alas, no one has ever written anything
about technology on the internet. Ironic that...

Michael
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: A certainl part of an if() structure never gets executed.

[Nick the Gr33k]

On 16/6/2013 12:22 μμ, Denis McMahon wrote:

On Sun, 16 Jun 2013 11:07:12 +0300, Nick the Gr33k wrote:


On 16/6/2013 9:32 πμ, Denis McMahon wrote:

On Sat, 15 Jun 2013 19:18:53 +0300, Nick the Gr33k wrote:


In both situations we still have 2 memory units holding values, so
hows that different?


Consider that each named variable is a pointer to a memory location
that holds a value. This is one of the ways in that a typed compiled
language and an untyped scripted language may differ in their treatment
of data items (or variables).

Consider the following C and Python code:

C:

int a, b;
b = 6;
a = b;

In C, this places the numeric value 6 into the memory location
identified by the variable "b", then copies the value from the location
pointed to by "b" into the location pointed to by "a".

b is a pointer to a memory location containing the value 6 a is a
pointer to another memory location also containing the value 6

Python:

b = 6
a = b

In Python, this first puts the value 6 in in a memory location and
points "b" at that memory location, then makes "a" point to the same
memory location as "b" points to.

b is a pointer to a memory location containing the value 6 a is a
pointer to the same memory location

Do you understand the difference?


Yes and thank you for explaining in detail to me.
So Python economies(saves) system's memory. Good job Python!


No. Don't read that into it.

For example, in Python

a = 6
b = a
c = 6

a and b point to one memory location that contains the value 6
c points to a different memory location that contains the value 6


I believe you are mistaken.

a here is not a pointer but variable,
which is a memory location that stores value 6.

b here is a pointer. It's value is the memory location of variable a 
which stores value 6.


c here is just te same as a , a variable.


A pointer = a variable that has as a value a memory address a variable =
a memory address that has as a value the actual value we want to store.


These are really C terms, not Python terms. Stop thinking that C is
behaving like Python.



I think it behaves the same way, but lets here from someone else too.


Is this how the thing works?


No.

Python is an interpreted language. C is a compiled language. They present
very different feature sets to the user. You need to understand this, and
at the moment you're not doing so.


Whats the difference of "interpreting " to "compiling" ?

I have also asked other things too which you didn't quote, please do.

--
What is now proved was at first only imagined!
--
http://mail.python.org/mailman/listinfo/python-list

Re: A certainl part of an if() structure never gets executed.

[Denis McMahon]

On Sun, 16 Jun 2013 11:07:12 +0300, Nick the Gr33k wrote:

> On 16/6/2013 9:32 πμ, Denis McMahon wrote:
>> On Sat, 15 Jun 2013 19:18:53 +0300, Nick the Gr33k wrote:
>>
>>> In both situations we still have 2 memory units holding values, so
>>> hows that different?
>>
>> Consider that each named variable is a pointer to a memory location
>> that holds a value. This is one of the ways in that a typed compiled
>> language and an untyped scripted language may differ in their treatment
>> of data items (or variables).
>>
>> Consider the following C and Python code:
>>
>> C:
>>
>> int a, b;
>> b = 6;
>> a = b;
>>
>> In C, this places the numeric value 6 into the memory location
>> identified by the variable "b", then copies the value from the location
>> pointed to by "b" into the location pointed to by "a".
>>
>> b is a pointer to a memory location containing the value 6 a is a
>> pointer to another memory location also containing the value 6
>>
>> Python:
>>
>> b = 6
>> a = b
>>
>> In Python, this first puts the value 6 in in a memory location and
>> points "b" at that memory location, then makes "a" point to the same
>> memory location as "b" points to.
>>
>> b is a pointer to a memory location containing the value 6 a is a
>> pointer to the same memory location
>>
>> Do you understand the difference?
>>
> Yes and thank you for explaining in detail to me.
> So Python economies(saves) system's memory. Good job Python!

No. Don't read that into it.

For example, in Python

a = 6
b = a
c = 6

a and b point to one memory location that contains the value 6
c points to a different memory location that contains the value 6

Python doesn't point all the variables that have the same value at the 
same location.

> A pointer = a variable that has as a value a memory address a variable =
> a memory address that has as a value the actual value we want to store.

These are really C terms, not Python terms. Stop thinking that C is 
behaving like Python.

> Is this how the thing works?

No.

Python is an interpreted language. C is a compiled language. They present 
very different feature sets to the user. You need to understand this, and 
at the moment you're not doing so.

-- 
Denis McMahon, denismfmcma...@gmail.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: A certainl part of an if() structure never gets executed.

[Nick the Gr33k]

On 16/6/2013 4:55 πμ, Tim Roberts wrote:

Nick the Gr33k  wrote:
Because Python lets you use arbitrary values in a Boolean context, the net
result is exactly the same.


What is an arbitrary value? don even knwo what arbitrary means literally 
in English.



In a long series separated by "or", the expression is true as soon as one
of the subexpressions is true.  So, as a short-circuit, Python simply
returns the first one that has a "true" value.  So, for example, these all
return 'abcd':

 'abcd' or 'defg' or 'hjkl'   ==> 'abcd'
 0 or 'abcd' or 'defg' or 'hjkl'  ==> 'abcd'
 0 or None or 'abcd' or 'defg' or 'hjkl'  ==> 'abcd'

Similarly, "and" returns the first "false" value, or if they're all true,
the last value.  Why?  Because it can't know whether the whole expression
is true unless it looks at every value.  So:

 0 and 1 and 'what'   ==>  0
 1 and 0 and 'what'   ==>  0
 1 and None and 0 ==>  None
 1 and 1 and 'what'   ==> 'what'


Thank you Tim.

I decided that it's better to thing it through as:

The argument being returned in an "and" or "or" expression is the one 
that *determined' the evaluation of the expression.


And actually what's being returned is not the argument itself but the 
argument's value.


--
What is now proved was at first only imagined!
--
http://mail.python.org/mailman/listinfo/python-list

Re: A certainl part of an if() structure never gets executed.

[Nick the Gr33k]

On 16/6/2013 9:32 πμ, Denis McMahon wrote:

On Sat, 15 Jun 2013 19:18:53 +0300, Nick the Gr33k wrote:


In both situations we still have 2 memory units holding values, so hows
that different?


Consider that each named variable is a pointer to a memory location that
holds a value. This is one of the ways in that a typed compiled language
and an untyped scripted language may differ in their treatment of data
items (or variables).

Consider the following C and Python code:

C:

int a, b;
b = 6;
a = b;

In C, this places the numeric value 6 into the memory location identified
by the variable "b", then copies the value from the location pointed to
by "b" into the location pointed to by "a".

b is a pointer to a memory location containing the value 6
a is a pointer to another memory location also containing the value 6

Python:

b = 6
a = b

In Python, this first puts the value 6 in in a memory location and points
"b" at that memory location, then makes "a" point to the same memory
location as "b" points to.

b is a pointer to a memory location containing the value 6
a is a pointer to the same memory location

Do you understand the difference?


Yes and thank you for explaining in detail to me.
So Python economies(saves) system's memory. Good job Python!

There is no point having 2 variables point to 2 different memory 
locations as C does since both of those memory locations are supposed to 
contain the same value!


One thing that i want you guys to confirm to me:

a and b in both of the languages mentioned are pointers to memory 
locations which hold a value.


A pointer = a variable that has as a value a memory address
a variable = a memory address that has as a value the actual value we 
want to store.


But since pointer itself is a memory location that holds as a value the 
address of another memory location(by definition) that in it's own turn 
holds the actual value we want stored?


So the scheme would look like this in Python:

memory address = number 6

memory address = memory address value that stores number 6 (pointer a)

memory address = memory address value that stores number 6 (pointer b)


So having in mind the above.

The memory address that actually stores number 6 have no name at all and 
the only way to access it's value is by printing the variables a or b? 
Doesn't that memory address have a name itself?


if someone wants the memory address of the pointer's a or b, how can he 
access it? in C it was somethign like &a and &b


And in Python internally shall i imagine two tables that has 
associations of:


variable's_name <-> memory_address <-> actual value

And ALL 3 of them are actually bits(1s and 0s)

Is this how the thing works?

--
What is now proved was at first only imagined!
--
http://mail.python.org/mailman/listinfo/python-list

Re: A certainl part of an if() structure never gets executed.

[Denis McMahon]

On Sat, 15 Jun 2013 19:18:53 +0300, Nick the Gr33k wrote:

> In both situations we still have 2 memory units holding values, so hows
> that different?

Consider that each named variable is a pointer to a memory location that 
holds a value. This is one of the ways in that a typed compiled language 
and an untyped scripted language may differ in their treatment of data 
items (or variables).

Consider the following C and Python code:

C:

int a, b;
b = 6;
a = b;

In C, this places the numeric value 6 into the memory location identified 
by the variable "b", then copies the value from the location pointed to 
by "b" into the location pointed to by "a".

b is a pointer to a memory location containing the value 6
a is a pointer to another memory location also containing the value 6

Python:

b = 6
a = b

In Python, this first puts the value 6 in in a memory location and points 
"b" at that memory location, then makes "a" point to the same memory 
location as "b" points to.

b is a pointer to a memory location containing the value 6
a is a pointer to the same memory location

Do you understand the difference?

-- 
Denis McMahon, denismfmcma...@gmail.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: A certainl part of an if() structure never gets executed.

[Steven D'Aprano]

On Sat, 15 Jun 2013 18:55:05 -0700, Tim Roberts wrote:

> Nick the Gr33k  wrote:
>>
>>but i'm doing this all day long i just dont comprehend why it works this
>>way. it doesn't make any sense to me.
> 
> It's just a rule you'll have to learn.  The "and" and "or" operators in
> Python simply do not return a boolean value.  The expression "a or b" is
> evaluated as:
> if a is true then return a otherwise return b

I prefer to say that as 

"if a is true-ish then return a otherwise return b"

or even

"if a quacks like a true value then return a otherwise return b"


to emphasis that this is a form of duck-typing, and avoid any confusion 
with "if a is True".


But otherwise, well said.



-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: A certainl part of an if() structure never gets executed.

[Tim Roberts]

Nick the Gr33k  wrote:
>
>but i'm doing this all day long i just dont comprehend why it works this 
>way.
>it doesn't make any sense to me.

It's just a rule you'll have to learn.  The "and" and "or" operators in
Python simply do not return a boolean value.  The expression "a or b" is
evaluated as:
if a is true then return a otherwise return b

It's true that in many languages, "or" returns a Boolean value, so the
result is:
if a is true then return True otherwise return bool(b)

Because Python lets you use arbitrary values in a Boolean context, the net
result is exactly the same.  However, the Python is a lot more flexible,
because it lets you simulate the C ternary ?: operator.

Similarly, "a and b" is evaluated as:
if a is false then return a otherwise return b

In a long series separated by "or", the expression is true as soon as one
of the subexpressions is true.  So, as a short-circuit, Python simply
returns the first one that has a "true" value.  So, for example, these all
return 'abcd':

'abcd' or 'defg' or 'hjkl'   ==> 'abcd'
0 or 'abcd' or 'defg' or 'hjkl'  ==> 'abcd'
0 or None or 'abcd' or 'defg' or 'hjkl'  ==> 'abcd'

Similarly, "and" returns the first "false" value, or if they're all true,
the last value.  Why?  Because it can't know whether the whole expression
is true unless it looks at every value.  So:

0 and 1 and 'what'   ==>  0
1 and 0 and 'what'   ==>  0
1 and None and 0 ==>  None
1 and 1 and 'what'   ==> 'what'
-- 
Tim Roberts, t...@probo.com
Providenza & Boekelheide, Inc.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: A certainl part of an if() structure never gets executed.

[Michael Torrie]

On 06/15/2013 10:18 AM, Nick the Gr33k wrote:
> a and b you say are names, which still are memory chunks

Yes no matter how you look at it, a dictionary of names and objects is
memory and "variables" in that sense.  But at a higher level, we can
consider the differences with how a language like C defines variables.

> In both situations we still have 2 memory units holding values, so hows 
> that different?

Perhaps one could think of python names as more like pointers or
references in C. But python references are counted and garbage-collected
(more like a C++ reference-counting pointer type).

For example, a = 4 makes the name "a" be a reference to the object
int(4), which will never ever change in its lifetime (indeed it wouldn't
make sense for the integer 4 to change otherwise it wouldn't be a 4).
Thus a = a + 1 creates a new object that represents the integer value of
4 + 1, and throws the old object away.

>>> a = 5
>>> id(a)
2857664
>>> a = a + 1
>>> id (a)
2857680
>>>

Note that the identity (object) of a has changed.  If a were a variable
in the same sense as C, the identity of a would not change.

A mutable object like a list acts more like a variable in some ways:
>>> b = []
>>> id(b)
3076765292
>>> b.append(3)
>>> id(b)
3076765292

In many cases the distinction is little more than intellectual for all
intents and purposes, though it some cases the idea is very powerful.

But there a couple of cases where the difference between a variable and
a name referencing an object does bite people in Python:
http://effbot.org/zone/default-values.htm
http://stackoverflow.com/questions/986006/python-how-do-i-pass-a-variable-by-reference
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: A certainl part of an if() structure never gets executed.

[Nick the Gr33k]

On 15/6/2013 6:53 μμ, Michael Torrie wrote:

On 06/15/2013 07:07 AM, Nick the Gr33k wrote:

result = mylist (since its a no-emoty list)


result.append('bar')
result is mylist

True


Never seen the last statement before. What does that mean?
result is mylist 


Yes.  Surprisingling good question.

http://docs.python.org/3.3/reference/expressions.html#is
http://docs.python.org/3/reference/datamodel.html

One thing that you may find interesting is that what we often call
variables in Python, and which from your code's point of view look and
act like variables are in fact names.  Whereas in C, assignment can be
thought of as copy (a = b in C means that b's value is copied to a), in
Python assignment is associating a name with an object.  Thus a = b in
Python means that now the names a and b both are bound (reference to)
the same object.  That's why the "is" operator is there, to help one
know if two names point to the same object.

I bring this up on the list from time to time because I find it really
interesting and intellectually appealing the way Python works.  Hearkens
back to my class at uni on programming language theory.




(a = b in C means that b's value is copied to a)

in C:

a = memory chunk able to hold some specific type's value
b = memory chunk able to hold some specific type's value

a = b means

So we have 2 memory units hod, the same value.

in Python:

a and b you say are names, which still are memory chunks

In both situations we still have 2 memory units holding values, so hows 
that different?


--
What is now proved was at first only imagined!
--
http://mail.python.org/mailman/listinfo/python-list

Re: A certainl part of an if() structure never gets executed.

[Michael Torrie]

On 06/15/2013 07:07 AM, Nick the Gr33k wrote:
> result = mylist (since its a no-emoty list)
> 
> result.append('bar')
> result is mylist
>> True
> 
> Never seen the last statement before. What does that mean?
> result is mylist 

Yes.  Surprisingling good question.

http://docs.python.org/3.3/reference/expressions.html#is
http://docs.python.org/3/reference/datamodel.html

One thing that you may find interesting is that what we often call
variables in Python, and which from your code's point of view look and
act like variables are in fact names.  Whereas in C, assignment can be
thought of as copy (a = b in C means that b's value is copied to a), in
Python assignment is associating a name with an object.  Thus a = b in
Python means that now the names a and b both are bound (reference to)
the same object.  That's why the "is" operator is there, to help one
know if two names point to the same object.

I bring this up on the list from time to time because I find it really
interesting and intellectually appealing the way Python works.  Hearkens
back to my class at uni on programming language theory.


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

Re: A certainl part of an if() structure never gets executed.

[Nick the Gr33k]

On 15/6/2013 12:54 μμ, Lele Gaifax wrote:

Nick the Gr33k  writes:


On 15/6/2013 8:27 πμ, Larry Hudson wrote:

Also they do NOT return "a variable's truthy value", they return the
variable itself.


No, as seen from my above examples, what is returned after the expr
eval are the actual variables' values, which in turn are truthy, *not*
the variable itself.


In the context we are talking about, "the variable itself" has the very
same meaning as "the actual variable value":


Are there cases that a variable and the variable's value cosidered to be 
2 different things?



mylist = ['foo']
emptylist = []
result = emptylist or mylist


result = mylist (since its a no-emoty list)


result.append('bar')
result is mylist

True


Never seen the last statement before. What does that mean?
result is mylist 


--
What is now proved was at first only imagined!
--
http://mail.python.org/mailman/listinfo/python-list

Re: A certainl part of an if() structure never gets executed.

[Lele Gaifax]

Nick the Gr33k  writes:

> On 15/6/2013 8:27 πμ, Larry Hudson wrote:
>> Also they do NOT return "a variable's truthy value", they return the
>> variable itself.
>
> No, as seen from my above examples, what is returned after the expr
> eval are the actual variables' values, which in turn are truthy, *not*
> the variable itself.

In the context we are talking about, "the variable itself" has the very
same meaning as "the actual variable value":

>>> mylist = ['foo']
>>> emptylist = []
>>> result = emptylist or mylist
>>> result.append('bar')
>>> result is mylist
True
>>> print(mylist)
['foo', 'bar']

ciao, lele.
-- 
nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri
real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia.
l...@metapensiero.it  | -- Fortunato Depero, 1929.

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

Re: A certainl part of an if() structure never gets executed.

[Nick the Gr33k]

On 15/6/2013 8:27 πμ, Larry Hudson wrote:

On 06/14/2013 09:56 AM, Nick the Gr33k wrote:

On 14/6/2013 7:31 μμ, Steven D'Aprano wrote:

On Fri, 14 Jun 2013 16:07:56 +0300, Nick the Gr33k wrote:





Returning True is the same thing as returning a variable's truthy value?


NO!  'True' and 'False' are the two values of the boolean type.  The
'and' and 'or' logical operators do NOT return a boolean type of True or
False.


Indeed.

>>> print( name and month and year )
hijk
>>> print( bool( name and month and year ) )
True

>>> print( name or month or year )
abcd
print( bool( name or month or year ) )
True


Also they do NOT return "a variable's truthy value", they return the
variable itself.


No, as seen from my above examples, what is returned after the expr eval 
are the actual variables' values, which in turn are truthy, *not* the 
variable itself.



Now, that returned variable can then be interpreted as
a boolean value for other operations in the same way that (virtually)
all data types can be interpreted as a boolean.  Let me emphasize...
they are INTERPRETED as having a boolean VALUE, but they are NOT a
boolean TYPE.


Yes the returned value of 'hijk' is being interpreted as bool('hijk'), 
which boils down as truthy.




--
What is now proved was at first only imagined!
--
http://mail.python.org/mailman/listinfo/python-list

Re: A certainl part of an if() structure never gets executed.

[Larry Hudson]

On 06/14/2013 09:56 AM, Nick the Gr33k wrote:

On 14/6/2013 7:31 μμ, Steven D'Aprano wrote:

On Fri, 14 Jun 2013 16:07:56 +0300, Nick the Gr33k wrote:





Returning True is the same thing as returning a variable's truthy value?

NO!  'True' and 'False' are the two values of the boolean type.  The 'and' and 'or' logical 
operators do NOT return a boolean type of True or False.  (Although, the 'not' DOES return a 
boolean.)


Also they do NOT return "a variable's truthy value", they return the variable itself.  Now, that 
returned variable can then be interpreted as a boolean value for other operations in the same 
way that (virtually) all data types can be interpreted as a boolean.  Let me emphasize... they 
are INTERPRETED as having a boolean VALUE, but they are NOT a boolean TYPE.




 >>> (a and b and c)
'ijkl'

This in my head should have been evaluated to True also since all 3 strings 
hold truthy values

You need to get it into your thick head that you are mistaken, like everyone is trying to tell 
you.  What YOU think about it is WRONG!  Throw that thinking away and start LISTENING to what 
you are being told are the facts.



Why on earth this boolean expression evaluates to the value of the last 
variable? This is what
can't at all seem to follow.

BECAUSE THAT IS THE WAY PYTHON IS DEFINED, whether or not you agree with it.  You are WRONG!  It 
is time for you to accept the fact that you are mistaken and start trying to learn how Python IS 
defined -- NOT how YOU think it should be defined.




What i'm trying to say that both these exprs are Boolean Expressions therefore 
should return
Boolean values not variable's values, even if they are truthy.

I repeat:  what YOU think Python should do is completely irrelevant.  If you keep insisting on 
trying to use Python they way you THINK it should work instead of the way it is DEFINED to work, 
you'll lose that argument every time.


The whys of how Python works is, frankly, not important -- interesting and useful perhaps, but 
essentially irrelevant.  Just keep writing Python in the way it is defined, and learning the 
whys will come along.



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

Re: A certainl part of an if() structure never gets executed.

[Jussi Piitulainen]

Nick the Gr33k writes:

>  >>> (a or b or c)
> 'abcd'
> 
> This for me, should evaluate to True but instead it has been
> evaluated to the first variable's value, which is a truthy value of
> course since its not an empty string, but shouldn't it return True
> instead?

In your own programs, write bool(a or b or c) instead. And instead of
writing (k in (a or b or c)), write ((k in a) or (k in b) or (k in c))
-- you can use fewer parentheses if you like, but only if you are
comfortable with it. (Here, I use the outer parentheses to separate
Python from English. I might not use them in code.)

Usually such expressions occur as conditions in conditional statements
or conditional expressions. There, the bool() makes no observable
difference.

> Returning True is the same thing as returning a variable's truthy
> value?

I think that's a good approximation. Strictly speaking, True is a
particular value in Python, but I think that at the moment you need to
understand that what is important is how the value is interpreted as a
condition in a conditional statement (if condition:, elif: condition),
a conditional expression (x if condition else y), a while loop (while
condition:).

   >>> while "ijkl": print("it doesn't matter")
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: A certainl part of an if() structure never gets executed.

[Chris Angelico]

On Sat, Jun 15, 2013 at 2:56 AM, Nick the Gr33k  wrote:
> What i'm trying to say that both these exprs are Boolean Expressions
> therefore should return Boolean values not variable's values, even if they
> are truthy.

Okay, now we get to the nub of the matter.

In some languages, what you say is the case. In C, for instance, 3 ||
4 == 1 (C doesn't have dedicated True and False types, it uses 1 and
0). But there are very few situations where you actually need it to
specifically be the boolean values, and plenty where you can make use
of this additional feature. If you want to demand a bool from Python,
there is a way to do this. Experiment with bool() in the interactive
interpreter.

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

Re: A certainl part of an if() structure never gets executed.

[Nick the Gr33k]

On 14/6/2013 7:31 μμ, Steven D'Aprano wrote:

On Fri, 14 Jun 2013 16:07:56 +0300, Nick the Gr33k wrote:


Thanks for explaining this but i cannot follow its logic at all. My mind
is stuck trying to interpret it as an English sentence:

if ('Parker' and 'May' and '2001')

if ('Parker' or 'May' or '2001')

i just don't get it and i feel silly about it.


Python is not English. You just have to accept that, no matter how much
you wish it worked like English, it does not.

Think of it like this:

"If today is Tuesday AND I finish work early, then I can go to the
movies."

Unless *both* conditions are true, I cannot go to the movies.


"If today is Tuesday AND I finish work early AND I have more than $16
spare cash to pay for a ticket, then I can go to the movies."

All three conditions must be true, or I cannot go to the movies.


If today is Monday, I don't need to check whether I finish work early, or
whether I have spare cash. It is enough to know that today is not
Tuesday, so I'm not going to the movies.


Python works the same way:

today_is_tuesday = True
finish_work_early = True
spare_cash = 11


if today_is_tuesday and finish_work_early and spare_cash > 16:
 print("Going to the movies")
else:
 print("No movies today.")

It will print the latter since the overall boolean evaluation of the 
expression is False since (spare_cash > 16) = False


That's understandable and works just like an English sentence, but in 
this example it was easy since you assigned the vars values to be either 
True or False.


This is my difficulty.

a = 'abcd'
b = 'efgh'
c = 'ijkl'


>>> (a or b or c)
'abcd'

This for me, should evaluate to True but instead it has been evaluated 
to the first variable's value, which is a truthy value of course since 
its not an empty string, but shouldn't it return True instead?


Returning True is the same thing as returning a variable's truthy value?


>>> (a and b and c)
'ijkl'

This in my head should have been evaluated to True also since all 3 
strings hold truthy values


Why on earth this boolean expression evaluates to the value of the last 
variable? This is what can't at all seem to follow.



What i'm trying to say that both these exprs are Boolean Expressions 
therefore should return Boolean values not variable's values, even if 
they are truthy.





--
What is now proved was at first only imagined!
--
http://mail.python.org/mailman/listinfo/python-list

Re: A certainl part of an if() structure never gets executed.

[Steven D'Aprano]

On Fri, 14 Jun 2013 16:07:56 +0300, Nick the Gr33k wrote:

> Thanks for explaining this but i cannot follow its logic at all. My mind
> is stuck trying to interpret it as an English sentence:
> 
> if ('Parker' and 'May' and '2001')
> 
> if ('Parker' or 'May' or '2001')
> 
> i just don't get it and i feel silly about it.

Python is not English. You just have to accept that, no matter how much 
you wish it worked like English, it does not.

Think of it like this:

"If today is Tuesday AND I finish work early, then I can go to the 
movies."

Unless *both* conditions are true, I cannot go to the movies.


"If today is Tuesday AND I finish work early AND I have more than $16 
spare cash to pay for a ticket, then I can go to the movies."

All three conditions must be true, or I cannot go to the movies.


If today is Monday, I don't need to check whether I finish work early, or 
whether I have spare cash. It is enough to know that today is not 
Tuesday, so I'm not going to the movies.


Python works the same way:

today_is_tuesday = True
finish_work_early = True
spare_cash = 11


if today_is_tuesday and finish_work_early and spare_cash > 16:
print("Going to the movies")
else:
print("No movies today.")




-- 
Steven
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: A certainl part of an if() structure never gets executed.

[Grant Edwards]

On 2013-06-14, Nick the Gr33k  wrote:

> Well i do not understand it.

Yea.  We know.

-- 
Grant Edwards   grant.b.edwardsYow! I feel like a wet
  at   parking meter on Darvon!
  gmail.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: A certainl part of an if() structure never gets executed.

[Nick the Gr33k]

On 14/6/2013 4:48 μμ, Zero Piraeus wrote:

:

On 14 June 2013 09:07, Nick the Gr33k  wrote:


Thanks for explaining this but i cannot follow its logic at all.
My mind is stuck trying to interpret it as an English sentence:

if ('Parker' and 'May' and '2001')

if ('Parker' or 'May' or '2001')

i just don't get it and i feel silly about it.


You've been advised many times to experiment in the Python
interpreter. I may be mistaken, but I don't recall seeing any evidence
at all that you've ever done so.

Try the following in a Python interpreter:


"vic" and "bob"
"bob" and "vic"
"vic" or "bob"
"bob" or "vic"
"vic" and ""
"" and "bob"
"bob" or ""
"" or "vic"


Carefully study the results you get. This is simple, basic stuff;
don't come back here asking for explanations of it. If you get stuck,
*carefully* read this article:

   http://en.wikipedia.org/wiki/Short-circuit_evaluation

Repeat the steps above until you do understand. If all else fails,
google "short circuit logic" or "short circuit evaluation python" or
similar search terms, until you find a resource which you do follow.

  -[]z.


(a or b or c)

is like saying True or True or True.
the first of these 3 variables that hasn;t as value an emptry string, 
which means they contain a truthy value, that variable's value will be 
returned


For 'and' operator, i do not understand it at all.

--
What is now proved was at first only imagined!
--
http://mail.python.org/mailman/listinfo/python-list

Re: A certainl part of an if() structure never gets executed.

[rusi]

On Jun 14, 6:48 pm, Zero Piraeus  wrote:
> :
>
> On 14 June 2013 09:07, Nick the Gr33k  wrote:
>
>
>
> > Thanks for explaining this but i cannot follow its logic at all.
> > My mind is stuck trying to interpret it as an English sentence:
>
> > if ('Parker' and 'May' and '2001')
>
> > if ('Parker' or 'May' or '2001')
>
> > i just don't get it and i feel silly about it.
>
> You've been advised many times to experiment in the Python
> interpreter. I may be mistaken, but I don't recall seeing any evidence
> at all that you've ever done so.
>
> Try the following in a Python interpreter:
>
> >>> "vic" and "bob"
> >>> "bob" and "vic"
> >>> "vic" or "bob"
> >>> "bob" or "vic"
> >>> "vic" and ""
> >>> "" and "bob"
> >>> "bob" or ""
> >>> "" or "vic"
>
> Carefully study the results you get. This is simple, basic stuff;
> don't come back here asking for explanations of it. If you get stuck,
> *carefully* read this article:
>
>  http://en.wikipedia.org/wiki/Short-circuit_evaluation
>
> Repeat the steps above until you do understand. If all else fails,
> google "short circuit logic" or "short circuit evaluation python" or
> similar search terms, until you find a resource which you do follow.
>
>  -[]z.

You get my prize 'Zero' for best answer!

[You've also given me a nice example for my next python class -- I
usually spend time showing how to play in the interpreter.  And the
examples I usually give are numeric/string/list based. Short-circuit
evaluation is good to show. So thanks]

Incidentally, you have also proved right Nicolas' claim that this is
helpful to all :-)  All that is needed is that other charitable-to-
Nick souls on this list should exercise some restraint and provide the
answers that they *know* he *needs* rather than what he *claims* to
*want*.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: A certainl part of an if() structure never gets executed.

[Zero Piraeus]

:

On 14 June 2013 09:07, Nick the Gr33k  wrote:
>
> Thanks for explaining this but i cannot follow its logic at all.
> My mind is stuck trying to interpret it as an English sentence:
>
> if ('Parker' and 'May' and '2001')
>
> if ('Parker' or 'May' or '2001')
>
> i just don't get it and i feel silly about it.

You've been advised many times to experiment in the Python
interpreter. I may be mistaken, but I don't recall seeing any evidence
at all that you've ever done so.

Try the following in a Python interpreter:

>>> "vic" and "bob"
>>> "bob" and "vic"
>>> "vic" or "bob"
>>> "bob" or "vic"
>>> "vic" and ""
>>> "" and "bob"
>>> "bob" or ""
>>> "" or "vic"

Carefully study the results you get. This is simple, basic stuff;
don't come back here asking for explanations of it. If you get stuck,
*carefully* read this article:

  http://en.wikipedia.org/wiki/Short-circuit_evaluation

Repeat the steps above until you do understand. If all else fails,
google "short circuit logic" or "short circuit evaluation python" or
similar search terms, until you find a resource which you do follow.

 -[]z.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: A certainl part of an if() structure never gets executed.

[Nick the Gr33k]

On 14/6/2013 3:40 μμ, Jussi Piitulainen wrote:

Nick the Gr33k writes:

On 14/6/2013 12:21 μμ, Jussi Piitulainen wrote:

Nick the Gr33k writes:

On 14/6/2013 11:28 πμ, Jussi Piitulainen wrote:


'Parker' and 'May' and '2001'

'2001'


But why?

that expression should return True since all stings are not empty.


It returns a value that counts as true in a conditional statement or
expression:


When a look at ('Parker' and 'May' and '2001') i can't help it but
interpret it as:

Return True if  'Parker' is not an empty string AND 'May' is not an
empty string AND'2001'  is not an empty string.


Nah. That expression would be:

   True if ('Parker' != '' and 'May' != '' and '2001' != '') else False

The one at hand is more like: 'Parker' if 'Parker' does not count as
true, else 'May' if 'May' does not count as true, else '2001' (which
counts as true if it counts as true, else it counts as false ...).


i just don't understand why it returns back the last value instead.


I suppose the value can be useful, and there is generally no harm in
it. But why not adjust your expectations to the reality? You can still
ask why.

This behaviour of the /and/ and /or/ was used to simulate the
conditional expression (_ if _ else _) before the latter was in the
language.


'' and whatever

''


Why does it return th first object back
isn't it like saying False and True and resulting in False?

Please put it in else word how Python unerstand that.


That would be: '' if '' counts as false, else whatever.

And yes, when the first expression determines the value, the second
expression is not evaluated. /or/ is similar.



Thanks for explaining this but i cannot follow its logic at all.
My mind is stuck trying to interpret it as an English sentence:

if ('Parker' and 'May' and '2001')

if ('Parker' or 'May' or '2001')

i just don't get it and i feel silly about it.

--
What is now proved was at first only imagined!
--
http://mail.python.org/mailman/listinfo/python-list

Re: A certainl part of an if() structure never gets executed.

[Jussi Piitulainen]

Nick the Gr33k writes:
> On 14/6/2013 12:21 μμ, Jussi Piitulainen wrote:
> > Nick the Gr33k writes:
> >> On 14/6/2013 11:28 πμ, Jussi Piitulainen wrote:
> >>
> >> 'Parker' and 'May' and '2001'
> >>> '2001'
> >>
> >> But why?
> >>
> >> that expression should return True since all stings are not empty.
> >
> > It returns a value that counts as true in a conditional statement or
> > expression:
> 
> When a look at ('Parker' and 'May' and '2001') i can't help it but
> interpret it as:
> 
> Return True if  'Parker' is not an empty string AND 'May' is not an
> empty string AND'2001'  is not an empty string.

Nah. That expression would be:

  True if ('Parker' != '' and 'May' != '' and '2001' != '') else False

The one at hand is more like: 'Parker' if 'Parker' does not count as
true, else 'May' if 'May' does not count as true, else '2001' (which
counts as true if it counts as true, else it counts as false ...).

> i just don't understand why it returns back the last value instead.

I suppose the value can be useful, and there is generally no harm in
it. But why not adjust your expectations to the reality? You can still
ask why.

This behaviour of the /and/ and /or/ was used to simulate the
conditional expression (_ if _ else _) before the latter was in the
language.

>  '' and whatever
> > ''
> 
> Why does it return th first object back
> isn't it like saying False and True and resulting in False?
> 
> Please put it in else word how Python unerstand that.

That would be: '' if '' counts as false, else whatever.

And yes, when the first expression determines the value, the second
expression is not evaluated. /or/ is similar.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: A certainl part of an if() structure never gets executed.

[Nick the Gr33k]

On 14/6/2013 3:03 μμ, Denis McMahon wrote:

for i, month in enumerate(months):
   if i != 0:
 print(' %s ' % (i, month) )
   else:
 print(' %s ' % ("==", month) )


This s exactly what i was looking for Denis, thank you.

I tough of that myself too, but i had implemented it wrongly as:

for i, month in enumerate(months):
if i == 0:
i = "=="
else:
print(' %s ' % (i, month))


I just cant think simple and clear some times.

Of course as you also said i could have left it as it it is and then 
look for month == 0 in the if condition instead of month == ""



--
What is now proved was at first only imagined!
--
http://mail.python.org/mailman/listinfo/python-list

Re: A certainl part of an if() structure never gets executed.

[Denis McMahon]

On Wed, 12 Jun 2013 11:54:25 +0300, Νικόλαος Κούρας wrote:

> So, i must tell:
> 
> for i, month in enumerate(months):
>  print(' %s ' % (i, month) )
> 
> to somehow return '==' instead of 0 but don't know how.

You could test for (month == 0) instead of re.search('=', month)? 

Or you could try using "==" instead of i when i is 0

for i, month in enumerate(months):
  if i != 0:
print(' %s ' % (i, month) )
  else:
print(' %s ' % ("==", month) )

But if you couldn't work either of these solutions out on your own, 
perhaps the really important question you need to be asking yourself 
right now is "should I even be trying to code this in python when my 
basic knowledge of python coding is so poor?"

-- 
Denis McMahon, denismfmcma...@gmail.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: A certainl part of an if() structure never gets executed.

[Nick the Gr33k]

On 14/6/2013 12:12 μμ, Chris Angelico wrote:

On Fri, Jun 14, 2013 at 7:00 PM, Nick the Gr33k  wrote:

but i really wont to understand how 'or' and 'and' works inside an
expression. please answer my previous post if you know.


*eyeroll*

You have all the information. Go play with it in the interactive
interpreter until you understand. Seriously. That interpreter wants to
be your friend, just extend a hand and say "Hi"! Become familiar with
Python that way. Don't expect everything to be answered on-list.

ChrisA



but i'm doing this all day long i just dont comprehend why it works this 
way.

it doesn't make any sense to me.

--
What is now proved was at first only imagined!
--
http://mail.python.org/mailman/listinfo/python-list

Re: A certainl part of an if() structure never gets executed.

[Nick the Gr33k]

On 14/6/2013 12:21 μμ, Jussi Piitulainen wrote:

Nick the Gr33k writes:


On 14/6/2013 11:28 πμ, Jussi Piitulainen wrote:


'Parker' and 'May' and '2001'

'2001'


But why?

that expression should return True since all stings are not empty.


It returns a value that counts as true in a conditional statement or
expression:


When a look at ('Parker' and 'May' and '2001') i can't help it but 
interpret it as:


Return True if  'Parker' is not an empty string AND 'May' is not an 
empty string AND'2001'  is not an empty string.


Why on eart doesn't work this way?

I can understand that the value it results to '2000' is a truthy value, 
although i was expecting it to result in True if all parts of 
expressions are true.


i just don't understand why it returns back the last value instead.


Zeroes and empty things tend to count as false in Python, other values
as true. The values are tested as is, not coerced to a boolean first,
so the value that decides the value of the whole expression is the
value of the whole expression.


'' and whatever

''


Why does it return th first object back
isn't it like saying False and True and resulting in False?

Please put it in else word how Python unerstand that.

False and whatever

False


Same here? The 2nd part of the expression never is been calculated 
because the 1st is False?

0 and whatever

0


Same here? The 2nd part of the expression never is been calculated 
because the 1st is False?

1 and whatever

Traceback (most recent call last):
   File "", line 1, in ?
NameError: name 'whatever' is not defined




--
What is now proved was at first only imagined!
--
http://mail.python.org/mailman/listinfo/python-list

Re: A certainl part of an if() structure never gets executed.

[Jussi Piitulainen]

Nick the Gr33k writes:

> On 14/6/2013 11:28 πμ, Jussi Piitulainen wrote:
> 
>  'Parker' and 'May' and '2001'
> > '2001'
> 
> But why?
> 
> that expression should return True since all stings are not empty.

It returns a value that counts as true in a conditional statement or
expression:

>>> if '2001': print('got a truish value')
... else: print("didn't")
... 
got a truish value

>>> if '': print('got a truish value')
... else: print("didn't")
... 
didn't

Zeroes and empty things tend to count as false in Python, other values
as true. The values are tested as is, not coerced to a boolean first,
so the value that decides the value of the whole expression is the
value of the whole expression.

>>> '' and whatever
''
>>> False and whatever
False
>>> 0 and whatever
0
>>> 1 and whatever
Traceback (most recent call last):
  File "", line 1, in ?
NameError: name 'whatever' is not defined
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: A certainl part of an if() structure never gets executed.

[Chris Angelico]

On Fri, Jun 14, 2013 at 7:00 PM, Nick the Gr33k  wrote:
> but i really wont to understand how 'or' and 'and' works inside an
> expression. please answer my previous post if you know.

*eyeroll*

You have all the information. Go play with it in the interactive
interpreter until you understand. Seriously. That interpreter wants to
be your friend, just extend a hand and say "Hi"! Become familiar with
Python that way. Don't expect everything to be answered on-list.

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

Re: A certainl part of an if() structure never gets executed.

[Fábio Santos]

On 14 Jun 2013 09:56, "Nick the Gr33k"  wrote:
>
> On 14/6/2013 11:03 πμ, Nick the Gr33k wrote:
>>
>> On 14/6/2013 4:14 πμ, Steven D'Aprano wrote:
>>>
>>> On Thu, 13 Jun 2013 17:26:18 +0300, Νικόλαος Κούρας wrote:
>>>
 i just want 4 cases to examine so correct execute to be run:

 i'm reading and reading and reading this all over:

 if '-' not in ( name and month and year ):

 and i cant comprehend it.
>>>
>>>
>>> Don't just read it. Open the interactive interpreter and test it.
>>>
>>> name = "abcd"
>>> month = "efgh"
>>> year = "ijkl"
>>>
>>> print(name and month and year)
>>>
>>> If you run that, you will see what the result of
>>> (name and month and year) is. Now, ask yourself:
>>>
>>> "k" in (name and month and year)
>>>
>>> True or false? Check your answer:
>>>
>>> print("k" in (name and month and year))
>>
>>
>>
>>  >>> name="abcd"
>>  >>> month="efgh"
>>  >>> year="ijkl"
>>
>>  >>> print(name or month or year)
>> abcd
>>
>> Can understand that, it takes the first string out of the 3 strings that
>> has a truthy value.
>>
>>  >>> print("k" in (name and month and year))
>> True
>>
>> No clue. since the expression in parenthesis returns 'abcd' how can 'k'
>> contained within 'abcd' ?
>>
>>  >>> print(name and month and year)
>> ijkl
>>
>> Seems here is returning the last string out of 3 strings, but have no
>> clue why Python doing this.
>>
>>  >>> print("k" in (name and month and year))
>> True
>>  >>>
>>
>> yes, since expression returns 'ijkl', then the in operator can detect
>> the 'k' character within the returned string.
>>
>
> Someone want to explain this?

At the very least read the replies to your questions.
http://code.activestate.com/lists/python-list/644572/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: A certainl part of an if() structure never gets executed.

[Nick the Gr33k]

On 14/6/2013 11:57 πμ, Chris Angelico wrote:

On Fri, Jun 14, 2013 at 6:44 PM, Nick the Gr33k  wrote:

Someone want to explain this?


Stop writing. Start reading. It has been explained. In the course of a
long and adventurous thread in the principal European courts, it has
been revealed to you that ...

Fill in whatever you like for the rest, it's probably all been
revealed at some point already.

ChrisA



Well i do not understand it.
Had to use:

if '-' not in name + month + year:
			cur.execute( '''SELECT * FROM works WHERE clientsID = (SELECT id FROM 
clients WHERE name = %s) and MONTH(lastvisit) = %s and YEAR(lastvisit) = 
%s ORDER BY lastvisit ASC''', (name, month, year) )

elif '-' not in name + year:
			cur.execute( '''SELECT * FROM works WHERE clientsID = (SELECT id FROM 
clients WHERE name = %s) and YEAR(lastvisit) = %s ORDER BY lastvisit 
ASC''', (name, year) )

elif '-' not in month + year:
			cur.execute( '''SELECT * FROM works WHERE MONTH(lastvisit) = %s and 
YEAR(lastvisit) = %s ORDER BY lastvisit ASC''', (month, year) )

elif '-' not in year:
			cur.execute( '''SELECT * FROM works WHERE YEAR(lastvisit) = %s ORDER 
BY lastvisit ASC''', year )


to am eit work.

but i really wont to understand how 'or' and 'and' works inside an 
expression. please answer my previous post if you know.


--
What is now proved was at first only imagined!
--
http://mail.python.org/mailman/listinfo/python-list

Re: A certainl part of an if() structure never gets executed.

[Fábio Santos]

On 14 Jun 2013 09:51, "Nick the Gr33k"  wrote:
>
> On 14/6/2013 11:28 πμ, Jussi Piitulainen wrote:
>
> 'Parker' and 'May' and '2001'
>>
>> '2001'
>
>
> But why?
>
> that expression should return True since all stings are not empty.
>
>
>> Either way, the interactive prompt is your friend.
>>
>

At the very least read the replies to your questions.
http://code.activestate.com/lists/python-list/644572/
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: A certainl part of an if() structure never gets executed.

[Chris Angelico]

On Fri, Jun 14, 2013 at 6:44 PM, Nick the Gr33k  wrote:
> Someone want to explain this?

Stop writing. Start reading. It has been explained. In the course of a
long and adventurous thread in the principal European courts, it has
been revealed to you that ...

Fill in whatever you like for the rest, it's probably all been
revealed at some point already.

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

Re: A certainl part of an if() structure never gets executed.

[Nick the Gr33k]

On 14/6/2013 11:03 πμ, Nick the Gr33k wrote:

On 14/6/2013 4:14 πμ, Steven D'Aprano wrote:

On Thu, 13 Jun 2013 17:26:18 +0300, Νικόλαος Κούρας wrote:


i just want 4 cases to examine so correct execute to be run:

i'm reading and reading and reading this all over:

if '-' not in ( name and month and year ):

and i cant comprehend it.


Don't just read it. Open the interactive interpreter and test it.

name = "abcd"
month = "efgh"
year = "ijkl"

print(name and month and year)

If you run that, you will see what the result of
(name and month and year) is. Now, ask yourself:

"k" in (name and month and year)

True or false? Check your answer:

print("k" in (name and month and year))



 >>> name="abcd"
 >>> month="efgh"
 >>> year="ijkl"

 >>> print(name or month or year)
abcd

Can understand that, it takes the first string out of the 3 strings that
has a truthy value.

 >>> print("k" in (name and month and year))
True

No clue. since the expression in parenthesis returns 'abcd' how can 'k'
contained within 'abcd' ?

 >>> print(name and month and year)
ijkl

Seems here is returning the last string out of 3 strings, but have no
clue why Python doing this.

 >>> print("k" in (name and month and year))
True
 >>>

yes, since expression returns 'ijkl', then the in operator can detect
the 'k' character within the returned string.



Someone want to explain this?

--
What is now proved was at first only imagined!
--
http://mail.python.org/mailman/listinfo/python-list

Re: A certainl part of an if() structure never gets executed.

[Chris Angelico]

On Fri, Jun 14, 2013 at 6:41 PM, Nick the Gr33k  wrote:
> On 14/6/2013 11:28 πμ, Jussi Piitulainen wrote:
>
> 'Parker' and 'May' and '2001'
>>
>> '2001'
>
>
> But why?
>
> that expression should return True since all stings are not empty.

It does. Not the bool value, but it does return a true value.

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

Re: A certainl part of an if() structure never gets executed.

[Nick the Gr33k]

On 14/6/2013 11:28 πμ, Jussi Piitulainen wrote:


'Parker' and 'May' and '2001'

'2001'


But why?

that expression should return True since all stings are not empty.


Either way, the interactive prompt is your friend.




--
What is now proved was at first only imagined!
--
http://mail.python.org/mailman/listinfo/python-list

Re: A certainl part of an if() structure never gets executed.

[Fábio Santos]

On 14 Jun 2013 09:09, "Nick the Gr33k"  wrote:
> >>> print(name and month and year)
> ijkl
>
> Seems here is returning the last string out of 3 strings, but have no
clue why Python doing this.
>

You have been told this above.

All languages kind of do that. Ever seen this command on a shell?

mkdir directory && cd directory

The shell evaluated the first and if that was truthy it went on to evaluate
the second and return that.

Now. You've been told countless times that you won't get anything from "not
in (a and b and c)", nor from "not in (a or b or c)".

Also you have been shown this link and I feel you really need to read it.

http://slash7.com/2006/12/22/vampires/

Cheers
-- 
http://mail.python.org/mailman/listinfo/python-list