PyChecker work with Python 2.3?

[achrist]

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

[Skip Montanaro]

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

[Gerhard Häring]

ac*****@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

[achrist]

Gerhard Häring wrote:

ac*****@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]

ac*****@easystreet.com wrote:

Gerhard Häring wrote:

ac*****@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]

[Gerhard Häring]

ac*****@easystreet.com wrote:

Gerhard Häring wrote:

ac*****@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.

--
François Pinard http://www.iro.umontreal.ca/~pinard

[Michele Simionato]

ac*****@easystreet.com wrote in message news:<3F***************@easystreet.com>...

Gerhard Häring wrote:

ac*****@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]

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

[achrist]

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

[achrist]

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

[John J. Lee]

ac*****@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

[achrist]

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]

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

[achrist]

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

[John Machin]

ac*****@easystreet.com wrote in message news:<3F***************@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.

[Terry Reedy]

<ac*****@easystreet.com> wrote in message
news:3F***************@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]

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