From rthorat at starentnetworks.com  Sun May  2 07:28:06 2010
From: rthorat at starentnetworks.com (Thorat, Rajashree)
Date: Sun, 2 May 2010 10:58:06 +0530
Subject: [Python-ideas] regarding CPU utilization calculation in python on
	solaris
Message-ID: <3BD53621E5C8E54594130AF5459379EE38A4ED@exchindia4.starentnetworks.com>



Hi


I would like to know if there is any way to calculate system wide CPU utilization in python on solaris. I got the way to calculate utilization on solaris for a process but not system wide CU utilization calculation. For linux there are methods which make use pf /etc/proc file. Is there any similar way present for solaris. If not, I would appriciate if anyone will tell me why this support is not there. Is there any specific reason for not providing this functionality.



Thanks,
Rajashree. 


This email and any attachments may contain legally privileged and/or confidential information of Starent Networks, Corp. and is intended only for the individual or entity named in the message.  The information transmitted may not be used to create or change any contractual obligations of Starent Networks, Corp.  Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this e-mail and its attachments by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify the sender immediately -- by replying to this message or by sending an email to postmaster at starentnetworks.com -- and destroy all copies of this message and any attachments without reading or disclosing their contents. Thank you.


From cmjohnson.mailinglist at gmail.com  Mon May  3 02:29:05 2010
From: cmjohnson.mailinglist at gmail.com (Carl M. Johnson)
Date: Sun, 2 May 2010 14:29:05 -1000
Subject: [Python-ideas] regarding CPU utilization calculation in python
	on solaris
In-Reply-To: <3BD53621E5C8E54594130AF5459379EE38A4ED@exchindia4.starentnetworks.com>
References: <AcrpuD5YB5C8ihXtQ7O/GPG4tMTxqA==>
	<3BD53621E5C8E54594130AF5459379EE38A4ED@exchindia4.starentnetworks.com>
Message-ID: <i2i3bdda691005021729q14ebf46cj5e6106bcac5181b1@mail.gmail.com>

This mailing list is for ideas on improving the Python language.
Please ask your question elsewhere.

-- Carl Johnson

On Saturday, May 1, 2010, Thorat, Rajashree <rthorat at starentnetworks.com> wrote:
>
>
> Hi
>
>
> I would like to know if there is any way to calculate system wide CPU utilization in python on solaris. I got the way to calculate utilization on solaris for a process but not system wide CU utilization calculation. For linux there are methods which make use pf /etc/proc file. Is there any similar way present for solaris. If not, I would appriciate if anyone will tell me why this support is not there. Is there any specific reason for not providing this functionality.
>
>
>
> Thanks,
> Rajashree.
>
>
> This email and any attachments may contain legally privileged and/or confidential information of Starent Networks, Corp. and is intended only for the individual or entity named in the message. ?The information transmitted may not be used to create or change any contractual obligations of Starent Networks, Corp. ?Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this e-mail and its attachments by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify the sender immediately -- by replying to this message or by sending an email to postmaster at starentnetworks.com -- and destroy all copies of this message and any attachments without reading or disclosing their contents. Thank you.
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>


From grosser.meister.morti at gmx.net  Fri May  7 02:43:42 2010
From: grosser.meister.morti at gmx.net (=?ISO-8859-1?Q?Mathias_Panzenb=F6ck?=)
Date: Fri, 07 May 2010 02:43:42 +0200
Subject: [Python-ideas] division oddness
Message-ID: <4BE3623E.5000900@gmx.net>

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


From python at mrabarnett.plus.com  Fri May  7 03:09:22 2010
From: python at mrabarnett.plus.com (MRAB)
Date: Fri, 07 May 2010 02:09:22 +0100
Subject: [Python-ideas] division oddness
In-Reply-To: <4BE3623E.5000900@gmx.net>
References: <4BE3623E.5000900@gmx.net>
Message-ID: <4BE36842.7060404@mrabarnett.plus.com>

Mathias Panzenb?ck wrote:
> 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?
> 
It's so that:

     y == (y // x) * x + (y % x)

is always True (assuming x != 0).


From pyideas at rebertia.com  Fri May  7 03:13:11 2010
From: pyideas at rebertia.com (Chris Rebert)
Date: Thu, 6 May 2010 18:13:11 -0700
Subject: [Python-ideas] division oddness
In-Reply-To: <4BE3623E.5000900@gmx.net>
References: <4BE3623E.5000900@gmx.net>
Message-ID: <o2i50697b2c1005061813ub4710185oe2483ad9611b4d82@mail.gmail.com>

On Thu, May 6, 2010 at 5:43 PM, Mathias Panzenb?ck
<grosser.meister.morti at gmx.net> wrote:
> Shouldn't by mathematical definition -x // y be the same as -(x // y)?

Not necessarily, that's only one possible definition; it is the one
that happens to be used in number theory, but it's not the *only*
possible one.
Most programming languages don't choose that definition and instead
choose one of 2 other definitions that use the signs of the operands
to determine what signs a%b and a//b will have (the difference between
the 2 definitions being *which* operand's sign is used).
See http://en.wikipedia.org/wiki/Modulo_operation for a thorough explanation.

> 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 would suppose it's what programmers have found more
useful/intuitive. Most programmers aren't number theorists.

Cheers,
Chris
--
http://blog.rebertia.com


From tjreedy at udel.edu  Fri May  7 05:24:50 2010
From: tjreedy at udel.edu (Terry Reedy)
Date: Thu, 06 May 2010 23:24:50 -0400
Subject: [Python-ideas] division oddness
In-Reply-To: <4BE36842.7060404@mrabarnett.plus.com>
References: <4BE3623E.5000900@gmx.net> <4BE36842.7060404@mrabarnett.plus.com>
Message-ID: <hs0161$t2q$1@dough.gmane.org>

On 5/6/2010 9:09 PM, MRAB wrote:
> Mathias Panzenb?ck wrote:
>> Shouldn't by by mathematical definition -x // y
be the same as -(x // y)?

When defining division of counts, which have no signs, quotient and 
remainder cannot be negative. So division both rounds down and rounds 
toward zero. It both truncates and floors.

When defining division on integers (signed counts), one can either 
define it to round down or to round toward zero, but obviously not both. 
As mentioned in the article Chris linked to,
http://en.wikipedia.org/wiki/Modulo_operation
one can also round down or up depending on the sign of the divisor.

The above definition is 'round toward zero' truncation. It has the 
anomaly that 0 then is the rounded value (and representative) of all 
ratios in the doubly open length-2 range (-1, 1) while all other 
quotients represent a half-open length-1 range. The is because -0 == 0 
whereas -n != n for all other ints. For 'round down', every quotient, 
including 0, represents a half-open length-1 range.

> It's so that:
> y == (y // x) * x + (y % x)
> is always True (assuming x != 0).

No, this is true for any definition of y//x if you *define* y % x to be 
y - (y//x)*x. But for truncation, this mean that the sign of y%x depends 
on the sign of y rather than the sign of x, as with floor division. The 
latter is probably more useful more of the time. For instance, y % 2 has 
only 2 possible values (0,1) with flooring rather than three (-1, 0, 1) 
as with truncation.

Terry Jan Reedy






From denis.spir at gmail.com  Fri May  7 09:21:28 2010
From: denis.spir at gmail.com (spir =?UTF-8?B?4pij?=)
Date: Fri, 7 May 2010 09:21:28 +0200
Subject: [Python-ideas] division oddness
In-Reply-To: <4BE3623E.5000900@gmx.net>
References: <4BE3623E.5000900@gmx.net>
Message-ID: <20100507092128.2cbddfea@o>

On Fri, 07 May 2010 02:43:42 +0200
Mathias Panzenb?ck <grosser.meister.morti at gmx.net> wrote:

>  >>> -2 // 3  
> -1

???
This is simply wrong, for me. The algorithm seems to use floor instead of integral part! But I'm unsure about math definition.

Denis
________________________________

vit esse estrany ?

spir.wikidot.com


From denis.spir at gmail.com  Fri May  7 09:28:42 2010
From: denis.spir at gmail.com (spir =?UTF-8?B?4pij?=)
Date: Fri, 7 May 2010 09:28:42 +0200
Subject: [Python-ideas] integer dividion in R
Message-ID: <20100507092842.18bc6532@o>

Hello,


The following point came up on the python-tutor mailing list:

spir at o:~$ python
Python 2.6.4 (r264:75706, Dec  7 2009, 18:45:15) 
[GCC 4.4.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 4//3
1
>>> -4//3
-2

The algorithm seems to use floor, not integral part. Is this correct, according to the (math) definition of integer division?


Denis
________________________________

vit esse estrany ?

spir.wikidot.com


From pyideas at rebertia.com  Fri May  7 09:38:49 2010
From: pyideas at rebertia.com (Chris Rebert)
Date: Fri, 7 May 2010 00:38:49 -0700
Subject: [Python-ideas] integer dividion in R
In-Reply-To: <20100507092842.18bc6532@o>
References: <20100507092842.18bc6532@o>
Message-ID: <r2x50697b2c1005070038yd23940dcr1df80fbcb7464557@mail.gmail.com>

2010/5/7 spir ? <denis.spir at gmail.com>:
> Hello,
>
>
> The following point came up on the python-tutor mailing list:
>
> spir at o:~$ python
> Python 2.6.4 (r264:75706, Dec ?7 2009, 18:45:15)
> [GCC 4.4.1] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
>>>> 4//3
> 1
>>>> -4//3
> -2
>
> The algorithm seems to use floor, not integral part. Is this correct, according to the (math) definition of integer division?

There was *literally* just a thread about essentially the same thing:
http://mail.python.org/pipermail/python-ideas/2010-May/007170.html

Short answer: Yes, because there are multiple valid ways to define
integer quotient and modulo.

Cheers,
Chris
--
http://blog.rebertia.com


From denis.spir at gmail.com  Fri May  7 09:57:51 2010
From: denis.spir at gmail.com (spir =?UTF-8?B?4pij?=)
Date: Fri, 7 May 2010 09:57:51 +0200
Subject: [Python-ideas] integer dividion in R -- PS
Message-ID: <20100507095751.6e617b39@o>

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_dans_les_entiers_relatifs:
    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


From contact at xavierho.com  Fri May  7 10:19:05 2010
From: contact at xavierho.com (Xavier Ho)
Date: Fri, 7 May 2010 18:19:05 +1000
Subject: [Python-ideas] integer dividion in R -- PS
In-Reply-To: <20100507095751.6e617b39@o>
References: <20100507095751.6e617b39@o>
Message-ID: <t2x2d56febf1005070119x36c7e7f7v5627a381c36dd317@mail.gmail.com>

2010/5/7 spir ? <denis.spir at gmail.com>

> 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
>

I believe the official decision relates to PEP 238:

http://www.python.org/dev/peps/pep-0238/

And Guido was one of the authors of the PEP, so the chances are it won't be
changed for a long time.

Cheers,
Xav

(PS: Yes, I prefer C's integer division, where it's always rounded towards 0
(truncation), not just a straight floor.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20100507/3ce2c82b/attachment.html>

From dickinsm at gmail.com  Fri May  7 11:43:20 2010
From: dickinsm at gmail.com (Mark Dickinson)
Date: Fri, 7 May 2010 10:43:20 +0100
Subject: [Python-ideas] integer dividion in R -- PS
In-Reply-To: <t2x2d56febf1005070119x36c7e7f7v5627a381c36dd317@mail.gmail.com>
References: <20100507095751.6e617b39@o>
	<t2x2d56febf1005070119x36c7e7f7v5627a381c36dd317@mail.gmail.com>
Message-ID: <AANLkTikMPUWt4IlJMFNMjCfDSWmPPsIUPA01x2-60bxH@mail.gmail.com>

On Fri, May 7, 2010 at 9:19 AM, Xavier Ho <contact at xavierho.com> wrote:
> 2010/5/7 spir ? <denis.spir at gmail.com>
>>
>> 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
>
> I believe the official decision relates to PEP 238:

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)...
[...]


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.

-- 
Mark


From contact at xavierho.com  Fri May  7 11:50:10 2010
From: contact at xavierho.com (Xavier Ho)
Date: Fri, 7 May 2010 19:50:10 +1000
Subject: [Python-ideas] integer dividion in R -- PS
In-Reply-To: <v2u2d56febf1005070249s8b25e169hdf4cd9b6fc2a81e9@mail.gmail.com>
References: <20100507095751.6e617b39@o>
	<t2x2d56febf1005070119x36c7e7f7v5627a381c36dd317@mail.gmail.com>
	<AANLkTikMPUWt4IlJMFNMjCfDSWmPPsIUPA01x2-60bxH@mail.gmail.com> 
	<v2u2d56febf1005070249s8b25e169hdf4cd9b6fc2a81e9@mail.gmail.com>
Message-ID: <z2g2d56febf1005070250o7724e8f7z947c9a9c672e2171@mail.gmail.com>

On Fri, May 7, 2010 at 7:43 PM, Mark Dickinson <dickinsm at 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.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20100507/25a3cfa0/attachment.html>

From ncoghlan at gmail.com  Fri May  7 12:10:41 2010
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Fri, 07 May 2010 20:10:41 +1000
Subject: [Python-ideas] integer dividion in R -- PS
In-Reply-To: <z2g2d56febf1005070250o7724e8f7z947c9a9c672e2171@mail.gmail.com>
References: <20100507095751.6e617b39@o>	<t2x2d56febf1005070119x36c7e7f7v5627a381c36dd317@mail.gmail.com>	<AANLkTikMPUWt4IlJMFNMjCfDSWmPPsIUPA01x2-60bxH@mail.gmail.com>
	<v2u2d56febf1005070249s8b25e169hdf4cd9b6fc2a81e9@mail.gmail.com>
	<z2g2d56febf1005070250o7724e8f7z947c9a9c672e2171@mail.gmail.com>
Message-ID: <4BE3E721.6050204@gmail.com>

Xavier Ho wrote:
>     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.

For Python, Mark (and others) write code like that so the rest of us
don't have to ;)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------


From dickinsm at gmail.com  Fri May  7 12:34:22 2010
From: dickinsm at gmail.com (Mark Dickinson)
Date: Fri, 7 May 2010 11:34:22 +0100
Subject: [Python-ideas] integer dividion in R -- PS
In-Reply-To: <z2g2d56febf1005070250o7724e8f7z947c9a9c672e2171@mail.gmail.com>
References: <20100507095751.6e617b39@o>
	<t2x2d56febf1005070119x36c7e7f7v5627a381c36dd317@mail.gmail.com>
	<AANLkTikMPUWt4IlJMFNMjCfDSWmPPsIUPA01x2-60bxH@mail.gmail.com>
	<v2u2d56febf1005070249s8b25e169hdf4cd9b6fc2a81e9@mail.gmail.com>
	<z2g2d56febf1005070250o7724e8f7z947c9a9c672e2171@mail.gmail.com>
Message-ID: <AANLkTinz_3S8LVrSjoM-dspqVyl2hdYeVjmef-tpxAO7@mail.gmail.com>

On Fri, May 7, 2010 at 10:50 AM, Xavier Ho <contact at xavierho.com> wrote:
> On Fri, May 7, 2010 at 7:43 PM, Mark Dickinson <dickinsm at gmail.com> wrote:
>> ? ? ? ?e = e >= 0 ? e % _PyHASH_BITS : _PyHASH_BITS-1-((-1-e) % _PyHASH_BITS);
>
> Wow. I would never write code like that, but you got a fair point.

Yes, sorry.  I didn't claim it was *good* code.  :)  It would probably
be better expressed as a macro, or as a function with the expectation
that the compiler would inline it.

Mark


From jason.orendorff at gmail.com  Fri May  7 16:20:14 2010
From: jason.orendorff at gmail.com (Jason Orendorff)
Date: Fri, 7 May 2010 09:20:14 -0500
Subject: [Python-ideas] integer dividion in R -- PS
In-Reply-To: <20100507095751.6e617b39@o>
References: <20100507095751.6e617b39@o>
Message-ID: <u2tbb8868b91005070720zaab01647jeeaceb44c95ab71f@mail.gmail.com>

2010/5/7 spir ? <denis.spir at gmail.com>:
> I searched the def of int division in R. I could not find it in the english wikipedia,

On page 4 of Gallian, "Contemporary Abstract Algebra", we have:

    Division Algorithm

    Let a and b be integers with b > 0. Then there exist unique
    integers q and r with the property that a = bq + r where
    0 <= r < b.

This is, of course, the definition Python uses. I think this is pretty
standard. What might mathematicians like about this definition? Well,
I think the fundamentally important thing about integer division (or
any mathematical object really) is the patterns it makes:

    >>> [a % 5 for a in range(20)]
    [0, 1, 2, 3, 4, 0, 1, 2, 3, 4, 0, 1, 2, 3, 4, 0, 1, 2, 3, 4]
    >>> [a // 5 for a in range(20)]
    [0, 0, 0, 0, 0, 1, 1, 1, 1, 1, 2, 2, 2, 2, 2, 3, 3, 3, 3, 3]

Those patterns show up in both C and Python. Do the patterns continue
as you go into the negative numbers? In Python they do:

    >>> [a % 5 for a in range(-10, 10)]
    [0, 1, 2, 3, 4, 0, 1, 2, 3, 4, 0, 1, 2, 3, 4, 0, 1, 2, 3, 4]
    >>> [a // 5 for a in range(-10, 10)]
    [-2, -2, -2, -2, -2, -1, -1, -1, -1, -1, 0, 0, 0, 0, 0, 1, 1, 1, 1, 1]

In C, the patterns change as you pass 0.

That is, the Python definition satisfies these mathematical
properties, and the C definition doesn't:

    (a + b) // b == a // b + 1
    (a + b) % b == a % b

The Python definition agrees with modulo arithmetic:

    -3 ? 2  (mod 5)
    http://en.wikipedia.org/wiki/Modular_arithmetic

In Python, -3 % 5 == 2 % 5 is true. In C it is false.

> But: that   -4/3 != -(4/3)   looks simply wrong for me.

You can either have the mirror symmetry about 0 that you want, or you
can have the translational symmetry shown above. I think translational
symmetry is the defining thing about integer division and therefore
more important.

Of course for a programming language the question of which definition
to use is a practical one: which is more useful? Ultimately
practicality beats purity. But as far as purity goes (and it goes
along with practicality a good long way) I think Python's integer
division wins by a wide margin.

Cheers,
-j


From rob.cliffe at btinternet.com  Fri May  7 17:10:38 2010
From: rob.cliffe at btinternet.com (Rob Cliffe)
Date: Fri, 7 May 2010 16:10:38 +0100
Subject: [Python-ideas] integer dividion in R -- PS
References: <20100507095751.6e617b39@o>
	<u2tbb8868b91005070720zaab01647jeeaceb44c95ab71f@mail.gmail.com>
Message-ID: <C4CFF3CEAF1842F68A8C96024B59B6B4@robslaptop>

If I can diffidently put myself forward as a mathematician of sorts (not a 
professional one):

I agree with everything that Jason says here.

Mathematics is the study of abstract patterns.  (No doubt, this is not an 
original observation.)

Rob Cliffe

----- Original Message ----- 
From: "Jason Orendorff" <jason.orendorff at gmail.com>
To: "spir ?" <denis.spir at gmail.com>
Cc: "python ideas" <python-ideas at python.org>
Sent: Friday, May 07, 2010 3:20 PM
Subject: Re: [Python-ideas] integer dividion in R -- PS


> 2010/5/7 spir ? <denis.spir at gmail.com>:
>> I searched the def of int division in R. I could not find it in the 
>> english wikipedia,
>
> On page 4 of Gallian, "Contemporary Abstract Algebra", we have:
>
>    Division Algorithm
>
>    Let a and b be integers with b > 0. Then there exist unique
>    integers q and r with the property that a = bq + r where
>    0 <= r < b.
>
> This is, of course, the definition Python uses. I think this is pretty
> standard. What might mathematicians like about this definition? Well,
> I think the fundamentally important thing about integer division (or
> any mathematical object really) is the patterns it makes:
>
>    >>> [a % 5 for a in range(20)]
>    [0, 1, 2, 3, 4, 0, 1, 2, 3, 4, 0, 1, 2, 3, 4, 0, 1, 2, 3, 4]
>    >>> [a // 5 for a in range(20)]
>    [0, 0, 0, 0, 0, 1, 1, 1, 1, 1, 2, 2, 2, 2, 2, 3, 3, 3, 3, 3]
>
> Those patterns show up in both C and Python. Do the patterns continue
> as you go into the negative numbers? In Python they do:
>
>    >>> [a % 5 for a in range(-10, 10)]
>    [0, 1, 2, 3, 4, 0, 1, 2, 3, 4, 0, 1, 2, 3, 4, 0, 1, 2, 3, 4]
>    >>> [a // 5 for a in range(-10, 10)]
>    [-2, -2, -2, -2, -2, -1, -1, -1, -1, -1, 0, 0, 0, 0, 0, 1, 1, 1, 1, 1]
>
> In C, the patterns change as you pass 0.
>
> That is, the Python definition satisfies these mathematical
> properties, and the C definition doesn't:
>
>    (a + b) // b == a // b + 1
>    (a + b) % b == a % b
>
> The Python definition agrees with modulo arithmetic:
>
>    -3 ? 2  (mod 5)
>    http://en.wikipedia.org/wiki/Modular_arithmetic
>
> In Python, -3 % 5 == 2 % 5 is true. In C it is false.
>
>> But: that   -4/3 != -(4/3)   looks simply wrong for me.
>
> You can either have the mirror symmetry about 0 that you want, or you
> can have the translational symmetry shown above. I think translational
> symmetry is the defining thing about integer division and therefore
> more important.
>
> Of course for a programming language the question of which definition
> to use is a practical one: which is more useful? Ultimately
> practicality beats purity. But as far as purity goes (and it goes
> along with practicality a good long way) I think Python's integer
> division wins by a wide margin.
>
> Cheers,
> -j
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
> 



From brett at python.org  Fri May  7 20:46:39 2010
From: brett at python.org (Brett Cannon)
Date: Fri, 7 May 2010 11:46:39 -0700
Subject: [Python-ideas] division oddness
In-Reply-To: <4BE3623E.5000900@gmx.net>
References: <4BE3623E.5000900@gmx.net>
Message-ID: <t2lbbaeab101005071146g4cd9a6e8p7782cc0ecc4f6df2@mail.gmail.com>

On Thu, May 6, 2010 at 17:43, Mathias Panzenb?ck <
grosser.meister.morti at gmx.net> wrote:

> 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?
>

Operator precedence; unary negation (the 'factor' rule from Grammar/Grammar)
binds more tightly than // (the 'term' rule), thus applying the negation to
'2' before applying the '//'. Making it bind as `-(x // y)` would require
introducing a special grammar rule just to make sure that unary negation on
binary operators like this worked this way. And I am not even sure if that
would be unambiguous in Python's LL(1) grammar.

-Brett


>
>        -panzi
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20100507/38778903/attachment.html>

From gruszczy at gmail.com  Mon May 10 01:50:47 2010
From: gruszczy at gmail.com (=?UTF-8?Q?Filip_Gruszczy=C5=84ski?=)
Date: Mon, 10 May 2010 01:50:47 +0200
Subject: [Python-ideas] Making Python more enterprise technology
Message-ID: <AANLkTilLViCpbzfuLdV3ZaeblchEQ5-0JWT1qpSMRZCQ@mail.gmail.com>

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


From digitalxero at gmail.com  Mon May 10 01:57:07 2010
From: digitalxero at gmail.com (Dj Gilcrease)
Date: Sun, 9 May 2010 19:57:07 -0400
Subject: [Python-ideas] Making Python more enterprise technology
In-Reply-To: <AANLkTilLViCpbzfuLdV3ZaeblchEQ5-0JWT1qpSMRZCQ@mail.gmail.com>
References: <AANLkTilLViCpbzfuLdV3ZaeblchEQ5-0JWT1qpSMRZCQ@mail.gmail.com>
Message-ID: <x2ne9764b731005091657hd8ecdf53x8a2af538cf1265fc@mail.gmail.com>

2010/5/9 Filip Gruszczy?ski <gruszczy at gmail.com>:
> 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?

The only thing lacking from Python / Django to make it "Enterprise
Ready" is an SLA (Service Level Agreement) that said enterprise
company can pay 200k/y for that gets them nothing.

Both Java and .Net have SLAs companies can pay for that lets them call
and bitch about bugs, and an Account Manager on the other end that
knows how to make pissed off corporate bigwigs happy without giving
them anything.


From gruszczy at gmail.com  Mon May 10 02:02:13 2010
From: gruszczy at gmail.com (=?UTF-8?Q?Filip_Gruszczy=C5=84ski?=)
Date: Mon, 10 May 2010 02:02:13 +0200
Subject: [Python-ideas] Making Python more enterprise technology
In-Reply-To: <x2ne9764b731005091657hd8ecdf53x8a2af538cf1265fc@mail.gmail.com>
References: <AANLkTilLViCpbzfuLdV3ZaeblchEQ5-0JWT1qpSMRZCQ@mail.gmail.com> 
	<x2ne9764b731005091657hd8ecdf53x8a2af538cf1265fc@mail.gmail.com>
Message-ID: <AANLkTilK1yOao-C-JzHmDVTd1E-ZCpreWjympsWC9wWd@mail.gmail.com>

In other words in your opinion Python needs a group of associated
companies, that would provide additional support? Isn't that just a
cool idea for a bussiness ;-)?

-- 
Filip Gruszczy?ski


From digitalxero at gmail.com  Mon May 10 02:38:25 2010
From: digitalxero at gmail.com (Dj Gilcrease)
Date: Sun, 9 May 2010 20:38:25 -0400
Subject: [Python-ideas] Making Python more enterprise technology
In-Reply-To: <AANLkTilK1yOao-C-JzHmDVTd1E-ZCpreWjympsWC9wWd@mail.gmail.com>
References: <AANLkTilLViCpbzfuLdV3ZaeblchEQ5-0JWT1qpSMRZCQ@mail.gmail.com> 
	<x2ne9764b731005091657hd8ecdf53x8a2af538cf1265fc@mail.gmail.com> 
	<AANLkTilK1yOao-C-JzHmDVTd1E-ZCpreWjympsWC9wWd@mail.gmail.com>
Message-ID: <s2ue9764b731005091738h95d9a3baj3a3312827be2639@mail.gmail.com>

2010/5/9 Filip Gruszczy?ski <gruszczy at gmail.com>:
> In other words in your opinion Python needs a group of associated
> companies, that would provide additional support? Isn't that just a
> cool idea for a bussiness ;-)?

Yes, but since neither python nor django have corporate entities
behind them any company providing an SLA would be viewed as suspect by
"enterprise" companies. The SLAs would need to be directly with the
Python Software Foundation and the Django Foundation to be accepted as
those are the closest things to corporate entities behind the
software.

That is the other main reason Java & .Net are viewed as "Enterprise
Ready", they have a large corporation behind their development. So
there is someone with deep pockets for the "enterprise" company to sue
if they feel their SLA has been violated.


If you had not guessed the term "Enterprise Ready" is just laughable
to me. Any programing language that solves the problem with a minimum
amount of effort is "Enterprise Ready". For frameworks and tools to be
"Enterprise Ready" the only qualifications I need are, 1) It is not in
beta (does not need to be a 1.0+ release though) 2) Active development
is still on going 3) They have some form of support where I can ask
questions and find work arounds / fixes to issues I come across.

One company I worked for used the Remedy ticketing system over a free
open source system only because they could pay 200k/y and have a
support engineer on the phone within 4 hours of reporting a problem /
asking a question. What really dove the point home to me that the
"Enterprise Ready" stamp on the software was a joke was when I was
developing a front end to the Remedy SOAP interface I found a bug in
which a comment fields delimiters were sent as invalid XML. Spent 6
hours on the phone & remote desktop with their engineer who finally
admitted it was a bug, but told us "We wont fix that, you need to wait
a few months and buy our new "X.0" version which will have that
fixed". The new "X.0" version would cost an additional 50k to upgrade
to and an extra 30k/y for the SLA.


That isnt to say SLAs are all bad, but the marketing hype around the
term "Enterprise Ready" is. What the term means to me is "This
software should work, but if it doent do quite what you want tough
luck cause we only support it in xyz configuration. If it does not
work in xyz configuration feel free to call 800-dont-care and we will
listen to your issue and may provide a work around. If it is a real
bug thank you for reporting it, the fix will be in our next major
release that you can pay to upgrade to"


From jimjjewett at gmail.com  Mon May 10 05:28:59 2010
From: jimjjewett at gmail.com (Jim Jewett)
Date: Sun, 9 May 2010 23:28:59 -0400
Subject: [Python-ideas] Making Python more enterprise technology
In-Reply-To: <x2ne9764b731005091657hd8ecdf53x8a2af538cf1265fc@mail.gmail.com>
References: <AANLkTilLViCpbzfuLdV3ZaeblchEQ5-0JWT1qpSMRZCQ@mail.gmail.com> 
	<x2ne9764b731005091657hd8ecdf53x8a2af538cf1265fc@mail.gmail.com>
Message-ID: <AANLkTinvzR9xbQQyjPfgzKqaFWfzfjmSeofckjHVBG6S@mail.gmail.com>

2010/5/9 Dj Gilcrease <digitalxero at gmail.com>:
> 2010/5/9 Filip Gruszczy?ski <gruszczy at gmail.com>:
>> For some reason Python seems not to be seen as an enterprise
>> technology unlike Java or .net. ... What Python is lacking?

> The only thing lacking from Python / Django to make it "Enterprise
> Ready" is an SLA (Service Level Agreement) that said enterprise
> company can pay 200k/y for that gets them nothing.

There are also some dynamic/security tradeoffs that BigCorp would make
differently.  In python, I can reset the values of sys.*, and it will
affect other programs running on the same virtual machine.  There
isn't really any good way to detect (let alone prevent) this.  [Err,
unless you count running different processes on different virtual
machines, which is what they already do in for Java *in practice*, but
... somehow it isn't acceptable to rely on that.]

-jJ


From dangyogi at gmail.com  Mon May 10 15:44:55 2010
From: dangyogi at gmail.com (Bruce Frederiksen)
Date: Mon, 10 May 2010 09:44:55 -0400
Subject: [Python-ideas] Making Python more enterprise technology
In-Reply-To: <AANLkTinvzR9xbQQyjPfgzKqaFWfzfjmSeofckjHVBG6S@mail.gmail.com>
References: <AANLkTilLViCpbzfuLdV3ZaeblchEQ5-0JWT1qpSMRZCQ@mail.gmail.com>
	<x2ne9764b731005091657hd8ecdf53x8a2af538cf1265fc@mail.gmail.com>
	<AANLkTinvzR9xbQQyjPfgzKqaFWfzfjmSeofckjHVBG6S@mail.gmail.com>
Message-ID: <AANLkTimnJhC_6lpWejlcEmCe8YJCMLCTnPm27cIHCIG1@mail.gmail.com>

On Sun, May 9, 2010 at 11:28 PM, Jim Jewett <jimjjewett at gmail.com> wrote:

> [...]  In python, I can reset the values of sys.*, and it will
> affect other programs running on the same virtual machine.
>

I'm a bit confused by what you are trying to say.

By "virtual machine", do you mean the python byte code interpretor?  But
generally each instance of the python virtual machine only runs one program.

Or, by "virtual machine" do you mean the kvm/vmware sort of thing?  But if
so, what mechanism are you thinking is used to reset these values?  Patching
a file in the python library directory?

-Bruce
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20100510/e4f704bd/attachment.html>

From jimjjewett at gmail.com  Mon May 10 16:04:22 2010
From: jimjjewett at gmail.com (Jim Jewett)
Date: Mon, 10 May 2010 10:04:22 -0400
Subject: [Python-ideas] Making Python more enterprise technology
In-Reply-To: <AANLkTimnJhC_6lpWejlcEmCe8YJCMLCTnPm27cIHCIG1@mail.gmail.com>
References: <AANLkTilLViCpbzfuLdV3ZaeblchEQ5-0JWT1qpSMRZCQ@mail.gmail.com> 
	<x2ne9764b731005091657hd8ecdf53x8a2af538cf1265fc@mail.gmail.com> 
	<AANLkTinvzR9xbQQyjPfgzKqaFWfzfjmSeofckjHVBG6S@mail.gmail.com> 
	<AANLkTimnJhC_6lpWejlcEmCe8YJCMLCTnPm27cIHCIG1@mail.gmail.com>
Message-ID: <AANLkTild2i_a9mJHU_Xa7BFkLMOACCVJGE3aDF0clYMk@mail.gmail.com>

On Mon, May 10, 2010 at 9:44 AM, Bruce Frederiksen <dangyogi at gmail.com> wrote:
> On Sun, May 9, 2010 at 11:28 PM, Jim Jewett <jimjjewett at gmail.com> wrote:

>> [...]? In python, I can reset the values of sys.*, and it will
>> affect other programs running on the same virtual machine.

> I'm a bit confused by what you are trying to say.

> By "virtual machine", do you mean the python byte code interpretor?

Yes.

> But generally each instance of the python virtual machine only
> runs one program.

"Not done in practice" isn't a sufficiently strong argument to get a
new infrastructure technology past an architectural board.  (A single
product which happens to use or embed python, yes.  Approval of python
for developing new internal products, no.)

> ... what mechanism are you thinking is used to reset these values?
> Patching a file in the python library directory?

That would be a problem, but probably acceptable.

The real concern is that running code can, for example, change the
value of sys.stdout, and other programs will see that newly modified
value.

And, again, the fact that they wouldn't normally be running in the
same process anyhow doesn't seem to be sufficient answer.  In some
ways, this is just a FUD argument, but ... monkeypatching really *is*
a pain for various audits and separations of authority.  A variant to
the python module type that prevents monkeypatching (and using that
variant for the builtin libraries) might make some difference.

-jJ


From digitalxero at gmail.com  Mon May 10 16:29:20 2010
From: digitalxero at gmail.com (Dj Gilcrease)
Date: Mon, 10 May 2010 10:29:20 -0400
Subject: [Python-ideas] Making Python more enterprise technology
In-Reply-To: <AANLkTild2i_a9mJHU_Xa7BFkLMOACCVJGE3aDF0clYMk@mail.gmail.com>
References: <AANLkTilLViCpbzfuLdV3ZaeblchEQ5-0JWT1qpSMRZCQ@mail.gmail.com> 
	<x2ne9764b731005091657hd8ecdf53x8a2af538cf1265fc@mail.gmail.com> 
	<AANLkTinvzR9xbQQyjPfgzKqaFWfzfjmSeofckjHVBG6S@mail.gmail.com> 
	<AANLkTimnJhC_6lpWejlcEmCe8YJCMLCTnPm27cIHCIG1@mail.gmail.com> 
	<AANLkTild2i_a9mJHU_Xa7BFkLMOACCVJGE3aDF0clYMk@mail.gmail.com>
Message-ID: <AANLkTinGoT--kjtF7ttgDF0zkIFk8piDae7W0llOHCHL@mail.gmail.com>

On Mon, May 10, 2010 at 10:04 AM, Jim Jewett <jimjjewett at gmail.com> wrote:
> The real concern is that running code can, for example, change the
> value of sys.stdout, and other programs will see that newly modified
> value.

No, no they wouldn't. It is not possible to run multiple python apps
in a single process, unless you write your own process that is
importing all these apps and running them in some way.

>
> And, again, the fact that they wouldn't normally be running in the
> same process anyhow doesn't seem to be sufficient answer. ?In some
> ways, this is just a FUD argument, but ... monkeypatching really *is*
> a pain for various audits and separations of authority. ?A variant to
> the python module type that prevents monkeypatching (and using that
> variant for the builtin libraries) might make some difference.

Monkeypatching only ever affects your application instance since other
applications are in other python processes there is no overlap or code
contamination.


From jimjjewett at gmail.com  Mon May 10 16:43:55 2010
From: jimjjewett at gmail.com (Jim Jewett)
Date: Mon, 10 May 2010 10:43:55 -0400
Subject: [Python-ideas] Making Python more enterprise technology
In-Reply-To: <AANLkTinGoT--kjtF7ttgDF0zkIFk8piDae7W0llOHCHL@mail.gmail.com>
References: <AANLkTilLViCpbzfuLdV3ZaeblchEQ5-0JWT1qpSMRZCQ@mail.gmail.com> 
	<x2ne9764b731005091657hd8ecdf53x8a2af538cf1265fc@mail.gmail.com> 
	<AANLkTinvzR9xbQQyjPfgzKqaFWfzfjmSeofckjHVBG6S@mail.gmail.com> 
	<AANLkTimnJhC_6lpWejlcEmCe8YJCMLCTnPm27cIHCIG1@mail.gmail.com> 
	<AANLkTild2i_a9mJHU_Xa7BFkLMOACCVJGE3aDF0clYMk@mail.gmail.com> 
	<AANLkTinGoT--kjtF7ttgDF0zkIFk8piDae7W0llOHCHL@mail.gmail.com>
Message-ID: <AANLkTilV_rlwbaWwwsCeVt8yLv8CKR3zNWTlSaIZ0Bof@mail.gmail.com>

On Mon, May 10, 2010 at 10:29 AM, Dj Gilcrease <digitalxero at gmail.com> wrote:
> On Mon, May 10, 2010 at 10:04 AM, Jim Jewett <jimjjewett at gmail.com> wrote:
>> The real concern is that running code can, for example, change the
>> value of sys.stdout, and other programs will see that newly modified
>> value.

> No, no they wouldn't. It is not possible to run multiple python apps
> in a single process, unless you write your own process that is
> importing all these apps and running them in some way.

For example, (the python equivalent of) a web server with multiple
different cgi scripts.  If you say each applet should use its own
python process, then the architecture board will scream about resource
hogging and startup latency, even though that probably is what they do
now for both Perl and Java.

>> And, again, the fact that they wouldn't normally be running in the
>> same process anyhow doesn't seem to be sufficient answer. ?In some
>> ways, this is just a FUD argument, but ... monkeypatching really *is*
>> a pain for various audits and separations of authority. ?A variant to
>> the python module type that prevents monkeypatching (and using that
>> variant for the builtin libraries) might make some difference.

> Monkeypatching only ever affects your application instance since other
> applications are in other python processes there is no overlap or code
> contamination.

Even if that guarantee were acceptable (but see above), the answer
wouldn't be.  You can't tell from file1 that file2 has monkey-patched
something they both use.  You can't tell that an upgrade to
third-party library foo won't monkey-patch it differently.

Yes, this is true in practice with Java and factories, and you can't
really audit closed-source anyhow, and ... in the end, it doesn't
matter.  Change is scary, so python (or any new infrastructure
technology) has to at least be able to get things right, even when, in
practice,  Java and Perl (or any incumbent technology) do not need to.

-jJ


From wuwei23 at gmail.com  Tue May 11 02:28:35 2010
From: wuwei23 at gmail.com (alex23)
Date: Mon, 10 May 2010 17:28:35 -0700 (PDT)
Subject: [Python-ideas] Making Python more enterprise technology
In-Reply-To: <AANLkTild2i_a9mJHU_Xa7BFkLMOACCVJGE3aDF0clYMk@mail.gmail.com>
References: <AANLkTilLViCpbzfuLdV3ZaeblchEQ5-0JWT1qpSMRZCQ@mail.gmail.com> 
	<x2ne9764b731005091657hd8ecdf53x8a2af538cf1265fc@mail.gmail.com> 
	<AANLkTinvzR9xbQQyjPfgzKqaFWfzfjmSeofckjHVBG6S@mail.gmail.com> 
	<AANLkTimnJhC_6lpWejlcEmCe8YJCMLCTnPm27cIHCIG1@mail.gmail.com> 
	<AANLkTild2i_a9mJHU_Xa7BFkLMOACCVJGE3aDF0clYMk@mail.gmail.com>
Message-ID: <65705a8e-35d7-4532-bea5-30b5236106a2@h20g2000prn.googlegroups.com>

Jim Jewett <jimjjew... at gmail.com> wrote:
> "Not done in practice" isn't a sufficiently strong argument to get a
> new infrastructure technology past an architectural board. ?(A single
> product which happens to use or embed python, yes. ?Approval of python
> for developing new internal products, no.)

This is just nonsense. I've worked for enterprise orgs that use Python
to do exactly that. It's been a long term trend to move away from
discrete desktop apps and towards intranet-bound web apps instead.
Python is ideal for this use, and none of the security issues you're
citing apply.

> The real concern is that running code can, for example, change the
> value of sys.stdout, and other programs will see that newly modified
> value.

Pure, unmitigated FUD.


From stephen at xemacs.org  Tue May 11 08:36:43 2010
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Tue, 11 May 2010 15:36:43 +0900
Subject: [Python-ideas] Making Python more enterprise technology
In-Reply-To: <65705a8e-35d7-4532-bea5-30b5236106a2@h20g2000prn.googlegroups.com>
References: <AANLkTilLViCpbzfuLdV3ZaeblchEQ5-0JWT1qpSMRZCQ@mail.gmail.com>
	<x2ne9764b731005091657hd8ecdf53x8a2af538cf1265fc@mail.gmail.com>
	<AANLkTinvzR9xbQQyjPfgzKqaFWfzfjmSeofckjHVBG6S@mail.gmail.com>
	<AANLkTimnJhC_6lpWejlcEmCe8YJCMLCTnPm27cIHCIG1@mail.gmail.com>
	<AANLkTild2i_a9mJHU_Xa7BFkLMOACCVJGE3aDF0clYMk@mail.gmail.com>
	<65705a8e-35d7-4532-bea5-30b5236106a2@h20g2000prn.googlegroups.com>
Message-ID: <87tyqfq70k.fsf@uwakimon.sk.tsukuba.ac.jp>

alex23 writes:
 > Jim Jewett <jimjjew... at gmail.com> wrote:
 > > "Not done in practice" isn't a sufficiently strong argument to get a
 > > new infrastructure technology past an architectural board. ?(A single
 > > product which happens to use or embed python, yes. ?Approval of python
 > > for developing new internal products, no.)
 > 
 > This is just nonsense. [...]
 > 
 > > The real concern is that running code can, for example, change the
 > > value of sys.stdout, and other programs will see that newly modified
 > > value.
 > 
 > Pure, unmitigated FUD.

Jim didn't say it was *his* concern, just that he has so far been at
best partially successful in convincing people that it's no more an
issue for Python than for incumbent platforms.  That's the reality you
see in many places, and I don't see how you can blame people who work
in that kind of environment for hoping for a Pythonic solution to it.
Heaven knows, the *people* who run things aren't going to change!

If it's not practical to change those parts of Python, OK, education
of the bosses is all that's left.


From wuwei23 at gmail.com  Tue May 11 08:56:11 2010
From: wuwei23 at gmail.com (alex23)
Date: Mon, 10 May 2010 23:56:11 -0700 (PDT)
Subject: [Python-ideas] Making Python more enterprise technology
In-Reply-To: <87tyqfq70k.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <AANLkTilLViCpbzfuLdV3ZaeblchEQ5-0JWT1qpSMRZCQ@mail.gmail.com> 
	<x2ne9764b731005091657hd8ecdf53x8a2af538cf1265fc@mail.gmail.com> 
	<AANLkTinvzR9xbQQyjPfgzKqaFWfzfjmSeofckjHVBG6S@mail.gmail.com> 
	<AANLkTimnJhC_6lpWejlcEmCe8YJCMLCTnPm27cIHCIG1@mail.gmail.com> 
	<AANLkTild2i_a9mJHU_Xa7BFkLMOACCVJGE3aDF0clYMk@mail.gmail.com> 
	<65705a8e-35d7-4532-bea5-30b5236106a2@h20g2000prn.googlegroups.com> 
	<87tyqfq70k.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <106d43af-7096-44de-a66c-3d1df2bd1aee@y6g2000pra.googlegroups.com>

"Stephen J. Turnbull" <step... at xemacs.org> wrote:
> Jim didn't say it was *his* concern, just that he has so far been at
> best partially successful in convincing people that it's no more an
> issue for Python than for incumbent platforms. ?

Jim said:
> There are also some dynamic/security tradeoffs that BigCorp would make
> differently.  In python, I can reset the values of sys.*, and it will
> affect other programs running on the same virtual machine.

He doesn't say "my employers believe", he quite clearly states that
_he can modify sys.* and it will be picked up by other programs. The
fact that the Python interpreter _doesn't work that way_ he dismisses
as irrelevant shortly after, which I just cannot follow.

If anyone can show me how I can run one python program and have it
modify the sys.stdout of an existing running python process without
explicitly coding the latter to allow for it, please, I'd love to be
enlightened.


From stephen at xemacs.org  Tue May 11 09:35:45 2010
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Tue, 11 May 2010 16:35:45 +0900
Subject: [Python-ideas] Making Python more enterprise technology
In-Reply-To: <106d43af-7096-44de-a66c-3d1df2bd1aee@y6g2000pra.googlegroups.com>
References: <AANLkTilLViCpbzfuLdV3ZaeblchEQ5-0JWT1qpSMRZCQ@mail.gmail.com>
	<x2ne9764b731005091657hd8ecdf53x8a2af538cf1265fc@mail.gmail.com>
	<AANLkTinvzR9xbQQyjPfgzKqaFWfzfjmSeofckjHVBG6S@mail.gmail.com>
	<AANLkTimnJhC_6lpWejlcEmCe8YJCMLCTnPm27cIHCIG1@mail.gmail.com>
	<AANLkTild2i_a9mJHU_Xa7BFkLMOACCVJGE3aDF0clYMk@mail.gmail.com>
	<65705a8e-35d7-4532-bea5-30b5236106a2@h20g2000prn.googlegroups.com>
	<87tyqfq70k.fsf@uwakimon.sk.tsukuba.ac.jp>
	<106d43af-7096-44de-a66c-3d1df2bd1aee@y6g2000pra.googlegroups.com>
Message-ID: <87pr12rium.fsf@uwakimon.sk.tsukuba.ac.jp>

alex23 writes:

 > If anyone can show me how I can run one python program and have it
 > modify the sys.stdout of an existing running python process without
 > explicitly coding the latter to allow for it, please, I'd love to be
 > enlightened.

It's easiest to think outside the box of modifying internals of a
python process from outside.  Specifically (as already mentioned),
suppose the python process is a webserver, or a persistent CGI server,
or something like that.  Then people who write application modules for
that process think of their module as "the program", even though in
our reality they are just data (well, a library) for the real process.
That "program" is loaded into the process using "import" as usual, and
can modify sys.stdout simply by assigning to it.

What that means to the architecture board is that they are going to
have to write up some coding standards about globals, when you can
create them, when you can touch them, what you can do when you do mess
with them, what kind of cleanup is required, and how and where you
must document all of the above when you do it.  I'm not at all
surprised that they throw up their hands and say "no, thanks".



From ncoghlan at gmail.com  Tue May 11 14:37:19 2010
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 11 May 2010 22:37:19 +1000
Subject: [Python-ideas] Making Python more enterprise technology
In-Reply-To: <87pr12rium.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <AANLkTilLViCpbzfuLdV3ZaeblchEQ5-0JWT1qpSMRZCQ@mail.gmail.com>	<x2ne9764b731005091657hd8ecdf53x8a2af538cf1265fc@mail.gmail.com>	<AANLkTinvzR9xbQQyjPfgzKqaFWfzfjmSeofckjHVBG6S@mail.gmail.com>	<AANLkTimnJhC_6lpWejlcEmCe8YJCMLCTnPm27cIHCIG1@mail.gmail.com>	<AANLkTild2i_a9mJHU_Xa7BFkLMOACCVJGE3aDF0clYMk@mail.gmail.com>	<65705a8e-35d7-4532-bea5-30b5236106a2@h20g2000prn.googlegroups.com>	<87tyqfq70k.fsf@uwakimon.sk.tsukuba.ac.jp>	<106d43af-7096-44de-a66c-3d1df2bd1aee@y6g2000pra.googlegroups.com>
	<87pr12rium.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <4BE94F7F.7040802@gmail.com>

Stephen J. Turnbull wrote:
> What that means to the architecture board is that they are going to
> have to write up some coding standards about globals, when you can
> create them, when you can touch them, what you can do when you do mess
> with them, what kind of cleanup is required, and how and where you
> must document all of the above when you do it.  I'm not at all
> surprised that they throw up their hands and say "no, thanks".

It's also the reason AppEngine cuts out a bunch of things to make it
easier to keep apps under control:)

>From my experience, Python most effectively makes its way into
organisations the way Linux did originally: developers are able to get
approval to use it at a fairly low level because it doesn't cost
anything, the licensing is more than reasonable and it will get the job
done. Once it is in the door and being used for "support" tasks, it
slowly makes its way closer and closer to core internal business
applications (as different tasks come up, developers do initial
prototypes in Python to try out functionality, then ask the obvious
question "hey, how about we do the real thing in Python as well?").

Java and .NET have large organisations behind them with significant
marketing budgets pushing them as the programming platform du jour.
Python, like Linux before Red Hat started making money and the
enterprise server hardware vendors got involved, relies more on word of
mouth and unpaid advocacy.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------


From wuwei23 at gmail.com  Tue May 11 14:51:01 2010
From: wuwei23 at gmail.com (alex23)
Date: Tue, 11 May 2010 05:51:01 -0700 (PDT)
Subject: [Python-ideas] Making Python more enterprise technology
In-Reply-To: <87pr12rium.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <AANLkTilLViCpbzfuLdV3ZaeblchEQ5-0JWT1qpSMRZCQ@mail.gmail.com> 
	<x2ne9764b731005091657hd8ecdf53x8a2af538cf1265fc@mail.gmail.com> 
	<AANLkTinvzR9xbQQyjPfgzKqaFWfzfjmSeofckjHVBG6S@mail.gmail.com> 
	<AANLkTimnJhC_6lpWejlcEmCe8YJCMLCTnPm27cIHCIG1@mail.gmail.com> 
	<AANLkTild2i_a9mJHU_Xa7BFkLMOACCVJGE3aDF0clYMk@mail.gmail.com> 
	<65705a8e-35d7-4532-bea5-30b5236106a2@h20g2000prn.googlegroups.com> 
	<87tyqfq70k.fsf@uwakimon.sk.tsukuba.ac.jp>
	<106d43af-7096-44de-a66c-3d1df2bd1aee@y6g2000pra.googlegroups.com>
	<87pr12rium.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <21439434-8f83-4b01-8d8a-11b817ad6a37@h37g2000pra.googlegroups.com>

"Stephen J. Turnbull" <step... at xemacs.org> wrote:
> What that means to the architecture board is that they are going to
> have to write up some coding standards about globals, when you can
> create them, when you can touch them, what you can do when you do mess
> with them, what kind of cleanup is required, and how and where you
> must document all of the above when you do it. ?I'm not at all
> surprised that they throw up their hands and say "no, thanks".

...

So a fictional architecture board's imagined opinion somehow trumps
the actual concrete experience I've had with working with Python in an
enterprise environment?

Wow. Good luck with this thread. I'm not entirely sure what the point
of it is, but I'm sure you'll all come to some amazing conclusions by
the end of it.


From solipsis at pitrou.net  Tue May 11 15:06:37 2010
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Tue, 11 May 2010 15:06:37 +0200
Subject: [Python-ideas] Making Python more enterprise technology
References: <AANLkTilLViCpbzfuLdV3ZaeblchEQ5-0JWT1qpSMRZCQ@mail.gmail.com>
	<x2ne9764b731005091657hd8ecdf53x8a2af538cf1265fc@mail.gmail.com>
	<AANLkTinvzR9xbQQyjPfgzKqaFWfzfjmSeofckjHVBG6S@mail.gmail.com>
	<AANLkTimnJhC_6lpWejlcEmCe8YJCMLCTnPm27cIHCIG1@mail.gmail.com>
	<AANLkTild2i_a9mJHU_Xa7BFkLMOACCVJGE3aDF0clYMk@mail.gmail.com>
	<65705a8e-35d7-4532-bea5-30b5236106a2@h20g2000prn.googlegroups.com>
	<87tyqfq70k.fsf@uwakimon.sk.tsukuba.ac.jp>
	<106d43af-7096-44de-a66c-3d1df2bd1aee@y6g2000pra.googlegroups.com>
	<87pr12rium.fsf@uwakimon.sk.tsukuba.ac.jp>
	<4BE94F7F.7040802@gmail.com>
Message-ID: <20100511150637.55039a3b@pitrou.net>

On Tue, 11 May 2010 22:37:19 +1000
Nick Coghlan <ncoghlan at gmail.com> wrote:
> 
> From my experience, Python most effectively makes its way into
> organisations the way Linux did originally: developers are able to get
> approval to use it at a fairly low level because it doesn't cost
> anything, the licensing is more than reasonable and it will get the job
> done. Once it is in the door and being used for "support" tasks, it
> slowly makes its way closer and closer to core internal business
> applications (as different tasks come up, developers do initial
> prototypes in Python to try out functionality, then ask the obvious
> question "hey, how about we do the real thing in Python as well?").

My latest customer was a PHP and Java shop. I used Python for the work
I had to do, and recently I learnt that their IT department had started
hiring (or trying to hire) people with Python competences. That might
indicate they intend to invest more in Python.

Regards

Antoine.




From janssen at parc.com  Tue May 11 18:20:26 2010
From: janssen at parc.com (Bill Janssen)
Date: Tue, 11 May 2010 09:20:26 PDT
Subject: [Python-ideas] Making Python more enterprise technology
In-Reply-To: <AANLkTilV_rlwbaWwwsCeVt8yLv8CKR3zNWTlSaIZ0Bof@mail.gmail.com>
References: <AANLkTilLViCpbzfuLdV3ZaeblchEQ5-0JWT1qpSMRZCQ@mail.gmail.com>
	<x2ne9764b731005091657hd8ecdf53x8a2af538cf1265fc@mail.gmail.com>
	<AANLkTinvzR9xbQQyjPfgzKqaFWfzfjmSeofckjHVBG6S@mail.gmail.com>
	<AANLkTimnJhC_6lpWejlcEmCe8YJCMLCTnPm27cIHCIG1@mail.gmail.com>
	<AANLkTild2i_a9mJHU_Xa7BFkLMOACCVJGE3aDF0clYMk@mail.gmail.com>
	<AANLkTinGoT--kjtF7ttgDF0zkIFk8piDae7W0llOHCHL@mail.gmail.com>
	<AANLkTilV_rlwbaWwwsCeVt8yLv8CKR3zNWTlSaIZ0Bof@mail.gmail.com>
Message-ID: <56808.1273594826@parc.com>

Jim Jewett <jimjjewett at gmail.com> wrote:

> Change is scary, so python (or any new infrastructure
> technology) has to at least be able to get things right, even when, in
> practice,  Java and Perl (or any incumbent technology) do not need to.

Well, there's hope!  After all, Java and Perl somehow *became* incumbent
technologies.

Bill


From dstanek at dstanek.com  Tue May 11 19:30:51 2010
From: dstanek at dstanek.com (David Stanek)
Date: Tue, 11 May 2010 13:30:51 -0400
Subject: [Python-ideas] Making Python more enterprise technology
In-Reply-To: <AANLkTilLViCpbzfuLdV3ZaeblchEQ5-0JWT1qpSMRZCQ@mail.gmail.com>
References: <AANLkTilLViCpbzfuLdV3ZaeblchEQ5-0JWT1qpSMRZCQ@mail.gmail.com>
Message-ID: <AANLkTim8E3RJebh0aSpU6fbkAgyDmWKyntLhecJkDM6X@mail.gmail.com>

2010/5/9 Filip Gruszczy?ski <gruszczy at gmail.com>:
> 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?
>

I believe that marketing, or lack of, has played a big role in
Python's acceptance. Java and C# have a big advantage by being
promoted so heavily by large, well-known companies. When I talk to
people I know in the enterprise space they don't understand exactly
what Python is or what it can be.

The pointy haired managers know that in a pinch they can get Java/C#
guys because there are so many. Outsourcing (I personally don't like)
is also much easier  with Java/C#.

-- 
David
blog: http://www.traceback.org
twitter: http://twitter.com/dstanek


From list at qtrac.plus.com  Tue May 11 19:56:21 2010
From: list at qtrac.plus.com (Mark Summerfield)
Date: Tue, 11 May 2010 18:56:21 +0100
Subject: [Python-ideas] Making Python more enterprise technology
In-Reply-To: <AANLkTim8E3RJebh0aSpU6fbkAgyDmWKyntLhecJkDM6X@mail.gmail.com>
References: <AANLkTilLViCpbzfuLdV3ZaeblchEQ5-0JWT1qpSMRZCQ@mail.gmail.com>
	<AANLkTim8E3RJebh0aSpU6fbkAgyDmWKyntLhecJkDM6X@mail.gmail.com>
Message-ID: <201005111856.21571.list@qtrac.plus.com>

On 2010-05-11, David Stanek wrote:
> 2010/5/9 Filip Gruszczy?ski <gruszczy at gmail.com>:
> > 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?
> 
> I believe that marketing, or lack of, has played a big role in
> Python's acceptance. Java and C# have a big advantage by being
> promoted so heavily by large, well-known companies. When I talk to
> people I know in the enterprise space they don't understand exactly
> what Python is or what it can be.
> 
> The pointy haired managers know that in a pinch they can get Java/C#
> guys because there are so many. Outsourcing (I personally don't like)
> is also much easier  with Java/C#.

As far as I'm aware no big company specifically promoted or promotes C++
(apart from those selling commercial compilers & related tools), yet C++
is still very widely used. Naturally, C++'s C-compatibility has been a
big help, but most languages nowadays are C compatible (at least as far
as being able to access C functions inside C libraries, and this
includes Python of course).

I think that one of the big wins for C++ (and C) was ISO
standardization. Companies that use C++ know that they can get compliant
compilers which gives them long term confidence that C++ is safe to
invest in. (Of course Pascal is also standardized, and it hasn't helped
the language at all.)

Unfortunately, C++ has developed at a glacial pace in the last decade,
with a much too long gap between standards. (They are hoping to get the
gap down to five years _after_ the 2011 or 2012 standard is ratified!) 

If Python were to be standardized it would become much more visible and
a much safer corporate bet. Such a process wouldn't be easy and I doubt
anyone would want to update the standard too often.

One possible way would be to standardize one particular version, but not
the next two minor releases. For example, standardize 3.2, but not 3.3
or 3.4, then standardize 3.5, but not 3.6 or 3.7, and so on. This would
mean that the standardization effort would take place about every four
years (and which would only affect those involved in the standardization
process). There would however, be a cost to the development community:
maintaining the standardized version (e.g., bug & security fixes) until
it is superceded.

My 2c on "enterprise" Python;-)

-- 
Mark Summerfield, Qtrac Ltd, www.qtrac.eu
    C++, Python, Qt, PyQt - training and consultancy
        "Advanced Qt Programming" - ISBN 0321635906


From george.sakkis at gmail.com  Tue May 11 23:34:32 2010
From: george.sakkis at gmail.com (George Sakkis)
Date: Tue, 11 May 2010 23:34:32 +0200
Subject: [Python-ideas] Making Python more enterprise technology
In-Reply-To: <AANLkTilLViCpbzfuLdV3ZaeblchEQ5-0JWT1qpSMRZCQ@mail.gmail.com>
References: <AANLkTilLViCpbzfuLdV3ZaeblchEQ5-0JWT1qpSMRZCQ@mail.gmail.com>
Message-ID: <AANLkTin7qvqnkwOBbgJhZiXG0m8yEFocR6hg5ExygR__@mail.gmail.com>

Python is ready for the enterprise; the enterprise is not ready for Python ;-)

2010/5/10 Filip Gruszczy?ski <gruszczy at gmail.com>:
> 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
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>


From ncoghlan at gmail.com  Wed May 12 00:37:36 2010
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Wed, 12 May 2010 08:37:36 +1000
Subject: [Python-ideas] Making Python more enterprise technology
In-Reply-To: <201005111856.21571.list@qtrac.plus.com>
References: <AANLkTilLViCpbzfuLdV3ZaeblchEQ5-0JWT1qpSMRZCQ@mail.gmail.com>	<AANLkTim8E3RJebh0aSpU6fbkAgyDmWKyntLhecJkDM6X@mail.gmail.com>
	<201005111856.21571.list@qtrac.plus.com>
Message-ID: <4BE9DC30.9000303@gmail.com>

Mark Summerfield wrote:
> One possible way would be to standardize one particular version, but not
> the next two minor releases. For example, standardize 3.2, but not 3.3
> or 3.4, then standardize 3.5, but not 3.6 or 3.7, and so on. This would
> mean that the standardization effort would take place about every four
> years (and which would only affect those involved in the standardization
> process). There would however, be a cost to the development community:
> maintaining the standardized version (e.g., bug & security fixes) until
> it is superceded.

Someone could always decide to standardise Python 2.7 ;)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------


From stephen at xemacs.org  Wed May 12 05:13:15 2010
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Wed, 12 May 2010 12:13:15 +0900
Subject: [Python-ideas] Making Python more enterprise technology
In-Reply-To: <201005111856.21571.list@qtrac.plus.com>
References: <AANLkTilLViCpbzfuLdV3ZaeblchEQ5-0JWT1qpSMRZCQ@mail.gmail.com>
	<AANLkTim8E3RJebh0aSpU6fbkAgyDmWKyntLhecJkDM6X@mail.gmail.com>
	<201005111856.21571.list@qtrac.plus.com>
Message-ID: <87hbmdrewk.fsf@uwakimon.sk.tsukuba.ac.jp>

Mark Summerfield writes:

 > As far as I'm aware no big company specifically promoted or promotes C++

That's because the U.S. government dismembered it and in the process
kneecapped a national treasure.  :-P

 > If Python were to be [ISO] standardized it would become much more
 > visible and a much safer corporate bet.

Perl managed without it, and AFAIK there is no ISO or ANSI Java,
either (the #3 Google hit was "Sun Drops ISO Java Standards Effort For
Good" from 1999).  Admittedly, EMCAscript is there, but that came
afterward, pushed by enterprises that had already adopted Javascript,
and wanted to stop the Netscape vs. Microsoft whipsaw.

In fact, Python not only has an excellent standard, but it has
excellent testing of the standard, what with 4 major implementations
aiming for conformance IIUC, plus assorted near-implementations such
as Cython and Stackless.  I suspect that a well-run marketing campaign
by the PSF, starting by trademarking "Standard Python" and getting
some funding to set up a conformance testing certification program,
would do wonders at not such great expense.


From list at qtrac.plus.com  Wed May 12 08:03:00 2010
From: list at qtrac.plus.com (Mark Summerfield)
Date: Wed, 12 May 2010 07:03:00 +0100
Subject: [Python-ideas] Making Python more enterprise technology
In-Reply-To: <87hbmdrewk.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <AANLkTilLViCpbzfuLdV3ZaeblchEQ5-0JWT1qpSMRZCQ@mail.gmail.com>
	<201005111856.21571.list@qtrac.plus.com>
	<87hbmdrewk.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <201005120703.00321.list@qtrac.plus.com>

On 2010-05-12, Stephen J. Turnbull wrote:
> Mark Summerfield writes:
>  > As far as I'm aware no big company specifically promoted or promotes 
C++
> 
> That's because the U.S. government dismembered it and in the process
> kneecapped a national treasure.  :-P

Ah...
 
>  > If Python were to be [ISO] standardized it would become much more
>  > visible and a much safer corporate bet.
> 
> Perl managed without it, and AFAIK there is no ISO or ANSI Java,
> either (the #3 Google hit was "Sun Drops ISO Java Standards Effort For
> Good" from 1999).  Admittedly, EMCAscript is there, but that came
> afterward, pushed by enterprises that had already adopted Javascript,
> and wanted to stop the Netscape vs. Microsoft whipsaw.

True, and _what_ a language got specified!
 
> In fact, Python not only has an excellent standard, but it has
> excellent testing of the standard, what with 4 major implementations
> aiming for conformance IIUC, plus assorted near-implementations such
> as Cython and Stackless.  I suspect that a well-run marketing campaign
> by the PSF, starting by trademarking "Standard Python" and getting
> some funding to set up a conformance testing certification program,
> would do wonders at not such great expense.

I'm sure you're right, but I guess it would be quite an undertaking.

-- 
Mark Summerfield, Qtrac Ltd, www.qtrac.eu
    C++, Python, Qt, PyQt - training and consultancy
        "Programming in Python 3 (Second Edition)" - ISBN 0321680561


From stephen at xemacs.org  Wed May 12 09:56:12 2010
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Wed, 12 May 2010 16:56:12 +0900
Subject: [Python-ideas] Making Python more enterprise technology
In-Reply-To: <201005120703.00321.list@qtrac.plus.com>
References: <AANLkTilLViCpbzfuLdV3ZaeblchEQ5-0JWT1qpSMRZCQ@mail.gmail.com>
	<201005111856.21571.list@qtrac.plus.com>
	<87hbmdrewk.fsf@uwakimon.sk.tsukuba.ac.jp>
	<201005120703.00321.list@qtrac.plus.com>
Message-ID: <877hn9r1sz.fsf@uwakimon.sk.tsukuba.ac.jp>

Mark Summerfield writes:

 > On 2010-05-12, Stephen J. Turnbull wrote:

 > > In fact, Python not only has an excellent standard, but it has
 > > excellent testing of the standard, what with 4 major implementations
 > > aiming for conformance IIUC, plus assorted near-implementations such
 > > as Cython and Stackless.  I suspect that a well-run marketing campaign
 > > by the PSF, starting by trademarking "Standard Python" and getting
 > > some funding to set up a conformance testing certification program,
 > > would do wonders at not such great expense.
 > 
 > I'm sure you're right, but I guess it would be quite an undertaking.

I'm not at all sure I'm right<wink>, but the point is that it need not
be such a huge undertaking.  There are some governments out there who
might be willing to supply some funding, and perhaps some
consultancies might like to get into the certification game for fun
and profit.

It wouldn't be as big as deal as ISO, of course, but you get what you
pay for (even if it's just a fancier rubber stamp!)  OTOH, you might
attract the attention of an on-average smarter crowd of PHBs this way,
even if it's smaller than ISO certification would get.  That has its
advantages, too.


From jimjjewett at gmail.com  Wed May 12 15:52:55 2010
From: jimjjewett at gmail.com (Jim Jewett)
Date: Wed, 12 May 2010 09:52:55 -0400
Subject: [Python-ideas] Making Python more enterprise technology
In-Reply-To: <87hbmdrewk.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <AANLkTilLViCpbzfuLdV3ZaeblchEQ5-0JWT1qpSMRZCQ@mail.gmail.com> 
	<AANLkTim8E3RJebh0aSpU6fbkAgyDmWKyntLhecJkDM6X@mail.gmail.com> 
	<201005111856.21571.list@qtrac.plus.com>
	<87hbmdrewk.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <AANLkTikKXT5--kcNZ01AOGJQ4ChGgBISgFJPVfiQJS6a@mail.gmail.com>

On Tue, May 11, 2010 at 11:13 PM, Stephen J. Turnbull
<stephen at xemacs.org> wrote:
> Mark Summerfield writes:

> ?> If Python were to be [ISO] standardized it would become much more
> ?> visible and a much safer corporate bet.

> Perl managed without it, and AFAIK there is no ISO or ANSI Java,
> either (the #3 Google hit was "Sun Drops ISO Java Standards Effort For
> Good" from 1999). ?Admittedly, EMCAscript is there, but that came
> afterward, pushed by enterprises that had already adopted Javascript,
> and wanted to stop the Netscape vs. Microsoft whipsaw.

[Within BigCorp] In my experience, Perl does "suffer" for it -- it is
OK to admit that an application is already in written in Perl, and it
*may* be OK to keep it in Perl instead of translating it to Java, but
approval for a *new* application in Perl is non-trivial.

I've never seen approval for an application in ECMAScript.  I have
seen several approvals for projects in HTML, with the one-paragraph
expansion making it clear that this includes a smorgasbord of related
"standards".  These related standards always include JavaScript (only
rarely called ECMAScript), if anything is called out at all.  They
usually include CSS and XML.  In theory, python could slip in there,
but because it is a server side technology, it still triggers
questions on why the server isn't written in Java, or at least a
"Microsoft standard".

> In fact, Python not only has an excellent standard, but it has
> excellent testing of the standard, what with 4 major implementations
> aiming for conformance IIUC, plus assorted near-implementations such
> as Cython and Stackless. ?I suspect that a well-run marketing campaign
> by the PSF, starting by trademarking "Standard Python" and getting
> some funding to set up a conformance testing certification program,
> would do wonders at not such great expense.

My guess is that it still wouldn't be enough -- but I'm pretty
confident that it would indeed help.

-jJ


From andre.roberge at gmail.com  Sat May 15 16:02:35 2010
From: andre.roberge at gmail.com (Andre Roberge)
Date: Sat, 15 May 2010 11:02:35 -0300
Subject: [Python-ideas] i18n and Python tracebacks
Message-ID: <AANLkTinEr_HGMesvf2u7k5YOY8jQP1Ad45j-1_vf_3Gs@mail.gmail.com>

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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20100515/27c069f9/attachment.html>

From solipsis at pitrou.net  Sat May 15 17:04:29 2010
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sat, 15 May 2010 17:04:29 +0200
Subject: [Python-ideas] i18n and Python tracebacks
References: <AANLkTinEr_HGMesvf2u7k5YOY8jQP1Ad45j-1_vf_3Gs@mail.gmail.com>
Message-ID: <20100515170429.46c46dd7@pitrou.net>

On Sat, 15 May 2010 11:02:35 -0300
Andre Roberge <andre.roberge at 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.

(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)

Antoine.




From reingart at gmail.com  Sat May 15 17:05:32 2010
From: reingart at gmail.com (Mariano Reingart)
Date: Sat, 15 May 2010 12:05:32 -0300
Subject: [Python-ideas] i18n and Python tracebacks
In-Reply-To: <AANLkTinEr_HGMesvf2u7k5YOY8jQP1Ad45j-1_vf_3Gs@mail.gmail.com>
References: <AANLkTinEr_HGMesvf2u7k5YOY8jQP1Ad45j-1_vf_3Gs@mail.gmail.com>
Message-ID: <AANLkTimZILcMHTsY9me1h4rkKLnFhIrhNZbV3xaFsUaZ@mail.gmail.com>

On Sat, May 15, 2010 at 11:02 AM, Andre Roberge <andre.roberge at gmail.com> wrote:
> 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.

+1

In PyAr (Python Argentina) we are talking about this too:
http://mx.grulic.org.ar/lurker/message/20100513.021134.7443563e.es.html

It would be great if there would be a standard mechanism as PO for
message translation.
In that case, Pootle could be used to get a colaborative reviewed translation.

English is a important barrier in some cases, like teaching Python to
non-advanced users that in general don't read/speak english (in our
country, the language is spanish).

Allowing changing locale messages language at runtime may be interesting too
(like in PostgreSQL: SET lc_messages TO 'en_US.UTF-8'; )

> 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
>

In spanish a possible translation would be:

Traza de rastreo (llamada m?s reciente a lo ?ltimo):
 Archivo "<stdin>", l?nea 1, en <m?dulo>
ZeroDivisionError: divisi?n entera o m?dulo por cero


We are setting up a local wiki page trying to address this issues:

http://python.org.ar/pyar/MensajesExcepcionales


Best regards,

Mariano Reingart
http://www.python.org.ar
http://www.sistemasagiles.com.ar
http://reingart.blogspot.com


From andre.roberge at gmail.com  Sat May 15 17:14:34 2010
From: andre.roberge at gmail.com (Andre Roberge)
Date: Sat, 15 May 2010 12:14:34 -0300
Subject: [Python-ideas] Fwd:  i18n and Python tracebacks
In-Reply-To: <AANLkTimRjN0McQjngFpPI0AmknKqdLIzEQ-2Vp4RDqCI@mail.gmail.com>
References: <AANLkTinEr_HGMesvf2u7k5YOY8jQP1Ad45j-1_vf_3Gs@mail.gmail.com>
	<20100515170429.46c46dd7@pitrou.net>
	<AANLkTimRjN0McQjngFpPI0AmknKqdLIzEQ-2Vp4RDqCI@mail.gmail.com>
Message-ID: <AANLkTilP6X2mChQBl5gQhOSq8Rq7QfEHFZ0S081g6463@mail.gmail.com>

Sorry, I did not forward to the list by mistake.
---------- Forwarded message ----------
From: Andre Roberge <andre.roberge at gmail.com>
Date: Sat, May 15, 2010 at 12:13 PM
Subject: Re: [Python-ideas] i18n and Python tracebacks
To: Antoine Pitrou <solipsis at pitrou.net>

On Sat, May 15, 2010 at 12:04 PM, Antoine Pitrou <solipsis at pitrou.net>wrote:

> On Sat, 15 May 2010 11:02:35 -0300
> Andre Roberge <andre.roberge at 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 at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20100515/678bbaf2/attachment.html>

From reingart at gmail.com  Sat May 15 17:29:01 2010
From: reingart at gmail.com (Mariano Reingart)
Date: Sat, 15 May 2010 12:29:01 -0300
Subject: [Python-ideas] Fwd: i18n and Python tracebacks
In-Reply-To: <AANLkTilP6X2mChQBl5gQhOSq8Rq7QfEHFZ0S081g6463@mail.gmail.com>
References: <AANLkTinEr_HGMesvf2u7k5YOY8jQP1Ad45j-1_vf_3Gs@mail.gmail.com>
	<20100515170429.46c46dd7@pitrou.net>
	<AANLkTimRjN0McQjngFpPI0AmknKqdLIzEQ-2Vp4RDqCI@mail.gmail.com>
	<AANLkTilP6X2mChQBl5gQhOSq8Rq7QfEHFZ0S081g6463@mail.gmail.com>
Message-ID: <AANLkTinkSrBI0ErG-hX_lWYzRCOPbG8e0oo4BOWIyg48@mail.gmail.com>

On Sat, May 15, 2010 at 12:14 PM, Andre Roberge <andre.roberge at gmail.com> wrote:
> Sorry, I did not forward to the list by mistake.
> ---------- Forwarded message ----------
> From: Andre Roberge <andre.roberge at gmail.com>
> Date: Sat, May 15, 2010 at 12:13 PM
> Subject: Re: [Python-ideas] i18n and Python tracebacks
> To: Antoine Pitrou <solipsis at pitrou.net>
>
> On Sat, May 15, 2010 at 12:04 PM, Antoine Pitrou <solipsis at pitrou.net>
> wrote:
>>
>> On Sat, 15 May 2010 11:02:35 -0300
>> Andre Roberge <andre.roberge at 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.

Yes, that our case here in Argentina too.

> Imagine you could start python with
>
> python --lang="en" your_script.py
>
> This would easily allow to share tracebacks with developers to get help.

Even easier, it could be allowed to change LC_MESSAGES back to English
at runtime or via shell environment variable before starting python,
see:
http://mx.grulic.org.ar/lurker/message/20100513.163151.1611cd68.es.html

That's the way other software does it (like PostgreSQL as I said
earlier), no new command line options or special development would be
required.

>> (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.

I think so.

BTW, with colaborative online translation tools like Pootle, it can be
reviewed easily to fix bad translations.

Best regards,

Mariano Reingart
http://www.python.org.ar
http://www.sistemasagiles.com.ar
http://reingart.blogspot.com


From solipsis at pitrou.net  Sat May 15 17:36:25 2010
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sat, 15 May 2010 17:36:25 +0200
Subject: [Python-ideas] i18n and Python tracebacks
References: <AANLkTinEr_HGMesvf2u7k5YOY8jQP1Ad45j-1_vf_3Gs@mail.gmail.com>
	<20100515170429.46c46dd7@pitrou.net>
	<AANLkTimRjN0McQjngFpPI0AmknKqdLIzEQ-2Vp4RDqCI@mail.gmail.com>
	<AANLkTilP6X2mChQBl5gQhOSq8Rq7QfEHFZ0S081g6463@mail.gmail.com>
Message-ID: <20100515173625.54a7b053@pitrou.net>


Hello Andr?,

> I think you forget students (including one ones) that have to deal with such
> messages.

It depends which students. If they want to become programmers, they
have to eventually master English. Many first-hand resources, and the
most vibrant programming communities, are in English.
(it's like a medieval theologian needing to know Latin)

> Imagine you could start python with
> 
> python --lang="en" your_script.py

I would do the reverse and have Python start untranslated by default.
Only by specifying an option (e.g. "python -L"), or perhaps an
environment variable, would you get the translation suited to your
system settings.

Having Python translate its error messages by default, however, could
be a disaster. It would break programs which parse those error
messages. It could also make error reporting to a developer more
complicated.

And, as I mentioned, I've seen two many dreadful translations to like
the idea of French error messages in my Python.
(how do you like ? d?r?f?rencement du pointeur type-punned brisera les
strictes d'aliases ? ?)

> True ...  I know I'd choose English as a default myself  for Python (even
> though, like you I believe, French is my first language).

Mine as well indeed. And I'm not even Canadian :)

Regards

Antoine.




From tjreedy at udel.edu  Sat May 15 18:23:08 2010
From: tjreedy at udel.edu (Terry Reedy)
Date: Sat, 15 May 2010 12:23:08 -0400
Subject: [Python-ideas] i18n and Python tracebacks
In-Reply-To: <AANLkTinEr_HGMesvf2u7k5YOY8jQP1Ad45j-1_vf_3Gs@mail.gmail.com>
References: <AANLkTinEr_HGMesvf2u7k5YOY8jQP1Ad45j-1_vf_3Gs@mail.gmail.com>
Message-ID: <hsmhpd$uk2$1@dough.gmane.org>

On 5/15/2010 10:02 AM, Andre Roberge wrote:
> 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.

If you change the proposal to having a translated version 'in addition 
to' rather than 'instead of' the English version, I would be in favor of 
it as an option. Then non-English speakers would gradually learn a bit 
of English from each error, and people like me could also get a boost on 
learning the math/comp vocabulary of another language, such as Spanish.

Since a decent translation will not necessarily have substitution fields 
in the same order, this proposal requires that they be indicated and 
filled by name rather than position. This is easy with the new 3.x 
string formatting system, but I have no idea how it is done presently.

Use of unicode as the string type in 3.x, including for identifiers, 
makes internationalization (whew, no wonder people abbreviate that as 
i8n) of Python, to whatever level, easier than with 2.x. But I think 
further steps will require more initiative from the various 
other-language communities. In other words, more is needed than 'I think 
it would be a good idea...'. I also think it would be good if they 
cooperated to not re-invent the wheel (differently) for each language 
and form something like an Intermation Python Working Group (assuming 
there is not such now). Current core developers, of necessity, are 
comfortable enough with the current situation and mostly have other 
itches to scratch.

Terry Jan Reedy



From bruce at leapyear.org  Sat May 15 21:36:46 2010
From: bruce at leapyear.org (Bruce Leban)
Date: Sat, 15 May 2010 12:36:46 -0700
Subject: [Python-ideas] i18n and Python tracebacks
In-Reply-To: <hsmhpd$uk2$1@dough.gmane.org>
References: <AANLkTinEr_HGMesvf2u7k5YOY8jQP1Ad45j-1_vf_3Gs@mail.gmail.com> 
	<hsmhpd$uk2$1@dough.gmane.org>
Message-ID: <AANLkTimQHxkXu1gOnOtrdnv6PesjQuezI4_239Ri8czx@mail.gmail.com>

I think it's important as Antoine notes to preserve the ability for code to
read and interpret the error messages. If changes are being made here (after
the moratorium presumably) it would be nice if the changes made it easier to
parse errors by explicitly delimiting the error message text rather than
requiring ad hoc parsing. Of course I'm saying "would be nice" rather than
offering a compelling argument here. My thought is that *if* changes are
being made here anyway then it's worth considering.

--- Bruce
http://www.vroospeak.com
http://jarlsberg.appspot.com



On Sat, May 15, 2010 at 9:23 AM, Terry Reedy <tjreedy at udel.edu> wrote:

> On 5/15/2010 10:02 AM, Andre Roberge wrote:
>
>> 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.
>>
>
> If you change the proposal to having a translated version 'in addition to'
> rather than 'instead of' the English version, I would be in favor of it as
> an option. Then non-English speakers would gradually learn a bit of English
> from each error, and people like me could also get a boost on learning the
> math/comp vocabulary of another language, such as Spanish.
>
> Since a decent translation will not necessarily have substitution fields in
> the same order, this proposal requires that they be indicated and filled by
> name rather than position. This is easy with the new 3.x string formatting
> system, but I have no idea how it is done presently.
>
> Use of unicode as the string type in 3.x, including for identifiers, makes
> internationalization (whew, no wonder people abbreviate that as i8n) of
> Python, to whatever level, easier than with 2.x. But I think further steps
> will require more initiative from the various other-language communities. In
> other words, more is needed than 'I think it would be a good idea...'. I
> also think it would be good if they cooperated to not re-invent the wheel
> (differently) for each language and form something like an Intermation
> Python Working Group (assuming there is not such now). Current core
> developers, of necessity, are comfortable enough with the current situation
> and mostly have other itches to scratch.
>
> Terry Jan Reedy
>
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20100515/394167b3/attachment.html>

From tjreedy at udel.edu  Sun May 16 00:37:13 2010
From: tjreedy at udel.edu (Terry Reedy)
Date: Sat, 15 May 2010 18:37:13 -0400
Subject: [Python-ideas] i18n and Python tracebacks
In-Reply-To: <AANLkTimQHxkXu1gOnOtrdnv6PesjQuezI4_239Ri8czx@mail.gmail.com>
References: <AANLkTinEr_HGMesvf2u7k5YOY8jQP1Ad45j-1_vf_3Gs@mail.gmail.com>
	<hsmhpd$uk2$1@dough.gmane.org>
	<AANLkTimQHxkXu1gOnOtrdnv6PesjQuezI4_239Ri8czx@mail.gmail.com>
Message-ID: <hsn7mq$u1m$1@dough.gmane.org>

On 5/15/2010 3:36 PM, Bruce Leban wrote:
> I think it's important as Antoine notes to preserve the ability for code
> to read and interpret the error messages.

If the English message were always present, in a known position, and a 
translation were optionally provided (perhaps bracked in <<>>, for 
instance) in addition, then that should remain true.

tjr



From reingart at gmail.com  Sun May 16 01:20:04 2010
From: reingart at gmail.com (Mariano Reingart)
Date: Sat, 15 May 2010 20:20:04 -0300
Subject: [Python-ideas] i18n and Python tracebacks
In-Reply-To: <hsmhpd$uk2$1@dough.gmane.org>
References: <AANLkTinEr_HGMesvf2u7k5YOY8jQP1Ad45j-1_vf_3Gs@mail.gmail.com>
	<hsmhpd$uk2$1@dough.gmane.org>
Message-ID: <AANLkTilrjU2lSBz20mkfnFeVvxhw9-KWnMOT7JUaNR93@mail.gmail.com>

On Sat, May 15, 2010 at 1:23 PM, Terry Reedy <tjreedy at udel.edu> wrote:
> Python, to whatever level, easier than with 2.x. But I think further steps
> will require more initiative from the various other-language communities. In
> other words, more is needed than 'I think it would be a good idea...'. I
> also think it would be good if they cooperated to not re-invent the wheel
> (differently) for each language and form something like an Intermation
> Python Working Group (assuming there is not such now). Current core
> developers, of necessity, are comfortable enough with the current situation
> and mostly have other itches to scratch.

As we were talking about this issues here in our local mailing list
too, I set forward and made a draft proposal with some thoughts:

http://python.org.ar/pyar/TracebackInternationalizationProposal

It includes very very early patch against trunk, with some messages
translated to spanish (harcoded).

Sorry if there is any mistake, I hope the interested people (here in
Argentina at least),  with more experience in C and Python, would help
me to fix/enhance this and/or champion it.

Do you think this is the right way?

Any advice will be appreciated, and any help is welcome

BTW, as you may have noticed, my first language is Spanish, so pardon
my English.

Best regards,

Mariano Reingart


From ncoghlan at gmail.com  Sun May 16 06:19:59 2010
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 16 May 2010 14:19:59 +1000
Subject: [Python-ideas] i18n and Python tracebacks
In-Reply-To: <AANLkTilrjU2lSBz20mkfnFeVvxhw9-KWnMOT7JUaNR93@mail.gmail.com>
References: <AANLkTinEr_HGMesvf2u7k5YOY8jQP1Ad45j-1_vf_3Gs@mail.gmail.com>	<hsmhpd$uk2$1@dough.gmane.org>
	<AANLkTilrjU2lSBz20mkfnFeVvxhw9-KWnMOT7JUaNR93@mail.gmail.com>
Message-ID: <4BEF726F.6020401@gmail.com>

Mariano Reingart wrote:
> Sorry if there is any mistake, I hope the interested people (here in
> Argentina at least),  with more experience in C and Python, would help
> me to fix/enhance this and/or champion it.
> 
> Do you think this is the right way?

The basic concept appears sound, but you'll want to work against the
py3k branch rather than trunk.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------


From stephen at xemacs.org  Sun May 16 10:09:38 2010
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Sun, 16 May 2010 17:09:38 +0900
Subject: [Python-ideas]  i18n and Python tracebacks
In-Reply-To: <AANLkTinEr_HGMesvf2u7k5YOY8jQP1Ad45j-1_vf_3Gs@mail.gmail.com>
References: <AANLkTinEr_HGMesvf2u7k5YOY8jQP1Ad45j-1_vf_3Gs@mail.gmail.com>
Message-ID: <87iq6ogtdp.fsf@uwakimon.sk.tsukuba.ac.jp>

Andre Roberge writes:

 > 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.

If you do this, you really need a way to recover the original message
(or a pointer to it) for programs that automatically analyze the
tracebacks.  A hash code or something like that might do the trick.
And, no, running the program again with --trace-lang=C is not good
enough; there's no guarantee you can reproduce.

AFAIK this requires an extension to the current localization
infrastructure, both gettext for C and in Python.


From denis.spir at gmail.com  Sun May 16 17:37:48 2010
From: denis.spir at gmail.com (spir =?UTF-8?B?4pij?=)
Date: Sun, 16 May 2010 17:37:48 +0200
Subject: [Python-ideas] i18n and Python tracebacks
In-Reply-To: <20100515170429.46c46dd7@pitrou.net>
References: <AANLkTinEr_HGMesvf2u7k5YOY8jQP1Ad45j-1_vf_3Gs@mail.gmail.com>
	<20100515170429.46c46dd7@pitrou.net>
Message-ID: <20100516173748.37953a08@o>

On Sat, 15 May 2010 17:04:29 +0200
Antoine Pitrou <solipsis at pitrou.net> wrote:

> On Sat, 15 May 2010 11:02:35 -0300
> Andre Roberge <andre.roberge at 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.
> 
> (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)
> 
> Antoine.

I share this point of view (while my mother tongue is french as well). Distinguish the language user (developper) from app end-user.
Now, at another level, it may also be considered that people are able to program using their own language; it's also fair and good from the pov of diversity. It may help spreading & developping "the art of programming" by removing an important entry barrier. But it's a very big effort and there should be a reference anyway (*).

Denis

(*) In "the best of all possible worlds", an IAL... http://en.wikipedia.org/wiki/International_auxiliary_language
________________________________

vit esse estrany ?

spir.wikidot.com


From tjreedy at udel.edu  Sun May 16 21:29:34 2010
From: tjreedy at udel.edu (Terry Reedy)
Date: Sun, 16 May 2010 15:29:34 -0400
Subject: [Python-ideas] i18n and Python tracebacks
In-Reply-To: <87iq6ogtdp.fsf@uwakimon.sk.tsukuba.ac.jp>
References: <AANLkTinEr_HGMesvf2u7k5YOY8jQP1Ad45j-1_vf_3Gs@mail.gmail.com>
	<87iq6ogtdp.fsf@uwakimon.sk.tsukuba.ac.jp>
Message-ID: <hsph2u$t6l$1@dough.gmane.org>

On 5/16/2010 4:09 AM, Stephen J. Turnbull wrote:
> Andre Roberge writes:
>
>   >  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.
>
> If you do this, you really need a way to recover the original message
> (or a pointer to it) for programs that automatically analyze the
> tracebacks.  A hash code or something like that might do the trick.
> And, no, running the program again with --trace-lang=C is not good
> enough; there's no guarantee you can reproduce.

I already posted the suggestion, from gmane, that translation be in 
addition to rather than instead of the English original, both for the 
above reason and for human language learning either way.

> AFAIK this requires an extension to the current localization
> infrastructure, both gettext for C and in Python.

It will probably required efforts of more than 1 person, perhaps from 
multiple language communities (who would most likely have to cooperate 
in English ;-).

Terry Jan Reedy





From cool-rr at cool-rr.com  Sun May 16 23:07:15 2010
From: cool-rr at cool-rr.com (cool-RR)
Date: Sun, 16 May 2010 23:07:15 +0200
Subject: [Python-ideas] Allowing negative `maxsplit` in `str.split`
Message-ID: <AANLkTilgcOiC32zzMnNOqpMVxOkVv_ydjNHYb7OgvRcs@mail.gmail.com>

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.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20100516/2227f530/attachment.html>

From pyideas at rebertia.com  Sun May 16 23:15:51 2010
From: pyideas at rebertia.com (Chris Rebert)
Date: Sun, 16 May 2010 14:15:51 -0700
Subject: [Python-ideas] Allowing negative `maxsplit` in `str.split`
In-Reply-To: <AANLkTilgcOiC32zzMnNOqpMVxOkVv_ydjNHYb7OgvRcs@mail.gmail.com>
References: <AANLkTilgcOiC32zzMnNOqpMVxOkVv_ydjNHYb7OgvRcs@mail.gmail.com>
Message-ID: <AANLkTim73lyhApuAJNVGdGM0rmMLreW4u9JZdS5torKr@mail.gmail.com>

On Sun, May 16, 2010 at 2:07 PM, cool-RR <cool-rr at cool-rr.com> wrote:
> 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?

What's wrong with 'hello.world.meow'.rsplit(maxsplit=1) ?

Cheers,
Chris
--
http://blog.rebertia.com


From cool-rr at cool-rr.com  Sun May 16 23:18:45 2010
From: cool-rr at cool-rr.com (cool-RR)
Date: Sun, 16 May 2010 23:18:45 +0200
Subject: [Python-ideas] Allowing negative `maxsplit` in `str.split`
In-Reply-To: <AANLkTim73lyhApuAJNVGdGM0rmMLreW4u9JZdS5torKr@mail.gmail.com>
References: <AANLkTilgcOiC32zzMnNOqpMVxOkVv_ydjNHYb7OgvRcs@mail.gmail.com>
	<AANLkTim73lyhApuAJNVGdGM0rmMLreW4u9JZdS5torKr@mail.gmail.com>
Message-ID: <AANLkTilxrJ4wIS9L8bIYm2yQK-FTE2uYOFgkTruxqObl@mail.gmail.com>

On Sun, May 16, 2010 at 11:15 PM, Chris Rebert <pyideas at rebertia.com> wrote:

> On Sun, May 16, 2010 at 2:07 PM, cool-RR <cool-rr at cool-rr.com> wrote:
> > 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?
>
> What's wrong with 'hello.world.meow'.rsplit(maxsplit=1) ?
>
> Cheers,
> Chris
> --
> http://blog.rebertia.com
>

What a noob I am, I didn't know that existed. Thanks Chris.

Ram.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20100516/85123401/attachment.html>

From brett at python.org  Mon May 17 04:10:36 2010
From: brett at python.org (Brett Cannon)
Date: Sun, 16 May 2010 19:10:36 -0700
Subject: [Python-ideas] Allowing negative `maxsplit` in `str.split`
In-Reply-To: <AANLkTilxrJ4wIS9L8bIYm2yQK-FTE2uYOFgkTruxqObl@mail.gmail.com>
References: <AANLkTilgcOiC32zzMnNOqpMVxOkVv_ydjNHYb7OgvRcs@mail.gmail.com> 
	<AANLkTim73lyhApuAJNVGdGM0rmMLreW4u9JZdS5torKr@mail.gmail.com> 
	<AANLkTilxrJ4wIS9L8bIYm2yQK-FTE2uYOFgkTruxqObl@mail.gmail.com>
Message-ID: <AANLkTilH0p3o5jCz5M644htNbbvvGoYqIybq-4xrs_RP@mail.gmail.com>

On Sun, May 16, 2010 at 14:18, cool-RR <cool-rr at cool-rr.com> wrote:
> On Sun, May 16, 2010 at 11:15 PM, Chris Rebert <pyideas at rebertia.com> wrote:
>>
>> On Sun, May 16, 2010 at 2:07 PM, cool-RR <cool-rr at cool-rr.com> wrote:
>> > 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?
>>
>> What's wrong with 'hello.world.meow'.rsplit(maxsplit=1) ?
>>
>> Cheers,
>> Chris
>> --
>> http://blog.rebertia.com
>
> What a noob I am, I didn't know that existed. Thanks Chris.


`dir(str)` is your friend.

-Brett


From cmjohnson.mailinglist at gmail.com  Mon May 17 14:32:36 2010
From: cmjohnson.mailinglist at gmail.com (Carl M. Johnson)
Date: Mon, 17 May 2010 02:32:36 -1000
Subject: [Python-ideas] i18n and Python tracebacks
In-Reply-To: <hsph2u$t6l$1@dough.gmane.org>
References: <AANLkTinEr_HGMesvf2u7k5YOY8jQP1Ad45j-1_vf_3Gs@mail.gmail.com>
	<87iq6ogtdp.fsf@uwakimon.sk.tsukuba.ac.jp>
	<hsph2u$t6l$1@dough.gmane.org>
Message-ID: <AANLkTinVdROyw6WqebZNqpsv5Nozr2qSaAa7yeiJY5Rv@mail.gmail.com>

Couldn't this be done first as a simple module that wraps a try block
around the interactive prompt and changes known error messages to
their translated counterparts? It would probably make sense to see if
there's any traction for the idea first that way before changing core
Python.

Does anyone know what happened to the Chinese Python project? Did that
ever get any significant user base?

-- Carl Johnson


From ncoghlan at gmail.com  Mon May 17 23:19:57 2010
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Tue, 18 May 2010 07:19:57 +1000
Subject: [Python-ideas] i18n and Python tracebacks
In-Reply-To: <AANLkTinVdROyw6WqebZNqpsv5Nozr2qSaAa7yeiJY5Rv@mail.gmail.com>
References: <AANLkTinEr_HGMesvf2u7k5YOY8jQP1Ad45j-1_vf_3Gs@mail.gmail.com>	<87iq6ogtdp.fsf@uwakimon.sk.tsukuba.ac.jp>	<hsph2u$t6l$1@dough.gmane.org>
	<AANLkTinVdROyw6WqebZNqpsv5Nozr2qSaAa7yeiJY5Rv@mail.gmail.com>
Message-ID: <4BF1B2FD.7020408@gmail.com>

Carl M. Johnson wrote:
> Couldn't this be done first as a simple module that wraps a try block
> around the interactive prompt and changes known error messages to
> their translated counterparts? It would probably make sense to see if
> there's any traction for the idea first that way before changing core
> Python.

It would actually be interesting to see just how far someone could get
purely with sys.excepthook.

It would be subject to some fairly significant limitations (particularly
when it comes to reparsing strings with interpolated values), but the
traceback parsing and comparison code in doctest may offer a good
starting point.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------


From stephen at xemacs.org  Tue May 18 05:14:27 2010
From: stephen at xemacs.org (Stephen J. Turnbull)
Date: Tue, 18 May 2010 12:14:27 +0900
Subject: [Python-ideas] i18n and Python tracebacks
In-Reply-To: <4BF1B2FD.7020408@gmail.com>
References: <AANLkTinEr_HGMesvf2u7k5YOY8jQP1Ad45j-1_vf_3Gs@mail.gmail.com>
	<87iq6ogtdp.fsf@uwakimon.sk.tsukuba.ac.jp>
	<hsph2u$t6l$1@dough.gmane.org>
	<AANLkTinVdROyw6WqebZNqpsv5Nozr2qSaAa7yeiJY5Rv@mail.gmail.com>
	<4BF1B2FD.7020408@gmail.com>
Message-ID: <87tyq5hpf0.fsf@uwakimon.sk.tsukuba.ac.jp>

Nick Coghlan writes:

 > It would actually be interesting to see just how far someone could get
 > [on translating tracebacks] purely with sys.excepthook.
 > 
 > It would be subject to some fairly significant limitations (particularly
 > when it comes to reparsing strings with interpolated values), but the
 > traceback parsing and comparison code in doctest may offer a good
 > starting point.

Actually, it shouldn't be too hard to handle the interpolations.  In
fact the language to be parsed is probably mostly pretty simple, and
can be automatically translated to BNF or whatever input your favorite
parsing library wants from the .pot file.  The generated grammar
probably would be on the order of the size of the .pot file, no?  It
could be stored with the .mos as a "pseudo-translation".



From marcos.bonci at gmail.com  Sun May 30 03:05:17 2010
From: marcos.bonci at gmail.com (Marcos Bonci)
Date: Sat, 29 May 2010 22:05:17 -0300
Subject: [Python-ideas] Date/time literals
Message-ID: <AANLkTim-r9dS1KOYwPUfWsqVUYzTuJEKiuYWe2Z1HU4o@mail.gmail.com>

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 --
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20100529/8e135d57/attachment.html>

From pyideas at rebertia.com  Sun May 30 03:49:02 2010
From: pyideas at rebertia.com (Chris Rebert)
Date: Sat, 29 May 2010 18:49:02 -0700
Subject: [Python-ideas] Date/time literals
In-Reply-To: <AANLkTim-r9dS1KOYwPUfWsqVUYzTuJEKiuYWe2Z1HU4o@mail.gmail.com>
References: <AANLkTim-r9dS1KOYwPUfWsqVUYzTuJEKiuYWe2Z1HU4o@mail.gmail.com>
Message-ID: <AANLkTikrRUh_PASlTRFQuUJCaDA98SRXkt5qQY7Rpft7@mail.gmail.com>

On Sat, May 29, 2010 at 6:05 PM, Marcos Bonci <marcos.bonci at gmail.com> wrote:
> 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.

Reading the rest of your post, it sounds like you're unaware of the
fairly nice API of the `datetime` std lib module:
http://docs.python.org/library/datetime.html

IMO, it's pretty nice to work with; although it is annoying that some
operations can only be done using the more primitive `time` or
`calendar` modules. Patches are probably welcome; perhaps I should
consider trying to write one.

> 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?

Well, the datetime module does appear to already be written in C, so
that'd be one less hurdle.
I wasn't able to find a prior post on the exact subject; perhaps
someone else will.

> 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).

The `datetime` module already provides nice and more typesafe
abstractions; purposefully conflating date/times with plain numbers is
not a good idea, imo.

<snip>
> 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.

datetime.timedelta:
http://docs.python.org/library/datetime.html#timedelta-objects

> I guess the most controversial point here would be the meaning of arithmetic
> operations
> between?dates (or the very validity of such operations).

Already defined and accepted as valid:
datetime.date, "Supported operations"
http://docs.python.org/library/datetime.html#date-objects

<snip>
> 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

I think the classes in the `datetime` module are the nice "missing"
API that you're looking for, and that there's not enough of a gain to
justify complicating the language by adding literals for them and
making them built-in types.

Cheers,
Chris
--
http://blog.rebertia.com


From marcos.bonci at gmail.com  Sun May 30 05:10:59 2010
From: marcos.bonci at gmail.com (Marcos Bonci)
Date: Sun, 30 May 2010 00:10:59 -0300
Subject: [Python-ideas] Date/time literals
In-Reply-To: <AANLkTikrRUh_PASlTRFQuUJCaDA98SRXkt5qQY7Rpft7@mail.gmail.com>
References: <AANLkTim-r9dS1KOYwPUfWsqVUYzTuJEKiuYWe2Z1HU4o@mail.gmail.com> 
	<AANLkTikrRUh_PASlTRFQuUJCaDA98SRXkt5qQY7Rpft7@mail.gmail.com>
Message-ID: <AANLkTikWce29YZDmgI56Xb2mwLMxB6LdWfeR2rfd51xh@mail.gmail.com>

Hey, thanks for your response, Chris!

Reading the rest of your post, it sounds like you're unaware of the

fairly nice API of the `datetime` std lib module:


Yes, you're (partially) right. I did know it existed, but I guess I forgot
about it and got used to the wrong modules. This one does seem
to have most (if not all) of what I was talking about, and does look
like "the obvious way".

But there are some limitations I don't understand the reason for.
Why aren't negative years allowed? (That ISO regulation I mentioned
earlier "says it's ok".) And why does `toordinal` return an int (ignoring
the "time" part of a `datetime`)?

And I still fail to see any disadvantage in having date and time
literals (probably as shortcuts for the already existing datetime types,
or a future version of them).

But maybe it's all just me putting my nose where it doesn't belong :)

-- Marcos --


On 29 May 2010 22:49, Chris Rebert <pyideas at rebertia.com> wrote:

> On Sat, May 29, 2010 at 6:05 PM, Marcos Bonci <marcos.bonci at gmail.com>
> wrote:
> > 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.
>
> Reading the rest of your post, it sounds like you're unaware of the
> fairly nice API of the `datetime` std lib module:
> http://docs.python.org/library/datetime.html
>
> IMO, it's pretty nice to work with; although it is annoying that some
> operations can only be done using the more primitive `time` or
> `calendar` modules. Patches are probably welcome; perhaps I should
> consider trying to write one.
>
> > 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?
>
> Well, the datetime module does appear to already be written in C, so
> that'd be one less hurdle.
> I wasn't able to find a prior post on the exact subject; perhaps
> someone else will.
>
> > 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).
>
> The `datetime` module already provides nice and more typesafe
> abstractions; purposefully conflating date/times with plain numbers is
> not a good idea, imo.
>
> <snip>
> > 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.
>
> datetime.timedelta:
> http://docs.python.org/library/datetime.html#timedelta-objects
>
> > I guess the most controversial point here would be the meaning of
> arithmetic
> > operations
> > between dates (or the very validity of such operations).
>
> Already defined and accepted as valid:
> datetime.date, "Supported operations"
> http://docs.python.org/library/datetime.html#date-objects
>
> <snip>
> > 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
>
> I think the classes in the `datetime` module are the nice "missing"
> API that you're looking for, and that there's not enough of a gain to
> justify complicating the language by adding literals for them and
> making them built-in types.
>
> Cheers,
> Chris
> --
> http://blog.rebertia.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20100530/a1f5493c/attachment.html>

From benjamin at python.org  Sun May 30 05:27:53 2010
From: benjamin at python.org (Benjamin Peterson)
Date: Sun, 30 May 2010 03:27:53 +0000 (UTC)
Subject: [Python-ideas] An identity dict
Message-ID: <loom.20100530T052013-34@post.gmane.org>

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



From ncoghlan at gmail.com  Sun May 30 09:27:18 2010
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 30 May 2010 17:27:18 +1000
Subject: [Python-ideas] Date/time literals
In-Reply-To: <AANLkTikWce29YZDmgI56Xb2mwLMxB6LdWfeR2rfd51xh@mail.gmail.com>
References: <AANLkTim-r9dS1KOYwPUfWsqVUYzTuJEKiuYWe2Z1HU4o@mail.gmail.com>
	<AANLkTikrRUh_PASlTRFQuUJCaDA98SRXkt5qQY7Rpft7@mail.gmail.com>
	<AANLkTikWce29YZDmgI56Xb2mwLMxB6LdWfeR2rfd51xh@mail.gmail.com>
Message-ID: <4C021356.3040904@gmail.com>

On 30/05/10 13:10, Marcos Bonci wrote:
> And I still fail to see any disadvantage in having date and time
> literals (probably as shortcuts for the already existing datetime types,
> or a future version of them).

The same disadvantage that any new syntax has: it increases the size of 
the language, making it harder to learn and harder to implement.

Why make date/time literals a special case, when they can be dealt with 
quite adequately as a standard module? (the existing module may have 
some odd quirks, but that's a far cry from needing to be given literal 
syntax).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------


From masklinn at masklinn.net  Sun May 30 10:28:08 2010
From: masklinn at masklinn.net (Masklinn)
Date: Sun, 30 May 2010 10:28:08 +0200
Subject: [Python-ideas] Date/time literals
In-Reply-To: <AANLkTikrRUh_PASlTRFQuUJCaDA98SRXkt5qQY7Rpft7@mail.gmail.com>
References: <AANLkTim-r9dS1KOYwPUfWsqVUYzTuJEKiuYWe2Z1HU4o@mail.gmail.com>
	<AANLkTikrRUh_PASlTRFQuUJCaDA98SRXkt5qQY7Rpft7@mail.gmail.com>
Message-ID: <AE9FEEDF-4747-4A30-9E40-93195140B259@masklinn.net>

On 2010-05-30, at 03:49 , Chris Rebert wrote:
> On Sat, May 29, 2010 at 6:05 PM, Marcos Bonci <marcos.bonci at gmail.com> wrote:
>> 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.
> 
> Reading the rest of your post, it sounds like you're unaware of the
> fairly nice API of the `datetime` std lib module:
> http://docs.python.org/library/datetime.html
> 
> IMO, it's pretty nice to work with; although it is annoying that some
> operations can only be done using the more primitive `time` or
> `calendar` modules. Patches are probably welcome; perhaps I should
> consider trying to write one.

datetime does have a bunch of issues and limitations which I believe soon
become harmful when doing serious date/calendaring works (which I don't
claim to do, but I've seen colleagues in serious trouble due to both
personal lack of knowledge in the field and issues with datetime itself):
it only supports a gregoriany calendar for instance, it's horrendous
in dealing with timezones, some methods are pretty much broken, 
constructor refuses "24" as an hour value, blows up on positive leap
seconds)?

See the following resources for issues with datetime:
http://blog.mfabrik.com/2008/06/30/relativity-of-time-shortcomings-in-python-datetime-and-workaround/
http://www.enricozini.org/2009/debian/using-python-datetime/

Libraries built over datetime:
http://labix.org/python-dateutil
http://pytz.sourceforge.net/ [1]


[1] note that as mentioned in the first blog post, datetime apparently
has issues re querrying tz objects, so it's generally suggested to work
with utc-only datetime objects and let the timezone stuff to direct 
pytz calls.

From lie.1296 at gmail.com  Sun May 30 11:07:46 2010
From: lie.1296 at gmail.com (Lie Ryan)
Date: Sun, 30 May 2010 19:07:46 +1000
Subject: [Python-ideas] An identity dict
In-Reply-To: <loom.20100530T052013-34@post.gmane.org>
References: <loom.20100530T052013-34@post.gmane.org>
Message-ID: <htta0r$9l5$1@dough.gmane.org>

On 05/30/10 13:27, Benjamin Peterson wrote:
> 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.

what's wrong with dict[id(key)] = foo?

> 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.

that their id() is expensive is implementation details, and the
developer of PyPy should solve that instead of adding a clutch to the
stdlib.



From fuzzyman at gmail.com  Sun May 30 11:29:35 2010
From: fuzzyman at gmail.com (Michael)
Date: Sun, 30 May 2010 10:29:35 +0100
Subject: [Python-ideas] An identity dict
In-Reply-To: <loom.20100530T052013-34@post.gmane.org>
References: <loom.20100530T052013-34@post.gmane.org>
Message-ID: <EC93587F-9A95-462C-8543-14F9018B75B4@gmail.com>

+1 - this has been useful to me in other languages.

(apologies for top-post, sent from phone.)

Michael Foord


--
http://www.ironpythoninaction.com

On 30 May 2010, at 04:27, Benjamin Peterson <benjamin at python.org> wrote:

> 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
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas


From solipsis at pitrou.net  Sun May 30 12:34:00 2010
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sun, 30 May 2010 12:34:00 +0200
Subject: [Python-ideas] An identity dict
References: <loom.20100530T052013-34@post.gmane.org>
Message-ID: <20100530123400.726a9fe1@pitrou.net>

On Sun, 30 May 2010 03:27:53 +0000 (UTC)
Benjamin Peterson <benjamin at python.org>
wrote:
> 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().

Perhaps it would be more useful to add a generic
collections.keyfuncdict, taking a function which applied to a key
gives the real key value used for lookups.
Your identity dict would be created as:
    d = collections.keyfuncdict(id)

But of course, you can just use a normal dict:
    d = {}
    d[id(key)] = key, value

(actually, this could be how a collections.keyfuncdict gets implemented)

Regards

Antoine.




From masklinn at masklinn.net  Sun May 30 12:35:42 2010
From: masklinn at masklinn.net (Masklinn)
Date: Sun, 30 May 2010 12:35:42 +0200
Subject: [Python-ideas] An identity dict
In-Reply-To: <htta0r$9l5$1@dough.gmane.org>
References: <loom.20100530T052013-34@post.gmane.org>
	<htta0r$9l5$1@dough.gmane.org>
Message-ID: <6501F5E2-C5BE-44D4-B71F-95B0B40BA1A2@masklinn.net>

On 2010-05-30, at 11:07 , Lie Ryan wrote:
> 
>> 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.
> 
> that their id() is expensive is implementation details, and the
> developer of PyPy should solve that instead of adding a clutch to the
> stdlib.

Actually, I'd say the exact opposite: CPython's identity being cheap is an
implementation detail, not the other way around, and that is what shouldn't
be relied on. In that light, a special-purpose identity dictionary independent
from implementation-specific and artificially low id() computation costs is a
pretty good idea.

From marcos.bonci at gmail.com  Sun May 30 12:39:50 2010
From: marcos.bonci at gmail.com (Marcos Bonci)
Date: Sun, 30 May 2010 07:39:50 -0300
Subject: [Python-ideas] Date/time literals
In-Reply-To: <AE9FEEDF-4747-4A30-9E40-93195140B259@masklinn.net>
References: <AANLkTim-r9dS1KOYwPUfWsqVUYzTuJEKiuYWe2Z1HU4o@mail.gmail.com> 
	<AANLkTikrRUh_PASlTRFQuUJCaDA98SRXkt5qQY7Rpft7@mail.gmail.com> 
	<AE9FEEDF-4747-4A30-9E40-93195140B259@masklinn.net>
Message-ID: <AANLkTilIwg597zUFivUEkTFlPn2AmpkNxRywNukxR4rG@mail.gmail.com>

>From Masklinn's post in his blog:


> Sadly it seems that Java got it right: having one class (Date<http://java.sun.com/j2se/1.5.0/docs/api/java/util/Date.html>)
> that stores times in UTC seconds relative to Unix Epoch, and subclasses of
> abstract Calendar<http://java.sun.com/j2se/1.5.0/docs/api/java/util/Calendar.html> class
> that deal with getting and setting individual components and date arithmetic
> in a localized way would indeed be the best long-term solution.


That's exactly what I was talking about. Date/time is something
apparently near-trivial (it's something everyone deals with every
day), but awfully complicated when looked at in detail. This can
be very deceiving for the inexperienced/inattentive programmer,
and very inconvenient/time-wasting for the attentive one.

I like Python because I can usually rely on its "magic" and just
care about what's elegant and readable (or else I would be using C).
Judging from your personal experience, the magic looks more like
illusionism when it comes to dates. Maybe this matter deserves
closer attention in the context of the language/stdlibs than it has
received so far? After all it's time we're talking about, it's not like
it's something unimportant or rarely used (and it's something I
would definitely expect to be able to rely on Python for, since
pretty much everything else Python is just awesome).

There's just too many ways to do it, and none of them seem to
be good enough.

-- Marcos --


On 30 May 2010 05:28, Masklinn <masklinn at masklinn.net> wrote:

> On 2010-05-30, at 03:49 , Chris Rebert wrote:
> > On Sat, May 29, 2010 at 6:05 PM, Marcos Bonci <marcos.bonci at gmail.com>
> wrote:
> >> 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.
> >
> > Reading the rest of your post, it sounds like you're unaware of the
> > fairly nice API of the `datetime` std lib module:
> > http://docs.python.org/library/datetime.html
> >
> > IMO, it's pretty nice to work with; although it is annoying that some
> > operations can only be done using the more primitive `time` or
> > `calendar` modules. Patches are probably welcome; perhaps I should
> > consider trying to write one.
>
> datetime does have a bunch of issues and limitations which I believe soon
> become harmful when doing serious date/calendaring works (which I don't
> claim to do, but I've seen colleagues in serious trouble due to both
> personal lack of knowledge in the field and issues with datetime itself):
> it only supports a gregoriany calendar for instance, it's horrendous
> in dealing with timezones, some methods are pretty much broken,
> constructor refuses "24" as an hour value, blows up on positive leap
> seconds)?
>
> See the following resources for issues with datetime:
>
> http://blog.mfabrik.com/2008/06/30/relativity-of-time-shortcomings-in-python-datetime-and-workaround/
> http://www.enricozini.org/2009/debian/using-python-datetime/
>
> Libraries built over datetime:
> http://labix.org/python-dateutil
> http://pytz.sourceforge.net/ [1]
>
>
> [1] note that as mentioned in the first blog post, datetime apparently
> has issues re querrying tz objects, so it's generally suggested to work
> with utc-only datetime objects and let the timezone stuff to direct
> pytz calls.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20100530/3fcd5e10/attachment.html>

From masklinn at masklinn.net  Sun May 30 12:55:40 2010
From: masklinn at masklinn.net (Masklinn)
Date: Sun, 30 May 2010 12:55:40 +0200
Subject: [Python-ideas] Date/time literals
In-Reply-To: <AANLkTilIwg597zUFivUEkTFlPn2AmpkNxRywNukxR4rG@mail.gmail.com>
References: <AANLkTim-r9dS1KOYwPUfWsqVUYzTuJEKiuYWe2Z1HU4o@mail.gmail.com>
	<AANLkTikrRUh_PASlTRFQuUJCaDA98SRXkt5qQY7Rpft7@mail.gmail.com>
	<AE9FEEDF-4747-4A30-9E40-93195140B259@masklinn.net>
	<AANLkTilIwg597zUFivUEkTFlPn2AmpkNxRywNukxR4rG@mail.gmail.com>
Message-ID: <E359EB0C-BE15-432A-BC43-ACEB81CE3008@masklinn.net>

On 2010-05-30, at 12:39 , Marcos Bonci wrote:
> 
> From Masklinn's post in his blog:
> 
It's very nice of you to attribute such a great post to me, but
I just linked to it. I'm not the author of any of the resources
I linked to.

> I like Python because I can usually rely on its "magic" and just
> care about what's elegant and readable (or else I would be using C).
> Judging from your personal experience, the magic looks more like
> illusionism when it comes to dates. Maybe this matter deserves
> closer attention in the context of the language/stdlibs than it has
> received so far? After all it's time we're talking about, it's not like
> it's something unimportant or rarely used (and it's something I
> would definitely expect to be able to rely on Python for, since
> pretty much everything else Python is just awesome).

One of the issues from what I understand is that you pretty much need
to be a specialist in the time/date domain (or have one available at
all times) to get this stuff right. I'm guessing the Python community
doesn't have any involved/available, least of which at the core level.

Furthermore if you want to see what's usually considered a
best-of-breed in the java world, look not at the standard library but
at joda time [1]. In fact, with Java 7 the current Date/Calendar API
should be replaced by one strongly inspired by Joda (and created by
its author) and influenced by a few other APIs of the Java world. See
JSR 310 for details [2], though note that the inclusion in Java 7
apparently isn't certain yet due to delays in the JSR 310 process [3].

For a (probably long outdated) overview of what JSR 310 would provide,
see [4]

[1] http://joda-time.sourceforge.net/
[2] http://jcp.org/en/jsr/detail?id=310
[3] http://tech.puredanger.com/java7
[4] http://today.java.net/pub/a/today/2008/09/18/jsr-310-new-java-date-time-api.html

From marcos.bonci at gmail.com  Sun May 30 13:06:00 2010
From: marcos.bonci at gmail.com (Marcos Bonci)
Date: Sun, 30 May 2010 08:06:00 -0300
Subject: [Python-ideas] Date/time literals
In-Reply-To: <E359EB0C-BE15-432A-BC43-ACEB81CE3008@masklinn.net>
References: <AANLkTim-r9dS1KOYwPUfWsqVUYzTuJEKiuYWe2Z1HU4o@mail.gmail.com> 
	<AANLkTikrRUh_PASlTRFQuUJCaDA98SRXkt5qQY7Rpft7@mail.gmail.com> 
	<AE9FEEDF-4747-4A30-9E40-93195140B259@masklinn.net>
	<AANLkTilIwg597zUFivUEkTFlPn2AmpkNxRywNukxR4rG@mail.gmail.com> 
	<E359EB0C-BE15-432A-BC43-ACEB81CE3008@masklinn.net>
Message-ID: <AANLkTimWXcg43YmSJmN9XfKK3Ij0bLOXHxOKe-RIE5-F@mail.gmail.com>

> It's very nice of you to attribute such a great post to me, but
> I just linked to it. I'm not the author of any of the resources
> I linked to.
>

Oops, lack-of-sleep in action!.. Being myself an example of the
inattentive guy I was talking about, I guess...


> One of the issues from what I understand is that you pretty much need
> to be a specialist in the time/date domain (or have one available at
> all times) to get this stuff right. I'm guessing the Python community
> doesn't have any involved/available, least of which at the core level.
>
> Furthermore if you want to see what's usually considered a
> best-of-breed in the java world, look not at the standard library but
> at joda time [1]. In fact, with Java 7 the current Date/Calendar API
> should be replaced by one strongly inspired by Joda (and created by
> its author) and influenced by a few other APIs of the Java world. See
> JSR 310 for details [2], though note that the inclusion in Java 7
> apparently isn't certain yet due to delays in the JSR 310 process [3].
>
> For a (probably long outdated) overview of what JSR 310 would provide,
> see [4]
>
> [1] http://joda-time.sourceforge.net/
> [2] http://jcp.org/en/jsr/detail?id=310
> [3] http://tech.puredanger.com/java7
> [4]
> http://today.java.net/pub/a/today/2008/09/18/jsr-310-new-java-date-time-api.html


Since it's all open source stuff, shouldn't it be possible to just
"clone" most of it?
Or is there some Java-specific thing that makes it hard to translate?

-- Marcos --
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20100530/789b9976/attachment.html>

From lie.1296 at gmail.com  Sun May 30 13:07:52 2010
From: lie.1296 at gmail.com (Lie Ryan)
Date: Sun, 30 May 2010 21:07:52 +1000
Subject: [Python-ideas] An identity dict
In-Reply-To: <20100530123400.726a9fe1@pitrou.net>
References: <loom.20100530T052013-34@post.gmane.org>
	<20100530123400.726a9fe1@pitrou.net>
Message-ID: <htth1v$sdj$1@dough.gmane.org>

On 05/30/10 20:34, Antoine Pitrou wrote:
> On Sun, 30 May 2010 03:27:53 +0000 (UTC)
> Benjamin Peterson <benjamin at python.org>
> wrote:
>> 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().
> 
> Perhaps it would be more useful to add a generic
> collections.keyfuncdict, taking a function which applied to a key
> gives the real key value used for lookups.
> Your identity dict would be created as:
>     d = collections.keyfuncdict(id)
> 
> But of course, you can just use a normal dict:
>     d = {}
>     d[id(key)] = key, value
> 
> (actually, this could be how a collections.keyfuncdict gets implemented)

+1 on this



From lie.1296 at gmail.com  Sun May 30 13:14:14 2010
From: lie.1296 at gmail.com (Lie Ryan)
Date: Sun, 30 May 2010 21:14:14 +1000
Subject: [Python-ideas] An identity dict
In-Reply-To: <6501F5E2-C5BE-44D4-B71F-95B0B40BA1A2@masklinn.net>
References: <loom.20100530T052013-34@post.gmane.org>	<htta0r$9l5$1@dough.gmane.org>
	<6501F5E2-C5BE-44D4-B71F-95B0B40BA1A2@masklinn.net>
Message-ID: <htthe4$tj4$1@dough.gmane.org>

On 05/30/10 20:35, Masklinn wrote:
> On 2010-05-30, at 11:07 , Lie Ryan wrote:
>>
>>> 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.
>>
>> that their id() is expensive is implementation details, and the
>> developer of PyPy should solve that instead of adding a clutch to the
>> stdlib.
> 
> Actually, I'd say the exact opposite: CPython's identity being cheap is an
> implementation detail, not the other way around, and that is what shouldn't
> be relied on. In that light, a special-purpose identity dictionary independent
> from implementation-specific and artificially low id() computation costs is a
> pretty good idea.

the performance of any Python statement/function is implementation
detail. Whether any statement/function is fast or cheap shouldn't be
relied on. IMHO, adding a brand new collection module just because a
Python implementation has a fast/cheap operations isn't a good reason.



From pyideas at rebertia.com  Sun May 30 13:17:45 2010
From: pyideas at rebertia.com (Chris Rebert)
Date: Sun, 30 May 2010 04:17:45 -0700
Subject: [Python-ideas] Date/time literals
In-Reply-To: <AANLkTimWXcg43YmSJmN9XfKK3Ij0bLOXHxOKe-RIE5-F@mail.gmail.com>
References: <AANLkTim-r9dS1KOYwPUfWsqVUYzTuJEKiuYWe2Z1HU4o@mail.gmail.com>
	<AANLkTikrRUh_PASlTRFQuUJCaDA98SRXkt5qQY7Rpft7@mail.gmail.com>
	<AE9FEEDF-4747-4A30-9E40-93195140B259@masklinn.net>
	<AANLkTilIwg597zUFivUEkTFlPn2AmpkNxRywNukxR4rG@mail.gmail.com>
	<E359EB0C-BE15-432A-BC43-ACEB81CE3008@masklinn.net>
	<AANLkTimWXcg43YmSJmN9XfKK3Ij0bLOXHxOKe-RIE5-F@mail.gmail.com>
Message-ID: <AANLkTikdf_CDObmVOI2xb_dQlMOUieqSKofB37CkHDEy@mail.gmail.com>

On Sun, May 30, 2010 at 4:06 AM, Marcos Bonci <marcos.bonci at gmail.com> wrote:
>> It's very nice of you to attribute such a great post to me, but
>> I just linked to it. I'm not the author of any of the resources
>> I linked to.
>
> Oops, lack-of-sleep in action!..?Being myself an example of the
> inattentive guy I was talking about, I guess...
>
>> One of the issues from what I understand is that you pretty much need
>> to be a specialist in the time/date domain (or have one available at
>> all times) to get this stuff right. I'm guessing the Python community
>> doesn't have any involved/available, least of which at the core level.
>>
>> Furthermore if you want to see what's usually considered a
>> best-of-breed in the java world, look not at the standard library but
>> at joda time [1]. In fact, with Java 7 the current Date/Calendar API
>> should be replaced by one strongly inspired by Joda (and created by
>> its author) and influenced by a few other APIs of the Java world. See
>> JSR 310 for details [2], though note that the inclusion in Java 7
>> apparently isn't certain yet due to delays in the JSR 310 process [3].
>>
>> For a (probably long outdated) overview of what JSR 310 would provide,
>> see [4]
>>
>> [1] http://joda-time.sourceforge.net/
>> [2] http://jcp.org/en/jsr/detail?id=310
>> [3] http://tech.puredanger.com/java7
>> [4]
>> http://today.java.net/pub/a/today/2008/09/18/jsr-310-new-java-date-time-api.html
>
> Since it's all open source stuff, shouldn't it be possible to just
> "clone"?most of it?
> Or is there some Java-specific thing that makes it hard to translate?

Doubtful, but anyhow, I hear mxDateTime
(http://www.egenix.com/products/python/mxBase/mxDateTime/ ) is the
current and extant Python gold standard. Not quite as nimble as Joda
(though not many applications need to deal with e.g. Coptic dates
anyway), but still a significant improvement over `datetime`.

Cheers,
Chris
--
http://blog.rebertia.com


From denis.spir at gmail.com  Sun May 30 13:20:47 2010
From: denis.spir at gmail.com (spir =?UTF-8?B?4pij?=)
Date: Sun, 30 May 2010 13:20:47 +0200
Subject: [Python-ideas] An identity dict
In-Reply-To: <loom.20100530T052013-34@post.gmane.org>
References: <loom.20100530T052013-34@post.gmane.org>
Message-ID: <20100530132047.39a5875a@o>

On Sun, 30 May 2010 03:27:53 +0000 (UTC)
Benjamin Peterson <benjamin at python.org> wrote:

> 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 is how Lua works, systematically. To make this work, all "primitive" values (non-table, since table is the single container type) are interned. Thus, for "values", equality and identity are equivalent. Tables instead are considered referenced objects, even when they are used as collections.
So that Lua can quietly hash the ref instead of the value.
* simplicity
* performance
* anything can be used as key

The drawback is that any structured value, eg an x,y position stored in a table, is compared by reference. A lookup with a position used as key thus cannot return an item stored with an equal key:
> p1 = {x=1,y=2}
> p2 = {x=1,y=2}
> t = {[p1]="abc"}
> print(t[p1],tp2)
abc	nil
Conversely, collections which, conceptually, are referenced things, do not erroneaously return false positive because of value comparison. (The case does not happen in python since collections cannot be used as keys).

For the scheme to really extend to any use case, there should be a kind of mark allowing the programmer to state whether a table is, conceptually, a value (simply happens to be structured) or a referenced thing. Value tables should then be interned like other values -- but this is certainly difficult and costly.


Denis
________________________________

vit esse estrany ?

spir.wikidot.com


From denis.spir at gmail.com  Sun May 30 13:28:02 2010
From: denis.spir at gmail.com (spir =?UTF-8?B?4pij?=)
Date: Sun, 30 May 2010 13:28:02 +0200
Subject: [Python-ideas] An identity dict
In-Reply-To: <loom.20100530T052013-34@post.gmane.org>
References: <loom.20100530T052013-34@post.gmane.org>
Message-ID: <20100530132802.73ec565b@o>

On Sun, 30 May 2010 03:27:53 +0000 (UTC)
Benjamin Peterson <benjamin at python.org> wrote:

> 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.

The main point is certainly that the limitation of "hashability" disappears... Everything can be used as key, if actually the ref is hashed instead of the value.

Denis
________________________________

vit esse estrany ?

spir.wikidot.com


From masklinn at masklinn.net  Sun May 30 13:43:18 2010
From: masklinn at masklinn.net (Masklinn)
Date: Sun, 30 May 2010 13:43:18 +0200
Subject: [Python-ideas] Date/time literals
In-Reply-To: <AANLkTikdf_CDObmVOI2xb_dQlMOUieqSKofB37CkHDEy@mail.gmail.com>
References: <AANLkTim-r9dS1KOYwPUfWsqVUYzTuJEKiuYWe2Z1HU4o@mail.gmail.com>
	<AANLkTikrRUh_PASlTRFQuUJCaDA98SRXkt5qQY7Rpft7@mail.gmail.com>
	<AE9FEEDF-4747-4A30-9E40-93195140B259@masklinn.net>
	<AANLkTilIwg597zUFivUEkTFlPn2AmpkNxRywNukxR4rG@mail.gmail.com>
	<E359EB0C-BE15-432A-BC43-ACEB81CE3008@masklinn.net>
	<AANLkTimWXcg43YmSJmN9XfKK3Ij0bLOXHxOKe-RIE5-F@mail.gmail.com>
	<AANLkTikdf_CDObmVOI2xb_dQlMOUieqSKofB37CkHDEy@mail.gmail.com>
Message-ID: <CD1F1380-FEB7-4303-8024-29C8C85EEE16@masklinn.net>

On 2010-05-30, at 13:17 , Chris Rebert wrote:
> 
> On Sun, May 30, 2010 at 4:06 AM, Marcos Bonci <marcos.bonci at gmail.com> wrote:
>>> It's very nice of you to attribute such a great post to me, but
>>> I just linked to it. I'm not the author of any of the resources
>>> I linked to.
>> 
>> Oops, lack-of-sleep in action!.. Being myself an example of the
>> inattentive guy I was talking about, I guess...
>> 
>>> One of the issues from what I understand is that you pretty much need
>>> to be a specialist in the time/date domain (or have one available at
>>> all times) to get this stuff right. I'm guessing the Python community
>>> doesn't have any involved/available, least of which at the core level.
>>> 
>>> Furthermore if you want to see what's usually considered a
>>> best-of-breed in the java world, look not at the standard library but
>>> at joda time [1]. In fact, with Java 7 the current Date/Calendar API
>>> should be replaced by one strongly inspired by Joda (and created by
>>> its author) and influenced by a few other APIs of the Java world. See
>>> JSR 310 for details [2], though note that the inclusion in Java 7
>>> apparently isn't certain yet due to delays in the JSR 310 process [3].
>>> 
>>> For a (probably long outdated) overview of what JSR 310 would provide,
>>> see [4]
>>> 
>>> [1] http://joda-time.sourceforge.net/
>>> [2] http://jcp.org/en/jsr/detail?id=310
>>> [3] http://tech.puredanger.com/java7
>>> [4]
>>> http://today.java.net/pub/a/today/2008/09/18/jsr-310-new-java-date-time-api.html
>> 
>> Since it's all open source stuff, shouldn't it be possible to just
>> "clone" most of it?
>> Or is there some Java-specific thing that makes it hard to translate?
> 
> Doubtful, but anyhow, I hear mxDateTime
> (http://www.egenix.com/products/python/mxBase/mxDateTime/ ) is the
> current and extant Python gold standard. Not quite as nimble as Joda
> (though not many applications need to deal with e.g. Coptic dates
> anyway), but still a significant improvement over `datetime`.

Used to be, but these days I believe most people use datetime + dateutil
instead. mx.DateTime is actually an improvement of what came before datetime
(raw date and time modules) and datetime was inspired by mx.DateTime.
Most of the mx.DateTime stuff missing from datetime is in dateutil, 
and mx.DateTime is very heavyweight, a pain to install and has other
issues. Mostly a complete lack of support in implementations other 
than CPython.

A significant limitation of datetime which mx doesn't have, though, is that
mx.DateTime can deal with BCE dates (< year 1).

I'm sure M.A. Lemburg will disagree and fix the mistakes in my post if he
passes by though.

Anyway personally, my biggest issues with mx.DateTime are that it mandates the
installation of the rest of the mx distro (the package is actually
egenix-mx-base) and that it generally refuses to install, short of
a bare `python setup.py install` (eqsy_install or 
pip install egenix-mx-base didn't ever work for me)

From ncoghlan at gmail.com  Sun May 30 14:05:20 2010
From: ncoghlan at gmail.com (Nick Coghlan)
Date: Sun, 30 May 2010 22:05:20 +1000
Subject: [Python-ideas] An identity dict
In-Reply-To: <loom.20100530T052013-34@post.gmane.org>
References: <loom.20100530T052013-34@post.gmane.org>
Message-ID: <4C025480.3070107@gmail.com>

On 30/05/10 13:27, Benjamin Peterson wrote:
> 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.

How would dict equality be defined? In terms of values, or in terms of 
value identity?

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------


From grosser.meister.morti at gmx.net  Sun May 30 15:43:36 2010
From: grosser.meister.morti at gmx.net (=?ISO-8859-1?Q?Mathias_Panzenb=F6ck?=)
Date: Sun, 30 May 2010 15:43:36 +0200
Subject: [Python-ideas] An identity dict
In-Reply-To: <20100530123400.726a9fe1@pitrou.net>
References: <loom.20100530T052013-34@post.gmane.org>
	<20100530123400.726a9fe1@pitrou.net>
Message-ID: <4C026B88.6020207@gmx.net>

On 05/30/2010 12:34 PM, Antoine Pitrou wrote:
> On Sun, 30 May 2010 03:27:53 +0000 (UTC)
> Benjamin Peterson<benjamin at python.org>
> wrote:
>> 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().
>
> Perhaps it would be more useful to add a generic
> collections.keyfuncdict, taking a function which applied to a key
> gives the real key value used for lookups.
> Your identity dict would be created as:
>      d = collections.keyfuncdict(id)
>
> But of course, you can just use a normal dict:
>      d = {}
>      d[id(key)] = key, value
>
> (actually, this could be how a collections.keyfuncdict gets implemented)
>
> Regards
>
> Antoine.
>

Yes, something like this or a dict wihch you can pass a custom hash and compare function would be a 
good idea, imho.

+1

	-panzi


From benjamin at python.org  Sun May 30 16:18:00 2010
From: benjamin at python.org (Benjamin Peterson)
Date: Sun, 30 May 2010 14:18:00 +0000 (UTC)
Subject: [Python-ideas] An identity dict
References: <loom.20100530T052013-34@post.gmane.org>
	<4C025480.3070107@gmail.com>
Message-ID: <loom.20100530T161713-652@post.gmane.org>

Nick Coghlan <ncoghlan at ...> writes:
> How would dict equality be defined? In terms of values, or in terms of 
> value identity?

Completely identity. __eq__ and __hash__ should never be called.






From benjamin at python.org  Sun May 30 16:23:02 2010
From: benjamin at python.org (Benjamin Peterson)
Date: Sun, 30 May 2010 14:23:02 +0000 (UTC)
Subject: [Python-ideas] An identity dict
References: <loom.20100530T052013-34@post.gmane.org>
	<htta0r$9l5$1@dough.gmane.org>
Message-ID: <loom.20100530T162050-351@post.gmane.org>

Lie Ryan <lie.1296 at ...> writes:
> what's wrong with dict[id(key)] = foo?

For one, you can't get the value of the key out of the dict.


> that their id() is expensive is implementation details, and the
> developer of PyPy should solve that instead of adding a clutch to the
> stdlib.

A "clutch"? Even ignoring PyPy, an identitydict is still a useful primitive.






From benjamin at python.org  Sun May 30 16:27:05 2010
From: benjamin at python.org (Benjamin Peterson)
Date: Sun, 30 May 2010 14:27:05 +0000 (UTC)
Subject: [Python-ideas] An identity dict
References: <loom.20100530T052013-34@post.gmane.org>
	<20100530123400.726a9fe1@pitrou.net>
Message-ID: <loom.20100530T162515-868@post.gmane.org>

Antoine Pitrou <solipsis at ...> writes:
> Perhaps it would be more useful to add a generic
> collections.keyfuncdict, taking a function which applied to a key

Perhaps; I'm only really interested in the identity version. That could be
specified by keyfuncdict(None, None).






From solipsis at pitrou.net  Sun May 30 16:54:08 2010
From: solipsis at pitrou.net (Antoine Pitrou)
Date: Sun, 30 May 2010 16:54:08 +0200
Subject: [Python-ideas] An identity dict
References: <loom.20100530T052013-34@post.gmane.org>
	<20100530123400.726a9fe1@pitrou.net>
	<loom.20100530T162515-868@post.gmane.org>
Message-ID: <20100530165408.52f48abb@pitrou.net>

On Sun, 30 May 2010 14:27:05 +0000 (UTC)
Benjamin Peterson <benjamin at python.org>
wrote:
> Antoine Pitrou <solipsis at ...> writes:
> > Perhaps it would be more useful to add a generic
> > collections.keyfuncdict, taking a function which applied to a key
> 
> Perhaps; I'm only really interested in the identity version. That could be
> specified by keyfuncdict(None, None).

Just keyfuncdict(None) or keyfuncdict(id), then.
I'm not proposing that the hash() and eq() function be passed, but
really a factory function which is used for computing the actual
lookup key when doing inserts and lookups (which then implicitly use
the natural hash and eq functions for that lookup key, as a normal
dict does).

Regards

Antoine.




From lie.1296 at gmail.com  Sun May 30 16:56:32 2010
From: lie.1296 at gmail.com (Lie Ryan)
Date: Mon, 31 May 2010 00:56:32 +1000
Subject: [Python-ideas] An identity dict
In-Reply-To: <loom.20100530T162050-351@post.gmane.org>
References: <loom.20100530T052013-34@post.gmane.org>	<htta0r$9l5$1@dough.gmane.org>
	<loom.20100530T162050-351@post.gmane.org>
Message-ID: <httueo$3de$1@dough.gmane.org>

On 05/31/10 00:23, Benjamin Peterson wrote:
> Lie Ryan <lie.1296 at ...> writes:
>> what's wrong with dict[id(key)] = foo?
> 
> For one, you can't get the value of the key out of the dict.

mydict[id(key)] = (key, value)

>> that their id() is expensive is implementation details, and the
>> developer of PyPy should solve that instead of adding a clutch to the
>> stdlib.
> 
> A "clutch"? Even ignoring PyPy, an identitydict is still a useful primitive.

it may be useful, but if you can emulate it relatively easily with
regular dict, why bother with a new type?



From benjamin at python.org  Sun May 30 17:20:41 2010
From: benjamin at python.org (Benjamin Peterson)
Date: Sun, 30 May 2010 15:20:41 +0000 (UTC)
Subject: [Python-ideas] An identity dict
References: <loom.20100530T052013-34@post.gmane.org>	<htta0r$9l5$1@dough.gmane.org>
	<loom.20100530T162050-351@post.gmane.org>
	<httueo$3de$1@dough.gmane.org>
Message-ID: <loom.20100530T171844-232@post.gmane.org>

Lie Ryan <lie.1296 at ...> writes:
> it may be useful, but if you can emulate it relatively easily with
> regular dict, why bother with a new type?

Why defaultdict then? It can be implemented just fine with dict.setdefault.
identitydict avoids the unnatural method of having the key and value as value of
the dictionary, resulting in contortions everytime the dictionary is manipulated.






From grosser.meister.morti at gmx.net  Sun May 30 17:34:19 2010
From: grosser.meister.morti at gmx.net (=?ISO-8859-1?Q?Mathias_Panzenb=F6ck?=)
Date: Sun, 30 May 2010 17:34:19 +0200
Subject: [Python-ideas] reiter: decorator to make generators reiterable
Message-ID: <4C02857B.2030502@gmx.net>

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.


From mikegraham at gmail.com  Sun May 30 19:04:39 2010
From: mikegraham at gmail.com (Mike Graham)
Date: Sun, 30 May 2010 12:04:39 -0500
Subject: [Python-ideas] An identity dict
In-Reply-To: <loom.20100530T052013-34@post.gmane.org>
References: <loom.20100530T052013-34@post.gmane.org>
Message-ID: <AANLkTil0HAqVqet0iVjZ7fO_iW8fJUSL-rBOI6C80AdR@mail.gmail.com>

What is the use case for such a collection? (This will help answer
questions about how stuff like comparing two identity dicts or an
identity dict and another mapping will work.)

By default, objects __eq__ and __hash__ methods allow them to be used
in dicts by identity. When I define __eq__ to mean something else, I
find that I don't typically have something I can really store in a
dict with the behavior I want.

Should an ID Dict really be a weak ref identity dict? The one time I
wanted an ID dict is when I was writing a memoization routine for
methods, where I wanted to store the caches for each object.
(Incidentally, I ended up refactoring not to require this anyhow.) Is
this the main basic use case? Am I missing something?

Best regards,
Mike


On Sat, May 29, 2010 at 10:27 PM, Benjamin Peterson <benjamin at python.org> wrote:
> 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


From daniel at stutzbachenterprises.com  Sun May 30 21:37:18 2010
From: daniel at stutzbachenterprises.com (Daniel Stutzbach)
Date: Sun, 30 May 2010 15:37:18 -0400
Subject: [Python-ideas] An identity dict
In-Reply-To: <20100530123400.726a9fe1@pitrou.net>
References: <loom.20100530T052013-34@post.gmane.org>
	<20100530123400.726a9fe1@pitrou.net>
Message-ID: <AANLkTikompBzNPJELwGat39maekuLwH4Bcg-q3mZ1RyL@mail.gmail.com>

On Sun, May 30, 2010 at 6:34 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:

> Perhaps it would be more useful to add a generic
> collections.keyfuncdict, taking a function which applied to a key
> gives the real key value used for lookups.
> Your identity dict would be created as:
>    d = collections.keyfuncdict(id)
>

For what it's worth, my sorteddict class (part of the blist library) already
supports exactly that syntax.  The full signature is:

sorteddict([key[, arg]], **kw)

where "arg" and "kw" do exactly what they do for dict(), and "key" specifies
a key function just as in your example.  (Although now that I think about
it, perhaps "arg" and "key" should be reversed to more closely match the
signature of dict())

Example usage:

>>> from blist import sorteddict
>>> d = sorteddict(id)
>>> d[(1,2)] = True
>>> d[(1,2)] = True
>>> d.keys()
[(1, 2), (1, 2)]

I'm not suggesting that Benjamin use sorteddict for his use-case, since
keeping the keys sorted by id() is probably not useful. ;-)

In some ways it would be nice if dict() itself accepted a "key" function as
an argument, but I don't see a way to provide that functionality without
adding another field to PyDictObject (yuck) or abusing the ma_lookup field
(again, yuck).

I favor adding the more general keyfuncdict over identitydict.
--
Daniel Stutzbach, Ph.D.
President, Stutzbach Enterprises, LLC <http://stutzbachenterprises.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20100530/04f719f6/attachment.html>

From mal at egenix.com  Sun May 30 23:16:27 2010
From: mal at egenix.com (M.-A. Lemburg)
Date: Sun, 30 May 2010 23:16:27 +0200
Subject: [Python-ideas] An identity dict
In-Reply-To: <loom.20100530T052013-34@post.gmane.org>
References: <loom.20100530T052013-34@post.gmane.org>
Message-ID: <4C02D5AB.9000207@egenix.com>

Benjamin Peterson wrote:
> 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.

Are you sure this is a good idea for the stdlib ?

id(obj) gives you the current storage address of an object
in CPython and these can be reused over time.

Using a key object to such a dict would not secure it's persistence
throughout the usage lifetime in that dict, since d[id(key)] = 1
doesn't increase the refcount of key.

Such reuse is bound to happen often for some Python object
types, due to the free-lists we're using in CPython and
the Python allocator which is optimized for reuse of
fixed-size memory chunks.

For experts, such a dictionary may have some value (e.g. to
work around the hash() requirement of normal dictionaries),
but I feel that newbies would have a hard time understanding
all the implications.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, May 30 2010)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________
2010-07-19: EuroPython 2010, Birmingham, UK                49 days to go

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/


From benjamin at python.org  Mon May 31 00:17:59 2010
From: benjamin at python.org (Benjamin Peterson)
Date: Sun, 30 May 2010 22:17:59 +0000 (UTC)
Subject: [Python-ideas] An identity dict
References: <loom.20100530T052013-34@post.gmane.org>
	<4C02D5AB.9000207@egenix.com>
Message-ID: <loom.20100531T001657-635@post.gmane.org>

M.-A. Lemburg <mal at ...> writes:
> Are you sure this is a good idea for the stdlib ?
> 
> id(obj) gives you the current storage address of an object
> in CPython and these can be reused over time.

But since the dictionary will hold a reference to the key, it won't be reused.

> For experts, such a dictionary may have some value (e.g. to
> work around the hash() requirement of normal dictionaries),
> but I feel that newbies would have a hard time understanding
> all the implications.

I'm not proposing a dictionary that would not hold a reference to its keys.






From lorgandon at gmail.com  Mon May 31 00:34:59 2010
From: lorgandon at gmail.com (Imri Goldberg)
Date: Mon, 31 May 2010 01:34:59 +0300
Subject: [Python-ideas] An identity dict
In-Reply-To: <htta0r$9l5$1@dough.gmane.org>
References: <loom.20100530T052013-34@post.gmane.org>
	<htta0r$9l5$1@dough.gmane.org>
Message-ID: <AANLkTikaoiKZ-TDUKXtfx6U3Y2tQkEGmY9PF0o7k3Ltg@mail.gmail.com>

On Sun, May 30, 2010 at 12:07 PM, Lie Ryan <lie.1296 at gmail.com> wrote:

> On 05/30/10 13:27, Benjamin Peterson wrote:
> > 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.
>

My 2 bits:

1. I implemented and used such a dict a few years ago, as part of a
graph/tree algorithm. While I don't have access to the source anymore, I
mainly wanted to bring up an example for the usage of such a data structure.
Still, I haven't needed it since, so take from it what you will.


> what's wrong with dict[id(key)] = foo?
>

2. Mostly that you want other operators to work as well. In your example,
"key in dic" will return False, as __contains__ is the standard
implementation.

Cheers,
Imri

-- 
Imri Goldberg
--------------------------------------
http://plnnr.com/ - automatic trip planning
http://www.algorithm.co.il/blogs/
--------------------------------------
-- insert signature here ----
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20100531/7e4a5add/attachment.html>

From greg.ewing at canterbury.ac.nz  Mon May 31 02:37:27 2010
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Mon, 31 May 2010 12:37:27 +1200
Subject: [Python-ideas] An identity dict
In-Reply-To: <AANLkTil0HAqVqet0iVjZ7fO_iW8fJUSL-rBOI6C80AdR@mail.gmail.com>
References: <loom.20100530T052013-34@post.gmane.org>
	<AANLkTil0HAqVqet0iVjZ7fO_iW8fJUSL-rBOI6C80AdR@mail.gmail.com>
Message-ID: <4C0304C7.6010908@canterbury.ac.nz>

Mike Graham wrote:

> Should an ID Dict really be a weak ref identity dict? ... Is
> this the main basic use case?

No, I don't think it's the main use case, although if an
identitydict is added, it would make sense to also add a
WeakIdentityDict to the weakref module.

-- 
Greg


From greg.ewing at canterbury.ac.nz  Mon May 31 02:30:25 2010
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Mon, 31 May 2010 12:30:25 +1200
Subject: [Python-ideas] An identity dict
In-Reply-To: <loom.20100530T162050-351@post.gmane.org>
References: <loom.20100530T052013-34@post.gmane.org>
	<htta0r$9l5$1@dough.gmane.org>
	<loom.20100530T162050-351@post.gmane.org>
Message-ID: <4C030321.4050803@canterbury.ac.nz>

Benjamin Peterson wrote:
> Lie Ryan <lie.1296 at ...> writes:
> 
>>what's wrong with dict[id(key)] = foo?
> 
> For one, you can't get the value of the key out of the dict.

Another thing is that it doesn't keep the key object
alive, so if the app doesn't do anything else to ensure
this, it's possible for the key to disappear and be
replaced by another object having the same id.

-- 
Greg


From raymond.hettinger at gmail.com  Mon May 31 06:11:54 2010
From: raymond.hettinger at gmail.com (Raymond Hettinger)
Date: Sun, 30 May 2010 21:11:54 -0700
Subject: [Python-ideas] An identity dict
In-Reply-To: <httueo$3de$1@dough.gmane.org>
References: <loom.20100530T052013-34@post.gmane.org>	<htta0r$9l5$1@dough.gmane.org>
	<loom.20100530T162050-351@post.gmane.org>
	<httueo$3de$1@dough.gmane.org>
Message-ID: <79AAB0F9-3775-40A4-9408-2A8286FC6EDB@gmail.com>


On May 30, 2010, at 7:56 AM, Lie Ryan wrote:

> On 05/31/10 00:23, Benjamin Peterson wrote:
>> Lie Ryan <lie.1296 at ...> writes:
>>> what's wrong with dict[id(key)] = foo?


 . . .

>> 
> 
> it may be useful, but if you can emulate it relatively easily with
> regular dict, why bother with a new type?

I agree that this would be a waste.

Also, I haven't seen much of a discussion of use cases.
It's been possible to make identity dictionaries for a very
long time, yet I can't remember the last time I saw one used.
The Python language makes very few guarantees about
object identity so it is mainly only usable in a few circumstances
where an object is continually referenced by something outside
the identity dict.

I would like to see an identity dict posted an ASPN recipe
to see if anyone actually uses it.


Raymond
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20100530/464b4412/attachment.html>

From raymond.hettinger at gmail.com  Mon May 31 19:25:30 2010
From: raymond.hettinger at gmail.com (Raymond Hettinger)
Date: Mon, 31 May 2010 10:25:30 -0700
Subject: [Python-ideas] An identity dict
In-Reply-To: <4C030321.4050803@canterbury.ac.nz>
References: <loom.20100530T052013-34@post.gmane.org>
	<htta0r$9l5$1@dough.gmane.org>
	<loom.20100530T162050-351@post.gmane.org>
	<4C030321.4050803@canterbury.ac.nz>
Message-ID: <89E5DB78-B304-4A9F-B140-96888B2FCCC7@gmail.com>


On May 30, 2010, at 5:30 PM, Greg Ewing wrote:

> Benjamin Peterson wrote:
>> Lie Ryan <lie.1296 at ...> writes:
>>> what's wrong with dict[id(key)] = foo?
>> For one, you can't get the value of the key out of the dict.
> 
> Another thing is that it doesn't keep the key object
> alive, so if the app doesn't do anything else to ensure
> this, it's possible for the key to disappear and be
> replaced by another object having the same id.

If you don't have an external reference to the object,
how are you ever going to look it up in the dictionary?

Since we can attach values directly to many objects
(using instance variables, function attributes, etc) 
or can keep them in a tuple, there appear to be remarkably 
few use cases for an identity dictionary.

Also, there hasn't been much discussion of implementation,
but unless you're willing to copy and paste most of the
code in dictobject.c, you're going to end-up with something
much slower than d[id(obj)]=value.


Raymond





From tjreedy at udel.edu  Mon May 31 20:05:57 2010
From: tjreedy at udel.edu (Terry Reedy)
Date: Mon, 31 May 2010 14:05:57 -0400
Subject: [Python-ideas] An identity dict
In-Reply-To: <79AAB0F9-3775-40A4-9408-2A8286FC6EDB@gmail.com>
References: <loom.20100530T052013-34@post.gmane.org>	<htta0r$9l5$1@dough.gmane.org>	<loom.20100530T162050-351@post.gmane.org>	<httueo$3de$1@dough.gmane.org>
	<79AAB0F9-3775-40A4-9408-2A8286FC6EDB@gmail.com>
Message-ID: <hu0tq6$ai7$1@dough.gmane.org>

It appears that different people are talking about two different ideas 
of identity dict, with different properties and possible use cased. So 
the statement of some do not apply to the idea held by others.

A. key object is not stored in dict.
    d[k] = o ==> _d[id(k)] = o
Faster but limited in that cannot extract keys and user code must keep 
keys alive.

B. key object stored in dict in one of at least two ways.
    1. d[k] = o ==> _d[id(k)] = (k,o)
    2. d[i] = o ==> i=id(k); _dk[i] = k; _do[i] = o
Slower, but (I believe) can fully emulate dicts.

Either type can be generalized to f instead of id as the key transform.


current vote: -.3
I am also not yet convinced, but perhaps could be, that either type, 
with or without generalization should be in the stdlib. Instances of 
user class without custom equality are already compared by identity. The 
use cases for keying immutables by identify is pretty sparse. That 
pretty much leave mutables with custom equality (by value rather than 
identity).

Terry Jan Reedy