From vernondcole at gmail.com  Fri Feb 16 23:01:37 2018
From: vernondcole at gmail.com (Vernon D. Cole)
Date: Fri, 16 Feb 2018 21:01:37 -0700
Subject: [python-win32] sudo.py -- publish to pypi or gist?
Message-ID: <CAH-ZgAerzZ3GXuqmNddHypY2dNUb0f74SL-jP5v1r=wEPwt0dQ@mail.gmail.com>

I finished work on a new module today -- it is called "sudo.py" and does
pretty much what you would expect.

If executed as a main program, on Linux or MacOS, it just runs "sudo" which
is not very exciting. On Windows, it requests elevation and runs a command
as an Administrator, which is a capability I have been wanting for years.

Or you can call it at the beginning of a Python program like this:
>>> import sudo
>>> sudo.run_elevated()  # run this script as an Administrator
which creates a new window (on Windows) and runs the script (from the top)
with elevated privileges.

Of course it requires PyWin32 to perform all this magic on Windows.

I want to publish it -- but in what form?
If you care, please respond to this poll.
<https://www.surveymonkey.com/r/23S85HG>
--
Vernon Cole
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-win32/attachments/20180216/bb200873/attachment.html>

From bkline at rksystems.com  Sat Feb 17 08:16:17 2018
From: bkline at rksystems.com (Bob Kline)
Date: Sat, 17 Feb 2018 08:16:17 -0500
Subject: [python-win32] Bug reports
Message-ID: <CAGjKmVrgWCDNgZA6AmhjkCFs3RBkr+gsquysV7ZuoyjMLPA2Ow@mail.gmail.com>

According to SourceForge [1]:

> Best Way to Get Help
> Python DB-API 2.0 module for ADO says the best way to get help with its software is by using its ticket tracker: Bugs. [2]

Is this true? I posted a bug report [3] a couple of weeks ago and I
still haven't seen even an acknowledgment that the report has been
seen. Is there another bug tracker somewhere I should be using? Has
the project silently migrated to GitHub?

Thanks!

[1] https://sourceforge.net/projects/adodbapi/
[2] http://sourceforge.net/p/adodbapi/bugs, which redirects to
https://sourceforge.net/p/adodbapi/bugs/
[3] https://sourceforge.net/p/adodbapi/bugs/27/

-- 
Bob Kline
http://www.rksystems.com
mailto:bkline at rksystems.com

From maxslimmer at gmail.com  Sat Feb 17 14:22:50 2018
From: maxslimmer at gmail.com (Max Slimmer)
Date: Sat, 17 Feb 2018 11:22:50 -0800
Subject: [python-win32] sudo module
Message-ID: <CAP6Y=Nrkc27BVoT8QZSA-wwkVz77hR900JR9jDDEiN2vAMVLhA@mail.gmail.com>

Vernon,

This sounds really useful. I'm voting for pypi package. Package management
is getting so much better and pypi seems to be pretty standard.

--Max III

On Sat, Feb 17, 2018 at 9:00 AM, <python-win32-request at python.org> wrote:

> Send python-win32 mailing list submissions to
>         python-win32 at python.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://mail.python.org/mailman/listinfo/python-win32
> or, via email, send a message with subject or body 'help' to
>         python-win32-request at python.org
>
> You can reach the person managing the list at
>         python-win32-owner at python.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of python-win32 digest..."
>
> Today's Topics:
>
>    1. sudo.py -- publish to pypi or gist? (Vernon D. Cole)
>    2. Bug reports (Bob Kline)
>
>
> ---------- Forwarded message ----------
> From: "Vernon D. Cole" <vernondcole at gmail.com>
> To: python-win32 <python-win32 at python.org>
> Cc:
> Bcc:
> Date: Fri, 16 Feb 2018 21:01:37 -0700
> Subject: [python-win32] sudo.py -- publish to pypi or gist?
> I finished work on a new module today -- it is called "sudo.py" and does
> pretty much what you would expect.
>
> If executed as a main program, on Linux or MacOS, it just runs "sudo"
> which is not very exciting. On Windows, it requests elevation and runs a
> command as an Administrator, which is a capability I have been wanting for
> years.
>
> Or you can call it at the beginning of a Python program like this:
> >>> import sudo
> >>> sudo.run_elevated()  # run this script as an Administrator
> which creates a new window (on Windows) and runs the script (from the top)
> with elevated privileges.
>
> Of course it requires PyWin32 to perform all this magic on Windows.
>
> I want to publish it -- but in what form?
> If you care, please respond to this poll.
> <https://www.surveymonkey.com/r/23S85HG>
> --
> Vernon Cole
>
>
>
> ---------- Forwarded message ----------
> From: Bob Kline <bkline at rksystems.com>
> To: python-win32 <python-win32 at python.org>
> Cc:
> Bcc:
> Date: Sat, 17 Feb 2018 08:16:17 -0500
> Subject: [python-win32] Bug reports
> According to SourceForge [1]:
>
> > Best Way to Get Help
> > Python DB-API 2.0 module for ADO says the best way to get help with its
> software is by using its ticket tracker: Bugs. [2]
>
> Is this true? I posted a bug report [3] a couple of weeks ago and I
> still haven't seen even an acknowledgment that the report has been
> seen. Is there another bug tracker somewhere I should be using? Has
> the project silently migrated to GitHub?
>
> Thanks!
>
> [1] https://sourceforge.net/projects/adodbapi/
> [2] http://sourceforge.net/p/adodbapi/bugs, which redirects to
> https://sourceforge.net/p/adodbapi/bugs/
> [3] https://sourceforge.net/p/adodbapi/bugs/27/
>
> --
> Bob Kline
> http://www.rksystems.com
> mailto:bkline at rksystems.com
>
>
> _______________________________________________
> python-win32 mailing list
> python-win32 at python.org
> https://mail.python.org/mailman/listinfo/python-win32
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-win32/attachments/20180217/baf2e280/attachment.html>

From maxslimmer at gmail.com  Sat Feb 17 14:29:32 2018
From: maxslimmer at gmail.com (Max Slimmer)
Date: Sat, 17 Feb 2018 11:29:32 -0800
Subject: [python-win32] Bug reporting
Message-ID: <CAP6Y=No2p+BJ2uq-He0K39RhtuZ2fDTrF5q=2ao0B+CJ=+C9JA@mail.gmail.com>

Bob,

I'm pretty sure adodbapi is now part of the pywin32 project. And pywin32
moved to github <https://github.com/mhammond/pywin32> a little bit ago.
Maybe Vernon can confirm or deny but I think submitting issues there is the
preferred route.

--Max III

On Sat, Feb 17, 2018 at 9:00 AM, <python-win32-request at python.org> wrote:

> Send python-win32 mailing list submissions to
>         python-win32 at python.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://mail.python.org/mailman/listinfo/python-win32
> or, via email, send a message with subject or body 'help' to
>         python-win32-request at python.org
>
> You can reach the person managing the list at
>         python-win32-owner at python.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of python-win32 digest..."
>
> Today's Topics:
>
>    1. sudo.py -- publish to pypi or gist? (Vernon D. Cole)
>    2. Bug reports (Bob Kline)
>
>
> ---------- Forwarded message ----------
> From: "Vernon D. Cole" <vernondcole at gmail.com>
> To: python-win32 <python-win32 at python.org>
> Cc:
> Bcc:
> Date: Fri, 16 Feb 2018 21:01:37 -0700
> Subject: [python-win32] sudo.py -- publish to pypi or gist?
> I finished work on a new module today -- it is called "sudo.py" and does
> pretty much what you would expect.
>
> If executed as a main program, on Linux or MacOS, it just runs "sudo"
> which is not very exciting. On Windows, it requests elevation and runs a
> command as an Administrator, which is a capability I have been wanting for
> years.
>
> Or you can call it at the beginning of a Python program like this:
> >>> import sudo
> >>> sudo.run_elevated()  # run this script as an Administrator
> which creates a new window (on Windows) and runs the script (from the top)
> with elevated privileges.
>
> Of course it requires PyWin32 to perform all this magic on Windows.
>
> I want to publish it -- but in what form?
> If you care, please respond to this poll.
> <https://www.surveymonkey.com/r/23S85HG>
> --
> Vernon Cole
>
>
>
> ---------- Forwarded message ----------
> From: Bob Kline <bkline at rksystems.com>
> To: python-win32 <python-win32 at python.org>
> Cc:
> Bcc:
> Date: Sat, 17 Feb 2018 08:16:17 -0500
> Subject: [python-win32] Bug reports
> According to SourceForge [1]:
>
> > Best Way to Get Help
> > Python DB-API 2.0 module for ADO says the best way to get help with its
> software is by using its ticket tracker: Bugs. [2]
>
> Is this true? I posted a bug report [3] a couple of weeks ago and I
> still haven't seen even an acknowledgment that the report has been
> seen. Is there another bug tracker somewhere I should be using? Has
> the project silently migrated to GitHub?
>
> Thanks!
>
> [1] https://sourceforge.net/projects/adodbapi/
> [2] http://sourceforge.net/p/adodbapi/bugs, which redirects to
> https://sourceforge.net/p/adodbapi/bugs/
> [3] https://sourceforge.net/p/adodbapi/bugs/27/
>
> --
> Bob Kline
> http://www.rksystems.com
> mailto:bkline at rksystems.com
>
>
> _______________________________________________
> python-win32 mailing list
> python-win32 at python.org
> https://mail.python.org/mailman/listinfo/python-win32
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-win32/attachments/20180217/44819e77/attachment.html>

From bkline at rksystems.com  Sat Feb 17 18:20:28 2018
From: bkline at rksystems.com (Bob Kline)
Date: Sat, 17 Feb 2018 18:20:28 -0500
Subject: [python-win32] Bug reporting
In-Reply-To: <CAP6Y=No2p+BJ2uq-He0K39RhtuZ2fDTrF5q=2ao0B+CJ=+C9JA@mail.gmail.com>
References: <CAP6Y=No2p+BJ2uq-He0K39RhtuZ2fDTrF5q=2ao0B+CJ=+C9JA@mail.gmail.com>
Message-ID: <CAGjKmVrZm_sb-A2NKsVYseZUvwB5q8zHqKbfPO-Mmo6m2nEY4A@mail.gmail.com>

Thanks for the tip, Max. I added a review to the SourceForge page so I
could help others avoid wasting time there (I didn't find any other
clues on the page about the move), and I submitted the patch I had
posted there as a pull request on GitHub.

Cheers,
Bob

On Sat, Feb 17, 2018 at 2:29 PM, Max Slimmer <maxslimmer at gmail.com> wrote:
> Bob,
>
> I'm pretty sure adodbapi is now part of the pywin32 project. And pywin32
> moved to github a little bit ago. Maybe Vernon can confirm or deny but I
> think submitting issues there is the preferred route.
>
> --Max III
>
> On Sat, Feb 17, 2018 at 9:00 AM, <python-win32-request at python.org> wrote:
>>
>> Send python-win32 mailing list submissions to
>>         python-win32 at python.org
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>>         https://mail.python.org/mailman/listinfo/python-win32
>> or, via email, send a message with subject or body 'help' to
>>         python-win32-request at python.org
>>
>> You can reach the person managing the list at
>>         python-win32-owner at python.org
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of python-win32 digest..."
>>
>> Today's Topics:
>>
>>    1. sudo.py -- publish to pypi or gist? (Vernon D. Cole)
>>    2. Bug reports (Bob Kline)
>>
>>
>> ---------- Forwarded message ----------
>> From: "Vernon D. Cole" <vernondcole at gmail.com>
>> To: python-win32 <python-win32 at python.org>
>> Cc:
>> Bcc:
>> Date: Fri, 16 Feb 2018 21:01:37 -0700
>> Subject: [python-win32] sudo.py -- publish to pypi or gist?
>> I finished work on a new module today -- it is called "sudo.py" and does
>> pretty much what you would expect.
>>
>> If executed as a main program, on Linux or MacOS, it just runs "sudo"
>> which is not very exciting. On Windows, it requests elevation and runs a
>> command as an Administrator, which is a capability I have been wanting for
>> years.
>>
>> Or you can call it at the beginning of a Python program like this:
>> >>> import sudo
>> >>> sudo.run_elevated()  # run this script as an Administrator
>> which creates a new window (on Windows) and runs the script (from the top)
>> with elevated privileges.
>>
>> Of course it requires PyWin32 to perform all this magic on Windows.
>>
>> I want to publish it -- but in what form?
>> If you care, please respond to this poll.
>> --
>> Vernon Cole
>>
>>
>>
>> ---------- Forwarded message ----------
>> From: Bob Kline <bkline at rksystems.com>
>> To: python-win32 <python-win32 at python.org>
>> Cc:
>> Bcc:
>> Date: Sat, 17 Feb 2018 08:16:17 -0500
>> Subject: [python-win32] Bug reports
>> According to SourceForge [1]:
>>
>> > Best Way to Get Help
>> > Python DB-API 2.0 module for ADO says the best way to get help with its
>> > software is by using its ticket tracker: Bugs. [2]
>>
>> Is this true? I posted a bug report [3] a couple of weeks ago and I
>> still haven't seen even an acknowledgment that the report has been
>> seen. Is there another bug tracker somewhere I should be using? Has
>> the project silently migrated to GitHub?
>>
>> Thanks!
>>
>> [1] https://sourceforge.net/projects/adodbapi/
>> [2] http://sourceforge.net/p/adodbapi/bugs, which redirects to
>> https://sourceforge.net/p/adodbapi/bugs/
>> [3] https://sourceforge.net/p/adodbapi/bugs/27/
>>
>> --
>> Bob Kline
>> http://www.rksystems.com
>> mailto:bkline at rksystems.com
>>
>>
>> _______________________________________________
>> python-win32 mailing list
>> python-win32 at python.org
>> https://mail.python.org/mailman/listinfo/python-win32
>>
>
>
> _______________________________________________
> python-win32 mailing list
> python-win32 at python.org
> https://mail.python.org/mailman/listinfo/python-win32
>



-- 
Bob Kline
http://www.rksystems.com
mailto:bkline at rksystems.com

From bkline at rksystems.com  Sat Feb 17 22:50:38 2018
From: bkline at rksystems.com (Bob Kline)
Date: Sat, 17 Feb 2018 22:50:38 -0500
Subject: [python-win32] Bug reporting
In-Reply-To: <CAGjKmVrZm_sb-A2NKsVYseZUvwB5q8zHqKbfPO-Mmo6m2nEY4A@mail.gmail.com>
References: <CAP6Y=No2p+BJ2uq-He0K39RhtuZ2fDTrF5q=2ao0B+CJ=+C9JA@mail.gmail.com>
 <CAGjKmVrZm_sb-A2NKsVYseZUvwB5q8zHqKbfPO-Mmo6m2nEY4A@mail.gmail.com>
Message-ID: <CAGjKmVr1UiHXui3s=HB8x+7N4PekcTQL=7vaq6gkFBwJp+yFCg@mail.gmail.com>

So, could someone clear up a couple of odd little puzzles for me? If
the adodbapi project has really moved to GitHub, (1) why does the
readme file for the package on GitHub still point back to the
SourceForge page, which still tells people to file bug reports there?
and (2) why is the apibase.py file (without which adodbapi can't load)
not in the GitHub repo?

Thanks,
Bob

On Sat, Feb 17, 2018 at 6:20 PM, Bob Kline <bkline at rksystems.com> wrote:
> Thanks for the tip, Max. I added a review to the SourceForge page so I
> could help others avoid wasting time there (I didn't find any other
> clues on the page about the move), and I submitted the patch I had
> posted there as a pull request on GitHub.
>
> Cheers,
> Bob
>
> On Sat, Feb 17, 2018 at 2:29 PM, Max Slimmer <maxslimmer at gmail.com> wrote:
>> Bob,
>>
>> I'm pretty sure adodbapi is now part of the pywin32 project. And pywin32
>> moved to github a little bit ago. Maybe Vernon can confirm or deny but I
>> think submitting issues there is the preferred route.
>>
>> --Max III
>>
>> On Sat, Feb 17, 2018 at 9:00 AM, <python-win32-request at python.org> wrote:
>>>
>>> Send python-win32 mailing list submissions to
>>>         python-win32 at python.org
>>>
>>> To subscribe or unsubscribe via the World Wide Web, visit
>>>         https://mail.python.org/mailman/listinfo/python-win32
>>> or, via email, send a message with subject or body 'help' to
>>>         python-win32-request at python.org
>>>
>>> You can reach the person managing the list at
>>>         python-win32-owner at python.org
>>>
>>> When replying, please edit your Subject line so it is more specific
>>> than "Re: Contents of python-win32 digest..."
>>>
>>> Today's Topics:
>>>
>>>    1. sudo.py -- publish to pypi or gist? (Vernon D. Cole)
>>>    2. Bug reports (Bob Kline)
>>>
>>>
>>> ---------- Forwarded message ----------
>>> From: "Vernon D. Cole" <vernondcole at gmail.com>
>>> To: python-win32 <python-win32 at python.org>
>>> Cc:
>>> Bcc:
>>> Date: Fri, 16 Feb 2018 21:01:37 -0700
>>> Subject: [python-win32] sudo.py -- publish to pypi or gist?
>>> I finished work on a new module today -- it is called "sudo.py" and does
>>> pretty much what you would expect.
>>>
>>> If executed as a main program, on Linux or MacOS, it just runs "sudo"
>>> which is not very exciting. On Windows, it requests elevation and runs a
>>> command as an Administrator, which is a capability I have been wanting for
>>> years.
>>>
>>> Or you can call it at the beginning of a Python program like this:
>>> >>> import sudo
>>> >>> sudo.run_elevated()  # run this script as an Administrator
>>> which creates a new window (on Windows) and runs the script (from the top)
>>> with elevated privileges.
>>>
>>> Of course it requires PyWin32 to perform all this magic on Windows.
>>>
>>> I want to publish it -- but in what form?
>>> If you care, please respond to this poll.
>>> --
>>> Vernon Cole
>>>
>>>
>>>
>>> ---------- Forwarded message ----------
>>> From: Bob Kline <bkline at rksystems.com>
>>> To: python-win32 <python-win32 at python.org>
>>> Cc:
>>> Bcc:
>>> Date: Sat, 17 Feb 2018 08:16:17 -0500
>>> Subject: [python-win32] Bug reports
>>> According to SourceForge [1]:
>>>
>>> > Best Way to Get Help
>>> > Python DB-API 2.0 module for ADO says the best way to get help with its
>>> > software is by using its ticket tracker: Bugs. [2]
>>>
>>> Is this true? I posted a bug report [3] a couple of weeks ago and I
>>> still haven't seen even an acknowledgment that the report has been
>>> seen. Is there another bug tracker somewhere I should be using? Has
>>> the project silently migrated to GitHub?
>>>
>>> Thanks!
>>>
>>> [1] https://sourceforge.net/projects/adodbapi/
>>> [2] http://sourceforge.net/p/adodbapi/bugs, which redirects to
>>> https://sourceforge.net/p/adodbapi/bugs/
>>> [3] https://sourceforge.net/p/adodbapi/bugs/27/
>>>
>>> --
>>> Bob Kline
>>> http://www.rksystems.com
>>> mailto:bkline at rksystems.com
>>>
>>>
>>> _______________________________________________
>>> python-win32 mailing list
>>> python-win32 at python.org
>>> https://mail.python.org/mailman/listinfo/python-win32
>>>
>>
>>
>> _______________________________________________
>> python-win32 mailing list
>> python-win32 at python.org
>> https://mail.python.org/mailman/listinfo/python-win32
>>
>
>
>
> --
> Bob Kline
> http://www.rksystems.com
> mailto:bkline at rksystems.com



-- 
Bob Kline
http://www.rksystems.com
mailto:bkline at rksystems.com

From vernondcole at gmail.com  Mon Feb 19 02:25:05 2018
From: vernondcole at gmail.com (Vernon D. Cole)
Date: Mon, 19 Feb 2018 00:25:05 -0700
Subject: [python-win32] Bug reporting
In-Reply-To: <CAGjKmVr1UiHXui3s=HB8x+7N4PekcTQL=7vaq6gkFBwJp+yFCg@mail.gmail.com>
References: <CAP6Y=No2p+BJ2uq-He0K39RhtuZ2fDTrF5q=2ao0B+CJ=+C9JA@mail.gmail.com>
 <CAGjKmVrZm_sb-A2NKsVYseZUvwB5q8zHqKbfPO-Mmo6m2nEY4A@mail.gmail.com>
 <CAGjKmVr1UiHXui3s=HB8x+7N4PekcTQL=7vaq6gkFBwJp+yFCg@mail.gmail.com>
Message-ID: <CAH-ZgAcrjtsKV0ppTsfa2mFP9mu_253e8_Y85kuKWuiVyVVywA@mail.gmail.com>

I will try to clear this up as much as I can...

Adodbapi lives in two places, as a stand-alone project on Sourceforge, and
integrated with PyWin32.
The Sourceforge project is needed for Iron Python, and has more
documentation, and, originally, a faster upgrade cycle.
The SF code was copied to pywin32 for easier installation and more
convenience, but the file layout is slightly different. I did not have the
capability to test the pywin32 installation so was unaware of the problem
until too late. Then I went to work for another company which did not use
Windows at all, so everything got kind of lost.

The move of pywin32 to GitHub, along with improved testing there will help
to fix things.  I am also building an SQL server test bench which I hope
will be permanent. A patch has been submitted to fix the "missing file"
problem, and I have changed my SF notifications to a different email
address that I check more frequently.

The python-win project is the preferred maintenance place.

Meanwhile ... I am not getting any younger and an active back-up maintainer
for the home adodbapi project would be very welcome if someone were willing
to help out. At the present moment the "bus size" is one -- which is a bad
thing.
--
Vernon Cole




On Sat, Feb 17, 2018 at 8:50 PM, Bob Kline <bkline at rksystems.com> wrote:

> So, could someone clear up a couple of odd little puzzles for me? If
> the adodbapi project has really moved to GitHub, (1) why does the
> readme file for the package on GitHub still point back to the
> SourceForge page, which still tells people to file bug reports there?
> and (2) why is the apibase.py file (without which adodbapi can't load)
> not in the GitHub repo?
>
> Thanks,
> Bob
>
> On Sat, Feb 17, 2018 at 6:20 PM, Bob Kline <bkline at rksystems.com> wrote:
> > Thanks for the tip, Max. I added a review to the SourceForge page so I
> > could help others avoid wasting time there (I didn't find any other
> > clues on the page about the move), and I submitted the patch I had
> > posted there as a pull request on GitHub.
> >
> > Cheers,
> > Bob
> >
> > On Sat, Feb 17, 2018 at 2:29 PM, Max Slimmer <maxslimmer at gmail.com>
> wrote:
> >> Bob,
> >>
> >> I'm pretty sure adodbapi is now part of the pywin32 project. And pywin32
> >> moved to github a little bit ago. Maybe Vernon can confirm or deny but I
> >> think submitting issues there is the preferred route.
> >>
> >> --Max III
> >>
> >> On Sat, Feb 17, 2018 at 9:00 AM, <python-win32-request at python.org>
> wrote:
> >>>
> >>> Send python-win32 mailing list submissions to
> >>>         python-win32 at python.org
> >>>
> >>> To subscribe or unsubscribe via the World Wide Web, visit
> >>>         https://mail.python.org/mailman/listinfo/python-win32
> >>> or, via email, send a message with subject or body 'help' to
> >>>         python-win32-request at python.org
> >>>
> >>> You can reach the person managing the list at
> >>>         python-win32-owner at python.org
> >>>
> >>> When replying, please edit your Subject line so it is more specific
> >>> than "Re: Contents of python-win32 digest..."
> >>>
> >>> Today's Topics:
> >>>
> >>>    1. sudo.py -- publish to pypi or gist? (Vernon D. Cole)
> >>>    2. Bug reports (Bob Kline)
> >>>
> >>>
> >>> ---------- Forwarded message ----------
> >>> From: "Vernon D. Cole" <vernondcole at gmail.com>
> >>> To: python-win32 <python-win32 at python.org>
> >>> Cc:
> >>> Bcc:
> >>> Date: Fri, 16 Feb 2018 21:01:37 -0700
> >>> Subject: [python-win32] sudo.py -- publish to pypi or gist?
> >>> I finished work on a new module today -- it is called "sudo.py" and
> does
> >>> pretty much what you would expect.
> >>>
> >>> If executed as a main program, on Linux or MacOS, it just runs "sudo"
> >>> which is not very exciting. On Windows, it requests elevation and runs
> a
> >>> command as an Administrator, which is a capability I have been wanting
> for
> >>> years.
> >>>
> >>> Or you can call it at the beginning of a Python program like this:
> >>> >>> import sudo
> >>> >>> sudo.run_elevated()  # run this script as an Administrator
> >>> which creates a new window (on Windows) and runs the script (from the
> top)
> >>> with elevated privileges.
> >>>
> >>> Of course it requires PyWin32 to perform all this magic on Windows.
> >>>
> >>> I want to publish it -- but in what form?
> >>> If you care, please respond to this poll.
> >>> --
> >>> Vernon Cole
> >>>
> >>>
> >>>
> >>> ---------- Forwarded message ----------
> >>> From: Bob Kline <bkline at rksystems.com>
> >>> To: python-win32 <python-win32 at python.org>
> >>> Cc:
> >>> Bcc:
> >>> Date: Sat, 17 Feb 2018 08:16:17 -0500
> >>> Subject: [python-win32] Bug reports
> >>> According to SourceForge [1]:
> >>>
> >>> > Best Way to Get Help
> >>> > Python DB-API 2.0 module for ADO says the best way to get help with
> its
> >>> > software is by using its ticket tracker: Bugs. [2]
> >>>
> >>> Is this true? I posted a bug report [3] a couple of weeks ago and I
> >>> still haven't seen even an acknowledgment that the report has been
> >>> seen. Is there another bug tracker somewhere I should be using? Has
> >>> the project silently migrated to GitHub?
> >>>
> >>> Thanks!
> >>>
> >>> [1] https://sourceforge.net/projects/adodbapi/
> >>> [2] http://sourceforge.net/p/adodbapi/bugs, which redirects to
> >>> https://sourceforge.net/p/adodbapi/bugs/
> >>> [3] https://sourceforge.net/p/adodbapi/bugs/27/
> >>>
> >>> --
> >>> Bob Kline
> >>> http://www.rksystems.com
> >>> mailto:bkline at rksystems.com
> >>>
> >>>
> >>> _______________________________________________
> >>> python-win32 mailing list
> >>> python-win32 at python.org
> >>> https://mail.python.org/mailman/listinfo/python-win32
> >>>
> >>
> >>
> >> _______________________________________________
> >> python-win32 mailing list
> >> python-win32 at python.org
> >> https://mail.python.org/mailman/listinfo/python-win32
> >>
> >
> >
> >
> > --
> > Bob Kline
> > http://www.rksystems.com
> > mailto:bkline at rksystems.com
>
>
>
> --
> Bob Kline
> http://www.rksystems.com
> mailto:bkline at rksystems.com
> _______________________________________________
> python-win32 mailing list
> python-win32 at python.org
> https://mail.python.org/mailman/listinfo/python-win32
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-win32/attachments/20180219/486be442/attachment.html>

From bkline at rksystems.com  Mon Feb 19 06:57:02 2018
From: bkline at rksystems.com (Bob Kline)
Date: Mon, 19 Feb 2018 06:57:02 -0500
Subject: [python-win32] Bug reporting
In-Reply-To: <CAH-ZgAcrjtsKV0ppTsfa2mFP9mu_253e8_Y85kuKWuiVyVVywA@mail.gmail.com>
References: <CAP6Y=No2p+BJ2uq-He0K39RhtuZ2fDTrF5q=2ao0B+CJ=+C9JA@mail.gmail.com>
 <CAGjKmVrZm_sb-A2NKsVYseZUvwB5q8zHqKbfPO-Mmo6m2nEY4A@mail.gmail.com>
 <CAGjKmVr1UiHXui3s=HB8x+7N4PekcTQL=7vaq6gkFBwJp+yFCg@mail.gmail.com>
 <CAH-ZgAcrjtsKV0ppTsfa2mFP9mu_253e8_Y85kuKWuiVyVVywA@mail.gmail.com>
Message-ID: <CAGjKmVpfDLtRLby4MbDDEndhNs5eL2De_6Krqh2wX0gtbqS3Fw@mail.gmail.com>

On Mon, Feb 19, 2018 at 2:25 AM, Vernon D. Cole <vernondcole at gmail.com> wrote:

> I will try to clear this up as much as I can...

Thanks very much for your reply, Vernon.

> Adodbapi lives in two places, as a stand-alone project on Sourceforge, and
> integrated with PyWin32.

Well, I wouldn't go so far as saying it "lives" in the GitHub project;
more like it's on life support. :-) As far as I can tell, it's never
actually been usable from that repo, as the required apibase.py file
didn't make it to the party.

> The Sourceforge project is needed for Iron Python, and has more
> documentation, and, originally, a faster upgrade cycle.

I see, however, that the code to support IronPython is in both places,
documentation can easily be enhanced, and (as you acknowledge) the
upgrade cycle for the SourceForge project has gone walkabout. It would
seem ideal (if nothing else, from the perspective of the attempt to
attract more maintainers) if we didn't have to maintain two separate
code bases.

> The SF code was copied to pywin32 for easier installation and more
> convenience, but the file layout is slightly different. I did not have the
> capability to test the pywin32 installation so was unaware of the problem
> until too late. Then I went to work for another company which did not use
> Windows at all, so everything got kind of lost.
>
> The move of pywin32 to GitHub, along with improved testing there will help
> to fix things.  I am also building an SQL server test bench which I hope
> will be permanent. A patch has been submitted to fix the "missing file"
> problem, and I have changed my SF notifications to a different email address
> that I check more frequently.
>
> The python-win project is the preferred maintenance place.

Perhaps a note on the SourceForge page to that effect would be appropriate.

> Meanwhile ... I am not getting any younger and an active back-up maintainer
> for the home adodbapi project would be very welcome if someone were willing
> to help out. At the present moment the "bus size" is one -- which is a bad
> thing.

I'm happy to do what I can, though as I pointed out in an earlier
thread, you're younger than I am. :-)

If you provide instructions for getting the regression tests running,
I'll try to replicate them here.

Let's first decide the question of how many places we're going to
maintain the package. I vote for one (on GitHub). If (for whatever
reason) it's necessary to maintain it in two places, let's (a) decide
whether it's possible to keep the two places synchronized so they
don't drift into forks of each other; (b) figure out how such
synchronization will be accomplished; and most important (c) make it
very clear in both locations what the relationship is between the two
repositories, telling everyone which one should be used in which
situation, where to file issue tracking tickets, etc.

Thanks again for your willingness to bring this project back to life.

-- 
Bob Kline
http://www.rksystems.com
mailto:bkline at rksystems.com

From vernondcole at gmail.com  Mon Feb 19 11:18:21 2018
From: vernondcole at gmail.com (Vernon D. Cole)
Date: Mon, 19 Feb 2018 09:18:21 -0700
Subject: [python-win32] Bug reporting
In-Reply-To: <CAGjKmVpfDLtRLby4MbDDEndhNs5eL2De_6Krqh2wX0gtbqS3Fw@mail.gmail.com>
References: <CAP6Y=No2p+BJ2uq-He0K39RhtuZ2fDTrF5q=2ao0B+CJ=+C9JA@mail.gmail.com>
 <CAGjKmVrZm_sb-A2NKsVYseZUvwB5q8zHqKbfPO-Mmo6m2nEY4A@mail.gmail.com>
 <CAGjKmVr1UiHXui3s=HB8x+7N4PekcTQL=7vaq6gkFBwJp+yFCg@mail.gmail.com>
 <CAH-ZgAcrjtsKV0ppTsfa2mFP9mu_253e8_Y85kuKWuiVyVVywA@mail.gmail.com>
 <CAGjKmVpfDLtRLby4MbDDEndhNs5eL2De_6Krqh2wX0gtbqS3Fw@mail.gmail.com>
Message-ID: <CAH-ZgAdj8CC9qWHmpnADaw23VkrBJHSP_A_9VG5muiNmAZRJYg@mail.gmail.com>

Sounds like a good plan.

On Feb 19, 2018 04:57, "Bob Kline" <bkline at rksystems.com> wrote:

> On Mon, Feb 19, 2018 at 2:25 AM, Vernon D. Cole <vernondcole at gmail.com>
> wrote:
>
> > I will try to clear this up as much as I can...
>
> Thanks very much for your reply, Vernon.
>
> > Adodbapi lives in two places, as a stand-alone project on Sourceforge,
> and
> > integrated with PyWin32.
>
> Well, I wouldn't go so far as saying it "lives" in the GitHub project;
> more like it's on life support. :-) As far as I can tell, it's never
> actually been usable from that repo, as the required apibase.py file
> didn't make it to the party.
>
> > The Sourceforge project is needed for Iron Python, and has more
> > documentation, and, originally, a faster upgrade cycle.
>
> I see, however, that the code to support IronPython is in both places,
> documentation can easily be enhanced, and (as you acknowledge) the
> upgrade cycle for the SourceForge project has gone walkabout. It would
> seem ideal (if nothing else, from the perspective of the attempt to
> attract more maintainers) if we didn't have to maintain two separate
> code bases.
>
> > The SF code was copied to pywin32 for easier installation and more
> > convenience, but the file layout is slightly different. I did not have
> the
> > capability to test the pywin32 installation so was unaware of the problem
> > until too late. Then I went to work for another company which did not use
> > Windows at all, so everything got kind of lost.
> >
> > The move of pywin32 to GitHub, along with improved testing there will
> help
> > to fix things.  I am also building an SQL server test bench which I hope
> > will be permanent. A patch has been submitted to fix the "missing file"
> > problem, and I have changed my SF notifications to a different email
> address
> > that I check more frequently.
> >
> > The python-win project is the preferred maintenance place.
>
> Perhaps a note on the SourceForge page to that effect would be appropriate.
>
> > Meanwhile ... I am not getting any younger and an active back-up
> maintainer
> > for the home adodbapi project would be very welcome if someone were
> willing
> > to help out. At the present moment the "bus size" is one -- which is a
> bad
> > thing.
>
> I'm happy to do what I can, though as I pointed out in an earlier
> thread, you're younger than I am. :-)
>
> If you provide instructions for getting the regression tests running,
> I'll try to replicate them here.
>
> Let's first decide the question of how many places we're going to
> maintain the package. I vote for one (on GitHub). If (for whatever
> reason) it's necessary to maintain it in two places, let's (a) decide
> whether it's possible to keep the two places synchronized so they
> don't drift into forks of each other; (b) figure out how such
> synchronization will be accomplished; and most important (c) make it
> very clear in both locations what the relationship is between the two
> repositories, telling everyone which one should be used in which
> situation, where to file issue tracking tickets, etc.
>
> Thanks again for your willingness to bring this project back to life.
>
> --
> Bob Kline
> http://www.rksystems.com
> mailto:bkline at rksystems.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-win32/attachments/20180219/76e31314/attachment.html>

From bkline at rksystems.com  Mon Feb 19 11:59:26 2018
From: bkline at rksystems.com (Bob Kline)
Date: Mon, 19 Feb 2018 11:59:26 -0500
Subject: [python-win32] Bug reporting
In-Reply-To: <CAH-ZgAdj8CC9qWHmpnADaw23VkrBJHSP_A_9VG5muiNmAZRJYg@mail.gmail.com>
References: <CAP6Y=No2p+BJ2uq-He0K39RhtuZ2fDTrF5q=2ao0B+CJ=+C9JA@mail.gmail.com>
 <CAGjKmVrZm_sb-A2NKsVYseZUvwB5q8zHqKbfPO-Mmo6m2nEY4A@mail.gmail.com>
 <CAGjKmVr1UiHXui3s=HB8x+7N4PekcTQL=7vaq6gkFBwJp+yFCg@mail.gmail.com>
 <CAH-ZgAcrjtsKV0ppTsfa2mFP9mu_253e8_Y85kuKWuiVyVVywA@mail.gmail.com>
 <CAGjKmVpfDLtRLby4MbDDEndhNs5eL2De_6Krqh2wX0gtbqS3Fw@mail.gmail.com>
 <CAH-ZgAdj8CC9qWHmpnADaw23VkrBJHSP_A_9VG5muiNmAZRJYg@mail.gmail.com>
Message-ID: <CAGjKmVr6tZaA+p-Daau8fKCJB0gP835cj_iviJ5US_N9c4UGXQ@mail.gmail.com>

On Mon, Feb 19, 2018 at 11:18 AM, Vernon D. Cole <vernondcole at gmail.com> wrote:

> Sounds like a good plan.

As in, "yes, let's consolidate the project in one place (under pywin
on GitHub)"? Or did you mean "yes, I agree we should have the
discussion about whether we have to maintain the package in more than
one place"? If the former, I'll be happy to get the ball rolling by
starting the analysis for topping up the GitHub repo from the
SourceForge oledbapi repo. If the latter, I guess the first step in
that discussion would be for you to lay out the reason(s) why it
wouldn't work to maintain the project just on GitHub (under pywin). Or
perhaps you intended some third interpretation of "good plan."

Cheers,
Bob

>
> On Feb 19, 2018 04:57, "Bob Kline" <bkline at rksystems.com> wrote:
>>
>> On Mon, Feb 19, 2018 at 2:25 AM, Vernon D. Cole <vernondcole at gmail.com>
>> wrote:
>>
>> > I will try to clear this up as much as I can...
>>
>> Thanks very much for your reply, Vernon.
>>
>> > Adodbapi lives in two places, as a stand-alone project on Sourceforge,
>> > and
>> > integrated with PyWin32.
>>
>> Well, I wouldn't go so far as saying it "lives" in the GitHub project;
>> more like it's on life support. :-) As far as I can tell, it's never
>> actually been usable from that repo, as the required apibase.py file
>> didn't make it to the party.
>>
>> > The Sourceforge project is needed for Iron Python, and has more
>> > documentation, and, originally, a faster upgrade cycle.
>>
>> I see, however, that the code to support IronPython is in both places,
>> documentation can easily be enhanced, and (as you acknowledge) the
>> upgrade cycle for the SourceForge project has gone walkabout. It would
>> seem ideal (if nothing else, from the perspective of the attempt to
>> attract more maintainers) if we didn't have to maintain two separate
>> code bases.
>>
>> > The SF code was copied to pywin32 for easier installation and more
>> > convenience, but the file layout is slightly different. I did not have
>> > the
>> > capability to test the pywin32 installation so was unaware of the
>> > problem
>> > until too late. Then I went to work for another company which did not
>> > use
>> > Windows at all, so everything got kind of lost.
>> >
>> > The move of pywin32 to GitHub, along with improved testing there will
>> > help
>> > to fix things.  I am also building an SQL server test bench which I hope
>> > will be permanent. A patch has been submitted to fix the "missing file"
>> > problem, and I have changed my SF notifications to a different email
>> > address
>> > that I check more frequently.
>> >
>> > The python-win project is the preferred maintenance place.
>>
>> Perhaps a note on the SourceForge page to that effect would be
>> appropriate.
>>
>> > Meanwhile ... I am not getting any younger and an active back-up
>> > maintainer
>> > for the home adodbapi project would be very welcome if someone were
>> > willing
>> > to help out. At the present moment the "bus size" is one -- which is a
>> > bad
>> > thing.
>>
>> I'm happy to do what I can, though as I pointed out in an earlier
>> thread, you're younger than I am. :-)
>>
>> If you provide instructions for getting the regression tests running,
>> I'll try to replicate them here.
>>
>> Let's first decide the question of how many places we're going to
>> maintain the package. I vote for one (on GitHub). If (for whatever
>> reason) it's necessary to maintain it in two places, let's (a) decide
>> whether it's possible to keep the two places synchronized so they
>> don't drift into forks of each other; (b) figure out how such
>> synchronization will be accomplished; and most important (c) make it
>> very clear in both locations what the relationship is between the two
>> repositories, telling everyone which one should be used in which
>> situation, where to file issue tracking tickets, etc.
>>
>> Thanks again for your willingness to bring this project back to life.
>>
>> --
>> Bob Kline
>> http://www.rksystems.com
>> mailto:bkline at rksystems.com



-- 
Bob Kline
http://www.rksystems.com
mailto:bkline at rksystems.com

From bkline at rksystems.com  Wed Feb 21 07:31:18 2018
From: bkline at rksystems.com (Bob Kline)
Date: Wed, 21 Feb 2018 07:31:18 -0500
Subject: [python-win32] Bug reporting
In-Reply-To: <CAGjKmVr6tZaA+p-Daau8fKCJB0gP835cj_iviJ5US_N9c4UGXQ@mail.gmail.com>
References: <CAP6Y=No2p+BJ2uq-He0K39RhtuZ2fDTrF5q=2ao0B+CJ=+C9JA@mail.gmail.com>
 <CAGjKmVrZm_sb-A2NKsVYseZUvwB5q8zHqKbfPO-Mmo6m2nEY4A@mail.gmail.com>
 <CAGjKmVr1UiHXui3s=HB8x+7N4PekcTQL=7vaq6gkFBwJp+yFCg@mail.gmail.com>
 <CAH-ZgAcrjtsKV0ppTsfa2mFP9mu_253e8_Y85kuKWuiVyVVywA@mail.gmail.com>
 <CAGjKmVpfDLtRLby4MbDDEndhNs5eL2De_6Krqh2wX0gtbqS3Fw@mail.gmail.com>
 <CAH-ZgAdj8CC9qWHmpnADaw23VkrBJHSP_A_9VG5muiNmAZRJYg@mail.gmail.com>
 <CAGjKmVr6tZaA+p-Daau8fKCJB0gP835cj_iviJ5US_N9c4UGXQ@mail.gmail.com>
Message-ID: <CAGjKmVpCoonM_X+W3ntaeJn4D=GET0A0GOX_1x9GHggWdr-i7w@mail.gmail.com>

Hi, Vernon. I'm afraid I'm going to start sounding like an annoying
nag. :-) If you really want help with this project, you need to meet
me half way. If you're swamped with work right now, please at least
write back and say something like "I'm buried under a project right
now, and I won't be able to get back to you until next Friday." If
you're in hospital with a serious illness, I sincerely apologize and
I'll back off. If you'd prefer to take this thread offline, that's
fine with me, too.

I asked for guidance in getting the regression tests running (if we're
going to attract maintainers, one of the first things that needs to
happen is for the configuration script for the test suite to be made
much simpler to adapt to a specific platform, with all of the values
which need to be modified collected in one place with clear
documentation for what each of them means), but I didn't see anything
from you in response to that request, so I plunged in on my own. I've
got the SQL Server and Access tests running, and expect it won't be
too long before I've got the other back ends set up and plugged in. I
ran into two problems with the Access tests. The first is that
setuptestframework.py tries to copy a file from
../examples/adotest.mdb and that file doesn't exist (except perhaps on
your own machine). I solved that by firing up Access and creating the
missing file myself. The second problem is that one of the tests in
the suite fails. From the error message, it appears that the package
(or perhaps something else in the stack) is trying to treat a binary
value as a string (note the presence of the null terminator at the end
of the value and the extra quote marks in the repr() output):

C:\Python\Lib\site-packages\adodbapi\test>adodbapitest.py
2.7.13 (default, Jun 26 2017, 14:28:43) [MSC v.1500 64 bit (AMD64)]
node=xp: is64bit.os()= True, is64bit.Python()= True
adodbapi v2.6.0.7
testADOdbapiConfig.py v 2.6.0.A00
    ...copying test ACCESS db to
c:\users\bkline\appdata\local\temp\adodbapi_test\xx_COU8KEJ7K.mdb
    ...Testing ACCESS connection...
  (successful)
    ...Testing MS-SQL login...
  (successful)
 Unit tests version 2.6.0.6 for adodbapi
Default Date Converter is <adodbapi.apibase.pythonDateTimeConverter
object at 0x0000000005970C18>
...............................F.......................................................................
======================================================================
FAIL: testDataTypeBinary (__main__.TestADOwithAccessDB)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Python\Lib\site-packages\adodbapi\test\adodbapitest.py",
line 395, in testDataTypeBinary
    allowedReturnValues=arv)
  File "C:\Python\Lib\site-packages\adodbapi\test\adodbapitest.py",
line 314, in helpTestDataType
    'Value "%s" not in %s' % (repr(rs[0]), allowedReturnValues))
AssertionError: Value "'\x07\x00\xe2@\x00'" not in ['\x07\x00\xe2@*',
<read-only buffer for 0x0000000005183990, size -1, offset 0 at
0x0000000005A0D6C0>, '\x07\x00\xe2@*']

----------------------------------------------------------------------
Ran 103 tests in 8.394s

FAILED (failures=1)

I get the same failure if I use a more modern .accdb file.

Again, I apologize for this blunt message, but you've done some good
work on this package, and it's worth getting it back on the road.

Regards,
Bob Kline

On Mon, Feb 19, 2018 at 11:59 AM, Bob Kline <bkline at rksystems.com> wrote:
> On Mon, Feb 19, 2018 at 11:18 AM, Vernon D. Cole <vernondcole at gmail.com> wrote:
>
>> Sounds like a good plan.
>
> As in, "yes, let's consolidate the project in one place (under pywin
> on GitHub)"? Or did you mean "yes, I agree we should have the
> discussion about whether we have to maintain the package in more than
> one place"? If the former, I'll be happy to get the ball rolling by
> starting the analysis for topping up the GitHub repo from the
> SourceForge oledbapi repo. If the latter, I guess the first step in
> that discussion would be for you to lay out the reason(s) why it
> wouldn't work to maintain the project just on GitHub (under pywin). Or
> perhaps you intended some third interpretation of "good plan."
>
> Cheers,
> Bob
>
>>
>> On Feb 19, 2018 04:57, "Bob Kline" <bkline at rksystems.com> wrote:
>>>
>>> On Mon, Feb 19, 2018 at 2:25 AM, Vernon D. Cole <vernondcole at gmail.com>
>>> wrote:
>>>
>>> > I will try to clear this up as much as I can...
>>>
>>> Thanks very much for your reply, Vernon.
>>>
>>> > Adodbapi lives in two places, as a stand-alone project on Sourceforge,
>>> > and
>>> > integrated with PyWin32.
>>>
>>> Well, I wouldn't go so far as saying it "lives" in the GitHub project;
>>> more like it's on life support. :-) As far as I can tell, it's never
>>> actually been usable from that repo, as the required apibase.py file
>>> didn't make it to the party.
>>>
>>> > The Sourceforge project is needed for Iron Python, and has more
>>> > documentation, and, originally, a faster upgrade cycle.
>>>
>>> I see, however, that the code to support IronPython is in both places,
>>> documentation can easily be enhanced, and (as you acknowledge) the
>>> upgrade cycle for the SourceForge project has gone walkabout. It would
>>> seem ideal (if nothing else, from the perspective of the attempt to
>>> attract more maintainers) if we didn't have to maintain two separate
>>> code bases.
>>>
>>> > The SF code was copied to pywin32 for easier installation and more
>>> > convenience, but the file layout is slightly different. I did not have
>>> > the
>>> > capability to test the pywin32 installation so was unaware of the
>>> > problem
>>> > until too late. Then I went to work for another company which did not
>>> > use
>>> > Windows at all, so everything got kind of lost.
>>> >
>>> > The move of pywin32 to GitHub, along with improved testing there will
>>> > help
>>> > to fix things.  I am also building an SQL server test bench which I hope
>>> > will be permanent. A patch has been submitted to fix the "missing file"
>>> > problem, and I have changed my SF notifications to a different email
>>> > address
>>> > that I check more frequently.
>>> >
>>> > The python-win project is the preferred maintenance place.
>>>
>>> Perhaps a note on the SourceForge page to that effect would be
>>> appropriate.
>>>
>>> > Meanwhile ... I am not getting any younger and an active back-up
>>> > maintainer
>>> > for the home adodbapi project would be very welcome if someone were
>>> > willing
>>> > to help out. At the present moment the "bus size" is one -- which is a
>>> > bad
>>> > thing.
>>>
>>> I'm happy to do what I can, though as I pointed out in an earlier
>>> thread, you're younger than I am. :-)
>>>
>>> If you provide instructions for getting the regression tests running,
>>> I'll try to replicate them here.
>>>
>>> Let's first decide the question of how many places we're going to
>>> maintain the package. I vote for one (on GitHub). If (for whatever
>>> reason) it's necessary to maintain it in two places, let's (a) decide
>>> whether it's possible to keep the two places synchronized so they
>>> don't drift into forks of each other; (b) figure out how such
>>> synchronization will be accomplished; and most important (c) make it
>>> very clear in both locations what the relationship is between the two
>>> repositories, telling everyone which one should be used in which
>>> situation, where to file issue tracking tickets, etc.
>>>
>>> Thanks again for your willingness to bring this project back to life.
>>>
>>> --
>>> Bob Kline
>>> http://www.rksystems.com
>>> mailto:bkline at rksystems.com
>
>
>
> --
> Bob Kline
> http://www.rksystems.com
> mailto:bkline at rksystems.com



-- 
Bob Kline
http://www.rksystems.com
mailto:bkline at rksystems.com

From bkline at rksystems.com  Wed Feb 21 10:26:27 2018
From: bkline at rksystems.com (Bob Kline)
Date: Wed, 21 Feb 2018 10:26:27 -0500
Subject: [python-win32] Bug reporting
In-Reply-To: <CAGjKmVpCoonM_X+W3ntaeJn4D=GET0A0GOX_1x9GHggWdr-i7w@mail.gmail.com>
References: <CAP6Y=No2p+BJ2uq-He0K39RhtuZ2fDTrF5q=2ao0B+CJ=+C9JA@mail.gmail.com>
 <CAGjKmVrZm_sb-A2NKsVYseZUvwB5q8zHqKbfPO-Mmo6m2nEY4A@mail.gmail.com>
 <CAGjKmVr1UiHXui3s=HB8x+7N4PekcTQL=7vaq6gkFBwJp+yFCg@mail.gmail.com>
 <CAH-ZgAcrjtsKV0ppTsfa2mFP9mu_253e8_Y85kuKWuiVyVVywA@mail.gmail.com>
 <CAGjKmVpfDLtRLby4MbDDEndhNs5eL2De_6Krqh2wX0gtbqS3Fw@mail.gmail.com>
 <CAH-ZgAdj8CC9qWHmpnADaw23VkrBJHSP_A_9VG5muiNmAZRJYg@mail.gmail.com>
 <CAGjKmVr6tZaA+p-Daau8fKCJB0gP835cj_iviJ5US_N9c4UGXQ@mail.gmail.com>
 <CAGjKmVpCoonM_X+W3ntaeJn4D=GET0A0GOX_1x9GHggWdr-i7w@mail.gmail.com>
Message-ID: <CAGjKmVqKV3CeGCjipQEi+1nyjjJmuniY0y6ia2710q_xyO6djw@mail.gmail.com>

[ Having a conversation with myself again :-) ]

It looks as if the second problem I reported with the Access suite is
a result of one of my patches. Apparently with the patch Access (but
not SQL Server) treats binary values incorrectly (at least sometimes).
Without the patch, SQL Server is unable to store a NULL value or an
empty string properly using placeholders. So we need to find out why
that is, and come up with a version of the patch which fixes the
second problem in SQL Server without introducing the first problem in
Access.

I have added MySQL to my test bed. That flushed out yet another error.
This is the output run using the unpatched (except for configuration
settings in adodbapitestconfig.py, of course, and supplying the
missing ../examples/adotest.mdb file) code base pulled directly from
the Mercurial server (hg clone http://hg.code.sf.net/p/adodbapi/code
adodbapi):

Z:\repos\adodbapi\test>python adodbapitest.py --mysql
2.7.13 (default, Jun 26 2017, 14:28:43) [MSC v.1500 64 bit (AMD64)]
node=xp: is64bit.os()= True, is64bit.Python()= True
adodbapi v2.6.1.3
testADOdbapiConfig.py v 2.6.0.A00
    ...copying test ACCESS db to
c:\users\bkline\appdata\local\temp\adodbapi_test\xx_T949JL5KW.mdb
    ...Testing ACCESS connection...
  (successful)
    ...Testing MS-SQL login...
  (successful)
    ...Testing MySql login...
  (successful)
 Unit tests version 2.6.1.0 for adodbapi
Default Date Converter is <adodbapi.apibase.pythonDateTimeConverter
object at 0x0000000006510CF8>
...................................................................................................................ADO
Errors:(1)
Description: [MySQL][ODBC 5.3(w)
Driver][mysqld-5.7.21-0ubuntu0.17.10.1]Data too long for column
'fldData' at row 1
Error: -2147467259 unknown
Source: Microsoft OLE DB Provider for ODBC Drivers
NativeError: 1406
SQL State: S1000
E...........................
======================================================================
ERROR: testDataTypeInt (__main__.TestADOwithMySql)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "adodbapitest.py", line 356, in testDataTypeInt
    self.helpTestDataType("bit",'NUMBER',1) #Does not work correctly with access
  File "adodbapitest.py", line 287, in helpTestDataType
    crsr.execute("INSERT INTO xx_%s (fldId,fldData) VALUES (?,?)" %
config.tmp, (fldId, inParam))
  File "Z:\repos\adodbapi\adodbapi.py", line 879, in execute
    self._execute_command()
  File "Z:\repos\adodbapi\adodbapi.py", line 694, in _execute_command
    self._raiseCursorError(klass, _message)
  File "Z:\repos\adodbapi\adodbapi.py", line 567, in _raiseCursorError
    eh(self.connection, self, errorclass, errorvalue)
  File "Z:\repos\adodbapi\apibase.py", line 54, in standardErrorHandler
    raise errorclass(errorvalue)
DatabaseError: (-2147352567, 'Exception occurred.', (0, u'Microsoft
OLE DB Provider for ODBC Drivers', u"[MySQL][ODBC 5.3(w)
Driver][mysqld-5.7.21-0ubuntu0.17.10.1]Data too long for column
'fldData' at row 1", None, 0, -2147467259), None)
Command:
INSERT INTO xx_T949JL5KW (fldId,fldData) VALUES (?,?)
Parameters:
[Name: p0, Dir.: Input, Type: adInteger, Size: 0, Value: "2",
Precision: 0, NumericScale: 0
Name: p1, Dir.: Input, Type: adInteger, Size: 0, Value: "1",
Precision: 0, NumericScale: 0]

----------------------------------------------------------------------
Ran 143 tests in 35.413s

FAILED (errors=1)

Thanks,
Bob

On Wed, Feb 21, 2018 at 7:31 AM, Bob Kline <bkline at rksystems.com> wrote:
> Hi, Vernon. I'm afraid I'm going to start sounding like an annoying
> nag. :-) If you really want help with this project, you need to meet
> me half way. If you're swamped with work right now, please at least
> write back and say something like "I'm buried under a project right
> now, and I won't be able to get back to you until next Friday." If
> you're in hospital with a serious illness, I sincerely apologize and
> I'll back off. If you'd prefer to take this thread offline, that's
> fine with me, too.
>
> I asked for guidance in getting the regression tests running (if we're
> going to attract maintainers, one of the first things that needs to
> happen is for the configuration script for the test suite to be made
> much simpler to adapt to a specific platform, with all of the values
> which need to be modified collected in one place with clear
> documentation for what each of them means), but I didn't see anything
> from you in response to that request, so I plunged in on my own. I've
> got the SQL Server and Access tests running, and expect it won't be
> too long before I've got the other back ends set up and plugged in. I
> ran into two problems with the Access tests. The first is that
> setuptestframework.py tries to copy a file from
> ../examples/adotest.mdb and that file doesn't exist (except perhaps on
> your own machine). I solved that by firing up Access and creating the
> missing file myself. The second problem is that one of the tests in
> the suite fails. From the error message, it appears that the package
> (or perhaps something else in the stack) is trying to treat a binary
> value as a string (note the presence of the null terminator at the end
> of the value and the extra quote marks in the repr() output):
>
> C:\Python\Lib\site-packages\adodbapi\test>adodbapitest.py
> 2.7.13 (default, Jun 26 2017, 14:28:43) [MSC v.1500 64 bit (AMD64)]
> node=xp: is64bit.os()= True, is64bit.Python()= True
> adodbapi v2.6.0.7
> testADOdbapiConfig.py v 2.6.0.A00
>     ...copying test ACCESS db to
> c:\users\bkline\appdata\local\temp\adodbapi_test\xx_COU8KEJ7K.mdb
>     ...Testing ACCESS connection...
>   (successful)
>     ...Testing MS-SQL login...
>   (successful)
>  Unit tests version 2.6.0.6 for adodbapi
> Default Date Converter is <adodbapi.apibase.pythonDateTimeConverter
> object at 0x0000000005970C18>
> ...............................F.......................................................................
> ======================================================================
> FAIL: testDataTypeBinary (__main__.TestADOwithAccessDB)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>   File "C:\Python\Lib\site-packages\adodbapi\test\adodbapitest.py",
> line 395, in testDataTypeBinary
>     allowedReturnValues=arv)
>   File "C:\Python\Lib\site-packages\adodbapi\test\adodbapitest.py",
> line 314, in helpTestDataType
>     'Value "%s" not in %s' % (repr(rs[0]), allowedReturnValues))
> AssertionError: Value "'\x07\x00\xe2@\x00'" not in ['\x07\x00\xe2@*',
> <read-only buffer for 0x0000000005183990, size -1, offset 0 at
> 0x0000000005A0D6C0>, '\x07\x00\xe2@*']
>
> ----------------------------------------------------------------------
> Ran 103 tests in 8.394s
>
> FAILED (failures=1)
>
> I get the same failure if I use a more modern .accdb file.
>
> Again, I apologize for this blunt message, but you've done some good
> work on this package, and it's worth getting it back on the road.
>
> Regards,
> Bob Kline
>
> On Mon, Feb 19, 2018 at 11:59 AM, Bob Kline <bkline at rksystems.com> wrote:
>> On Mon, Feb 19, 2018 at 11:18 AM, Vernon D. Cole <vernondcole at gmail.com> wrote:
>>
>>> Sounds like a good plan.
>>
>> As in, "yes, let's consolidate the project in one place (under pywin
>> on GitHub)"? Or did you mean "yes, I agree we should have the
>> discussion about whether we have to maintain the package in more than
>> one place"? If the former, I'll be happy to get the ball rolling by
>> starting the analysis for topping up the GitHub repo from the
>> SourceForge oledbapi repo. If the latter, I guess the first step in
>> that discussion would be for you to lay out the reason(s) why it
>> wouldn't work to maintain the project just on GitHub (under pywin). Or
>> perhaps you intended some third interpretation of "good plan."
>>
>> Cheers,
>> Bob
>>
>>>
>>> On Feb 19, 2018 04:57, "Bob Kline" <bkline at rksystems.com> wrote:
>>>>
>>>> On Mon, Feb 19, 2018 at 2:25 AM, Vernon D. Cole <vernondcole at gmail.com>
>>>> wrote:
>>>>
>>>> > I will try to clear this up as much as I can...
>>>>
>>>> Thanks very much for your reply, Vernon.
>>>>
>>>> > Adodbapi lives in two places, as a stand-alone project on Sourceforge,
>>>> > and
>>>> > integrated with PyWin32.
>>>>
>>>> Well, I wouldn't go so far as saying it "lives" in the GitHub project;
>>>> more like it's on life support. :-) As far as I can tell, it's never
>>>> actually been usable from that repo, as the required apibase.py file
>>>> didn't make it to the party.
>>>>
>>>> > The Sourceforge project is needed for Iron Python, and has more
>>>> > documentation, and, originally, a faster upgrade cycle.
>>>>
>>>> I see, however, that the code to support IronPython is in both places,
>>>> documentation can easily be enhanced, and (as you acknowledge) the
>>>> upgrade cycle for the SourceForge project has gone walkabout. It would
>>>> seem ideal (if nothing else, from the perspective of the attempt to
>>>> attract more maintainers) if we didn't have to maintain two separate
>>>> code bases.
>>>>
>>>> > The SF code was copied to pywin32 for easier installation and more
>>>> > convenience, but the file layout is slightly different. I did not have
>>>> > the
>>>> > capability to test the pywin32 installation so was unaware of the
>>>> > problem
>>>> > until too late. Then I went to work for another company which did not
>>>> > use
>>>> > Windows at all, so everything got kind of lost.
>>>> >
>>>> > The move of pywin32 to GitHub, along with improved testing there will
>>>> > help
>>>> > to fix things.  I am also building an SQL server test bench which I hope
>>>> > will be permanent. A patch has been submitted to fix the "missing file"
>>>> > problem, and I have changed my SF notifications to a different email
>>>> > address
>>>> > that I check more frequently.
>>>> >
>>>> > The python-win project is the preferred maintenance place.
>>>>
>>>> Perhaps a note on the SourceForge page to that effect would be
>>>> appropriate.
>>>>
>>>> > Meanwhile ... I am not getting any younger and an active back-up
>>>> > maintainer
>>>> > for the home adodbapi project would be very welcome if someone were
>>>> > willing
>>>> > to help out. At the present moment the "bus size" is one -- which is a
>>>> > bad
>>>> > thing.
>>>>
>>>> I'm happy to do what I can, though as I pointed out in an earlier
>>>> thread, you're younger than I am. :-)
>>>>
>>>> If you provide instructions for getting the regression tests running,
>>>> I'll try to replicate them here.
>>>>
>>>> Let's first decide the question of how many places we're going to
>>>> maintain the package. I vote for one (on GitHub). If (for whatever
>>>> reason) it's necessary to maintain it in two places, let's (a) decide
>>>> whether it's possible to keep the two places synchronized so they
>>>> don't drift into forks of each other; (b) figure out how such
>>>> synchronization will be accomplished; and most important (c) make it
>>>> very clear in both locations what the relationship is between the two
>>>> repositories, telling everyone which one should be used in which
>>>> situation, where to file issue tracking tickets, etc.
>>>>
>>>> Thanks again for your willingness to bring this project back to life.
>>>>
>>>> --
>>>> Bob Kline
>>>> http://www.rksystems.com
>>>> mailto:bkline at rksystems.com
>>
>>
>>
>> --
>> Bob Kline
>> http://www.rksystems.com
>> mailto:bkline at rksystems.com
>
>
>
> --
> Bob Kline
> http://www.rksystems.com
> mailto:bkline at rksystems.com



-- 
Bob Kline
http://www.rksystems.com
mailto:bkline at rksystems.com

From vernondcole at gmail.com  Wed Feb 21 12:04:21 2018
From: vernondcole at gmail.com (Vernon D. Cole)
Date: Wed, 21 Feb 2018 10:04:21 -0700
Subject: [python-win32] Bug reporting
In-Reply-To: <CAGjKmVqKV3CeGCjipQEi+1nyjjJmuniY0y6ia2710q_xyO6djw@mail.gmail.com>
References: <CAP6Y=No2p+BJ2uq-He0K39RhtuZ2fDTrF5q=2ao0B+CJ=+C9JA@mail.gmail.com>
 <CAGjKmVrZm_sb-A2NKsVYseZUvwB5q8zHqKbfPO-Mmo6m2nEY4A@mail.gmail.com>
 <CAGjKmVr1UiHXui3s=HB8x+7N4PekcTQL=7vaq6gkFBwJp+yFCg@mail.gmail.com>
 <CAH-ZgAcrjtsKV0ppTsfa2mFP9mu_253e8_Y85kuKWuiVyVVywA@mail.gmail.com>
 <CAGjKmVpfDLtRLby4MbDDEndhNs5eL2De_6Krqh2wX0gtbqS3Fw@mail.gmail.com>
 <CAH-ZgAdj8CC9qWHmpnADaw23VkrBJHSP_A_9VG5muiNmAZRJYg@mail.gmail.com>
 <CAGjKmVr6tZaA+p-Daau8fKCJB0gP835cj_iviJ5US_N9c4UGXQ@mail.gmail.com>
 <CAGjKmVpCoonM_X+W3ntaeJn4D=GET0A0GOX_1x9GHggWdr-i7w@mail.gmail.com>
 <CAGjKmVqKV3CeGCjipQEi+1nyjjJmuniY0y6ia2710q_xyO6djw@mail.gmail.com>
Message-ID: <CAH-ZgAefJnorOjOYWz5QV=Mvar+1D0v=5EtvR0sUD+V7ad7Ueg@mail.gmail.com>

Ummm ... "I'm buried under a project right now, and I won't be able to get
back to you until next Friday." My day job has been burning up a lot of
time, and we had an important Family Occasion on Saturday that ate the
entire weekend. Sorry.  I will try to do better at context switching.

You are heading in exactly the correct direction with the test suite.

As for a single copy of the source -- would it work to keep the stand-alone
(Iron Python) distribution in the /adodbapi directory on GitHub, and just
ignore the extra files (for the big distribution) by not putting them in
the main manifest?  @Mark -- please chime in here...

> On Mon, Feb 19, 2018 at 11:59 AM, Bob Kline <bkline at rksystems.com> wrote:

> >> On Mon, Feb 19, 2018 at 11:18 AM, Vernon D. Cole <vernondcole at gmail.com>
> wrote:
> >>
> >>> Sounds like a good plan.
> >>
> >> As in, "yes, let's consolidate the project in one place (under pywin
> >> on GitHub)"? Or did you mean "yes, I agree we should have the
> >> discussion about whether we have to maintain the package in more than
> >> one place"? If the former, I'll be happy to get the ball rolling by
> >> starting the analysis for topping up the GitHub repo from the
> >> SourceForge oledbapi repo. If the latter, I guess the first step in
> >> that discussion would be for you to lay out the reason(s) why it
> >> wouldn't work to maintain the project just on GitHub (under pywin). Or
> >> perhaps you intended some third interpretation of "good plan."
> >>
> >> Cheers,
> >> Bob
> >>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-win32/attachments/20180221/63935746/attachment.html>

From bkline at rksystems.com  Wed Feb 21 12:37:14 2018
From: bkline at rksystems.com (Bob Kline)
Date: Wed, 21 Feb 2018 12:37:14 -0500
Subject: [python-win32] Bug reporting
In-Reply-To: <CAH-ZgAefJnorOjOYWz5QV=Mvar+1D0v=5EtvR0sUD+V7ad7Ueg@mail.gmail.com>
References: <CAP6Y=No2p+BJ2uq-He0K39RhtuZ2fDTrF5q=2ao0B+CJ=+C9JA@mail.gmail.com>
 <CAGjKmVrZm_sb-A2NKsVYseZUvwB5q8zHqKbfPO-Mmo6m2nEY4A@mail.gmail.com>
 <CAGjKmVr1UiHXui3s=HB8x+7N4PekcTQL=7vaq6gkFBwJp+yFCg@mail.gmail.com>
 <CAH-ZgAcrjtsKV0ppTsfa2mFP9mu_253e8_Y85kuKWuiVyVVywA@mail.gmail.com>
 <CAGjKmVpfDLtRLby4MbDDEndhNs5eL2De_6Krqh2wX0gtbqS3Fw@mail.gmail.com>
 <CAH-ZgAdj8CC9qWHmpnADaw23VkrBJHSP_A_9VG5muiNmAZRJYg@mail.gmail.com>
 <CAGjKmVr6tZaA+p-Daau8fKCJB0gP835cj_iviJ5US_N9c4UGXQ@mail.gmail.com>
 <CAGjKmVpCoonM_X+W3ntaeJn4D=GET0A0GOX_1x9GHggWdr-i7w@mail.gmail.com>
 <CAGjKmVqKV3CeGCjipQEi+1nyjjJmuniY0y6ia2710q_xyO6djw@mail.gmail.com>
 <CAH-ZgAefJnorOjOYWz5QV=Mvar+1D0v=5EtvR0sUD+V7ad7Ueg@mail.gmail.com>
Message-ID: <CAGjKmVqQFfWUjtDueF+sJ97fdt778wQyX7OTD1ru6z5N8sqpFg@mail.gmail.com>

On Wed, Feb 21, 2018 at 12:04 PM, Vernon D. Cole <vernondcole at gmail.com> wrote:
> Ummm ... "I'm buried under a project right now, and I won't be able to get
> back to you until next Friday."

No worries. I'll keep plugging along with getting my test bed
assembled and then hold off until you come up for air.

Thanks,
Bob

From bkline at rksystems.com  Wed Feb 21 19:12:51 2018
From: bkline at rksystems.com (Bob Kline)
Date: Wed, 21 Feb 2018 19:12:51 -0500
Subject: [python-win32] Bug reporting
In-Reply-To: <CAGjKmVqKV3CeGCjipQEi+1nyjjJmuniY0y6ia2710q_xyO6djw@mail.gmail.com>
References: <CAP6Y=No2p+BJ2uq-He0K39RhtuZ2fDTrF5q=2ao0B+CJ=+C9JA@mail.gmail.com>
 <CAGjKmVrZm_sb-A2NKsVYseZUvwB5q8zHqKbfPO-Mmo6m2nEY4A@mail.gmail.com>
 <CAGjKmVr1UiHXui3s=HB8x+7N4PekcTQL=7vaq6gkFBwJp+yFCg@mail.gmail.com>
 <CAH-ZgAcrjtsKV0ppTsfa2mFP9mu_253e8_Y85kuKWuiVyVVywA@mail.gmail.com>
 <CAGjKmVpfDLtRLby4MbDDEndhNs5eL2De_6Krqh2wX0gtbqS3Fw@mail.gmail.com>
 <CAH-ZgAdj8CC9qWHmpnADaw23VkrBJHSP_A_9VG5muiNmAZRJYg@mail.gmail.com>
 <CAGjKmVr6tZaA+p-Daau8fKCJB0gP835cj_iviJ5US_N9c4UGXQ@mail.gmail.com>
 <CAGjKmVpCoonM_X+W3ntaeJn4D=GET0A0GOX_1x9GHggWdr-i7w@mail.gmail.com>
 <CAGjKmVqKV3CeGCjipQEi+1nyjjJmuniY0y6ia2710q_xyO6djw@mail.gmail.com>
Message-ID: <CAGjKmVqv43_z33765=0Yj3_A4URUpNdxC=SBO-oEwKa_+h5w8Q@mail.gmail.com>

On Wed, Feb 21, 2018 at 10:26 AM, Bob Kline <bkline at rksystems.com> wrote:

> Without the patch, SQL Server is unable to store a NULL value or an
> empty string properly using placeholders. So we need to find out why
> that is, and come up with a version of the patch which fixes the
> second problem in SQL Server without introducing the first problem in
> Access.

The original code only tries to use ADO's existing parameters if a
stored procedure is being invoked. The comment said:

    # needed only if we are calling a stored procedure

Can you tell us why this would be true? Do we know for sure that the
binary-handling problem I ran into doesn't bite us if we're in a
stored procedure?

The solutions (for the two bugs my patch attempted to address) which
come immediately to mind include:

  1. figure out exactly what the difference is in the behavior or
ADO's parms and the ones the code replaces them with; base the
solution on this understanding;

  2. if it is possible to detect at this point in the code which DBMS
engine is being used, then branch in the logic based on that
knowledge; or

  3. allow the user of the package to control whether we try to use
ADO's parameter list

Clearly, the first solution is the ideal choice, if we can pull it
off. I'm not sure about the relative merits of the other two. The
second option has the advantage of avoiding bug reports from users who
didn't manage to find the documentation about setting the special
option to avoid the bugs we're trying to fix (as would be required by
option #3). The last option gives the users who do read all the
documentation the flexibility to control the behavior, with perhaps
the better chance of avoiding the bugs we're wrestling with. It (that
is, the attractiveness of option #2) partly depends on (a) how
reliable our detection of which DBMS we're talking to is and (b) how
confident we are that we know which paths will produce the desired
behavior for which DBMS engines.

You might have thought of other solutions which haven't occurred to me
yet. I'm all ears. :-)

Cheers,
Bob

From bkline at rksystems.com  Sat Feb 24 14:54:24 2018
From: bkline at rksystems.com (Bob Kline)
Date: Sat, 24 Feb 2018 14:54:24 -0500
Subject: [python-win32] Parameters in adodbapi [was Re:  Bug reporting]
Message-ID: <CAGjKmVrP9a0=b_7rBzxD9ER9r9gRe+naZfXB3hDvk3k0vsSamQ@mail.gmail.com>

On Wed, Feb 21, 2018 at 7:12 PM, Bob Kline <bkline at rksystems.com> wrote:

> The solutions (for the two bugs my patch attempted to address) which
> come immediately to mind include: ....

Here's what I think I've been able to determine at this point.

1. The adodbapi package uses two approaches to the ADO Parameter
objects needed for operations with placeholders. The approach adopted
currently for stored procedure invocation tries to use the Parameter
objects created by the underlying provider, based on the definition of
the column associated with the placeholder. For operations which are
not invoking stored procedures (and for stored procedures where the
provider fails to create Parameter objects) the package creates the
Parameter objects itself, based not on the column definitions
associated with the placeholders, but instead on the values being
plugged in for those placeholders.

2. Creating Parameter objects based on the values being passed for an
operation sometimes results in failure or an incorrect result. For
example, trying to pass None in the values list for a column defined
as "NTEXT NULL" fails on SQL Server with an exception complaining
"Operand type clash: int is incompatible with ntext." For another
example, passing an empty string ("") for a VARCHAR column results in
a single blank character being stored on SQL Server.

3. Some providers do a better job than others at figuring out what the
ADO data type code should be for a given column definition. For
example, the SQLOLEDB provider, used to talk to Microsoft's SQL
Server, selects adVarBinary for a column defined as varbinary(5),
whereas the Microsoft ACE provider, connected to an Access database,
thinks the correct type is adVarWChar for the same column definition,
with the result that an incorrect value is stored. The ODBC 5.3(w)
driver for MySQL has a similar problem (worse, actually, as it
discards information).

4. Running against MS SQL Server and PostgreSQL (I've completed the
setup of my test bed for the package), all tests in the unit test
suite pass using either approach to ADO Parameter objects. Running the
suite against an Access or MySQL database, one test fails when the
package uses the Parameter objects created by the ADO layer (because
of the problem described immediately above), but passes when the
package creates its own Parameter objects. All of the other tests pass
for Access. As I reported earlier in this thread, the test of storing
a value in a 'bit' column fails when running the suite against a MySQL
database no matter which approach to Parameter objects is used.

5. These observations seem to lead to the conclusion that we need one
approach to Parameter object handling when connected to SQL Server and
a different approach when we're talking to MySQL or an Access database
(or at least when using the driver/providers with which I've been
testing). PostgreSQL is the only DBMS which appears to work correctly
with either approach.

6. The package already has an extension attribute (dbms_name) on the
connection object identifying which DBMS we're connected to. My
recommendation would be to use that information to decide which
approach to take to Parameter objects, using the existing Parameter
Objects if the DBMS name is "Microsoft SQL Server" or if (preserving
the current behavior) the operation is the invocation of a stored
procedure. If you agree, I'll come up with a new pair of pull requests
to address the two bugs describe above in paragraph #2.

7. If it is unacceptable to change the current behavior silently for
connections to SQL Server, we would need a way for the programmer to
tell the package which approach is needed for handling Parameter
objects. The simplest way would be to have a module-level variable
(similar to the dateconverter variable, which is documented as
something the user can override). However, this would be awkward for a
program which needed to communicate with two different databases.
Perhaps a connection-level extension would be more appropriate, with
an optional keyword argument passed to the connect() function.
Presumably the default should be to keep the current behavior to avoid
introducing new breakage for existing code (though I suspect most of
the use of the package is for talking to SQL Server, possibly by a
large margin).

When you come up for air, Vernon, I'll be grateful for any corrections
you can provide for any errors I've made in this analysis. One thing I
should point out is that some of what I've written here is based on
the results of the regression test suite, and I can see that there are
places where certain of those tests are altered or even suppressed at
run time depending on which engine is in play. It's conceivable that
had the package always used Parameter object created internally by ADO
(when available) that tweaking would have been done differently, and
there would be no failures or errors from the test suite for those
objects.

-- 
Bob Kline
http://www.rksystems.com
mailto:bkline at rksystems.com

From mhammond at skippinet.com.au  Sun Feb 25 00:31:39 2018
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Sun, 25 Feb 2018 16:31:39 +1100
Subject: [python-win32] Bug reporting
In-Reply-To: <CAH-ZgAefJnorOjOYWz5QV=Mvar+1D0v=5EtvR0sUD+V7ad7Ueg@mail.gmail.com>
References: <CAP6Y=No2p+BJ2uq-He0K39RhtuZ2fDTrF5q=2ao0B+CJ=+C9JA@mail.gmail.com>
 <CAGjKmVrZm_sb-A2NKsVYseZUvwB5q8zHqKbfPO-Mmo6m2nEY4A@mail.gmail.com>
 <CAGjKmVr1UiHXui3s=HB8x+7N4PekcTQL=7vaq6gkFBwJp+yFCg@mail.gmail.com>
 <CAH-ZgAcrjtsKV0ppTsfa2mFP9mu_253e8_Y85kuKWuiVyVVywA@mail.gmail.com>
 <CAGjKmVpfDLtRLby4MbDDEndhNs5eL2De_6Krqh2wX0gtbqS3Fw@mail.gmail.com>
 <CAH-ZgAdj8CC9qWHmpnADaw23VkrBJHSP_A_9VG5muiNmAZRJYg@mail.gmail.com>
 <CAGjKmVr6tZaA+p-Daau8fKCJB0gP835cj_iviJ5US_N9c4UGXQ@mail.gmail.com>
 <CAGjKmVpCoonM_X+W3ntaeJn4D=GET0A0GOX_1x9GHggWdr-i7w@mail.gmail.com>
 <CAGjKmVqKV3CeGCjipQEi+1nyjjJmuniY0y6ia2710q_xyO6djw@mail.gmail.com>
 <CAH-ZgAefJnorOjOYWz5QV=Mvar+1D0v=5EtvR0sUD+V7ad7Ueg@mail.gmail.com>
Message-ID: <25b03231-c10d-84e1-2c9e-18a4863c9316@skippinet.com.au>

On 22/02/2018 4:04 am, Vernon D. Cole wrote:
> Ummm ... "I'm buried under a project right now, and I won't be able to 
> get back to you until next Friday."

I'm afraid Bob is going to get quite frustrated if he gets upset about 
responses taking more than a few days to come in. While pywin32 has 
moved to github, I honestly don't expect the release cadence, nor the 
amount of time I can offer the project to change from what it has been 
over the last few years.

> My day job has been burning up a lot 
> of time, and we had an important Family Occasion on Saturday that ate 
> the entire weekend. Sorry.? I will try to do better at context switching.

There's no need to apologize for life getting in the way of maintaining 
free and open source software.

> You are heading in exactly the correct direction with the test suite.
> 
> As for a single copy of the source -- would it work to keep the 
> stand-alone (Iron Python) distribution in the /adodbapi directory on 
> GitHub, and just ignore the extra files (for the big distribution) by 
> not putting them in the main manifest?? @Mark -- please chime in here...

I'm afraid I don't really know what is being asked here. adodbapi has 
been in pywin32 for many years - what changes exactly are being 
proposed? I see mention of IronPython, but I don't understand how 
IronPython components in pywin32 makes sense for either the people 
releasing pywin32 packages (ie, me), nor how IronPython users would take 
advantage of them (ie, I assume asking them to install pywin32 doesn't 
make sense).

Cheers,

Mark

From bkline at rksystems.com  Sun Feb 25 09:12:24 2018
From: bkline at rksystems.com (Bob Kline)
Date: Sun, 25 Feb 2018 09:12:24 -0500
Subject: [python-win32] Bug reporting
In-Reply-To: <25b03231-c10d-84e1-2c9e-18a4863c9316@skippinet.com.au>
References: <CAP6Y=No2p+BJ2uq-He0K39RhtuZ2fDTrF5q=2ao0B+CJ=+C9JA@mail.gmail.com>
 <CAGjKmVrZm_sb-A2NKsVYseZUvwB5q8zHqKbfPO-Mmo6m2nEY4A@mail.gmail.com>
 <CAGjKmVr1UiHXui3s=HB8x+7N4PekcTQL=7vaq6gkFBwJp+yFCg@mail.gmail.com>
 <CAH-ZgAcrjtsKV0ppTsfa2mFP9mu_253e8_Y85kuKWuiVyVVywA@mail.gmail.com>
 <CAGjKmVpfDLtRLby4MbDDEndhNs5eL2De_6Krqh2wX0gtbqS3Fw@mail.gmail.com>
 <CAH-ZgAdj8CC9qWHmpnADaw23VkrBJHSP_A_9VG5muiNmAZRJYg@mail.gmail.com>
 <CAGjKmVr6tZaA+p-Daau8fKCJB0gP835cj_iviJ5US_N9c4UGXQ@mail.gmail.com>
 <CAGjKmVpCoonM_X+W3ntaeJn4D=GET0A0GOX_1x9GHggWdr-i7w@mail.gmail.com>
 <CAGjKmVqKV3CeGCjipQEi+1nyjjJmuniY0y6ia2710q_xyO6djw@mail.gmail.com>
 <CAH-ZgAefJnorOjOYWz5QV=Mvar+1D0v=5EtvR0sUD+V7ad7Ueg@mail.gmail.com>
 <25b03231-c10d-84e1-2c9e-18a4863c9316@skippinet.com.au>
Message-ID: <CAGjKmVqTL48+vwnJogdHq5ZhcqnqdJJVVZSVJtzabwuO8fnSMA@mail.gmail.com>

On Sun, Feb 25, 2018 at 12:31 AM, Mark Hammond
<mhammond at skippinet.com.au> wrote:

> I'm afraid Bob is going to get quite frustrated if he gets upset about
> responses taking more than a few days to come in.

I'm going to assume you hadn't yet read the thread leading up to
Vernon's last message. Here is some historical context which you may
be missing.

The adodbapi package exists in two places, the original on
SourceForge, and the newer fork which forms a part of your pywin32
project on GitHub (migrated from its own earlier SourceForge hosting,
where the incorporation of the adodbapi fork had already taken place).
Vernon has provided no indication that I could find in the SourceForge
project, that bug reports should now be submitted to the GitHub fork,
and in fact there are explicit instructions to file adodbapi bug
reports on SF. Nevertheless, there are bug reports that have sat for
years in the SF tracker for the project with no maintainer responses
at all (I would provide more specifics, but SourceForge is actually
down at the moment), and I recently was advised on this mailing list
that I should be filing my bug reports for the package on GitHub, not
SourceForge.

As far as I can tell, the adodbapi fork in the pywin32 GitHub
repository has been completely broken for at least four years. So it's
impossible to import the adodbapi GitHub/pywin32 fork, much less run
the unit test suite one would normally incorporate into the
preparation of a pull request. Vernon replied to the bug reporting
this breakage (https://github.com/mhammond/pywin32/issues/671) in
2014, providing the workaround of installing the original SourceForge
adodbapi, but there's been no movement on that bug since then. He has
at various times since then mentioned the difficulties he has had with
his Windows development/testing platform and said that he's been
working on getting it functional again.

Here's my take on the current situation. Vernon has acknowledged the
problems I just described, has reached out asking for assistance in
getting them solved, and is appreciative of the offer I have made to
help. He indicated that he wouldn't be able to get back to me for a
week or so because of current work and family obligations, and I
thanked him for his reply and told him I was happy to wait until he
was able to come up for air. As far as I can tell, we're on the right
path to solving the problems.

> While pywin32 has moved to
> github, I honestly don't expect the release cadence, nor the amount of time
> I can offer the project to change from what it has been over the last few
> years.

There's nothing wrong with the release cadence. I just don't want more
years to go by before the problems with the adodbapi package are
addressed. I'm trying to help Vernon achieve that goal.

> There's no need to apologize for life getting in the way of maintaining free
> and open source software.

I absolutely agree. However, taking 30 seconds to write "sorry, I'm
not going to be able to look at this until [expected re-engagement
date]" (as Vernon did in his last reply) goes a long way when you're
trying to encourage assistance from your users.

Regards,
Bob

From planders at gmail.com  Sun Feb 25 12:04:21 2018
From: planders at gmail.com (Preston Landers)
Date: Sun, 25 Feb 2018 17:04:21 +0000
Subject: [python-win32] Bug reporting
In-Reply-To: <CAGjKmVqTL48+vwnJogdHq5ZhcqnqdJJVVZSVJtzabwuO8fnSMA@mail.gmail.com>
References: <CAP6Y=No2p+BJ2uq-He0K39RhtuZ2fDTrF5q=2ao0B+CJ=+C9JA@mail.gmail.com>
 <CAGjKmVrZm_sb-A2NKsVYseZUvwB5q8zHqKbfPO-Mmo6m2nEY4A@mail.gmail.com>
 <CAGjKmVr1UiHXui3s=HB8x+7N4PekcTQL=7vaq6gkFBwJp+yFCg@mail.gmail.com>
 <CAH-ZgAcrjtsKV0ppTsfa2mFP9mu_253e8_Y85kuKWuiVyVVywA@mail.gmail.com>
 <CAGjKmVpfDLtRLby4MbDDEndhNs5eL2De_6Krqh2wX0gtbqS3Fw@mail.gmail.com>
 <CAH-ZgAdj8CC9qWHmpnADaw23VkrBJHSP_A_9VG5muiNmAZRJYg@mail.gmail.com>
 <CAGjKmVr6tZaA+p-Daau8fKCJB0gP835cj_iviJ5US_N9c4UGXQ@mail.gmail.com>
 <CAGjKmVpCoonM_X+W3ntaeJn4D=GET0A0GOX_1x9GHggWdr-i7w@mail.gmail.com>
 <CAGjKmVqKV3CeGCjipQEi+1nyjjJmuniY0y6ia2710q_xyO6djw@mail.gmail.com>
 <CAH-ZgAefJnorOjOYWz5QV=Mvar+1D0v=5EtvR0sUD+V7ad7Ueg@mail.gmail.com>
 <25b03231-c10d-84e1-2c9e-18a4863c9316@skippinet.com.au>
 <CAGjKmVqTL48+vwnJogdHq5ZhcqnqdJJVVZSVJtzabwuO8fnSMA@mail.gmail.com>
Message-ID: <CAKgs+RWFPB9Jev13Cw0-ah3gXYbJr+7PcW8j1ZGeLX36mDEvAg@mail.gmail.com>

Bob,

Is there are reason you can't use PyODBC?
https://github.com/mkleehammer/pyodbc/wiki

It is more actively maintained and I've used it successfully for years.

I'm curious what adodbapi is doing for you that PyODBC can't? Are you using
non-SQL data sources?

thanks,
Preston
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-win32/attachments/20180225/2567d627/attachment.html>

From bkline at rksystems.com  Sun Feb 25 16:17:35 2018
From: bkline at rksystems.com (Bob Kline)
Date: Sun, 25 Feb 2018 16:17:35 -0500
Subject: [python-win32] Bug reporting
In-Reply-To: <CAKgs+RWFPB9Jev13Cw0-ah3gXYbJr+7PcW8j1ZGeLX36mDEvAg@mail.gmail.com>
References: <CAP6Y=No2p+BJ2uq-He0K39RhtuZ2fDTrF5q=2ao0B+CJ=+C9JA@mail.gmail.com>
 <CAGjKmVrZm_sb-A2NKsVYseZUvwB5q8zHqKbfPO-Mmo6m2nEY4A@mail.gmail.com>
 <CAGjKmVr1UiHXui3s=HB8x+7N4PekcTQL=7vaq6gkFBwJp+yFCg@mail.gmail.com>
 <CAH-ZgAcrjtsKV0ppTsfa2mFP9mu_253e8_Y85kuKWuiVyVVywA@mail.gmail.com>
 <CAGjKmVpfDLtRLby4MbDDEndhNs5eL2De_6Krqh2wX0gtbqS3Fw@mail.gmail.com>
 <CAH-ZgAdj8CC9qWHmpnADaw23VkrBJHSP_A_9VG5muiNmAZRJYg@mail.gmail.com>
 <CAGjKmVr6tZaA+p-Daau8fKCJB0gP835cj_iviJ5US_N9c4UGXQ@mail.gmail.com>
 <CAGjKmVpCoonM_X+W3ntaeJn4D=GET0A0GOX_1x9GHggWdr-i7w@mail.gmail.com>
 <CAGjKmVqKV3CeGCjipQEi+1nyjjJmuniY0y6ia2710q_xyO6djw@mail.gmail.com>
 <CAH-ZgAefJnorOjOYWz5QV=Mvar+1D0v=5EtvR0sUD+V7ad7Ueg@mail.gmail.com>
 <25b03231-c10d-84e1-2c9e-18a4863c9316@skippinet.com.au>
 <CAGjKmVqTL48+vwnJogdHq5ZhcqnqdJJVVZSVJtzabwuO8fnSMA@mail.gmail.com>
 <CAKgs+RWFPB9Jev13Cw0-ah3gXYbJr+7PcW8j1ZGeLX36mDEvAg@mail.gmail.com>
Message-ID: <CAGjKmVryNGpiQUTWJerSA2gLMBmiB5aeVvd81T4JrOEt9J12vw@mail.gmail.com>

On Sun, Feb 25, 2018 at 12:04 PM, Preston Landers <planders at gmail.com> wrote:

> Is there [any] reason you can't use PyODBC? ....

A reasonable question. This is not for a new project. When it was
first started the analysis of the available options for database
connection libraries came to the conclusion that the PyODBC wasn't
ready for prime time. At this point, while it might be possible to do
the archaeological work needed to track down the specifics behind that
decision, it would almost certainly be more profitable to do a fresh
assessment at some point based on where the package is now. I can
imagine that after all this time it's likely that many of the flaws
have been addressed. Not a trivial exercise, you understand, to do all
the testing of a large application needed to make sure nothing gets
broken with a new database layer, so not something we'd undertake
lightly. Assuming the effort to clean up the rough edges of the
ADODB-base package goes smoothly we'll probably stick with what we're
using, at least for the immediate future.

But thanks for the suggestion. You never know. :-)

-- 
Bob Kline
http://www.rksystems.com
mailto:bkline at rksystems.com

From mhammond at skippinet.com.au  Sun Feb 25 18:18:32 2018
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Mon, 26 Feb 2018 10:18:32 +1100
Subject: [python-win32] Bug reporting
In-Reply-To: <CAGjKmVqTL48+vwnJogdHq5ZhcqnqdJJVVZSVJtzabwuO8fnSMA@mail.gmail.com>
References: <CAP6Y=No2p+BJ2uq-He0K39RhtuZ2fDTrF5q=2ao0B+CJ=+C9JA@mail.gmail.com>
 <CAGjKmVrZm_sb-A2NKsVYseZUvwB5q8zHqKbfPO-Mmo6m2nEY4A@mail.gmail.com>
 <CAGjKmVr1UiHXui3s=HB8x+7N4PekcTQL=7vaq6gkFBwJp+yFCg@mail.gmail.com>
 <CAH-ZgAcrjtsKV0ppTsfa2mFP9mu_253e8_Y85kuKWuiVyVVywA@mail.gmail.com>
 <CAGjKmVpfDLtRLby4MbDDEndhNs5eL2De_6Krqh2wX0gtbqS3Fw@mail.gmail.com>
 <CAH-ZgAdj8CC9qWHmpnADaw23VkrBJHSP_A_9VG5muiNmAZRJYg@mail.gmail.com>
 <CAGjKmVr6tZaA+p-Daau8fKCJB0gP835cj_iviJ5US_N9c4UGXQ@mail.gmail.com>
 <CAGjKmVpCoonM_X+W3ntaeJn4D=GET0A0GOX_1x9GHggWdr-i7w@mail.gmail.com>
 <CAGjKmVqKV3CeGCjipQEi+1nyjjJmuniY0y6ia2710q_xyO6djw@mail.gmail.com>
 <CAH-ZgAefJnorOjOYWz5QV=Mvar+1D0v=5EtvR0sUD+V7ad7Ueg@mail.gmail.com>
 <25b03231-c10d-84e1-2c9e-18a4863c9316@skippinet.com.au>
 <CAGjKmVqTL48+vwnJogdHq5ZhcqnqdJJVVZSVJtzabwuO8fnSMA@mail.gmail.com>
Message-ID: <9ba1e1ec-51a0-08dc-07d7-f11a7e961670@skippinet.com.au>

On 26/02/2018 1:12 am, Bob Kline wrote:
> On Sun, Feb 25, 2018 at 12:31 AM, Mark Hammond
> <mhammond at skippinet.com.au> wrote:
> 
>> I'm afraid Bob is going to get quite frustrated if he gets upset about
>> responses taking more than a few days to come in.
> 
> I'm going to assume you hadn't yet read the thread leading up to
> Vernon's last message. Here is some historical context which you may
> be missing.

Thanks for the response. I did read the thread, but I'm still a little 
confused by some of the context.

IIUC:

1) There's a relatively easy fix that can be made to the copy of 
adodbapi which is inside pywin32.

2) There's a concern regarding some IronPython bindings for adodbapi 
which aren't in pywin32 and Vernon was asking something whether they 
should also be included in pywin32.

Assuming I'm not misunderstanding the issue, then we should just apply 
the fix for (1). However, I'm not sure what (2) would mean for pywin32's 
build process nor for existing IronPython users.

Hopefully Vernon will clear things up when he gets back.

Cheers,

Mark

From mhammond at skippinet.com.au  Sun Feb 25 19:20:09 2018
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Mon, 26 Feb 2018 11:20:09 +1100
Subject: [python-win32] [ANN] pywin32 build 223 released
Message-ID: <bf2f7e6d-5a3c-5d9d-5350-6dccff297a73@skippinet.com.au>

Hi all,
   I'm happy to announce the release of pywin32 build 223.

The only significant change in this release is to help pywin32 when 
being installed as a wheel (ie, via pypi) - the pywin32_system32 
directory is now added to PATH. Thanks to @xoviat via 
https://github.com/mhammond/pywin32/pull/1153

This should help when installing pywin32 via pypi. While I still 
consider wheel support to be experimental, I encourage everyone to try 
it out and report any issues via https://github.com/mhammond/pywin32/issues.

Downloads are available at:

   https://github.com/mhammond/pywin32/releases/tag/b223

and via pypi.

For initial support (eg, to ask questions about the release etc), please 
contact this mailing-list (python-win32 at python.org).  If you want to 
report a bug, please do so at https://github.com/mhammond/pywin32/issues

As always, thanks to everyone who contributed to this release, both in 
terms of code and reporting bugs.

Cheers,

Mark.

Changes:
* pywin32.pth now arranges for the pywin32_system32 directory to be on
   PATH to help with pypi installations (thanks to @xovian via #1153)

From bkline at rksystems.com  Sun Feb 25 21:35:23 2018
From: bkline at rksystems.com (Bob Kline)
Date: Sun, 25 Feb 2018 21:35:23 -0500
Subject: [python-win32] Bug reporting
In-Reply-To: <9ba1e1ec-51a0-08dc-07d7-f11a7e961670@skippinet.com.au>
References: <CAP6Y=No2p+BJ2uq-He0K39RhtuZ2fDTrF5q=2ao0B+CJ=+C9JA@mail.gmail.com>
 <CAGjKmVrZm_sb-A2NKsVYseZUvwB5q8zHqKbfPO-Mmo6m2nEY4A@mail.gmail.com>
 <CAGjKmVr1UiHXui3s=HB8x+7N4PekcTQL=7vaq6gkFBwJp+yFCg@mail.gmail.com>
 <CAH-ZgAcrjtsKV0ppTsfa2mFP9mu_253e8_Y85kuKWuiVyVVywA@mail.gmail.com>
 <CAGjKmVpfDLtRLby4MbDDEndhNs5eL2De_6Krqh2wX0gtbqS3Fw@mail.gmail.com>
 <CAH-ZgAdj8CC9qWHmpnADaw23VkrBJHSP_A_9VG5muiNmAZRJYg@mail.gmail.com>
 <CAGjKmVr6tZaA+p-Daau8fKCJB0gP835cj_iviJ5US_N9c4UGXQ@mail.gmail.com>
 <CAGjKmVpCoonM_X+W3ntaeJn4D=GET0A0GOX_1x9GHggWdr-i7w@mail.gmail.com>
 <CAGjKmVqKV3CeGCjipQEi+1nyjjJmuniY0y6ia2710q_xyO6djw@mail.gmail.com>
 <CAH-ZgAefJnorOjOYWz5QV=Mvar+1D0v=5EtvR0sUD+V7ad7Ueg@mail.gmail.com>
 <25b03231-c10d-84e1-2c9e-18a4863c9316@skippinet.com.au>
 <CAGjKmVqTL48+vwnJogdHq5ZhcqnqdJJVVZSVJtzabwuO8fnSMA@mail.gmail.com>
 <9ba1e1ec-51a0-08dc-07d7-f11a7e961670@skippinet.com.au>
Message-ID: <CAGjKmVqbg+tkDH0cqor6bQyZq14w3KFKBW_knT10U_FfctPFCw@mail.gmail.com>

On Sun, Feb 25, 2018 at 6:18 PM, Mark Hammond <mhammond at skippinet.com.au> wrote:

> 1) There's a relatively easy fix that can be made to the copy of adodbapi
> which is inside pywin32.

Right. Basically, I think what needs to happen is for the fork on
GitHub to be brought in sync with the working code on SF. I'm going to
guess it's not quite as simple as that, because we'd want to be
careful to preserve any patches which got applied on GitHub, but
didn't make it to the original repo. Don't know for sure that there
are any, but we should check.

> 2) There's a concern regarding some IronPython bindings for adodbapi which
> aren't in pywin32 and Vernon was asking something whether they should also
> be included in pywin32.

As I understand it, the code to support IronPython is already included
in what's on GitHub. I think Vernon's hoping that there's a way to
script an export of just the adodbapi portion of your GitHub repo for
the use of the IronPython users (who, as you correctly point out, have
no use for the pywin32 bits). If that's possible (and I can't see why
it wouldn't be, as GitHub is pretty easy to script), he would be able
to avoid the tedium and risks involved in having to maintain the same
code base in two different places. It would also eliminate the "where
am I supposed to file bugs" confusion, as well as make it easier to
persuade others to assist with maintenance of the code. Most of the
adodbapi code is common for IronPython and CPython users, and I don't
see that the presence of "if IronPython: ..." code in the
mhammond/pywin32 repo does any harm (after all, it's already there and
I'll bet no one has noticed).

I hope that makes things a little clearer. But this explanation is
speculation on my part, and I should really let Vernon say what he
means for #2.

Regards,
Bob

From vernondcole at gmail.com  Mon Feb 26 13:40:02 2018
From: vernondcole at gmail.com (Vernon D. Cole)
Date: Mon, 26 Feb 2018 11:40:02 -0700
Subject: [python-win32] Bug reporting
In-Reply-To: <CAGjKmVqbg+tkDH0cqor6bQyZq14w3KFKBW_knT10U_FfctPFCw@mail.gmail.com>
References: <CAP6Y=No2p+BJ2uq-He0K39RhtuZ2fDTrF5q=2ao0B+CJ=+C9JA@mail.gmail.com>
 <CAGjKmVrZm_sb-A2NKsVYseZUvwB5q8zHqKbfPO-Mmo6m2nEY4A@mail.gmail.com>
 <CAGjKmVr1UiHXui3s=HB8x+7N4PekcTQL=7vaq6gkFBwJp+yFCg@mail.gmail.com>
 <CAH-ZgAcrjtsKV0ppTsfa2mFP9mu_253e8_Y85kuKWuiVyVVywA@mail.gmail.com>
 <CAGjKmVpfDLtRLby4MbDDEndhNs5eL2De_6Krqh2wX0gtbqS3Fw@mail.gmail.com>
 <CAH-ZgAdj8CC9qWHmpnADaw23VkrBJHSP_A_9VG5muiNmAZRJYg@mail.gmail.com>
 <CAGjKmVr6tZaA+p-Daau8fKCJB0gP835cj_iviJ5US_N9c4UGXQ@mail.gmail.com>
 <CAGjKmVpCoonM_X+W3ntaeJn4D=GET0A0GOX_1x9GHggWdr-i7w@mail.gmail.com>
 <CAGjKmVqKV3CeGCjipQEi+1nyjjJmuniY0y6ia2710q_xyO6djw@mail.gmail.com>
 <CAH-ZgAefJnorOjOYWz5QV=Mvar+1D0v=5EtvR0sUD+V7ad7Ueg@mail.gmail.com>
 <25b03231-c10d-84e1-2c9e-18a4863c9316@skippinet.com.au>
 <CAGjKmVqTL48+vwnJogdHq5ZhcqnqdJJVVZSVJtzabwuO8fnSMA@mail.gmail.com>
 <9ba1e1ec-51a0-08dc-07d7-f11a7e961670@skippinet.com.au>
 <CAGjKmVqbg+tkDH0cqor6bQyZq14w3KFKBW_knT10U_FfctPFCw@mail.gmail.com>
Message-ID: <CAH-ZgAdmtrtDFsn6jn1a129rmncegqxiPxptJoG1Zqk-hnjfSA@mail.gmail.com>

There are two problems with the existing SourceForge repo of adodbapi.

First, the manual copy of updates to the pywin32 code base can easily fail
-- as it did several years ago and I missed the resulting error which
remained unfixed for several releases of pywin32. That problem was
exacerbated by me moving to a new job where I never used Windows at all,
along with my test platform dying.

Second: the effective "bus size" of the adodbapi repo is *one*. The other
three authorized maintainers are inactive.  Indeed, the way I got approved
as a maintainer 15 years ago (has it really been that long?) was to
document to SourceForge that the then-existing two maintainers were
unresponsive. Moving the working source into the pywin32 repo would solve
that problem.

So, it looks to me like moving the development copy of adodbapi source to
the pywin32 GitHub repo would be a Good Idea. But could that be easily done?

My research this morning suggests that by suitable editing of the
MANIFEST.in file in the pywin32 root, and the  /adodbapi/MANIFEST.in and
./setup.py we could effectively send two seemingly independent (but source
locked) versions of adodbapi to PyPi.  That should keep both
CPython/pywin32 and IronPython use cases covered.  Should I pursue that?
--
Vernon


I spent the morning reviewing the documentation for setuptools and wheels
and such.



On Sun, Feb 25, 2018 at 7:35 PM, Bob Kline <bkline at rksystems.com> wrote:

> On Sun, Feb 25, 2018 at 6:18 PM, Mark Hammond <mhammond at skippinet.com.au>
> wrote:
>
> > 1) There's a relatively easy fix that can be made to the copy of adodbapi
> > which is inside pywin32.
>
> Right. Basically, I think what needs to happen is for the fork on
> GitHub to be brought in sync with the working code on SF. I'm going to
> guess it's not quite as simple as that, because we'd want to be
> careful to preserve any patches which got applied on GitHub, but
> didn't make it to the original repo. Don't know for sure that there
> are any, but we should check.
>
> > 2) There's a concern regarding some IronPython bindings for adodbapi
> which
> > aren't in pywin32 and Vernon was asking something whether they should
> also
> > be included in pywin32.
>
> As I understand it, the code to support IronPython is already included
> in what's on GitHub. I think Vernon's hoping that there's a way to
> script an export of just the adodbapi portion of your GitHub repo for
> the use of the IronPython users (who, as you correctly point out, have
> no use for the pywin32 bits). If that's possible (and I can't see why
> it wouldn't be, as GitHub is pretty easy to script), he would be able
> to avoid the tedium and risks involved in having to maintain the same
> code base in two different places. It would also eliminate the "where
> am I supposed to file bugs" confusion, as well as make it easier to
> persuade others to assist with maintenance of the code. Most of the
> adodbapi code is common for IronPython and CPython users, and I don't
> see that the presence of "if IronPython: ..." code in the
> mhammond/pywin32 repo does any harm (after all, it's already there and
> I'll bet no one has noticed).
>
> I hope that makes things a little clearer. But this explanation is
> speculation on my part, and I should really let Vernon say what he
> means for #2.
>
> Regards,
> Bob
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-win32/attachments/20180226/2f4f1c1b/attachment.html>

From mhammond at skippinet.com.au  Mon Feb 26 19:53:33 2018
From: mhammond at skippinet.com.au (Mark Hammond)
Date: Tue, 27 Feb 2018 11:53:33 +1100
Subject: [python-win32] Bug reporting
In-Reply-To: <CAH-ZgAdmtrtDFsn6jn1a129rmncegqxiPxptJoG1Zqk-hnjfSA@mail.gmail.com>
References: <CAP6Y=No2p+BJ2uq-He0K39RhtuZ2fDTrF5q=2ao0B+CJ=+C9JA@mail.gmail.com>
 <CAGjKmVr1UiHXui3s=HB8x+7N4PekcTQL=7vaq6gkFBwJp+yFCg@mail.gmail.com>
 <CAH-ZgAcrjtsKV0ppTsfa2mFP9mu_253e8_Y85kuKWuiVyVVywA@mail.gmail.com>
 <CAGjKmVpfDLtRLby4MbDDEndhNs5eL2De_6Krqh2wX0gtbqS3Fw@mail.gmail.com>
 <CAH-ZgAdj8CC9qWHmpnADaw23VkrBJHSP_A_9VG5muiNmAZRJYg@mail.gmail.com>
 <CAGjKmVr6tZaA+p-Daau8fKCJB0gP835cj_iviJ5US_N9c4UGXQ@mail.gmail.com>
 <CAGjKmVpCoonM_X+W3ntaeJn4D=GET0A0GOX_1x9GHggWdr-i7w@mail.gmail.com>
 <CAGjKmVqKV3CeGCjipQEi+1nyjjJmuniY0y6ia2710q_xyO6djw@mail.gmail.com>
 <CAH-ZgAefJnorOjOYWz5QV=Mvar+1D0v=5EtvR0sUD+V7ad7Ueg@mail.gmail.com>
 <25b03231-c10d-84e1-2c9e-18a4863c9316@skippinet.com.au>
 <CAGjKmVqTL48+vwnJogdHq5ZhcqnqdJJVVZSVJtzabwuO8fnSMA@mail.gmail.com>
 <9ba1e1ec-51a0-08dc-07d7-f11a7e961670@skippinet.com.au>
 <CAGjKmVqbg+tkDH0cqor6bQyZq14w3KFKBW_knT10U_FfctPFCw@mail.gmail.com>
 <CAH-ZgAdmtrtDFsn6jn1a129rmncegqxiPxptJoG1Zqk-hnjfSA@mail.gmail.com>
Message-ID: <32dd7921-05e9-31c8-0dde-8e5fe8df0f63@skippinet.com.au>

On 27/02/2018 5:40 am, Vernon D. Cole wrote:
> Second: the effective "bus size" of the adodbapi repo is *one*. The 
> other three authorized maintainers are inactive.? Indeed, the way I got 
> approved as a maintainer 15 years ago (has it really been that long?) 
> was to document to SourceForge that the then-existing two maintainers 
> were unresponsive. Moving the working source into the pywin32 repo would 
> solve that problem.

It's not immediately clear that it would though. pywin32 itself has the 
exact same issue (ie, it's largely just me), and I don't use or know 
much about adodbapi - so it seems somewhat likely you'd have the same 
"bus size" - just on a different bus :)

> My research this morning suggests that by suitable editing of the 
> MANIFEST.in file in the pywin32 root, and the? /adodbapi/MANIFEST.in and 
> ./setup.py we could effectively send two seemingly independent (but 
> source locked) versions of adodbapi to PyPi.? That should keep both 
> CPython/pywin32 and IronPython use cases covered.? Should I pursue that?

When building pywin32 I don't send *any* versions of adodbapi to pypi, 
so I'm really not sure what that means. I'm reluctant to agree that 
building pywin32 will create many discrete wheels - I already need to 
upload wheels for each python version supported and for 64 and 32 bits 
and making the build and release process more convoluted doesn't sound 
like a win for me.

So can you please explain in more detail what is being proposed here, 
and why it would be preferred to splitting adodbapi into its own repo on 
github, possibly including removal of it from pywin32 if the duplication 
causes problems?

Cheers,

Mark

> --
> Vernon
> 
> 
> I spent the morning reviewing the documentation for setuptools and 
> wheels and such.
> 
> 
> 
> On Sun, Feb 25, 2018 at 7:35 PM, Bob Kline <bkline at rksystems.com 
> <mailto:bkline at rksystems.com>> wrote:
> 
>     On Sun, Feb 25, 2018 at 6:18 PM, Mark Hammond
>     <mhammond at skippinet.com.au <mailto:mhammond at skippinet.com.au>> wrote:
> 
>     > 1) There's a relatively easy fix that can be made to the copy of adodbapi
>     > which is inside pywin32.
> 
>     Right. Basically, I think what needs to happen is for the fork on
>     GitHub to be brought in sync with the working code on SF. I'm going to
>     guess it's not quite as simple as that, because we'd want to be
>     careful to preserve any patches which got applied on GitHub, but
>     didn't make it to the original repo. Don't know for sure that there
>     are any, but we should check.
> 
>     > 2) There's a concern regarding some IronPython bindings for adodbapi which
>     > aren't in pywin32 and Vernon was asking something whether they should also
>     > be included in pywin32.
> 
>     As I understand it, the code to support IronPython is already included
>     in what's on GitHub. I think Vernon's hoping that there's a way to
>     script an export of just the adodbapi portion of your GitHub repo for
>     the use of the IronPython users (who, as you correctly point out, have
>     no use for the pywin32 bits). If that's possible (and I can't see why
>     it wouldn't be, as GitHub is pretty easy to script), he would be able
>     to avoid the tedium and risks involved in having to maintain the same
>     code base in two different places. It would also eliminate the "where
>     am I supposed to file bugs" confusion, as well as make it easier to
>     persuade others to assist with maintenance of the code. Most of the
>     adodbapi code is common for IronPython and CPython users, and I don't
>     see that the presence of "if IronPython: ..." code in the
>     mhammond/pywin32 repo does any harm (after all, it's already there and
>     I'll bet no one has noticed).
> 
>     I hope that makes things a little clearer. But this explanation is
>     speculation on my part, and I should really let Vernon say what he
>     means for #2.
> 
>     Regards,
>     Bob
> 
> 


From hartmut.niemann at siemens.com  Wed Feb 28 09:09:45 2018
From: hartmut.niemann at siemens.com (Niemann, Hartmut)
Date: Wed, 28 Feb 2018 14:09:45 +0000
Subject: [python-win32] Excel / Word: setting properties
Message-ID: <1AE3002F400CE4498072DFDF74A843CC1F71C080@DEFTHW99EH3MSX.ww902.siemens.net>

Hi!

I create an excel document using the COM interface.

Now I need to set two properties to be compatible with a new company rule:

"[the tool] uses MS Office standard ('Keyword') and custom ('Document Confidentiality') properties. so if your code is able
to preset values to these properties [everything should work]"

How do I set the [Excel workbook] standard property "Keywords" to "C_Restricted" and the user property "Document Confidentiality" to "Restricted"?

Mit freundlichen Gr??en
Dr. Hartmut Niemann

Siemens AG
Mobility Division
Rolling Stock
Standardization, Remote Control, Display
MO RS LM EN CCI SRD
Werner-von-Siemens-Str. 67
91052 Erlangen, Deutschland
Mobil: +49 173 5342327
mailto:hartmut.niemann at siemens.com
www.siemens.com/ingenuityforlife<https://siemens.com/ingenuityforlife>
[www.siemens.com/ingenuityforlife]
Siemens Aktiengesellschaft: Vorsitzender des Aufsichtsrats: Jim Hagemann Snabe; Vorstand: Joe Kaeser, Vorsitzender; Roland Busch, Lisa Davis, Klaus Helmrich, Janina Kugel, Cedrik Neike, Michael Sen, Ralf P. Thomas; Sitz der Gesellschaft: Berlin und M?nchen, Deutschland; Registergericht: Berlin Charlottenburg, HRB 12300, M?nchen, HRB 6684; WEEE-Reg.-Nr. DE 23691322
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-win32/attachments/20180228/3212905b/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 3536 bytes
Desc: image001.gif
URL: <http://mail.python.org/pipermail/python-win32/attachments/20180228/3212905b/attachment.gif>

From timr at probo.com  Wed Feb 28 12:20:03 2018
From: timr at probo.com (Tim Roberts)
Date: Wed, 28 Feb 2018 09:20:03 -0800
Subject: [python-win32] Excel / Word: setting properties
In-Reply-To: <1AE3002F400CE4498072DFDF74A843CC1F71C080@DEFTHW99EH3MSX.ww902.siemens.net>
References: <1AE3002F400CE4498072DFDF74A843CC1F71C080@DEFTHW99EH3MSX.ww902.siemens.net>
Message-ID: <99874e19-977c-dff1-2b4f-43b2972f42c6@probo.com>

Niemann, Hartmut wrote:
>
> ?
>
> I create an excel document using the COM interface.
>
> ?
>
> Now I need to set two properties to be compatible with a new company rule:
>
> ?
>
> ?[the tool] uses MS Office standard (?Keyword?) and custom (?Document
> Confidentiality?) properties. so if your code is able
>
> to preset values to these properties [everything should work]?
>
> ?
>
> How do I set the [Excel workbook] standard property ?Keywords? to
> ?C_Restricted? and the user property ?Document Confidentiality? to
> ?Restricted??
>

The Document object should have a BuiltinDocumentProperties collection
and a CustomDocumentProperties collection that you can query and
manipulate.? You'll have to discover whether the properties you need to
tweak are builtin or not.

-- 
Tim Roberts, timr at probo.com
Providenza & Boekelheide, Inc.