Re: [Python-Dev] Looking for Memories of Python Old-Timers
Just to remember 10 years ago was the python 1.3 release. I can't remember how long I use python but I can remember the first release I used. Use the cvs (svn) history of tags to get the date: http://svn.python.org/view/python/tags/ I hope this helps. :-) 2006/5/23, Guido van Rossum <[EMAIL PROTECTED]>: > How long have you used Python? 10 years or longer? Please tell us how > you first heard of the language, how you first used it, and how you > helped develop it (if you did). More recent reminiscences are welcome > too! -- bye by Wolfgang ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.5 schedule
Neal Norwitz wrote: > Anthony's schedule is a bit up in the air which means this schedule > does not reflect what reality will be. Perhaps we will skip a3 > altogether which will give more time in a sense, though not in reality > since b1 in that case will hopefully be on or before June 14. FWIW: > > alpha 3: May 25, 2006 [planned] > beta 1: June 14, 2006 [planned] > beta 2: July 6, 2006 [planned] > rc 1:July 27, 2006 [planned] > final: August 3, 2006 [planned] > > As for wanting to get more things in, people ought to communicate that > here. If there's something that should be added to the PEP, everyone > needs to know. Skipping alpha 3 wouldn't be a problem for the functional->functools move (and the new functools functions), which is the only thing I really want to get in before beta 1. Any errors created by that should be shallow ones that Buildbot will pick up. So no objections here to going straight from a2 to b1 (although I'll try to get the module move done this week anyway). Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Looking for Memories of Python Old-Timers
2006/5/23, Guido van Rossum <[EMAIL PROTECTED]>: > How long have you used Python? 10 years or longer? Please tell us how > you first heard of the language, how you first used it, and how you > helped develop it (if you did). More recent reminiscences are welcome > too! I'm almost at the 10 year mark now. I'll just blab a bit. I'm a C guy from way back. Back in the '80s I liked C, but by the mid-90s I was pretty tired of working at such a low level, having to do so much code to do string manipulations, having to cut-and-paste code for getting dynamic list code, etc... I liked that C was small and I could hold it all in my head, but it was just too low-level. The problem was that I was starting to lose my immortality. As I grew older I just wanted to be more productive so I'd spend less time doing the same damn thing over and over just to make progress. Because I liked C, I really wanted C++ to be an option. In 1995 I tried out C++, but the compilers and environment then were extremely immature. Templates were horrible. I spent about 6 to 9 months giving it the "college-try". It just wasn't workable then though. Next I tried Perl, another 6 to 9 months. It made me realize that a "scripting language" could be fast enough for much of what I was doing, and the POSIX-like API was very familiar to my C and Unix background. However, I never got comfortable with Perl, just passing lists to functions never seemed to work the way I expected. Then I tried Java, only for about 3 months. I mostly liked the language, though it was much to "object-centric" for my taste. By that, I mean even a simple "hello world" program HAS to be an object. My biggest complaint was that in 1997, Java under Linux was in a horrible state. Long running processes would leak horribly, compiling was slow even on my mighty, mighty dual PPro 200 box, and anything I wrote in Java was 32MB of RAM just to start, even without the memory leaking. A friend of mine, John Shipman, mentioned right around then that he was learning Python and really liking it. I took a look at it shortly after Evelyn and I moved to our new house in 1998. Python was everything I had wanted C++ to be. Like C, it was simple and easy to keep in my head. It had a rich library, which appealed to my desires for having to write less code. It was operating at such a high level that I felt productive. I was working with an ISP at the time, and there was this Perl application that generated accounting reports of dial-in user activity. It had bugs where it would generate slightly or sometimes vastly wrong data. Worse, it used RAM for holding all the data to generate the accounting. It was pretty easy to fill up all the memory for even small or medium ISPs records. My first program was a re-implementation of the Perl program, with fewer bugs. I also used the shelve library to keep the accounting data out of RAM. It worked brilliantly. Mostly I haven't done as much development as I would like. I built a lot of the Python RPMs for Linux, which is my primary contribution. I also have done some documentation changes and have added the string.rfind() methods. I've done a few things on pydotorg for the web-site, including sprinting on the new site at PyCon. Sean -- The price of freedom is responsibility, but it's a bargain because freedom is priceless. -- Hugh Downs Sean Reifschneider, Member of Technical Staff <[EMAIL PROTECTED]> tummy.com, ltd. - Linux Consulting since 1995: Ask me about High Availability ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Changing python int to "long long".
We've been discussing the possibility of converting the Python int type to long long (from long). I played around with it some, and it's going to be a huge change that probably will break most C extensions until. However, as uncletimmy says, "Python is so stinking slow" that it probably won't make much of a negative impact on the performance. The reason we're looking at this at Need for Speed is that EWT has a lot of code that uses ints between the 32 and 64 bit range. It'd be a hard change to make to convert to long long for regular ints. I'm going to speak with John and Runar today about if we can make just a long long extension type and live with it not integrating with other type coercion as well as an int would. The big deal right now is on 32 bit platforms, giving the 64-bits for int. However, it will also be a win for 64-bit platforms for ints that fall between 64 and 128 bits. So, I ran pybench on a half-arsed conversion of ints to long long, and only lost around 1.11% over all. However, for simple math I got a solid 25% speed-up (n = i << 33) * 2) + 1) / 3) - 2), and for 1<<35 I got a 34% speed up, compared with them getting converted to Python longs. For ints that will fit entirely within 32-bits, I'm seeing around 11% worse performance when going to 64-bit types. This is all on the 2.5 trunk. My conclusion is that it's probably enough of a performance drop that we can't just do it wholesale. It has a big gain for ints within 32 and 64 on 32-bit platforms, but for <32-bit ints it's going to be pretty bad. Within the next few years many platforms, particularly performance-critical ones, will probably be 64 bit anyway, so fewer people will probably be able to see an advantage to it. The ideal would probably be to have another int type and up-convert to a long long, THEN go to arbitrary precision, but that's a pretty big change. Less big than converting the int to long long though. The easiest would be to make an extension that has long long, if that will work for speeding up applications like EWT has. I'll follow up with them on this. Any thoughts on this? Thanks, Sean -- Linux: When you need to run like a greased weasel. -- Sean Reifschneider, 1998 Sean Reifschneider, Member of Technical Staff <[EMAIL PROTECTED]> tummy.com, ltd. - Linux Consulting since 1995: Ask me about High Availability ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Decimal and Exponentiation
2006/5/19, Tim Peters <[EMAIL PROTECTED]>: > If you're not a numeric expert, I wouldn't recommend that you try this > yourself (in particular, trying to implement x**y as exp(ln(x)*y) > using the same precision is mathematically correct but is numerically > badly naive). I'd start to see this not before two weeks (I have a conference, and need to finish my papers). TIm, we both know that I'm not, under any point of view, a numeric expert. So, I'd ask you a favor. Could you please send here some examples, for a given precision, of perilous "not-int ** not-int" situations, just to add them to the test cases and be sure that the modifications to Decimal are safe enough? Or just point to some docs? Thank you very much! -- .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Decimal and Exponentiation
[Facundo Batista] > I'd start to see this not before two weeks (I have a conference, and > need to finish my papers). > > TIm, we both know that I'm not, under any point of view, a numeric > expert. So, I'd ask you a favor. > > Could you please send here some examples, for a given precision, of > perilous "not-int ** not-int" situations, just to add them to the test > cases and be sure that the modifications to Decimal are safe enough? > > Or just point to some docs? This is all part of IBM's spec (31 Mar 2006) now: http://www2.hursley.ibm.com/decimal/decarith.html Here's the change log from December: """ Changes in Draft 1.50 (9 December 2005) * The exp operation for raising e to a power has been added. * The ln natural logarithm and log10 base 10 logarithm operations have been added. * The power operation has been redefined to allow raising a number to a non-integral power. """ The change log for the test vectors (at the same site) implies the tests have also been updated to match: """ Changes in Version 2.35 (27 November 2005) * The exp, ln, and log10 operations and testcase groups have been added. * The power testcase group has been greatly extended, to cover non-integer second operands, and the powersqrt testcase group has been added. """ So tests probably aren't a problem. Implementation will be, and I'll do that if I can -- designing efficient arbitrary-precision transcendental functions is an obscure skill. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r46064 - in python/trunk: Include/Python.h Include/pyport.h Misc/ACKS Misc/NEWS Modules/_localemodule.c Modules/main.c Modules/posixmodule.c Modules/sha512module.c P
- Original Message - From: ""Martin v. Löwis"" <[EMAIL PROTECTED]> To: "Neal Norwitz" <[EMAIL PROTECTED]> Cc: "Python Dev" Sent: Tuesday, May 23, 2006 2:38 PM Subject: Re: [Python-Dev] [Python-checkins] r46064 - in python/trunk: Include/Python.h Include/pyport.h Misc/ACKS Misc/NEWS Modules/_localemodule.c Modules/main.c Modules/posixmodule.c Modules/sha512module.c PC/pyconfig.h Python/thread_nt.h > Neal Norwitz wrote: >> What is the reason for the DONT_HAVE_* macros? Can we use the HAVE_* >> versions? > > I think the actual rationale is that the contributor didn't want to be > bothered with modifying configure.in, and running autoconf. I thought that smaller patches would generally be preferred, but yes it is also more effort to modify configure, especially when doing development on Windows. In the case of errno.h there was already 3 occurrences of DONT_HAVE_ERRNO_H in the source and no occurrences of HAVE_ERRNO_H, and I wanted to be consistent. > I accepted the change since systems which don't have, say, , > are "unusual", in the sense that they aren't standard C systems > (as standard C mandates errno.h, atleast in a hosted environment). > So far, only one target platform doesn't have these things (Windows > CE), so the reasoning is that the burden of setting things right > should be on that system. Yes, this is also my reasoning and is supported by the comments in Include/pyport.h about sys/stat.h. > Of course, it would be fairly straight-forward to convert this > to standard autoconf machinery (if one remembers to update > PC/pyconfig.h accordingly). I'm sure Luke Dunstan would be willing > to revise the patch in that direction if that is agreed. > > Regards, > Martin Yes, I can do that. But what about the other 3 versions of pyconfig.h in platform subdirectories? Luke ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Changing python int to "long long".
On 5/23/06, Sean Reifschneider <[EMAIL PROTECTED]> wrote: > We've been discussing the possibility of converting the Python int type to > long long (from long). I played around with it some, and it's going to be > a huge change that probably will break most C extensions until. However, > as uncletimmy says, "Python is so stinking slow" that it probably won't > make much of a negative impact on the performance. Based on the stability picture alone I think this must wait for 2.6. > The reason we're looking at this at Need for Speed is that EWT has a lot of > code that uses ints between the 32 and 64 bit range. It'd be a hard change > to make to convert to long long for regular ints. I'm going to speak with > John and Runar today about if we can make just a long long extension type > and live with it not integrating with other type coercion as well as an int > would. Actually it should be able to integrate almost perfectly given that 2.5 has __index__. > The big deal right now is on 32 bit platforms, giving the 64-bits for int. > However, it will also be a win for 64-bit platforms for ints that fall > between 64 and 128 bits. But who needs those? And who says that long long is 128 bits on a 64-bit machine? (At least on Windows 64, long is still 32 bit, so I expect long long to be 64 bit there.) > So, I ran pybench on a half-arsed conversion of ints to long long, and only > lost around 1.11% over all. However, for simple math I got a solid 25% > speed-up (n = i << 33) * 2) + 1) / 3) - 2), and for 1<<35 I got a 34% > speed up, compared with them getting converted to Python longs. > > For ints that will fit entirely within 32-bits, I'm seeing around 11% worse > performance when going to 64-bit types. > > This is all on the 2.5 trunk. > > My conclusion is that it's probably enough of a performance drop that we > can't just do it wholesale. It has a big gain for ints within 32 and 64 > on 32-bit platforms, but for <32-bit ints it's going to be pretty bad. > Within the next few years many platforms, particularly performance-critical > ones, will probably be 64 bit anyway, so fewer people will probably be able > to see an advantage to it. Indeed. I say EWT can solve the problem much cheaper by using 64-bit hardware, compared to the cost imposed on the rest of the world. > The ideal would probably be to have another int type and up-convert to a > long long, THEN go to arbitrary precision, but that's a pretty big change. > Less big than converting the int to long long though. The easiest would be > to make an extension that has long long, if that will work for speeding up > applications like EWT has. I'll follow up with them on this. > > Any thoughts on this? In 2.6, I'd be okay with standardizing int on 64 bits everywhere (I don't think bothering with 128 bits on 64-bit platforms is worth it). In 2.5, I think we should leave this alone. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] SSH key for work computer
Can someone install the attached SSH key (it's for my work machine)? The fingerprint is:: cd:69:15:52:b2:e5:dc:2e:73:f1:62:1a:12:49:2b:a1 [EMAIL PROTECTED]Also, how hard is it to have a specific key uninstalled? The reason I ask is that my internship is only for three months so that after that the key won't be valid. -Brett id_dsa.pub Description: Binary data ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] 2.5 schedule
Thomas Wouters wrote: > The fact that much testing goes on between releases > as well makes the alphas even less important. I suspect the amount of MS Windows testing done between releases is fairly small. And what little there is doesn't always use the same compiler that will eventually be used for the final release. A snapshot build would fill this gap almost as well as a formal alpha. -jJ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] SSH key for work computer
[Brett Cannon]
> Can someone install the attached SSH key (it's for my work machine)? The
> fingerprint is::
>
> cd:69:15:52:b2:e5:dc:2e:73:f1:62:1a:12:49:2b:a1
> [EMAIL PROTECTED]
I tried. Scream at someone else if it didn't work ;-)
> Also, how hard is it to have a specific key uninstalled?
While I have yet to try that, it appears dead easy, provided you
remember the comment on the key in question ("[EMAIL PROTECTED]" in
this case).
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r46064 - in python/trunk: Include/Python.h Include/pyport.h Misc/ACKS Misc/NEWS Modules/_localemodule.c Modules/main.c Modules/posixmodule.c Modules/sha512module.c P
Luke Dunstan wrote: > Yes, I can do that. But what about the other 3 versions of pyconfig.h in > platform subdirectories? If you think you can fix them, go ahead and include changes; no need to test these changes. If they are wrong, some user of the platform will hopefully provide fixes. Likewise, if you don't think you can fix them, don't bother - some user of the platform will provide the missing pieces. Or, if no contributions from a user arrive, it either means that it just works fine, or that there are no users. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Changing python int to "long long".
Sean Reifschneider wrote: > The big deal right now is on 32 bit platforms, giving the 64-bits for int. > However, it will also be a win for 64-bit platforms for ints that fall > between 64 and 128 bits. As Guido suggests: long long isn't 128 bits on most 64-bit platforms (AFAIK). > My conclusion is that it's probably enough of a performance drop that we > can't just do it wholesale. It has a big gain for ints within 32 and 64 > on 32-bit platforms, but for <32-bit ints it's going to be pretty bad. > Within the next few years many platforms, particularly performance-critical > ones, will probably be 64 bit anyway, so fewer people will probably be able > to see an advantage to it. I'm more worried about the actual breakage instead of the speed loss. For example, what will the "i" modifier for PyArg_ParseTuple do? What will PyInt_AsLong do? What about systems where "long long" is not supported? Not that those can't be resolved (they were resolved, in some way or the other, for ssize_t). However, I think a complete specification of the proposed changes should be available before integrating this into Python. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Changing python int to "long long".
[Guido] > ... > In 2.6, I'd be okay with standardizing int on 64 bits everywhere (I > don't think bothering with 128 bits on 64-bit platforms is worth it). > In 2.5, I think we should leave this alone. Nobody panic. This wasn't on the table for 2.5, and as Martin points out it needs more specification regardless. If the current ~10% slowdown for 32-bit ints in its presence (as measured by something ;-)) persists, I expect it would have a justfiably hard time getting into 2.6. I'm blessing small language changes at the sprint, but so far (and I expect going on) they're harmless. For example, Georg Brandl wanted to change PyErr_NewException() to accept a tuple of base classes, because some of the decimal module's exceptions have multiple bases and coding that bit in C was needlessly convoluted without liberating PyErr_NewException() from its historic single-inheritance limitation. I think that's fine, so approved it. Nevertheless, if someone feels a patch committed to the trunk goes over the edge, do complain to me: it's my job to push back here when needed. OTOH, I expect other "wild ideas" from the sprint to be brought up here, and when they are please just assume that they're not being proposed for 2.5 unless that's explicitly stated. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.5 schedule
Ok - we're going to skip the 3rd alpha, and the next release will be beta1, currently scheduled for June 14th. With all the changes this week from the needforspeed sprint, cutting a release seems like too much of a risk. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PySequence_Fast_GET_ITEM in string join
The Sourceforge tracker is kaputt so I'm sending it here, in part
because the effbot says it's interesting.
I can derive from list and override __getitem__
>>> class Spam(list):
... def __getitem__(self, i):
... print i
... return 2
...
>>> Spam()[1]
1
2
>>> Spam()[9]
9
2
>>>
Now consider the following
>>> class Spam(list):
... def __getitem__(self, i):
... print "Asking for", i
... if i == 0: return "zero"
... if i == 1: return "one"
... raise IndexError, i
...
>>> Spam()[1]
Asking for 1
'one'
>>>
Spiffy! For my next trick
>>> "".join(Spam())
''
>>>
The relevant code in stringobject uses PySequence_Fast_GET_ITEM(seq, i),
which likely doesn't know about my derived __getitem__.
p = PyString_AS_STRING(res);
for (i = 0; i < seqlen; ++i) {
size_t n;
item = PySequence_Fast_GET_ITEM(seq, i);
n = PyString_GET_SIZE(item);
memcpy(p, PyString_AS_STRING(item), n);
p += n;
if (i < seqlen - 1) {
memcpy(p, sep, seplen);
p += seplen;
}
}
The Unicode join has the same problem
>>> class Spam(list):
... def __getitem__(self, i):
... print "Asking for", i
... if i == 0: return "zero"
... if i == 1: return u"one"
... raise IndexError, i
...
>>> "".join(Spam())
''
While if my class is not derived from list, everything is copacetic.
>>> class Spam:
... def __getitem__(self, i):
... print "Asking for", i
... if i == 0: return "zero"
... if i == 1: return u"one"
... raise IndexError, i
...
>>> "".join(Spam())
Asking for 0
Asking for 1
Asking for 2
u'zeroone'
>>>
Ditto for deriving from object.
>>> class Spam(object):
... def __getitem__(self, i):
... print "Asking for", i
... if i == 0: return "zero"
... if i == 1: return "one"
... raise IndexError, i
...
>>> "".join(Spam())
Asking for 0
Asking for 1
Asking for 2
'zeroone'
>>>
Andrew
[EMAIL PROTECTED]
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PySequence_Fast_GET_ITEM in string join
Me [Andrew Dalke] said: > The relevant code in stringobject uses PySequence_Fast_GET_ITEM(seq, > i), > which likely doesn't know about my derived __getitem__. Oops, I didn't know what the code was doing well enough. The relevant problem is seq = PySequence_Fast(orig, ""); That calls __iter__ on my derived list object, which knows nothing about my overridden __getitem__ So things are working as designed. Well, back to blundering about. Too much brennivin. ;) Andrew [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
