Hello!

I've just noted that validators dropped Python 2.7 support at version 0.14.3. It seems it kept working in my case until 0.16.0. My luck I guess :)

Unfortunatly, the package doesn't fully properly declare the drop of Python 2.7, causing Python 2.7 system to keep trying to install it. The solution: Add python_requires='>=3.4' in the setup.py (https://packaging.python.org/guides/distributing-packages-using-setuptools/#python-requires)

Another unfortunate aspect is that it's not possible to go back in time to add this metadata to 0.14.3, 0.15.0 and 0.16.0. The solution to this would be the new option to yank releases from pypi. In short, it prevents a package version from being automatically picked up by a pip install validators, but will keep that package version available for anyone specifically requesting with pip install validators==0.14.3 for instance. The best of both worlds :). The option should be available from the maintainer's UI. Ref: https://pypi.org/help/#yanked https://twitter.com/di_codes/status/1253166894158417926

Doing both of these would be sincerly greatly appreciated. I can send a MR for the python_requires='>=3.4' part, but the yank on pypi is necessary for keeping the ecosystem sane for system still depending on Python 2.7. Thanks!

I was fed up of bad hashs validations on some scripts around. Here are validators for md5, sha1, sha224, sha256 and sha512. Including tests and doc.

Each test include:

• valid : lowercase and uppercase hashs (of empty files)
• invalid : non-hex char, shorter, and longer size

Important Could this be fixed and released in a patch version so that our users don't have an issue ? We have a FOSS Asia stall where we expect a lot of new users.

If you like, I can submit a patch ?

Hi ! I'm a maintainer of coala - https://github.com/coala-analyzer/coala and we recently started using your package in coala, because it's awesome.

We just did a release yesterday and when doing some basic testing, we found a bug in your package.

You use setuptools in setup.py but don't depend on it in install_requires. Hence, if I don't have setuptools already installed, I'm unable to install your package.

$ python -c "import setuptools"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ImportError: No module named 'setuptools'
$ pip install validators
Collecting validators
  Using cached validators-0.10.tar.gz
Could not import setuptools which is required to install from a source distribution.
Please install setuptools.
You are using pip version 8.0.2, however version 8.1.0 is available.
You should consider upgrading via the 'pip install --upgrade pip' command.

@ coala we normally add setuptools>=19.2 to our install_requires and it works fine. For example, this is what installing pyprint (one of our tools) without setuptools does:

$ pip install PyPrint
Collecting PyPrint
  Using cached PyPrint-0.2.3-py3-none-any.whl
Requirement already satisfied (use --upgrade to upgrade): termcolor~=1.1.0 in /home/ajk/.pyenv/versions/3.5.1/lib/python3.5/site-packages (from PyPrint)
Requirement already satisfied (use --upgrade to upgrade): colorama~=0.3.6 in /home/ajk/.pyenv/versions/3.5.1/lib/python3.5/site-packages (from PyPrint)
Collecting setuptools>=19.2 (from PyPrint)
  Using cached setuptools-20.3-py2.py3-none-any.whl
Installing collected packages: setuptools, PyPrint
Successfully installed PyPrint-0.2.3 setuptools-20.3
You are using pip version 8.0.2, however version 8.1.0 is available.
You should consider upgrading via the 'pip install --upgrade pip' command.

You can check out pyprint at https://github.com/coala-analyzer/pyprint

• Updated regex to not allow numeric only TLDs (examples in tests)
• Allow for idna encoded domains and test for them (examples in tests)

Fixes #47 Fixes #123

Hello,

It seems any string composed of numbers separated by dots is now accepted by the domain validator.

>>> validators.domain("123.123")
True

>>> validators.domain("123.123.123")
True

>>> validators.domain("123.123.123.123")
True

It didn't use to be the case (I know because it now causes some errors in my unit tests in the "naval" library) I think it was good that these strings weren't accepted as domains. I don't think these are valid domains.

The test for python 3.7 is not even succeeding to download the python interpret in travis.

I think this is because 3.7 requires a workaround with sudo: true in travis to work properly in 3.7. I can create a PR for this if you want help.

Version: 0.10.2

Wondering if this is a new behavior? I didn't have a chance to look at the code, though..

from validators import url

if url('http://127.0.0.1:8080/'):
    print("success")
else:
    print("failure")

failure

Including this thread, there are 83 #issues and 21 #PRs that were never addressed or were done so sparsely. They date as far back as 2015 and the latest commit on the master branch was 6 months ago.

@kvesteri I'm not sure what your intentions/ambitions are to maintain this package, but as a concerned developer (and yes a user) I'd like to extend my (skill set) support (in my off time) to the sustenance of this (validators) package. Anybody else, who wants to do so, may articulate it in your comments to this thread.

I suggest that this package is moved to a GitHub organization account and few people are provided with privileged/collaborative access to address the PRs and issues. If anyone has better/different ideas feel free to to voice them below.

Thanks!

"pypy3" is version 2.4.0 is feature compatible with Python 3.2.5. (Python 3.2 itself reached its end of life on 2016-02-20). "pypy3.5" should be feature compatible with Python 3.5.

Related to PR #61 .

Hello! I've noticed that I had some errors when getting a URL with a hostname that has an underscore, so I thought of finding and making some changes to the code such that URLs with an underscore in the hostname will now be valid, example: https://_this_is_an.example.com

I was unable to test with the testing folder of the project, mainly because I don't really know how either because there is no documentation or I am looking in the wrong areas, or I lack experience with python testing with how this project is structured. I did use my own method of testing (using grep and the -P argument) and the results worked in the favor I was intending for, so hopefully it works in the code as well.

I was also inspired that this issue has already been hinted at but not fixed.

Closes #102 Closes #180 Maybe closes #38 And maybe something should happen to #179

I found that the existing URL validator did not fully support certain IDNA URLs or emojis in URLs. This adds support for these while continuing to pass all existing tests.

A URL without a FQDN is perfectly valid. The resolver may attempt to add labels to a non FQDN in order to fully qualify it allowing the user to specify non-FQDNs.

I.e. http://pc:8081/ is perfectly valid:

$ host pc
pc.example.com has address 10.75.22.1
$ curl -q -4 -v 'http://pc:8081/'
*   Trying 10.75.22.1:8081...
* Connected to pc (10.75.22.1) port 8081 (#0)
> GET / HTTP/1.1
> Host: pc:8081
> User-Agent: curl/7.82.0
> Accept: */*
> 

Because /etc/reslov.conf has search example.com in it.

Yet this fails validation with validators.url()

$ python -c 'import validators; print(validators.url("http://pc:8081/"))'
ValidationFailure(func=url, args={'value': 'http://pc:8081/', 'public': False})

Hi @kvesteri, please consider adding type hints or an external library stubs to make mypy (or other type checker) to be happy. Thanks for your work 🙏

Hey guys, thanks a lot for the work! really appreciate it.

However it is failing for some urls like 'www.intesasanpaolo.com' Can you guys please check?