On Friday, January 23, 2015 at 1:59:38 PM UTC-6, Chris Angelico wrote:
> On Sat, Jan 24, 2015 at 6:48 AM, Sir Rick Johnson wrote:
> > On Thursday, January 22, 2015 at 10:04:29 PM UTC-6, Chris Angelico wrote:
> >
> >> It's worth pointing out, too, that the idea isn't
> >> panaceaic - it's just another tool in the box. Any time
> >> you break related things into separate places, especially
> >> separate files, the tendency for them to get out of sync
> >> grows dramatically.
> >
> > I wonder how that "poor python interpreter" keeps all those
> > .pyc and .pyo files in sync with constantly changing source
> > code? It should be tantamount to torture! Will someone
> > *PLEASE* start a charity site titled: "Python's sanity fund"?
>
> That's where one is directly derived from the other. Edit the .py
> file, rebuild the .pyc from it. Any dumb machine can do that... as
> long as timestamps can be relied on, the hard drive is correctly
> retaining data, etc, etc, etc.
Okay, you make a fair point, so let's dig beyond the
superficiality and find the truth shall we? I don't care who
wins, i just want to find the truth.
Your assertion is that since "external hints" are not
directly visible when reading source (as they would be in
func sigs) that the author will forget to update them???
Heck, do you ever read comments? Many of them are not only
out of sync with the code they describe (because an author
forgot to update a corresponding comment after changing the
code), in some cases, they are not even in sync with
*REALITY* (this case being where the author cannot
articulately describe what the code is doing and the
comments become misleading)
Yes, there are programmers out there who can write
perfectly functioning code but cannot describe what
it is doing with even a modicum of coherency! Do the
phrase "word salad" mean anything to you?
So after observing the lunacy of comment authors, arguing
that by placing hints in source (as opposed to exporting them
to stub files) is somehow going to "magically enforce"
synchronicity -- you have more faith in others than i do!
> And guess what? Python isn't perfect at it. I had a
> bizarre problem a while ago that came down to an incorrect
> .pyc file in the stdlib. (I still have no idea how that
> came to be incorrect. The hard drive doesn't seem to be
> failing, and the corruption in the file looks more like a
> software bug than a hardware issue.)
I too have encountered, when doing some heavy *EDIT-RUN-
EDIT* sessions, where Python was still using an old pyc file
that did not correctly sync with the modified code in my
editor.
And in some cases i was able to verify the bug by changing a
symbol and noting that the exception reports a reference to
the old (now non-existent) symbol.
Sadly when this happens i am usually too busy to stop and
spend time chasing down the source: is it my editor, or is
this a Python issue, or something more subtle??? My quick fix
is to run a Python script that deletes all my .pyc files and
everything is all peaches and cream again.
Mmm, peaches!
So yes, anecdotal evidence does support your argument that:
"machines can screw up".
--
https://mail.python.org/mailman/listinfo/python-list
