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: Dreaming of new generation IDE
http://groups.google.com/group/comp.lang.python/t/e019614ea149e7bd?hl=en
==============================================================================

== 1 of 8 ==
Date: Wed, Feb 3 2010 1:40 pm
From: Steven D'Aprano

On Wed, 03 Feb 2010 06:42:52 -0800, Paul Rubin wrote:

> One nice trick with static types is if you change
> what the method does (even if its type signature doesn't change), you
> can rename the method:
>
> class.method2(string name, int count): # change 'method' to
> 'method2'
>
> and recompile your codebase. Every place in the code that called
> 'method' now gets a compile time "undefined method" error that you can
> examine to see if you need to update it. This is something you can't
> catch with unit tests because the call sites can be in distant modules.

I don't understand why that won't work with unit tests. If you change the
name of a method, surely your unit tests will now start failing with
AttributeError?

--
Steven

== 2 of 8 ==
Date: Wed, Feb 3 2010 1:42 pm
From: Steven D'Aprano

On Wed, 03 Feb 2010 18:48:12 +0300, Vladimir Ignatov wrote:

> Imagine simple operation like "method renaming" in a simple "dumb"
> environment like text editor + grep. Now imagine how simple it can be if
> system "knows" all your identifiers and just regenerates relevant
> portions of text from internal database-alike representation.

Something like Bicycle Repair Man then:

http://bicyclerepair.sourceforge.net/

--
Steven

== 3 of 8 ==
Date: Wed, Feb 3 2010 1:43 pm
From: Steven D'Aprano

On Wed, 03 Feb 2010 10:39:53 -0500, Adam Tauno Williams wrote:

> On Wed, 2010-02-03 at 16:23 +0100, Stef Mientki wrote:
>> Yes, it certainly does. Not that you'll get many Pythonistas
>> to confess
>> to that fact. Somehow those who brag about the readability and
>> expressiveness of source code just cannot admit that:
>> class.method(sting name, int count)
>> - is *obviously* more expressive than - class.method(name,
>> count)
>> Oh, well.
>> 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... ?"
>
>> But I thought that was the one of beauties of Python, you don't need to
>> know if the input parameter is a list or a string.
>
> You don't need to know; unless of course you want the expected result.

Says who? If you're free to assume the function requires a certain type,
we're free to assume the function is polymorphic and doesn't.

--
Steven

== 4 of 8 ==
Date: Wed, Feb 3 2010 2:00 pm
From: Paul Rubin

Steven D'Aprano <steven@REMOVE.THIS.cybersource.com.au> writes:
>> and recompile your codebase. Every place in the code that called
>> 'method' now gets a compile time "undefined method" error that you can
>> examine to see if you need to update it. This is something you can't
>> catch with unit tests because the call sites can be in distant modules.
>
> I don't understand why that won't work with unit tests. If you change the
> name of a method, surely your unit tests will now start failing with
> AttributeError?

Unit tests only test the code in the local module or package ("unit").
Obviously you also need other tests to exercise the interaction between
local and remote modules, but it's harder to be as thorough with those,
or write them as reflexively, in part because they're often written
by a separate group of programmers.

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

Vladimir Ignatov <kmisoft@gmail.com> writes:

>> I guess Vladimir means what's called a structure editor. The (by me)
>> aforementioned Synthesizer Generator is an example of such an editor
>> (environment).
>
> Maybe. Yes, it kind of "generator". It has (entered somehow) internal
> representation of target program. Then it generates code out of this
> internal data. Yes, it is imaginable system, I don't have any working
> prototype yet. But about to start making it. For prototype I choose
> python 2.x as implementation language, sqlite as internal database and
> Django as UI.

You might check out articles that mention the Synthesizer Generator, etc.
http://citeseer.ist.psu.edu/cis?q=synthesizer+generator&cs=1
http://citeseer.ist.psu.edu/cis?q=structure+editor&cs=1

The idea is not new (at least 30 years old), and those articles might
help you.

--
John Bokma j3b

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

== 6 of 8 ==
Date: Wed, Feb 3 2010 2:24 pm
From: Terry Reedy

On 2/3/2010 8:18 AM, Adam Tauno Williams wrote:

> class.method(sting name, int count)
>
> - is *obviously* more expressive than -
>
> class.method(name, count)

So write

class.method(name:str, count:int)->return_type # 3.x

if you really prefer.

In spite of you disparagement of 'pythonistas', it seems that the head
pythonista *did* admit that some people, at least, would prefer such
annotations.

3.0 also added abstract base classes so one can better specify object
classes without losing duck-typing.

import numbers
class.method(name:str, count:numbers.Integral)->return_type

Now one is documenting that count should be an integral value that acts
like an integer even if it is not an int per se. Of course, this is too
broad as it allows (presumably invalid) negative values.

Terry Jan Reedy

== 7 of 8 ==
Date: Wed, Feb 3 2010 2:27 pm
From: Robert Kern

On 2010-02-03 15:40 PM, Steven D'Aprano wrote:
> On Wed, 03 Feb 2010 06:42:52 -0800, Paul Rubin wrote:
>
>> One nice trick with static types is if you change
>> what the method does (even if its type signature doesn't change), you
>> can rename the method:
>>
>> class.method2(string name, int count): # change 'method' to
>> 'method2'
>>
>> and recompile your codebase. Every place in the code that called
>> 'method' now gets a compile time "undefined method" error that you can
>> examine to see if you need to update it. This is something you can't
>> catch with unit tests because the call sites can be in distant modules.
>
> I don't understand why that won't work with unit tests. If you change the
> name of a method, surely your unit tests will now start failing with
> AttributeError?

Let's say we have class "A" with a method named "foo" that we change to "bar".
We have another class "B" with a method that accepts and A() instance and calls
the .foo() method on it. 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.

Of course, in a static language, it's much harder to make mock objects to do
this kind of (very useful!) testing to begin with.

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

== 8 of 8 ==
Date: Wed, Feb 3 2010 2:38 pm
From: Robert Kern

On 2010-02-03 15:37 PM, Steven D'Aprano wrote:
> On Wed, 03 Feb 2010 08:18:40 -0500, Adam Tauno Williams wrote:
>
>> On Wed, 2010-02-03 at 14:10 +0300, Vladimir Ignatov wrote:
>>> Hello,
>>> I am sitting here for quite some time, but usually keep silent ;-) I
>>> use Python since 2003 both "professionally" and for my hobby projects
>>> and love it a much.
>>> I notice however, that "maintaining" existing/older python code is may
>>> be not so enjoyable task. It may be even harder than supporting old
>>> code written in some type of "static" languages (like Java or C++).
>>> Surely "dynamic" nature of python comes with price.
>>
>> Yes, it certainly does. Not that you'll get many Pythonistas to confess
>> to that fact. Somehow those who brag about the readability and
>> expressiveness of source code just cannot admit that:
>>
>> class.method(sting name, int count)
>>
>> - is *obviously* more expressive than -
>>
>> 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.

That said, I agree with your later point that this kind of information is better
provided by the docstring, not the call signature. Not least because the "type"
may be something wishy-washy and ad-hoc like "sequence" or "string or list of
strings". I do wish that people would document their parameters with this
information a little more consistently, though.

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

==============================================================================
TOPIC: simple and fast platform independent IPC
http://groups.google.com/group/comp.lang.python/t/0fb9d731abbc5ab3?hl=en
==============================================================================

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

Tim Golden wrote:
>
>> Anyway, you have in mind that respect to speed:
>>
>> shared memory> named pipes> Unix domain socket> TCP socket
>
> True, but the OP didn't mention speed; rather simplicity. Not
> saying it isn't a consideration but premature optimisation and
> all that...
>

Yes true. I'm looking for something simple, platform agnostic. Lateron I
can always improve performance.

Perhaps I'll stick initially with xmlrpc, as it is quite simple, though
a little heavy.
I just have to see how to deal with servers which are not up, no more
up, being restarted.

== 2 of 3 ==
Date: Wed, Feb 3 2010 2:02 pm
From: News123

Hi Terry,

Terry Reedy wrote:

>
> That aside, I would wonder whether you could use a master process with a
> gui to haphazardly launch subprocess, so as to avail oneself of
> multiprocessing.Queue.
>
T

This is also an option I'm looking.

insted of the python scripts, thet users would normally click at I had
to implement small sripts, that just communicate with the master
process, which would then launch the application.

== 3 of 3 ==
Date: Wed, Feb 3 2010 2:01 pm
From: Paul Rubin

News123 <news123@free.fr> writes:
> Perhaps I'll stick initially with xmlrpc, as it is quite simple,
> though a little heavy. I just have to see how to deal with servers
> which are not up, no more up, being restarted.

Something wrong wtih nagios?

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

== 1 of 2 ==
Date: Wed, Feb 3 2010 1:46 pm
From: 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.

Any help appreciate,
Soltys

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

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

==============================================================================
TOPIC: Wrap a function
http://groups.google.com/group/comp.lang.python/t/fce27f8c4a22d12b?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Feb 3 2010 1:50 pm
From: Ben Finney

Dan Stromberg <drsalists@gmail.com> writes:

> Ben Finney wrote:
> > It's no sin to say that Python isn't a good choice for specific
> > things; and "I want to write programs by indistinguishably mixing
> > statements with external system calls" is one of them, IMO

> > From
> http://stromberg.dnsalias.org/~dstromberg/debugging-with-syscall-tracers.html#terminology
>
> A quick note on terminology: open() is typically a system call.
[…]

That is a different use of "system call". I used it in the 'os.system'
sense: meaning "invoke an external OS command as a child of this
process".

--
\ "I was in a bar the other night, hopping from barstool to |
`\ barstool, trying to get lucky, but there wasn't any gum under |
_o__) any of them." —Emo Philips |
Ben Finney

==============================================================================
TOPIC: Need help w 'Broken pipe' handling
http://groups.google.com/group/comp.lang.python/t/5d5f97e6b466082e?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Feb 3 2010 1:51 pm
From: gb345

Hi! I'm having a hard time figuring out how to handle a Unix
SIGPIPE exception cleanly. The following short script illustrates
the problem:

------------------------------------------------------------------
#!/usr/bin/python
# sigpipebug.py
import sys
import random
from signal import signal, SIGPIPE, SIGINT

def handle_sigpipe(signo, frame):
print >> sys.stderr, "caught SIGPIPE (%d)" % signo
sys.exit(0)

def handle_sigint(signo, frame):
print >> sys.stderr, "caught SIGINT (%d)" % signo
sys.exit(1)

def my_excepthook(exc_type, exc_obj, exc_tb):
print >> sys.stderr, "excepthook called"
sys.exit(0)

signal(SIGPIPE, handle_sigpipe)
signal(SIGINT, handle_sigint)
# sys.excepthook = my_excepthook

while True:
try:
print random.random()
except IOError as (_, error):
if error == 'Broken pipe':
print >> sys.stderr, 'EXCEPTION: %s' % error
sys.exit(0)
raise
------------------------------------------------------------------

The problem shows up only occasionally; the following bash one-liner
helps to see the problem (terminate with Ctrl-C):

while [ 1 ]; do (./sigpipebug.py||break) | head -1; done

(The pipe through head should cause the script to receive a PIPE
signal.)

The typical output from the above one-liner will start out as
something like this:

0.666233280308
caught SIGPIPE (13)
0.554289690682
caught SIGPIPE (13)
0.438033929588
caught SIGPIPE (13)
0.969307976257
caught SIGPIPE (13)
close failed in file object destructor:
Error in sys.excepthook:

Original exception was:
0.916260186232
caught SIGPIPE (13)
0.798590903019
caught SIGPIPE (13)
0.737496617527

...though the length of the output preceding "close failed..." is
highly variable.

My problem is that I can't figure out how to get rid of this unwanted
extra output:

close failed in file object destructor:
Error in sys.excepthook:

Original exception was:

I figure that the way the script is handling the SIGPIPE is somehow
incorrect, but I don't see what is it that I'm doing wrong (BTW,
I'm a Python noob). Is there some cleanup method I should invoke
in the sigpipe handler before executing sys.exit(0)? (BTW, I'm
using sys.exit in this script instead of plain exit to avoid a
strange error of the form "NameError: global name 'exit' is not
defined".)

The same thing happens when I redefine sys.excepthook (by uncommenting
the commented-out line).

Also, is there a way to define the SIGPIPE handler to obviate the
need to trap the IOError exception? (Without this try block, I
get a traceback when the script receives the PIPE signal. This
traceback is also unwanted output.)

Any suggestions or comments would be appreciated!

Gabe

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

== 1 of 1 ==
Date: Wed, Feb 3 2010 1:50 pm
From: Robert Kern

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.

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

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

== 1 of 5 ==
Date: Wed, Feb 3 2010 2:04 pm
From: "Diez B. Roggisch"

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.

And there are people who say "you should *never* write web-apps that
only work with enabled javascript"... catch 22.

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.

Diez

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

Am 03.02.10 19:01, schrieb Alan Harris-Reid:
> 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).
>
> Is there another way of passing a record-id to a method
> a) without it appearing in the URL?

You can populate an invisible HTML-form with the values, and submit that
- of course you need javascript for this.

But this doesn't increase security a bit. Using an extension to FF such
as HTTP live headers, it's easy enough to figure out what parameters are
passed, and simply forge a request.

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

Paul already mentioned that - you can create a server-side,
session-stored action-item that is identified by a hash of some sort.
Then use that hash as parameter.

But I'd say you should instead make sure that your serve actions perform
authorization checking before performing any operations. Then you don't
need to worry - even guessing a hash argument won't work then.

>
> As each link contains row-id, I guess there is nothing to stop someone
> from getting the id from the page source-code. 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?

You should of course always do that. Every http-action except login
should be guarded (unless you allow anonymous access of course).

Diez

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

"Diez B. Roggisch" <deets@nospam.web.de> writes:
> 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. This was an
annoyance in a web chat package I fooled with for a while. Because the
package sent user messages by GET, if I ran the software the way the
developers set it up, the contents of all the user conversations stayed
in my server logs. I was unable to convince the chat package
maintainers that this was a bug. I ended up doing some fairly kludgy
hack to prevent the logging.

== 4 of 5 ==
Date: Wed, Feb 3 2010 2:31 pm
From: "Diez B. Roggisch"

Am 03.02.10 23:09, schrieb Paul Rubin:
> "Diez B. Roggisch"<deets@nospam.web.de> writes:
>> 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. This was an
> annoyance in a web chat package I fooled with for a while. Because the
> package sent user messages by GET, if I ran the software the way the
> developers set it up, the contents of all the user conversations stayed
> in my server logs. I was unable to convince the chat package
> maintainers that this was a bug. I ended up doing some fairly kludgy
> hack to prevent the logging.

If somebody happens to have access to a proxy & it's logs, he can as
well log the request body.

Don't get me wrong, I don't want to propagate the use of GET as one and
only method for parameter passing. But whatever is transmitted clear
text over the wire is subject to inspection of all hops in between. Use
SSL if you bother.

Diez

== 5 of 5 ==
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.

==============================================================================
TOPIC: Radian language
http://groups.google.com/group/comp.lang.python/t/880c455b1f3ff7fe?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Feb 3 2010 2:12 pm
From: Steven D'Aprano

For those interested in language design, the former head of RealBasic's
development team, and current "compiler architect guy" for Microsoft's
VisualBasic team, Mars Saxman, is developing an interesting programming
language, Radian:

"The goal of the Radian project is to provide the concurrency benefits
of a pure functional language inside the syntax and conceptual style
of a high-level imperative language. This suggests two questions:
what is it about a pure functional language that makes it useful for
developing concurrent software, and what is it about an imperative
syntax that makes the marriage of these two divergent linguistic
styles worth the effort?"

Radian is heavily (but not uniquely) influenced by Python, although
sometimes that influence is "what not to do".

http://www.radian-lang.org/

--
Steven

==============================================================================
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 2:24 pm
From: Carl Banks

On Feb 3, 8:55 am, Nobody <nob...@nowhere.com> wrote:
> On Tue, 02 Feb 2010 10:38:53 -0800, Carl Banks wrote:
> >> I don't know if that's necessary. Only supporting the "foo.h" case would
> >> work fine if Python behaved like gcc, i.e. if the "current directory"
> >> referred to the directory contain the file performing the import rather
> >> than in the process' CWD.
>
> >> As it stands, imports are dynamically scoped, when they should be
> >> lexically scoped.
>
> > Mostly incorrect. The CWD is in sys.path only for interactive
> > sessions, and when started with -c switch. When running scripts, the
> > directory where the script is located is used instead, not the
> > process's working directory.
>
> Okay, so s/CWD/directory containing __main__ script/, but the general
> argument still holds.
>
> > So, no, it isn't anything like dynamic scoping.
>
> That's what it looks like to me. The way that an import name is resolved
> depends upon the run-time context in which the import occurs.

Well it has one superficial similarity to dynamic binding, but that's
pretty much it.

When the directory containing __main__ script is in the path, it
doesn't matter if you invoke it from a different directory or os.chdir
() during the program, the same modules get imported. I.e., there's
nothing dynamic at all about which modules are used. (Unless you
fiddle with the path but that's another question.)

All I'm saying is the analogy is bad. A better analogy would be if
you have lexical binding, but you automatically look in various sister
scope before your own scope.

Carl Banks

== 2 of 2 ==
Date: Wed, Feb 3 2010 2:34 pm
From: Carl Banks

On Feb 2, 8:52 pm, Steven D'Aprano
<ste...@REMOVE.THIS.cybersource.com.au> wrote:
> On Tue, 02 Feb 2010 19:55:15 -0800, Carl Banks wrote:
> > On Feb 2, 5:49 pm, Steven D'Aprano
> > <ste...@REMOVE.THIS.cybersource.com.au> wrote:
> >> On Tue, 02 Feb 2010 12:26:16 -0800, Carl Banks wrote:
> >> > I did not propose obvious module names. I said obvious names like
> >> > email.py are bad; more descriptive names like send_email.py are
> >> > better.
>
> >> But surely send_email.py doesn't just send email, it parses email and
> >> receives email as well?
>
> > No, it doesn't.
>
> Nevertheless, as a general principle, modules will tend to be multi-
> purpose and/or generic.

Uh, no?

If your module is a library with a public API, then you might
defensibly have a "generic and/or multi-purpose module", but if that's
the case you should have already christened it something unique.

Otherwise modules should stick to a single purpose that can be
summarized in a short action word or phrase.

Carl Banks

==============================================================================
TOPIC: PEP 3147 - new .pyc format
http://groups.google.com/group/comp.lang.python/t/7a0d8230a5907885?hl=en
==============================================================================

== 1 of 1 ==
Date: Wed, Feb 3 2010 2:28 pm
From: Daniel Fetchinson

>>> Python does most of that for you: it automatically recompiles the
>>> source whenever the source code's last modified date stamp is newer
>>> than that of the byte code. So to a first approximation you can forget
>>> all about the .pyc files and just care about the source.
>>
>> True, but the .pyc file is lying around and I always have to do 'ls -al
>> | grep -v pyc' in my python source directory.
>
>
> So alias a one-word name to that :)
>
>
> [...]
>> Here is an example: shared object files. If your code needs them, you
>> can use them easily, you can access them easily if you want to, but they
>> are not in the directory where you keep your C files. They are somewhere
>> in /usr/lib for example, where they are conveniently collected, you can
>> inspect them, look at them, distribute them, do basically whatever you
>> want, but they are out of the way, and 99% of the time while you develop
>> your code, you don't need them. In the 1% of the case you can easily get
>> at them in the centralized location, /usr/lib in our example.
>>
>> Of course the relationship between C source files and shared objects is
>> not parallel to the relationship to python source files and the created
>> pyc files, please don't nitpick on this point. The analogy is in the
>> sense that your project inevitable needs for whatever reason some binary
>> files which are rarely needed at hand, only the
>> linker/compiler/interpreter/etc needs to know where they are. These
>> files can be stored separately, but at a location where one can inspect
>> them if needed (which rarely happens).
>
> I'll try not to nit-pick :)
>
> When an object file is in /usr/lib, you're dealing with it as a user.
> You, or likely someone else, have almost certainly compiled it in a
> different directory and then used make to drop it in place. It's now a
> library, you're a user of that library, and you don't care where the
> object file is so long as your app can find it (until you have a
> conflict, and then you do).
>
> While you are actively developing the library, on the other hand, the
> compiler typically puts the object file in the same directory as the
> source file. (There may be an option to gcc to do otherwise, but surely
> most people don't use it often.) While the library is still being
> actively developed, the last thing you want is for the object file to be
> placed somewhere other than in your working directory. A potentially
> unstable or broken library could end up in /usr/lib and stomp all over a
> working version. Even if it doesn't, it means you have to be flipping
> backwards and forwards between two locations to get anything done.
>
> Python development is much the same, the only(?) differences are that we
> have a lower threshold between "in production" and "in development", and
> that we typically install both the source and the binary instead of just
> the binary.
>
> When you are *using* a library/script/module, you don't care whether
> import uses the .py file or the .pyc, and you don't care where they are,
> so long as they are in your PYTHONPATH (and there are no conflicts). But
> I would argue that while you are *developing* the module, it would more
> nuisance than help to have the .pyc file anywhere other than immediately
> next to the .py file (either in the same directory, or in a clearly named
> sub-directory).

Okay, I think we got to a point where it's more about rationalizing
gut feelings than factual stuff. But that's okay,
system/language/architecure design is often times more about gut
feelings than facts so nothing to be too surprised about :)

Cheers,
Daniel

--
Psss, psss, put it down! - http://www.cafepress.com/putitdown

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

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 - 25 new messages in 10 topics - digest

0 Comments:

Post a Comment

About Me

Previous Posts