twitter: comp.lang.python - 25 new messages in 10 topics

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

comp.lang.python@googlegroups.com

Today's topics:

==============================================================================
TOPIC: python admin abuse complaint
http://groups.google.com/group/comp.lang.python/t/fbd35c552dc67d77?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Feb 3 2010 11:15 pm
From: Stephen Thorne

On Feb 3, 6:40 am, Xah Lee <xah...@gmail.com> wrote:
> This is a short complaint on adminabuseon #pythonircchannel on
> freenode.net.
>
> Here's a log:
>
> 2010-02-02
>
> (12:11:57 PM) The topic for #pythonis: NO LOL |http://pound-python.org/
> | It's too early to usePython3.x | Pasting > 3 lines? Pastebin:http://paste.pocoo.org/| Tutorial:http://docs.python.org/tut/| FAQ:http://effbot.org/pyfaq/| New Programmer? Readhttp://tinyurl.com/thinkcspy
> | #python.web #wsgi #python-fr #python.de #python-es #python.tw
> #python.pl #python-br #python-jp #python-nl #python-ir #python-
> offtopic
> (12:12:00 PM) _habnabit: pr100, I replaced it with str.startswith,
> actually.
> (12:12:01 PM) jarray52: Jarray
> (12:12:11 PM) _habnabit: jarray52, yes, you are.
> (12:12:16 PM) xahlee: is hash={} and hash.clean() identical?
> (12:12:18 PM) eggy_: OhnoesRaptor: getting sockets (and event loops
> etc) right is quite tricky
> (12:12:21 PM) OhnoesRaptor: I know how to do sockets right eggy, just
> wondering whats up with thepythonverison :D
> (12:12:24 PM) mode (+o dash) by ChanServ
> (12:12:30 PM) You have been kicked by dash: (No.)

G'day,

My name is Stephen Thorne, and my nick on #python is Jerub. dash and I
are both ops on the #python IRC channel.

According to my logs the most recent time I have banned you from
#python was the 16th of June, 2006, when I established that you were
the same troll that posts to this usenet group.

I have no interest in letting you troll #python, and thoroughly
approve of dash's responsible behaviour as a joint custodian of the
#python irc channel. Maintaining a high signal to noise ratio is
difficult, and we appreciate that in this particular case you have
acknowledged that you were made unwelcome in our IRC community and
will endeavour to avoid it in future.

Regards,
Stephen Thorne

==============================================================================
TOPIC: PyChecker under python's virtualenv
http://groups.google.com/group/comp.lang.python/t/d3fa46ebbd2b8295?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Feb 4 2010 12:41 am
From: "Diez B. Roggisch"

Am 04.02.10 01:52, schrieb Steve Holden:
> Diez B. Roggisch wrote:
>> Am 03.02.10 22:46, schrieb soltys:
>>> Hi Everybody,
>>> I've been doing some test on pythons' virtualenv and recently I've
>>> decided to run PyChecker. But I'm having some difficulties with importing
>>> modules available only on virtualenv by pychecker. As if it was
>>> trying to use systemwide python.
>>> I've googled about it, and found nothing in this area.
>>> I installed pychecker using python setup.py install
>>> from virtualenv. I looked at pychecker script - it uses correct python.
>>
>> I doubt that it uses the "correct python", because then you wouldn't
>> have the problems you have.
>>
>> I don't use pychecker, but pylint. And there, the system-wide command
>> uses the system's python - which of course doesn't know anything about
>> virtualenv.
>>
>> There are two solutions to this problem:
>>
>> - install py(lint|checker) into your virtualenv.
>
> See the OP's original assertion:
>
>>> I installed pychecker using python setup.py install
>>> from virtualenv. I looked at pychecker script - it uses correct python.
>
> Isn't that "installing into his virtualenv"?

You are right, it reads like that. I should have read it better.

All I can say is that even a system-wide pylint with my recipe above
gives me no troubles.

Diez

==============================================================================
TOPIC: Dreaming of new generation IDE
http://groups.google.com/group/comp.lang.python/t/e019614ea149e7bd?hl=en
==============================================================================

== 1 of 3 ==
Date: Thurs, Feb 4 2010 12:52 am
From: purui

> This is obvious even in the Python documentation itself where one
> frequently asks oneself "Uhh... so what is parameter X supposed to be...
> a string... a list... ?"
>

That is partially why I created this search engine for python, to see
what parameters other people feed in.
http://nullege.com/

== 2 of 3 ==
Date: Thurs, Feb 4 2010 1:41 am
From: Vladimir Ignatov

> That is partially why I created this search engine for python, to see
> what parameters other people feed in.
> http://nullege.com/

Thank you for excellent effort! I found it very useful and start using
it on almost everyday basis. It's much simple to learn from real live
examples.

Vladimir Ignatov

== 3 of 3 ==
Date: Thurs, Feb 4 2010 2:54 am
From: Vladimir Ignatov

> http://sourceforge.net/mailarchive/message.php?msg_name=9c768dc61001121642t5bd1a7ddmd1fe9e088e1d9ab0@mail.gmail.com

Thanks a lot! That is a great reference (a must read for everybody
interested). Reading just this: "Internally at Google we have a
language-neutral representation shared by all our language analyzers,"
make me jumping ;-) Googlers can't be wrong.

Vladimir Ignatov

==============================================================================
TOPIC: Passing parameters in URL
http://groups.google.com/group/comp.lang.python/t/52695ffb32fef94b?hl=en
==============================================================================

== 1 of 10 ==
Date: Thurs, Feb 4 2010 1:02 am
From: "Diez B. Roggisch"

> I'm not sure what you mean by that. Obviously if users want to record
> their own conversations, then I can't stop them, but that's much
> different than a non-participant in the conversation leaving a recorder
> running 24/7. Is that so hard to understand?

Is it so hard to understand that this is not about laws and rights, but
about technical properties of the HTTP-protocol?

Your web-based chat uses HTTP, no P2P-protocol, and thus the service
provider *can* log conversations. I don't say he should, I don't say I
want that, I don't say there are now laws that prevent them from doing
so, all I say is he *can*.

> I certainly didn't feel that saving or not saving client conversations
> on the server side was up to my discretion. When I found that the
> default server configuration caused conversations to be logged then I
> was appalled.

Then stop logging. Or get a hosting-provider that allows you to
configure it to strip QUERY_STRINGS from log-entries. And if they refuse
to, maybe using POST solves the issue.

But wait, there is

http://www.cyberciti.biz/faq/apache-mod_dumpio-log-post-data/

So what if they run that?

So, for the umpteenth time: data sent over the wire can be recorded.
From the user's POV, your nitpicking of who's the actual culprit - the
IT-guys, or the programmers - is fruitless. You have a nice anecdote
where switching from GET to POST allowed you to trick whoever wasn't
acting to your wishes. Good for you. But John B. and your posts indicate
that using POST is inherently more secure. It *isn't*.

> Do you think the phone company has the right to record all your phone
> calls if they feel like it (absent something like a law enforcement
> investigation)? What about coffee shops that you visit with your
> friends? It is not up to their discretion. They have a positive
> obligation to not do it. If you think they are doing it on purpose
> without your authorization, you should notify the FBI or your
> equivalent, not just "don't use it". If they find they are doing it
> inadvertently, they have to take measures to make it stop. That is the
> situation I found myself in, because of the difference in how servers
> treat GET vs. POST.

If they have a positive obligation not to do it, it doesn't matter if
they run their service over GET or POST.

Again, this is not about laws and what service providers should or must
do. It's about POST vs. GET, and if either of them is more secure or
not. It isn't.

Diez

== 2 of 10 ==
Date: Thurs, Feb 4 2010 1:07 am
From: "Diez B. Roggisch"

Am 04.02.10 01:42, schrieb John Bokma:
> "Diez B. Roggisch"<deets@nospam.web.de> writes:
>
>> Am 03.02.10 19:11, schrieb John Bokma:
>>> Alan Harris-Reid<alan@baselinedata.co.uk> writes:
>>>
>>>> I have a web-page where each row in a grid has edit/delete buttons to
>>>> enable the user to maintain a selected record on another page. The
>>>> buttons are in the form of a link with href='/item_edit?id=123', but
>>>> this string appears in the URL and gives clues as to how to bypass the
>>>> correct sequence of events, and could be risky if they entered the URL
>>>> directly (especially when it comes to deleting records).
>>>
>>> You should *never* use a GET request to do actions like deleting
>>> records. You already are aware of it being risky, so don't do this. You
>>> should use GET for getting information, and POST for modifying information.
>>
>> You should *never* say never, because there might be situations where
>> exceptions from rules are valid. This is one such cases. Making this a
>> post means that you need to resort to javascript to populate& submit
>> a hidden HTML-form. Just for the sake of a POST.
>
> Make each edit/delete button a submit button and optionally style it.

*slap* Yep, you are right, no JS needed. I should have thought about that.

>
>> Also, your claim of it being more risky is simply nonsense. GET is a
>> tiny bit more prone to tinkering by the average user. But calling this
>> less risky is promoting security by obscurity, at most.
>
> Maybe you should think about what happens if someone posts:
> <img src="http://example.com/item_delete?id=123"> to a popular forum...

And the difference to posting

from urrlib2 import open
from urllib import encode

open("http://example.com/item_delete", data=encode([("id", "123")]))

to that same public "hacker" forum is exactly what?

If your webapp happens to allow item_delete to be called without
authentication & authorization, then *that's* your problem.

Diez

== 3 of 10 ==
Date: Thurs, Feb 4 2010 1:23 am
From: "Diez B. Roggisch"

Am 04.02.10 03:52, schrieb Nobody:
> On Wed, 03 Feb 2010 14:09:07 -0800, Paul Rubin wrote:
>
>>> Also, your claim of it being more risky is simply nonsense. GET is a
>>> tiny bit more prone to tinkering by the average user. But calling this
>>> less risky is promoting security by obscurity, at most.
>>
>> GET parameters also tend to get recorded in the http logs of web proxies
>> and web servers while POST parameters usually aren't.
>
> More significantly, they'll appear in the Referer: header for any link the
> user follows from the page, so they're visible to anyone who can get a
> link to their site onto the page (whether<a href=...>,<img src=...> or
> whatever).
>
> Even if this isn't possible at the moment, will you remember to fix it the
> first time you allow an off-site link?
>
> You should assume that anything which goes into a GET request is visible
> to the entire world. Don't put anything even remotely private in there.

You mean like

http://www.google.de/search?q=dirty+buttsex

? Which is the key example for when to use GET - non-modifying queries.

I agree though that you have to be cautious about that, and using POST
makes it easier to do so.

Diez

== 4 of 10 ==
Date: Thurs, Feb 4 2010 2:32 am
From: Bruno Desthuilliers

Alan Harris-Reid a écrit :
> I have a web-page where each row in a grid has edit/delete buttons to
> enable the user to maintain a selected record on another page. The
> buttons are in the form of a link with href='/item_edit?id=123', but
> this string appears in the URL and gives clues as to how to bypass the
> correct sequence of events, and could be risky if they entered the URL
> directly (especially when it comes to deleting records).

Basic HTTP stuff - this is definitely not Python-related.
<OT>
Do yourself (and your users / customers / etc) a favor and read the HTTP
rfc. "GET" requests should NOT modify the server state. At least use
"POST" requests for anything that Create/Update/Delete resources.

For the record, someone once had serious problems with GET requests
deleting records - turned out to be a very bad idea when a robot started
following these links...
</OT>

> Is there another way of passing a record-id to a method

href="/item/23/edit"
href="/item/edit/23"

etc

> a) without it appearing in the URL?
> b) without the user being able to fathom-out how to attach which id to
> which URL?

Wrong solution. The correct solution is to
1/ make correct use of the request method (GET and POST at least).
2/ make sure the user performing the action has the permission to do it.

1/ won't protect your data from malicious users, but will at least avoid
accidental mistakes.

2/ by checking the user's perms when handling the POST request of course
- not by hidding "forbidden" urls.

> As each link contains row-id, I guess there is nothing to stop someone
> from getting the id from the page source-code.

Nor even from trying any other id (brute-force attack).

> Is it safe to use the
> above href method if I test for authorised credentials (user/password
> stored as session variables, perhaps?) before performing the edit/delete
> action?

cf above.

> I am currently using CherryPy 3.2, but I guess the theory could apply to
> any HTTP framework or web app..

Indeed.
</OT>

== 5 of 10 ==
Date: Thurs, Feb 4 2010 2:27 am
From: Paul Rubin

"Diez B. Roggisch" <deets@nospam.web.de> writes:
> Your web-based chat uses HTTP, no P2P-protocol, and thus the service
> provider *can* log conversations. I don't say he should, I don't say I
> want that, I don't say there are now laws that prevent them from doing
> so, all I say is he *can*.

Sure, my complaint is that the default setup caused this to actually
happen so lots of people using that software were recording user
conversations without realizing it and maybe without caring. This
is a bad erosion as I see it.

> Then stop logging. Or get a hosting-provider that allows you to
> configure it to strip QUERY_STRINGS from log-entries. And if they
> refuse to, maybe using POST solves the issue.

I did stop logging. There wasn't an issue with the hosting provider
since I was running the server myself. But I had to resort to some ugly
software kludge to stop logging those particular strings. More
frustratingly, I filed a bug report about the issue against the chat
software but the conversation was sort of like the one you and I are
having now. I just couldn't convince them that there was a problem and
that they should change the default.

> http://www.cyberciti.biz/faq/apache-mod_dumpio-log-post-data/
> So what if they run that?

That sounds like something someone would have to go out of their way to
install and use. It's not the default. Of course if someone is
malicious they can do all sorts of nasty stuff. A coffeeshop that
wanted to mess with me on purpose wouldn't have to do high tech crap
like recording my conversations--they could just poison my coffee. I
have to trust them to not do this on purpose, but then I see a situation
where their coffee sweetener accidentaly has a harmful chemical, so of
course I'd ask them to do something about it.

> So, for the umpteenth time: data sent over the wire can be recorded.

And for the umpteenth time, I'm less concerned about "can be" than "is".
POST isn't logged unless you go to some lengths to have it logged. GET
is logged unless you go to some lengths to prevent it. It's not enough
in a software deployment to only consider what actions are possible.
It's important to make sure that the default actions are the right ones.

> If they have a positive obligation not to do it, it doesn't matter if
> they run their service over GET or POST.

GET makes it harder for them to fulfill their obligations. As a
security nerd, I saw what was happening and took measures against it,
but a more typical operator might never notice or care.

There is also the matter of the referer header which an anon mentioned,
though it didn't apply to this particular situation because of how
the application worked.

== 6 of 10 ==
Date: Thurs, Feb 4 2010 2:32 am
From: Paul Rubin

Bruno Desthuilliers <bruno.42.desthuilliers@websiteburo.invalid> writes:
>> The buttons are in the form of a link with href='/item_edit?id=123',
> ...At least use "POST" requests for anything that Create/Update/Delete
> resources.

There's also the issue that a user can change "123" to "125" and
possibly mess with someone else's resource, unless you use some server
side authentication. Or just seeing how often the numbers change could
reveal patterns about what other users are doing. I always think it's
best to encrypt anything sensitive like that, to avoid leaking any info.

== 7 of 10 ==
Date: Thurs, Feb 4 2010 2:47 am
From: Bruno Desthuilliers

Diez B. Roggisch a �crit :
> Am 03.02.10 19:11, schrieb John Bokma:
>> Alan Harris-Reid<alan@baselinedata.co.uk> writes:
>>
>>> I have a web-page where each row in a grid has edit/delete buttons to
>>> enable the user to maintain a selected record on another page. The
>>> buttons are in the form of a link with href='/item_edit?id=123', but
>>> this string appears in the URL and gives clues as to how to bypass the
>>> correct sequence of events, and could be risky if they entered the URL
>>> directly (especially when it comes to deleting records).
>>
>> You should *never* use a GET request to do actions like deleting
>> records. You already are aware of it being risky, so don't do this. You
>> should use GET for getting information, and POST for modifying
>> information.
>
> You should *never* say never, because there might be situations where
> exceptions from rules are valid. This is one such cases.

Oh yes ?

> Making this a
> post means that you need to resort to javascript to populate & submit a
> hidden HTML-form.

I beg your pardon ???? This is total nonsense. Hopefully you don't need
any js to emit a post request from a browser ! The only thing you need
to do is to use a form and submit input instead.

== 8 of 10 ==
Date: Thurs, Feb 4 2010 2:52 am
From: Bruno Desthuilliers

Paul Rubin a �crit :
> Bruno Desthuilliers <bruno.42.desthuilliers@websiteburo.invalid> writes:
>>> The buttons are in the form of a link with href='/item_edit?id=123',
>> ...At least use "POST" requests for anything that Create/Update/Delete
>> resources.
>
> There's also the issue that a user can change "123" to "125" and
> possibly mess with someone else's resource,
> unless you use some server
> side authentication.

What I said IIRC.

> Or just seeing how often the numbers change could
> reveal patterns about what other users are doing. I always think it's
> best to encrypt anything sensitive like that, to avoid leaking any info.

Depends on how "sensitive" it really is.

== 9 of 10 ==
Date: Thurs, Feb 4 2010 2:53 am
From: Bruno Desthuilliers

Bruno Desthuilliers a �crit :
> Diez B. Roggisch a �crit :
(snip)
>> Making this a post means that you need to resort to javascript to
>> populate & submit a hidden HTML-form.
>
> I beg your pardon ???? This is total nonsense.

Sorry, posted too fast, John alredy adressed this.

== 10 of 10 ==
Date: Thurs, Feb 4 2010 4:14 am
From: Steve Holden

Paul Rubin wrote:
> "Diez B. Roggisch" <deets@nospam.web.de> writes:
>>> But it would be outrageous for the shop owner to record the
>>> conversations of patrons.
>> Which is the exact thing that happens when you use an email-provider
>> with IMAP. Or google wave. Or groups. Or facebook. Or twitter. Which I
>> wouldn't call outrageous.
>
> Those are not comparable. IMAP is a storage service, and groups,
> facebook, and twitter are publishing systems (ok, I've never understood
> quite what Google Wave is). Yes, by definition, your voice mail
> provider (like IMAP) has to save recordings of messages people leave
> you, but that's a heck of a lot different than your phone carrier
> recording your real-time conversations. Recording live phone
> conversations by a third party is called a "wiretap" and doing it
> without suitable authorization can get you in a heck of a lot of
> trouble.
>
Unless you happen to be following the illegal instructions of the
President of the United States, in which case Congress will
retro-actively alter the law to void your offenses and provide you with
legal immunity for your wrong-doing. Assuming you are a large telephone
company and not a private individual.

>> This discussion moves away from the original question: is there
>> anything inherently less secure when using GET vs. POST. There isn't.
>
> Well, the extra logging of GET parameters is not inherent to the
> protocol, but it's an accidental side effect that server ops may have to
> watch out for.
>
>> Users can forge both kind of requests easy enough, whoever sits in the
>> middle can access both,
>
> I'm not sure what you mean by that. Obviously if users want to record
> their own conversations, then I can't stop them, but that's much
> different than a non-participant in the conversation leaving a recorder
> running 24/7. Is that so hard to understand?
>
> Interception from the middle is addressed by SSL, though that relies on
> the PKI certificate infrastructure, which while somewhat dubious, is
> better than nothing.
>
>> and it's at the discretion of the service provider to only save what
>> it needs to. If you don't trust it, don't use it.
>
> I certainly didn't feel that saving or not saving client conversations
> on the server side was up to my discretion. When I found that the
> default server configuration caused conversations to be logged then I
> was appalled.
>
> Do you think the phone company has the right to record all your phone
> calls if they feel like it (absent something like a law enforcement
> investigation)? What about coffee shops that you visit with your
> friends? It is not up to their discretion. They have a positive
> obligation to not do it. If you think they are doing it on purpose
> without your authorization, you should notify the FBI or your
> equivalent, not just "don't use it". If they find they are doing it
> inadvertently, they have to take measures to make it stop. That is the
> situation I found myself in, because of the difference in how servers
> treat GET vs. POST.

A lot will depend on the terms of service of the network supply
contract. Most vendors take pains to ensure that such "innocent" logging
(i.e. the maintenance by their servers of logging information, which may
under subpoena or similar legal coercion be given up to law enforcement
authorities as "business records") is permitted. If you have signed the
contract, then they have the right to log that data.

Caveat emptor.

regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
PyCon is coming! Atlanta, Feb 2010 http://us.pycon.org/
Holden Web LLC http://www.holdenweb.com/
UPCOMING EVENTS: http://holdenweb.eventbrite.com/

==============================================================================
TOPIC: How to guard against bugs like this one?
http://groups.google.com/group/comp.lang.python/t/fe6430e7980e2a96?hl=en
==============================================================================

== 1 of 2 ==
Date: Wed, Feb 3 2010 8:33 am
From: Tim Golden

On 03/02/2010 16:17, kj wrote:
> Boy, that was dumb of me. The above apology was meant for Stephen
> Hansen, not Steve Holden. I guess this is now a meta-apology...
> (Sheesh.)

You see? That's what I like about the Python community:
people even apologise for apologising :)

TJG

== 2 of 2 ==
Date: Thurs, Feb 4 2010 4:04 am
From: Steve Holden

Tim Golden wrote:
> On 03/02/2010 16:17, kj wrote:
>> Boy, that was dumb of me. The above apology was meant for Stephen
>> Hansen, not Steve Holden. I guess this is now a meta-apology...
>> (Sheesh.)
>
> You see? That's what I like about the Python community:
> people even apologise for apologising :)
>
QOTW?

==============================================================================
TOPIC: Overcoming python performance penalty for multicore CPU
http://groups.google.com/group/comp.lang.python/t/586ef2d3685fa7ea?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Feb 4 2010 3:13 am
From: Anh Hai Trinh

On Feb 4, 10:46 am, John Nagle <na...@animats.com> wrote:
>
> There's enough intercommunication between the threads working on
> a single site that it's a pain to do them as subprocesses. And I
> definitely don't want to launch subprocesses for each page; the
> Python load time would be worse than the actual work. The
> subprocess module assumes you're willing to launch a subprocess
> for each transaction.

You could perhaps use a process pool inside each domain worker to work
on the pages? There is multiprocessing.Pool and other
implementations.

For examples, in this library, you can s/ThreadPool/ProcessPool/g and
this example would work: <http://www.onideas.ws/stream.py/#retrieving-
web-pages-concurrently>.

If you want to DIY, with multiprocessing.Lock/Pipe/Queue, I don't
understand why it would be more of a pain to write your threads as
processes.

// aht
http://blog.onideas.ws

==============================================================================
TOPIC: Building a multiline string
http://groups.google.com/group/comp.lang.python/t/cb131609c7b065a9?hl=en
==============================================================================

== 1 of 3 ==
Date: Thurs, Feb 4 2010 3:34 am
From: lallous

Hello

Maybe that's already documented, but it seems the parser accepts to
build a long string w/o really using the first method:

# Method1
x = "line1" + \ # cannot use comments!
"line2"+ \
"line3"

and instead using a list with one element like this:

# Method2
x = [
"line1" # can use comments
"line2"
"line3"
][0]

Or:
# Method3
x = (
"line1" # can use comments
"line2"
"line3"
)

(Not that I don't want new lines in the strings)

Now should I be using method 2 or 3 in production code?

--
Elias

== 2 of 3 ==
Date: Thurs, Feb 4 2010 4:09 am
From: Ulrich Eckhardt

Just for the record: Neither of the below methods actually produce a
multiline string. They only spread a string containing one line over
multiple lines of source code.

lallous wrote:
> Maybe that's already documented, but it seems the parser accepts to
> build a long string w/o really using the first method:
>
> # Method1
> x = "line1" + \ # cannot use comments!
> "line2"+ \
> "line3"

Well, obviously you can't use comments like that there. The point of the
backslash is that it continues the current logical line over the
_immediately_ _following_ newline. If anything follows, that obviously
doesn't work.

> and instead using a list with one element like this:
>
> # Method2
> x = [
> "line1" # can use comments
> "line2"
> "line3"
> ][0]

This basically makes use of the fact that "this" "is" "one" "string" and not
four strings.

> # Method3
> x = (
> "line1" # can use comments
> "line2"
> "line3"
> )

This uses the same, only that this time it uses brackets which cause an
expression to extend to multiple lines.

> (Not that I don't want new lines in the strings)

You don't not want or you don't want newlines? Depending on that, you could
also do this:

# method 4
x = "line1"\
"line2"\
"line3"

or maybe

# method 5
x = """line1
line2
line3
"""

> Now should I be using method 2 or 3 in production code?

I'd go for 3 or 4. 2 is basically a hack (you could do the same with a
dictionary, or a tuple, not only a list). 1 will actually create strings
and then concatenate them (unless Python is smart enough to optimize that),
but it allows adding expressions in the middle.

Uli

--
Sator Laser GmbH
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932

== 3 of 3 ==
Date: Thurs, Feb 4 2010 4:31 am
From: Steve Holden

lallous wrote:
> Hello
>
> Maybe that's already documented, but it seems the parser accepts to
> build a long string w/o really using the first method:
>
> # Method1
> x = "line1" + \ # cannot use comments!
> "line2"+ \
> "line3"
>
> and instead using a list with one element like this:
>
> # Method2
> x = [
> "line1" # can use comments
> "line2"
> "line3"
> ][0]
>
> Or:
> # Method3
> x = (
> "line1" # can use comments
> "line2"
> "line3"
> )
>
> (Not that I don't want new lines in the strings)
>
> Now should I be using method 2 or 3 in production code?
>
I should have thought it was pretty obvious that method 2 creates a list
and then performs an indexing operation on it. These are completely
unnecessary operations, which are avoided in method 3 which is a simple
parenthesised expression.

So why anyone would want to adopt method 2, which is also mess clear as
source code, is beyond me.

==============================================================================
TOPIC: Common area of circles
http://groups.google.com/group/comp.lang.python/t/8cf2115734d16002?hl=en
==============================================================================

== 1 of 2 ==
Date: Thurs, Feb 4 2010 3:41 am
From: Chris Rebert

On Thu, Feb 4, 2010 at 2:39 AM, Shashwat Anand <anand.shashwat@gmail.com> wrote:
> Given 'n' circles and the co-ordinates of their center, and the radius of
> all being equal i.e. 'one', How can I take out the intersection of their
> area.

How is this at all specific to Python?

This also sounds suspiciously like homework, which you should know
this list is unlikely to give direct answers to, though you might be
able to get a few pointers or some general suggestions.

Cheers,
Chris
--
Back to toiling away on CSE 105 HW#3
http://blog.rebertia.com

== 2 of 2 ==
Date: Thurs, Feb 4 2010 4:19 am
From: Bearophile

Shashwat Anand:
> > Given 'n' circles and the co-ordinates of their center, and the radius of
> > all being equal i.e. 'one', How can I take out the intersection of their
> > area.

I can see two possible solutions, both approximate. In both solutions
you first look if there are a pair of circles that don't intersect, in
this case the intersect area is zero. You also remove all circles
fully contained in another circle.

The first strategy is easy to do, but it probably leads to a lower
precision. Then you can sample randomly many times the rectangular
area that surely contains all circles. You count how many of those
random points are inside all circles. This gives you an approximate
area of their intersection. Increasing the points numbers slowly
increases the result precision.

The second strategy is more complex. You convert your circles into
polygons with a fixed number of vertices (like 50 or 100 or 1000 or
more. This number is constant even if the circles don't have all the
same radius). So you can turn this circle into a simple mesh of
triangles (all vertices are on the circumference). Then you "subtract"
the second polygonalized circle, this can create a hole and split
triangles in pieces, and so on with successive circles. At the end you
can compute the total area of the triangles left. This is doable, but
you need time to do implement this. The advantage is that the
numerical precision of the result is probably higher. If you implement
this second solution you can implement the first one too, and use it
as a test to avoid bugs. Visualizing the triangles with Pygame or
MatPlotLib can be useful to look for bugs.

Bye,
bearophile

==============================================================================
TOPIC: read a process output with subprocess.Popen
http://groups.google.com/group/comp.lang.python/t/ff58d1f8efb0bd23?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Feb 4 2010 4:28 am
From: Ashok Prabhu

Hi,

I m trying a read the output of a process which is running
continuously with subprocess.Popen. However the readline() method
hangs for the process to finish. Please let me know if the following
code can be made to work with subprocess.Popen with threads or queues.
I tried a lot of methods but to no avail. It would be great if someone
can make it work.

import subprocess

p1 = subprocess.Popen('tail -f /var/log/
messages',stdout=subprocess.PIPE,shell=True)
p2 = subprocess.Popen('grep
something',stdin=p1.stdout,stdout=subprocess.PIPE,shell=True)

while 1:
line = p2.stdout.readline()
print line

Thanks,
~Ashok.

==============================================================================
TOPIC: Python and Ruby
http://groups.google.com/group/comp.lang.python/t/dfe4f6c60032755e?hl=en
==============================================================================

== 1 of 1 ==
Date: Thurs, Feb 4 2010 4:28 am
From: Marius Gedminas

On Feb 4, 1:03 am, John Bokma <j...@castleamber.com> wrote:
> Jonathan Gardner <jgard...@jonathangardner.net> writes:
> > I can explain all of Python in an hour;
>
> OK, in that case I would say give it a go. Put it on YouTube, or write a
> blog post about it (or post it here). I am sure you will help a lot of
> people that way.

Someone already did: "Advanced Python or Understanding Python"
http://video.google.com/videoplay?docid=7760178035196894549
(76 minutes).

Worth watching.

Regards,
--
Marius Gedminas

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

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

Thursday, February 4, 2010

comp.lang.python - 25 new messages in 10 topics - digest

0 Comments:

Post a Comment

About Me

Previous Posts