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
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ZeroDivisionError: integer division or modulo by zero
I might get something like
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 think this decorator sould be included in itertools:
from functools import wraps
__slots__ = 'f', 'args', 'kwargs'
self.f = f
self.args = args
self.kwargs = kwargs
return self.f(*self.args, **self.kwargs)
Using this you can iterate over the return value of a generator decorated with reiter as often as
you like (and not just once):
for i in xrange(x):
g = gen(5,3)
for x in g:
sys.stdout.write('%r\n' % x)
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?
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.
I've been working a lot with date/time variables lately, and maybe it's just
maybe I just don't get it yet, but it sure doesn't feel like there's
elegant, obvious way to work with them. Feels like working with strings in
So I was thinking, have date and time literals ever been seriously
in these discussion lists? (If so, I apologize in advance for reviving this
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
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
I guess the most controversial point here would be the meaning of arithmetic
between dates (or the very validity of such operations).
Another (not so obvious) problem is leap seconds (btw, who the hell invented
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
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 --
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
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?
(Please `cc` any replies to me if you can, thanks.)
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>
> > >>> 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
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.
> Python-ideas mailing list
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?
Shouldn't by by mathematical definition -x // y be the same as -(x // y)? But when assign x=2, y=3
>>> -2 // 3
>>> -(2 // 3)
>>> 2 // -3
>>> -2 // -3
And even more:
>>> int(-2 / 3)
>>> int(2 / -3)
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?
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_d...:
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.
vit esse estrany ☣
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
> ==> 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) %
> in C.
Wow. I would never write code like that, but you got a fair point.
(Mark: Sorry, I forgot to reply to the correct list.)