Re: Tool that can document private inner class?

[Ian Pilcher]

On 2/8/23 08:25, Weatherby,Gerard wrote:

No.

I interpreted your query as “is there something that can read docstrings 
of dunder methods?”


Have you tried the Sphinx specific support forums? 
https://www.sphinx-doc.org/en/master/support.html 


Yes.  I've posted to both the -user and -dev groups, and I've also filed
an issue[1].  I haven't received a response.

Thus my conclusion that Sphinx, specifically autodoc, simply can't do
this.

[1] https://github.com/sphinx-doc/sphinx/issues/11181

--

Google  Where SkyNet meets Idiocracy


--
https://mail.python.org/mailman/listinfo/python-list

Re: Question about logging.config.dictConfig

[Ivan "Rambius" Ivanov]

On Tue, Feb 7, 2023 at 7:35 PM Peter J. Holzer  wrote:
>
> On 2023-02-07 17:58:26 -0500, Ivan "Rambius" Ivanov wrote:
> > I am trying to configure my loggers using dictConfig, but they do not
> > print anything. Here are more details.
> [...]
> > from myloggingconf import configure_logging
> >
> > logger = logging.getLogger(os.path.basename(__file__))
> [...]
> >
> > def main():
> > configure_logging()
> > dosmth()
> [...]
> > def configure_logging():
> > config = {
> > 'version': 1,
> > 'disable_existing_loggers': True,
>
>   'disable_existing_loggers': False,

Thank you! That helped a lot!

Regards
rambius

>
> I think I just found out why I've been cargo-culting this line since my
> early Django days ;-)-
>
> If you call getLogger very early (as you do), you don't want it disabled
> by a later call to dictConfig().
>
>
> > 'formatters': {
> > 'default': {
> > 'fmt': '%(asctime)s %(levelname)-7s %(name)s %(funcName)s 
> > %(message)s'
>   'format'
> > }
> > },
> [...]
> > }
> > logging.config.dictConfig(config)
> >
> > When I run uselog.py it prints nothing. I am wondering what is wrong
> > with the second configuration.
>
> See above.
>
> hp
>
> --
>_  | Peter J. Holzer| Story must make more sense than reality.
> |_|_) ||
> | |   | h...@hjp.at |-- Charles Stross, "Creative writing
> __/   | http://www.hjp.at/ |   challenge!"
> --
> https://mail.python.org/mailman/listinfo/python-list



-- 
Tangra Mega Rock: http://www.radiotangra.com
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: tree representation of Python data

[Thomas Passin]

On 2/8/2023 6:39 AM, Shaozhong SHI wrote:
What is the robust way to use Python to read in an XML and turn it into 
a JSON file?


JSON dictionary is actually a tree.  It is much easier to manage the 
tree-structured data.


XML and JSON are both for interchanging data.  What are you trying to 
accomplish? XML elements form a tree, XML attributes can be thought of 
as a dictionary.   JSON can contain both lists and associative arrays 
(dictionaries).  Personally, I would not say it's easier to "manage" 
tree-structured data than dictionaries, but either way it sounds like 
you want to send or receive data, rather than "managing" data in program 
data structures.


So why do you want to convert data in XML form to JSON?  Once you have 
XML ingested into some Python data structure, you can use the json 
library to output JSON- see


https://docs.python.org/3/library/json.html

There is a pip-installable program (which I have never used), xmltodict, 
that stores an XML file as a Python dictionary.  You then can write it 
to JSON as above.  I don't know how general this program is - XML is not 
isomorphic to JSON, but maybe your XML sources never use anything 
besides elements and attributes, and don't use namespaces.  Then it's 
pretty easy.


--
https://mail.python.org/mailman/listinfo/python-list

RE: evaluation question

[Robbie mezazem]

Ok I understand


Sent from Mail for Windows

From: Rob Cliffe via Python-list
Sent: Tuesday, February 7, 2023 6:54 PM
To: Chris Angelico; 
python-list@python.org
Subject: Re: evaluation question



On 07/02/2023 08:15, Chris Angelico wrote:
> On Tue, 7 Feb 2023 at 18:49, Rob Cliffe via Python-list
>  wrote:
>>
>>
>> On 02/02/2023 09:31, mutt...@dastardlyhq.com wrote:
>>> On Wed, 1 Feb 2023 18:28:04 +0100
>>> "Peter J. Holzer"  wrote:
 --b2nljkb3mdefsdhx
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable

 On 2023-02-01 09:00:39 -, mutt...@dastardlyhq.com wrote:
> Its not evolution, its revolution. Evolution retains old functionality.
 Tell a penguin that it can fly :-)
>>> Yeah ok :) But the ancestors of penguins didn't wake up one morning, flap
>>> their wings and fall out the tree, it happened gradually. Python2 syntax
>>> could have been retained for X versions of 3 just as C++ keeps old stuff
>>> until its eventually deprecated them removed.
>> Yeah?  So what would this do:
>>   print ()
>> In Python 2 this prints an empty tuple.
>> In Python 3 this is a call to the print function with no arguments,
>> which prints a blank line.
>> You can't have it both ways.
>> In any case, supporting two different syntaxes simultaneously would be
>> messy and difficult to maintain.
> There are two solutions to this. The most obvious is "from __future__
> import print_function", which gives you the full power and flexibility
> of Py3 in anything back as far as 2.6; the other is to always pass a
> single string argument to print:
>
> print("")
> print("spam %d ham %d" % (spam, ham))
>
> This will work in pretty much ANY version of Python [1] and doesn't
> require any sort of per-module configuration.
>
> The idea that old syntax should be retained is only part of the story.
> While it's definitely important to not break old code unnecessarily,
> it is far more important to ensure that there's *some way* to write
> code that works across multiple versions. That's what we have here:
> even with the breaking changes, there was usually a way to make your
> code run identically on multiple versions. Sometimes this means a
> compatibility shim at the top, like "try: raw_input; except NameError:
> raw_input = input", and sometimes it means following a discipline like
> putting b"..." for all strings that need to be bytes. But there always
> needs to be a way.
>
> ChrisA
>
> [1] This is the part where someone points out to me that it wouldn't
> work in Python 1.3 or something
You are quite right Chris, and indeed I have used both solutions in my
own code to keep 2-3 compatibility.
I was just pointing out that continuing to support Python 2 syntax in
Python 3 was not an option.
Best wishes
Rob Cliffe
--
https://mail.python.org/mailman/listinfo/python-list

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Tool that can document private inner class?

[Weatherby,Gerard]

No.

I interpreted your query as “is there something that can read docstrings of 
dunder methods?”

Have you tried the Sphinx specific support forums? 
https://www.sphinx-doc.org/en/master/support.html

From: Ian Pilcher 
Date: Tuesday, February 7, 2023 at 4:01 PM
To: Weatherby,Gerard , python-list@python.org 

Subject: Re: Tool that can document private inner class?
*** Attention: This is an external email. Use caution responding, opening 
attachments or clicking on links. ***

On 2/7/23 14:53, Weatherby,Gerard wrote:
> Yes.
>
> Inspect module
>
> import inspect
>
>
> class Mine:
>
> def __init__(self):
> self.__value = 7
>
> def __getvalue(self):
> /"""Gets seven"""
> /return self.__value
>
>
> mine = Mine()
> data = inspect.getdoc(mine)
> for m in inspect.getmembers(mine):
> if '__getvalue' in m[0]:
>  d = inspect.getdoc(m[1])
> print(d)
>

Can inspect generate HTML documentation, à la Sphinx and other tools?

--

Google  Where SkyNet meets Idiocracy

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: tree representation of Python data

[Shaozhong SHI]

What is the robust way to use Python to read in an XML and turn it into a
JSON file?

JSON dictionary is actually a tree.  It is much easier to manage the
tree-structured data.

Regards,

David
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: pylint scoping question

[Karsten Hilbert]

Am Wed, Feb 08, 2023 at 12:20:48PM +0100 schrieb Karsten Hilbert:

> I have a pylint scoping (or how-to) question.
...
> Objective:
>
> to disable all pylint errors/warnings starting from a
> particular source line until EOF (that part contains
> to-be-run-manually scratch/test code for that file)

This


https://stackoverflow.com/questions/66914050/what-is-the-scope-of-pylint-comments

BTW, is the seemingly closest related information I could
find but it does not explain the difference in scoping
between disable=something and disable=all.

Karsten
--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
-- 
https://mail.python.org/mailman/listinfo/python-list

pylint scoping question

[Karsten Hilbert]

Dear readers,

I have a pylint scoping (or how-to) question.

pylint 2.7.2
astroid 2.5.1
Python 3.9.2 (default, Feb 28 2021, 17:03:44)

Objective:

to disable all pylint errors/warnings starting from a
particular source line until EOF (that part contains
to-be-run-manually scratch/test code for that file)

As an MWE consider this code:

#---
usr/bin/python3
"""MWE"""

print(does_not_exist_1)
# Xpylint: disable=undefined-variable
# Xpylint: disable=all
print(does_not_exist_2)
print(does_not_exist_3)
#---

Pylint docs say that disables are per-scope. Thusly a

# pylint: disable=undefined-variable

inside the file-global scope should (?) disable
undefined-variable for the entire (?) file-global scope.

It does not, however, but rather seems to disable it inside
the file-global scope *from the line of occurrence onwards*.
To see this, remove the X from the relevant disable in the
MWE. This is the behaviour I desire to achieve.

However, when using the "disable=all" it *does* disable all
output, including the

x.py:4:6: E0602: Undefined variable 'does_not_exist_1' 
(undefined-variable)

despite the

# pylint: disable=all

sitting *after* the

print(does_not_exist_1)

So:

Am I doing something wrong ?

Am I misinterpreting the docs ?

Do the docs explain this difference in disable-scoping ?

How should I properly go about my objective (apart from
fixing my code, of course :-D ) ?

Thanks for insights,
Karsten
--
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
-- 
https://mail.python.org/mailman/listinfo/python-list