kj wrote:
...
Through a *lot* of trial an error I finally discovered that the
root cause of the problem was the fact that, in the same directory
as buggy.py, there is *another* innocuous little script, totally
unrelated, whose name happens to be numbers.py.
The right answer to this is to
On Fri, Feb 5, 2010 at 12:16 PM, John Nagle na...@animats.com wrote:
kj wrote:
Through a *lot* of trial an error I finally discovered that the
root cause of the problem was the fact that, in the same directory
as buggy.py, there is *another* innocuous little script, totally
unrelated, whose
Stephen Hansen wrote:
On Fri, Feb 5, 2010 at 12:16 PM, John Nagle na...@animats.com
mailto:na...@animats.com wrote:
kj wrote:
Through a *lot* of trial an error I finally discovered that the
root cause of the problem was the fact that, in the same directory
as
John Nagle wrote:
kj wrote:
...
Through a *lot* of trial an error I finally discovered that the
root cause of the problem was the fact that, in the same directory
as buggy.py, there is *another* innocuous little script, totally
unrelated, whose name happens to be numbers.py.
The right
On 03/02/2010 16:17, kj wrote:
Boy, that was dumb of me. The above apology was meant for Stephen
Hansen, not Steve Holden. I guess this is now a meta-apology...
(Sheesh.)
You see? That's what I like about the Python community:
people even apologise for apologising :)
TJG
--
Tim Golden wrote:
On 03/02/2010 16:17, kj wrote:
Boy, that was dumb of me. The above apology was meant for Stephen
Hansen, not Steve Holden. I guess this is now a meta-apology...
(Sheesh.)
You see? That's what I like about the Python community:
people even apologise for apologising :)
Steve, I apologize for the snarkiness of my previous reply to you.
After all, I started the thread by asking the forum for advice on
how to avoid a certain kind of bugs, you were among those who gave
me advice. So nothing other than thanking you for it was in order.
I just let myself get
In hkbv23$c0...@reader2.panix.com kj no.em...@please.post writes:
Steve, I apologize for the snarkiness of my previous reply to you.
After all, I started the thread by asking the forum for advice on
how to avoid a certain kind of bugs, you were among those who gave
me advice. So nothing other
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.
Don't give it another thought. I'd much rather you cared than you didn't ...
regards
Steve
kj wrote:
Steve, I apologize for the snarkiness of my previous reply to you.
After all, I started the thread by asking the forum for advice on
how to avoid a certain kind of bugs, you were among
kj wrote:
In hkbv23$c0...@reader2.panix.com kj no.em...@please.post writes:
Steve, I apologize for the snarkiness of my previous reply to you.
After all, I started the thread by asking the forum for advice on
how to avoid a certain kind of bugs, you were among those who gave
me advice.
kj wrote:
I just spent about 1-1/2 hours tracking down a bug.
An innocuous little script, let's call it buggy.py, only 10 lines
long, and whose output should have been, at most two lines, was
quickly dumping tens of megabytes of non-printable characters to
my screen (aka gobbledygook), and in
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
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
On Feb 2, 3:28 am, Steven D'Aprano
ste...@remove.this.cybersource.com.au wrote:
There is no module numbers in the standard library, at least not in 2.5.
It's new in 2.6 (and 3.0, I think; it's there in 3.1, anyway). It
provides abstract base classes for numeric types; see the fractions
Carl Banks wrote:
On Feb 1, 7:33 pm, Tim Chase python.l...@tim.thechases.com wrote:
Stephen Hansen wrote:
First, I don't shadow built in modules. Its really not very hard to avoid.
Given the comprehensive nature of the batteries-included in
Python, it's not as hard to
Let me preface everything by thanking you and all those who
replied for their comments.
I have only one follow-up question (or rather, set of related
questions) that I'm very keen about, plus a bit of a vent at the
end.
In pan.2010.02.02.03.28...@remove.this.cybersource.com.au Steven D'Aprano
On 2010-02-02, Roy Smith r...@panix.com wrote:
In article hk82uv$8k...@reader1.panix.com, kj no.em...@please.post
wrote:
Through a *lot* of trial an error I finally discovered that the
root cause of the problem was the fact that, in the same directory
as buggy.py, there is *another*
On Tue, Feb 2, 2010 at 6:13 AM, kj no.em...@please.post wrote:
In pan.2010.02.02.03.28...@remove.this.cybersource.com.au Steven
D'Aprano ste...@remove.this.cybersource.com.au writes:
As for fixing it, unfortunately it's not quite so simple to fix without
breaking backwards-compatibility. The
On Tue, 02 Feb 2010 15:00:28 +, Grant Edwards wrote:
It turns out that buggy.py imports psycopg2, as you can see, and
apparently psycopg2 (or something imported by psycopg2) tries to
import some standard Python module called numbers; instead it ends
up importing the innocent
* Nobody:
On Tue, 02 Feb 2010 15:00:28 +, Grant Edwards wrote:
It turns out that buggy.py imports psycopg2, as you can see, and
apparently psycopg2 (or something imported by psycopg2) tries to
import some standard Python module called numbers; instead it ends
up importing the innocent
On 2/2/2010 9:13 AM, kj wrote:
As for fixing it, unfortunately it's not quite so simple to fix without
breaking backwards-compatibility. The opportunity to do so for Python 3.0
was missed.
This last point is to me the most befuddling of all. Does anyone
know why this opportunity was missed
On Feb 2, 9:02 am, Nobody nob...@nowhere.com 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
On Feb 2, 2:49 am, Jean-Michel Pichavant jeanmic...@sequans.com
wrote:
Carl Banks wrote:
Name your modules send_email.py or sort_email.py or if it's a
library module of related functions, email_handling.py. Modules and
scripts do things (usually), they should be given action words as
Carl Banks wrote:
On Feb 2, 2:49 am, Jean-Michel Pichavant jeanmic...@sequans.com
wrote:
Carl Banks wrote:
Name your modules send_email.py or sort_email.py or if it's a
library module of related functions, email_handling.py. Modules and
scripts do things (usually), they should be
In mailman.1795.1265135424.28905.python-l...@python.org Terry Reedy
tjre...@udel.edu writes:
On 2/2/2010 9:13 AM, kj wrote:
As for fixing it, unfortunately it's not quite so simple to fix without
breaking backwards-compatibility. The opportunity to do so for Python 3.0
was missed.
This
On Feb 2, 11:07 am, Jean-Michel Pichavant jeanmic...@sequans.com
wrote:
Carl Banks wrote:
On Feb 2, 2:49 am, Jean-Michel Pichavant jeanmic...@sequans.com
wrote:
Carl Banks wrote:
Name your modules send_email.py or sort_email.py or if it's a
library module of related functions,
Op 2010-02-02 18:02, Nobody schreef:
On Tue, 02 Feb 2010 15:00:28 +, Grant Edwards wrote:
It turns out that buggy.py imports psycopg2, as you can see, and
apparently psycopg2 (or something imported by psycopg2) tries to
import some standard Python module called numbers; instead it ends
On Feb 1, 6:34 pm, kj no.em...@please.post wrote:
An innocuous little script, let's call it buggy.py, only 10 lines
long, and whose output should have been, at most two lines, was
quickly dumping tens of megabytes of non-printable characters to
my screen (aka gobbledygook), and in the process
On Tue, Feb 2, 2010 at 1:38 PM, Roel Schroeven
rschroev_nospam...@fastmail.fm wrote:
Apparently, contrary to my expectations, Python looks in the directory
containing the currently running script instead. That means that the
behavior of import foo depends very much on circumstances not under
On 2/2/2010 2:43 PM, kj wrote:
Inmailman.1795.1265135424.28905.python-l...@python.org Terry
Reedytjre...@udel.edu writes:
On 2/2/2010 9:13 AM, kj wrote:
As for fixing it, unfortunately it's not quite so simple to fix without
breaking backwards-compatibility. The opportunity to do so for
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?
--
(For reasons I don't understand Stephen Hansen's posts don't show
in my news server. I became aware of his reply from a passing
reference in one of Terry Reedy's post. Then I found Hansen's post
online, and then an earlier one, and pasted the relevant portion
below.)
First, I don't shadow
In mailman.1804.1265150872.28905.python-l...@python.org Terry Reedy
tjre...@udel.edu writes:
On 2/2/2010 2:43 PM, kj wrote:
Inmailman.1795.1265135424.28905.python-l...@python.org Terry
Reedytjre...@udel.edu writes:
On 2/2/2010 9:13 AM, kj wrote:
As for fixing it, unfortunately it's not
kj wrote:
(For reasons I don't understand Stephen Hansen's posts don't show
in my news server. I became aware of his reply from a passing
reference in one of Terry Reedy's post. Then I found Hansen's post
online, and then an earlier one, and pasted the relevant portion
below.)
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
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
(This is no mere Python wart; this is a suppurating chancre, and
the fact that it remains unfixed is a neverending source of puzzlement
for me.)
How can the average Python programmer guard against this sort of
time-devouring bug in the future (while remaining a Python programmer)?
The only
This is kinda akin to creating your own libc.so in a folder where your
compiling and executing c programs and then wondering why your program bugs
out
On Mon, Feb 1, 2010 at 9:34 PM, kj no.em...@please.post wrote:
I just spent about 1-1/2 hours tracking down a bug.
An innocuous little
On Mon, Feb 1, 2010 at 6:34 PM, kj no.em...@please.post wrote:
I just spent about 1-1/2 hours tracking down a bug.
snip
Through a *lot* of trial an error I finally discovered that the
root cause of the problem was the fact that, in the same directory
as buggy.py, there is *another* innocuous
In article hk82uv$8k...@reader1.panix.com, kj no.em...@please.post
wrote:
Through a *lot* of trial an error I finally discovered that the
root cause of the problem was the fact that, in the same directory
as buggy.py, there is *another* innocuous little script, totally
unrelated, whose name
On Tue, 02 Feb 2010 02:34:07 +, kj wrote:
I just spent about 1-1/2 hours tracking down a bug.
An innocuous little script, let's call it buggy.py, only 10 lines long,
and whose output should have been, at most two lines, was quickly
dumping tens of megabytes of non-printable characters
Stephen Hansen wrote:
First, I don't shadow built in modules. Its really not very hard to avoid.
Given the comprehensive nature of the batteries-included in
Python, it's not as hard to accidentally shadow a built-in,
unknown to you, but yet that is imported by a module you are
using. The
On Mon, Feb 1, 2010 at 7:33 PM, Tim Chase python.l...@tim.thechases.comwrote:
Stephen Hansen wrote:
First, I don't shadow built in modules. Its really not very hard to avoid.
Given the comprehensive nature of the batteries-included in Python, it's
not as hard to accidentally shadow a
On Feb 1, 6:34 pm, kj no.em...@please.post wrote:
Both scripts live in a directory filled with *hundreds* little
one-off scripts like the two of them. I'll call this directory
myscripts in what follows.
[snip]
How can the average Python programmer guard against this sort of
time-devouring
On Feb 1, 7:33 pm, Tim Chase python.l...@tim.thechases.com wrote:
Stephen Hansen wrote:
First, I don't shadow built in modules. Its really not very hard to avoid.
Given the comprehensive nature of the batteries-included in
Python, it's not as hard to accidentally shadow a built-in,
unknown
46 matches
Mail list logo
