FAQ
The pychecker site says that pychecker works with versions
1.5 through 2.2. Any reason to expect that 2.3 breaks it?
Anyone tried it to see?

TIA


Al

Search Discussions

  • Gerhard Häring at Aug 3, 2003 at 3:21 am

    achrist at easystreet.com wrote:
    The pychecker site says that pychecker works with versions
    1.5 through 2.2. Any reason to expect that 2.3 breaks it?
    Anyone tried it to see?
    Why don't *you*?

    -- Gerhard
  • Skip Montanaro at Aug 3, 2003 at 3:23 am
    Al> The pychecker site says that pychecker works with versions
    Al> 1.5 through 2.2. Any reason to expect that 2.3 breaks it?
    Al> Anyone tried it to see?

    I run Python CVS as my normal Python on my laptop. I've never had a problem
    with PyChecker.

    Skip
  • Achrist at Aug 3, 2003 at 7:41 am

    Gerhard H?ring wrote:
    achrist at easystreet.com wrote:
    The pychecker site says that pychecker works with versions
    1.5 through 2.2. Any reason to expect that 2.3 breaks it?
    Anyone tried it to see?
    Why don't *you*?
    Smart people learn from their mistakes. Very smart people
    learn from other people's mistakes.


    Al
  • Gerhard Häring at Aug 3, 2003 at 1:11 pm

    achrist at easystreet.com wrote:
    Gerhard H?ring wrote:
    achrist at easystreet.com wrote:
    The pychecker site says that pychecker works with versions
    1.5 through 2.2. Any reason to expect that 2.3 breaks it?
    Anyone tried it to see?
    Why don't *you*?
    Smart people learn from their mistakes. Very smart people
    learn from other people's mistakes.
    If you think you are so smart, why don't you use your time more
    economically then and just try it out?

    -- Gerhard
  • François Pinard at Aug 3, 2003 at 2:34 pm
    [Gerhard H??ring]
    achrist at easystreet.com wrote:
    Gerhard H?ring wrote:
    achrist at easystreet.com wrote:
    The pychecker site says that pychecker works with versions
    1.5 through 2.2. Any reason to expect that 2.3 breaks it?
    Anyone tried it to see?
    Why don't *you*?
    Smart people learn from their mistakes. Very smart people
    learn from other people's mistakes.
    If you think you are so smart, why don't you use your time more economically
    then and just try it out?
    Come on, guys!

    What's so wrong, asking if someone had success or problems with something?
    Asserting for oneself that a package `works' may be a bigger undertaking
    than one might think of. Quickly trying simple cases is one thing. But
    being solid in all conditions is another game. If unit testing is popular
    in these days, this is because people feel an urge of being able to answer
    such questions, however imperfect unit testing may be.

    It looks like time economical, to me, asking to a crowd of interesting
    people if someone hit any problem using a package under specified
    conditions, compared to trying all alone to ascertain the quality. There is
    of course the danger of abusive laziness, but we should be careful and
    reserved, before silently assuming that our correspondent is rotten lazy.
  • Achrist at Aug 3, 2003 at 5:11 pm

    Fran?ois Pinard wrote:
    There is of course the danger of abusive laziness, but we should be
    careful and reserved, before silently assuming that our correspondent > is rotten lazy.
    I may be rotten and I may be lazy, but rotten lazy no one has ever
    called me AFAIK. I post code here whenever I've got anything worth
    sharing or finding out if it's not worth sharing. (I should publish
    a paper sometime about using Google Groups as a substitute for CVS.)
    About a month ago I made some comments about wxHtml and wound up
    debugging code for a correspondent by email who wasn't getting it
    to work. That was good.

    The world has brilliant people and pedestrian people. I'm more
    pedestrian. I'll admit that I ask more questions than I answer,
    but that helps keep this newsgroup balanced, as there are so many
    brilliant people here who answer more questions than they ask. If
    it wasn't for people like me, the brilliant ones would be here
    answering questions that noboby had asked. Life's like that.
    Everyone has a place at the table. First you eat, and then you
    get eaten.


    Al
  • Michele Simionato at Aug 3, 2003 at 3:03 pm
    achrist at easystreet.com wrote in message news:<3F2CBCC2.3FC51D57 at easystreet.com>...
    Gerhard H?ring wrote:
    achrist at easystreet.com wrote:
    The pychecker site says that pychecker works with versions
    1.5 through 2.2. Any reason to expect that 2.3 breaks it?
    Anyone tried it to see?
    Why don't *you*?
    Smart people learn from their mistakes. Very smart people
    learn from other people's mistakes.


    Al
    I context one can learn anything from second hand mistakes.
    There is much more satisfaction in making your own ;)

    Michele
  • Achrist at Aug 3, 2003 at 4:57 pm

    Gerhard H?ring wrote:

    If you think you are so smart, why don't you use your time more
    economically then and just try it out?
    If I upgrade python to 2.3 I also must upgrade:

    ctypes
    py2exe
    pysqlite
    win32all
    wxPython

    With a dial-up connection that's quite a bit of download time.
    Then, if there is a problem, I must roll back:

    python
    ctypes
    py2exe
    pysqlite
    win32all
    wxPython

    And hope that everything rolls back ok.

    Meanwhile, I've got a reasonably busy application-level
    to-do list going.

    Better to ask a question than worry about all that, no?


    Al
  • Skip Montanaro at Aug 3, 2003 at 6:46 pm

    If you think you are so smart, why don't you use your time more
    economically then and just try it out?
    al> If I upgrade python to 2.3 I also must upgrade:

    al> ctypes
    al> py2exe
    al> pysqlite
    al> win32all
    al> wxPython

    Just to see if pychecker works? Why not just configure Python with a
    different --prefix=... flag? That's assuming you're on a unix-like system.
    If you're on Windows (as it appears you are), Python 2.3 installs in
    c:\Python23 by default which shouldn't disturb your earlier Python
    installation unless you were tanked the day you installed it and put it in
    c:\Python23.

    Skip
  • Achrist at Aug 3, 2003 at 8:53 pm

    Skip Montanaro wrote:
    If you think you are so smart, why don't you use your time more
    economically then and just try it out?
    al> If I upgrade python to 2.3 I also must upgrade:

    al> ctypes
    al> py2exe
    al> pysqlite
    al> win32all
    al> wxPython

    Just to see if pychecker works?
    Just to see if pychecker works for the software for which it matters
    to me if pychecker works.
    Why not just configure Python with a
    different --prefix=... flag? That's assuming you're on a unix-like > system. I'm not.
    If you're on Windows (as it appears you are), Python 2.3 installs in
    c:\Python23 by default which shouldn't disturb your earlier Python
    installation unless you were tanked the day you installed it and put > it in
    c:\Python23.
    If I'm on a Windows system, and I am, I am very suspicious of any
    claims that it is possible to install and uninstall anything easily
    and come out exactly where I was before. About a month ago I noticed
    that my jaz drive was working not too well, so I upgraded Iomega's
    tools. That broke NT, it wouldn't uninstall, and I spent 3.5 days
    trying to fix NT. (This was actually within a week after NT had been
    dropped from Microsoft's supported list, and all the MS knowledgebase
    articles about NT and NT workstation service packs and patches had
    been purged from the MS website). If you work with Windows much, you
    learn the downside of promiscuous installing. There's always a risk.
    Better to ask twice and install once.


    Al
  • Tim Peters at Aug 3, 2003 at 10:56 pm
    [achrist at easystreet.com]
    ...
    If I'm on a Windows system, and I am, I am very suspicious of any
    claims that it is possible to install and uninstall anything easily
    and come out exactly where I was before.
    If you feel that way often <wink>, search google for GoBack. That's a
    commercial product (i.e, you pay for it), which performs deep magic to track
    all changes to your hard drive, storing recovery information to a
    permanently reserved part of your hard drive. It doesn't care (or know) why
    anything on disk is changing, it simply captures *all* changes. It's very
    effective at restoring the disk to a previous state. For example,
    defragment your hard drive, and (provided you reserved enough disk space to
    store all the change info), it can restore your disk to its fragmented state
    again (! not useful, but an impressive demo; maybe more impressive is
    deleting your Windows system directory -- the box won't be able to boot then
    until you tell GoBack to revert the drive to a time before the deletion).
    About a month ago I noticed that my jaz drive was working not too
    well, so I upgraded Iomega's tools. That broke NT, it wouldn't
    uninstall, and I spent 3.5 days trying to fix NT.
    With the tool above, you would simply tell it to restore your disk to its
    state at a time preceding your Iomega upgrade. End of problem! It doesn't
    matter whether an upgrade fiddled with the registry, replaced device
    drivers, deleted files completely, whatever -- in the end, they're all just
    bits on your hard drive, and your drive will get changed back to exactly
    what it was before you installed the upgrade (or before you even downloaded
    the updgrade installer, if you choose a restoration time before you did the
    download).
    ...
    If you work with Windows much, you learn the downside of promiscuous
    installing. There's always a risk. Better to ask twice and install
    once.
    Python installs are pretty benign, and on Windows 2.2.x and 2.3.y even name
    the base DLL differently (python22.dll vs python23.dll). For a minimally
    intrusive 2.3 test drive:

    + Install to the suggested \Python23 directory. It won't touch anything
    in your 2.2.x installation then.

    + Leave the "Yes, make backups" default selected.

    + In the "Select Components" dialog, click on "Advanced Options ...".
    In the "Advanced Options" dialog that pops up,

    - Select "Non-Admin install". Then all files (even the base Python
    DLL) will be unpacked under \Python23 (by default, we try to unpack
    the base DLL into a Windows system directory).

    - Uncheck "Register file extensions". Then .py (etc) files will
    continue to be associated with whatever Python you had before
    the 2.3 test drive.

    Because I build the PLabs Windows installer, I install broken pre-release
    Pythons all the time. The steps above are the ones I use then to ensure
    that they don't interfere with any of the released Pythons on my box. The
    Wise uninstaller does a thorough job of removing all traces of a Python
    installed in this way, and because we avoid changing file associations,
    can't be fooled by an unfortunate sequence of installs and uninstalls.
  • John J. Lee at Aug 3, 2003 at 9:02 pm

    achrist at easystreet.com writes:

    The pychecker site says that pychecker works with versions
    1.5 through 2.2. Any reason to expect that 2.3 breaks it?
    Anyone tried it to see?
    No, but 2.3 has no major language changes, and concentrates on library
    improvements, so I'd guess it's likely there are no major problems
    running Pychecker.


    John
  • Raymond Hettinger at Aug 4, 2003 at 7:05 am
    <achrist at easystreet.com> wrote in message
    news:3F2C5300.FA223CBA at easystreet.com...
    The pychecker site says that pychecker works with versions
    1.5 through 2.2. Any reason to expect that 2.3 breaks it?
    Anyone tried it to see?
    FWIW, just before the 2.3 release, Neal posted as couple of issues
    that PyChecker had detected. This is a pretty good indication
    that it runs fine on Py2.3.


    Raymond Hettinger
  • Achrist at Aug 4, 2003 at 7:43 pm

    Skip Montanaro wrote:
    Al> The pychecker site says that pychecker works with versions
    Al> 1.5 through 2.2. Any reason to expect that 2.3 breaks it?
    Al> Anyone tried it to see?

    I run Python CVS as my normal Python on my laptop. I've never had a problem
    with PyChecker.
    Based on this encouraging news, I have upgraded all the packages listed
    and run pychecker on a program using them all. It looks to work fine.
    Speed was not noticeably increased or decreased.

    The only change required in my sources is evidently that the csv
    module no longer has a parser(); it's a reader(aFile).

    About the only noticeably slow part of the program is the part that
    read a gzipped csv file. Unzipping and parsing a 170kb gzip file
    took about 20 sec with v2.2.3, and takes only about 9 sec with v2.3
    (200 MHz machine). So, the speed increase is big where I needed it
    most. This is great.


    Al
  • Skip Montanaro at Aug 4, 2003 at 9:39 pm
    Al> The only change required in my sources is evidently that the csv
    Al> module no longer has a parser(); it's a reader(aFile).

    Sounds like you were using a different csv file reader/writer, perhaps
    Object Craft's. The csv module which is part of 2.3 is a new module in the
    core. It has a different interface than Object Craft's csv module. (Note
    that the Object Craft folks are the primary developers of the new csv module
    as well.)

    Skip
  • John Machin at Aug 4, 2003 at 10:59 pm
    achrist at easystreet.com wrote in message news:<3F2EB773.4895B5DD at easystreet.com>...
    The only change required in my sources is evidently that the csv
    module no longer has a parser(); it's a reader(aFile).
    Python doesn't break version-to-version compatibility like that. You
    have to pay lots of money to software vendors to get them to do that
    to you.

    No, "the" csv module is new in 2.3. Under 2.2 you had been using "a"
    3rd party extension, written by Dave Cole. Same name, similar purpose,
    different contents.

    Another case: the 'optik' 3rd party extension was sanctified as
    'optparse'. Different name, mostly same contents.

    Hint: before upgrading to a new Python version, check what extensions
    you have in your site-packages directory. Read "what's new in Python
    m.n". Some of the site-packages you may have trialled and abandoned,
    most will need to be upgraded to be compatible with the new Python
    version (especially if you are running Windows), and in a few cases
    (e.g. csv and optik) you may want to switch to a new module, requiring
    changes to your source.
  • Achrist at Aug 4, 2003 at 11:18 pm

    Skip Montanaro wrote:
    Al> The only change required in my sources is evidently that the csv
    Al> module no longer has a parser(); it's a reader(aFile).

    Sounds like you were using a different csv file reader/writer,
    perhaps Object Craft's. The csv module which is part of 2.3 is a
    new module in the core. It has a different interface than Object
    Craft's csv module.
    I knew that was coming, and I hoped it would be compatible. It
    isn't, but it's close enough that I just had to change about 5 lines
    and cut out about ten to switch from one API to the other.

    I didn't have to change anything else. I guess that I'm still ok
    importing generators from the future even though they are no longer
    in the future.

    This moving from one release to the next is really very nice and easy.
    With other tools and languages, you have to wait for all the
    third-party vendors to upgrade their packages, then see what works
    and what doesn't. All the 3rd party packages for python that I was
    relying on under 2.2 were available for 2.3 the day that 2.3 went
    final.


    Al
  • Terry Reedy at Aug 5, 2003 at 5:50 am
    <achrist at easystreet.com> wrote in message
    news:3F2EE9C7.A38F7912 at easystreet.com...
    I didn't have to change anything else. I guess that I'm still ok
    importing generators from the future even though they are no longer
    in the future.
    It is quite intentional that future imports be simply ignored when
    'obsolete' and not suddenly make program not run.

    tjr
  • Achrist at Aug 5, 2003 at 7:04 am

    Terry Reedy wrote:
    It is quite intentional that future imports be simply ignored when
    'obsolete' and not suddenly make program not run.
    Don't worry about it. I can find plenty of other ways to have my
    programs not run.

    Al

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppython-list @
categoriespython
postedAug 3, '03 at 12:10a
activeAug 5, '03 at 7:04a
posts20
users10
websitepython.org

People

Translate

site design / logo © 2022 Grokbase