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: How to install local module other than in "site-packages"?
http://groups.google.com/group/comp.lang.python/t/fd324f13a857c248?hl=en
==============================================================================

== 1 of 9 ==
Date: Sun, Jan 17 2010 4:39 pm
From: "Diez B. Roggisch"

Am 18.01.10 01:33, schrieb Jive Dadson:
> Diez B. Roggisch wrote:
>> Am 18.01.10 01:07, schrieb Jive Dadson:
>>> (My apologies if this question shows up twice. I posted it quite a
>>> while ago, and it's yet to show up.)
>>>
>>> This is no doubt a beginner's question, but I've searched for the answer
>>> for quite a while, to no avail. I'm running Python 2.6 under Windows XP.
>>>
>>> How do I install a module that I wrote, without putting it in the
>>> site-packages directory for a specific release? I have stuff that, to
>>> the best of my knowledge and belief, ought to work under any release. I
>>> do not want to have multiple copies of it. When I edit one of the
>>> modules, I want it to "take" for every release. Is that clear? Hope so.
>>
>> Setting the PYTHONPATH environment variable should work.
>>
>> Diez
>
> I was trying that just now. So far, no joy. Can you type up a DUMMIES
> version?
>
> There was no environment variable PYTHONPATH. I added one to my "User
> Variables." It's still not finding anything. And yes, I closed and
> re-opened my Python shell before I tested it.

Did "echo %PYTHONPATH%" yield anything? Or is it part of

>>> import sys
>>> sys.path

Diez

== 2 of 9 ==
Date: Sun, Jan 17 2010 4:47 pm
From: Jive Dadson

Ben Finney wrote:
> Jive Dadson <notontheweb@noisp.com> writes:
>
>> How do I install a module that I wrote, without putting it in the
>> site-packages directory for a specific release? I have stuff that, to
>> the best of my knowledge and belief, ought to work under any release.
>
> Nevertheless, the compiled byte-code version will be specific to the
> Python version that compiled it. You need to install the module to a
> version-specific directory for that reason at least.
>
>> I do not want to have multiple copies of it. When I edit one of the
>> modules, I want it to "take" for every release. Is that clear? Hope
>> so.
>
> You'll need (I'd love to be corrected on this) to come up with a
> deployment discipline: a build process that deploys the module from its
> (single, canonical) source location to the appropriate locations when
> you decide to deploy it.
>

Thanks for your help.

Well that majorly sucks. I was hoping the "foo.pth" thing would save
me. There ought to be a way. But even if they did invent one, it
wouldn't help me, because I am stuck at version 2.6. Don't even get me
started on that. I really like Python, but the way every release breaks
everything is a royal pain. The biggest problem is C-extensions of stuff
that does not come with the Python release. I've complained about it
before, but it didn't help. I guess I got myself started on that. :-)

Since I cannot imagine facing the challenge of going to 3.0, I guess it
doesn't matter if I have my stuff in a folder that's specific to 2.6.

== 3 of 9 ==
Date: Sun, Jan 17 2010 4:49 pm
From: Jive Dadson

Diez B. Roggisch wrote:
>
> Did "echo %PYTHONPATH%" yield anything? Or is it part of
>
> >>> import sys
> >>> sys.path
>
>
> ?
>
> Diez

Yes and no in that order. Never mind. Ben Fenny talked me out of it
anyway. Grrrrr.

== 4 of 9 ==
Date: Sun, Jan 17 2010 4:54 pm
From: Jive Dadson

Diez B. Roggisch wrote:
>
> Did "echo %PYTHONPATH%" yield anything? Or is it part of
>
> >>> import sys
> >>> sys.path
>
>
> ?
>
> Diez

Update: It's working now. I guess I hadn't reloaded something that I
need to. Thanks for your help.

== 5 of 9 ==
Date: Sun, Jan 17 2010 5:09 pm
From: Jive Dadson

Okay, I might go this route anyway. It's almost working.

I created a directory (folder in MS-speak) named Modules, and put its
path in the PYTHONPATH env variable.

I can now put a file foo.py into the directory Modules, and it will load
foo.py when I say "import foo."

Now I put a folder into Modules called myModule and in that I put
bar.py. It does not find bar.py when I say either import bar or import
myModule.bar. I tried the myModule.pth trick but it didn't help. Maybe
I did it wrong.

== 6 of 9 ==
Date: Sun, Jan 17 2010 6:15 pm
From: Benjamin Kaplan

On Sun, Jan 17, 2010 at 8:09 PM, Jive Dadson <notontheweb@noisp.com> wrote:
> Okay, I might go this route anyway. It's almost working.
>
> I created a directory (folder in MS-speak) named Modules, and put its path
> in the PYTHONPATH env variable.
>
> I can now put a file foo.py into the directory Modules, and it will load
> foo.py when I say "import foo."
>
> Now I put a folder into Modules called myModule and in that I put bar.py.
> It does not find bar.py when I say either import bar or import
> myModule.bar. I tried the myModule.pth trick but it didn't help. Maybe I
> did it wrong.

Just put a blank file called __init__.py inside myModule

In Python, packages have to have an __init__.py file in them, even if
it's empty. Whatever you put in __init__.py gets imported when you
"import myModule".

http://docs.python.org/tutorial/modules.html#packages

> --
> http://mail.python.org/mailman/listinfo/python-list
>

== 7 of 9 ==
Date: Sun, Jan 17 2010 6:35 pm
From: Jive Dadson

Thankee. I had just figgered that out. I wrote everything up in a
message titled "The answer," but I accidentally created a new thread
with it. I'll post it in this thread.

== 8 of 9 ==
Date: Sun, Jan 17 2010 6:35 pm
From: Jive Dadson

Okay, with your help I've figured it out. Instructions are below, but
read the caveat by Ben Fenny in this thread. All this stuff is good for
one default version of Python only. The PYTHONPATH described below, for
example, cannot specify a version number. Yes, that's a pain in the
butt, but there's no way around it. If you switch versions, you may
have to delete all the .pyc files that will show up in the module
folders. Python ought to check them to see if they are valid, but I do
not know if it does so.

These instructions are for MS Windows.

1) Create your modules folder. Let's say it's named "Modules." The
documentation calls it a "package."

2) In an explorer window or on the desktop, right click on My Computer,
and select Properties.

3) Select the Advanced tab, and click on Environment Variables near the
bottom.

4) Look for an environment variable named PYTHONPATH.

a) If you do not find one, create one using the New button(s). I
don't know if it has to be in User Variables or System Variables. To
save time experimenting, I just put one in both. For the value, put the
full path of the folder Modules.

b) If there's already a PYTHONPATH, Edit it, adding a semi-colon
and the full path of folder Module to the end.

5) Put your module folders into the folder Module.

6) (Here's a really arcane bit.) Into each module folder, put a file
named __init__.py. It will be executed when you load the module. It
can be empty, but it has to be there or else the module folder will be
ignored.

== 9 of 9 ==
Date: Sun, Jan 17 2010 7:57 pm
From: "Alf P. Steinbach"

* Jive Dadson:
> Okay, with your help I've figured it out. Instructions are below, but
> read the caveat by Ben Fenny in this thread. All this stuff is good for
> one default version of Python only. The PYTHONPATH described below, for
> example, cannot specify a version number. Yes, that's a pain in the
> butt, but there's no way around it. If you switch versions, you may
> have to delete all the .pyc files that will show up in the module
> folders. Python ought to check them to see if they are valid, but I do
> not know if it does so.
>
> These instructions are for MS Windows.
>
> 1) Create your modules folder. Let's say it's named "Modules." The
> documentation calls it a "package."
>
> 2) In an explorer window or on the desktop, right click on My Computer,
> and select Properties.
>
> 3) Select the Advanced tab, and click on Environment Variables near the
> bottom.
>
> 4) Look for an environment variable named PYTHONPATH.
>
> a) If you do not find one, create one using the New button(s). I
> don't know if it has to be in User Variables or System Variables. To
> save time experimenting, I just put one in both. For the value, put the
> full path of the folder Modules.

The User variables /override/ the System variables for a given user. The System
variables provide defaults for all users. One notable exception is PATH, where
the User PATH items are appended to the System PATH.

Anyways, with many items in a variable like PATH it can be impractical to use
Windows' functionality, which presents it all on one line, which for a PATH with
many items can be exceeding long -- like a many thousand characters[1] line.

So for your convenience, below is a little Windows app (as an HTML application,
it's just some HTML and VBScript and CSS) that presents the user PATH items one
per line in a Notepad-like window. It should be no problem modifying it to
instead edit PYTHONPATH, or even a choice of environment variable. As my late
father used to say, when you don't have a tool, you make it.

Maybe now I should recode this in Python. But on the other hand, one shouldn't
spend time fixing what works. So ... enjoy! :-)

Note: it's crucial to use [.HTA] filename extension.
Also, it's quite possible that this doesn't work in Windows Vista (at least not
without configuration of Windows), but it works in XP and earlier.

<hta:application scroll="no"/>
<title>Simple user-environment %path% editor</title>

#menuArea
{
width: 100%; height: 1.8em; white-space: nowrap; padding-top: 2px;
background: #E0E0E0;
}

#clientArea
{
width: 100%; position: absolute; top: 1.8em; bottom: 0;
}

#pathEditor
{
display: inline-block;
width: 100%; height: 100%;
border: 0;
position: absolute; top: 0;
overflow: scroll;
}
</style>

sub loadText
pathEditor.innerText = replace( wshUserEnv( "PATH" ), ";",
vbNewline)
end sub

sub saveText
dim text
dim button

text = pathEditor.innerText
text = replace( text, vbNewLine, ";" )
button = MsgBox( _
text, vbYesNo + vbQuestion, "Save this as new %path% value?" _
)
if button = vbYes then wshUserEnv( "PATH" ) = text
end sub

sub onBtnLoad
loadText
end sub

sub onBtnLoadOriginal
pathEditor.innerText = originalText
end sub

sub onBtnSave
saveText
end sub

sub onLoaded
set wshShell = createObject( "WScript.Shell" )
set wshUserEnv = wshShell.environment( "USER" )
loadText
originalText = pathEditor.innerText
MsgBox _
"Type one path per line (no semicolons)", _
vbInformation, _
"How to use:"
end sub
</script>
</head>

<body onload="onLoaded">
<div id="menuArea">
  <button onClick="onBtnLoad">Load current</button>
  <button onClick="onBtnLoadOriginal">Reload original</button>
  <button onClick="onBtnSave">Save as current ...</button>
</div>
<div id="clientArea">
<textarea id="pathEditor" wrap="off">
</textarea>
</div>
</body>
</html>
</code>

> b) If there's already a PYTHONPATH, Edit it, adding a semi-colon and
> the full path of folder Module to the end.
>
> 5) Put your module folders into the folder Module.
>
> 6) (Here's a really arcane bit.) Into each module folder, put a file
> named __init__.py. It will be executed when you load the module. It
> can be empty, but it has to be there or else the module folder will be
> ignored.

Cheers & hth.,

- Alf

Notes:
[1] Windows XP and I believe also Vista places a limit of about 8 KiB on the
length of any environment variable.

==============================================================================
TOPIC: IDLE Namespace Toolbox? Windows.
http://groups.google.com/group/comp.lang.python/t/46f240e19b94a094?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Jan 17 2010 4:44 pm
From: MRAB

W. eWatson wrote:
> John Bokma wrote:
>> "W. eWatson" <wolftracks@invalid.com> writes:
>>
>>> This is a follow up to my post "Changing Lutz's mydir. It would seem
>>> there should be some sort of toolbox that allows one to do things like
>>> mydir, and perhaps a lot more. Maybe something like it exists in
>>> Linux. I'm a Windows user. I've found it a bit aggravating that using
>>> dir and help, for example, that the output just rolls on off the
>>> screen and I have to play around with the shell scroll bars to find
>>> what I'm looking for. A few simple changes to mydir should change
>>> that, but I would hope or think maybe there are even more tools to
>>> generally help.
>>
>> on the command prompt:
>>
>> cmd | more
>>
>> works
> Apparently, not in IDLE under Win.
> >>> dir() | more
> Traceback (most recent call last):
> File "<pyshell#42>", line 1, in <module>
> dir() | more
> NameError: name 'more' is not defined

He said "command prompt", not Python prompt.

==============================================================================
TOPIC: Inheriting methods but over-riding docstrings
http://groups.google.com/group/comp.lang.python/t/dee6cab40192e20d?hl=en
==============================================================================

== 1 of 3 ==
Date: Sun, Jan 17 2010 4:45 pm
From: "Alf P. Steinbach"

* Gabriel Genellina:
> En Sat, 16 Jan 2010 14:55:11 -0300, Steven D'Aprano
> <steve@remove-this-cybersource.com.au> escribió:
>
>> I have a series of subclasses that inherit methods from a base class, but
>> I'd like them to have their own individual docstrings. The obvious
>> solution (other than copy-and-paste) is this:
>>
>>
>> class Base(object):
>> colour = "Blue"
>> def parrot(self):
>> """docstring for Base"""
>> return "Norwegian %s" % self.colour
>>
>>
>> class SubClass(Base):
>> colour = "Red"
>> def parrot(self):
>> """docstring for Subclass"""
>> return super(Subclass, self).parrot()
>>
>>
>> but that adds an awful lot of boilerplate to my subclasses. Are there any
>> other good solutions to this problem?
>
> Methods don't have docstrings; functions do. So one has to "clone" the
> function to set a new docstring.
>
> <code>
> def copy_function(fn, docstring):
> fn = getattr(fn, "im_func", fn) # accomodate unbound methods in 2.x
> function_type = type(lambda:0)
> newfn = function_type(fn.__code__, fn.__globals__, fn.__name__,
> fn.__defaults__, fn.__closure__)
> newfn.__doc__ = docstring
> return newfn
>
> class Base(object):
> colour = "Blue"
> def parrot(self):
> """docstring for Base"""
> return "Norwegian %s" % self.colour
>
> class SubClass(Base):
> colour = "Red"
> parrot = copy_function(Base.parrot, "docstring for Subclass")
>
> </code>
>
> py> x = Base()
> py> print(x.parrot())
> Norwegian Blue
> py> print x.parrot.__doc__
> docstring for Base
> py> y = SubClass()
> py> print(y.parrot())
> Norwegian Red
> py> print y.parrot.__doc__
> docstring for Subclass

Since Steven says he has a series of subclasses, perhaps wrapping those function
calls in a decorator?

<code>
def copy_function(fn, docstring):
# Gabriel Genellina's copy_function
fn = getattr(fn, "im_func", fn) # accomodate unbound methods in 2.x
function_type = type(lambda:0)
newfn = function_type(fn.__code__, fn.__globals__, fn.__name__,
fn.__defaults__, fn.__closure__)
newfn.__doc__ = docstring
return newfn

def docstrings(**kwargs):
def with_altered_docstrings(cls, kwargs=kwargs):
for kwarg in kwargs.items():
func_name = kwarg[0]
docstring = kwarg[1]
original_func = getattr(cls, func_name)
new_func = copy_function(getattr(cls, func_name), docstring)
setattr(cls, func_name, new_func)
return cls
return with_altered_docstrings

class Base(object):
colour = "Blue"
def parrot(self):
"""docstring for Base"""
return "Norwegian %s" % self.colour

@docstrings( parrot = "docstring for Subclass" )
class SubClass(Base):
colour = "Red"
</code>

This is my first decorator ever so it might be Incorect and nonIdiomatic...

Also, neither 'copy_function' nor 'docstrings' seem to work with slots.

Steven: on a personal note, earlier when I saw you (I think it was you) using
the "Norwegian Parrot" example I thought it referred to me because that was the
only sense I could make of it, it followed right after some discussion we had.
Thus my impression of you or or responses in this group was colored by a false
interpretation. But, checking, which is often a good idea!, and *which I should
have done then*, as far as I can see the term was first used in this group in
April 2001, <url:
http://groups.google.com/group/comp.lang.python/browse_thread/thread/12a125ceddd401e2/c021547a1dc14a41>.

It's still a mystery to me what it refers to, though... :-)

Cheers & hth.,

- Alf

== 2 of 3 ==
Date: Sun, Jan 17 2010 6:23 pm
From: Steve Holden

Gabriel Genellina wrote:
> En Sat, 16 Jan 2010 14:55:11 -0300, Steven D'Aprano
> <steve@remove-this-cybersource.com.au> escribió:
>
>> I have a series of subclasses that inherit methods from a base class, but
>> I'd like them to have their own individual docstrings. The obvious
>> solution (other than copy-and-paste) is this:
>>
>>
>> class Base(object):
>> colour = "Blue"
>> def parrot(self):
>> """docstring for Base"""
>> return "Norwegian %s" % self.colour
>>
>>
>> class SubClass(Base):
>> colour = "Red"
>> def parrot(self):
>> """docstring for Subclass"""
>> return super(Subclass, self).parrot()
>>
>>
>> but that adds an awful lot of boilerplate to my subclasses. Are there any
>> other good solutions to this problem?
>
> Methods don't have docstrings; functions do. So one has to "clone" the
> function to set a new docstring.
>
On behalf of all methods I would like to say "We demand the right to
docstrings".

>>> print abs.__doc__
abs(number) -> number

Return the absolute value of the argument.
>>>

Perhaps I am misunderstanding "don't have docstrings". This code:

>>> class TheHellOfIt:
... """Classes, of course, as first-class citizens and have
docstrings."""
... def method(self):
... """Discrimination against methods, I call it."""
... pass
...
>>> print TheHellOfIt.method.__doc__
Discrimination against methods, I call it.
>>> import sys
>>> help(sys.modules["__main__"])

Gives:

Help on built-in module __main__:

NAME
__main__

FILE
(built-in)

CLASSES
TheHellOfIt

So, are the demands of the methods reasonable, or do they already have
what they are so loudly demanding?

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/

== 3 of 3 ==
Date: Sun, Jan 17 2010 6:28 pm
From: J

On Sun, Jan 17, 2010 at 19:45, Alf P. Steinbach <alfps@start.no> wrote:
> Steven: on a personal note, earlier when I saw you (I think it was you)
> using the "Norwegian Parrot" example I thought it referred to me because
> that was the only sense I could make of it, it followed right after some
> discussion we had. Thus my impression of you or or responses in this group
> was colored by a false interpretation. But, checking, which is often a good
> idea!, and *which I should have done then*, as far as I can see the term was
> first used in this group in April 2001, <url:
> http://groups.google.com/group/comp.lang.python/browse_thread/thread/12a125ceddd401e2/c021547a1dc14a41>.
>
> It's still a mystery to me what it refers to, though... :-)

I can't really comment on decorators and subclassing yet (still a
newb) but I am finding this discussion very informative... and lo
there IS something I can comment on.

The Norwegian Blue is a remarkable bird. Beautiful plumage! Though
they do like to lie around on their backs a bit, and seem to spend
their time either resting, or pining for the fjords. Yes lovely
plumage, indeed!

Google the remarkable Norwegian Blue Parrot and you'll fall in love as
I did so long ago :)

Marie von Ebner-Eschenbach - "Even a stopped clock is right twice a
day." - http://www.brainyquote.com/quotes/authors/m/marie_von_ebnereschenbac.html

==============================================================================
TOPIC: C-API: Get scope in function
http://groups.google.com/group/comp.lang.python/t/5db33ef55cc2486f?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Jan 17 2010 4:49 pm
From: moerchendiser2k3

Perfect, this helped me a lot, thx! :)

==============================================================================
TOPIC: A simple-to-use sound file writer
http://groups.google.com/group/comp.lang.python/t/d25a419d61a5e439?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Jan 17 2010 4:54 pm
From: TimmyGee

On Jan 15, 3:43 pm, Steve Holden <st...@holdenweb.com> wrote:
> Alf P. Steinbach wrote:
>
> [...]> Perhaps you'd also admit to being wrong, and retract your innuoendo etc.?
>
> Disregarding any matters of right or wrong (for this post, at least), I
> herebe retract anything I have said about you that you consider
> innuendo. Feel free to remind me what that was.
>
> 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/

Now now children...

==============================================================================
TOPIC: Feb 3 2010
http://groups.google.com/group/comp.lang.python/t/2eccb86ca1fbb0b7?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Jan 17 2010 5:14 pm
From: Jim Wilson

Your TMobile minutes expire 2/3/10. On or before Feb 1, we should buy $10 more
to extend for another year.

==============================================================================
TOPIC: Arrrrgh! Another module broken
http://groups.google.com/group/comp.lang.python/t/770b3880810d9174?hl=en
==============================================================================

== 1 of 5 ==
Date: Sun, Jan 17 2010 5:25 pm
From: Jive Dadson

I just found another module that broke when I went to 2.6. Gnuplot.
Apparently one of its routines has a parameter named "with." That used
to be okay, and now it's not.

Once I get everything to work under 2.6, I am using it forever or until
new releases no longer break working code, whichever comes first.

== 2 of 5 ==
Date: Sun, Jan 17 2010 6:02 pm
From: Chris Rebert

On Sun, Jan 17, 2010 at 5:25 PM, Jive Dadson <notontheweb@noisp.com> wrote:
> I just found another module that broke when I went to 2.6. Gnuplot.
> Apparently one of its routines has a parameter named "with." That used to
> be okay, and now it's not.
>
> Once I get everything to work under 2.6, I am using it forever or until new
> releases no longer break working code, whichever comes first.

The latter ain't gonna happen. Going 2.x --> 3.x *will* break code,
and no future 3.x version will change that fact.

Cheers,
Chris
--
http://blog.rebertia.com

== 3 of 5 ==
Date: Sun, Jan 17 2010 6:21 pm
From: Matt Newville

On Jan 17, 7:25 pm, Jive Dadson <notonthe...@noisp.com> wrote:
> I just found another module that broke when I went to 2.6. > Gnuplot. Apparently one of its routines has a parameter
> named "with." That used to be okay, and now it's not.

This was fixed in version 1.8 of Gnuplot.py

> Once I get everything to work under 2.6, I am using it
> forever or until new releases no longer break working
> code, whichever comes first.

Hey, good luck with that forever plan.

--Matt

== 4 of 5 ==
Date: Sun, Jan 17 2010 6:33 pm
From: Jive Dadson

Matt Newville wrote:
> Hey, good luck with that forever plan.
>
> --Matt

Yeah, I know. I'm just glad I don't have to get new executables and
dll's from all my software vendors every Tuesday when the MS Window XP
updates come out.

2.6 FOREVER!

== 5 of 5 ==
Date: Sun, Jan 17 2010 6:51 pm
From: Jive Dadson

Matt Newville wrote:
> On Jan 17, 7:25 pm, Jive Dadson <notonthe...@noisp.com> wrote:
>> I just found another module that broke when I went to 2.6. > Gnuplot. Apparently one of its routines has a parameter
>> named "with." That used to be okay, and now it's not.
>
> This was fixed in version 1.8 of Gnuplot.py
>
>> Once I get everything to work under 2.6, I am using it
>> forever or until new releases no longer break working
>> code, whichever comes first.
>
> Hey, good luck with that forever plan.
>
> --Matt

Thanks. I also had to install a new version of numpy. Have I kvetched
enough about have to track down new versions of all my third party stuff
every time I up-rev Python? I guess so. :-)

2.6 FOREVER!

==============================================================================
TOPIC: The answer
http://groups.google.com/group/comp.lang.python/t/af841f9283916f79?hl=en
==============================================================================

== 1 of 2 ==
Date: Sun, Jan 17 2010 6:30 pm
From: Jive Dadson

These instructions are for MS Windows.

1) Create your modules folder. Let's say it's named "Modules." The
documentation calls it a "package."

2) In an explorer window or on the desktop, right click on My Computer,
and select Properties.

3) Select the Advanced tab, and click on Environment Variables near the
bottom.

4) Look for an environment variable named PYTHONPATH.

b) If there's already a PYTHONPATH, Edit it, adding a semi-colon
and the full path of folder Module to the end.

5) Put your module folders into the folder Module.

== 2 of 2 ==
Date: Sun, Jan 17 2010 8:15 pm
From: alex23

On Jan 18, 12:30 pm, Jive Dadson <notonthe...@noisp.com> wrote:
> These instructions are for MS Windows.
>
> 1) Create your modules folder. Let's say it's named "Modules." The
> documentation calls it a "package."
>
> 2) In an explorer window or on the desktop, right click on My Computer,
> and select Properties.
>
> 3) Select the Advanced tab, and click on Environment Variables near the
> bottom.
>
> 4) Look for an environment variable named PYTHONPATH.
>
> a) If you do not find one, create one using the New button(s). I
> don't know if it has to be in User Variables or System Variables. To
> save time experimenting, I just put one in both. For the value, put the
> full path of the folder Modules.
>
> b) If there's already a PYTHONPATH, Edit it, adding a semi-colon
> and the full path of folder Module to the end.
>
> 5) Put your module folders into the folder Module.
>
> 6) (Here's a really arcane bit.) Into each module folder, put a file
> named __init__.py. It will be executed when you load the module. It
> can be empty, but it has to be there or else the module folder will be
> ignored.

Actually, if you're using Python 2.6+/3.x, you can effectively skip
steps 1-5, as these versions now support user site-packages.

Rather than create a Module folder and modify your PYTHONPATH, add (if
it doesn't exist already) the following folder:
%APPDATA%/Python/Python26/site-packages

Modules can sit directly in the folder, or within packages.

For more details: http://www.python.org/dev/peps/pep-0370/

==============================================================================
TOPIC: py2exe and pydocs. Downloads?
http://groups.google.com/group/comp.lang.python/t/5567fec77f2aff83?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Jan 17 2010 7:40 pm
From: "Gabriel Genellina"

En Sun, 17 Jan 2010 19:43:25 -0300, W. eWatson <wolftracks@invalid.com>
escribió:

> According to Lutz's 4th edition (reading from Amazon), Pydoc is shipped
> with Python. I found this earlier in the Python Help under Global Index
> for modules.
> ==========================
> The pydoc module automatically generates documentation from Python
> modules. The documentation can be presented as pages of text on the
> console, served to a Web browser, or saved to HTML files.
>
> The built-in function help() invokes the online help system in the
> interactive interpreter, which uses pydoc to generate its documentation
> as text on the console. The same text documentation can also be viewed
> from outside the Python interpreter by running pydoc as a script at the
> operating system's command prompt. For example, running
>
>
> pydoc sys
>
> at a shell prompt
> =========================
> I get:
> >>> import pydoc
> >>> pydoc sys
> SyntaxError: invalid syntax
> >>>
> The book says Help uses it, and there's some sort of html version, but
> I'm missing something here. Command line, Linux shell?

From *inside* the Python interpreter:

py> import sys
py> help(sys)
Help on built-in module sys:

NAME
sys

FILE
(built-in)
[...lots of info...]

py> help("sys")
Help on built-in module sys:
[...same info...]

From the system command line (shell, command prompt, DOS box...), assuming
you're using 2.5 or later:

c:\temp>python -m pydoc sys
Help on built-in module sys:
[...same info...]

C:\TEMP>python -m pydoc
pydoc - the Python documentation tool

pydoc.py <name> ...
Show text documentation on something. <name> may be the name of a
Python keyword, topic, function, module, or package, or a dotted
reference to a class or function within a module or module in a
package. If <name> contains a '\', it is used as the path to a
Python source file to document. If name is 'keywords', 'topics',
or 'modules', a listing of these things is displayed.

pydoc.py -k <keyword>
Search for a keyword in the synopsis lines of all available modules.

pydoc.py -p <port>
Start an HTTP server on the given port on the local machine.

pydoc.py -g
Pop up a graphical interface for finding and serving documentation.

pydoc.py -w <name> ...
Write out the HTML documentation for a module to a file in the current
directory. If <name> contains a '\', it is treated as a filename; if
it names a directory, documentation is written for all the contents.

Try the -g option; it lets you search for the relevant documentation and
show it on your favorite web browser (locally).

Depending on how you installed Python, you may find a 'pydoc' or
'pydocgui' script somewhere in your Python directory.

--
Gabriel Genellina

==============================================================================
TOPIC: Is python not good enough?
http://groups.google.com/group/comp.lang.python/t/d3d14948773bff74?hl=en
==============================================================================

== 1 of 1 ==
Date: Sun, Jan 17 2010 7:54 pm
From: alex23

Blog <Blogtes...@gmail.com> wrote:
> Have you not heard about the "Unladen Swallow" project from google?
> There's a new PEP coming up which will propose google's codebase to be
> merged with Py3k, resulting in superior performance.

This kind of worries me for a number of reasons:
* unladen is _way_ too immature and unproven a project to replace the
current implementation,
* Google themselves have stressed they're only concerned with
improvements that benefit their use cases, such that
* other benchmarks appear to perform _worse_ under unladen, and
* has the project even posted substantive enough gains to warrant
this change? that didn't seem to be the situation when I last checked
* so far, the speed improvements have come at a cost of significantly
higher memory use (i believe it was ~10 times that of CPython at one
point)

I dunno, I kinda feel about Unladen Swallow the exact same way I do
about Go: if it wasn't a Google project, I really doubt it would be
getting the attention it is (over the other performance enhancement
projects: cython, psyco2, pypi et al)

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

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

Sunday, January 17, 2010

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

0 Comments:

Post a Comment

About Me

Previous Posts