On 2/2/2012 1:21 AM, Terry Reedy wrote:
On 2/2/2012 1:42 AM, Devin Jeanpierre wrote:
On Wed, Feb 1, 2012 at 2:53 PM, Terry Reedy
wrote:
And it bothers me that you imput such ignorance to me. You
made what I think
was a bad analogy and I made a better one of the same type,
though still
imperfe
On 2/2/2012 1:42 AM, Devin Jeanpierre wrote:
On Wed, Feb 1, 2012 at 2:53 PM, Terry Reedy wrote:
And it bothers me that you imput such ignorance to me. You made what I think
was a bad analogy and I made a better one of the same type, though still
imperfect. I acknowledged that the transition wil
On Wed, Feb 1, 2012 at 2:53 PM, Terry Reedy wrote:
> And it bothers me that you imput such ignorance to me. You made what I think
> was a bad analogy and I made a better one of the same type, though still
> imperfect. I acknowledged that the transition will take years.
Ah. It is a common attitude
On 2/1/2012 8:11 AM, John Roth wrote:
One other point: I'm unclear if a compiled module in the source
directory would be named spam.pyc or spam.cpython-32.pyc. I'd think
the latter to allow two versions of a compiled-only distribution.
By test, it has to be spam.pyc, as before.
--
Terry Jan R
On 2/1/2012 6:14 AM, Devin Jeanpierre wrote:
It really bothers me that you imagine that there are no other problems
than the newness.
And it bothers me that you imput such ignorance to me. You made what I
think was a bad analogy and I made a better one of the same type, though
still imperfec
On Jan 31, 4:43 pm, Terry Reedy wrote:
> On 1/31/2012 3:20 PM, John Roth wrote:
>
> > On Jan 30, 3:43 pm, Terry Reedy wrote:
> >> On 1/30/2012 4:30 PM, Roy Smith wrote:
>
> >>> Every so often (typically when refactoring), I'll remove a .py file
> >>> and forget to remove the corresponding .pyc fi
On Tue, Jan 31, 2012 at 6:55 PM, Terry Reedy wrote:
> Q. "How do I make my old model car do something (it cannot do)?"
> A. "Get the free new model that has that feature added."
>
> Of course, there is a cost to giving up the old and familiar and learning
> and adjusting to the new, even when it i
On 1/31/2012 11:14 PM, Roy Smith wrote:
We would love to move to 3.x, for the better unicode support, if nothing
else. What's keeping us from doing so is the host of third-party
modules and tools we depend on that don't yet support 3.x.
Tell that to the authors of packages you use so they no
Terry Reedy wrote:
On 1/31/2012 9:19 AM, Jean-Michel Pichavant wrote:
A: "My wheel is flat"
B: "Buy a new car"
A better analogy would be
Q. "How do I make my old model car do something (it cannot do)?"
A. "Get the free new model that has that feature added."
Of course, there is a cost to gi
In article ,
Terry Reedy wrote:
> But I am sure that 95% of readers here will be using 3.x withing 10
> years. The only question for them is "When?". This not-well-known new
> feature is one straw that some will put on the 'sooner' side of the balance.
We would love to move to 3.x, for the be
On 1/31/2012 9:19 AM, Jean-Michel Pichavant wrote:
A: "My wheel is flat"
B: "Buy a new car"
A better analogy would be
Q. "How do I make my old model car do something (it cannot do)?"
A. "Get the free new model that has that feature added."
Of course, there is a cost to giving up the old and
On 1/31/2012 3:20 PM, John Roth wrote:
On Jan 30, 3:43 pm, Terry Reedy wrote:
On 1/30/2012 4:30 PM, Roy Smith wrote:
Every so often (typically when refactoring), I'll remove a .py file
and forget to remove the corresponding .pyc file. If I then import
the module, python finds the orphaned .p
On Jan 30, 3:43 pm, Terry Reedy wrote:
> On 1/30/2012 4:30 PM, Roy Smith wrote:
>
> > Every so often (typically when refactoring), I'll remove a .py file
> > and forget to remove the corresponding .pyc file. If I then import
> > the module, python finds the orphaned .pyc and happily imports it.
>
Steven D'Aprano wrote:
On Tue, 31 Jan 2012 11:26:10 +0100, Jean-Michel Pichavant wrote:
Terry Reedy wrote:
On 1/30/2012 4:30 PM, Roy Smith wrote:
Every so often (typically when refactoring), I'll remove a .py file
and forget to remove the corresponding .pyc file. If I then imp
On Tue, 31 Jan 2012 11:26:10 +0100, Jean-Michel Pichavant wrote:
> Terry Reedy wrote:
>> On 1/30/2012 4:30 PM, Roy Smith wrote:
>>> Every so often (typically when refactoring), I'll remove a .py file
>>> and forget to remove the corresponding .pyc file. If I then import
>>> the module, python fin
Jean-Michel Pichavant writes:
> Terry Reedy wrote:
> > On 1/30/2012 4:30 PM, Roy Smith wrote:
> >> Is there some way to globally tell python, "Never import a .pyc
> >> unless the corresponding .py file exits"?
> >
> > Upgrade to 3.2.
> >
> No.
Terry's response was an answer to “Is there some way
On 01/30/2012 09:30 PM, Roy Smith wrote:
Every so often (typically when refactoring), I'll remove a .py file and forget
to remove the corresponding .pyc file. If I then import the module, python
finds the orphaned .pyc and happily imports it. Usually leading to confusing
and hard to debug fa
Terry Reedy wrote:
On 1/30/2012 4:30 PM, Roy Smith wrote:
Every so often (typically when refactoring), I'll remove a .py file
and forget to remove the corresponding .pyc file. If I then import
the module, python finds the orphaned .pyc and happily imports it.
Usually leading to confusing and ha
On 1/30/2012 4:30 PM, Roy Smith wrote:
Every so often (typically when refactoring), I'll remove a .py file
and forget to remove the corresponding .pyc file. If I then import
the module, python finds the orphaned .pyc and happily imports it.
Usually leading to confusing and hard to debug failures
Not that I'm aware of.
I have a script that run the test suite, one of the first commands (before
calling nosetests) is:
find . -name '*.py[co]' -exec rm {} \;
This makes sure the tests run in a "clean" environment.
--
http://mail.python.org/mailman/listinfo/python-list
Every so often (typically when refactoring), I'll remove a .py file and forget
to remove the corresponding .pyc file. If I then import the module, python
finds the orphaned .pyc and happily imports it. Usually leading to confusing
and hard to debug failures.
Is there some way to globally tell
21 matches
Mail list logo