Re: [python-win32] Bug reporting

2018-03-05 Thread Mark Hammond 

That sounds fine to me.

On 5/03/2018 6:53 am, Vernon D. Cole wrote:

Here is what I propose:

1) This time, rather than copy a selected (major) part of the adodbapi 
source files over to their pywin32 directory,

I would copy _all_ of the files.

2) Adjust adodbapi/MANIFEST.in and setup.py to create a proper PyPi 
submission from that directory.


That sounds good, but could you please tweak setup.py so that it sticks 
the files into "../dist", so everything I need to release ends up in the 
same dir.


You'll probably also need to tweak adodbapi on pypi so I can upload.

3) Adjust the pywin32 MANIFEST.in to include a subset of adodbapi files 
that actually works.


4) Put a simple go/no-go test of adodbapi (perhaps ACCESS database only) 
into the pywin32 test suite.


5) document in SourceForge that future updates will take place in the 
pywin32 repo.


I guess I'll look forward to a PR :)

Cheers,

Mark
___
python-win32 mailing list
python-win32@python.org
https://mail.python.org/mailman/listinfo/python-win32

Re: [python-win32] Bug reporting

2018-03-04 Thread Vernon D. Cole 
I decided to meditate for a few days rather than answer immediately and
poorly.

After I took over maintenance of adodbapi in about 2003, I was struggling
with how to properly document
that most users (CPython) had to install pywin32 as a prerequisite. At that
time the odbc sub-module had a couple of bugs,
and ADO seemed to be all the future. Also pywin32's odbc module follows the
api 1.0 version.
I asked, and received a green light, to bundle adodbapi with pywin32.

When you (Mark) gave that okay, you had one stipulation: that the module
get "some support".

During the last few years I have failed to provide that support. That fact
causes me daily regret.
I want the opportunity to correct my failure. I also want to enable someone
else to be able to support the package
should the need arise, like if I have a stroke or something. I have already
survived cancer.
I understand that pywin32 support is "largely" just you, but adodbapi
support is _only_ just me -- a critical difference.

Here is what I propose:

1) This time, rather than copy a selected (major) part of the adodbapi
source files over to their pywin32 directory,
I would copy _all_ of the files.

2) Adjust adodbapi/MANIFEST.in and setup.py to create a proper PyPi
submission from that directory.

3) Adjust the pywin32 MANIFEST.in to include a subset of adodbapi files
that actually works.

4) Put a simple go/no-go test of adodbapi (perhaps ACCESS database only)
into the pywin32 test suite.

5) document in SourceForge that future updates will take place in the
pywin32 repo.
--
Vernon


On Mon, Feb 26, 2018 at 5:53 PM, Mark Hammond 
wrote:

> 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  bkl...@rksystems.com>> wrote:
>>
>> On Sun, Feb 25, 2018 at 6:18 PM, Mark Hammond
>> > 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

Re: [python-win32] Bug reporting

2018-02-26 Thread Mark Hammond 

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 > wrote:


On Sun, Feb 25, 2018 at 6:18 PM, Mark Hammond
> 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




___
python-win32 mailing list
python-win32@python.org
https://mail.python.org/mailman/listinfo/python-win32

Re: [python-win32] Bug reporting

2018-02-26 Thread Vernon D. Cole 
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  wrote:

> On Sun, Feb 25, 2018 at 6:18 PM, Mark Hammond 
> 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
>
___
python-win32 mailing list
python-win32@python.org
https://mail.python.org/mailman/listinfo/python-win32

Re: [python-win32] Bug reporting

2018-02-25 Thread Bob Kline 
On Sun, Feb 25, 2018 at 6:18 PM, Mark Hammond  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
___
python-win32 mailing list
python-win32@python.org
https://mail.python.org/mailman/listinfo/python-win32

Re: [python-win32] Bug reporting

2018-02-25 Thread Mark Hammond 

On 26/02/2018 1:12 am, Bob Kline wrote:

On Sun, Feb 25, 2018 at 12:31 AM, Mark Hammond
 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
___
python-win32 mailing list
python-win32@python.org
https://mail.python.org/mailman/listinfo/python-win32

Re: [python-win32] Bug reporting

2018-02-25 Thread Bob Kline 
On Sun, Feb 25, 2018 at 12:04 PM, Preston Landers  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:bkl...@rksystems.com
___
python-win32 mailing list
python-win32@python.org
https://mail.python.org/mailman/listinfo/python-win32

Re: [python-win32] Bug reporting

2018-02-25 Thread Preston Landers 
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
___
python-win32 mailing list
python-win32@python.org
https://mail.python.org/mailman/listinfo/python-win32

Re: [python-win32] Bug reporting

2018-02-25 Thread Bob Kline 
On Sun, Feb 25, 2018 at 12:31 AM, Mark Hammond
 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
___
python-win32 mailing list
python-win32@python.org
https://mail.python.org/mailman/listinfo/python-win32

Re: [python-win32] Bug reporting

2018-02-24 Thread Mark Hammond 

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
___
python-win32 mailing list
python-win32@python.org
https://mail.python.org/mailman/listinfo/python-win32

Re: [python-win32] Bug reporting

2018-02-21 Thread Bob Kline 
On Wed, Feb 21, 2018 at 10:26 AM, Bob Kline  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
___
python-win32 mailing list
python-win32@python.org
https://mail.python.org/mailman/listinfo/python-win32

Re: [python-win32] Bug reporting

2018-02-21 Thread Vernon D. Cole 
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  wrote:

> >> On Mon, Feb 19, 2018 at 11:18 AM, Vernon D. Cole 
> 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
> >>
>
___
python-win32 mailing list
python-win32@python.org
https://mail.python.org/mailman/listinfo/python-win32

Re: [python-win32] Bug reporting

2018-02-21 Thread Bob Kline 
[ 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 
...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  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

Re: [python-win32] Bug reporting

2018-02-21 Thread Bob Kline 
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 
...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@*',
, '\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  wrote:
> On Mon, Feb 19, 2018 at 11:18 AM, Vernon D. Cole  
> 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"  wrote:
>>>
>>> On Mon, Feb 19, 2018 at 2:25 AM, Vernon D. Cole 
>>> 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

Re: [python-win32] Bug reporting

2018-02-19 Thread Bob Kline 
On Mon, Feb 19, 2018 at 11:18 AM, Vernon D. Cole  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"  wrote:
>>
>> On Mon, Feb 19, 2018 at 2:25 AM, Vernon D. Cole 
>> 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:bkl...@rksystems.com



-- 
Bob Kline
http://www.rksystems.com
mailto:bkl...@rksystems.com
___
python-win32 mailing list
python-win32@python.org
https://mail.python.org/mailman/listinfo/python-win32

Re: [python-win32] Bug reporting

2018-02-19 Thread Vernon D. Cole 
Sounds like a good plan.

On Feb 19, 2018 04:57, "Bob Kline"  wrote:

> On Mon, Feb 19, 2018 at 2:25 AM, Vernon D. Cole 
> 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:bkl...@rksystems.com
>
___
python-win32 mailing list
python-win32@python.org
https://mail.python.org/mailman/listinfo/python-win32

Re: [python-win32] Bug reporting

2018-02-17 Thread Bob Kline 
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  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  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,  wrote:
>>>
>>> Send python-win32 mailing list submissions to
>>> python-win32@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-requ...@python.org
>>>
>>> You can reach the person managing the list at
>>> python-win32-ow...@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" 
>>> To: python-win32 
>>> 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 
>>> To: python-win32 
>>> 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:bkl...@rksystems.com
>>>
>>>
>>> ___
>>> python-win32 mailing list
>>> python-win32@python.org
>>> https://mail.python.org/mailman/listinfo/python-win32
>>>
>>
>>
>> ___
>> python-win32 mailing list
>> python-win32@python.org
>> https://mail.python.org/mailman/listinfo/python-win32
>>
>
>
>
> --
> Bob Kline
> http://www.rksystems.com
> mailto:bkl...@rksystems.com



-- 
Bob Kline
http://www.rksystems.com
mailto:bkl...@rksystems.com
___
python-win32 mailing list
python-win32@python.org
https://mail.python.org/mailman/listinfo/python-win32

Re: [python-win32] Bug reporting

2018-02-17 Thread Bob Kline 
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  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,  wrote:
>>
>> Send python-win32 mailing list submissions to
>> python-win32@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-requ...@python.org
>>
>> You can reach the person managing the list at
>> python-win32-ow...@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" 
>> To: python-win32 
>> 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 
>> To: python-win32 
>> 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:bkl...@rksystems.com
>>
>>
>> ___
>> python-win32 mailing list
>> python-win32@python.org
>> https://mail.python.org/mailman/listinfo/python-win32
>>
>
>
> ___
> python-win32 mailing list
> python-win32@python.org
> https://mail.python.org/mailman/listinfo/python-win32
>



-- 
Bob Kline
http://www.rksystems.com
mailto:bkl...@rksystems.com
___
python-win32 mailing list
python-win32@python.org
https://mail.python.org/mailman/listinfo/python-win32

[python-win32] Bug reporting

2018-02-17 Thread Max Slimmer 
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,  wrote:

> Send python-win32 mailing list submissions to
> python-win32@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-requ...@python.org
>
> You can reach the person managing the list at
> python-win32-ow...@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" 
> To: python-win32 
> 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 
> To: python-win32 
> 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:bkl...@rksystems.com
>
>
> ___
> python-win32 mailing list
> python-win32@python.org
> https://mail.python.org/mailman/listinfo/python-win32
>
>
___
python-win32 mailing list
python-win32@python.org
https://mail.python.org/mailman/listinfo/python-win32