Mailman 3 May 2010 - Python-ideas

i18n and Python tracebacks
by Andre Roberge 28 Oct '12

28 Oct '12

I think it would be a good idea if Python tracebacks could be translated into languages other than English - and it would set a good example. For example, using French as my default local language, instead of >>> 1/0 Traceback (most recent call last): File "<stdin>", line 1, in <module> ZeroDivisionError: integer division or modulo by zero I might get something like >>> 1/0 Suivi d'erreur (appel le plus récent en dernier) : Fichier "<stdin>", à la ligne 1, dans <module> ZeroDivisionError: division entière ou modulo par zéro André

9 15

reiter: decorator to make generators reiterable
by Mathias Panzenböck 13 Jun '10

13 Jun '10

I think this decorator sould be included in itertools: from functools import wraps class ReIter(object): __slots__ = 'f', 'args', 'kwargs' def __init__(self,f,args,kwargs): self.f = f self.args = args self.kwargs = kwargs def __iter__(self): return self.f(*self.args, **self.kwargs) def reiter(f): @wraps(f) def _reiter(*args,**kwargs): return ReIter(f,args,kwargs) return _reiter Using this you can iterate over the return value of a generator decorated with reiter as often as you like (and not just once): @reiter def gen(x,y): for i in xrange(x): yield i*y g = gen(5,3) for x in g: sys.stdout.write('%r\n' % x) sys.stdout.write('\n') for x in g: sys.stdout.write('%r\n' % x) The difference to tee is that old values are not remembered but the generator is evaluated when __iter__() is called. This might come in handy when you implement methods like items(), values() and keys() in a custom dict implementation. Or is there already such a thing and I missed it? -panzi PS: Maybe it should be called regen/ReGen instead of reiter/ReIter? PPS: Funny thing, both "Reiter" and "Regen" are german words. Reiter = rider or tab; Regen = rain.

4 3

Date/time literals
by Marcos Bonci 04 Jun '10

04 Jun '10

Hi! I've been working a lot with date/time variables lately, and maybe it's just me, and maybe I just don't get it yet, but it sure doesn't feel like there's one-and-only-one elegant, obvious way to work with them. Feels like working with strings in C. So I was thinking, have date and time literals ever been seriously discussed anywhere in these discussion lists? (If so, I apologize in advance for reviving this subject.) Is there any chance we could ever see date/time literals in Python? Perhaps as a top-level abstraction itself, or as a subclass of numbers.Number, or even as common float or int (by adding attributes regarding specific properties of a number's date/time interpretation, e.g. "<2010-12-31>.incr_month(2) == <2011-02-28>" -- just an example though, i don't really think this exact method would be practical). If we adopt a standard like ISO 8601, then we automatically get an unambiguous one-to-one relationship between (date+time) and (amount of time elapsed from <epoch>), over a continuous, infinite domain (towards +inf and -inf). Very often the "time elapsed" value is what we really want (or at least the absolute difference between two values, which is of course easier to find in this form), and besides being more compact and flexible, no functionality is lost. I guess the most controversial point here would be the meaning of arithmetic operations between dates (or the very validity of such operations). Another (not so obvious) problem is leap seconds (btw, who the hell invented that?!..). It's a weird and complicated problem, but I think it's not impossible to turn this "complicated" into just "complex", keeping the tricky concepts buried inside the implementation. Anyway, here's a couple of suggestions for a syntax: 2010.05.29 + 20.06.17 2010.05.29d + 20.06.17t (just like complex literals) So, what do you guys think? I'd love to hear others' opinions, even if it's just for me to understand what I got wrong and see the obvious way that's already there :) PS: Just for fun, is there a standard way I could experiment with creating new types of literals? -- Marcos --

14 39

An identity dict
by Benjamin Peterson 03 Jun '10

03 Jun '10

In the spirit of collections.OrderedDict and collections.defaultdict, I'd like to propose collections.identitydict. It would function just like a normal dictionary, but ignore hash values and comparison operators and merely lookup keys based on the key's id(). This dict is very useful for keep track of objects that should not be compared by normal comparison methods. For example, I would use an identitydict to hold weak references that would otherwise fallback to their referant object's hash. An advantage of formalizing this in collections would be to enable other Python implementations like PyPy, where id() is expensive, to provide an optimized identitydict. Regards, Benjamin

20 43

Allowing negative `maxsplit` in `str.split`
by cool-RR 16 May '10

16 May '10

Here's something that I would want now: An ability to give a negative `maxsplit` argument to `str.split`, to make it start splitting from the end of the string. For example, right now I wanted to be able to separate a module's name 'hello.world.meow' to ['hello.world', 'meow'] without knowing how many dots would be in the name. If I could give a `maxsplit` of -1 to achieve this, it would be nice. What do you think? Ram. (Please `cc` any replies to me if you can, thanks.)

3 3

Fwd: i18n and Python tracebacks
by Andre Roberge 15 May '10

15 May '10

Sorry, I did not forward to the list by mistake. ---------- Forwarded message ---------- From: Andre Roberge <andre.roberge(a)gmail.com> Date: Sat, May 15, 2010 at 12:13 PM Subject: Re: [Python-ideas] i18n and Python tracebacks To: Antoine Pitrou <solipsis(a)pitrou.net> On Sat, May 15, 2010 at 12:04 PM, Antoine Pitrou <solipsis(a)pitrou.net>wrote: > On Sat, 15 May 2010 11:02:35 -0300 > Andre Roberge <andre.roberge(a)gmail.com> > wrote: > > >>> 1/0 > > Suivi d'erreur (appel le plus récent en dernier) : > > Fichier "<stdin>", à la ligne 1, dans <module> > > ZeroDivisionError: division entière ou modulo par zéro > > I'm not sure it's a good idea. The fact that these messages are always > in English makes it possible: > - to share them with other developers in order to get help > - to parse them in order to assert certain kind of errors > > These messages are primarily meant for developers, not users. > I think you forget students (including one ones) that have to deal with such messages. Imagine you could start python with python --lang="en" your_script.py This would easily allow to share tracebacks with developers to get help. > (as a sidenote, I regularly get annoyed by gcc's "translated" error > messages -- especially how crappy the French translation often is. > It's always better to get a good English error message than a horrible > French one) > True ... I know I'd choose English as a default myself for Python (even though, like you I believe, French is my first language). *But*, for beginners, this would be, I think, a great option. André > > Antoine. > > > _______________________________________________ > Python-ideas mailing list > Python-ideas(a)python.org > http://mail.python.org/mailman/listinfo/python-ideas >

3 2

Making Python more enterprise technology
by Filip Gruszczyński 12 May '10

12 May '10

For some reason Python seems not to be seen as an enterprise technology unlike Java or .net. Do you think there any steps that could be taken, to change this opinion? I love Python, but all job offers I can find at the moment are web development. At my company we use Python a lot, but that's only because my lead is a very sensible person and sees python potential and me and my friend are python enthusiasts. Anyway, beside one Python + Qt project we mostly use Django for projects. How can this be changed? What Python is lacking? -- Filip Gruszczyński

12 24

division oddness
by Mathias Panzenböck 07 May '10

07 May '10

Shouldn't by by mathematical definition -x // y be the same as -(x // y)? But when assign x=2, y=3 you get: >>> -2 // 3 -1 >>> -(2 // 3) 0 And also: >>> 2 // -3 -1 >>> -2 // -3 0 And even more: >>> int(-2 / 3) 0 >>> int(2 / -3) 0 I think this rather odd. Is there any deeper reason to this behaviour? I guess changing this will break a lot of code, but why does it behave like this? -panzi

6 5

integer dividion in R -- PS
by spir ☣ 07 May '10

07 May '10

Hello again, I searched the def of int division in R. I could not find it in the english wikipedia, but in the french one, there was http://fr.wikipedia.org/wiki/Division_enti%C3%A8re#Division_euclidienne_dan…: for each pair (a,b) in ZxZ*, there exists (q,r) in ZxZ | a = b*q + r | |r| < |b| This implies that if a xor b is negative, thare are 2 of solutions: the one where (q,r) is equal in absolute value to the solution in N, and (q-1,r+b). So, in the case of -4/3, we have the choice between (-1,-1) and (-2,2). The following discussion in the article does not tell whether one solution is the _official_ one. But: that -4/3 != -(4/3) looks simply wrong for me. Denis ________________________________ vit esse estrany ☣ spir.wikidot.com

5 4

Re: [Python-ideas] integer dividion in R -- PS
by Xavier Ho 07 May '10

07 May '10

On Fri, May 7, 2010 at 7:43 PM, Mark Dickinson <dickinsm(a)gmail.com> wrote: > No: PEP 238 is (partly) about how integer division is expressed in > Python; not about its semantics. Python's choice for integer > division with negative arguments goes back much further. From > Misc/HISTORY: > > ================================== > ==> RELEASE 0.9.6 (6 Apr 1992) <== > ================================== > > [...] > > New features in 0.9.6: > > [...] > > - Division and modulo for long and plain integers with negative operands > have changed; a/b is now floor(float(a)/float(b)) and a%b is defined > as a-(a/b)*b. So now the outcome of divmod(a,b) is the same as > (a/b, a%b) for integers. For floats, % is also changed, but of course > / is unchanged, and divmod(x,y) does not yield (x/y, x%y)... > [...] > Nice! Thanks for sharing. > > > Personally, I've always liked Python's behaviour in this regard: for > the few times that I've needed an 'x % y' operation that works with > both positive and negative x, more often than not x-y*floor(x/y) turns > out to be what I need. I've lost count of the number times I've had > to write something awkward like: > > /* adjust for the exponent; first reduce it modulo _PyHASH_BITS */ > e = e >= 0 ? e % _PyHASH_BITS : _PyHASH_BITS-1-((-1-e) % > _PyHASH_BITS); > > in C. > Wow. I would never write code like that, but you got a fair point. Cheers, Xav (Mark: Sorry, I forgot to reply to the correct list.)

3 2