[Tutor] Installing psutil 2.2.0-1 on Canopy Enthought
I use MAC OSX 10.9.5 Canopy Enthought python 2.7.6 I also use the Enthought Package Manager to keep my installation up-todate. For about two weeks now, Canopy says that I need to install psutil 2.2.0-1 instead of the currently installed version 2.1.1. I appear to do that successfully, but the next day the Package manager says to install the updated psutil. When I import psutil I get no error message. And when I do: psutil.__version__ , I get back '2.1.1', which is the old version, and I have just apparently succesfully udated the package. What in fact is my problem? I simply want to update this package, and I cannot. I do not know if this is the best Forum to get advice on this, but any guidance, including where else I might ask would be appreciated. -- Sydney ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
[Tutor] Class errors
Dear All,
I created a class that invoke from another file another class
I get an error that I do not understand: gobal name Job is not defined
However If I see the class imported I found the class Job.
Any suggestion or example on class invoke another class
#job,py
class Jobs:
.
#trial.py
from core.job import *
class Second:
def __initi__:
tp = open("/tmp/file.txt")
def gus(self):
tr = Job()
thanks so much!1
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Class errors
On Thu, Jan 22, 2015 at 8:11 AM, jarod...@libero.it wrote:
> Dear All,
>
> I created a class that invoke from another file another class
> I get an error that I do not understand: gobal name Job is not defined
Please use copy-and-paste. You just typed out the error message by
hand: we can tell because the error message you're presenting is
misspelled. Copy-and-paste it, as well as the surrounding text around
it.
> However If I see the class imported I found the class Job.
Ok. But where? In the code you present:
> #job,py
> class Jobs:
> .
>
> #trial.py
>
> from core.job import *
> class Second:
> def __initi__:
> tp = open("/tmp/file.txt")
>
> def gus(self):
> tr = Job()
I don't see a class named 'Job'. I see a class named 'Jobs' defined
in 'job.py', but that's a different class.
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor
[Tutor] Fwd: Testing a string to see if it contains a substring
-- Forwarded message -- From: dw Date: Thu, Jan 22, 2015 at 7:49 AM Subject: Re: [Tutor] Testing a string to see if it contains a substring To: Danny Yoo Hi Danny. Thanks for your email. The number of elements could start out as up to 500. But since they are short string elements, even that amount won't be a problem for in-ram memory. The eventual module is designed to ensure that the max elements count will be kept at 53. I'm playing with a module that will remove files that are created as archives weekly. Right now we have about 3 years and they are starting to eat up hard-drive. So I'm playing with a module that will remove the oldest files based on their creation date. And keep the max count of them to 52(1 years worth of archives) Thanks for the additional explanation of the search() returning a match or None. Many thanks my friend!! Duane On Wed, Jan 21, 2015, at 05:13 PM, Danny Yoo wrote: > How large will your array be in production? > > If it going to be very large, you may want to consider a database. > You're simulating a collection of records as an in-memory sequence of > flat strings. This design won't scale, so if you are working with a > lot of data, you may want to look into a dedicated database. > > > > > This method works really well when the regex date characters are found. > > It returns the value 0 to misc_int1 because the date regex starts at 0 > > position. > > I was hoping the .start() method would return a -1 value for the > > instance in which the regex search string is not found. > > That way I could iterate through the elements and retain only the valid > > ones. > > With regards to your original question: the return type of a search() > is either a match object, or a None. So your program's control-flow > logic should be accounting for these two possibilities. At the > moment, the code assumes that it always gets a match object, but that > assumption doesn't hold and explains why you're seeing run-time error > messages. -- bw...@fastmail.net ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
[Tutor] Does the Python way of doing things have a definite preference for the structure and content of program file header comments?
And will this vary depending on whether a version control system is being used or not? Or is the use of a version control system considered to be highly recommended (if not mandatory)? -- boB ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Class errors
On 22Jan2015 17:11, jarod...@libero.it wrote:
I created a class that invoke from another file another class
I get an error that I do not understand: gobal name Job is not defined
However If I see the class imported I found the class Job.
Any suggestion or example on class invoke another class
First, please cut/paste error messages, filenames and code. Do not hand type
them, as that introduces errors.
#job,py
For example, I suspect you mean "job.py", not "job,py".
class Jobs:
.
#trial.py
from core.job import *
It is not recommended to import "*". Just impor the names you need. It avoids
_unexpected_ names leaking into your program: you might be using such a name
for something else!
class Second:
def __initi__:
tp = open("/tmp/file.txt")
def gus(self):
tr = Job()
Because you have hand typed things I cannot be sure - it may just be a mistake
- but "job.py" defines a class "Jobs". In "trial.py" you use the name "Job".
Not the same!
Cheers,
Cameron Simpson
Beware of bugs in the above code; I have only proved it correct, not tried it.
- Donald E. Knuth
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Does the Python way of doing things have a definite preference for the structure and content of program file header comments?
On 22/01/15 21:17, boB Stepp wrote: And will this vary depending on whether a version control system is being used or not? Or is the use of a version control system considered to be highly recommended (if not mandatory)? Virtually nothing in Python is mandatory - unless you plan on putting your code in the standard library. But the standard library is aq good template to follow... As to headers, I tend to put version control type stuff in real comments (author, version, date etc) and put comments about functionality in doc strings where the help() function can find them. There is a kind of standard presentation of doc strings; use help a few times and you'll see. But it's not mandatory in as much as everything will continue to work if you ignore the conventions. -- Alan G Author of the Learn to Program web site http://www.alan-g.me.uk/ http://www.amazon.com/author/alan_gauld Follow my photo-blog on Flickr at: http://www.flickr.com/photos/alangauldphotos ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Installing psutil 2.2.0-1 on Canopy Enthought
On 22/01/15 12:56, Sydney Shall wrote: I use MAC OSX 10.9.5 Canopy Enthought python 2.7.6 I also use the Enthought Package Manager to keep my installation up-todate. Canopy and Enthoughts paqckage management are well beyond the bounds of standard Python. What in fact is my problem? I simply want to update this package, and I cannot. I do not know if this is the best Forum to get advice on this, but any guidance, including where else I might ask would be appreciated. I'd try the Enthought/Canopy forums. Or perhaps even the SciPy forums because Canopy has SciPy as standard (along with a bunch of other stuff) -- Alan G Author of the Learn to Program web site http://www.alan-g.me.uk/ http://www.amazon.com/author/alan_gauld Follow my photo-blog on Flickr at: http://www.flickr.com/photos/alangauldphotos ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Does the Python way of doing things have a definite preference for the structure and content of program file header comments?
boB Stepp writes: > And […] Could you write a message body that asks the question? (The Subject field isn't part of the message body.) As it is, I'm not sure what in particular you're asking about. -- \ “Are you thinking what I'm thinking, Pinky?” “Uh... yeah, | `\ Brain, but where are we going to find rubber pants our size?” | _o__) —_Pinky and The Brain_ | Ben Finney ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Does the Python way of doing things have a definite preference for the structure and content of program file header comments?
On Thu, Jan 22, 2015 at 03:17:58PM -0600, boB Stepp hid the following
question in the subject line:
"Does the Python way of doing things have a definite preference for the
structure and content of program file header comments?"
and then wrote:
> And will this vary depending on whether a version control system is
> being used or not? Or is the use of a version control system
> considered to be highly recommended (if not mandatory)?
This is a language-agnostic question, it is not specific to Python. It
may be a question about the community of users for a language, but in
principle at least it applies to *every language*.
I'm not entirely sure what you mean by "program file header comments",
can you give an example?
As far as version control, I consider it *absolutely essential* for
anyone who is serious about programming professionalism. Clearly,
however, I'm not serious, because I only use it about 50% of the time
*wink*
I consider the use of a DVCS (Distributed Version Control System) such
as Mercurial or Git to be Best Practice for professional programmers and
highly recommended for non-professionals. In this case, I'm referring to
professionalism, not necessarily whether you are paid to program.
DVCS is, in some ways, akin to having backups: if you're a home user who
only uses the computer for playing games, you probably don't care about
backups ("I lost my Minesweeper top scores!!! What shall I do???"), but
for everyone else backups of some type or another are essential if you
are treating your computer seriously.
If you are collaborating with other programmers (or at least *hope* to
collaborate with others), using a DVCS is all but mandatory, but if
you're just working on your own, you can avoid using one. You probably
shouldn't -- even for a single user programming alone, a DVCS makes it
easier to experiment with your code without fear of irreversibly
breaking things.
Example: some years ago, before starting to use version control, I had a
working script that I wanted to experiment on. So I made a copy of it,
and edited the copy. Well, one thing lead to another, and at some point
I broke the script so badly that I decided to throw it away and start
again, which I did.
Except that somehow I somehow managed to delete the original, so I was
left with a non-working, heavily modified (to the point that it was
almost unrecognisable) copy, and a .pyc (compiled byte-code) version of
the original, but no source code to the original. Had I been working
with version control, fixing this would have been easy. But I wasn't.
Eventually, after many tears and much sweat, I was able to reconstruct
most of the original from memory, the broken copy, and the byte-code in
the .pyc file. I had no tests either, so to this day I cannot be sure
that what I reconstructed does exactly what the original did, or whether
I have introduced bugs. I surely have, but if I had tests for it, I
would have quickly discovered where the bugs lie.
So even for a lone programmer who doesn't share his work with others,
using version control can be a good thing.
As far as the Python community goes, that depends. The Python community
is really many little subcommunities only linked by their use of Python.
People working on Open Source projects these days pretty much always use
a version control system. Business programmers may, or may not, it
depends on whether or not they apply best practices.
Does this help answer your question?
--
Steve
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor
[Tutor] Class learning
Dear All
How can gave the attributes __name__ to a function?
class Foo(object):
def __init__(self):
steps = {}
tmp = open("rnaseq.base.ini","rb")
config.readfp(tmp)
readsets =
parse_illumina_readset_file("/home/mauro/Desktop/readset.csv")
@property
def steps(self):
return [
self.one,
self.two,
self.fmit,
]
def one(self):
a = 5
return a
def two(self):
b = 5
return b
def fmit(self):
c = 7
return c
#@property
def show(self):
ftp="\n".join([str(idx + 1) + "- " + step.__name__ for idx, step in
enumerate(self.steps)])
print ftp
It is working
In [5]: F = Foo()
In [6]: F.show()
1- one
2- two
3- fmit
Why if I define the data in the same way I have this error?
in ()
> 1 rna.show()
in show(self)
261 #@property
262 def show(self):
--> 263 ftp="\n".join([str(idx + 1) + "- " + step.__name__ for
idx, step in enumerate(self.steps)])
264
265 print ftp
AttributeError: 'str' object has no attribute '__name__'
Here you find all the other code the principal are the
same:http://pastebin.com/nYGEiXY4
rna = Rnaseq()
rna.show()
thanks so much!!
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Does the Python way of doing things have a definite preference for the structure and content of program file header comments?
On Thu, Jan 22, 2015 at 5:25 PM, Ben Finney wrote: > boB Stepp writes: > >> And […] > > Could you write a message body that asks the question? (The Subject > field isn't part of the message body.) Does the Python way of doing things have a definite preference for the structure and content of program file header comments? > As it is, I'm not sure what in particular you're asking about. I am asking about what is considered "good practice" in what to include in the introductory comments to a program, just after the shebang line. I had done a web search, but had found a surprising variety of thoughts on this. Since the Python community culture seems to have strong opinions on making code and its explanation (where needed) as simple, direct and clear as possible, I was wondering if there existed similar opinions about this area of program comments. Some opinions (paraphrased from memory) I've found on this: 1) College courses usually have some blurb about including the course name, assignment name/number and an explanation of what the program proposes to do. 2) Some advise including information such as the file name, other files called by the program, global variables used, etc. Others advise that this type of information is superfluous and should not be included. 3) Most of what I found advised a brief statement of the program's purpose. 4) Most mentioned that the code's author should be stated and the date of creation. 5) Some advised to keep the change log/version info here. Others very strongly said no way, that is the function of version control systems, which make such records redundant and just something that might not be kept up to date. 6) Etc. -- boB ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Does the Python way of doing things have a definite preference for the structure and content of program file header comments?
On Thu, Jan 22, 2015 at 5:45 PM, Steven D'Aprano wrote: > On Thu, Jan 22, 2015 at 03:17:58PM -0600, boB Stepp hid the following > question in the subject line: > > "Does the Python way of doing things have a definite preference for the > structure and content of program file header comments?" > > and then wrote: > >> And will this vary depending on whether a version control system is >> being used or not? Or is the use of a version control system >> considered to be highly recommended (if not mandatory)? > > This is a language-agnostic question, it is not specific to Python. It > may be a question about the community of users for a language, but in > principle at least it applies to *every language*. I was wondering if the Python culture had their own particular take on these types of comments. > I'm not entirely sure what you mean by "program file header comments", > can you give an example? I outlined what I meant in my response to Ben Finney. Briefly, just the introductory/explanatory comments made at the very beginning of a program, describing its purpose, the author, etc. > As far as version control, I consider it *absolutely essential* for > anyone who is serious about programming professionalism. Clearly, > however, I'm not serious, because I only use it about 50% of the time > *wink* > > I consider the use of a DVCS (Distributed Version Control System) such > as Mercurial or Git to be Best Practice for professional programmers and > highly recommended for non-professionals. In this case, I'm referring to > professionalism, not necessarily whether you are paid to program. I am striving hard to at least make myself aware of what constitutes "professionalism" in software creation. I fully intend to go in your stated direction, but finding time to become proficient in such a tool in the midst of all the other things I am trying to absorb is difficult. However, my mention of version control was in response to a web search where many said that including change logs/version history in a program's header comments is made unnecessary by modern version control systems and is even harmful in that it might lead to unmaintained comments. OTH, there seemed to be plenty of others who advocate that this information should indeed be included in the program's header comments. [...] > Example: some years ago, before starting to use version control, I had a > working script that I wanted to experiment on. So I made a copy of it, > and edited the copy. Well, one thing lead to another, and at some point > I broke the script so badly that I decided to throw it away and start > again, which I did. > > Except that somehow I somehow managed to delete the original, so I was > left with a non-working, heavily modified (to the point that it was > almost unrecognisable) copy, and a .pyc (compiled byte-code) version of > the original, but no source code to the original. Had I been working > with version control, fixing this would have been easy. But I wasn't. > Eventually, after many tears and much sweat, I was able to reconstruct > most of the original from memory, the broken copy, and the byte-code in > the .pyc file. I had no tests either, so to this day I cannot be sure > that what I reconstructed does exactly what the original did, or whether > I have introduced bugs. I surely have, but if I had tests for it, I > would have quickly discovered where the bugs lie. Ugh! Unfortunately I have mirrored your example recently, which has had me wondering whether I should "make" time to implement a DVCS. And I simply MUST learn how to do test driven development and how to automate such testing. Dave Angel was absolutely correct (Of course!) that manual testing is insufficient. The things I am starting to try to do are just getting too large and complex for manual testing and manual backups. > So even for a lone programmer who doesn't share his work with others, > using version control can be a good thing. "The Pragmatic Programmer" and some other books I have read in the past couple of years along with your and other's comments on this list make it sound better than the invention of sliced bread! > As far as the Python community goes, that depends. The Python community > is really many little subcommunities only linked by their use of Python. > People working on Open Source projects these days pretty much always use > a version control system. Business programmers may, or may not, it > depends on whether or not they apply best practices. "Best practices". "Software craftsmanship". Clarity of code. And more... As I continue to learn I am appreciating these things more and more, especially when I must suffer multi-day interruptions to the project I am working on and have to reconstruct what I had last been doing/thinking. I find myself almost constantly trying to rename things to make them more self-explanatory, break things down into more self-contained, single-purpose constructs, etc. Trying to make my code more "obviou
Re: [Tutor] Does the Python way of doing things have a definite preference for the structure and content of program file header comments?
boB Stepp writes: > Does the Python way of doing things have a definite preference for the > structure and content of program file header comments? To my knowledge, the term “program file header comments” for Python would best describe a module docstring; not a comment, but documentation https://docs.python.org/3/glossary.html#term-docstring>. It seems from what follows that this is what you're asking about; I'll assume so. > I am asking about what is considered "good practice" in what to > include in the introductory comments to a program, just after the > shebang line. I would consider it good practice to have a copyright statement and a grant of license at the top; a handful of lines should suffice. That way it's very easy for anyone diving into the code (as programmers tend to do when looking around a code base) to see what rights they have been granted to the code, without needing to engage in a lot of effort. But none of that belongs in the docstring. > I had done a web search, but had found a surprising variety of > thoughts on this. Since the Python community culture seems to have > strong opinions on making code and its explanation (where needed) as > simple, direct and clear as possible, I was wondering if there existed > similar opinions about this area of program comments. There is PEP 257 https://www.python.org/dev/peps/pep-0257/> which defines the format a docstring should conform to. As for the content, I would advise the module docstring should contain a concise description of the module's purpose, and anything unusual about its API. Consider that the primary reader of that content will be a programmer using the Python interactive help (e.g. ‘pydoc’). > Some opinions (paraphrased from memory) I've found on this: > 1) College courses usually have some blurb about including the > course name, assignment name/number and an explanation of what the > program proposes to do. That might be useful depending on the institution, I suppose. > 2) Some advise including information such as the file name, other > files called by the program, global variables used, etc. Others advise > that this type of information is superfluous and should not be > included. Right, a lot of that should either be in unit tests, or gathered automatically from introspection tools. Writing it in manually-maintained comments invites the comments and code getting out of sync without anyone realising the error. > 3) Most of what I found advised a brief statement of the program's > purpose. That definitely belongs in the module docstring, IMO. Anyone reading ‘pydoc’ or other interactive help is likely to need a reminder of this module's intended purpose. > 4) Most mentioned that the code's author should be stated and the > date of creation. Not in the docstring, but I certainly want to see a concise copyright statement and grant of license (under free-software terms, please). > 5) Some advised to keep the change log/version info here. Others > very strongly said no way, that is the function of version control > systems, which make such records redundant and just something that > might not be kept up to date. Certainly, the VCS is the correct repository of that information. Duplicating it leads to disagreements between the VCS and the code comments as to the history of the file. > 6) Etc. Hope that helps. -- \ “For fast acting relief, try slowing down.” —Jane Wagner, via | `\ Lily Tomlin | _o__) | Ben Finney ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Does the Python way of doing things have a definite preference for the structure and content of program file header comments?
Ben Finney writes: > I would consider it good practice to have a copyright statement and a > grant of license at the top; a handful of lines should suffice. > […] > But none of that belongs in the docstring. > > […] > There is PEP 257 https://www.python.org/dev/peps/pep-0257/> which > defines the format a docstring should conform to. > > As for the content, I would advise the module docstring should contain a > concise description of the module's purpose, and anything unusual about > its API. Consider that the primary reader of that content will be a > programmer using the Python interactive help (e.g. ‘pydoc’). An example:: # -*- coding: utf-8 -*- # foo/frob.py # Part of FooBar, a garden gnome decoration library. # # Copyright © 2011–2015 Ben Finney # # This is free software: you may copy, modify, and/or distribute this work # under the terms of the GNU General Public License as published by the # Free Software Foundation; version 3 of that license or any later version. # No warranty expressed or implied. See the file ‘LICENSE.GPL-3’ for details. """ Functionality to frobnicate spangules. Each frobnicator conforms to the Weebly-Ruckford standard https://example.com/dingle/dangle/> for input and output vraxen. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Quisque commodo elit eget odio hendrerit sollicitudin ac eget felis. Praesent cursus accumsan vehicula. Nullam ac euismod quam, tincidunt maximus augue. """ from __future__ import (absolute_import, unicode_literals) … Much of the comment block is there to aid the reader who wants to know their rights. What is this file? What work is it part of? What rights are granted in this work? Who holds copyright and when? Which file in this code base contains the full license text? These are at the top of each file because frequently a code base will amalgamate files with different copyright holders, different copyright years, different license grants, etc. so it's necessary to answer the questions specifically for each file. Note that the docstring has a single-line synopsis of the module's purpose; the remaining paragraphs say only what is likely to be of interest to the reader of interactive help for the module. The copyright and other administrivia don't belong there. Note these absences: * No full license text. The *grant* of license is there so the reader knows a license is granted and what they can do, but the full terms can go into a separate named file included in the code base. * No history of changes. The VCS of the code base is the canonical place where that information should be, and a separate “ChangeLog” document in the code base can be maintained for a higher-level, feature-based change history of interest to recipients. * Details of the contents of the file. Any objects created in the module are available via introspection tools, so duplicating them manually is again inviting discrepancies between comments and code. Hopefully that's some guidance in forming a convention on this matter. -- \ “Religious faith is the one species of human ignorance that | `\ will not admit of even the *possibility* of correction.” —Sam | _o__) Harris, _The End of Faith_, 2004 | Ben Finney ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
