As Thomas has said, a true and proper cryptographic hash function should not leak any information about the password. This is due to a few things:
- Fixed-length output: The hash output will always be a certain length (varies depending on algorithm), regardless of how long or short the password is.
- Unique, dissimilar outputs: Any change to the password should result in such a significant change to the output, that two very similar passwords (i.e.: "password1" and "password2") are not similar after hashing.
- Unique, per-user salt: An added element is used in the hashing function that is unique for each user, such that two users choosing the same password will not have the same password hash.
As has been mentioned in my comments, and included in grawulf's answer, there have historically been examples of hashing functions which violate these principles. Perhaps the most well-known example of this is LANMAN (a.k.a.: LM hash, or LAN Manager hash). This hashing function was used in versions of Windows prior to NT, and is still included (though disabled by default) for backward-compatibility in modern versions.
The problems with LANMAN are many, but most of them are rooted in its use of DES - especially the part that allows for guessing a user's password length. DES is limited to a 56-bit key length, which translates to 7 bytes or ASCII characters. Of course this must have been known, even in pre-NT days, to be too small for a reasonably strong password.
So, Microsoft's work-around was to split the user's password in half, hash each half separately, then stick the hash strings together to form the final LM hash. This would allow users to create passwords up to 14 characters long. For passwords shorter than 14 characters, there would be an added padding of null characters at the end (prior to splitting the password) to fill out the rest of the DES key(s). Of course, this means that all passwords shorter than 7 characters would end up with the latter half of their hash (having started as all null characters, and hashed without salt) being identical to all other passwords shorter than 7 characters.
If Microsoft had used a per-user salt, it would at least have prevented the easy guessing of a user's password length from the hash output. It would also have made dictionary attacks a fair deal more difficult. However, there are other inherent weaknesses (beyond the scope of this question) in the function which still leave it wholly unsuitable for use in today's world.
Modern cryptographic functions are much stronger and smarter than this, and therefore much less likely to leak any particular data about your password's length. However, it is good to bear in mind this historical detail as an example of how not to hash passwords. (Of course, it's never a good idea to roll your own crypto anyway.)
TIP: While hashing passwords with LANMAN has been disabled by default since Vista, it is still an available feature for backwards-compatibility. If you want to make sure that your Windows passwords cannot and therefore will not be processed as LM hashes on any Windows system, despite how the system administrator may configure it, make sure your passwords are at least 15 characters long.