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

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

comp.lang.python@googlegroups.com

Today's topics:

* Striving for PEP-8 compliance - 5 messages, 4 authors
http://groups.google.com/group/comp.lang.python/t/08f3e64e10fdf47e?hl=en
* Preserving logging streams through a daemon.DaemonContext switch - 1
messages, 1 author
http://groups.google.com/group/comp.lang.python/t/89daec0325dde0d2?hl=en
* raise exception with fake filename and linenumber - 1 messages, 1 author
http://groups.google.com/group/comp.lang.python/t/187e8a1d660e5a25?hl=en
* urllib2: post request to textarea - 1 messages, 1 author
http://groups.google.com/group/comp.lang.python/t/57614f8404451575?hl=en
* Performance of list vs. set equality operations - 1 messages, 1 author
http://groups.google.com/group/comp.lang.python/t/818d143c7e9550bc?hl=en
* Python Line Intersection - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.python/t/d413d2531f81ff97?hl=en

==============================================================================
TOPIC: Striving for PEP-8 compliance
http://groups.google.com/group/comp.lang.python/t/08f3e64e10fdf47e?hl=en
==============================================================================

== 1 of 5 ==
Date: Fri, Apr 9 2010 5:36 pm
From: Grant Edwards

On 2010-04-09, Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> wrote:
> In message <4bbf6eb8$0$1670$742ec2ed@news.sonic.net>, John Nagle wrote:
>
>> Lawrence D'Oliveiro wrote:
>>
>>> In message <mailman.1610.1270655932.23598.python-list@python.org>,
>>> Gabriel Genellina wrote:
>>>
>>>> If you only reindent the code (without adding/removing lines) then you
>>>> can compare the compiled .pyc files (excluding the first 8 bytes that
>>>> contain a magic number and the source file timestamp). Remember that
>>>> code objects contain line number information.
>>>
>>> Anybody who ever creates another indentation-controlled language should
>>> be beaten to death with a Guido van Rossum voodoo doll.
>>
>> No ...
>
> Yes, because otherwise you wouldn?t have stupid problems like the one
> which is preoccupying this thread: how to make sure indentation is
> consistent without introducing logic errors into the code.

Anybody who invents another brace-delimited language should be beaten.
You always end up with a big problem trying to make sure the braces
are consistent with the program logic.

--
Grant

== 2 of 5 ==
Date: Fri, Apr 9 2010 5:51 pm
From: Lawrence D'Oliveiro

In message <hpoh5j$35j$1@reader1.panix.com>, Grant Edwards wrote:

> Anybody who invents another brace-delimited language should be beaten.
> You always end up with a big problem trying to make sure the braces
> are consistent with the program logic.

Would you prefer "begin" and "end" word symbols, then?

== 3 of 5 ==
Date: Fri, Apr 9 2010 6:31 pm
From: Grant Edwards

On 2010-04-10, Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> wrote:
> In message <hpoh5j$35j$1@reader1.panix.com>, Grant Edwards wrote:
>
>> Anybody who invents another brace-delimited language should be beaten.
>> You always end up with a big problem trying to make sure the braces
>> are consistent with the program logic.

> Would you prefer ???begin??? and ???end??? word symbols, then?

Nope, I categorize those as nothing more than verbose "braces".

--
Grant

== 4 of 5 ==
Date: Fri, Apr 9 2010 6:57 pm
From: Patrick Maupin

On Apr 9, 5:31 pm, Lawrence D'Oliveiro <l...@geek-
central.gen.new_zealand> wrote:
> >> Anybody who ever creates another indentation-controlled language should
> >> be beaten to death with a Guido van Rossum voodoo doll.
>
> >     No ...
>
> Yes, because otherwise you wouldn't have stupid problems like the one which
> is preoccupying this thread: how to make sure indentation is consistent
> without introducing logic errors into the code.

You go through life and you choose your stupid problems. Well, not
really, but you make your choices, and you wind up with stupid
problems. I use Linux, and have a different set of stupid problems
than I did when I used Windows.

But as Ian Bicking said:

I think there is a meme that Python people are close-minded to
suggestions for changes in the language. I think there is significant
truth to that. But sometimes everyone else is just completely wrong. I
want nothing to do with any programmer who would mis-indent their
code. If you want to mis-indent your code you are an idiot. If you
want idiotic code to be an option you are being absurd.

And as paraphrased by Markos Gaivo ( http://markos.gaivo.net/blog/?p=126
):

A: I don't like Python because of significant whitespace.
B: Do you indent your code?
A: Yes, of course.
B: And the problem is?

Regards,
Pat

== 5 of 5 ==
Date: Fri, Apr 9 2010 7:51 pm
From: Steven D'Aprano

On Sat, 10 Apr 2010 10:31:58 +1200, Lawrence D'Oliveiro wrote:

> In message <4bbf6eb8$0$1670$742ec2ed@news.sonic.net>, John Nagle wrote:
>
>> Lawrence D'Oliveiro wrote:
>>
>>> In message <mailman.1610.1270655932.23598.python-list@python.org>,
>>> Gabriel Genellina wrote:
>>>
>>>> If you only reindent the code (without adding/removing lines) then
>>>> you can compare the compiled .pyc files (excluding the first 8 bytes
>>>> that contain a magic number and the source file timestamp). Remember
>>>> that code objects contain line number information.
>>>
>>> Anybody who ever creates another indentation-controlled language
>>> should be beaten to death with a Guido van Rossum voodoo doll.
>>
>> No ...
>
> Yes, because otherwise you wouldn't have stupid problems like the one
> which is preoccupying this thread: how to make sure indentation is
> consistent without introducing logic errors into the code.

I don't see the problem here.

The OP has code which is already correctly indented. He wants to re-
indent it, from two spaces to four. As I see it, even a simple-minded
string replacement from 2 to 4 spaces should Just Work, provided you
don't care about extra spacing potentially being introduced into strings,
comments, etc.

E.g. if you have this (already ugly) code:

def f(a):
x = 42
if a < 0:
return a # Return a untouched.
else:
for i in range( x ) : # Do pointless work
pass
this_is_a_very_long_line = ( 2, 4, 5,
7, 9 )
return a+1

and just do a simple string replacement, you get this:

def f(a):
x = 42
if a < 0:
return a # Return a untouched.
else:
for i in range( x ) : # Do pointless work
pass
this_is_a_very_long_line = ( 2, 4, 5,
7, 9 )
return a+1

which is still ugly, but continues to work correctly. The only way to
break working code by re-indenting in such a simple-minded fashion is if
the layout of string literals is significant.

But of course no professional-quality re-indenter program would just do a
simple-minded replace(' ', ' ') on the source code, any more than a
professional-quality code beautifier for a brace language would just add
newlines and spaces around every brace it saw.

A less simple-minded re-indenter would only replace *indentation*, not
random whitespace. In that case, how could it break anything? Since the
indents are correct, you are mapping indents of 2, 4, 6, 8, ... spaces to
4, 8, 12, 16, .... What do you think will break?

If you start with broken indentation, it is difficult to fix, but that's
not the OP's problem. In a brace language (whether you spell them { } or
BEGIN END or START-BLOCK-HERE and END-BLOCK-HERE) if you start with
inconsistent braces, it is equally difficult to fix. Invalid code is
invalid code no matter what language you are using, and in general can't
be mechanically fixed. If the nature of the breakage is such that the
code is inconsistent or ambiguous, you need to *read* and *understand* it
to fix it, no matter whether you have braces or indents.

--
Steven

==============================================================================
TOPIC: Preserving logging streams through a daemon.DaemonContext switch
http://groups.google.com/group/comp.lang.python/t/89daec0325dde0d2?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Apr 9 2010 6:09 pm
From: Ben Finney

Vinay Sajip <vinay_sajip@yahoo.co.uk> writes:

> On Apr 9, 12:46 am, Ben Finney <ben+pyt...@benfinney.id.au> wrote:
> > Not quite. As the docs specify, you need to pass the *file
> > descriptors* for the files you want preserved.
>
> Okay, but the docstring you quoted:
>
> "Elements of the list are file descriptors (as returned by a file
> object's `fileno()` method) or Python `file` objects."
>
> implies that fh.stream would work as well as fh.stream.fileno()

You're quite right, I made a mistake in what I wrote above.

Rebelo <puntabluda@gmail.com> writes:

> Ben Finney wrote:
> > So how do we get the file object for a logging handler? The
> > 'logging' module documentation doesn't mention any way to get at the
> > stream object for the handlers.
> >
> > But looking at the source code for 'StreamHandler' on my system,
> > '/usr/lib/python2.5/logging/__init__.py', shows a 'stream' attribute
> > that is bound to the stream object. It's not marked private (i.e.
> > it's not named with a leading underscore), so one presumes it is
> > part of the public API.

[…]

> >
> > lh = logging.handlers.TimedRotatingFileHandler(
> > LOG_FILENAME,
> > # …
> > )
> > log_stream_descriptor = lh.stream.fileno()
> >
> > daemon_context.files_preserve = [log_stream_descriptor]
> >

The above can then be simplified as:

lh = logging.handlers.TimedRotatingFileHandler(
LOG_FILENAME,
# …
)

daemon_context.files_preserve = [lh.stream]

> thank you both for a detailed explanation.

I hope this helps you to make better use of 'python-daemon', and thank
you for raising questions here.

This is a good addition for the Frequently Asked Questions document; I
will do this and it will be available in the next version of the
library.

--
\ "I prayed for twenty years but received no answer until I |
`\ prayed with my legs." —Frederick Douglass, escaped slave |
_o__) |
Ben Finney

==============================================================================
TOPIC: raise exception with fake filename and linenumber
http://groups.google.com/group/comp.lang.python/t/187e8a1d660e5a25?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Apr 9 2010 7:19 pm
From: kwatch

On 4月8日, 午後12:52, "Gabriel Genellina" <gagsl-...@yahoo.com.ar> wrote:
>
> The built-in SyntaxError exception does what you want. Constructor  
> parameters are undocumented, but they're as follows:
>
>     raise SyntaxError("A descriptive error message", (filename, linenum,  
> colnum, source_line))
>
> colnum is used to place the ^ symbol (10 in this fake example). Output:
>
> Traceback (most recent call last):
>    File "1.py", line 9, in <module>
>      foo()
>    File "1.py", line 7, in foo
>      raise SyntaxError("A descriptive error message", (filename, linenum,  
> colnum, "this is line 123 in example.file"))
>    File "example.file", line 123
>      this is line 123 in example.file
>               ^
> SyntaxError: A descriptive error message
>
> --
> Gabriel Genellina

Thank you Gabriel,
this is great help for me.

By the way, is it hard to specify any other exception class instead of
SyntaxError?
The SyntaxError class is a good solution in my case, but if possible,
I want to know
more general solution to specify filename and linenum for exception.

--
makoto

==============================================================================
TOPIC: urllib2: post request to textarea
http://groups.google.com/group/comp.lang.python/t/57614f8404451575?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Apr 9 2010 9:36 pm
From: Tim Roberts

bfrederi <brfredericks@gmail.com> wrote:
>
>I'm getting a 500 error when attempting to make a post request with
>urllib2 to a form with a <textarea> tag. When I create the post
>request with all the other post data, I don't get a 500. Just the part
>of the form that is a <textarea>. Is this just a coincidence, and my
>real problem is something else?

It's just a coincidence. The contents of a <textarea> are transmitted
exactly like the contents of an <input type=text>. My guess is that you
did the encoding improperly.
--
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

==============================================================================
TOPIC: Performance of list vs. set equality operations
http://groups.google.com/group/comp.lang.python/t/818d143c7e9550bc?hl=en
==============================================================================

== 1 of 1 ==
Date: Fri, Apr 9 2010 10:46 pm
From: Raymond Hettinger

> > I don't know if it's a good "fix" anyway.  If you subclass an internal
> > type, you can certainly supply your own rich comparison methods, which
> > would (IMO) put the CPU computation burden where it belongs if you
> > decide to do something goofy like subclass a list and then override
> > __len__.
>
> We're all consenting adults, that's the Python philosophy, isn't it?
> If I decide to make stupid things, it's my fault. I don't see why Python  
> should have to prevent that.

Perhaps so for pure python classes, but the C builtins are another
story.

The C containers directly reference underlying structure and methods
for several reasons. The foremost reason is that if their internal
invariants are violated, they can segfault. A list's __getitem__
method needs to know the real length (not what you report in __len__)
if it is to avoid writing objects outside of its allocated memory
range. Another reason is efficiency -- the cost of attribute lookups
is high and would spoil the performance of the builtins if they could
not access their underlying structure and friend methods directly.
It is important to have those perform well because they are used
heavily
in everyday programming.

There are also couple of OOP design considerations. The
http://en.wikipedia.org/wiki/Open/closed_principle is one example.

Encapsulation is another example. If you override __len__
in order to influence the behavior of __eq__, then you're
relying on an implementation detail, not the published interface.
Eventhough the length check is an obvious optimization
for list equality and set equality, there is no guarantee
that other implementations of Python use that same pattern.

my-two-cents-ly yours,

Raymond

==============================================================================
TOPIC: Python Line Intersection
http://groups.google.com/group/comp.lang.python/t/d413d2531f81ff97?hl=en
==============================================================================

== 1 of 2 ==
Date: Fri, Apr 9 2010 11:24 pm
From: "Mark Tolonen"

"Chris Rebert" <clp2@rebertia.com> wrote in message
news:y2o50697b2c1004091304u627d99bfj44ad56fa76a3cc15@mail.gmail.com...
> On Fri, Apr 9, 2010 at 11:43 AM, John Nagle <nagle@animats.com> wrote:
>> Chris Rebert wrote:
>>> On Fri, Apr 9, 2010 at 8:04 AM, Peyman Askari
>>> <peter_peyman_puk@yahoo.ca>
>>> wrote:
>>>>
>>>> Hello
>>>>
>>>> This is partly Python related, although it might end up being more math
>>>> related.
>>>>
>>>> I am using PyGTK (GUI builder for Python) and I need to find the
>>>> intersection point for two lines. It is easy to do, even if you only
>>>> have
>>>> the four points describing line segments
>>>> (http://www.maths.abdn.ac.uk/~igc/tch/eg1006/notes/node23.html).
>>>> However, it
>>>> requires that you solve for two equations. How can I do this in Python,
>>>> either solve equations, or calculating intersection points some other
>>>> way?
>>>
>>> Just solve the equations ahead of time by using generic ones.
> <snip>
>>> x = (c - b) / (m-n)
>>
>> Actually, you don't want to do it that way, because it fails for vertical
>> lines, when m and n go to infinity.
>
> As the programmer said upon seeing a stripe-less zebra:
> "Oh no, a special case!"
>
> Excellent catch my good sir; although I will point out that strictly
> speaking, you can't put vertical lines into slope-intercept form (but
> I should not have forgotten that precondition).

And parallel lines, where m and n are equal (divide-by-zero)...

-Mark

== 2 of 2 ==
Date: Sat, Apr 10 2010 12:44 am
From: Lie Ryan

On 04/10/10 16:24, Mark Tolonen wrote:
>
> "Chris Rebert" <clp2@rebertia.com> wrote in message
> news:y2o50697b2c1004091304u627d99bfj44ad56fa76a3cc15@mail.gmail.com...
>> On Fri, Apr 9, 2010 at 11:43 AM, John Nagle <nagle@animats.com> wrote:
>>> Chris Rebert wrote:
>>>> On Fri, Apr 9, 2010 at 8:04 AM, Peyman Askari
>>>> <peter_peyman_puk@yahoo.ca>
>>>> wrote:
>>>>>
>>>>> Hello
>>>>>
>>>>> This is partly Python related, although it might end up being more
>>>>> math
>>>>> related.
>>>>>
>>>>> I am using PyGTK (GUI builder for Python) and I need to find the
>>>>> intersection point for two lines. It is easy to do, even if you
>>>>> only have
>>>>> the four points describing line segments
>>>>> (http://www.maths.abdn.ac.uk/~igc/tch/eg1006/notes/node23.html).
>>>>> However, it
>>>>> requires that you solve for two equations. How can I do this in
>>>>> Python,
>>>>> either solve equations, or calculating intersection points some
>>>>> other way?
>>>>
>>>> Just solve the equations ahead of time by using generic ones.
>> <snip>
>>>> x = (c - b) / (m-n)
>>>
>>> Actually, you don't want to do it that way, because it fails for
>>> vertical
>>> lines, when m and n go to infinity.
>>
>> As the programmer said upon seeing a stripe-less zebra:
>> "Oh no, a special case!"
>>
>> Excellent catch my good sir; although I will point out that strictly
>> speaking, you can't put vertical lines into slope-intercept form (but
>> I should not have forgotten that precondition).
>
> And parallel lines, where m and n are equal (divide-by-zero)...

This is actually one place where non-stop arithmetic can be a good thing.

With non-stop arithmetic, when you divide by zero, you get infinity and
everything turns out quite well.

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

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