Unicode + SuperUltraAllNewGetItNow Python Upgrade questions: ASP/VBScript->Python

[Alex Martelli]

"Jason Cunliffe" <jasonic at nomadicsltd.com> wrote in message
news:srdavtfkljn174 at corp.supernews.com...
    [snip]
> In my wrox VBScript reference it says:
> AscW(string)        returns the unicode character code for the first
> character in a string
>
> Please can anyone tell me what python function I can use ro replace
> VBScript's AscW()

In Python 2, the version currently out in beta (and also, I think,
in the latest released version, Python 1.6),
    ord(thestring[0])
will do exactly the same thing.  Ie., you can define your own
function, name it the same way as VBscript's if you want...:

def AscW(string):
    return ord(string[0])

and live happily ever after.


In older versions of Python, Unicode support is a bit more of a
problem.  But actually, for the sample cases you give, you don't
really need the Unicode part, since the characters you're using
(spaces, letters) are all within the ANSI code range; so, the
Python builtin ord() will work just fine (just remember it applies
to a ONE-character-long string, not to the first character of a
string of arbitrary length, so, you do need to index with [0] to
get the first character).


> Q1. What version of Python now includes Unicode ?
> [sorry to be dense about this but the recent embarassment of Python riches
> plus other major software upgrades I am using this month has my head
> spinning]

1.6 and 2.0 (the latter in Beta).

On Windows, the win32all has always included some (modest) measure of
Unicode support (inevitable to interoperate with COM, since COM's string
standards have always been Unicode-based), actually.


> Q2. What unciode strategy can I use to make it work now with Python 1.5.2
> [Win98se, PythonWin]?
> I am running Python 1.5.2 on Win98se and I need to find an solution which
> will work for others who I know also have 1.5.2 and may not be so ready to
> upgrade just yet [Zope on Linux reasons etc]

On Linux, you won't have the COM servers (controls) you're trying to
drive, anyway.  But, as I said, no big problem since the specific
strings you're using don't truly need the 'Unicode' part of things.


> Q3. This has to be very easy...
> What can I enter as hardcode or via a little dictionary  which will return
> the correct values for AscW("B"), AscW("I"), AscW("") as above?
> There are only a few options when it comes to setting th font.. where can
I
> find out what these strings are ?

Again, ord is your friend; you don't need any dictionary here.


> It seems upgrading to Unicode version Python is good thing.

Yes!

> Q4. Can I do this easily overwriting my current c:\program files\python
> folder wihtout damage to all the packages and moduesl in there?

When you upgrade, existing whatever.py files will normally keep
working (it's very rare for a Python upgrade to break backward
compatibility; actually, the 1.5.2 -> 1.6 did, in an obscure
corner of the language, by fixing a "laxity" that previous Python
versions had about enforcing a certain rule...), but foo.pyd files
will generally break.  On Windows, the breakage is truly painful:
it crashes the Python interpreter when a script tries to import
a module that exists as a .pyd built for another version... alas,
this is the default way Windows' DLL's work, and a .pyd is just a
.DLL with a different extension for clarity.  It would slow down
Python's "import" statement substantially, I think, if it had to
carefully check before loading the .pyd (although it *might* be
nice to have some flag on the Python interpreter to have it run
in a "paranoid mode", to be used when one has just upgraded and
may not have rebuilt everything...).

With Python 1.6 and later, the need to rebuild all .pyd's may not
be terrible, since these recent versions include the beautiful
distutils, marking a huge step up in usability and convenience
for the distribution of Python extensions; if an extension's
author has packaged up his stuff with distutils, all you need
for a rebuild is just a few 'python setup.py install' to be run
in the appropriate directories.  Unfortunately, when moving up
from 1.5.2, it's very unlikely that distutils were used to
package up your existing extensions, as they didn't exist or
at least weren't part of core Python back in 1.5.2's time!-(
So, this helps a bit for the future, but, not much right now.

Actually, on Windows, you also need to own Microsoft Visual
C++ 6 to rebuild an extension for Python, so it's not really
all that painless:-(.  [On Linux, &c, where the free gcc is used,
it's not as bad!]  In theory, it's possible to build Python
extensions on Windows with the free gcc compiler in the
mingw32 packaging, but I don't think distutils let you do
that, nor is it "painless" easy, I believe.

>From this point of view, it WOULD be nice if Python moved to
another approach to expose the Python C API to extension
modules, with explicit "stubs" rather than relying on a
system's native linker/loader; that's what Tcl does.  It's
also what Python does the *other* way 'round -- an extension
module exposes its stuff to the Python interpreter via an
explicit stub structure; however, when the extension calls
upon Python C API's, it accesses them through the native
system linker/loader, which is what leads to the need to
rebuild the extension module when the Python dynamically
loaded library changes name (python15.dll to python20.dll,
for example).  Oh well -- maybe one day...

Python used to undergo such renamings pretty rarely, making
the painlevel sustainable; the Python library was named
python15.dll for a VERY long time, for example.  However,
I gather that this is due for a drastic change, as vividly
exemplified by the Day Of The Two Releases, when both
1.6 (final) and 2.0 (beta 1) were released the same day!
So, the python-library-changes-name problem will become
substantially higher in the near future, starting *right
now* (or, a few days ago, actually:-0).


Alex