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: Passing parameters in URL
http://groups.google.com/group/comp.lang.python/t/52695ffb32fef94b?hl=en
==============================================================================

== 1 of 6 ==
Date: Wed, Feb 3 2010 2:35 pm
From: Paul Rubin

"Diez B. Roggisch" <deets@nospam.web.de> writes:
> If somebody happens to have access to a proxy & it's logs, he can as
> well log the request body.

I'm not talking about a malicious server operator. In this situation, I
was the server operator and I didn't want to be recording the
conversations. I had to go out of my way to stop the recording. SSL
doesn't help and in fact I was using it, but web server logging happens
after the SSL layer. I suppose SSL would help against a malicious
proxy.

Many people back in those days (before AJAX became a buzzword du jour)
wanted to do encryption on the client in java or javascript, but that
was almost unworkably kludgy, and SSL was the only approach that made
any sense. It might be easier now that the javascript API's are richer
and the interpreters are faster.

== 2 of 6 ==
Date: Wed, Feb 3 2010 3:26 pm
From: "Diez B. Roggisch"

Am 03.02.10 23:35, schrieb Paul Rubin:
> "Diez B. Roggisch"<deets@nospam.web.de> writes:
>> If somebody happens to have access to a proxy& it's logs, he can as
>> well log the request body.
>
> I'm not talking about a malicious server operator. In this situation, I
> was the server operator and I didn't want to be recording the
> conversations. I had to go out of my way to stop the recording. SSL
> doesn't help and in fact I was using it, but web server logging happens
> after the SSL layer. I suppose SSL would help against a malicious
> proxy.

Well, we actually implemented POST-parameter logging (inside the
WSGI-app), because we *want* all parameters users pass. They end up in
the application anyway, and aid debugging. Of course we blind sensitive
parameters such as passwords & creditcard numbers.

Of course only information not gathered is really safe information. But
every operation that has side-effects is reproducable anyway, and if
e.g. your chat-app has a history, you can as well log the parameters.

Diez

== 3 of 6 ==
Date: Wed, Feb 3 2010 3:39 pm
From: Paul Rubin

"Diez B. Roggisch" <deets@nospam.web.de> writes:
> Of course only information not gathered is really safe
> information. But every operation that has side-effects is reproducable
> anyway, and if e.g. your chat-app has a history, you can as well log
> the parameters.

No I can't. The chat-app history would be on the client, not the
server, so I'd have no access to it. Put another way: as server
operator, I'm like the owner of a coffee shop. I can't stop patrons
from recording their own conversations with each other, and it's not
even really my business whether they do that. But it would be
outrageous for the shop owner to record the conversations of patrons.

== 4 of 6 ==
Date: Wed, Feb 3 2010 4:09 pm
From: "Diez B. Roggisch"

Am 04.02.10 00:39, schrieb Paul Rubin:
> "Diez B. Roggisch"<deets@nospam.web.de> writes:
>> Of course only information not gathered is really safe
>> information. But every operation that has side-effects is reproducable
>> anyway, and if e.g. your chat-app has a history, you can as well log
>> the parameters.
>
> No I can't. The chat-app history would be on the client, not the
> server, so I'd have no access to it. Put another way: as server
> operator, I'm like the owner of a coffee shop. I can't stop patrons
> from recording their own conversations with each other, and it's not
> even really my business whether they do that. 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.

This discussion moves away from the original question: is there anything
inherently less secure when using GET vs. POST. There isn't.

Users can forge both kind of requests easy enough, whoever sits in the
middle can access both, 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.

Diez

== 5 of 6 ==
Date: Wed, Feb 3 2010 4:35 pm
From: Paul Rubin

"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.

> 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.

== 6 of 6 ==
Date: Wed, Feb 3 2010 4:42 pm
From: 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.

> 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...

--
John Bokma j3b

Hacking & Hiking in Mexico - http://johnbokma.com/
http://castleamber.com/ - Perl & Python Development

==============================================================================
TOPIC: equivalent of Ruby's Pathname?
http://groups.google.com/group/comp.lang.python/t/f580fb3763208425?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Feb 3 2010 2:47 pm
From: Phlip

Pythonistas:

Yes, calling os.path.walk() and os.path.join() all the time on raw
strings is fun, but I seem to recall from my Ruby days a class called
Pathname, which presented an object that behaved like a string at
need, and like a filesystem path at need. path + 'folder' would
call .join() and insert the / correctly, for example.

What's the best equivalent in Python-land?

--
Phlip

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

== 1 of 5 ==
Date: Wed, Feb 3 2010 2:54 pm
From: Lou Pecora

In article
<1944d953-25ad-440b-9317-a7a4b4de6dac@f17g2000prh.googlegroups.com>,
Jonathan Gardner <jgardner@jonathangardner.net> wrote:

>
> I can explain all of Python in an hour; I doubt anyone will understand
> all of Python in an hour.
>
> Coming from perl to python, the big "aha!" moment was when I realized
> there wasn't anything more than what I saw before me. I kept expecting
> something big around the corner, kind of like when I first discovered
> refs in perl, or when I realized how hard it truly was to write OO
> code in perl that actually does what you think it should do.
>
> Perl has trained me to be fearful of the language, constantly on the
> lookout for jabberwockies. If you fall into one of those traps in
> perl, it's because you weren't smart enough and aren't worthy of the
> language, or so they say. It's never perl's fault. I mean, doesn't
> everyone know what the Schwartzian Transform is?
>
> Python is the complete opposite. Go through http://docs.python.org/reference/
> . Once you've familiarized yourself with all the operators,
> statements, and the special methods, you're done with syntax and the
> core language. There is no more.
>
> The next step is to learn the basic objects and functions in builtins.
> That's in the first seven chapters of
> http://docs.python.org/library/index.html.
> You can always fall back to the "help" function to remind yourself if
> you forget. I do it all the time.
>
> After that, it's merely figuring out which standard libraries do what
> and how. The documentation there is complete and awesome, and there
> are more than enough people willing to point you in the right
> direction here.
>
> There are no dragons in this forest. Heck, this isn't even a forest---
> it's a single-room apartment with everything you need right there
> where you can see it. The thermostat is set to room temperature, and
> no matter what happens outside, you're safe and protected from it all.

That's a pretty accurate description of how I transitioned to Python
from C and Fortran. I kept trying to think of how to output data and
parameter variables of different types to files for later reading in.
How to format them all consistently and then get them back in with the
exact same accuracy. I was stuck in printf and scanf land. Then after
much noodling around and reading it hit me that I could just put all
that output of different types of variables into a list, hit it with a
repr() function to get a string version, and write the string to a file
-- no formatting necessary-- three lines of code. Later reading in the
string version (no formatting necessary), and hitting it with an eval()
function returned all the values I originally had in those variables.
How simple, but beautiful. I was making it harder when Python was
making it easier. Trained on the wrong language.

--
-- Lou Pecora

== 2 of 5 ==
Date: Wed, Feb 3 2010 3:03 pm
From: John Bokma

Jonathan Gardner <jgardner@jonathangardner.net> writes:

> On Feb 2, 9:11 pm, John Bokma <j...@castleamber.com> wrote:
>> Jonathan Gardner <jgard...@jonathangardner.net> writes:
>> > I can explain, in an hour, every single feature of the Python language
>> > to an experienced programmer, all the way up to metaclasses,
>>
>> Either you're a hell of a talker, or I am far, far away from being an
>> experienced programmer. It's advocacy like this, IMO, that keeps people
>> away from a language, because you can't feel nothing but a failure after
>> a statement like this.
>>
>
> 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.

> Coming from perl to python, the big "aha!" moment was when I realized
> there wasn't anything more than what I saw before me. I kept expecting
> something big around the corner, kind of like when I first discovered
> refs in perl, or when I realized how hard it truly was to write OO
> code in perl that actually does what you think it should do.

There are very nice frameworks to help you (e.g. Moose). OO is not that
hard IMO, but I can imagine it's very hard if you don't understand
references sufficiently.

> Perl has trained me to be fearful of the language, constantly on the
> lookout for jabberwockies. If you fall into one of those traps in
> perl, it's because you weren't smart enough and aren't worthy of the
> language, or so they say.

Odd, you gave me the same feeling when you stated you could explain me
all features of Python in an hour.

> It's never perl's fault. I mean, doesn't everyone know what the
> Schwartzian Transform is?

Doesn't everyone know what the big O notation is? I mean, Schwartzian
transform is not unique to Perl, and it strikes me as odd that you think
it is. It's all about understanding that general sort on average is O(n
log n), and hence does O(n log n) comparisons. Which means that if you
do an expensive calculation in a custom compare function or do a lot of
comparisons it might be cheaper to do precalculate the keys
(O(n)). Randal Schwartz was the person who made this idea popular in the
Perl community, hence the Perl community named it after him, but it was
long known before that and used in other languages.

[How to learn Python]
I am fully aware of how to learn a language, I've done so several times
(or many times even). I only disagree with your statement that you can
explain all features of Python to me in an hour. But I love to be wrong
on this, and to stand corrected.

> There are no dragons in this forest. Heck, this isn't even a forest---
> it's a single-room apartment with everything you need right there
> where you can see it. The thermostat is set to room temperature, and
> no matter what happens outside, you're safe and protected from it all.

Why does this sound like some religious speech?

I always say: if there was a really easy to learn programming language,
I would be programming in it. And no, I don't think Python is it. (Nor
Perl for that matter). I do agree that Python /looks/ more simple (and
certainly cleaner, unless you're using regexp a lot) than Perl, and
certainly to some extend Python /is/ simpler. But in my (relatively long
experience) programming boils mostly down to which libraries you know,
and how well you can use them.

Finally, note that simpeler doesn't always make your code more easy to
grasp. There is a reason that human languages are rich and often have
many ways to say something. Programming, after all, is also
communication with other humans (if only with one self).

--
John Bokma j3b

Hacking & Hiking in Mexico - http://johnbokma.com/
http://castleamber.com/ - Perl & Python Development

== 3 of 5 ==
Date: Wed, Feb 3 2010 3:09 pm
From: Paul Rubin

Lou Pecora <pecora@anvil.nrl.navy.mil> writes:
> after much noodling around and reading it hit me that I could just put
> all that output of different types of variables into a list, hit it
> with a repr() function to get a string version, and write the string
> to a file -- no formatting necessary-- three lines of code. Later
> reading in the string version (no formatting necessary), and hitting
> it with an eval() function returned all the values I originally had in
> those variables. How simple, but beautiful.

FYI: I do that too sometimes, but in general using repr/eval that way
is poor style and not very reliable. It's better to use the pickle
module, which is intended for that sort of thing, or the json module
if your datatypes are suitable and you want to follow a semi-standard.

== 4 of 5 ==
Date: Wed, Feb 3 2010 3:39 pm
From: Steve Holden

Robert Kern wrote:
> On 2010-02-03 15:32 PM, Jonathan Gardner wrote:
>
>> I can explain all of Python in an hour; I doubt anyone will understand
>> all of Python in an hour.
>
> With all respect, talking about a subject without a reasonable chance of
> your audience understanding the subject afterwards is not explaining.
> It's just exposition.
>
I agree. If the audience doesn't understand then you haven't explained it.

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/

== 5 of 5 ==
Date: Wed, Feb 3 2010 4:56 pm
From: John Bokma

Lou Pecora <pecora@anvil.nrl.navy.mil> writes:

> That's a pretty accurate description of how I transitioned to Python
> from C and Fortran.

Not C, but C++ (but there are also C implementations): YAML, see:
http://code.google.com/p/yaml-cpp/wiki/HowToParseADocument

I use YAML now and then with Perl for both reading/writing data and for
debugging purposes (YAML is quite human readable, for programmers at least)

Of course there is also YAML support for Python:
http://pyyaml.org/.

--
John Bokma j3b

Hacking & Hiking in Mexico - http://johnbokma.com/
http://castleamber.com/ - Perl & Python Development

==============================================================================
TOPIC: Selenium/SauceLabs OpenSpace at Pycon
http://groups.google.com/group/comp.lang.python/t/259ee71b81205891?hl=en
==============================================================================

== 1 of 2 ==
Date: Wed, Feb 3 2010 3:31 pm
From: Terry Reedy

On 2/3/2010 1:42 PM, Raymond Hettinger wrote:
> For those who are interested, the Sauce Labs team, http://saucelabs.com/about/team,
> is hosting two free tutorial open space sessions at Pycon in Atlanta.
>
> In the short session, people bringing their laptops should be able to
> record a web session in their browser, convert the recorded activity
> to a Python script, modify the script to accept a number of inputs ,
> and replay the script locally on their laptops. Once you've learned
> how to fully automate your own browser, submit the same script to the
> Sauce Labs cloud to run the tests in parallel across multiple browsers
> and operating systems, and view the results with instant video
> playback.

A free tutorial is a good way to introduce Suace Lab and its product. I
visited the site, but one variable I did not address is screen size and
aspect ratio. When my wife redid her home page last fall, that was more
of a problem than browser differences.

tjr

== 2 of 2 ==
Date: Wed, Feb 3 2010 5:32 pm
From: aahz@pythoncraft.com (Aahz)

In article <f4932015-d9e7-47f8-8525-feaa7486330a@x1g2000prb.googlegroups.com>,
Raymond Hettinger <python@rcn.com> wrote:
>
>For those who are interested, the Sauce Labs team,
>http://saucelabs.com/about/team, is hosting two free tutorial open
>space sessions at Pycon in Atlanta.

Congrats on the new job!
--
Aahz (aahz@pythoncraft.com) <*> http://www.pythoncraft.com/

import antigravity

==============================================================================
TOPIC: expy 0.5.2 released
http://groups.google.com/group/comp.lang.python/t/ea3018487d9365ec?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Feb 3 2010 4:00 pm
From: Yingjie Lan

> >
> > expy is an expressway to extend python.
> >
> > in release 0.5.2, expy now supports custom exceptions,
> besides all built-in ones, and exception handling is made
> easy.
> >
> > for more info, see
> >
> > http://expy.sourceforge.net/
>
> What Python versions does it work with?
> There is no indication either above or on the sf page.
>

Thanks for point that out, I will add this to the
document. Currently, it works with Python 2.5, 2.6.
I haven't tested with Python 2.7 or 3.x
(for 3.x, need to use the code tool first,
then I am not sure if the C API for 3.x
has changed much).

BTW, the current version is 0.5.5.

Yingjie

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

== 1 of 6 ==
Date: Wed, Feb 3 2010 4:01 pm
From: Steven D'Aprano

On Wed, 03 Feb 2010 16:38:21 -0600, Robert Kern wrote:

>>> class.method(name, count)
>>
>> Obviously? I don't know about that. Being told that "count" is an int
>> doesn't really help me -- it's obvious just from the name. In a well-
>> written API, what else could it be?
>
> A bool. As in telling the method whether or not it should count
> something.

Ha ha, good point. I question that this is a well-written API: such flags
to change the behaviour of a function/method are generally poor design.
If method behaves differently depending on whether or not you want it to
count something, then it is usually better design to have two methods,
one that counts and one that doesn't.

In any case, yes, the weakness of naming conventions is that there are
always odd-corner cases of natural language. Perhaps `name` is also a
flag telling the method whether or not to name something.

But then, one can write crappy APIs in any language.

--
Steven

== 2 of 6 ==
Date: Wed, Feb 3 2010 4:49 pm
From: Robert Kern

On 2010-02-03 18:01 PM, Steven D'Aprano wrote:
> On Wed, 03 Feb 2010 16:38:21 -0600, Robert Kern wrote:
>
>>>> class.method(name, count)
>>>
>>> Obviously? I don't know about that. Being told that "count" is an int
>>> doesn't really help me -- it's obvious just from the name. In a well-
>>> written API, what else could it be?
>>
>> A bool. As in telling the method whether or not it should count
>> something.
>
> Ha ha, good point. I question that this is a well-written API: such flags
> to change the behaviour of a function/method are generally poor design.
> If method behaves differently depending on whether or not you want it to
> count something, then it is usually better design to have two methods,
> one that counts and one that doesn't.

I prefer Guido's formulation (which, naturally, I can't find a direct quote for
right now): if you expect that a boolean argument is only going to take
*literal* True or False, then it should be split into two functions. There is a
use case for a boolean argument like this when you can expect to pass around a
variable between multiple functions.

Of course, this also might be the private API that the public API (with two
distinct methods for each case) uses internally in order to avoid code
duplication. Private APIs need to be documented, too.

> In any case, yes, the weakness of naming conventions is that there are
> always odd-corner cases of natural language. Perhaps `name` is also a
> flag telling the method whether or not to name something.
>
> But then, one can write crappy APIs in any language.

Well, I'm not trying to make Paul's point that other languages are better in
this regard. I think that type documentation is quite helpful, but requiring
static type declaration to get that documentation is an undesirable tradeoff for
most of the code that I want to write. I do think it is worthwhile to recognize
that the tradeoff does cut the other way, too. It just so happens that Python
has docstrings and argument annotations to document argument types without the
burden of static typing.

Not all good, clean APIs are always going to have argument names that clearly
inform the kind of type it expects. And what an author thinks is obviously
deducible while writing the API is often quite different from what a new user
thinks is obvious. There isn't much reason to place that cognitive burden on the
(many) readers of the code when the (single) author can put in a word or two
into the docstring (once) to describe what the parameter is expected to be.
Figuring out how to use an API to solve your real problem is hard enough without
having your brainpower nickled-and-dimed at every turn.

--
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 6 ==
Date: Wed, Feb 3 2010 4:55 pm
From: Steve Holden

Vladimir Ignatov wrote:
>> can you sketch an example/use case more concretely?
>
> Sorry, I don't have anything written down. I just have some rough idea
> of implementation and some concrete features I would like to see in
> such system. For example:
>
> 1) Instant refactoring. No more needs for manual
> search/inspect/rename. Since system knows exactly that is going on,
> the refactoring will be fully automatic.

You'll probably want to take a look at "Bicycle Repair Man", which
offers Python refactoring functionality.

> 2) Show "xref table" for each function. How often this function used?
> Where is it used? (code snippets of calls) What functionality is
> supported by this function?

Bear in mind this information can only ever be partial, since functions
are first-class objects and aren't always referred to by their original
name.

> 3) Extended statistics. How many objects this object/function
> interacts with? Popular functions, dead/unused functions.
> 4) Code smell detector - too long functions, too much interaction with
> other objects, global objects, etc.
> ...
>
Also take a look at pylint and pychecker, which are already built to
perform that kind of check on Python code.

== 4 of 6 ==
Date: Wed, Feb 3 2010 5:03 pm
From: alex23

Adam Tauno Williams <awill...@opengroupware.us> wrote:
> 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... ?"

Could you provide an actual example to support this?

The only places I tend to see 'x' as a parameter in the Python library
docs are where it's clearly a number, or the text immediately beneath
it explains exactly what it is.

random.seed([x])
Initialize the basic random number generator. Optional
argument x can be any hashable object.

Everywhere else, the docs seem to declare what the parameters should
be _and_ explains them in the text:

itertools.combinations(iterable, r)
Return r length subsequences of elements from
the input iterable.

If you're finding places in the docs where this isn't the case, I'd
treat them as a documentation bug and report them. If it's not obvious
to you what an iterable is, well, I'm sure you've got a disparaging
term for those of us who do...

== 5 of 6 ==
Date: Wed, Feb 3 2010 5:46 pm
From: Ben Finney

Steven D'Aprano <steven@REMOVE.THIS.cybersource.com.au> writes:

> On Wed, 03 Feb 2010 18:48:12 +0300, Vladimir Ignatov wrote:
> > […] system "knows" all your identifiers and just regenerates
> > relevant portions of text from internal database-alike
> > representation.

You will probably want to learn about "refactoring" to see if that's
related to what you mean <URL:http://www.refactoring.com/>.

> Something like Bicycle Repair Man then:

Bicycle Repair Man has not shown any development activity since 2004.
Which is a shame, because it's an awesomely appropriate name for what it
does :-)

The niche is now occupied by the Rope library and tools
<URL:http://rope.sourceforge.net/>.

--
\ "Holy knit one purl two, Batman!" —Robin |
`\ |
_o__) |
Ben Finney

== 6 of 6 ==
Date: Wed, Feb 3 2010 5:57 pm
From: Ben Finney

Robert Kern <robert.kern@gmail.com> writes:

> It is perfectly reasonable (and often necessary) for the unit test of
> class B to use a mock object instead of a real A() instance. The unit
> test for class B will fail to catch the renaming of A.foo() to A.bar()
> because it never tries to call .foo() on a real A instance.

Right, which is one good reason why unit tests are *necessary* but not
*sufficient*. You also need so-called "integration" tests (make sure
modules work together as expected) and "system" tests (make sure the
whole running system behaves as expected).

This need for testing is true regardless of whether you're using a
statically-typed or dynamically-typed language, of course. (I hope
no-one here thinks that static typing obviates the need for integration
and system tests in the test suite.)

--
\ "It is far better to grasp the universe as it really is than to |
`\ persist in delusion, however satisfying and reassuring." —Carl |
_o__) Sagan |
Ben Finney

==============================================================================
TOPIC: pychecker and "import my.special.module as mymod"
http://groups.google.com/group/comp.lang.python/t/6180173a5795a7e8?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Feb 3 2010 4:18 pm
From: News123

Hi,

I'm not really used to structuring modules withn directories, but I
started playing

#####################################
# the commands to reproduce my setup:
#####################################
mkdir -p my/special
touch my/__init__.py my/special/__init__.py
echo 'print "myspecialmod"' > my/special/module.py
echo "import my.special.module as mymod" > tst.py

so I have now following files:
-rw-r--r-- 1 0 2010-02-04 01:05 ./my/__init__.py
-rw-r--r-- 1 131 2010-02-04 01:07 ./my/__init__.pyc
-rw-r--r-- 1 0 2010-02-04 01:05 ./my/special/__init__.py
-rw-r--r-- 1 139 2010-02-04 01:07 ./my/special/__init__.pyc
-rw-r--r-- 1 21 2010-02-04 01:06 ./my/special/module.py
-rw-r--r-- 1 159 2010-02-04 01:07 ./my/special/module.pyc
-rw-r--r-- 1 34 2010-02-04 01:07 ./tst.py

the program tst.py runs as expected:
> $ python tst.py
> myspecialmod

However pychecker gives me two warnings:
> $ pychecker tst.py
> Processing module tst (tst.py)...
> myspecialmod
>
> Warnings...
>
> tst.py:1: Imported module (my.special.module) not used
> tst.py:1: No module attribute (special) found

I understand the first one and this one will not appear in my real code.
However I don't really understand the second one.

So my questions are:
- Is this a real warning or is this 'just' a pychecker problem?
- Can I write my code such, that the warning will not appear?
- Is there a pychecker switch, which would get rid of this warning?

thanks a lot in advance for your answers / suggestions

==============================================================================
TOPIC: Python 3 minor irritation
http://groups.google.com/group/comp.lang.python/t/5985c3d61bb30991?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Feb 3 2010 4:39 pm
From: David Monaghan

I have a small program which reads files from the directory in which it
resides. It's written in Python 3 and when run through IDLE or PythonWin
works fine. If I double-click the file, it works fine in Python 2.6, but in
3 it fails because it looks for the files to load in the Python31 folder,
not the one the script is in.

It's not a big deal, but browsing around I haven't found why the behaviour
has been changed or any comment about it (That might be my poor search
technique, I suppose).

The program fails at:

try:
tutdoc = minidom.parse(".//Myfile.xml")
except IOError:
<snip>

DaveM

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

== 1 of 1 ==
Date: Wed, Feb 3 2010 4:52 pm
From: 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"?

regards
Steve

> - write a wrapper-script that invokes py(lint|checker) with an adapted
> PYTHONPATH environtment variable, based on the venv's sys.path. I do
> that for my epylint-wrapper for emacs. Works flawlessly.
>
>
> Diez

--
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: simple and fast platform independent IPC
http://groups.google.com/group/comp.lang.python/t/0fb9d731abbc5ab3?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Feb 3 2010 5:40 pm
From: bobicanprogram

On Feb 3, 3:32 am, News123 <news...@free.fr> wrote:
> Hi,
>
> I wondered what IPC library might be best simplest for following task?
>
> I'm having a few python scripts all running on the same host (linux or
> win), which are started manually in random order. (no common parent process)
> Each process might be identified by an integer (1,2,3) or by a symbolic
> name ( 'dad' , 'mom' , 'dog' )
>
> these scripts want to send short messages to each other ( mostly
> integers, max a few bytes, short string), which would be enqueued in
> message queues of the receiving process.
>
> example:
>
> 'dad' wants to tell 'mom': 'cook'
> 'dog' wants to tell 'dad' : 'feedme'
> 'mom' wants to tell 'dad' : 'cookyourself'
>
> the receiver dos not necesarily have to know who sent the message
>
> a message shall be dropped silently if the receiving process is not running
>
> a message shall be reliably delivered if the receiving process is up
>
> xmlrpc seems to be a little heavy for such tasks.
>
> signals don't allow to exchange data
>
> a shared memory message queue would probably a good solution, but
> python's Multiprocessing.Queue seems to require a common parent process
>
> thanks a lot for any ideas / suggestions
>
> N
>
> N

Have a look at the SIMPL toolkit (http://www.icanprogram.com/simpl or
http://www.icanprogram.com/06py/main.html). It should do everything
you describe at least on the Linux end of the spectrum. Under the
hood SIMPL uses a shared memory scheme for local message exchange.
SIMPL would be especially effective if you want to move your modules
at some future point onto different nodes. SIMPL-Python can work
seamlessly on heterogeneous networks provided at least one node is
Linux.

bob

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

== 1 of 1 ==
Date: Wed, Feb 3 2010 5:51 pm
From: Paul Rubin

John Nagle <nagle@animats.com> writes:
> Analysis of each domain is
> performed in a separate process, but each process uses multiple
> threads to read process several web pages simultaneously.
>
> Some of the threads go compute-bound for a second or two at a time as
> they parse web pages.

You're probably better off using separate processes for the different
pages. If I remember, you were using BeautifulSoup, which while very
cool, is pretty doggone slow for use on large volumes of pages. I don't
know if there's much that can be done about that without going off on a
fairly messy C or C++ coding adventure. Maybe someday someone will do
that.

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

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, February 3, 2010

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

No comments:

Post a Comment