PyWin32 for Python 3.x

T

Tim Golden

John said:
That "wizard" won't even install unless Python 3.0 is "in the
registry", which apparently means "installed as the default Python".

No, it just means "installed somewhere". I have 6 different
versions of Python installed on this box. The choice of
which is "the default" is mine, either by selection at
installation or by later manipulation of associations,
path etc.

After giving the user an alert box, it dumps you into a dialog which
says "Python 3.0 is required for this package. Select installation to
use".
That's blank, and the form fields "Python Directory" and "Installation
Directory" won't accept input, so it can't even be overridden manually.

I agree that this is annoying.
Lame.

And no, I don't want to build it from source. I'm just checking to
see how close Python 3.x is getting to prime time. Looks like it's
still a long way off.


While I don't feel strongly about the matter -- I have no particular
need to use Python 3.x for now, altho' I'm tracking it -- I think
that you're making quite a far-reaching statement on scant evidence. Fair
enough, you couldn't do a quick-and-dirty install of pywin32-213
for Python 3.x without having Python 3.x installed and in the
registry. To go from that to claiming that Python 3.x is a long
way from prime time seems at the very least to ignore the legions
of non-Windows users who neither know nor care about pywin32.


TJG
 
J

John Nagle

Tim said:
Release 213 is out already:

http://sourceforge.net/project/showfiles.php?group_id=78018&package_id=79063&release_id=661475


I think it's still considered a little bit beta. There have been a *lot*
of changes involved.

That "wizard" won't even install unless Python 3.0 is "in the
registry", which apparently means "installed as the default Python".
After giving the user an alert box, it dumps you into a dialog which
says "Python 3.0 is required for this package. Select installation to use".
That's blank, and the form fields "Python Directory" and "Installation
Directory" won't accept input, so it can't even be overridden manually.

Lame.

And no, I don't want to build it from source. I'm just checking to
see how close Python 3.x is getting to prime time. Looks like it's
still a long way off.

John Nagle
 
T

Tim Golden

John said:
Well, of some other packages I use:

MySQLdb: "Python versions 2.3-2.5 are supported."
Ref: http://sourceforge.net/projects/mysql-python
M2Crypto: Latest version is for Python 2.6.
Ref: http://chandlerproject.org/bin/view/Projects/MeTooCrypto

Somebody who's into tracking might want to maintain a big cross-reference
table of "what packages work with what versions".


I'm inclined to agree. I remember some discussion about adding
a Wiki page for this, but searching quickly what I've come up
with is a suggestion in the Py3k/FAQ page:

http://wiki.python.org/moin/Python3000/FAQ

which points towards a PyPI query listing packages which have
Python :: 3 tagged:

http://pypi.python.org/pypi?:action=browse&c=533

It doesn't seem an entirely unreasonable approach. It falls
short of a researched / edited page (even a Wiki one) but
that would be a lot of work. I'm not sure how many Python
packages don't make into PyPI, nor am I sure how much effort
people take to categorise their packages appropriately. It
could well be the case that a number of packages will work
in Python 3.x without modification but their entry probably
won't reflect that unless their maintainer's gone to the
trouble to test the package and update it.

Obviously, in the case of (Windows) extension modules,
the module will at the very least need recompiling and
rebuilding even if the code works without modification.


TJG
 
J

John Nagle

Tim said:
No, it just means "installed somewhere". I have 6 different
versions of Python installed on this box. The choice of
which is "the default" is mine, either by selection at
installation or by later manipulation of associations,
path etc.



I agree that this is annoying.
While I don't feel strongly about the matter -- I have no particular
need to use Python 3.x for now, altho' I'm tracking it -- I think
that you're making quite a far-reaching statement on scant evidence. Fair
enough, you couldn't do a quick-and-dirty install of pywin32-213
for Python 3.x without having Python 3.x installed and in the
registry. To go from that to claiming that Python 3.x is a long
way from prime time seems at the very least to ignore the legions
of non-Windows users who neither know nor care about pywin32.

Well, of some other packages I use:

MySQLdb: "Python versions 2.3-2.5 are supported."
Ref: http://sourceforge.net/projects/mysql-python
M2Crypto: Latest version is for Python 2.6.
Ref: http://chandlerproject.org/bin/view/Projects/MeTooCrypto

Somebody who's into tracking might want to maintain a big cross-reference
table of "what packages work with what versions".

John Nagle
 
J

John Nagle

Tim said:
I'm inclined to agree. I remember some discussion about adding
a Wiki page for this, but searching quickly what I've come up
with is a suggestion in the Py3k/FAQ page:

http://wiki.python.org/moin/Python3000/FAQ

which points towards a PyPI query listing packages which have
Python :: 3 tagged:

http://pypi.python.org/pypi?:action=browse&c=533

It doesn't seem an entirely unreasonable approach. It falls
short of a researched / edited page (even a Wiki one) but
that would be a lot of work. I'm not sure how many Python
packages don't make into PyPI, nor am I sure how much effort
people take to categorise their packages appropriately.

At least there's a place to put the information. But the
data isn't there. The short list of 40 packages listed as working with
Python 3.0 contains mostly minor, special-purpose packages.

John Nagle
 
J

John Machin

[snip]
people take to categorise their packages appropriately. It
could well be the case that a number of packages will work
in Python 3.x without modification but their entry probably
won't reflect that unless their maintainer's gone to the
trouble to test the package and update it.

Excuse me, but what I read in this newsgroup, supported by my
experience doing a triage port followed by a fullscale practice port
on each of 2 non-trivial packages that I maintain (xlrd and xlwt),
suggests that the likelihood of a pure Python module (let alone
package) working with Python 3.X (even after going through 2to3)
without modification is rather low ... unless it was rather small and
had been written expressly to work unchanged in 2.X and 3.X. [1] It's
been stated authoritatively that the subset of Python that will run
unchanged unported un2to3ed is "crippled". Many packages support old
versions of Python (xlrd back to 2.1; some of the effbot's goodies
(e.g. PIL) run on 1.5.2 even), increasing the effort required to
assess the scope of the port, let alone implement it.

IOW any package that isn't specified as being 3.X-ready is unlikely to
be 3.X-ready. And if it was ready, wouldn't you want to wait till the
maintainer had tested that it was, and published its readyness?
Obviously, in the case of (Windows) extension modules,
the module will at the very least need recompiling and
rebuilding even if the code works without modification.

I could be wrong, but I got the impression that the C-API had changed
significantly from 2.x to 3.X and module initialisation had changed
drastically ... see (for example) http://docs.python.org/3.0/howto/cporting..html#cporting-howto
.... Looks to me like the chance of any extension (Windows or not) not
requiring changes is zero.

[1]: I've written a pure-Python module for calculating Levenshtein
distance using a bit-parallel algorithm; it will work on 3.x unchanged
because it operates on two sequences which need to support only seq[x]
and len(seq) and whose elements need to be hashable and comparable and
not much else, and it doesn't import anything. This is very small,
recent, and deliberate, hence definitely not the norm.

Cheers,
John
 
C

cgoldberg

Release 213 is out already:

Tim, Mark,
this is great news.. thanks for tracking 3.x so closely. I big
barrier for me to eventually adopt 3.x is the ability to use pywin32.

thanks!

-Corey
 
M

Mark Tolonen

cgoldberg said:
Tim, Mark,
this is great news.. thanks for tracking 3.x so closely. I big
barrier for me to eventually adopt 3.x is the ability to use pywin32.

thanks!

-Corey

I am using 213 on both 2.6.1 (default) and 3.0.1 and had no problems with
installation. I agree it is beta and have found a couple of bugs, but in
general it is working well.

I encourage people to download, use and report bugs. I haven't seen a lot
of activity about it on the python.windows newsgroup, so more users will
probably encourage fixes.

-Mark
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top