S
Steven D'Aprano
Hang on, you say that an explanation which is "quite incorrect" is
*better* than one which is correct?
I can see why they call the card "Madness".
Hang on, you say that an explanation which is "quite incorrect" is
*better* than one which is correct?
I can see why they call the card "Madness".
C
Chris Angelico
Hang on, you say that an explanation which is "quite incorrect" is
*better* than one which is correct?
I can see why they call the card "Madness".
Agreed about the ability name
The fact is, though, that when you'reexplaining something, it's often better to have a one-sentence
explanation that's not quite technically accurate than two paragraphs
explaining it in multiple steps and are opaque to anyone who doesn't
have the rules-lawyer mind. (I happen to have such a mind. It's not
always a good thing, but it makes me a better debugger.)
Does it really hurt to anthropomorphize and say that "Python looks for
modules in the directories in sys.path" instead of "Module lookup
consists of iterating over the elements in sys.path [and that's
leaving out the worst-case DFS where you explain THAT in detail],
calling combine_path [or whatever it is] with the element and the
module name, and attempting to stat/open the result"? While your
listener's getting bogged down in unnecessary detail, s/he isn't
grokking the overall purpose of what you're saying.
One option is more accurate. The other is far more helpful.
ChrisA
S
Steven D'Aprano
Don't anthropomorphise computers. They don't like it when you do.
I don't think so, I often talk about Python looking for files myself. The
intentional stance is an incredibly powerful technique for understanding
behaviour of all sorts of entities, sentient or not, from DNA to
computers to corporations, and even people.
But it does depend on context. Sometimes you need more detail than just
"Python looks". You need to know precisely *how* Python looks, and how it
decides whether it has found or not.
And note that I'm still using the intentional stance.
C
Chris Angelico
Agreed. So, looking back at the original context: A question was posed
that isn't really about Python at all, but more about file systems. I
gave a simple one-sentence answer that omitted heaps of details. It
didn't seem likely that someone confused by path names would be
changing the current directory inside the script, nor that the
distinction of who evaluates a path would be significant (how often
does _anyone_ care whether your path is parsed by Python, by the OS,
or by the underlying file system?).
ChrisA
D
Dennis Lee Bieber
Take into account that one of the detailed rules is that the text on
a card overrides the text in the rulebook.
S
subhabangalore
33:25 PM UTC+5:30, Chris Angelico wrote:
>> On Sun, Jul 8, 2012 at 3:42 PM, <[email protected]> wrote:
>> > file_open=open("/python32/doc1.txt","r"
>> Also, as has already been mentioned: keeping your data files in the
>> Python binaries directory isn't usually a good idea. More common to
>> keep them in the same directory as your script, which would mean that
>> you don't need a path on it at all.
> No file path! Amazing. I do not know I like to know one small example please.
open("doc1.txt","r"
Python will look for a file called doc1.txt in the directory you run
the script from (which is often going to be the same directory as your
.py program).
> Btw, some earlier post said, line.split() to convert line into bag of words can be done with power(), but I did not find it, if any one can help. I do close files do not worry. New style I'd try.
I don't know what power() function you're talking about, and can't
find it in the previous posts; the nearest I can find is a post from
Ranting Rick which says a lot of guff that you can ignore. (Rick is a
professional troll. Occasionally he says something useful and
courteous; more often it's one or the other, or neither.)
As to the closing of files: There are a few narrow issues that make it
worth using the 'with' statement, such as exceptions; mostly, it's
just a good habit to get into. If you ignore it, your file will
*usually* be closed fairly soon after you stop referencing it, but
there's no guarantee. (Someone else will doubtless correct me if I'm
wrong, but I'm pretty sure Python guarantees to properly flush and
close on exit, but not necessarily before.)
ChrisA
Dear Group,
The problem is more or less solved. Thank you for giving varied ways of thinking on the problem. Everytime I visit the group I learn so many things. Thank you all for taking your kind time to try to absolve the issue.
Regards,
Subhabrata Banerjee.
S
subhabangalore
33:25 PM UTC+5:30, Chris Angelico wrote:
>> On Sun, Jul 8, 2012 at 3:42 PM, <[email protected]> wrote:
>> > file_open=open("/python32/doc1.txt","r"
>> Also, as has already been mentioned: keeping your data files in the
>> Python binaries directory isn't usually a good idea. More common to
>> keep them in the same directory as your script, which would mean that
>> you don't need a path on it at all.
> No file path! Amazing. I do not know I like to know one small example please.
open("doc1.txt","r"
Python will look for a file called doc1.txt in the directory you run
the script from (which is often going to be the same directory as your
.py program).
> Btw, some earlier post said, line.split() to convert line into bag of words can be done with power(), but I did not find it, if any one can help. I do close files do not worry. New style I'd try.
I don't know what power() function you're talking about, and can't
find it in the previous posts; the nearest I can find is a post from
Ranting Rick which says a lot of guff that you can ignore. (Rick is a
professional troll. Occasionally he says something useful and
courteous; more often it's one or the other, or neither.)
As to the closing of files: There are a few narrow issues that make it
worth using the 'with' statement, such as exceptions; mostly, it's
just a good habit to get into. If you ignore it, your file will
*usually* be closed fairly soon after you stop referencing it, but
there's no guarantee. (Someone else will doubtless correct me if I'm
wrong, but I'm pretty sure Python guarantees to properly flush and
close on exit, but not necessarily before.)
ChrisA
Dear Group,
The problem is more or less solved. Thank you for giving varied ways of thinking on the problem. Everytime I visit the group I learn so many things. Thank you all for taking your kind time to try to absolve the issue.
Regards,
Subhabrata Banerjee.