Re: [pywin32-checkins] py3k status

[Vern C. <kf...@ya...>]

Mark:
  You have no idea how much you just made my day!  Mother used to tell me that "great minds run in the same channels."  

--- On Thu, 11/13/08, Mark Hammond <mha...@sk...> wrote:
> To: "'Vern Cole'" <kf...@ya...>, "'Vernon Cole'" <kf...@us...>, pyw...@li...
> Date: Thursday, November 13, 2008, 6:33 PM
> > Argh! I'm still struggling with version control -- learning three at
> > once. My personal & commercial stuff is on Bazaar so I only use CVS for
> > pywin32 and am not too good with it. I intended that this checkin be
> > applied to the py3k fork only.
> 
> My apologies for the short and cryptic message.  You did check in on the
> py3k branch - I just wasn't clear.
> 
> [BTW - how are you finding bzr?  I'm working with them on a tortoise
> implementation, but find windows support is a little lacking and they aren't
> that motivated to help fix the niggles - eg, EOL support]

I installed Bazaar 1.9 yesterday (that was an adventure in itself, https://bugs.launchpad.net/bugs/238869) so I am just seeing the tortoise for the first time. It may not be "just what the doctor ordered" yet, but I am confident that it will be.

> > I used python 2.6 for testing because I needed to import pythoncom and
> > win32com, which work on 2.6 and I assumed were not yet ready on py3k.
> > (If I had compiled them would they have worked?)

> Let me explain what is happening:
> 
> Roger started the py3k work a long time ago, well before '2to3' was much use
> at all.  The only practical way to proceed was to "fork" the .py code
  [... snip ...]
> So, I'm working towards my goal on a bzr branch -
> lp:~mhammond/pywin32/py3k-integration - and this (mostly) works with *both*
> 2.3->2.7 and 3.0 from the same source tree.  Most of my work these days is
> just merging and testing 
[... snip ...] and the py3k branch will be able to be retired.
>  There is still a fair bit to go to get there though - specifically in bytes and buffer handling.

Here's what I used in my py3k attempt:
try:
    memoryViewType = memoryview  # will work in p3k
except NameError:
    memoryViewType = types.BufferType # will work in 2.6
    memoryview = buffer
    
> Getting back specifically to ado: this means that while making changes in a
> 2.6-only syntax is fine for the py3k branch, it will still leave me/us with
> a future merge problem.  As we should be able to continue supporting py2.x
> versions for a while, it makes the most sense for new versions to continue
> to be developed in a Python 2.x syntax, and using 2to3, even manually in the
> short term, to test on py3k.

That fits with the recommendations from BDFL.
 
> I hope that clarifies things - please let me know if you  have any concerns
> or comments.  I'd be more than welcome to accept bundles/patches against the
> bzr branch - even though that branch will also end up being thrown away, it
> is currently useful in helping me merge.

Okay: I have killed off my crufty CVS checkout and pulled a bzr branch.
(Wow, that was easy!)
I will re-merge my newer stuff from py3k into that trunk. I want to do more of the version-specific stuff at import time, so I want to do some more refactoring anyway. In reviewing the merge changes, I see many things like:
    if win32:
        f = rs.Fields[i]
    else: # Iron Python
        f = rs.Fields.Item[i]
which I'ld like to re-code, if I can, to get rid of the "if" at run time.
Would something like:
    f = getItemValue(rs.Fields,i)
be too confusing? 
--
Vernon