provide public access to _content etc #3329
Comments
|
Would any of these Pelican signals help you deal with access to each document's content, specifically content signals? Something like:
About 80% of the plugins use this signal. A content handler would look like this: from pelican import signals
from pelican.contents import Content, Article, Page
def my_content_object_init(content_class):
# Description:
# First signal handler to provide the actual content of any article/page/static
# file.
#
# arg1 : content_class:Content
#
# article of Article(Content) class provides the following variable member items:
# allowed_statuses:tuple, author:Author, authors:list, category:Category,
# content:str, date:SafeDatetime, date_format:str, default_status:str,
# default_template:str, filename:str, get_content:partial, get_summary:partial,
# in_default_lang:bool, lang:str, locale_date:str, mandatory_properties:tuple,
# metadata:dict, private:str, reader:str, relative_dir:str,
# relative_source_path:str, save_as:str, settings:dict, slug:str,
# source_path:str, status:str, summary:str, tags:list, template:str,
# timezone:Zoneinfo, title:str, translations:list, url:str, url_format:dict
#
# Callstack
# signals.content_object_init.send()
# Content.__init__()
# Article.__init__()
# Readers.read_file()
# ArticlesGenerator.generate_context()
# Pelican.run()
#
# 4th article-related signal
# 3rd signal in ArticlesGenerator.generate_context()
# Still inside read_file()
# First signal appearance having a content provided by Markdown.read_file()
#
# Hooked using signals.content_object_init.connect(my_content_object_init)
#
print('my_content_object_init called')
print('my_content_object_init: content: {0!s}'.format(content_class.content))
if not (isinstance(content_class, Article) or isinstance(content_class, Page)):
return
# Do your article/page processing here
returnyou can set above handler up by doing # This is how pelican plugin works.
# register() is a well-established function name used by Pelican plugin
# handler for this plugin to get recognized, inserted, initialized, and
# its processors added into and by the Pelican app.
import logging
def register():
logger.info(
'MY plugin registered for Pelican, using new 4.0 plugin variant')
signals.content_object_init.connect(my_content_object_init) |
|
I don't see how that helps. This request is about getting public access to the protected field _content which is part of the Content object, not about getting access to the Content object. |
|
As I have had reviewed all the signals (as of v4.9.1), I am not fully convinced ... yet... that While Python (or JetBrain IDE PyCharm) may be able to access this protected Is there a particular signal stage that you need # All signals are listed here as of Pelican v4.9.1
signals.initialized.connect()
signals.get_generators.connect()
signals.readers_init() # Article class
signals.generator_init() #ArticlesGenerator class
signals.article_generator_init.connect()
signals.readers_init()
signals.readers_init() # Page class
signals.generator_init() # PagesGenerator
signals.page_generator_init()
signals.readers_init()
signals.generator_init()
signals.readers_init() # Static class
signals.generator_init() # StaticGenerator
signals.static_generator_init()
signals.article_generator_preread.connect()
signals.article_generator_context.connect()
signals.content_object_init.connect()
signals.article_generator_pretaxonomy.connect()
signals.article_generator_finalized.connect()
signals.page_generator_preread.connect()
signals.page_generator_context.connect()
signals.content_object_init.connect()
signals.page_generator_finalized.connect()
signals.static_generator_preread.connect()
signals.static_generator_context.connect()
signals.content_object_init.connect()
signals.static_generator_finalized.connect()
signals.all_generators_finalized.connect()
signals.get_writers()
signals.feed_generated()
signals.feed_written()
signals.article_generator_write_article.connect()
signals.content_written()
signals.article_writer_finalized.connect()
signals.page_generator_write_page.connect()
signals.content_written()
signals.page_writer_finalized()
signals.content_written()
signals.pelican_finalized() |
|
Here are some plugins that reference _content: |
Got it. I think I may have a fix, but no time to test it. Right off the bat, I can tell you that this particular plugin should be easily fixable by replacing the def register():
signals.initialized.connect(get_excludes)
signals.content_object_init.connect(parse_content)
signals.page_generator_context.connect(set_definitions)Upgrading the protected def parse_content(content):
# vvvvv NEW CODE vvvvv
# Only process Article or Page subclass contents
if not (isinstance(content_class, Article) or isinstance(content_class, Page)):
return
# ^^^^^ NEW CODE ^^^^^
# resume normal code
soup = bs4.BeautifulSoup(content._content, 'html.parser')
...Notice a choice of article or page, modify that as needed. Oh yea, totally remove the |
|
Your suggested change does solve the issue. It does not change the line where |
|
Oops, my bad. Please, if you haven't, replace ALL instances of _content is a protected variable, in short, it is a read-only variable that is discourage from making any access to it by a function. |
|
We are going round in circles. ._content and .content don't always return the same value, otherwise plugins would not need to use _content. |
Feature Request
Plugins regularly need to access _content.
However pylint (rightly) complains that this is using protected-access.
AFAICT it is expected that plugins may need to access _content (and _summary, _content) so the protected status is just a nuisance when using pylint.
Renaming would cause lots of issues, but it would be possible to provide a public accessor for use by plugins.
The text was updated successfully, but these errors were encountered: