twitter: comp.lang.python - 26 new messages in 11 topics

comp.lang.python
http://groups.google.com/group/comp.lang.python?hl=en

comp.lang.python@googlegroups.com

Today's topics:

==============================================================================
TOPIC: Docstrings considered too complicated
http://groups.google.com/group/comp.lang.python/t/dea5c94f3d058e26?hl=en
==============================================================================

== 1 of 8 ==
Date: Wed, Mar 3 2010 11:54 am
From: David Robinow

On Wed, Mar 3, 2010 at 1:01 PM, Ed Keith <e_d_k@yahoo.com> wrote:
> --- On Wed, 3/3/10, D'Arcy J.M. Cain wrote:
>
>> They needed a way to tell where the end of the information
>> was. Why
>> they used ^Z (SUB - Substitute) instead of ^C (ETX - End of
>> TeXt) or
>> even ^D (EOT - End Of Transmission) is anyone's guess.
>
> That has always puzzled me to. ETX and EOT were well established, why no use one of them? I'd love to know what they were thinking.

There were numerous incompatible and primitive transfer protocols in
those days. They probably wanted to pick something that was NOT well
established so it would pass through without, for example, causing End
Of Transmission.

== 2 of 8 ==
Date: Wed, Mar 3 2010 12:02 pm
From: Grant Edwards

On 2010-03-03, mk <mrkafk@gmail.com> wrote:

>> That has always puzzled me to. ETX and EOT were well established, why
>> no use one of them? I'd love to know what they were thinking.
>
> Probably nothing: what many people do with confronted with a problem.
>
> It reminds me of why Windows uses backslashes for path separation
> instead of slashes: what I've *heard*, and do not know if it's true,
> it's because Gates fancied using / for options switch instead of -,
> and to hell with established practice.

Using / for the option switch _was_ the established practice (if you
came from a DEC background the way that CP/M and DOS did).

--
Grant Edwards grant.b.edwards Yow! Boy, am I glad it's
at only 1971...
gmail.com

== 3 of 8 ==
Date: Wed, Mar 3 2010 1:19 pm
From: mk

Steve Holden wrote:

> Puts me in mind of Mario Wolczko's early attempts to implement SmallTalk
> on a VAX 11/750. The only bitmapped display we had available was a Three
> Rivers PERQ, connected by a 9600bps serial line. We left it running at
> seven o'clock one evening, and by nine am the next day it had brought up
> about two thirds of the initial VM loader screen ...
>
> You tell these young kids, and they just don't believe you!

For the uncouth yobs, err, culturally-challenged:

http://www.youtube.com/watch?v=Xe1a1wHxTyo

(Four Yorkshiremen)

Regards,
mk

== 4 of 8 ==
Date: Wed, Mar 3 2010 1:29 pm
From: "D'Arcy J.M. Cain"

On Wed, 03 Mar 2010 18:34:51 +0000
MRAB <python@mrabarnett.plus.com> wrote:
> But I was still able to play Nim and Duck Shoot (after keying it in)!

Did you ever play Star Trek with sound effects? I was never able to
get it to work but supposedly if you put an AM radio tuned to a
specific frequency near the side with the I/O card it would generate
static that was supposed to be the sound of explosions.

Of course, the explosions were happening in a vaccum so maybe the
silence was accurate. :-)

--
D'Arcy J.M. Cain <darcy@druid.net> | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.

== 5 of 8 ==
Date: Wed, Mar 3 2010 1:37 pm
From: "D'Arcy J.M. Cain"

On Wed, 03 Mar 2010 20:44:08 +0100
mk <mrkafk@gmail.com> wrote:
> It reminds me of why Windows uses backslashes for path separation
> instead of slashes: what I've *heard*, and do not know if it's true,
> it's because Gates fancied using / for options switch instead of -, and
> to hell with established practice.

That was because CP/M used slashes for options and DOS copied that. By
the time hierarchy was added it was too late to change.

--
D'Arcy J.M. Cain <darcy@druid.net> | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.

== 6 of 8 ==
Date: Wed, Mar 3 2010 1:43 pm
From: Ed Keith

--- On Wed, 3/3/10, David Robinow <drobinow@gmail.com> wrote:

> From: David Robinow <drobinow@gmail.com>
> Subject: Re: Docstrings considered too complicated
> To: python-list@python.org
> Date: Wednesday, March 3, 2010, 2:54 PM
> On Wed, Mar 3, 2010 at 1:01 PM, Ed
> Keith <e_d_k@yahoo.com>
> wrote:
> > --- On Wed, 3/3/10, D'Arcy J.M. Cain wrote:
> >
> >> They needed a way to tell where the end of the
> information
> >> was. Why
> >> they used ^Z (SUB - Substitute) instead of ^C (ETX
> - End of
> >> TeXt) or
> >> even ^D (EOT - End Of Transmission) is anyone's
> guess.
> >
> > That has always puzzled me to. ETX and EOT were well
> established, why no use one of them? I'd love to know what
> they were thinking.
>
> There were numerous incompatible and primitive transfer
> protocols in
> those days. They probably wanted to pick something that was
> NOT well
> established so it would pass through without, for example,
> causing End
> Of Transmission.

That makes a lot of sense.

-EdK

Ed Keith
e_d_k@yahoo.com

Blog: edkeith.blogspot.com

== 7 of 8 ==
Date: Wed, Mar 3 2010 1:45 pm
From: MRAB

D'Arcy J.M. Cain wrote:
> On Wed, 03 Mar 2010 18:34:51 +0000
> MRAB <python@mrabarnett.plus.com> wrote:
>> But I was still able to play Nim and Duck Shoot (after keying it in)!
>
> Did you ever play Star Trek with sound effects? I was never able to
> get it to work but supposedly if you put an AM radio tuned to a
> specific frequency near the side with the I/O card it would generate
> static that was supposed to be the sound of explosions.
>
> Of course, the explosions were happening in a vaccum so maybe the
> silence was accurate. :-)
>
A computer with sound? Heresy! :-)

There was some hardware that could be added to provide some sort of
video output, IIRC.

Aha, here it is:
http://en.wikipedia.org/wiki/MK14

and also here:

http://www.nvg.ntnu.no/sinclair/computers/mk14/mk14_photos.htm

The top-left picture looks like it has all its chips, so is the
fully-expanded version.

Oh, I forgot about the red reset button!

== 8 of 8 ==
Date: Wed, Mar 3 2010 1:58 pm
From: Andreas Waldenburger

On Wed, 03 Mar 2010 22:19:04 +0100 mk <mrkafk@gmail.com> wrote:

> For the uncouth yobs, err, culturally-challenged:
>
> http://www.youtube.com/watch?v=Xe1a1wHxTyo
>
> (Four Yorkshiremen)
>

http://www.youtube.com/watch?v=-eDaSvRO9xA

That's the definitive version. I mean, if you're going to talk vintage,
talk vintage.

--
INVALID? DE!

==============================================================================
TOPIC: Sort Big File Help
http://groups.google.com/group/comp.lang.python/t/229446141c0af5c7?hl=en
==============================================================================

== 1 of 4 ==
Date: Wed, Mar 3 2010 11:59 am
From: MRAB

mk wrote:
> John Filben wrote:
>> I am new to Python but have used many other (mostly dead) languages in
>> the past. I want to be able to process *.txt and *.csv files. I can
>> now read that and then change them as needed – mostly just take a
>> column and do some if-then to create a new variable. My problem is
>> sorting these files:
>>
>> 1.) How do I sort file1.txt by position and write out
>> file1_sorted.txt; for example, if all the records are 100 bytes long
>> and there is a three digit id in the position 0-2; here would be some
>> sample data:
>>
>> a. 001JohnFilben……
>>
>> b. 002Joe Smith…..
>
> Use a dictionary:
>
> linedict = {}
> for line in f:
> key = line[:3]
> linedict[key] = line[3:] # or alternatively 'line' if you want to
> include key in the line anyway
>
> sortedlines = []
> for key in linedict.keys().sort():
> sortedlines.append(linedict[key])
>
> (untested)
>
> This is the simplest, and probably inefficient approach. But it should
> work.
>
[snip]
Simpler would be:

lines = f.readlines()
lines.sort(key=lambda line: line[ : 3])

or even:

lines = sorted(f.readlines(), key=lambda line: line[ : 3]))

== 2 of 4 ==
Date: Wed, Mar 3 2010 12:58 pm
From: Arnaud Delobelle

MRAB <python@mrabarnett.plus.com> writes:

> mk wrote:
>> John Filben wrote:
>>> I am new to Python but have used many other (mostly dead) languages
>>> in the past. I want to be able to process *.txt and *.csv files.
>>> I can now read that and then change them as needed – mostly just
>>> take a column and do some if-then to create a new variable. My
>>> problem is sorting these files:
>>>
>>> 1.) How do I sort file1.txt by position and write out
>>> file1_sorted.txt; for example, if all the records are 100 bytes
>>> long and there is a three digit id in the position 0-2; here would
>>> be some sample data:
>>>
>>> a. 001JohnFilben……
>>>
>>> b. 002Joe Smith…..
>>
>> Use a dictionary:
>>
>> linedict = {}
>> for line in f:
>> key = line[:3]
>> linedict[key] = line[3:] # or alternatively 'line' if you want
>> to include key in the line anyway
>>
>> sortedlines = []
>> for key in linedict.keys().sort():
>> sortedlines.append(linedict[key])
>>
>> (untested)
>>
>> This is the simplest, and probably inefficient approach. But it
>> should work.
>>
> [snip]
> Simpler would be:
>
> lines = f.readlines()
> lines.sort(key=lambda line: line[ : 3])
>
> or even:
>
> lines = sorted(f.readlines(), key=lambda line: line[ : 3]))

Or even:

lines = sorted(f)

--
Arnaud

== 3 of 4 ==
Date: Wed, Mar 3 2010 1:46 pm
From: mk

John, there's an error in my program, I forgot that list.sort() method
doesn't return the list (it sorts in place). So it should look like:

#!/usr/bin/python

def sortit(fname):
fo = open(fname)
linedict = {}
for line in fo:
key = line[:3]
linedict[key] = line
sortedlines = []
keys = linedict.keys()
keys.sort()
for key in keys:
sortedlines.append(linedict[key])
return sortedlines

if __name__ == '__main__':
sortit('testfile.txt')

MRAB's solution is obviously better, provided you know about Python's
lambda.

Regards,
mk

== 4 of 4 ==
Date: Wed, Mar 3 2010 1:52 pm
From: mk

MRAB wrote:

> [snip]
> Simpler would be:
>
> lines = f.readlines()
> lines.sort(key=lambda line: line[ : 3])
>
> or even:
>
> lines = sorted(f.readlines(), key=lambda line: line[ : 3]))

Sure, but a complete newbie (I have this impression about OP) doesn't
have to know about lambda.

I expected my solution to be slower, but it's not (on a file with
100,000 random string lines):

# time ./sort1.py

real 0m0.386s
user 0m0.372s
sys 0m0.014s

# time ./sort2.py

real 0m0.303s
user 0m0.286s
sys 0m0.017s

sort1.py:

#!/usr/bin/python

def sortit(fname):
lines = open(fname).readlines()
lines.sort(key = lambda x: x[:3])

if __name__ == '__main__':
sortit('testfile.txt')

sort2.py:

#!/usr/bin/python

if __name__ == '__main__':
sortit('testfile.txt')

Any idea why? After all, I'm "manually" doing quite a lot: allocating
key in a dict, then sorting dict's keys, then iterating over keys and
accessing dict value.

Regards,
mk

==============================================================================
TOPIC: Re Interest check in some delicious syntactic sugar for "except:pass"
http://groups.google.com/group/comp.lang.python/t/0041fb118a65a722?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Mar 3 2010 12:18 pm
From: Terry Reedy

On 3/3/2010 6:47 AM, Oren Elrad wrote:

> With that said, let me at least offer a token defense of my position.
> By way of motivation, I wrote that email after copying/pasting the
> following a few times around a project until I wrote it into def
> SilentlyDelete() and its cousin SilentlyRmdir()
>
> """ code involving somefile """
> try:
> ........os.remove(somefile)
> except:
> .......pass # The bloody search indexer has got the file and I
> can't delete it. Nothing to be done.
>
> Certainly the parade of horribles (bad files! corrupt data! syntax
> errors!) is a tad melodramatic. Either os.remove() succeeds or it
> doesn't and the execution path (in the estimation of this programmer,
> at least) is not at all impacted by whether it succeeds or fails. I
> know with certainty at compile time what exceptions might be raised
> and what the consequences of passing them are and there is no sense
> pestering the user or sweating over it. Nor can I see the logic, as
> was suggested, in writing "except OSError:" since (seems to me) mere
> surplusage -- it neither causes a semantic difference in the way the
> program runs nor provides anything useful to the reader.

Suppose you misspell 'somefile' or 'remove' (or the file gets corrupted
somehow -- which unfortunate can happen). Now you suppress the NameError
or AttributeError, which is a mistake. Suppose someone copies your code
into a context where 'os' is not imported or where 'os' is a variable
(for bone type, for instance). More bad error suppression.

Bare excepts seem ok for experimental, draft, or throwaway code, but
somewhat dubious for production code.

For anyone reading your code a few years from now, 'except OSError'
would be clearer that that is all you mean to pass on.

Wrapping the code in a function makes the overhead of adding 'OSError'
trivial. It also makes it trivial to do something different, like adding
the file to a collection to be retried later. It also reduces the points
of possible corruption to one instead of many.

Terry Jan Reedy

==============================================================================
TOPIC: Which mock library do you prefer?
http://groups.google.com/group/comp.lang.python/t/a12daa9de8354ff2?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Mar 3 2010 12:47 pm
From: Terry Reedy

On 3/3/2010 7:43 AM, Albert van der Horst wrote:

>> Right, isolation is essential. But I can't decide to which extent I
>> should propagate isolation.
>> For example, in "Python Testing: Beginner's Guide" by Daniel Arbuckle,
>> author suggests that if you do unittesting you should isolate the
>> smallest units of code from each other. For example, if you have a
>> class:
>> Class SomeClass(object):
>> def method1(self):
>> return 5
>> def method2(self):
>> return self.method1 + 10
>>
>> According to the book, if you want to test method2, you should isolate
>> it from method1 and class instance('self').
>> Other books are not so strict...
>>
>> And what should I follow as newbie?

Pretty much any test assumes that basic things other than the tested
object work correctly. For instance, any test of method2 will assume
that '+' works correctly. The dependency graph between methods in a
class will nearly always be acyclic. So I would start with the 'leaf'
methods and work up. In the above case, test method1 first and then
method2. The dependence of the test of method2 on the correctness of
method1 is hardly worse, to me, then its dependence on the correctness
of int.__add__. It is just the the responsibility for the latter falls
on the developers, and *their* suite of tests.

Whenever any code test fails, there are two possibilities. The code
itself is buggy, or something it depends on is buggy. I see two reasons
for isolation and mock units: test resource saving (especially time) and
independent development. If you are developing ClassA and someone else
is developing ClassB, you might want to test ClassA even though it
depends on ClassB and classB is not ready yet. This consideration is
much less likely to apply to method2 versus method1 of a coherent class.

My current opinions.

Terry Jan Reedy

==============================================================================
TOPIC: NoSQL Movement?
http://groups.google.com/group/comp.lang.python/t/942e22a0145599b2?hl=en
==============================================================================

== 1 of 2 ==
Date: Wed, Mar 3 2010 12:54 pm
From: ccc31807

On Mar 3, 12:36 pm, Xah Lee <xah...@gmail.com> wrote:
> recently i wrote a blog article on The NoSQL Movement
> athttp://xahlee.org/comp/nosql.html
>
> i'd like to post it somewhere public to solicit opinions, but in the
> 20 min or so, i couldn't find a proper newsgroup, nor private list
> that my somewhat anti-NoSQL Movement article is fitting.

I only read the first two paragraphs of your article, so I can't
respond to it.

I've halfway followed the NoSQL movement. My day job is a database
manager and I so SQL databases for a living, as well as Perl. I see a
lot of abuse of relational databases in the Real World, as well as a
lot of abuse for non-SQL alternatives, e.g., (mis)using Excel for a
database. The big, enterprise database we have at work is built on IBM
UniQuery, which is a non-SQL flat file database product, so I've had a
lot of experience with big non-SQL database work.

I've also developed a marked preference for plain text databases. For
a lot of applications they are simpler, easier, and better. I've also
had some experience with XML databases, and find that they are ideal
for applications with 'ragged' data.

As with anything else, you need to match the tool to the job. Yes, I
feel that relational database technology has been much used, and much
abused. However, one of my favorite applications is Postgres, and I
think it's absolutely unbeatable where you have to store data and
perform a large number of queries.

Finally, with regard to Structured Query Language itself, I find that
it's well suited to its purpose. I hand write a lot of SQL statements
for various purposes, and while like any language you find it
exceedingly difficult to express concepts that you can think, it
mostly allows the expression of most of what you want to say.

CC.

== 2 of 2 ==
Date: Wed, Mar 3 2010 1:55 pm
From: toby

On Mar 3, 3:54 pm, ccc31807 <carte...@gmail.com> wrote:
> On Mar 3, 12:36 pm, Xah Lee <xah...@gmail.com> wrote:
>
> > recently i wrote a blog article on The NoSQL Movement
> > athttp://xahlee.org/comp/nosql.html
>
> > i'd like to post it somewhere public to solicit opinions, but in the
> > 20 min or so, i couldn't find a proper newsgroup, nor private list
> > that my somewhat anti-NoSQL Movement article is fitting.
>
> I only read the first two paragraphs of your article, so I can't
> respond to it.
>
> I've halfway followed the NoSQL movement. My day job is a database
> manager and I so SQL databases for a living, as well as Perl. I see a
> lot of abuse of relational databases in the Real World, as well as a
> lot of abuse for non-SQL alternatives, e.g., (mis)using Excel for a
> database. The big, enterprise database we have at work is built on IBM
> UniQuery, which is a non-SQL flat file database product, so I've had a
> lot of experience with big non-SQL database work.
>
> I've also developed a marked preference for plain text databases. For
> a lot of applications they are simpler, easier, and better. I've also
> had some experience with XML databases, and find that they are ideal
> for applications with 'ragged' data.
>
> As with anything else, you need to match the tool to the job. Yes, I
> feel that relational database technology has been much used, and much
> abused. However, one of my favorite applications is Postgres, and I
> think it's absolutely unbeatable

It is beatable outside of its sweetspot, like any system. NoSQL is not
so much about "beating" relational databases, as simply a blanket term
for useful non-relational technologies. There's not much point in
reading Xah beyond the heading of his manifesto, as it is no more
relevant to be "anti-NoSQL" as to be "anti-integers" because they
don't store fractions.

> where you have to store data and

"relational data"

> perform a large number of queries.

Why does the number matter?

>
> Finally, with regard to Structured Query Language itself, I find that
> it's well suited to its purpose. I hand write a lot of SQL statements
> for various purposes, and while like any language you find it
> exceedingly difficult to express concepts that you can think, it
> mostly allows the expression of most of what you want to say.
>
> CC.

==============================================================================
TOPIC: taking python enterprise level?...
http://groups.google.com/group/comp.lang.python/t/3dca28b82d10655c?hl=en
==============================================================================

== 1 of 2 ==
Date: Wed, Mar 3 2010 12:58 pm
From: mk

Philip Semanchuk wrote:
>> So there *may* be some evidence that joins are indeed bad in practice.
>> If someone has smth specific/interesting on the subject, please post.
>
> It's an unprovable assertion, or a meaningless one depending on how one
> defines the terms. You could also say "there *may* be some evidence that
> Python lists are bad in practice". Python lists and SQL JOINs are like
> any part of a language or toolkit. They're good tools for solving
> certain classes of problems. They can also be misapplied to problems
> that they're not so good at. Sometimes they're a performance bottleneck,
> even when solving the problems for which they're best. Sometimes the
> best way to solve a performance bottleneck is to redesign your
> app/system so you don't need to solve that kind of problem anymore
> (hence the join-less databases). Other times, the cure is worse than the
> disease and you're better off throwing hardware at the problem.

Look, I completely agree with what you're saying, but: that doesn't
change the possibility that joins may be expensive in comparison to
other SQL operations. This is the phrase I should have used perhaps;
'expensive in comparison with other SQL operations' instead of 'bad'.

Example from my app, where I behaved "by the book" (I hope) and
normalized my data:

$ time echo "\c hrs;
SELECT hosts.ip, reservation.start_date, architecture.architecture,
os_kind.os_kind, os_rel.os_rel, os_version.os_version, project.project,
email.email FROM hosts
INNER JOIN project ON project.id = hosts.project_id
INNER JOIN architecture ON hosts.architecture_id = architecture.id
INNER JOIN os_kind ON os_kind.id = hosts.os_kind_id
INNER JOIN os_rel ON hosts.os_rel_id = os_rel.id
INNER JOIN os_version ON hosts.os_version_id = os_version.id
INNER JOIN reservation_hosts ON hosts.id = reservation_hosts.host_id
INNER JOIN reservation on reservation.id =
reservation_hosts.reservation_id
INNER JOIN email ON reservation.email_id = email.id

;" | psql > /dev/null

real 0m0.099s
user 0m0.015s
sys 0m0.005s

$ time echo "\c hrs;
> SELECT hosts.ip FROM hosts;
> SELECT reservation.start_date FROM reservation;
> SELECT architecture.architecture FROM architecture;
> SELECT os_rel.os_rel FROM os_rel;
> SELECT os_version.os_version FROM os_version;
> SELECT project.project FROM project;
> SELECT email.email FROM email;
> " | psql > /dev/null

real 0m0.046s
user 0m0.008s
sys 0m0.004s

Note: I've created indexes on those tables, both on data columns like
hosts.ip and on .id columns.

So yes, joins apparently are at least twice as expensive as simple
selects without joins, on a small dataset. Not a drastic increase in
cost, but smth definitely shows.

It would be interesting to see what happens when row numbers increase to
large numbers, but I have no such data.

Regards,
mk

== 2 of 2 ==
Date: Wed, Mar 3 2010 1:23 pm
From: "D'Arcy J.M. Cain"

On Wed, 03 Mar 2010 20:39:35 +0100
mk <mrkafk@gmail.com> wrote:
> > If you denormalise the table, and update the first index to be on
> > (client_id, project_id, date) it can end up running far more quickly -

Maybe. Don't start with denormalization. Write it properly and only
consider changing if profiling suggests that that is your bottleneck.
With a decent database engine and proper design it will hardly ever be.

> From what you write further in the mail I conclude that you have not
> eliminated the first table, just made table projects look like I wrote
> above, right? (and used stored procedures to make sure that both tables
> contain the relevant data for client_id and project_id columns in both
> tables)

Note that rather than speeding things up this could actually slow
things down depending on your usage. If you do lots of updates and you
have to write extra information every time then that's worse than a few
extra reads, especially since read data can be cached but written data
must be pushed to disk immediately in an ACID database.

--
D'Arcy J.M. Cain <darcy@druid.net> | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.

==============================================================================
TOPIC: Working group for Python CPAN-equivalence?
http://groups.google.com/group/comp.lang.python/t/c2c452cc4aaa6e98?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Mar 3 2010 1:00 pm
From: Terry Reedy

On 3/3/2010 12:05 PM, John Nagle wrote:

>> We have an equivalent in PyPI, though it's incomplete since many
>> *registered* packages are not actually hosted *at* PyPI.
>
> CPAN is a repository. PyPi is an collection of links.

As Ben said, PyPI currently is also a respository and not just links to
other repositories.

> CPAN has over 260 mirrors. PyPi has none.

A mirroring system has been or is being set up with at least a couple of
mirrors for things that are hosted at PyPI.

> CPAN enforces standard organization on packages. PyPi does not.
>
> CPAN has quality control, with testers and a test reporting system.
> PyPi does not.

People who are familiar with and like CPAN are free to help improve
PyPI. Those of us not familiar with it may not know what we are missing,
or have little idea about what works with CPAN.

Terry Jan Reedy

==============================================================================
TOPIC: A "scopeguard" for Python
http://groups.google.com/group/comp.lang.python/t/8c752e871801c223?hl=en
==============================================================================

== 1 of 3 ==
Date: Wed, Mar 3 2010 1:02 pm
From: Jerry Hill

On Wed, Mar 3, 2010 at 2:32 PM, Alf P. Steinbach <alfps@start.no> wrote:
> I'm not sure what that shows, except that you haven't grokked this yet.

Maybe you could give us an example of how your code should be used,
and how it differs from the other examples people have given? And
maybe a quick example of why you would not want to clean up after a
failed operation?

I've been trying to follow along, and I don't get it either. I guess
that makes me at least the third person that doesn't understand what
you're trying to get across.

--
Jerry

== 2 of 3 ==
Date: Wed, Mar 3 2010 1:02 pm
From: Robert Kern

On 2010-03-03 13:32 PM, Alf P. Steinbach wrote:
> * Robert Kern:
>> On 2010-03-03 11:18 AM, Alf P. Steinbach wrote:
>>> * Robert Kern:
>>>> On 2010-03-03 09:56 AM, Alf P. Steinbach wrote:
>>>>> * Mike Kent:
>>>>>> What's the compelling use case for this vs. a simple try/finally?
>>>>>
>>>>> if you thought about it you would mean a simple "try/else".
>>>>> "finally" is
>>>>> always executed. which is incorrect for cleanup
>>>>
>>>> Eh? Failed execution doesn't require cleanup? The example you gave is
>>>> definitely equivalent to the try: finally: that Mike posted.
>>>
>>> Sorry, that's incorrect: it's not.
>>>
>>> With correct code (mine) cleanup for action A is only performed when
>>> action A succeeds.
>>>
>>> With incorrect code cleanup for action A is performed when A fails.
>>
>> Oh?
>>
>> $ cat cleanup.py
>>
>> class Cleanup:
>> def __init__( self ):
>> self._actions = []
>>
>> def call( self, action ):
>> assert( callable( action ) )
>> self._actions.append( action )
>>
>> def __enter__( self ):
>> return self
>>
>> def __exit__( self, x_type, x_value, x_traceback ):
>> while( len( self._actions ) != 0 ):
>> try:
>> self._actions.pop()()
>> except BaseException as x:
>> raise AssertionError( "Cleanup: exception during cleanup" )
>>
>> def print_(x):
>> print x
>>
>> with Cleanup() as at_cleanup:
>> at_cleanup.call(lambda: print_("Cleanup executed without an exception."))
>>
>> with Cleanup() as at_cleanup:
>
> *Here* is where you should
>
> 1) Perform the action for which cleanup is needed.
>
> 2) Let it fail by raising an exception.
>
>
>> at_cleanup.call(lambda: print_("Cleanup execute with an exception."))
>> raise RuntimeError()
>
> With an exception raised here cleanup should of course be performed.
>
> And just in case you didn't notice: the above is not a test of the
> example I gave.
>
>
>> $ python cleanup.py
>> Cleanup executed without an exception.
>> Cleanup execute with an exception.
>> Traceback (most recent call last):
>> File "cleanup.py", line 28, in <module>
>> raise RuntimeError()
>> RuntimeError
>>
>>>> The actions are always executed in your example,
>>>
>>> Sorry, that's incorrect.
>>
>> Looks like it to me.
>
> I'm sorry, but you're
>
> 1) not testing my example which you're claiming that you're testing, and

Then I would appreciate your writing a complete, runnable example that
demonstrates the feature you are claiming. Because it's apparently not
"ensur[ing] some desired cleanup at the end of a scope, even when the scope is
exited via an exception" that you talked about in your original post.

Your sketch of an example looks like mine:

with Cleanup as at_cleanup:
# blah blah
chdir( somewhere )
at_cleanup.call( lambda: chdir( original_dir ) )
# blah blah

The cleanup function gets registered immediately after the first chdir() and
before the second "blah blah". Even if an exception is raised in the second
"blah blah", then the cleanup function will still run. This would be equivalent
to a try: finally:

# blah blah #1
chdir( somewhere )
try:
# blah blah #2
finally:
chdir( original_dir )

and not a try: else:

# blah blah #1
chdir( somewhere )
try:
# blah blah #2
else:
chdir( original_dir )

Now, I assumed that the behavior with respect to exceptions occurring in the
first "blah blah" weren't what you were talking about because until the chdir(),
there is nothing to clean up.

There is no way that the example you gave translates to a try: else: as you
claimed in your response to Mike Kent.

> 2) not even showing anything about your earlier statements, which were
> just incorrect.
>
> You're instead showing that my code works as it should for the case that
> you're testing, which is a bit unnecessary since I knew that, but thanks
> anyway.

It's the case you seem to be talking about in your original post. You seem to
have changed your mind about what you want to talk about. That's fine. We don't
have to stick with the original topic, but I do ask you to acknowledge that you
originally were talking about a feature that "ensure[s] some desired cleanup at
the end of a scope, even when the scope is exited via an exception."

Do you acknowledge this?

> I'm not sure what that shows, except that you haven't grokked this yet.
>
>
>>>> From your post, the scope guard technique is used "to ensure some
>>>> desired cleanup at the end of a scope, even when the scope is exited
>>>> via an exception." This is precisely what the try: finally: syntax is
>>>> for.
>>>
>>> You'd have to nest it. That's ugly. And more importantly, now two people
>>> in this thread (namely you and Mike) have demonstrated that they do not
>>> grok the try functionality and manage to write incorrect code, even
>>> arguing that it's correct when informed that it's not, so it's a pretty
>>> fragile construct, like goto.
>>
>> Uh-huh.
>
> Yeah. Consider that you're now for the third time failing to grasp the
> concept of cleanup for a successful operation.

Oh, I do. But if I didn't want it to run on an exception, I'd just write the
code without any try:s or with:s at all.

# blah blah #1
chdir( somewhere )
# blah blah #2
chdir( original_dir )

>>>> The with statement allows you to encapsulate repetitive boilerplate
>>>> into context managers, but a general purpose context manager like your
>>>> Cleanup class doesn't take advantage of this.
>>>
>>> I'm sorry but that's pretty meaningless. It's like: "A house allows you
>>> to encapsulate a lot of stinking garbage, but your house doesn't take
>>> advantage of that, it's disgustingly clean". Hello.
>>
>> No, I'm saying that your Cleanup class is about as ugly as the try:
>> finally:. It just shifts the ugliness around. There is a way to use
>> the with statement to make things look better and more readable in
>> certain situations, namely where there is some boilerplate that you
>> would otherwise repeat in many places using try: finally:. You can
>> encapsulate that repetitive code into a class or a @contextmanager
>> generator and just call the contextmanager. A generic context manager
>> where you register callables doesn't replace any boilerplate. You
>> still repeat all of the cleanup code everywhere. What's more, because
>> you have to shove everything into a callable, you have significantly
>> less flexibility than the try: finally:.
>
> Sorry, but that's meaningless again. You're repeating that my house has
> no garbage in it.

No, I'm repeatedly saying that I think your solution stinks. I think it's ugly.
I think it's restrictive. I think it does not improve on the available solutions.

> And you complain that it would be work to add garbage
> to it. Why do you want that garbage? I think it's nice without it!

And you are entitled to that opinion. I am giving you mine.

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco

== 3 of 3 ==
Date: Wed, Mar 3 2010 1:35 pm
From: "Alf P. Steinbach"

* Robert Kern:
> On 2010-03-03 13:32 PM, Alf P. Steinbach wrote:
>> * Robert Kern:
>>> On 2010-03-03 11:18 AM, Alf P. Steinbach wrote:
>>>> * Robert Kern:
>>>>> On 2010-03-03 09:56 AM, Alf P. Steinbach wrote:
>>>>>> * Mike Kent:
>>>>>>> What's the compelling use case for this vs. a simple try/finally?
>>>>>>
>>>>>> if you thought about it you would mean a simple "try/else".
>>>>>> "finally" is
>>>>>> always executed. which is incorrect for cleanup
>>>>>
>>>>> Eh? Failed execution doesn't require cleanup? The example you gave is
>>>>> definitely equivalent to the try: finally: that Mike posted.
>>>>
>>>> Sorry, that's incorrect: it's not.
>>>>
>>>> With correct code (mine) cleanup for action A is only performed when
>>>> action A succeeds.
>>>>
>>>> With incorrect code cleanup for action A is performed when A fails.
>>>
>>> Oh?
>>>
>>> $ cat cleanup.py
>>>
>>> class Cleanup:
>>> def __init__( self ):
>>> self._actions = []
>>>
>>> def call( self, action ):
>>> assert( callable( action ) )
>>> self._actions.append( action )
>>>
>>> def __enter__( self ):
>>> return self
>>>
>>> def __exit__( self, x_type, x_value, x_traceback ):
>>> while( len( self._actions ) != 0 ):
>>> try:
>>> self._actions.pop()()
>>> except BaseException as x:
>>> raise AssertionError( "Cleanup: exception during cleanup" )
>>>
>>> def print_(x):
>>> print x
>>>
>>> with Cleanup() as at_cleanup:
>>> at_cleanup.call(lambda: print_("Cleanup executed without an
>>> exception."))
>>>
>>> with Cleanup() as at_cleanup:
>>
>> *Here* is where you should
>>
>> 1) Perform the action for which cleanup is needed.
>>
>> 2) Let it fail by raising an exception.
>>
>>
>>> at_cleanup.call(lambda: print_("Cleanup execute with an exception."))
>>> raise RuntimeError()
>>
>> With an exception raised here cleanup should of course be performed.
>>
>> And just in case you didn't notice: the above is not a test of the
>> example I gave.
>>
>>
>>> $ python cleanup.py
>>> Cleanup executed without an exception.
>>> Cleanup execute with an exception.
>>> Traceback (most recent call last):
>>> File "cleanup.py", line 28, in <module>
>>> raise RuntimeError()
>>> RuntimeError
>>>
>>>>> The actions are always executed in your example,
>>>>
>>>> Sorry, that's incorrect.
>>>
>>> Looks like it to me.
>>
>> I'm sorry, but you're
>>
>> 1) not testing my example which you're claiming that you're testing, and
>
> Then I would appreciate your writing a complete, runnable example that
> demonstrates the feature you are claiming. Because it's apparently not
> "ensur[ing] some desired cleanup at the end of a scope, even when the
> scope is exited via an exception" that you talked about in your original
> post.
>
> Your sketch of an example looks like mine:
>
> with Cleanup as at_cleanup:
> # blah blah
> chdir( somewhere )
> at_cleanup.call( lambda: chdir( original_dir ) )
> # blah blah
>
> The cleanup function gets registered immediately after the first chdir()
> and before the second "blah blah". Even if an exception is raised in the
> second "blah blah", then the cleanup function will still run. This would
> be equivalent to a try: finally:
>
> # blah blah #1
> chdir( somewhere )
> try:
> # blah blah #2
> finally:
> chdir( original_dir )

Yes, this is equivalent code.

The try-finally that you earlier claimed was equivalent, was not.

> and not a try: else:
>
> # blah blah #1
> chdir( somewhere )
> try:
> # blah blah #2
> else:
> chdir( original_dir )

This example is however meaningless except as misdirection. There are infinitely
many constructs that include try-finally and try-else, that the with-Cleanup
code is not equivalent to. It's dumb to show one such.

Exactly what are you trying to prove here?

Your earlier claims are still incorrect.

> Now, I assumed that the behavior with respect to exceptions occurring in
> the first "blah blah" weren't what you were talking about because until
> the chdir(), there is nothing to clean up.
>
> There is no way that the example you gave translates to a try: else: as
> you claimed in your response to Mike Kent.

Of course there is.

Note that Mike wrapped the action A within the 'try':

<code author="Mike" correct="False">
original_dir = os.getcwd()
try:
os.chdir(somewhere)
# Do other stuff
finally:
os.chdir(original_dir)
# Do other cleanup
</code>

The 'finally' he used, shown above, yields incorrect behavior.

Namely cleanup always, while 'else', in that code, can yield correct behavior
/provided/ that it's coded correctly:

<code author="Alf" correct="ProbablyTrue" disclaimer="off the cuff">
original_dir = os.getcwd()
try:
os.chdir(somewhere)
except Whatever:
# whatever, e.g. logging
raise
else:
try:
# Do other stuff
finally:
os.chdir(original_dir)
# Do other cleanup
</code>

>> 2) not even showing anything about your earlier statements, which were
>> just incorrect.
>>
>> You're instead showing that my code works as it should for the case that
>> you're testing, which is a bit unnecessary since I knew that, but thanks
>> anyway.
>
> It's the case you seem to be talking about in your original post.

What's this "seems"? Are you unable to read that very short post?

> You
> seem to have changed your mind about what you want to talk about. That's
> fine.

And what's this claim about me changing any topic?

> We don't have to stick with the original topic

Why not stick with the original topic?

>, but I do ask you
> to acknowledge that you originally were talking about a feature that
> "ensure[s] some desired cleanup at the end of a scope, even when the
> scope is exited via an exception."

Yes, that's what it does.

Which is I why I wrote that.

This should not be hard to grok.

> Do you acknowledge this?

This seems like pure noise, to cover up that you were sputing a lot of incorrect
statements earlier.

>> I'm not sure what that shows, except that you haven't grokked this yet.
>>
>>
>>>>> From your post, the scope guard technique is used "to ensure some
>>>>> desired cleanup at the end of a scope, even when the scope is exited
>>>>> via an exception." This is precisely what the try: finally: syntax is
>>>>> for.
>>>>
>>>> You'd have to nest it. That's ugly. And more importantly, now two
>>>> people
>>>> in this thread (namely you and Mike) have demonstrated that they do not
>>>> grok the try functionality and manage to write incorrect code, even
>>>> arguing that it's correct when informed that it's not, so it's a pretty
>>>> fragile construct, like goto.
>>>
>>> Uh-huh.
>>
>> Yeah. Consider that you're now for the third time failing to grasp the
>> concept of cleanup for a successful operation.
>
> Oh, I do. But if I didn't want it to run on an exception, I'd just write
> the code without any try:s or with:s at all.
>
> # blah blah #1
> chdir( somewhere )
> # blah blah #2
> chdir( original_dir )

Yes, but what's that got to do with anything?

>>>>> The with statement allows you to encapsulate repetitive boilerplate
>>>>> into context managers, but a general purpose context manager like your
>>>>> Cleanup class doesn't take advantage of this.
>>>>
>>>> I'm sorry but that's pretty meaningless. It's like: "A house allows you
>>>> to encapsulate a lot of stinking garbage, but your house doesn't take
>>>> advantage of that, it's disgustingly clean". Hello.
>>>
>>> No, I'm saying that your Cleanup class is about as ugly as the try:
>>> finally:. It just shifts the ugliness around. There is a way to use
>>> the with statement to make things look better and more readable in
>>> certain situations, namely where there is some boilerplate that you
>>> would otherwise repeat in many places using try: finally:. You can
>>> encapsulate that repetitive code into a class or a @contextmanager
>>> generator and just call the contextmanager. A generic context manager
>>> where you register callables doesn't replace any boilerplate. You
>>> still repeat all of the cleanup code everywhere. What's more, because
>>> you have to shove everything into a callable, you have significantly
>>> less flexibility than the try: finally:.
>>
>> Sorry, but that's meaningless again. You're repeating that my house has
>> no garbage in it.
>
> No, I'm repeatedly saying that I think your solution stinks. I think
> it's ugly. I think it's restrictive. I think it does not improve on the
> available solutions.

First you'd have to understand it, simple as it is.

>> And you complain that it would be work to add garbage
>> to it. Why do you want that garbage? I think it's nice without it!
>
> And you are entitled to that opinion. I am giving you mine.

Well, I'm sorry, but while you are entitled to an opinion it's not an opinion
that carries any weight: first you need to get your facts and claims straight.

So far only this latest posting of yours has been free of directly incorrect
statements.

But you still have a lot of statements that just show total incomprehension,
like your example of achieving no cleanup in the case of an exception.

Cheers & hth.,

- Alf

==============================================================================
TOPIC: Generic singleton
http://groups.google.com/group/comp.lang.python/t/9228a3763eb552b3?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Mar 3 2010 1:11 pm
From: mk

Arnaud Delobelle wrote:
> mk <mrkafk@gmail.com> writes:
> [...]
>> hashable
>> ..
>> All of Python's immutable built-in objects are hashable, while no
>> mutable containers (such as lists or dictionaries) are.
>>
>> Well ok, hashable they're not; but apparently at least dict and list
>> have id()?
>
> lists and dicts are not hashable, but their types are:

Oh.

>>>> hash(dict)
> 4296155808
>>>> hash(list)
> 4296151808
>
> So just use the type as the key to the dictionary you maintain in your
> singleton.

Hmm I have tested it and it seems to work.

> But the question is what you use your singleton for.

Well, partly this was for sake of learning; but partially I was thinking
whether singleton as such may be useful for implementing "global queue
of tasks" for worker threads in a large program: instead of handing down
over and over the same reference to the global queue of tasks, classes
or functions could call Singleton() and be done with it.

Or I could make my life simpler and use global variable. :-)

I will soon need to write such program, with remote calls from pyro
(most probably), many worker threads, short-running jobs and
long-running jobs, etc.

Regards,
mk

==============================================================================
TOPIC: Pylint Argument number differs from overridden method
http://groups.google.com/group/comp.lang.python/t/12977374ae8461dc?hl=en
==============================================================================

== 1 of 2 ==
Date: Wed, Mar 3 2010 1:15 pm
From: Wanderer

On Mar 3, 2:33 pm, Robert Kern <robert.k...@gmail.com> wrote:
> On 2010-03-03 11:39 AM, Wanderer wrote:
>
> > Pylint W0221 gives the warning
> > Argument number differs from overridden method.
>
> > Why is this a problem? I'm overriding the method to add additional
> > functionality.
>
> There are exceptions to every guideline. Doing this could easily be a mistake,
> so it's one of the many things that Pylint checks for. Silence the warning if
> you like.
>
> --
> Robert Kern
>
> "I have come to believe that the whole world is an enigma, a harmless enigma
> that is made terrible by our own mad attempt to interpret it as though it had
> an underlying truth."
> -- Umberto Eco

Thanks I was just wondering if I was overlooking something about
inheritance.

== 2 of 2 ==
Date: Wed, Mar 3 2010 1:17 pm
From: Terry Reedy

On 3/3/2010 12:39 PM, Wanderer wrote:
> Pylint W0221 gives the warning
> Argument number differs from overridden method.
>
> Why is this a problem?

It *could* indicate a mistake. Lint programs, by definition, are
nitpicky, and flag things that are possible problems even though
syntactically correct.

I'm overriding the method to add additional
> functionality.
>
> This
> def GetRays(self, angle, pt, lmbda = 0.6):
> """
> """
>
> angle, x, y, Rays, Power = self.ARefract(angle, pt[0], pt[1],
> lmbda)
> pt1 = (x, y)
>
> return Rays, Power, angle, pt1
>
>
> def ARefract(self, angle, x, y, lmbda = 0.6):
> """
> """
>
> Nt = self.Mat.NtGet(lmbda)
> self.NtSet(Nt)
> angle, x, y, Rays, Power = self.Refract(angle, x, y)
>
> return angle, x, y, Rays, Power
>
>
>
> Over rides this
>
> def GetRays(self, angle, pt):
> """
> """
>
> angle, x, y, Rays, Power = self.Refract(angle, pt[0], pt[1])
> pt1 = (x, y)
>
> return Rays, Power, angle, pt1
>
>
> Thanks

==============================================================================
TOPIC: Installing Scrapy on Mac OS X 10.6
http://groups.google.com/group/comp.lang.python/t/c8b38f00b8c0fd38?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Mar 3 2010 1:22 pm
From: Ned Deily

In article
<9b08574f-0410-45bc-89af-0d3cf7d21819@e7g2000yqf.googlegroups.com>,
Sky Larking <skylarking11@gmail.com> wrote:
> Has anyone successfully installed Scrapy ( http://scrapy.org ) on a
> Mac OS X machine running 10.6.x? The Documentaion says
> Mac OS X ships an libxml2 version too old to be used by Scrapy...But
> doesn't say which version of OS X.. I am wondering if the version of
> libxml2 is also not compatible..

A similar question came up on Stack Overflow recently:

http://stackoverflow.com/questions/2353957/do-i-need-32bit-libxml2-for-py
thon-on-snow-leopard/

--
Ned Deily,
nad@acm.org

==============================================================================

You received this message because you are subscribed to the Google Groups "comp.lang.python"
group.

To post to this group, visit http://groups.google.com/group/comp.lang.python?hl=en

To unsubscribe from this group, send email to comp.lang.python+unsubscribe@googlegroups.com

To change the way you get mail from this group, visit:
http://groups.google.com/group/comp.lang.python/subscribe?hl=en

To report abuse, send email explaining the problem to abuse@googlegroups.com

==============================================================================
Google Groups: http://groups.google.com/?hl=en

twitter

Wednesday, March 3, 2010

comp.lang.python - 26 new messages in 11 topics - digest

0 Comments:

Post a Comment

About Me

Previous Posts