Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > A certainl part of an if() structure never gets executed.

Reply
Thread Tools

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

 
 
Dave Angel
Guest
Posts: n/a
 
      06-18-2013
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:
>>>
>>> <SNIP>
>>>
>>> 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
 
Reply With Quote
 
 
 
 
Steven D'Aprano
Guest
Posts: n/a
 
      06-18-2013
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:
>>>>
>>>> <SNIP>
>>>>
>>>> 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 "<stdin>", line 1, in <module>
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
 
Reply With Quote
 
 
 
 
Steven D'Aprano
Guest
Posts: n/a
 
      06-18-2013
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
 
Reply With Quote
 
Νίκος
Guest
Posts: n/a
 
      06-18-2013
Στις 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!
 
Reply With Quote
 
Steven D'Aprano
Guest
Posts: n/a
 
      06-18-2013
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
 
Reply With Quote
 
Νίκος
Guest
Posts: n/a
 
      06-18-2013
Στις 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!
 
Reply With Quote
 
Chris Angelico
Guest
Posts: n/a
 
      06-18-2013
On Tue, Jun 18, 2013 at 7:51 PM, <(E-Mail Removed)> 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
 
Reply With Quote
 
Jan Riechers
Guest
Posts: n/a
 
      06-18-2013
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

 
Reply With Quote
 
Dave Angel
Guest
Posts: n/a
 
      06-19-2013
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 <(E-Mail Removed)> wrote:
>>
>> On 16/6/2013 4:55 ??, Tim Roberts wrote:
>>
>>> Nick the Gr33k <(E-Mail Removed)> 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
 
Reply With Quote
 
Chris Angelico
Guest
Posts: n/a
 
      06-19-2013
On Wed, Jun 19, 2013 at 3:42 PM, Dave Angel <(E-Mail Removed)> 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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
semple code accept never executed fakessh C Programming 11 09-15-2012 05:46 AM
Using callback, I fill dorpdownlist without postback but it gets empty when a postback is executed Fabio Mastria ASP .Net 5 01-30-2008 09:07 PM
server event never/always executed phil ASP .Net Web Controls 1 06-06-2006 12:00 PM
ORIGINAL CODE GETS EXECUTED NOT THE NEW CODE - ASCX sk ASP .Net 1 04-19-2006 11:50 AM
Page_Unload gets executed twice chefo@bulgaria.com ASP .Net 0 01-21-2005 01:44 PM



Advertisments