We Keep Coding

How to log a warning without creating a logger?

How does one log a warning without creating a logger python? I also want to make sure it DOES log properly.
Is:
import logging
logging.warning('warning')
enough?

If I understand you want logging without all the hassle with setting up a logger. If you don't mind installing third-party package, have a look at loguru.
It is ready to use out of the box without boilerplate:
from loguru import logger
logger.warning("That's it, beautiful and simple logging!")
Check the docs for more info.

Yes:
import logging
logging.warning('warning with real information from your code')
ouput:
WARNING:root:warning

Is there any way to stop logger in the AWS Iot Python SDK?

In the AWSIoTPythonSDK, in MqttCore.py, there is logger define '''class MqttCore(object):
_logger = logging.getLogger(name)'''
Everytime "subscribe timed out" is getting printed in the console, is there any way to forcefully stop the logger of the IoT SDK. I know it is not recommended but i badly needed to stop it forcefully.

I dont know if it recommended, but I did it:
sdk_logger = logging.getLogger('AWSIoTPythonSDK.core.protocol.mqtt_core')
sdk_logger.setLevel(logging.WARNING)
you can see here an example that they printed it to a different file:
https://docs.aws.amazon.com/code-samples/latest/catalog/python-iotthingsgraph-camera.py.html
this is a very simple explanation on how logging works in general when you import a module (If you need) https://www.youtube.com/watch?v=jxmzY9soFXg&ab_channel=CoreySchafer
credit: How do I define a different logger for an imported module in Python?

Logging within a package

I'm developing a package that will be used by others to write processing scripts. For testing/debugging/not-going-insane purposes, I'd like to include some logging statements within my code, and especially using a logging_setup() utility function that I developed for another project for formatting/file output control.
Because I'm not writing a self-contained application, however, but a library that is meant to be called by other programs, I am confused where I should use my logging_setup() utility in order to produce the desired logging results that I want. This made me wonder whether using a logging system within my package was a good idea to begin with.
Where should I use my logging_setup() utility, if anywhere?
EDIT: Here's the function I mention above:
def logging_setup(cfg_path=definitions.LOG_CONFIG_PATH, lvl=logging.INFO):
"""Setup logging tool from YAML configuration file.
This should only be run once. Formatted (or configured) logging can only be
done from within functions/classes in other modules.
"""
# create directory for log files if not already there
try:
os.makedirs(definitions.LOGS_PATH)
except OSError as e:
if e.errno != errno.EEXIST:
raise
# configure logging from yaml config file
if os.path.exists(cfg_path):
with open(cfg_path, 'rt') as f:
config = yaml.safe_load(f.read())
logging.config.dictConfig(config)
else:
logging.basicConfig(level=lvl)

Where should I use my logging_setup() utility, if anywhere?
In library code, you should not configure logging anywhere. It is up to the users of your library (application distributors) to configure logging handlers.
As a library author, you don't know anything about the runtime context, you don't even know if there is a writable filesystem available at all in order to create logfiles. But to use logging, you don't need to care about the configuration - just import logging and create loggers, at the module level, and you can log events from library code. It is not for the library code to decide where those log events go - or if they go anywhere at all.
If you're providing an app and you want logging output, then configure logging as the first thing your application does when starting up - usually in Python this means a call to logging.config.dictConfig or similar is made shortly after entering the main() function (please make sure the logging configuration does not happen at import time).

how to use the twistd log system for logging my data?

I am interested in the main features of the twistd logging system, and I'm using it to log some data i need, much more that logging the real state of the twisted application. BTW it is very noisy, i've readed this Twisted: disable logging of Twisted-framework classes but i am not sure to get the point. Also using the .noise will not fit my need.
I would like to know if it is possible and easy to separate clearly in two logging systems having on one hand the log necessary for the twisted matrix application and on the other only the log that will contain my important data?
(so that i can have the time features, the rotating and so on on my own data, as i i've already spent some efforts with the kindly help of many guys from here to adapt the process of twisted logging to my needs).
can someone give me some hints on how to achieve this?
or maybe your main advice will be that i should definitively open a file, print my time format and data line inside it. And implements my own rotating on this file rather that turning away/hijack the twisted logging system to my needs?
i have also think of using a log.msg(mydata, system = "myownflag") and then using a grep myownflag | my log > only-my-data but there can be better ideas...
(i'm new to twisted, and learning it the wrong way, from the end and deeping too fast on my needs, rather that on the library basis, so i miss lot of thing. Please apologize me for that.)
best regards.

Here is a log observer wrapper that filters out events from the wrong system:
from functools import wraps
def makeObserver(system, originalObserver):
#wraps(originalObserver)
def observe(event):
if event.get("system", None) == system:
originalObserver(event)
You can use this by wrapping any existing observer and adding it to the logging system:
from twisted.python.log import FileLogObserver, addObserver
fileObs = FileLogObserver(file("myownflag.log", "at"))
addObserver(makeObserver("myownflag", fileObs.emit)

Advantages of logging vs. print() + logging best practices

I'm currently working on 1.0.0 release of pyftpdlib module.
This new release will introduce some backward incompatible changes in
that certain APIs will no longer accept bytes but unicode.
While I'm at it, as part of this breackage, I was contemplating the
possibility to get rid of my logging functions, which currently use the
print statement, and use the logging module instead.
As of right now pyftpdlib delegates the logging to 3 functions:
def log(s):
"""Log messages intended for the end user."""
print s
def logline(s):
"""Log commands and responses passing through the command channel."""
print s
def logerror(s):
"""Log traceback outputs occurring in case of errors."""
print >> sys.stderr, s
The user willing to customize logs (e.g. write them to a file) is
supposed to just overwrite these 3 functions as in:
>>> from pyftpdlib import ftpserver
>>>
>>> def log2file(s):
... open('ftpd.log', 'a').write(s)
...
>>> ftpserver.log = ftpserver.logline = ftpserver.logerror = log2file
Now I'm wondering: what benefits would imply to get rid of this approach
and use logging module instead?
From a module vendor perspective, how exactly am I supposed to
expose logging functionalities in my module?
Am I supposed to do this:
import logging
logger = logging.getLogger("pyftpdlib")
...and state in my doc that "logger" is the object which is supposed
to be used in case the user wants to customize how logs behave?
Is it legitimate to deliberately set a pre-defined format output as in:
FORMAT = '[%(asctime)] %(message)s'
logging.basicConfig(format=FORMAT)
logger = logging.getLogger('pyftpdlib')
...?
Can you think of a third-party module I can take cues from where the logging functionality is exposed and consolidated as part of the public API?
Thanks in advance.

libraries (ftp server or client library) should never initialize the logging system.
So it's ok to instantiate a logger object and to point at logging.basicConfig in the
documentation (or provide a function along the lines of basicConfig with fancier output
and let the user choose among his logging configuration strategy, plain basicConfig or
library provided configuration)
frameworks (e.g. django) or servers (ftp server daemon)
should initialize the logging system to a reasonable
default and allow for customization of logging system configuration.

Typically libraries should just create a NullHandler handler, which is simply a do nothing handler. The end user or application developer who uses your library can then configure the logging system. See the section Configuring Logging for a Library in the logging documentation for more information. In particular, see the note which begins
It is strongly advised that you do not add any handlers other than NullHandler to your library's loggers.
In your case I would simply create a logging handler, as per the logging documentation,
import logging
logging.getLogger('pyftpdlib').addHandler(logging.NullHandler())
Edit The logging implementation sketched out in the question seems perfectly reasonable. In your documentation just mention logger and discuss or point users to the logging.setLevel and logging.setFormatter methods for customising the output from your library. Rather than using logging.basicConfig(format=FORMAT) you could consider using logging.config.fileConfig to manage the settings for your output and document the configuration file somewhere in your documentation, again pointing the user to the logging module documentation for the format expected in this file.

Here is a resource I used to make a customizable logger. I didn't change much, I just added an if statement, and pass in whether or not I want to log to a file or just the console.
Check this Colorer out. It's really nice for colorizing the output so DEBUG looks different than WARN which looks different than INFO.
The Logging module bundles a heck of a lot of nice functionality, like SMTP logging, file rotation logging (so you can save a couple old log files, but not make 100s of them every time something goes wrong).
If you ever want to migrate to Python 3, using the logging module will remove the need to change your print statements.
Logging is awesome depending on what you're doing, I've only lightly used it before to see where I am in a program (if you're running this function, color this way), but it has significantly more power than a regular print statement.

You can look at Django (just create a sample project) and see how it initialize logger subsystem.
There is also a contextual logger helper that I've written some time ago - this logger automatically takes name of module/class/function is was initialized from. This is very useful for debug messages where you can see right-through that module spits the messages and how the call flow goes.