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

[Jason Cunliffe]

Alex

That was great reply.
Thank you very much.

It seems like Python is going through some unavoidable growing pains right
now.
Lots of new goodies and options, lots of small-time confusion and
versionitis headaches while everyone catches up.
And then I imagine the number of new people using and learning Python will
increase considerably and ultimeatly this must be a very good thing for all.

It makes me wonder though if it might be a good idea to develop a little
python script which grep inserts a line at he top of all the .py files in
directory or recursively below it to identify what version it comes with.
For example insert:

usePyVersion = '152'   #or '20b1' or something.

Then make a little usePyVersion parsing tool which sniffs out the
'usePyVersion' value, advises of any variation across import statements and
can direct it to use the appropriate python stored maybe via a dictionary:
PyVersionPath = {'152':'c:\\program files\\python\\python152\\python.exe',
'20b1': 'd:\\python20b1\\python.exe' }

PyVersionPath [usePyVersion ]

perhaps even spits out an XML tree report showing the versions by group..

This way one can keep the various trees of python code around [assuming
enough disk space]. This way one can maintain legacy stuff during the next
6-12 months period while all th packages and binaries catch up.
All new work can proceed in the default latest/stable release. Except wher
one needs to use something which has not yet been supported.
Physically one can locate it anywhere, since a global 'usePyVersion'
variable would allow fast changes and updates to fall into place.

It seems the realtively long stabel period of recent Python history has
encouraged a dirctory-driven 'id' system.
But what is needed now is an explicit emebedded Id system within every .py
file. I am thinkninghere if things like wxPython, BerkeleyDB, Metakit etc,
col things but many of which depend on .dll, .pyd or large inter-dependent
sets of files.

..thoughts?

cheers
- Jason
________________________________________________________________
Jason CUNLIFFE = NOMADICS.(Interactive Art and Technology).Design Director

Alex Martelli <aleaxit at yahoo.com> wrote in message
news:8p7q6e019hv at news1.newsguy.com...
> "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
>
>
>