[Python-Dev] \code or \constant in tex markup

2007-05-09 Thread Neal Norwitz
Which is correct?

$ egrep '(False|True)' Doc/lib/*.tex | grep -c \\constant{
74
$ egrep '(False|True)' Doc/lib/*.tex | grep -c \\code{
204
$ egrep 'None' Doc/lib/*.tex | grep -c \\code{
512
$ egrep 'None' Doc/lib/*.tex | grep -c \\constant{
83

n
___
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] svn logs

2007-05-09 Thread Giovanni Bajo
On 08/05/2007 19.37, Neal Norwitz wrote:

 Part of the problem might be that we are using an old version of svn
 (1.1) AFAIK.  IIRC these operations were sped up in later versions.

Yes they were. If that's the case, then probably the server should be updated.
-- 
Giovanni Bajo

___
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] best practices stdlib: purging xrange

2007-05-09 Thread Terry Reedy

Martin v. Löwis [EMAIL PROTECTED] wrote in message 
news:[EMAIL PROTECTED]
| Just curious why 2to3 would not replace range() with list(range())?
|
| In most usages of range(), using the 3.0 range() will work just as
| well, and be more efficient.

If so, which it would seem from range2x functionally equal to list(range3), 
then the suggestion of the subject line is backwards.  What should be 
purged eventually is range in for statement headers (or list(range) after 
conversion).

It seems that what some consider best practice now (make a list unless it 
is long and un-needed) is different from what will be best practice in Py3 
(do not make a list unless actually need it).

tjr



___
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] best practices stdlib: purging xrange

2007-05-09 Thread O.R.Senthil Kumaran
* James Y Knight [EMAIL PROTECTED] [2007-05-08 11:18:44]:

 On May 8, 2007, at 8:49 AM, Armin Rigo wrote:
  On Tue, May 08, 2007 at 09:14:02AM +1000, Anthony Baxter wrote:
  I'd like to suggest that we remove all (or nearly all) uses of
  xrange from the stdlib. A quick scan shows that most of the usage
  of it is unnecessary. With it going away in 3.0, and it being
  informally deprecated anyway, it seems like a good thing to go away
  where possible.
 
  I personally think that replacing these with range() is a clean-up,  
  but
  I also know that not everybody agrees to that.  So: should we, or  
  should
  we not, replace xrange() with range() as a matter of clean-up when the
  difference between the two is really completely irrelevant?
 
 But doesn't doing this now this make the conversion to Py3 *harder*?  
 If 2to3 is going to rewrite xrange() as range(), and range() to list 
 (range()), then moving towards xrange where possible would actually  
 be preferable, wouldn't it? Or is there no plan to run 2to3 on the  
 stdlib?

Looking at xrange() and range() definitions and from this discussion, it seems
to me that xrange() to be preferable over range(). Its common that most of the
code have range() because its simple use in iteration, but if same
functionality is provided with xrange as an object. And doing
:s/xrange/range/g would make sense also. ( Am I right in understanding this?)

Why range or xrange and why not xrange or range?
Or is this discussion about why having two functions with similar (or rather
same) functionality, and lets move to one and in which case either of them is
fine.

-- 
O.R.Senthil Kumaran
___
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