I'm not sure I'm able to give a good answer to all your questions, but I found it interesting and took a look and here is my result.

In general, import mod.sub or from mod import sub assumes that sub is a sub-module in a mod package. However, it could also mean that sub is a field/variable declared in a mod module.

The presence of an __init.py__-file will denote that a folder is a package:

The __init__.py files are required to make Python treat the directories as containing packages; this is done to prevent directories with a common name, such as string, from unintentionally hiding valid modules that occur later on the module search path. In the simplest case, __init__.py can just be an empty file, but it can also execute initialization code for the package (...).

I believe that, from werkzeug import security and import werkzeug.security both imports a module security, thus security.generate_password_hash is a known and valid attribute. Basically, from werkzeug.security import generate_password_hash imports that very attribute directly via the valid import statement.

In the Werkzeug Quickstart docs, I found the following:

Make sure to import all objects from the places the documentation suggests. It is theoretically possible in some situations to import objects from different locations but this is not supported.

Further, Werkzeug transition to 1.0 states:

Werkzeug originally had a magical import system hook that enabled everything to be imported from one module and still loading the actual implementations lazily as necessary. Unfortunately this turned out to be slow and also unreliable on alternative Python implementations and Google’s App Engine.

Starting with 0.7 we recommend against the short imports and strongly encourage starting importing from the actual implementation module. Werkzeug 1.0 will disable the magical import hook completely.

It appears that Werkzeug modifies how modules are loaded. (I speculate that this is not uncommon in big packages with contrib-content, e.g. Flask, Django; motivated by ability to lazy-load, improve performance, or manage contributed module content spread across packages.)

As you've discovered, import werkzeug does not import security from the werkzeug module, because (as far as I understand), the only submodules that will be imported as attributes are those defined on line 100 of the __init__.py:

# modules that should be imported when accessed as attributes of werkzeug
attribute_modules = frozenset(['exceptions', 'routing'])

In the same file, when looking at the Werkzeug's module(ModuleType)-class, and its __getattr__()-method:

class module(ModuleType):

    """Automatically import objects from the modules."""

    def __getattr__(self, name):
        if name in object_origins:
            module = __import__(object_origins[name], None, None, [name])
            for extra_name in all_by_module[module.__name__]:
                setattr(self, extra_name, getattr(module, extra_name))
            return getattr(module, name)
        elif name in attribute_modules:
            __import__('werkzeug.' + name)
        return ModuleType.__getattribute__(self, name)

It seems that module names in the object_origins dictionary, via definition in all_by_module, must be imported separately, and werkzeug.security is one of them.

Lastly, I think the reason for why the:

import werkzeug     
from werkzeug import security  

combination works, is that the first line does not import security, but the second one does, AND the __getattr__()-method will return modules that are explicitly imported.

Edit: this last section is not correct, tested by Filipp:

I expect that by simply doing only from werkzeug import security that still werkzeug.security.generate_password_hash() would work. (I have not tested or confirmed this)

werkzeug.generate_password_hash wants to generate a salt value. Taking a look at the source we can see _hash_internal called with the generated salt value.

def generate_password_hash(password, method="pbkdf2:sha256", salt_length=8):
    """Hash a password with the given method and salt with a string of
    the given length. The format of the string returned includes the method
    that was used so that :func:`check_password_hash` can check the hash.

    The format for the hashed string looks like this::

        method$salt$hash

    This method can **not** generate unsalted passwords but it is possible
    to set param method='plain' in order to enforce plaintext passwords.
    If a salt is used, hmac is used internally to salt the password.

    If PBKDF2 is wanted it can be enabled by setting the method to
    ``pbkdf2:method:iterations`` where iterations is optional::

        pbkdf2:sha256:80000$salt$hash
        pbkdf2:sha256$salt$hash

    :param password: the password to hash.
    :param method: the hash method to use (one that hashlib supports). Can
                   optionally be in the format ``pbkdf2:<method>[:iterations]``
                   to enable PBKDF2.
    :param salt_length: the length of the salt in letters.
    """
    salt = gen_salt(salt_length) if method != "plain" else ""
    h, actual_method = _hash_internal(method, salt, password)
    return "%s$%s$%s" % (actual_method, salt, h)

If we call _hash_internal with your sha1 method, and provided salt/password, we get a different hash

In [83]: import werkzeug.security                                                                                                                                                     

In [84]: h, method = werkzeug.security._hash_internal('sha1', 'e40e1e9addc186828a5554a71527342c', '123456')                                                                           

In [86]: h == '784517f57fbe61179960739e29d7ae925aa4fd5b'                                                                                                                              
Out[86]: False

In [85]: h                                                                                                                                                                            
Out[85]: 'e8c2de9bdc1ab92479e3e55b608a040dad7bf656'

I think you'll need to revisit your PHP code to see how these values are generated.

EDIT: per your comment

In [138]: werkzeug.security._hash_internal('sha1', '', 'e40e1e9addc186828a5554a71527342c123456')                                                                                      
Out[138]: ('784517f57fbe61179960739e29d7ae925aa4fd5b', 'sha1')

If you want to use check_password_hash you'd have to not set the salt on your hash and instead prepend it to your password:

In [148]: werkzeug.check_password_hash('sha1$$784517f57fbe61179960739e29d7ae925aa4fd5b', 'e40e1e9addc186828a5554a71527342c123456')                                                    
Out[148]: True

If we look at the source we can see that check_password_hash extracts method, salt, and hashval out of the pwhash, then validates the hashed password matches hashval. I'm not familiar with hashing in PHP, but it appears the password was "salted" and then hashed without salt (as far as werkzeug.security is concerned anyway).

def check_password_hash(pwhash, password):
    """check a password against a given salted and hashed password value.
    In order to support unsalted legacy passwords this method supports
    plain text passwords, md5 and sha1 hashes (both salted and unsalted).

    Returns `True` if the password matched, `False` otherwise.

    :param pwhash: a hashed string like returned by
                   :func:`generate_password_hash`.
    :param password: the plaintext password to compare against the hash.
    """
    if pwhash.count("$") < 2:
        return False
    method, salt, hashval = pwhash.split("$", 2)
    return safe_str_cmp(_hash_internal(method, salt, password)[0], hashval)

The use of SHA-1 in generate_password_hash is not vulnerable, as it is only used as an intermediate, iterated step in the PBKDF2 hash. See the discussion in chat.

when you're chaining zillions of hashes as in PBKDF2 the risk is indistinguishable from someone breaking a strong password by pure chance.

There was further discussion on the cryptography-dev mailing list.

You're correct that HMAC's security is still fine when used with SHA-1, HMAC-MD5 is even secure believe it or not.

generate_password_hash takes a method argument to customize how the hash is generated. The default is pbkdf2:sha1. Pass a different derivation method for PBKDF2.

generate_password_hash(secret, method='pbkdf2:sha512')

You can also change the number of iterations from the default of 150,000 to a higher number, at the cost of a slower hash speed. pbkdf2:sha1:200000.

You're probably okay with PBKDF2, as long as the hash and iterations are tuned well. Alternatively, use Passlib, which supports more hash methods than Werkzeug. See Passlib's recommended hashes for discussion on which hashes to use. This example shows how to use bcrypt with Passlib.

pip install passlib bcrypt

from passlib.context import CryptContext
crypt_context = CryptContext(schemes=['bcrypt_sha256'])
crypt_context.hash(secret)