Please allow option to either disable "optional" blacklist or disable its output. #33
Labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: karolyi/py3-validate-email#33
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
I use your module in a command-line utility I've written for our company, every time it starts we get the spitted out info for the blacklist check. We would really appreciate a way to disable this output.
See below:
(note that the '::>' is all you are supposed to see. Its the 'promt' part of the utility but its being covered by the output of blacklist check. My users are confused because they think its still doing something and it is not.)
Hey,
this comes from the file locking module, not from our updater (a module that the updater is using).
Can you tell me what logging settings you use? Per default, no one is supposed to see these lines, as it's internal to the filelock module.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
I dont have any logging settings set. So the default
On Wed, Nov 4, 2020, 11:15 AM László Károlyi notifications@github.com
wrote:
This is all my code does with the module:
from validate_email import validate_email
def checkEmail(*emails):
invalidEmails = []
validEmails = []
for email in emails:
if '@yahoo.com' in email:
print(colored("NOTE: This tool will not be able to check Yahoo emails.
Yahoo's mail server unfortunately reports any @yahoo.com email as valid
until an actual email is sent to it.",'white','on_red'))
print(colored(email,'white','on_red'))
continue
emailIsValid = validate_email(email_address=email, check_regex=True,
check_mx=True, from_address='alphacli@alink.com', helo_host='
officemail.alink.com', smtp_timeout=5, dns_timeout=5, use_blacklist=True,
debug=False)
if emailIsValid:
validEmails.append(email)
else:
invalidEmails.append(email)
print(colored('Valid Emails:','yellow'))
print(colored(validEmails,'green'))
print('')
print(colored('Invalid Emails:','yellow'))
print(colored(invalidEmails,'red'))
On Wed, Nov 18, 2020 at 1:08 PM Brandon G brandongaliher7@gmail.com wrote:
Hey,
I've just released 0.2.11, where I've changed the logging to only emit
debug()
messages instead ofinfo()
and warnings whendebug=True
is passed.The ones the
Filelock
module emits, I have no control over. When looking into its source, I saw they useLOGGER.info()
to emit some debug logging.I don't know what logging setup your
colored()
function (or the module that contains it) does, but even if my module itself doesn't emit messages you don't want to see, you can try and change the default logging settings at startup so you skip the.info()
logs the locking module emits.This way, you could achieve the desired outcome of having absolutely no logs emitted on stdout.
I'm not familiar with the logging modules, I typically just print using
default print module. The colored module is a submodule of termcolor.
Allows for some pretty output.
I am not sure if something within those modules is goofing up the Filelock
module you mentioned.
You don't have to give me the direct answer if you don't have it handy,
what logging module should I look up so I can figure out how to change the
default logging settings at the beginning of my script?
On Thu, Nov 19, 2020, 12:51 PM László Károlyi notifications@github.com
wrote:
It's the one in python: https://docs.python.org/3/library/logging.html
If you search around on the internet, you'll find examples on stackoverflow about how to add filters to the logging to filter out the Filelock logging.
Ok! Thank you sir for your help, for identifying that the problem isn't
with your module, and pointing me in the right direction to resolve my
specific case. Much appreciated!!
On Thu, Nov 19, 2020, 4:44 PM László Károlyi notifications@github.com
wrote:
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.