Re: [Python-Dev] Fwd: Anyone still using Python 2.5?
On Wed, Dec 21, 2011 at 07:42:45AM -0500, Barry Warsaw wrote: FWIW, Ubuntu dropped 2.5 quite a while ago. The next LTS (long term support) That's true for *CURRENT* releases, however Ubuntu still supports Python 2.5 via 8.04 LTS (end of life in April 2013). Lucid is 2.6 and goes EOL in 2015. Red Hat Enterprise is a bit more difficult a situation. They currently still have active support for Python 2.3 in RHEL 4, but that comes up to EOL in just a couple of months (Feb 2012). But they have this extended life cycle that ends in Feb 2015. RHEL 5 has python 2.4.3 and has an EOL of April 2014 (April 2017 for extended life cycle). There was a fairly large lag between RHEL 5 and RHEL 6 (almost 4 years), so there are a *LOT* of RHEL 5 systems out there. RHEL 6 has Python 2.6.6, BTW. This is why I recently released the ineedpy2 package so that your program can request and search for specific versions of Python on a multi-python system. We have a number of systems that have Python 2.3 and older on them, but many of those systems have newer Pythons also available as alternate names. We recommend that whenever possible customers target deploying against the system python, meaning version 2.4.3 if they are deploying on CentOS 5. Because otherwise security updates of Python and *all the libraries they depend on* need to be tracked manually. Some customers decide to go one route, some to go the other, but that is our recommendation. Ideally, you are building your apps to target a production environment, not just using the latest and greatest Python without compelling reasons. So, yes, people are still using Python 2.5 and 2.4. Mostly this is people who have already deployed apps and are either fixing/updating them, or are adding new applications that they want to target the same production environment rather than setting up a new environment. Sean -- Linux, because eventually you grow up enough to be trusted with a fork(). Sean Reifschneider, Member of Technical Staff j...@tummy.com 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] Enhanced tracker privileges for dangerjim to do triage.
On Sun, Apr 25, 2010 at 08:42:00PM -0400, Terry Reedy wrote: What is *his* interest? How long has he known and used Python? Good points have been made on both sides of the issue here. Despite my having a vested interest, I really have no strong feelings one way or another on the initial request. But, the answers to your questions above may make it more clear why I was looking for the enhanced privileges. James (dangerjim) has *NO* knowledge of Python -- he has done primarily C and Java coding. He *DOES* have time on his hands. This is why I proposed to him to do tracker triage. However, as I started walking him through some examples of triage, I realized that regular accounts don't have the privileges to do any of the things I was proposing. For example: Go into the list of task tasks and look at the ones with no priority. Read through the description and any follow-ups and try to figure out what priority to give it. In most cases it will be normal. However, for some issues it will be clear they should be a higher or lower priority, even to someone who doesn't know Python. Then we went on to issue 5575 and read through it. In reading this one to determine the priority, it was clear that the ball was back in Collin's court, so I showed that I would look to see if Collin was a valid assignee (which he was) and assign it to him, with a comment about why. Go into old bugs that have patches, and see if the patches cleanly apply against the trunk. If they do, do a make and make test. Add a comment with the outcome. Two of the 3 easiest things I came up with for an outsider to help out with, are things that his account couldn't do. But, as I said above, I'm fine with having him push those changes through me and I can make them when he can't. Thanks, Sean -- It was a sneaky lawyer's trick, and I fell for it. Because... She's much smarter than me. -- _High_Fidelity_ Sean Reifschneider, Member of Technical Staff j...@tummy.com 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] Enhanced tracker privileges for dangerjim to do triage.
I'm trying to get a good friend of mine to start doing bug triage on Python. As part of my trying to mentor him on it, I've found that many of the common things I do in triage, like setting a priority for priorityless bugs, assigning them to people who obviously are the next step, requires enhanced privileges. He has no reputation in the Python community, so I'd be up for getting him started on things that require fewer privileges like verifying older patches still apply against newer Pythons, or maybe summarizing priority/assignment changes to the list and having someone (possibly me) make the changes, etc... However, I will step up for him and say that I've known him a decade, and he's very trustworthy. He has been the president (we call that position Maximum Leader) of our Linux Users Group here for 5 years or so. Thoughts? Thanks, Sean -- Sean Reifschneider, Member of Technical Staff j...@tummy.com tummy.com, ltd. - Linux Consulting since 1995: Ask me about High Availability signature.asc Description: OpenPGP digital signature ___ 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] Bug? syslog.openlog using ident python by default.
I've implemented this and put the patch in Issue8451: http://bugs.python.org/issue8451 I'm happy with how it is now, including documentation, but would like some review. Thanks, Sean -- Sean Reifschneider, Member of Technical Staff j...@tummy.com tummy.com, ltd. - Linux Consulting since 1995: Ask me about High Availability signature.asc Description: OpenPGP digital signature ___ 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] Needs Review: 2to3 fixer for sys.exitfunc to atexit.
Issue 2356 ( http://bugs.python.org/issue2356 ) looks like it has a patch candidate, but just needs review to put in place. Seems like it may be low hanging fruit critical that just needs a quick review to either apply or at least get back to the folks who are working on a patch. Thanks, Sean -- The most important thing in communication is to hear what isn't being said. -- Peter Drucker Sean Reifschneider, Member of Technical Staff j...@tummy.com 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] Bug? syslog.openlog using ident python by default.
I'd appreciate some opinions on this. Personally, I'm in the the current
code is buggy camp. :-) I can code up the changes to the syslog module
if we decide that's the right way to go. Looks like Raymond, Guido, and I
are the last ones to do syslog-specific changes to this module in the last
15 years.
If you call:
from syslog import syslog, openlog
syslog('My error message')
Something like the following gets logged:
Mar 18 05:20:22 guin python: My error message
^^
Where I'm annoyed by the python in the above. This is pulled from
the C argv[0]. IMHO, what we really want is the Python sys.argv[0].
Because of this feature, I always have to do the following when I'm using
syslog:
openlog(os.path.basename(sys.argv[0]))
I would propose changing the Python syslog() call to do the C equivalent of:
if openlog_hasnt_been_called_before_now:
if sys.argv[0]:
syslog.openlog(os.path.basename(sys.argv[0]))
In other words, if there's a script name and openlog hasn't already been
called, call openlog with the basename of the script name.
This is effectively what happens in normal C code that calls syslog.
Note that the Python syslog.openlog says that the default for ident is
(usually) 'syslog'.
The benefit of this change is that you get a more identifiable ident string
in Python programs, so when you look at the logs you can tell what script
it came from, not just that it came from some Python program. One way of
looking at it would be that the syslog module logging python as the
program name is a bug.
The downside I see is that there might be some users doing log scraping
depending on this (IMHO, buggy) log ident.
Something else just occurred to me though, a nice enhancement would be for
openlog() to have a None default for ident, something like:
orig_openlog = openlog
def openlog(ident = None, logopt = 0, facility = LOG_USER)
if ident == None:
if sys.argv[0]:
ident = os.path.basename(sys.argv[0])
else:
ident = 'python'
orig_openlog(ident, logopt, facility)
So you could call openlog and rely on the default ident (sys.argv[0]),
and set the logopt and facility.
The gory details of why this is occurring are: If you don't call
openlog() before syslog(), the system syslog() function calls
something similar to: openlog(basename(argv[0])), which causes the
ident of the syslog messages to be python rather than the specific
program.
Thoughts?
Thanks,
Sean
--
Every increased possession loads us with new weariness.
-- John Ruskin
Sean Reifschneider, Member of Technical Staff j...@tummy.com
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] REVIEW: PyArg_ParseTuple with s format and NUL: Bogus TypeError detail string.
make test in both python and py3k trunks were happy with this change, so I've documented the issue in Issue #6624 and committed it in 74277 (2.x) and 74278 (3.x). Sean -- The only thing more expensive than hiring a professional is hiring an amateur. -- Red Adair, Oil Well Fire-Fighter Sean Reifschneider, Member of Technical Staff j...@tummy.com 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] REVIEW: PyArg_ParseTuple with s format and NUL: Bogus TypeError detail string.
Please review this, I'm worried that there are cases where convertitem() is
returning a string that really should be overridden by the argument help
string. However, I'm worried that this change will get rid of useful
messages (via the format ; help string), when there otherwise wouldn't
be.
PyArg_ParseTuple when handling a string format s, raises a TypeError
when the passed string contains a NUL. However, the TypeError doesn't
contain useful information.
For example:
syslog.syslog('hello\0there')
TypeError: [priority,] message string
This seems to be a thinko in Python/getargs.c at line 331:
msg = convertitem(PyTuple_GET_ITEM(args, i), format, p_va,
flags, levels, msgbuf,
sizeof(msgbuf), freelist);
if (msg) {
seterror(i+1, msg, levels, fname, message);Line 331
return cleanreturn(0, freelist);
}
This also applies to Python 3 trunk in line 390.
I think that's supposed to be msg instead of message in the last
argument. If I change it, I get:
import syslog; syslog.syslog('hello\0there')
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: must be string without null bytes, not str
I think it's safe to change message to msg because:
message is the help string [priority,] message string,
but msg contains much more useful information.
msg is in the fall back if the last argument doesn't contain useful
information argument position, but msg is never NULL.
message only is NULL if the format string doesn't contain ;.
In every case I can find in the code, convertitem() is returning a
much more useful string than the help string.
Or perhaps it should do something like:
if (msg) {
seterror(i+1, msg, levels, fname, '%s (%s)' % ( msg, message ));
Pardon my mixed C+Python, but you get the idea.
Thoughts?
Thanks,
Sean
--
[...] Premature optimization is the root of all evil.
-- Donald Knuth
Sean Reifschneider, Member of Technical Staff j...@tummy.com
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] Experiment: Adding re to string objects.
I'm mailing this to python-dev because I'd like feedback on the idea of
adding an re attribute to strings. I'm not sure if it's a good idea or
not yet, but I figure it's worth discussion. The module mentioned here
includes a class called restr() which allows you to play with s.re.
As some of you may recall, I'm not particularly fond of the recipe:
m = re.match(r'whatever(.*)', s)
if m:
m.group(1)
The other morning I came up on the idea of adding an re to strings, so
you could do things like:
if s.re.match(r'whatever(.*)'):
print s.re.group(1)
or:
if (date.re.match(r'(?Pyear\d\d\d\d)-(?Pmonth\d\d)' or
date.re.match(r'(?Pmonth\d\d)-(?Pyear\d\d\d\d)'):
print date.re.groupdict('year')
So I decided to try experimenting with it and see how I like it. I've also
thrown a bunch of other stuff into it and made a module called
filtertools:
http://pypi.python.org/pypi/filtertools/0.01
ftp://ftp.tummy.com/pub/tummy/Python/python-filtertools/
As the version number is meant to indicate, this is something that I'm
still exploring whether it is the right thing done in the right way.
Though at the moment the only thing I plan to change is that some of the
iterators (having nothing to do with adding re to string objects)
probably shouldn't consume the barrier such as the dropwhile() and
takewhile(). You might want to do something like:
fp = filtertools.reopen('mailbox')
for header in filtertools.takewhile([ r'^\S' ], fp.readlines()) :
print 'HEADER:', header.rstrip()
for continued in filtertools.takewhile([ r'^\s+\S' ], fp.readlines()) :
print 'CONTINUED:', continued.rstrip()
But, the takewhile() I will consume the first non-matching line.
Anyway, I appreciate any feedback folks have.
Thanks,
Sean
--
What we see depends on mainly what we look for.
-- John Lubbock
Sean Reifschneider, Member of Technical Staff j...@tummy.com
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] Signals+Threads (PyGTK waking up 10x/sec).
On Thu, Dec 06, 2007 at 10:55:12PM -0700, Adam Olsen wrote: That's pretty much what issue1564547 does. I think there's two marks Good point, I hadn't seen that before. * Using poll and fd's is pretty platform specific for what should be a general-purpose API I would say that this is an optimization that helps a specific set of platforms, including one that I think we really care about, the OLPC which needs it for decreased battery use. It doesn't cause breakage of other platforms, it just may not help them. Thanks, Sean -- Linux, because eventually you grow up enough to be trusted with a fork(). Sean Reifschneider, Member of Technical Staff [EMAIL PROTECTED] tummy.com, ltd. - Linux Consulting since 1995: Ask me about High Availability Back off man. I'm a scientist. http://HackingSociety.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
[Python-Dev] Signals+Threads (PyGTK waking up 10x/sec).
Overview (my reading of it): PyGTK wakes up 10x a second in it's main loop because signals may be delivered to another thread and will only get picked up if the mainloop wakes up. In the following thread: http://mail.python.org/pipermail/python-dev/2006-September/068569.html it sounds like the patch at: http://bugs.python.org/issue1564547 doesn't solve the problem. A recent gnome bug brings this issue back up: http://bugzilla.gnome.org/show_bug.cgi?id=481569 I went ahead and closed the python issue as rejected to hopefully get some more activity on it. I thought about this some, and I wondered if there was some way we could signal the sleeping thread when a signal came in on another thread. Like perhaps we could make some code to create a pipe, and put it someplace that all threads could get access to. Then, if a thread gets a signal, write on this pipe. The mainloop could include this file descriptor in the set it's watching, so it would wake up when the signal came in. Is this something Python should provide, or something PyGTK should do? If an approach like the above would work, we could make it so that select() always created this file descriptor and added it to one of the FD sets, so that it would do the right thing behind the scenes. I have no idea if this is a reasonable approach, but it's something that came to mind when I thought about the problem and was an approach I didn't see mentioned before in the discussion. Thanks, Sean -- I live my life like I type; Fast with lots of mistakes. Sean Reifschneider, Member of Technical Staff [EMAIL PROTECTED] tummy.com, ltd. - Linux Consulting since 1995: Ask me about High Availability Back off man. I'm a scientist. http://HackingSociety.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
[Python-Dev] Triage of old tracker bugs: Any use?
I've taken the week off and I'm trying to do something useful for Python in some of my time. I've basically been looking through the entries sorted by priority and least recent activity. Some items I've been able to do something with (like the immediate priority %formatting bug #1467929, and the high priority bz2 module bug #1597011). Others I've been just kind of prodding people to take some action on, just kind of getting them in front of people again. Keeping them fresh instead of just letting them stagnate... I kind of figure that something that's in high priority, that has been sitting there for 46 months, either needs to have some activity on it or should be pushed to a lower priority. I've also been tempted to try to triage some of the bugs without assigned priorities, guessing a priority, that sort of thing. Is doing this sort of triage or administration work useful? Any recommendations on what you'd like to have happen in this sort of task? Thanks, Sean -- Obtuse: Not pointed or acute. Exceeding 90 degrees but less than 180 degrees. OOOooh! Rounded at the free end. Dull... Hey! That's an insult! -- WKRP 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] IOError errno=514 in time.sleep(1)
I've been tracking down an issue with some code sporadically raising IOError with errno=514 on time.sleep(1). time.sleep() is implemented with the select() system call, and on Linux this is sporadically returning errno=514 (ERESTARTNOHAND). This is on 2.6.9, though I've heard reports of it happening through 2.6.17, and my review of the code indicates that 2.6.19.1 (the latest kernel) is probably also going to act the same. Now, the header file where ERESTARTNOHAND is defined says that user-space should never see this errno. Clearly, that's not as true as it could be. I'm going to ask the LKML for more information about whether this should make it to user-space, but thought I'd bring it up here as well. Some options we have: Do nothing. (I like this one :-) Catch and ignore 514. (Only on Linux? Far-reaching implications, I don't like this one). Use the libc sleep() call for integer time.sleep() values? No guarantee that libc sleep() doesn't use select, though I've seen indications that it might use alarm. I haven't looked at the libc source. Try to make time.sleep() smarter in the face of errnos. Maybe try the sleep multiple times, check time.time() before and after the sleep to do multiple sleeps. Could possibly even fail over to using /dev/rtc if select fails? In general I'm reluctant to suggest a Python fix to this, but it's fairly unexpected for time.sleep() to raise an exception... Thoughts? Sean -- I think the net needs some Viagra today. It's just not performing... -- Mike Loseke, 2000 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] Need for Speed Sprint status
On Fri, May 26, 2006 at 09:51:55PM -0700, Neal Norwitz wrote: I just hope to hell you're done, because I can't keep up! :-) Yeah, sucks to be you. :-) It would help me enormously if someone could summarize the status and everything that went on. These are the things that would help me the most. I'm hoping that before we break tonight, that we can do an overview of the changes, and make sure that everything is on the Wiki pages that Raymond pointed to. I've also been writing reports of activity on my work blog at http://www.tummy.com/journals/users/jafo/ Thanks, Sean -- Unix actually IS user friendly -- it's just very picky about whom it calls its friend. 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] 2.5a2 try/except slow-down: Convert to type?
Changes have been checked into the trunk for converting exceptions to types instead of classes. According to pybench, 2.5a2 was 60% slower at raising exceptions than 2.4.3, and now trunk is 30% faster than 2.4.3. Yay! Thanks, Sean -- I was on IRC once and got mistaken for Dan Bernstein. I still have nightmares. -- Donnie Barnes 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] A Horrible Inconsistency
On Fri, May 26, 2006 at 12:37:02PM -0300, Facundo Batista wrote: - Treat the negative as a reverser, so we get back (3, 2, 1). Then we could get: print -123 321 Yay! Thanks, Sean -- Sometimes it pays to stay in bed on Monday, rather than spending the rest of the week debugging Monday's code. -- Christopher Thompson 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] Cost-Free Slice into FromString constructors--Long
On Thu, May 25, 2006 at 03:01:36PM +, Runar Petursson wrote: simply limit the scope of the parsing. There are other solutions, using buffer-like objects and such, but this seems like a simple win for anyone parsing a lot of text. I implemented it in a branch I'll expand on that a little bit, since I talked to Runar yesterday about it. My original blurb on the #nfs IRC channel was that this would seem to have the camel's nose under the tent problem, that once this is in you probably want it in lots of other places where slices may be used. Another interface would be to have something like a lazy string slice that functions that understood it could directly in C operate on the sub-buffer, and oblivious functions would have to create a new slice. Later, John showed Martin and I the Java byte buffer class, and Martin is working on that now. This would probably provide a solution. The Java interface allows you to push a new start and end, and the buffer then acts like it's the string in that range. Useful for parsing without having to create new objects in a tight loop. Conversion functions taking a start and end are the low-hanging fruit, but I think in the long term something that does that described I would prefer. I believe that Martin is expecting expecting to have something this week to try. Thanks, Sean -- A computer lets you make more mistakes faster than any invention in human history -- with the possible exceptions of handguns and tequila. -- Mitch Ratcliffe Sean Reifschneider, Member of Technical Staff [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] A Horrible Inconsistency
On Thu, May 25, 2006 at 09:06:49PM +, Georg Brandl wrote: Don't tell me that! I was actually working on a patch right now... While undoubtedly a performance patch, it wasn't on the list of tasks to do today. You risk Steve's wrath! Thanks, Sean -- In the end, we will remember not the words of our enemies, but the silence of our friends. -- Martin Luther King Jr. 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] 2.5a2 try/except slow-down: Convert to type?
Brett provided the following direction: Right, I meant change how it (BaseException) is written. Right now it uses PyMethodDef for magic methods and just uses PyType_New() as a constructor. I was wondering if, for some reason, it would be faster if you used a PyType_Type definition for BaseException and used the proper C struct to associate the methods with the class. Just a status update. Richard has implemented enough of this that I've been able to run some performance tests, and this changes it this pybench test from being 57% slower than 2.4.3 to being 32% faster. Go Richard. It's looking pretty good so far. Now we just have to keep it from exploding. Thanks, Sean -- Denial is more than just a river in Egypt, you know? Sean Reifschneider, Member of Technical Staff [EMAIL PROTECTED] tummy.com, ltd. - Linux Consulting since 1995: Ask me about High Availability Back off man. I'm a scientist. http://HackingSociety.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
[Python-Dev] 2.5a2 try/except slow-down: Convert to type?
We're working at the sprint on tracking this down. I want to provide some
history first and then what we're looking for feedback on.
Steve Holden found this on Sunday, the pybench try/except test shows a ~60%
slowdown from 2.4.3 to 2.5a2. The original test is, roughly:
for i in range(N):
try: raise ValueError, 'something'
except: pass
But changing it to the following shows 0% slowdown from 2.4.3 to 2.5a2:
e = ValueError('something')
for i in range(N):
try: raise e
except: pass
The change is that from 2.4.3 to 2.5a2 includes Brett Cannon's patch to make
exceptions all new-style objects.
Brett provided the following direction:
Right, I meant change how it (BaseException) is written. Right now
it uses PyMethodDef for magic methods and just uses PyType_New()
as a constructor. I was wondering if, for some reason, it would be
faster if you used a PyType_Type definition for BaseException and
used the proper C struct to associate the methods with the class.
Richard Jones has done some investigation, and we're looking at fixing
it from the current implementation. This is basically a direct
implementation of the old-style exception, but inheriting from object.
Converting it to a type in C should reduce the cost dramatically.
We're looking for feedback on where this may cause problems or break
things. Thoughts?
Thanks,
Sean
--
Thieves broke into Scotland Yard yesterday and stole all the toilets.
Detectives say they have nothing to go on.
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] 2.5a2 try/except slow-down: Convert to type?
On Wed, May 24, 2006 at 11:36:52AM +0100, Michael Hudson wrote: Could it just be that instantiating instances of new-style classes is slower than instantiating instances of old-style classes? There's not anything in what you've posted to suggest that exceptions are involved directly. Sorry, I should have mentioned that. Yes, instantiating new-style classes is slower than old-style, but only by about 10%. The slow-down for try/except is more like 60%. So, it's not just the new versus old difference. It's much, much more than that. Thanks, Sean -- The Law of Software Development and Envelopment at MIT: Every program in development at MIT expands until it can read mail. 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] 2.5a2 try/except slow-down: Convert to type?
We've done some more research on it, and Richard Jones is working on it right now. We'll see how it works, probably tomorrow. Thanks, Sean -- If you don't have time to do it right, when will you ever find time to do it over? 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] 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 gasp '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 135 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] Builtin exit, good in interpreter, bad in code.
On Mon, Apr 24, 2006 at 08:31:19AM +0200, Martin v. L?wis wrote: Sean Reifschneider wrote: Thoughts? In Python 2.5, exit(0) exits. Eeexcellent. Thanks, Sean -- UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things. -- Doug Gwyn 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] Builtin exit, good in interpreter, bad in code.
A friend of mine is learning Python, and had a problem with the exit
builtin. I like that in the interpreter it gives useful information, but
he was writing a program in a file and tried exit(0), and was presented
with the non-obvious error:
TypeError: 'str' object is not callable
What about something like:
class ExitClass:
...def __repr__(self):
... return('Hey, press control-D')
...def __call__(self, value):
... raise SyntaxError, 'You want to use sys.exit'
...
exit = ExitClass()
exit
Hey, press control-D
exit(1)
Traceback (most recent call last):
File stdin, line 1, in ?
File stdin, line 5, in __call__
SyntaxError: You want to use sys.exit
Jerub on #python thinks that maybe it needs to subclass the string object
instead, but in general it seems like it might be an improvement.
Thoughts?
Thanks,
Sean
--
Peppermint Patty gets a DSL line in YOU'D TELL ME IF YOU WERE IN A GERMAN
SCHEISSE VIDEO WOULDN'T YOU, CHARLIE BROWN
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] bdist_deb checkin comments
On Sat, Mar 19, 2005 at 06:20:44PM -0500, Kurt B. Kaiser wrote: Sean Reifschneider [EMAIL PROTECTED] writes: Does anyone have any feedback on this before I do so? I made a few comments on the Tracker. Thanks a lot, they look great. I'll try to get the submitter to follow up on it. Sean -- Sure I like country music, and I like violins. But right now I need a telecaster through a vibrolux turned up to ten. Sean Reifschneider, Member of Technical Staff [EMAIL PROTECTED] tummy.com, ltd. - Linux Consulting since 1995. Qmail, Python, SysAdmin ___ 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
