Mailman 3 June 2012 - Python-ideas

isascii()/islatin1()/isbmp()
by Serhiy Storchaka July 2, 2012

July 2, 2012

As shown in issue #15016 [1], there is a use cases when it is useful to determine that string can be encoded in ASCII or Latin1. In working with Tk or Windows console applications can be useful to determine that string can be encoded in UCS2. C API provides interface for this, but at Python level it is not available. I propose to add to strings class new methods: isascii(), islatin1() and isbmp() (in addition to such methods as isalpha() or isdigit()). The implementation will be trivial. … [View More]

10 19

Happy leap second
by Alexander Belopolsky July 1, 2012

July 1, 2012

Even though many have hoped that the authorities would stop fiddling with our clocks, today a leap second will be inserted in UTC. Systems using Olson/IANA timezone database have a way to deal with this without adjusting their clocks, but few systems are configured that way: $ TZ=right/UTC date -d @1341100824 Sat Jun 30 23:59:60 UTC 2012 (1341100824 is the number of seconds since epoch including the leap seconds.) Python's time module works fine with the "right" timezones: >>> … [View More]

4 9

BackupFile
by Kim Gräsman June 29, 2012

June 29, 2012

Hello, I'm new here, so forgive me if this has been discussed before or is off-topic. I came up with a mechanism that I thought might be useful in the Python standard library -- a scope-bound self-restoring backup file. I came to this naïve implementation; -- class BackupError(Exception): pass class Backup: def __init__(self, path): if not os.path.exists(path) or os.path.isdir(path): raise BackupError("%s must be a valid file path" % path) self.path = path … [View More]

7 10

Re: [Python-ideas] itertools.chunks(iterable, size, fill=None)
by Joao S. O. Bueno June 29, 2012

June 29, 2012

On 29 June 2012 05:55, Michele Lacchia <michelelacchia(a)gmail.com> wrote: > + 1 for the original proposal! I don't think splitting belongs to potential > itertools.chunks > > Il giorno martedì 26 giugno 2012 14:58:35 UTC+2, Simon Sapin ha scritto: >> >> Le 26/06/2012 14:42, Joao S. O. Bueno a écrit : >> > itertools.chunks(iterable, size=None, separator=None, fill=None) >> > >> > Requiring at leas one of size or separator to be set? >&… [View More]

1 0

Re: [Python-ideas] BackupFile
by Kim Gräsman June 25, 2012

June 25, 2012

Hi Mike, On Mon, Jun 25, 2012 at 3:41 PM, Mike Graham <mikegraham(a)gmail.com> wrote: > > I like the basic idea, but if we do something like this, it would be > useful to have read access to the old version of the file while you > are writing out the new version that might become permanent. Thanks, though this sounds like another mechanism than the one I'm aiming for :-) I want to replace an existing file temporarily, and then restore it no matter what. > If I was to … [View More]

4 6

BackupFile
by Kim Gräsman June 25, 2012

June 25, 2012

+python-ideas ---------- Forwarded message ---------- From: Kim Gräsman <kim(a)mvps.org> Date: Mon, Jun 25, 2012 at 3:21 PM Subject: Re: [Python-ideas] BackupFile To: Masklinn <masklinn(a)masklinn.net> Hi Masklinn, Thanks for your response! On Mon, Jun 25, 2012 at 2:33 PM, Masklinn <masklinn(a)masklinn.net> wrote: > On 2012-06-25, at 14:17 , Kim Gräsman wrote: >> >> - Would something like this be useful outside of my office? > > I'm not sure I … [View More]

1 0

Just __main__
by anatoly techtonik June 21, 2012

June 21, 2012

How about global __main__ as a boolean? __name__ == '__main__' as a mark of entrypoint module is coherent and logical, but awkward to type and requires explicit explaination for newcomers even with prior background in other langauges.

18 30

Add adaptive-load salt-mandatory hashing functions?
by Masklinn June 20, 2012

June 20, 2012

The standard library already provides for cryptographic hashes (hashlib) and MACs (hmac). One issue which exists, and has been repeatedly outlined after several breaches of straight-hashed databases (salted and unsalted) last week, is that many developers do not know: 1. straight hashes are not sufficient to store passwords securely in case of database breach 2. salted password, while mitigating rainbow table attacks, aren't enough to mitigate brute-force attacks. (in case of database … [View More]breach, the goal being to protect password plaintexts from being found and matched to a user identity in case users re-use passwords across services, as it would allow attackers to access all services used by the user). The best solution to these currently is *mandatory* salting (of specified minimum strength) and adaptive workload which can be tuned higher to keep up with Moore's law (especially as most hashing functions tend to be very fast and embarassingly parallelizable, two undesirable properties in the face of brute-forcing of the plaintext). Therefore, I would suggest either adding a new module (name tbd) or adding new constructors to hashlib. * All password-hashing functions listed below should recommend a strong salt (the PBKDF2 specification recommends 64 bits, we could go further) by erroring out (ValueError) if the conditions are not met unless a `weak_salt=True` parameter is provided. I think this would be sufficient to hint at the importance of salt to users, and to drive them to "the right thing". The salt should also be mandated non-empty, providing an empty salt should generate an error in all cases. * All password-hashing functions should require a `workload` parameter with documentary recommendation. A default value might make sense in the short run (ensure the functions are used with an acceptably high workload), but those defaults would be set in stone for users *not* setting their own load factor. This module (or addition) should provide, if possible: * PBKDF2, recommending a load factor of above 10000. The recommended load factor in RFC 2898 (PKCS #5) is 1000, but the specification is 12 years old. Extrapolating on that original load factor using Moore's law (the load factor has a linear relation to the amount of computation in PBKDF2 as it's the number of hashing iterations), the stdlib could recommend a load factor of 64000 (6 doublings). As with hmac, it should be possible to configure the digest constructor (PKCS #5 specifies HMAC-SHA1 as the default PRF) * bcrypt, the bcrypt C library is BSD-licensed and open-source so it could be added pretty directly, there is already a wrapper called "py-bcrypt" (under ISC/BSD licence)[0] * scrypt is younger and has been looked at less than the previous two[0], but from my readings (of articles on it, I am no cryptographer) it seems to have no overt issue and combines load-adaptive CPU-hardness with load-adaptive memory-hardness (PBKDF2 and bcrypt both work in constant space) making it significantly more resistant to massively parallel brute-forcing arrays (GPGPU or custom ASIC). It is available under a 2-clause BSD license as are the existing Python bindings I could find[2], but has a hard dependency on OpenSSL which may prevent its usage. I think these would make Python users safe by lowering the cost of using these functions and by demonstrating ways to safely store passwords up-front. They could be augmented with a note in hashlib indicating that they are to be preferred for password hashing. [0] especially PBKDF2, still the most conservatively safe choice [1] http://code.google.com/p/py-bcrypt/ [2] http://pypi.python.org/pypi/scrypt/ [View Less]

11 27

Context helper for new os.*at functions
by Christian Heimes June 16, 2012

June 16, 2012

Hello, Python 3.3 has got new wrappers for the 'at' variants of low level functions, for example os.openat(). The 'at' variants work like their brothers and sisters with one exception. The first argument must be a file descriptor of a directory. The fd is used to calculate the absolute path instead of the current working directory. File descriptors are harder to manage than files because a fd isnt't automatically closed when it gets out of scope. I've written a small wrapper that takes care … [View More]

2 2

Make dict customisation easier
by Laurie Clark-Michalek June 16, 2012

June 16, 2012

Hi, A few weeks ago, a guy was on #python, looking to customise a dictionary to be case insensitive (he was assuming string keys). His naive implementation looked something like this: class CaseInsensitiveDict(dict): def __getitem__(self, key): return dict.__getitem__(self, key.lower()) def __setitem__(self, key, item): dict.__setitem__(self, key.lower(), item) However he was dismayed to find that this didn't work with other methods that dict uses:… [View More]

2 1