Programming Forums > Script Programming > Python

DaWei · May 21st, 2006, 9:51 AM

Obviously, some Python brevity is of the same type as the C/C++ ternary operator, which is to say, not really more efficient, but more efficient to write. How much do you use this in your Python? Here's an example:

(Toggle Plain Text)

    for sets in re.finditer (pattern, doc, re.I):
	medList.append ([found for found in sets.group (1, 2, 3) if found != None])
    tagList.append (medList)

The second line is an example, and all three lines could be combined. How much of this do you do? Just curious.

Arevos · May 21st, 2006, 1:59 PM

I think it depends on how easy it appears to read. As a general rule of thumb, I try to keep list comprehensions under 80 characters long.

hydroxide · May 22nd, 2006, 3:16 AM

Quote:

Originally Posted by DaWei

Obviously, some Python brevity is of the same type as the C/C++ ternary operator, which is to say, not really more efficient, but more efficient to write. How much do you use this in your Python? Here's an example:

(Toggle Plain Text)

    for sets in re.finditer (pattern, doc, re.I):
	medList.append ([found for found in sets.group (1, 2, 3) if found != None])
    tagList.append (medList)

The second line is an example, and all three lines could be combined. How much of this do you do? Just curious.

In general I'd make that five lines (and if the listcomp were complicated I'd use more):

(Toggle Plain Text)

    for sets in re.finditer(pattern, doc, re.I):
        matches = [found for found in sets.group (1, 2, 3) 
                      if found is not None] # "is not" is safer practice in general
        medList.append (matches)
    tagList.append (medList)

It's rare that a function in Python will go over a page for me. If it does, I try to split things up. For me the extra fraction of a second overhead in the funccall is neither here nor there and readability should trump brevity. The entire structure isn't there, but assuming that you're gathering tags all at the same time, I'd probably use a generator instead:

(Toggle Plain Text)

    def gather(pattern, doc):
        yield [[found for found in sets.group (1, 2, 3) 
                   if found is not None]
                for sets in re.finditer(pattern, doc, re.I)]

    def run():
        taglist = [gather(pattern, doc)
                      for pattern, doc in fetchlist()]
        use(taglist)

-T. (Gnaaah - code appears as non-monospaced for me - hope it looks ok)

Arevos · May 22nd, 2006, 4:25 AM

I'd design it with a slightly more general purpose "gather" function, myself:

(Toggle Plain Text)

def gather(sets, groups):
    for found in sets.group(*groups):
        if found is not None: yield

found = re.finditer (pattern, doc, re.I)

medList = [x for x in gather(sets, (1, 2, 3)) for sets in found]

Although, on the other hand, if gather will only be used once, it seems a little redundant to wrap it in a separate function.

DaWei · May 22nd, 2006, 7:09 AM

Please explain to me why "is not" is safer practice....

Arevos · May 22nd, 2006, 7:16 AM

I think it's just more human-readable than "not (x is y)". I don't believe it has any other significance.

DaWei · May 22nd, 2006, 7:20 AM

Well, I can easily accept that. I don't know from generators, I'll have to put that in lesson 2.

DaWei · May 22nd, 2006, 9:40 AM

(Toggle Plain Text)

if found is not None

means: if 'found' is not the same object as 'None'

(Toggle Plain Text)

if found != None

means: 'found' is not equal to 'None'

I am a total Python noob. That means ignorant, or uninformed; not stupid. Please do not mislead me while I'm trying to learn, whether it's to promote yourself as a guru, or high-priest, or for any other reason. If you care to give a rational dissertation on why one of the above is safer than the other (particularly in this circumstance), please feel free to do so. I'll certainly read it with all my attention.

Arevos · May 22nd, 2006, 10:55 AM

Quote:

Originally Posted by DaWei

I am a total Python noob. That means ignorant, or uninformed; not stupid. Please do not mislead me while I'm trying to learn, whether it's to promote yourself as a guru, or high-priest, or for any other reason.

Sorry, I merely misunderstood what you were asking.

I thought you were asking why "x is not y" is used instead of "not (x is y)", a question that I've pondered before (because whilst "is not" makes sense in English, it makes less sense from a programming perspective). I didn't realise you were asking the difference between "==" and "is".

As for why "is" should be used instead of "==" for checking None, well, in most cases, it doesn't matter. However, Python objects can overide certain operators (as in C++), thus it's possible that an object will tell you that it is equal to None, without actually being None.

Using "is" ensures that the object really is (or is not) None in all circumstances.

DaWei · May 22nd, 2006, 11:36 AM

It wasn't directed at you, Arevos, it was directed at the rewriting of my code from

(Toggle Plain Text)

medList.append ([found for found in sets.group (1, 2, 3) if found != None])

to

(Toggle Plain Text)

if found is not None] # "is not" is safer practice in general

which is an explicit tutorial comment. In fact, the thread HAS been educational. I diverted from my course long enough to go check out generators. I see their utility, but it isn't applicable in this case. The code exists in one place and gets two passes (one for each of two classes of tags). Of particular value to me was discovering the packer/unpacker capability (*group) along the way.

May 21st, 2006, 9:51 AM	#1
DaWei Resident Grouch Join Date: Jun 2005 Posts: 6,453 Rep Power: 10	Python brevity Obviously, some Python brevity is of the same type as the C/C++ ternary operator, which is to say, not really more efficient, but more efficient to write. How much do you use this in your Python? Here's an example: (Toggle Plain Text) for sets in re.finditer (pattern, doc, re.I): medList.append ([found for found in sets.group (1, 2, 3) if found != None]) tagList.append (medList) for sets in re.finditer (pattern, doc, re.I): medList.append ([found for found in sets.group (1, 2, 3) if found != None]) tagList.append (medList) The second line is an example, and all three lines could be combined. How much of this do you do? Just curious. __________________ Abstraction doesn't make it impossible to write bad code; it makes it possible to write superior code. Contributor's Corner: Grumpy on C++ Exceptions DaWei on Pointers

May 22nd, 2006, 4:25 AM	#4
Arevos Programming Guru Join Date: Aug 2005 Location: England Posts: 1,499 Rep Power: 5	I'd design it with a slightly more general purpose "gather" function, myself: (Toggle Plain Text) def gather(sets, groups): for found in sets.group(groups): if found is not None: yield found = re.finditer (pattern, doc, re.I) medList = [x for x in gather(sets, (1, 2, 3)) for sets in found] def gather(sets, groups): for found in sets.group(groups): if found is not None: yield found = re.finditer (pattern, doc, re.I) medList = [x for x in gather(sets, (1, 2, 3)) for sets in found] Although, on the other hand, if gather will only be used once, it seems a little redundant to wrap it in a separate function.

May 22nd, 2006, 7:09 AM	#5
DaWei Resident Grouch Join Date: Jun 2005 Posts: 6,453 Rep Power: 10	Please explain to me why "is not" is safer practice.... __________________ Abstraction doesn't make it impossible to write bad code; it makes it possible to write superior code. Contributor's Corner: Grumpy on C++ Exceptions DaWei on Pointers

May 22nd, 2006, 7:20 AM	#7
DaWei Resident Grouch Join Date: Jun 2005 Posts: 6,453 Rep Power: 10	Well, I can easily accept that. I don't know from generators, I'll have to put that in lesson 2. __________________ Abstraction doesn't make it impossible to write bad code; it makes it possible to write superior code. Contributor's Corner: Grumpy on C++ Exceptions DaWei on Pointers

May 22nd, 2006, 9:40 AM	#8
DaWei Resident Grouch Join Date: Jun 2005 Posts: 6,453 Rep Power: 10	(Toggle Plain Text) if found is not None if found is not None means: if 'found' is not the same object as 'None' (Toggle Plain Text) if found != None if found != None means: 'found' is not equal to 'None' I am a total Python noob. That means ignorant, or uninformed; not stupid. Please do not mislead me while I'm trying to learn, whether it's to promote yourself as a guru, or high-priest, or for any other reason. If you care to give a rational dissertation on why one of the above is safer than the other (particularly in this circumstance), please feel free to do so. I'll certainly read it with all my attention. __________________ Abstraction doesn't make it impossible to write bad code; it makes it possible to write superior code. Contributor's Corner: Grumpy on C++ Exceptions DaWei on Pointers

May 21st, 2006, 1:59 PM	#2
Arevos Programming Guru Join Date: Aug 2005 Location: England Posts: 1,499 Rep Power: 5	I think it depends on how easy it appears to read. As a general rule of thumb, I try to keep list comprehensions under 80 characters long.

May 22nd, 2006, 7:16 AM	#6
Arevos Programming Guru Join Date: Aug 2005 Location: England Posts: 1,499 Rep Power: 5	I think it's just more human-readable than "not (x is y)". I don't believe it has any other significance.

May 22nd, 2006, 11:36 AM	#10
DaWei Resident Grouch Join Date: Jun 2005 Posts: 6,453 Rep Power: 10	It wasn't directed at you, Arevos, it was directed at the rewriting of my code from (Toggle Plain Text) medList.append ([found for found in sets.group (1, 2, 3) if found != None]) medList.append ([found for found in sets.group (1, 2, 3) if found != None]) to (Toggle Plain Text) if found is not None] # "is not" is safer practice in general if found is not None] # "is not" is safer practice in general which is an explicit tutorial comment. In fact, the thread HAS been educational. I diverted from my course long enough to go check out generators. I see their utility, but it isn't applicable in this case. The code exists in one place and gets two passes (one for each of two classes of tags). Of particular value to me was discovering the packer/unpacker capability (group) along the way. __________________ Abstraction doesn't make it impossible to write bad code; it makes it possible to write superior code. Contributor's Corner: Grumpy on C++ Exceptions DaWei on Pointers*

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode