Mailman 3 January 2014 - Python-ideas

from __past__ import division, str, etc
by Alejandro López Correa 09 Jan '14

09 Jan '14

I am posting again this. I am new to mailing lists and I've realised I've sent it only to Nick Coghlan four hours ago. ---- 2014/1/8 Nick Coghlan <ncoghlan(a)gmail.com> > This is mostly a communications problem on our part. I certainly > thought "5 years for Python 3 to be the default choice for new > projects" was fairly straightforward to interpret > [...] > We're largely happy with the rate of adoption though - there were just > some folks that didn't grasp the kinds of time scales we're talking > about for a migration of this magnitude. > > See this for more details: > http://python-notes.curiousefficiency.org/en/latest/python3/questions_and_a… Ok, thanks. I see this has been a recurring topic and a lot of care has been given. I am looking at a different issue, though. I am thinking in existing projects, python 2 code in use, not even third party libraries but end products. I fear that if existing projects remain python 2 for too long because the benefit of expending resources on the migration are not worth the return, when the time finally comes for the upgrade another language might be chosen. At that point the divergence between that ancient py2 code and the latest py3 version would probably be greater than now, and other languages may offer features like GIL-less multithreading. If this happens in a large scale the whole python community may shrink and lose momentum. I do not know whether this is a real risk or not, and it is really up to you to assess it. I think a convenient way to run old python 2 modules along with new python 3 ones may be a good idea despite the cost. Even embedding a complete python 2.7 interpreter that executes .py2 modules and somehow shares the state with the main python 3 environment. I don't know whether that "monstrosity" is feasible without changing python 3 core too much, but it should help many people and nullify the risk of losing them. A large community is desirable in this context. > > With a 2to3 tool that covers 99.99% of the cases, we could even have .py2 > > modules that would be translated transparently to .py when first used > > I'm pretty sure someone already wrote one of those - they're a > problem, because they mean the tracebacks for runtime exceptions don't > match the source code The idea is that exceptions that end up showing tracebacks should be, uhmm, exceptional (the tool should work 99.9% of the time and we are talking about working py2 code). When something happens, the problem of a different source in the traceback could be handled by the translation tool by adding annotations (even comments). Cheers, Alejandro

3 3

Decorators on loops
by Enric Tejedor 08 Jan '14

08 Jan '14

Hello, I would like to discuss a new use of python decorators. I apologize if this has already been suggested before. The basic idea would be to support decorators on loops, in addition to functions and classes. Something like this: @mydecorator for i in range(10): # loop body In mydecorator, I would like to have access to the loop body and the iterable object. In my case, I would use this to parallelize the iterations of the loop. Thank you for your feedback, Enric WARNING / LEGAL TEXT: This message is intended only for the use of the individual or entity to which it is addressed and may contain information which is privileged, confidential, proprietary, or exempt from disclosure under applicable law. If you are not the intended recipient or the person responsible for delivering the message to the intended recipient, you are strictly prohibited from disclosing, distributing, copying, or in any way using this message. If you have received this communication in error, please notify the sender and destroy and delete any copies you may have received. http://www.bsc.es/disclaimer

5 8

[OT] banning Mark Janssen
by Ethan Furman 08 Jan '14

08 Jan '14

Moderators, Mark Janssen's posts are becoming extremely abusive, which seems to me to be against he code of conduct. Can we ban him, at least from the mailing lists? -- ~Ethan~

7 6

Strong password hashing algorithms in the standard library
by Terry Chia 08 Jan '14

08 Jan '14

Hi all, I would like to propose that a new library for strong password hashing algorithms[1] be included in the standard library. The proposed library should have implementations of one or more strong password hashes like pbkdf2, bcrypt or scrypt. There already exist third party libraries like passlib[2] that accomplishes the same thing but I feel that inclusion of the algorithms in the standard library would do a lot to help people that are not as security-aware to do the right thing when it comes to password storage. Alternatively, if the idea of adding the algorithms into the standard library does not have much support, I would like to see a warning added to the hashlib[3] documentation discouraging its use for password hashing. Thoughts? Cheers, Terry [1] http://security.stackexchange.com/q/211/10211 [2] https://code.google.com/p/passlib/ [3] http://docs.python.org/2/library/hashlib.html

4 4

str.startswith taking any iterator instead of just tuple
by James Powell 07 Jan '14

07 Jan '14

Some functions and methods allow the provision of a tuple of arguments which will be looped over internally. e.g., 'spam'.startswith(('s', 'z')) # 'spam' starts with 's' or with 'z' isinstance(42, (float, int)) In these cases, CPython uses PyTuple_Check and PyTuple_GET_ITEM to perform this internal iteration. As a result, the following are considered invalid: 'spam'.startswith(['s', 'z']) 'spam'.startswith({'s', 'z'}) 'spam'.startswith(x for x in 'sz') Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: startswith first arg must be str, unicode, or tuple There are two common workarounds: 'spam'.startswith(tuple({'s', 'z'})) any('spam'.startwith(c) for c in {'s', 'z'}) Of course, the following construction already has a clear, separate meaning: 'spam'.startswith('sz') # 'spam' starts with 'sz' In these cases, could we supplant the PyTuple_Check with one that would allow any iterator? Alternatively, could add this as an additional branch? The code would look something like: it = PyObject_GetIter(subobj); if (it == NULL) return NULL; iternext = *Py_TYPE(it)->tp_iternext; for(;;) { substring = iternext(it); if (substring == NULL) Py_RETURN_FALSE; result = tailmatch(self, substring, start, end, -1); Py_DECREF(substring); if (result) Py_RETURN_TRUE; } Of course, in the case of methods like .startswith, this would need to ensure the following behaviour remains unchanged. The following should always check if 'spam' starts with 'sz' not starts with 's' or with 'z': 'spam'.startswith('sz') I searched bugs.python.org and python-ideas for any previous discussion of this topic. If this seems reasonable, I can submit an enhancement to bugs.python.org with a patch for unicodeobject.c:unicode_startswith Cheers, James Powell follow: @dontusethiscode + @nycpython attend: nycpython.org + flask-nyc.org read: seriously.dontusethiscode.com

13 21

Getting file name of Path without suffix
by Ram Rachum 06 Jan '14

06 Jan '14

Hi guys, What do you think about introducing this Path property: @property def suffixless_name(self): return self.name[:-len(self.suffix)] if self.suffix else self.name It's simple but I'd really hate to have this conditional slicing in user code. Thanks, Ram.

2 1

`pathlib.Path.write` and `pathlib.Path.read`
by Ram Rachum 06 Jan '14

06 Jan '14

Hi, I'd really like to have methods `pathlib.Path.write` and `pathlib.Path.read`. Untested implementation: def read(self, binary=False): with self.open('br' is binary else 'r') as file: return file.read() def write(self, data. binary=False): with self.open('bw' is binary else 'w') as file: file.write(data) This will be super useful to me. Many files actions are one liners like that, and avoiding putting the `with` clause in user code would be wonderful. What do you think? Thanks, Ram.

3 2

strings as iterables - from str.startswith taking any iterator instead of just tuple
by Alexander Heger 05 Jan '14

05 Jan '14

> By designing an API that doesn't require such overloading. > > On Thursday, January 2, 2014, Alexander Heger wrote: >> >> >> isinstance(x, Iterable) and not isinstance(x, str) >> > >> > If you find yourself typing that a lot I think you have a bigger problem >> > though. >> >> How do you replace this? for my applications this seemed the most natural way - have the method deal with what it is fed, which could be strings or any kind of collections or iterables of strings. But never would I want to disassemble strings into characters. From the previous message I gather that I am not the only one with this application case. Generally, I find strings being iterables of characters as useful as if integers were iterables of bits. They should just be units. They already start out being not mutable. I think it would be a positive design change for Python 4 to make them units instead of being iterables. At least for me, there is much fewer applications where the latter is useful than where it requires extra code. Overall, it makes the language less clean that a string is an iterable; a special case we always have to code around. I know it will break a lot of existing code, but so did the string change from py2 to 3. (It would break very few of my codes, though.) -Alexander

15 27

Introduce constant: `pathlib.null_path`
by Ram Rachum 05 Jan '14

05 Jan '14

What do you think about introducing this constant in the `pathlib` module: null_path = pathlib.Path('\\Device\\Null') if os.name = 'nt' else pathlib.Path('/dev/null') Thanks, Ram.

4 3

Re: [Python-ideas] *var()*
by Liam Marsh 03 Jan '14

03 Jan '14

hello,here is my idea: var(): input var name (str), outputs var value example: >>>count1=1.34 >>>var('count',1) 1.34thank you and have a nice day!

5 7