[Python-Dev] float formatting

[Dennis Allison]

Floating point printing is tricky, as I am sure you know.  You might
want to refrefresh your understanding by consulting the literture--I
know I would.  For example, you might want to look at 

http://portal.acm.org/citation.cfm?id=93559

Guy Steele's paper:

Guy L. Steele , Jon L. White, How to print floating-point numbers accurately, 
ACM SIGPLAN Notices, v.39 n.4, April 2004 

is a classic and worthy of a read.

___
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.4 & 2.5 beta 3 crash

[Dennis Allison]

def test():
  for abc in range(10):
  try: pass
  finally:
  try:
  pass
  except: 
  pass
 
test()

does not raise a segmentation fault.

On Wed, 16 Aug 2006, Josiah Carlson wrote:

> 
> Dino Viehland <[EMAIL PROTECTED]> wrote:
> > 
> > We've been working on fixing some exception handling bugs in
> > IronPython where we differ from CPython.  Along the way we ran into
> > this issue which causes CPython to crash when the code below is run.
> > It crashes on both 2.4 and 2.5 beta 3.  The code's technically illegal,
> > but it probably shouldn't crash either :)
> 
> > def test():
> > for abc in range(10):
> > try: pass
> > finally:
> > try:
> > continue
> > except:
> > pass
> > 
> > 
> > test()
> 
> It also reliably crashes 2.3, though I don't see anything in there as
> being illegal, but maybe I don't understand the langauge as well as I
> think I do.
> 
> Note that there is another segfaulting bug in CPython with regards to
> threads that was recently closed, but which is still a problem:
> http://python.org/sf/780714
> 
> Does IronPython survive in that case?
> 
> 
>  - Josiah
> 
> ___
> 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/allison%40shasta.stanford.edu
> 

-- 

___
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] Does anyone care enough about asyncore and asynchat to help adapt their APIs for Py3k?

[Dennis Allison]

Guido,

These modules provide the server component of many existing versions of the
Zope system where they have served well (pun intended).I would be
concerned were they disappear in Python 3000.

On Dec 5, 2007 10:19 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote:

> The asyncore and asynchat modules are in a difficult position when it
> comes to Python 3000. None of the core developers use it or
> particularly care about it (AFAIK), and the API has problems because
> it wasn't written to deal with bytes vs. unicode. E.g. in
> http://bugs.python.org/issue1067, Thomas suggests that these modules
> need to be rewritten to use bytes internally and have separate APIs to
> handle (unicode) text as desired, similar to the way file I/O was
> redesigned. Another alternative would be to make these modules deal
> strictly in bytes, but that would probably vastly reduce their
> usefulness (though I don't know -- as I said, I don't use them).
>
> --
> --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/allison%40shasta.stanford.edu
>
___
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] Python 2.4 and Zope 2.7.X

[Dennis Allison]

A report on the [EMAIL PROTECTED] list suggests that Python 2.4 is not fully
compatible with Zope 2.7.3.  Has any tested against Zope? 

___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

RE: [Python-Dev] Re: 2.4 news reaches interesting places

[Dennis Allison]

The goal here is to make Python better known and to counter some of the
prevalent myths.  One way to accomplish this goal is to publish literate
technical articles with real content including performance measurements
and pointers to the code.  Perhaps Guido could be a real-life N. Bourbaki
and co-publish with developers.

A significant issue is: where to publish.  Certainly publishing in the
technical society journals (ACM & IEEE CS) would make sense.  Software
Practice and Experience would also be good.  Likewise DDJ and Game
Developer Magazine. But I suspect that much of our target audience will be
missed if we limit ourselves to these journals.  We also need to get
articles placed in the mass market computer mags.  And we need to build an
editorial relationship with the mass market journals so that when X says 
they think "Python is slow" there's some they know they can call for a
truth-squad quote.

And, parenthetically, I continue to be amazed at the number of projects
that use Python, but do it in stealth-mode and view it as their
silver-bullet and competative edge.  I wish more people would publish
their experience.





___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Re: Re: Re: 2.4 news reaches interesting places

[Dennis Allison]

Ummm... I don't think that anyone looks for information by trolling
subdomain names.  If I am looking for python information, I go to 
www.python.org or python.org.  I would never guess "business.python.org".

Seems to me that what we need is content and let the search engines bring
on the masses.

On Wed, 15 Dec 2004, Terry Reedy wrote:

> For a subsite aimed at businesses, business.python.org is obvious and 
> easily remembered.  Not all businesses are corporations.  'about' and 'why' 
> are not specific at all.
> 
> I think such a subsite, linked from the main site also, would be a good 
> idea.  It should explain both why (including success stories) and how 
> (including employment/contracting) to use Python in business.  Pieces could 
> come from the existing site.
> 
> I think the mere existence of such a site would constitute a message to 
> businesses that Python is ready for business.  I suspect the existence of 
> even a skeletal site would attract contributions to build it further.
> 
> Correspondingly, perhaps there should also be a
> science(or scitech or learning).python.org with pages on Astronomy, 
> Bioscience, Chemistry, Mathematics, Education, etc.  Perhaps the scipy and 
> other science application groups would help.
> 
> With two subsites for the main application areas, this would leave 
> www.python.org to focus on the language itself.
> 
> Terry J. Reedy
> 
> 
> 
> ___
> Python-Dev mailing list
> [EMAIL PROTECTED]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/allison%40sumeru.stanford.edu
> 

___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] string find(substring) vs. substring in string

[Dennis Allison]

Boyer-Moore and variants need a bit of preprocessing on the pattern which
makes them great for long patterns but more costly for short ones.

On Wed, 16 Feb 2005, Irmen de Jong wrote:

> Mike Brown wrote:
> > Fredrik Lundh wrote:
> > 
> >>any special reason why "in" is faster if the substring is found, but
> >>a lot slower if it's not in there?
> > 
> > 
> > Just guessing here, but in general I would think that it would stop 
> > searching 
> > as soon as it found it, whereas until then, it keeps looking, which takes 
> > more 
> > time. But I would also hope that it would be smart enough to know that it 
> > doesn't need to look past the 2nd character in 'not the xyz' when it is 
> > searching for 'not there' (due to the lengths of the sequences).
> 
> There's the Boyer-Moore string search algorithm which is
> allegedly much faster than a simplistic scanning approach,
> and I also found this: http://portal.acm.org/citation.cfm?id=79184
> So perhaps there's room for improvement :)
> 
> --Irmen
> ___
> 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/allison%40sumeru.stanford.edu
> 

___
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] Coverity Open Source Defect Scan of Python

[Dennis Allison]

On Mon, 6 Mar 2006, Barry Warsaw wrote:

> On Mon, 2006-03-06 at 14:26 -0500, Tim Peters wrote:
> > [Ben Chelf <[EMAIL PROTECTED]>]
> > > ...
> > > I'd ask that if you are interested in really digging into the results a 
> > > bit
> > > further for your project, please have a couple of core maintainers (or
> > > group nominated individuals) reach out to me to request access.
> > 
> > Didn't we set up a "security swat team" some time ago?  If not, we
> > should.  Regardless, since I have more free time these days, I'd like
> > to be on it.
> 
> Yep, it's called [EMAIL PROTECTED] (with a semi-secret backing mailing
> list, which I'd be happy for you to join
!).  I definitely think that
> group of folks at the least should review the results.
> 
> -Barry
> 
>From their open source chart:

OpenVPN 7   69,842  0.100   Sign in Register
Perl89  479,780 0.186   Sign in Register
PHP 207 431,251 0.480   Sign in Register
PostgreSQL  297 815,700 0.364   Sign in Register
ProFTPD 26  89,650  0.290   Sign in Register
Python  59  259,896 0.227   Sign in Register
Samba   215 312,482 0.688   Sign in Register

This is interesting stuff.  See http://metacomp.stanford.edu for some 
background.  

The Coverty marketing droids need to be a bit less anal about getting
people to register at the website.  IMHO, the technology should be
described openly and allowed to speak for itself. On the other hand, the
policy of not disclosing discovered bugs until someone has had a chance to
evaluate their significance and fix them is probably a good one.

I'd also encourage Coventry to explain their business model a bit more
clearly.  Coventry seems to be supportive of open source projects.  
Coverty also seems to be targeting big companies as customers.  It's not
clear how arbitrary open source projects (and small companies and
individuals) will be able to take advantage of Coventry's products and
services.

>From Ben's email:

... if you are interested in 
   really digging into the results a bit further for your project, please 
   have a couple of core maintainers (or group nominated individuals) reach 
   out to me to request access. As this is a new process for us and still 
   involves a small number of packages, I want to make sure that I 
   personally can be involved with the activity that is generated from this 
   effort.
   
  So I'm basically asking for people who want to play around with some 
   cool new technology to help make source code better. If this interests 
   you, please feel free to reach out to me directly. And of course, if 
   there are other packages you care about that aren't currently on the 
   list, I want to know about those too.
   
This looks to me to be something worth doing.  I wish I had the time to be
one of the designated folks, but, sadly, I don't.  



___
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] Discussing the Great Library Reorganization

[Dennis Allison]

Not quite on the same topic, but perhaps it belong there.  I think most of
use use both the stdlib and some selection of other libraries
(MySQL-Python, ReportLab Toolkit, PyChart, and PyXML, for example).  These 
libraries have to be managed independently and installed independently.
It would be nice if there were a central repository of "blessed" 
extensions to the standard library which could be selectively loaded when 
a new version of Python is installed.  There'd also need to be a tool for 
checking the extensions for new versions and upgrading since they would 
most likely not be maintained in lockstep with Python and its standard 
library.


On Wed, 29 Mar 2006, Brett Cannon wrote:

> While this is going to require a PEP (which I am willing to write),
> the discussion of adding pysqlite has brought forth some discussion on
> naming and packaging in the stdlub.  Perhaps it's time to start
> discussing the Great Library Reorganization that has been discussed
> for eons.
> 
-- 

___
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] Regular expressions

[Dennis Allison]

This is probably OT for [Python-dev]

I suspect that your problem is not the GIL but is due to something else.
Rather than dorking with the interpreter's threading, you probably would 
be better off rethinking your problem and finding a better way to 
accomplish your task.

On Thu, 24 Nov 2005, Duncan Grisby wrote:

> On Thursday 24 November, Donovan Baarda wrote:
> 
> > I don't know if this will help, but in my experience compiling re's
> > often takes longer than matching them... are you sure that it's the
> > match and not a compile that is taking a long time? Are you using
> > pre-compiled re's or are you dynamically generating strings and using
> > them?
> 
> It's definitely matching time. The res are all pre-compiled.
> 
> [...]
> > > A quick look at the code in _sre.c suggests that for most of the time,
> > > no Python objects are being manipulated, so the interpreter lock could
> > > be released. Has anyone tried to do that?
> > 
> > probably not... not many people would have several-minutes-to-match
> > re's.
> > 
> > I suspect it would be do-able... I suggest you put together a patch and
> > submit it on SF...
> 
> The thing that scares me about doing that is that there might be
> single-threadedness assumptions in the code that I don't spot. It's the
> kind of thing where a patch could appear to work fine, but them
> mysteriously fail due to some occasional race condition. Does anyone
> know if there is there any global state in _sre that would prevent it
> being re-entered, or know for certain that there isn't?
> 
> Cheers,
> 
> Duncan.
> 
> 

-- 

___
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] Ph.D. dissertation ideas?

[Dennis Allison]

Brett,

Where are you doing your Phd and who will be your likely supervisor? 
It does make a difference.

Your dissertation idea list seems to me to focus on implementation
projects and not on research.  Usually a dissertation proceeds from a
hypothesis leading to an experiment, some measurements, and conclusions.  
Many universities tacitly expect a theorem and associated proof. The goal
of dissertation research is a completed approved dissertation, not some
intergalactic all encompassing contribution to human knowledge.  
Dissertation research should, IMHO, focus on a small, manageable problem.

Frequently, universities have a large cooperative project involving many 
graduate students, each of whom research a small, well defined topic areas 
related to the larger project.   Is this the case for your dissertation?

What are your interests?  Are you interested in language structure, 
language implementation, the formal interface between languages and 
applications, or what.   

Like most folks who lurk on this list, I have my list of things I'd like 
to see someone research.  Tell us a bit more and I am sure you'll get lots 
of us to share.

-d

On Thu, 12 Jan 2006, Brett Cannon wrote:

> It is time once again in my educational career to come to python-dev
> for help for major project ideas.  This time, though, it is for my
> Ph.D. dissertation (and thus can have larger scope than my masters
> thesis) but there are funding restrictions (and thus only certain
> areas I have possible funding for).
> 
> First off, there are two areas where I have possible funding: XML
> integration into programming languages and game scripting support (I
> have a third, AOP for anything, but  I don't think AOP is a good match
> for Python and thus not considering it for Python work).  The XML
> integration I have no direct ideas since I don't use XML.  There is
> the possibility of doing something like the LINQ project
> (http://msdn.microsoft.com/netframework/future/linq/default.aspx?pull=/library/en-us/dndotnet/html/linqprojectovw.asp)
> or something, but I don't know how useful that could be.  It would
> have to be just as generic, though, as the LINQ project in terms of
> working with intefaces to be Pythonic so it might turn out to be more
> about language support for querying data.
> 
> For the game scripting, trying out the active objects for Python is a
> possibility (or something else that would help with concurrency). 
> Since that could allow for agent objects to be more concurrent it can
> be argued that it would help with game scripting.  I don't have any
> other ideas for the area of game scripting support.
> 
> Now I am not locked down to these areas, but they are what I have
> possible grant money for.  If through some miracle someone out there
> wants to fund my Ph.D. and wants something else worked on for Python,
> don't be shy.  =)  Unfortunately I don't think the PSF is up for
> funding my Ph.D., else I would say I would work on whatever python-dev
> decided they wanted to worked on that could be done as a dissertation.
> 
> Anyway, any ideas are appreciated.  There is no rush on this, either. 
> Just getting this out there now while I am tentatively exploring
> possible topics.
> 
> -Brett
> ___
> 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/allison%40sumeru.stanford.edu
> 

-- 

___
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] Ph.D. dissertation ideas?

[Dennis Allison]

On Thu, 12 Jan 2006, Brett Cannon wrote:

> It is time once again in my educational career to come to python-dev
> for help for major project ideas.  This time, though, it is for my
> Ph.D. dissertation (and thus can have larger scope than my masters
> thesis) but there are funding restrictions (and thus only certain
> areas I have possible funding for).
> 
> First off, there are two areas where I have possible funding: XML
> integration into programming languages and game scripting support (I
> have a third, AOP for anything, but  I don't think AOP is a good match
> for Python and thus not considering it for Python work).  The XML
> integration I have no direct ideas since I don't use XML.  There is
> the possibility of doing something like the LINQ project
> (http://msdn.microsoft.com/netframework/future/linq/default.aspx?pull=/library/en-us/dndotnet/html/linqprojectovw.asp)
> or something, but I don't know how useful that could be.  It would
> have to be just as generic, though, as the LINQ project in terms of
> working with intefaces to be Pythonic so it might turn out to be more
> about language support for querying data.
> 
> For the game scripting, trying out the active objects for Python is a
> possibility (or something else that would help with concurrency). 
> Since that could allow for agent objects to be more concurrent it can
> be argued that it would help with game scripting.  I don't have any
> other ideas for the area of game scripting support.

Brett--

Financial considerations aside, neither of the ideas you mention see ready
to be a dissertation topic.  I'd encourge you to look to other topics.

You might research interpreter structures for languages like Python which
do not use a global interpreter lock (GIL).  There's been discussion about
this from time to time on this list, even some suggestions as to what
might be done.  Given the trend toward multi-core processors, Python would
benefit if all processors did not need to block on the GIL. Guido told me
once that someone had build a Python interpreter with multiple locks, but
that the peformance was not very good and that the interpreter was
fragile.  This is, of course, a hard problem.

In 1974, Dijkstra wrote a fascinating paper on self-stabalizing 
algorithms; since that time a considerable literature has grown up.

Managing a Python system these days is a management problem when the
standard system is extended with libraries from many different sources,
each with different release schedules, dependencies, compatibilities, and 
documentation.  Automating the management of Python and its libraries 
might make a good dissertation topic, particualarly if there is some 
advice giving system that helps find an appropriate library for a 
particular problem.

Testing, optimization, refactopring tools, etc.

Dave Altel, following others, suggested in a provacatively title talks--

 



___
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] Let's just *keep* lambda

[Dennis Allison]

+1 on retaining lambda
-1 on any name change


On Sun, 5 Feb 2006, Paul Moore wrote:

> On 2/5/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > After so many attempts to come up with an alternative for lambda,
> > perhaps we should admit defeat. I've not had the time to follow the
> > most recent rounds, but I propose that we keep lambda, so as to stop
> > wasting everybody's talent and time on an impossible quest.
> 
> +1
> 
> The recently suggested keyword change, from lambda to expr (as in
> '''expr x, y: x+y''') looks like an improvement to me, but I suspect
> opening up the possibility of a keyword change would simply restart
> all the discussions... (Nevertheless, I'd be +1 on lambda being
> renamed to expr, if it was an option).
> 
> Paul.
> ___
> 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/allison%40shasta.stanford.edu
> 

-- 

___
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