Re: [python-win32] pywin32 Documentation

[Brian Johnson]

Hi Mark.Thank you for the feedback. My responses in-line below. Also...Example of reformatted narrative doc:Quick 
Start to Client side COM and Python — pywin32 305 documentation (brian3johnson.github.io)Example of api docs 
generated from .py docstring:adodbapi package — pywin32 305 documentation (brian3johnson.github.io)Note: the TOC 
sidebar still needs work. Thanks for your interest. I probably should have written more about this earlier. From 
my POV, the main considerations I have are:1) Much of the documentation is inside the c++ source formatted via 
"autoduck" style comments. I really don't want to abandon this documentation, but I don't think it's 
helpful in a sphinx-based world?BJ > I would not want to abandon this either. I don't know much about Autoduck 
apart from gathering that it generates documentation from the C++ source. There may be an approach using SWIG 
with some modifications within the C++ source code:https://www.swig.org/Doc4.1/Python.html#Python_nn65 2) There's 
no where near as much docs embedded in the .py code, which is something that we can address. However, some work 
has started on https://github.com/mhammond/pywin32/issues/1913, which hopes to add type annotations - see also 
yesterday's mail to this list on this topic. While I'm not quite sure exactly what approach is being suggested 
for that, it seems possible it will have at least *some* overlap here?BJ > Yes, I saw the email about this 
yesterday. Good news is that those type hints/annotations can be used by sphinx to generate the api docs. In 
fact, this is something I would have done as part of this documentation effort.3) Working out a good layout in 
the repo for docs is also important, but I don't forsee any real obstacles here - as you mention, a TOC etc are 
important. .rst seems like a perfectly reasonable format for hand-written docs, and given there aren't really 
that many hand-written docs in the tree which remain relevant, hand-converting them to largely unformatted 
markdown seems reasonable in the first instance. There's always going to be a bit of tension between keeping the 
docs organized and trying to keep the docs fairly close to the implementation they are documenting, but we can 
manage that.BJ> Agreed.4) I'd want to kill the existing tooling entirely as it's just going stale. Eg, the way 
https://mhammond.github.io/pywin32/ is built is interesting (it decompiles the .chm!) but that seems like a 
dead-end - I suspect that at some point it will end up extremely difficult to build that .chm in the first place 
- finding the Windows HTML Help compiler today is difficult enough.BJ> I agree with this as well. In fact, 
sphinx can generate HTMLHelp for compiling to CHM if you still want to have a CHM file available.So really, the 
big unknowns for me that need answering are:* How exactly do the autoduck comments get handled as they 
change?BJ> Maybe via SWIG. More research needed.* How does adding docs to the .py files overlap with adding 
type hints?BJ> Overlaps perfectly.* Does it replace the existing system rather than adding yet more complexity 
to it?BJ> ReplacesI'll look a little more at your repo over the next week or so, but I'm currently a bit short 
on time, but really am interested in improving the docs, so thanks!BJ> Sounds good! Thanks!___
python-win32 mailing list
python-win32@python.org
https://mail.python.org/mailman/listinfo/python-win32

Re: [python-win32] pywin32 Documentation

[Vernon D. Cole]

Brian:

I did not see your entry before writing mine.

Fantastic work on the adodbapi calling interfaces!

I think that there is still a need for something like the quick_reference,
so that there can be discussion about things like the extensions. The
ability to switch between paramstyles is probably still unique. There was
discussion in the dbapi community that it was impossible to do. Sometimes
that sort of thing is best presented in paragraph format.

I still have the original source for *Python Programming on Win32* (thank
you, Mark) but O'Reilly was not interested in publishing a second edition
several years ago. Perhaps it is time to ask them again.

On Tue, Dec 6, 2022 at 3:02 AM Brian Johnson  wrote:

> Hi Mark.
>
> Thank you for the feedback. My responses in-line below. Also...
>
> *Example of reformatted narrative doc*:
> Quick Start to Client side COM and Python — pywin32 305 documentation
> (brian3johnson.github.io)
> 
> *Example of api docs generated from .py docstring*:
> adodbapi package — pywin32 305 documentation (brian3johnson.github.io)
> 
> *Note: the TOC sidebar still needs work.*
>
> Thanks for your interest. I probably should have written more about
> this earlier. From my POV, the main considerations I have are:
>
> 1) Much of the documentation is inside the c++ source formatted via
> "autoduck" style comments. I really don't want to abandon this
> documentation, but I don't think it's helpful in a sphinx-based world?
>
>
> BJ > I would not want to abandon this either. I don't know much about
> Autoduck apart from gathering that it generates documentation from the C++
> source. There may be an approach using SWIG with some modifications within
> the C++ source code:
> https://www.swig.org/Doc4.1/Python.html#Python_nn65
>
> 2) There's no where near as much docs embedded in the .py code, which is
> something that we can address. However, some work has started on
> https://github.com/mhammond/pywin32/issues/1913, which hopes to add type
> annotations - see also yesterday's mail to this list on this topic.
> While I'm not quite sure exactly what approach is being suggested for
> that, it seems possible it will have at least *some* overlap here?
>
>
> BJ > Yes, I saw the email about this yesterday. Good news is that those
> type hints/annotations can be used by sphinx to generate the api docs. In
> fact, this is something I would have done as part of this documentation
> effort.
>
> 3) Working out a good layout in the repo for docs is also important, but
> I don't forsee any real obstacles here - as you mention, a TOC etc are
> important. .rst seems like a perfectly reasonable format for
> hand-written docs, and given there aren't really that many hand-written
> docs in the tree which remain relevant, hand-converting them to largely
> unformatted markdown seems reasonable in the first instance. There's
> always going to be a bit of tension between keeping the docs organized
> and trying to keep the docs fairly close to the implementation they are
> documenting, but we can manage that.
>
>
> BJ> Agreed.
>
> 4) I'd want to kill the existing tooling entirely as it's just going
> stale. Eg, the way https://mhammond.github.io/pywin32/ is built is
> interesting (it decompiles the .chm!) but that seems like a dead-end - I
> suspect that at some point it will end up extremely difficult to build
> that .chm in the first place - finding the Windows HTML Help compiler
> today is difficult enough.
>
>
> BJ> I agree with this as well. In fact, sphinx can generate HTMLHelp for
> compiling to CHM if you still want to have a CHM file available.
>
> So really, the big unknowns for me that need answering are:
>
> * How exactly do the autoduck comments get handled as they change?
>
>
> BJ> Maybe via SWIG. More research needed.
>
> * How does adding docs to the .py files overlap with adding type hints?
>
>
> BJ> Overlaps perfectly.
>
> * Does it replace the existing system rather than adding yet more
> complexity to it?
>
>
> BJ> Replaces
>
> I'll look a little more at your repo over the next week or so, but I'm
> currently a bit short on time, but really am interested in improving the
> docs, so thanks!
>
>
> BJ> Sounds good! Thanks!
>
> ___
> 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

Re: [python-win32] pywin32 Documentation

[Vernon D. Cole]

The most important document for adodbapi is in Markdown. (That's an
improvement - - I wrote it in .odt) so if that helps the decision, I would
say lean toward that direction.
It needs to be linked / indexed in where people can actually find it.
adodbapi/quick_reference.md
 If
we make an actual .docs directory, it should move there.

It also needs an edit pass to get rid of obsolete references to Python 2
and to check that the external links still work and so forth. I'll add that
to my to-do list.



On Mon, Dec 5, 2022 at 6:57 PM Brian Johnson  wrote:

> Hi.
>
> I took a stab at upgrading and "untangling" the documentation. I am
> willing to work on this documentation "untangling" project. Before I put
> more effort into it, I would like to get feedback from Mark and other
> contributors on what I'm proposing. If so, I'll log an Issue and/or pull
> request.
>
> *Motivation*: I need to work with a COM server application and want to
> use python. I found it challenging to find documentation and examples.
> Also, Mark mentioned this in the repo README: *"Lots of that is very old,
> but some is auto-generated and current. Would love help untangling the
> docs!"*
>
> *Where*: The current iteration is hosted on my forked repo at Python for
> Windows Extensions — pywin32 305 documentation (brian3johnson.github.io)
> . If this effort
> moves forward, I'll pull it down once it's built and posted from mhammond's
> repo.
>
> *How*: I am building the documentation with sphinx Welcome — Sphinx
> documentation (sphinx-doc.org)  to
> update the narrative docs and automate or semi-automate the pywin32 API
> reference. I am using the default theme. I'm using reStructuredText (.rst)
> for the docs.
>
> *What*: I included all the existing narrative documentation from the CHM.
> Most of it remains unformatted, except for a couple of docs. I added a Home
> page, Installation, Support, and Resources pages, and the start of a
> Getting Started Tutorial.
>
> *Proposed Next Steps*:
>
> 1. Confirm if I move forward with sphinx. If so, confirm if we use
> reStructuredText (reStructuredText — Sphinx documentation (sphinx-doc.org)
> )
> or Markdown (Markdown — Sphinx documentation (sphinx-doc.org)
> ) for narrative
> documents.
> 2. Finish formatting the existing narrative docs per rst or md.
> 3. Add docstrings to .py source files to generate API docs.
> 4. Convert some of the "samples" embedded in the source files to "How-tos".
>
> I have more ideas and suggestions, which I can share in an Issue, PR, or
> on this mailing list.
>
> I look forward to hearing what you think.
>
> Sincerely,
> Brian
> ___
> 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

[python-win32] imap mail parsing - forms of socket timeout/EOF errors

[jacob kruger]

Hi there


Know haven't posted on this list for a little while now, but, thought 
may as well ask if any of you guys have an idea about what seems to be a 
pretty common issue, but, with no specific, or consistent workarounds 
that am finding mention of via various google searches, etc.



Effectively, if trying to use either the imaplib, or the poplib modules 
to query a remote mail server inbox, to then parse the mail messages 
contents, to insert them into a postgresql database, for more efficient 
querying/referencing, I am, at times - not consistently at all - 
receiving one of the two following messages, depending on which 
protocol/client I was trying to make use of:-



the error message/exception information am getting from imap is the 
following:

imaplib.IMAP4.abort: command: FETCH => socket error: EOF

the pop3 error message is the following:
poplib.error_proto: -ERR EOF


For example, if just run same code against my one test server, with just 
100 messages in the inbox, it works fine every time on both protocols, 
but, when try run it against the live mailbox, which has over 2 million 
mails in it, this happens on a regular, if inconsistent basis when you 
try retrieving specific messages each time, based on their server-side 
UID/ID.



So, just wondering if anyone has come across things like this before, 
has ideas about implementing a form of timeout, or connection renewal, 
or if you have ideas about additional resources could try making use of 
instead for this type of thing - main thing is want to be able to, 
initially at least, just parse all the mail contents, updating the 
database on a repeated basis, since this inbox receives a lot of e-mails 
every hour/day, and, possibly, later on, be able to retrieve or interact 
with mail messages as well?



Thanks in advance


--

Jacob Kruger
+2782 413 4791
Skype: BlindZA
"...resistance is futile...but, acceptance is versatile..."___
python-win32 mailing list
python-win32@python.org
https://mail.python.org/mailman/listinfo/python-win32

Re: [python-win32] pywin32 Documentation

[Brian Johnson]

Vernon.The fantastic work is all yours. I simply started converting your quick_reference.md to reStructuredText.-BrianOn Dec 
6, 2022, at 7:52 AM, Vernon D. Cole  wrote:Brian:I did not see your entry before writing mine.  
Fantastic work on the adodbapi calling interfaces! I think that there is still a need for something like the quick_reference, 
so that there can be discussion about things like the extensions. The ability to switch between paramstyles is probably still 
unique. There was discussion in the dbapi community that it was impossible to do. Sometimes that sort of thing is best 
presented in paragraph format.I still have the original source for Python Programming on Win32 (thank you, Mark) but O'Reilly 
was not interested in publishing a second edition several years ago. Perhaps it is time to ask them again.On Tue, Dec 6, 2022 
at 3:02 AM Brian Johnson  wrote:Hi Mark.Thank you for the feedback. My responses in-line below. 
Also...Example of reformatted narrative doc:Quick Start to Client side COM and Python — pywin32 305 documentation 
(brian3johnson.github.io)Example of api docs generated from .py docstring:adodbapi package — pywin32 305 documentation 
(brian3johnson.github.io)Note: the TOC sidebar still needs work.Thanks for your interest. I probably should have written more 
about this earlier. From my POV, the main considerations I have are:1) Much of the documentation is inside the c++ source 
formatted via "autoduck" style comments. I really don't want to abandon this documentation, but I don't think it's 
helpful in a sphinx-based world?BJ > I would not want to abandon this either. I don't know much about Autoduck apart from 
gathering that it generates documentation from the C++ source. There may be an approach using SWIG with some modifications 
within the C++ source code:https://www.swig.org/Doc4.1/Python.html#Python_nn65 2) There's no where near as much docs embedded 
in the .py code, which is something that we can address. However, some work has started on 
https://github.com/mhammond/pywin32/issues/1913, which hopes to add type annotations - see also yesterday's mail to this list 
on this topic. While I'm not quite sure exactly what approach is being suggested for that, it seems possible it will have at 
least *some* overlap here?BJ > Yes, I saw the email about this yesterday. Good news is that those type hints/annotations 
can be used by sphinx to generate the api docs. In fact, this is something I would have done as part of this documentation 
effort.3) Working out a good layout in the repo for docs is also important, but I don't forsee any real obstacles here - as 
you mention, a TOC etc are important. .rst seems like a perfectly reasonable format for hand-written docs, and given there 
aren't really that many hand-written docs in the tree which remain relevant, hand-converting them to largely unformatted 
markdown seems reasonable in the first instance. There's always going to be a bit of tension between keeping the docs 
organized and trying to keep the docs fairly close to the implementation they are documenting, but we can manage that.BJ> 
Agreed.4) I'd want to kill the existing tooling entirely as it's just going stale. Eg, the way 
https://mhammond.github.io/pywin32/ is built is interesting (it decompiles the .chm!) but that seems like a dead-end - I 
suspect that at some point it will end up extremely difficult to build that .chm in the first place - finding the Windows 
HTML Help compiler today is difficult enough.BJ> I agree with this as well. In fact, sphinx can generate HTMLHelp for 
compiling to CHM if you still want to have a CHM file available.So really, the big unknowns for me that need answering are:* 
How exactly do the autoduck comments get handled as they change?BJ> Maybe via SWIG. More research needed.* How does adding 
docs to the .py files overlap with adding type hints?BJ> Overlaps perfectly.* Does it replace the existing system rather 
than adding yet more complexity to it?BJ> ReplacesI'll look a little more at your repo over the next week or so, but I'm 
currently a bit short on time, but really am interested in improving the docs, so thanks!BJ> Sounds good! 
Thanks!___ 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

Re: [python-win32] pywin32 Documentation

[Brian Johnson]

Hi Vernon. I made an initial pass with moving it.Python ADODBAPI quick reference — pywin32 305 documentationbrian3johnson.github.ioI have mot worked through cleaning up the format nor scrubbing it for old code or dead links. Thanks!BrianOn Dec 6, 2022, at 7:33 AM, Vernon D. Cole  wrote:The most important document for adodbapi is in Markdown. (That's an improvement - - I wrote it in .odt) so if that helps the decision, I would say lean toward that direction.It needs to be linked / indexed in where people can actually find it. adodbapi/quick_reference.md If we make an actual .docs directory, it should move there.It also needs an edit pass to get rid of obsolete references to Python 2 and to check that the external links still work and so forth. I'll add that to my to-do list.On Mon, Dec 5, 2022 at 6:57 PM Brian Johnson  wrote:Hi.I took a stab at upgrading and "untangling" the documentation. I am willing to work on this documentation "untangling" project. Before I put more effort into it, I would like to get feedback from Mark and other contributors on what I'm proposing. If so, I'll log an Issue and/or pull request.Motivation: I need to work with a COM server application and want to use python. I found it challenging to find documentation and examples. Also, Mark mentioned this in the repo README: "Lots of that is very old, but some is auto-generated and current. Would love help untangling the docs!"Where: The current iteration is hosted on my forked repo at Python for Windows Extensions — pywin32 305 documentation (brian3johnson.github.io). If this effort moves forward, I'll pull it down once it's built and posted from mhammond's repo.How: I am building the documentation with sphinx Welcome — Sphinx documentation (sphinx-doc.org) to update the narrative docs and automate or semi-automate the pywin32 API reference. I am using the default theme. I'm using reStructuredText (.rst) for the docs.What: I included all the existing narrative documentation from the CHM. Most of it remains unformatted, except for a couple of docs. I added a Home page, Installation, Support, and Resources pages, and the start of a Getting Started Tutorial.Proposed Next Steps:1. Confirm if I move forward with sphinx. If so, confirm if we use reStructuredText (reStructuredText — Sphinx documentation (sphinx-doc.org)) or Markdown (Markdown — Sphinx documentation (sphinx-doc.org)) for narrative documents.2. Finish formatting the existing narrative docs per rst or md.3. Add docstrings to .py source files to generate API docs.4. Convert some of the "samples" embedded in the source files to "How-tos".I have more ideas and suggestions, which I can share in an Issue, PR, or on this mailing list.I look forward to hearing what you think.Sincerely,Brian___
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

[python-win32] Trouble finding MSOLAP provider with adodbapi

[savoy]

I'm trying to use python to connect to a Microsoft Analysis Services
cube for MDX queries due to the phasing out of a SQL server that used to
fill its place as the access point.

I've downloaded the most up-to-date MSOLAP library from Microsoft's site
(16.0.56.19) and installed it. The location of the library is then saved
as C:\\Program Files (x86)\Microsoft Analysis Services\AS
OLEDB\140\msolap.dll.

Using the connection string I've told is the correct to use (and also
verifying it by using it in Microsoft Excel) with adodbapi.connect(),
I get an OperationalError exception in python. Below is the text which
also includes the obfuscated connection string.

(com_error(-2147352567, 'Exception occurred.', (0, 'ADODB.Connection',
'Provider cannot be found. It may not be properly installed.',
'C:\\WINDOWS\\HELP\\AD027.CHM', 1240655, -2146824582), None), 'Error
opening connection to "Provider=MSOLAP.8;Integrated
Security=SSPI;Persist Security Info=True;Initial
Catalog=bi_mdp_SEMANTIC_live_db;Data Source=subdomain.domain.com;MDX
Compatibility=1;Safety Options=2;MDX Missing Member Mode=Error;Update
Isolation Level=2"').

Is there something that I'm missing in order for the connection to work?
I take it that as I can get it working in Excel there isn't anything
wrong with the installation, am I correct in that assumption? And if so,
is there a piece I've left out?

Thank you,
savoy
___
python-win32 mailing list
python-win32@python.org
https://mail.python.org/mailman/listinfo/python-win32

Re: [python-win32] Trouble finding MSOLAP provider with adodbapi

[Tim Roberts]

savoy wrote:


I've downloaded the most up-to-date MSOLAP library from Microsoft's site
(16.0.56.19) and installed it. The location of the library is then saved
as C:\\Program Files (x86)\Microsoft Analysis Services\AS
OLEDB\140\msolap.dll.


That's a 32-bit DLL.  Your ODBC driver needs to match your Python 
bittedness, and most of us run 64-bit Python.  Is there a 64-bit version 
of the connector?


--
Tim Roberts, t...@probo.com
Providenza & Boekelheide, Inc.



smime.p7s
Description: S/MIME Cryptographic Signature
___
python-win32 mailing list
python-win32@python.org
https://mail.python.org/mailman/listinfo/python-win32