Re: [Python-Dev] 3.1 performance

[Victor Stinner]

Hi,

> So, 3.1 is 30% faster in user CPU time, even though it probably has more
> tests (...)

Wow!

I just downloaded Python 2.6.1, 3.0.1 and 3.1alpha1, compiled them on 32 and 
64 bits CPU, and ran pybench 2.1(*).

Summary (minimum total) on 32 bits CPU:
 * Python 2.6.1: 8762 ms
 * Python 3.0.1: 8977 ms
 * Python 3.1a1: 9228 ms (slower than 3.0)

Summary (minimum total) on 64 bits CPU:
 * Python 2.6.1: 4219 ms
 * Python 3.0.1: 4502 ms 
 * Python 3.1a1: 4442 ms (faster than 3.0)

I also ran pybench once, is it enough? See attached files for the details.

(*) I copied pybench 2.1 from Pthon 3.1alpha1 because 2.6.1 only 
includes pybench 2.0

-- 
Victor Stinner aka haypo
http://www.haypocalc.com/blog/
Computer:
 * Ubuntu 7.10
 * Pentium(R) 4 CPU 3.00GHz (32 bits)
 * 2 GB of RAM

#

---
PYBENCH 2.1
---
* using CPython 3.0.1 (r301:69556, Mar 8 2009, 11:34:16) [GCC 4.1.3 20070929 
(prerelease) (Ubuntu 4.1.2-16ubuntu2)]
* disabled garbage collection
* system check interval set to maximum: 2147483647
* using timer: time.time

Calibrating tests. Please wait... done.

Running 10 round(s) of the suite at warp factor 10:

* Round 1 done in 9.777 seconds.
* Round 2 done in 12.040 seconds.
* Round 3 done in 10.130 seconds.
* Round 4 done in 9.619 seconds.
* Round 5 done in 9.197 seconds.
* Round 6 done in 9.199 seconds.
* Round 7 done in 9.231 seconds.
* Round 8 done in 9.217 seconds.
* Round 9 done in 10.090 seconds.
* Round 10 done in 9.125 seconds.

---
Benchmark: 2009-03-08 11:36:02
---

Rounds: 10
Warp:   10
Timer:  time.time

Machine Details:
   Platform ID:Linux-2.6.22-16-386-i686-with-debian-lenny-sid
   Processor:

Python:
   Implementation: CPython
   Executable: /home/haypo/prog/Python-3.0.1/python
   Version:3.0.1
   Compiler:   GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)
   Bits:   32bit
   Build:  Mar  8 2009 11:34:16 (#r301:69556)
   Unicode:UCS2


Test minimum  average  operation  overhead
---
  BuiltinFunctionCalls:149ms154ms0.30us0.380ms
   BuiltinMethodLookup:140ms143ms0.14us0.469ms
 CompareFloats:139ms141ms0.12us0.538ms
 CompareFloatsIntegers:269ms274ms0.30us0.462ms
   CompareIntegers:172ms176ms0.10us0.823ms
CompareInternedStrings:138ms139ms0.09us2.911ms
  CompareLongs: 97ms 98ms0.09us0.623ms
CompareStrings:120ms125ms0.13us1.865ms
ComplexPythonFunctionCalls:162ms165ms0.83us0.902ms
 ConcatStrings:251ms264ms0.53us0.788ms
   CreateInstances:175ms196ms1.75us0.626ms
CreateNewInstances:132ms134ms1.59us0.504ms
   CreateStringsWithConcat:194ms203ms0.20us1.310ms
  DictCreation:121ms142ms0.36us0.526ms
 DictWithFloatKeys:222ms224ms0.25us1.001ms
   DictWithIntegerKeys:119ms122ms0.10us1.324ms
DictWithStringKeys:125ms130ms0.11us1.347ms
  ForLoops:129ms155ms6.20us0.072ms
IfThenElse:138ms150ms0.11us1.005ms
   ListSlicing:129ms141ms   10.11us0.095ms
NestedForLoops:142ms160ms0.11us0.002ms
  NestedListComprehensions:197ms222ms   18.47us0.151ms
  NormalClassAttribute:229ms279ms0.23us0.709ms
   NormalInstanceAttribute:166ms179ms0.15us0.713ms
   PythonFunctionCalls:162ms173ms0.52us0.390ms
 PythonMethodCalls:202ms220ms0.98us0.244ms
 Recursion:274ms399ms7.98us0.656ms
  SecondImport:158ms173ms1.73us0.307ms
   SecondPackageImport:164ms179ms1.79us0.260ms
 SecondSubmoduleImport:216ms233ms2.33us0.261ms
   SimpleComplexArithmetic:135ms163ms0.19us0.536ms
SimpleDictManipulation:242ms282ms0.24us0.663ms
 SimpleFloatArithmetic:148ms162ms0.12us0.807ms
  SimpleIntFloatArithmetic:196ms205ms0.16us0.796ms
   SimpleIntegerArithmetic:190ms197ms

Re: [Python-Dev] Integrate BeautifulSoup into stdlib?

[Chris Withers]

Guido van Rossum wrote:

Based on the sad example of BerkeleyDB, which was initially welcomed
into the stdlib but more recently booted out for reasons having to do
with the release cycle of the external dependency and other issues
typical for large external dependencies, I think we should be very
careful with including it in the standard library.



Yes. My experience of these kinds of libraries (bdb, lxml, etc) is that 
having them in the Python stdlib is a "bad thing".


Why? Because python (quite rightly, as I'm being convinced!) has a very 
conservative policy of changes is 3rd point releases. This, however, 
means you end up getting 'stuck" with a release of something like lxml 
that you can't upgrade to get new features because you, say, use a 
debian-packages python which only upgrades when Debian next decide to do 
 release...


In light of this, what I'd love to see (but sadly can't really help 
with, and am not optimistic about happening) is for:


- python to grow a decent, cross platform, package management system

- the standard library to actually shrink to a point where only 
libraries that are not released elsewhere are included


I'd be interested to know how many users of python also felt this way ;-)

Chris
___
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] patch commit policies (was [issue4308] repr of httplib.IncompleteRead is stupid)

[Chris Withers]

Barry Warsaw wrote:

That aside, is it actually a python-wide policy to *forbid* patching
older releases where the patch isn't security-related?


I set this policy for the releases I manage, namely 2.4 and 2.5.


This is a Python-wide policy.


...and, now that Martin has explained it, it makes perfect sense...

When Python 2.7 is released, there will be one last 2.6.x bug fix 
release, and then it will go into security-only mode.  Similarly, when 
Python 3.1 is released, there will be one last 3.0.x release and it too 
will go into security-only mode.


...of course, in a perfect work, it'd be nice to have 2 or 3 previous 
second point releases in bug-fix mode, rather than just one ;-)


Chris


___
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] patch commit policies (was [issue4308] repr of httplib.IncompleteRead is stupid)

[Chris Withers]

Tres Seaver wrote:

If it is possible for a hostile outsider to trigger the DOS by sending
mail to be processed by an application using the library, and the
application can't avoid the DOS without ditching / forking /
monkeypatching the library, then I would call the bug a "security bug",
period.


I just captured the original exception and re-raised it as a subclass 
with a sane __repr__


cheers,

Chris

___
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] 3.1 performance

[Antoine Pitrou]

Hi,

Victor Stinner  haypocalc.com> writes:
> 
> Summary (minimum total) on 32 bits CPU:
>  * Python 2.6.1: 8762 ms
>  * Python 3.0.1: 8977 ms
>  * Python 3.1a1: 9228 ms (slower than 3.0)

Have you compiled with or without "--with-computed-gotos"?

Regards

Antoine.


___
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] asyncore fixes in Python 2.6 broke Zope's version of medusa

[glyph]

On 02:28 am, s...@pobox.com wrote:
   Glyph> ... which is exactly why I have volunteered to explain to 
someone

   Glyph> how to separate the core event-loop bits



   Neil> This sounds great.



Anybody interested in working on this at a PyCon Sprint?  I won't be
attending the conference proper, but plan to spend a couple days 
sprinting,
one on Mailman/SpamBayes integration and one on Python core stuff. 
This
might fit well into my Python core "slot".  I will probably have little 
time
before the sprint to do much, but any brain dumps or Twisted pointers 
people

could give me in the interim would be appreciated.


I'll try to make sure we get those notes to you in advance of the 
sprints :).  I should be at the Twisted sprint the whole time - will you 
be at the physical sprint, or following along at home?

___
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] asyncore fixes in Python 2.6 broke Zope's version of medusa

[glyph]

On 01:50 am, n...@arctrix.com wrote:

gl...@divmod.com  wrote:



we're not even talking about actually putting any Twisted code
into the standard library, just standardizing the "protocol" API, 
which

basically boils down to:

[...]

This sounds great.  I'm interested on working on this since it
scratches an itch of mine but I don't know if I will have time.  Do
you think if this part of Twisted became part of the standard
library that it would be used by Twisted or would it continue to
have its own version?


As I said above, right now I'm just talking about the interface.  There 
are several implementations of the main loop that call those interfaces, 
as well as test implementations.


Of course I hope we can eliminate some redundancy, but that's step 2: 
before we refactor, we have to make the code that we're refactoring 
actually repetitive rather than just similar.

___
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] asyncore fixes in Python 2.6 broke Zope's version of medusa

[skip]

Glyph> I'll try to make sure we get those notes to you in advance of the
Glyph> sprints :).  I should be at the Twisted sprint the whole time -
Glyph> will you be at the physical sprint, or following along at home?

Thanks.  I will be at the physical sprints.  (I live in the Chicago area.)

Skip
___
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] Integrate BeautifulSoup into stdlib?

[Martin v. Löwis]

> In light of this, what I'd love to see (but sadly can't really help
> with, and am not optimistic about happening) is for:
> 
> - python to grow a decent, cross platform, package management system
> 
> - the standard library to actually shrink to a point where only
> libraries that are not released elsewhere are included
> 
> I'd be interested to know how many users of python also felt this way ;-)

I don't like the standard library to shrink. It's good that batteries
are included.

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] Integrate BeautifulSoup into stdlib?

[Michael Foord]

Martin v. Löwis wrote:

In light of this, what I'd love to see (but sadly can't really help
with, and am not optimistic about happening) is for:

- python to grow a decent, cross platform, package management system

- the standard library to actually shrink to a point where only
libraries that are not released elsewhere are included

I'd be interested to know how many users of python also felt this way ;-)



I don't like the standard library to shrink. It's good that batteries
are included.
  
I have mixed feelings. It is great that the batteries are included, but 
some batteries are showing their age or not maintained (who maintains 
IDLE? - does the calendar module really warrant being in the standard 
library? - imaplib is really not useful and IMAPClient which isn't in 
the standard library is much better [1]).


If a library is well maintained then there seems to be little point in 
moving it into the standard library as it may actually be harder to 
maintain, and if a library has no active developers then do we really 
want it in the standard library...


On the other hand there are some standard tools that a significant 
portion of the community use (Python Imaging Library and the PyWin32 
extensions for example) that aren't in the standard library.


I think other developers have similar mixed feelings, or at least there 
are enough people on both sides of the fence that it is very hard to 
make changes. Perhaps this is the way it should be.


Michael

[1] http://freshfoo.com/wiki/CodeIndex


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/fuzzyman%40voidspace.org.uk
  



--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog


___
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] 3.1 performance

[Christian Heimes]

Antoine Pitrou wrote:
> Hi,
> 
> Victor Stinner  haypocalc.com> writes:
>> Summary (minimum total) on 32 bits CPU:
>>  * Python 2.6.1: 8762 ms
>>  * Python 3.0.1: 8977 ms
>>  * Python 3.1a1: 9228 ms (slower than 3.0)
> 
> Have you compiled with or without "--with-computed-gotos"?

Why is the feature still disabled by default?

Christian

PS: Holy moly! Computed gotos totally put my Python on fire! The feature
increases the minimum run-time by approx. 25% and the average run-time
by approx. 40% on my Ubuntu 8.10 box (AMD64, Intel(R) Core(TM)2 CPU
T7600  @ 2.33GHz).
---
PYBENCH 2.1
---
* using CPython 3.1a0 (py3k:70205, Mar 8 2009, 15:16:23) [GCC 4.3.2]
* disabled garbage collection
* system check interval set to maximum: 2147483647
* using timer: time.time

---
Benchmark: no_goto.pybench
---

Rounds: 10
Warp:   10
Timer:  time.time

Machine Details:
   Platform ID:Linux-2.6.27-11-generic-x86_64-with-debian-lenny-sid
   Processor:  

Python:
   Implementation: CPython
   Executable: /home/heimes/dev/python/py3k/python
   Version:3.1.0
   Compiler:   GCC 4.3.2
   Bits:   64bit
   Build:  Mar  8 2009 15:11:16 (#py3k:70205)
   Unicode:UCS2


---
Comparing with: goto.pybench
---

Rounds: 10
Warp:   10
Timer:  time.time

Machine Details:
   Platform ID:Linux-2.6.27-11-generic-x86_64-with-debian-lenny-sid
   Processor:  

Python:
   Implementation: CPython
   Executable: /home/heimes/dev/python/py3k/python
   Version:3.1.0
   Compiler:   GCC 4.3.2
   Bits:   64bit
   Build:  Mar  8 2009 15:16:23 (#py3k:70205)
   Unicode:UCS2


Test minimum run-timeaverage  run-time
 thisother   diffthisother   diff
---
  BuiltinFunctionCalls:90ms68ms  +31.2%   109ms75ms  +44.8%
   BuiltinMethodLookup:56ms46ms  +21.4%75ms50ms  +48.9%
 CompareFloats:   100ms61ms  +64.8%   116ms65ms  +77.8%
 CompareFloatsIntegers:   139ms97ms  +43.3%   169ms   103ms  +64.0%
   CompareIntegers:   151ms88ms  +72.7%   187ms96ms  +94.2%
CompareInternedStrings:   117ms66ms  +78.9%   136ms69ms  +95.8%
  CompareLongs:87ms50ms  +75.5%   102ms53ms  +93.1%
CompareStrings:   102ms53ms  +94.0%   124ms63ms  +97.8%
ComplexPythonFunctionCalls:97ms83ms  +17.4%   113ms85ms  +32.9%
 ConcatStrings:   128ms   116ms  +10.3%   151ms   117ms  +28.6%
   CreateInstances:90ms81ms  +10.0%   108ms83ms  +30.1%
CreateNewInstances:67ms61ms   +9.6%84ms63ms  +32.7%
   CreateStringsWithConcat:   128ms   108ms  +18.3%   150ms   110ms  +35.6%
  DictCreation:71ms54ms  +30.4%87ms61ms  +43.3%
 DictWithFloatKeys:83ms67ms  +24.1%   104ms69ms  +51.5%
   DictWithIntegerKeys:80ms60ms  +32.9%   108ms67ms  +61.6%
DictWithStringKeys:   109ms50ms +117.0%   111ms59ms  +88.1%
  ForLoops:70ms59ms  +18.4%95ms63ms  +51.2%
IfThenElse:96ms68ms  +40.7%   115ms69ms  +66.8%
   ListSlicing:78ms77ms   +1.5%83ms80ms   +2.8%
NestedForLoops:92ms71ms  +29.2%   124ms76ms  +62.7%
  NestedListComprehensions:98ms76ms  +28.6%   118ms86ms  +36.1%
  NormalClassAttribute:   152ms   139ms   +9.2%   183ms   140ms  +30.6%
   NormalInstanceAttribute:96ms76ms  +27.2%   128ms82ms  +56.9%
   PythonFunctionCalls:87ms70ms  +23.9%   100ms71ms  +39.9%
 PythonMethodCalls:   108ms87ms  +23.9%   126ms91ms  +38.9%
 Recursion:   135ms   113ms  +20.0%   166ms   117ms  +42.6%
  SecondImport:84ms82ms   +3.0%97ms86ms  +12.9%
   SecondPackageImport:90ms89ms   +1.2%   102ms91ms  +12.0%
 SecondSubmoduleImport:   120ms   119ms   +0.7%   130ms   120ms   +8.4%
   SimpleComplexArithmetic:68ms57ms  +18.3%84ms58ms  +44.6%
SimpleDictManipulation:   136ms   111ms  +22.2%   162ms   115

Re: [Python-Dev] Integrate BeautifulSoup into stdlib?

[Martin v. Löwis]

> I have mixed feelings. It is great that the batteries are included, but
> some batteries are showing their age or not maintained (who maintains
> IDLE? - does the calendar module really warrant being in the standard
> library? - imaplib is really not useful and IMAPClient which isn't in
> the standard library is much better [1]).

I certainly agree that little-used modules should be removed (by means
of a proper deprecation procedure). I do think it is fairly important
that IDLE remains included (whether or not gpolo takes ownership of it).

As for imaplib: I can't comment on the library itself, since I never
use it. However, given the number of bug reports that we receive, it
seems there is a fairly significant followership of it.

> If a library is well maintained then there seems to be little point in
> moving it into the standard library as it may actually be harder to
> maintain

It depends. For quickly evolving libraries, it might be harder to
maintain them in the core, as you can't release as quickly as you
desire. In other cases, it simplifies maintenance: whenever a
systematic API change is added, all standard library modules get
typically updated by whoever makes the systematic change. That is
more productive than having each individual maintainer to figure out
what to change in response.

However, I don't think of the maintainer point of view that much:
it's rather the end users (i.e. application developers) who I worry
about: Should we remove regular expressions from Python, just because
the library doing it is unmaintained?

> On the other hand there are some standard tools that a significant
> portion of the community use (Python Imaging Library and the PyWin32
> extensions for example) that aren't in the standard library.

I continue having the same position: if the authors of those respective
libraries would like to contribute it to the core (and eventually drop
the out-of-core fork), then I would be happy to let them do that. Of
course, Guido's cautioning wrt. external libraries that those depend on
still applies: if there are strong external dependencies, the library
would have to be really important to the community to still include it.

> I think other developers have similar mixed feelings, or at least there
> are enough people on both sides of the fence that it is very hard to
> make changes. Perhaps this is the way it should be.

I think so, yes. Decisions will be made on a case-by-case basis, going
either direction one time or the other.

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] 3.1 performance

[Antoine Pitrou]

Christian Heimes  cheimes.de> writes:
> 
> Why is the feature still disabled by default?

Marc-André expressed concerns that it might trigger compiler issues.

> PS: Holy moly! Computed gotos totally put my Python on fire! The feature
> increases the minimum run-time by approx. 25% and the average run-time
> by approx. 40% on my Ubuntu 8.10 box (AMD64, Intel(R) Core(TM)2 CPU
> T7600  @ 2.33GHz).

You surely mean that it /decreased/ run-time by approx. 20% :-)
I don't think average numbers are significant, but they might indicate that your
system was slightly loaded when running the benchmarks.

Regards

Antoine.


___
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] asyncore fixes in Python 2.6 broke Zope's version of medusa

[Daniel Stutzbach]

On Sat, Mar 7, 2009 at 8:28 PM,  wrote:

> Anybody interested in working on this at a PyCon Sprint?  I won't be
> attending the conference proper, but plan to spend a couple days sprinting,
>

I'll be there and interested. :)

--
Daniel Stutzbach, Ph.D.
President, Stutzbach Enterprises, LLC 
___
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] Integrate BeautifulSoup into stdlib?

[Steve Holden]

Martin v. Löwis wrote:
>> In light of this, what I'd love to see (but sadly can't really help
>> with, and am not optimistic about happening) is for:
>>
>> - python to grow a decent, cross platform, package management system
>>
>> - the standard library to actually shrink to a point where only
>> libraries that are not released elsewhere are included
>>
>> I'd be interested to know how many users of python also felt this way ;-)
> 
> I don't like the standard library to shrink. It's good that batteries
> are included.
> 
Perhaps we could encourage more "jumbo" distributions, like Enthought's
and ActiveState's. I suspect many people would rather be able to
maintain their Python functionality as a single product.

regards
 Steve
-- 
Steve Holden   +1 571 484 6266   +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/
Want to know? Come to PyCon - soon! http://us.pycon.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] Ruby-style Blocks in Python [Pseudo-PEP]

[tav]

Hey all,

Apologies for bringing up an old issue, but I think I've worked out a
Pythonic syntax for doing Ruby-style blocks. The short of it is:

with employees.select do (emp):
if emp.salary > developer.salary:
return fireEmployee(emp)
else:
return extendContract(emp)

I explain in detail in this blog article:

  http://tav.espians.com/ruby-style-blocks-in-python.html

It covers everything from why these are useful to a proposal of how
the new ``do`` statement and __do__ function could work.

Let me know what you think.

My apologies if I've missed something obvious. Thanks!

-- 
love, tav

plex:espians/tav | t...@espians.com | +44 (0) 7809 569 369
http://tav.espians.com | http://twitter.com/tav | skype:tavespian
___
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] 3.1 performance

[Collin Winter]

On Sun, Mar 8, 2009 at 7:30 AM, Christian Heimes  wrote:
> Antoine Pitrou wrote:
>> Hi,
>>
>> Victor Stinner  haypocalc.com> writes:
>>> Summary (minimum total) on 32 bits CPU:
>>>  * Python 2.6.1: 8762 ms
>>>  * Python 3.0.1: 8977 ms
>>>  * Python 3.1a1: 9228 ms (slower than 3.0)
>>
>> Have you compiled with or without "--with-computed-gotos"?
>
> Why is the feature still disabled by default?
>
> Christian
>
> PS: Holy moly! Computed gotos totally put my Python on fire! The feature
> increases the minimum run-time by approx. 25% and the average run-time
> by approx. 40% on my Ubuntu 8.10 box (AMD64, Intel(R) Core(TM)2 CPU
> T7600  @ 2.33GHz).

Note that of the benchmarks tested, PyBench benefits the most from
threaded eval loop designs. Other systems benefit less; for example,
Django template benchmarks were only sped up by 7-8% when I was
testing it.

Collin Winter
___
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] RELEASED Python 3.1 alpha 1

[Steve Holden]

Aahz wrote:
> On Sat, Mar 07, 2009, Benjamin Peterson wrote:
>> On behalf of the Python development team and the Python community, I'm
>> happy to announce the first alpha release of Python 3.1.
> 
> Congratulations on your first baby!  Here's to hoping you release many
> more of these!

Yes, well done, Benjamin. Barry Warsaw is walking with a spring in his
steps again ;-)

regards
 Steve
-- 
Steve Holden   +1 571 484 6266   +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/
Want to know? Come to PyCon - soon! http://us.pycon.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] 3.1 performance

[Victor Stinner]

Le Sunday 08 March 2009 13:20:34 Antoine Pitrou, vous avez écrit :
> Hi,
>
> Victor Stinner  haypocalc.com> writes:
> > Summary (minimum total) on 32 bits CPU:
> >  * Python 2.6.1: 8762 ms
> >  * Python 3.0.1: 8977 ms
> >  * Python 3.1a1: 9228 ms (slower than 3.0)
>
> Have you compiled with or without "--with-computed-gotos"?

I used "./configure --prefix=...", no other option. Should I enable it? For 
which version?

-- 
Victor Stinner aka haypo
http://www.haypocalc.com/blog/
___
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] Ruby-style Blocks in Python [Pseudo-PEP]

[Duncan Booth]

tav  wrote:

> I explain in detail in this blog article:
> 
>   http://tav.espians.com/ruby-style-blocks-in-python.html
> 

"This is also possible in Python but at the needless cost of naming and 
defining a function first"

The cost of defining the function first is probably much less than the cost 
of your __do__ function. Your proposal seems to be much more limited than 
passing functions around e.g. Python allows you to pass in multiple 
functions where appropriate, or to store them for later calling. 


___
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] Ruby-style Blocks in Python [Pseudo-PEP]

[Antoine Pitrou]

tav  espians.com> writes:
> 
> Apologies for bringing up an old issue, but I think I've worked out a
> Pythonic syntax for doing Ruby-style blocks. The short of it is:
> [...]

This thread should probably be redirected to python-ideas.

Regards

Antoine.


___
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] Ruby-style Blocks in Python [Pseudo-PEP]

[Matthew Wilkes]

On 8 Mar 2009, at 15:13, tav wrote:


Apologies for bringing up an old issue, but I think I've worked out a
Pythonic syntax for doing Ruby-style blocks. The short of it is:

   with employees.select do (emp):
   if emp.salary > developer.salary:
   return fireEmployee(emp)
   else:
   return extendContract(emp)


My train of thought when seeing this:

 1. Ok, "with" it's a context manager.
 2. Huh, no it's not, "do", it's a loop.
 3. What on earth is emp?  Where's that defined?  Why the parens?
 4. Where do those returns return to?
 5. I have no idea what this does.

Ah, now, reading your Python alternative, defining a function then  
passing it is, it's more clear.


This is completely incomprehensible to me, it doesn't feel like  
python.  I'd rather define the throwaway function, anonymous callables  
that do complex things aren't my kind of thing.  Give them a sensible  
name, put them in a utils module, and import it where needed, it's  
much clearer.


Matt
___
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] asyncore fixes in Python 2.6 broke Zope's version of medusa

[glyph]

On 02:46 pm, dan...@stutzbachenterprises.com wrote:

On Sat, Mar 7, 2009 at 8:28 PM,  wrote:

Anybody interested in working on this at a PyCon Sprint?  I won't be
attending the conference proper, but plan to spend a couple days 
sprinting,



I'll be there and interested. :)


Great!  I plan to hold both of you to that :).
___
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] 3.1 performance

[Guido van Rossum]

On Sun, Mar 8, 2009 at 4:05 AM, Victor Stinner
 wrote:
> I just downloaded Python 2.6.1, 3.0.1 and 3.1alpha1, compiled them on 32 and
> 64 bits CPU, and ran pybench 2.1(*).
>
> Summary (minimum total) on 32 bits CPU:
>  * Python 2.6.1: 8762 ms
>  * Python 3.0.1: 8977 ms
>  * Python 3.1a1: 9228 ms (slower than 3.0)
>
> Summary (minimum total) on 64 bits CPU:
>  * Python 2.6.1: 4219 ms
>  * Python 3.0.1: 4502 ms
>  * Python 3.1a1: 4442 ms (faster than 3.0)
>
> I also ran pybench once, is it enough? See attached files for the details.
>
> (*) I copied pybench 2.1 from Pthon 3.1alpha1 because 2.6.1 only
>    includes pybench 2.0

How are these numbers significant? IIUC that is not at all how pybench
is supposed to be used. Its strength is that it lets you watch the
relative performance of many individual operations. I don't think
adding up the numbers for all operations gives a very useful total,
since each individual timing loop seems to be scaled to last around
50-100 msec; this means the operation mix is probably vastly different
from that occurring in real operations.

What I'd be interested in however would be a list of which operations
got speeded up the most and which slowed down the most. That might
stir up someone's memory of a change that was made in that operations
that could explain the performance change (especially for slow-downs,
of course :-).

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

Re: [Python-Dev] Ruby-style Blocks in Python [Pseudo-PEP]

[Guido van Rossum]

On Sun, Mar 8, 2009 at 8:13 AM, tav  wrote:
> Apologies for bringing up an old issue, but I think I've worked out a
> Pythonic syntax for doing Ruby-style blocks.

As a point of order, please move this discussion to python-ideas,
where it belongs roughly until the time a PEP might be ready for
approval.

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

Re: [Python-Dev] RELEASED Python 3.1 alpha 1

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mar 8, 2009, at 11:18 AM, Steve Holden wrote:


Aahz wrote:

On Sat, Mar 07, 2009, Benjamin Peterson wrote:
On behalf of the Python development team and the Python community,  
I'm

happy to announce the first alpha release of Python 3.1.


Congratulations on your first baby!  Here's to hoping you release  
many

more of these!


Yes, well done, Benjamin. Barry Warsaw is walking with a spring in his
steps again ;-)


I was wondering why the weather here in DC has turned so beautiful  
after last week's snow storm!


Barry

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSbP4DXEjvBPtnXfVAQJ3DgP/SI+Um8xbOP5I64dDz5y9FDj+OL/quL8U
h1pCZsaekK6NMmMZmACylsj6a8ZUg7h6Mm9RVLYgwyYje/3mEOHxNIaL4mgLBtr8
sQJS3UYyxK/uaf6UxTodWJFnFkeyx291sp3jlPppjDDyNrHK48pwEZ2+ZpCL9w9t
y3sqVsGAy40=
=h8nT
-END PGP 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] Integrate BeautifulSoup into stdlib?

[Martin v. Löwis]

> Perhaps we could encourage more "jumbo" distributions, like Enthought's
> and ActiveState's. I suspect many people would rather be able to
> maintain their Python functionality as a single product.

I think the concept of "jumbo distribution" has been lost. I mentioned
it to one of the Enthought people (sorry, forgot who exactly), and he
said he had never heard the term.

Looking back, it seems that you have to be a commercial enterprise to
produce such a thing. There is the python.org distribution, where many
volunteers maintain it, and then there are the two (?) free-commercial
distributions (ActivePython, and EPD). I'm skeptical that there can be
motivation for creating another "community" jumbo distribution - why
would anybody put efforts into maintaining it? You don't get much credit
for release engineering - except from fellow release engineers.

In addition, you have the Linux distributions, which you can also count
as jumbo Python distributions (and also jumbo Perl, jumbo Java, jumbo
LISP - at least for Debian :-). Again, many of these are commercially
based, although there still seems to be space for multiple community
distributions (Debian, Gentoo).

This is precisely the reason why I want Python to continue including its
batteries. If we give that up, it will not come back, and users get
frustrated that they have to collect stuff from many places, and that
the stuff doesn't fit together completely.

What that means for BeautifulSoup, I don't know. First, its authors
would have to offer contributing it, and then experts should also
agree that this would be a useful inclusion. Some apparently say that
html5lib would be a better choice. If that's the thing that is currently
on release 0.11, then I think we should take no action at this point -
I don't want to include anything that has version 0.11.

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] Ruby-style Blocks in Python

[Henning von Bargen]

I totally agree with Matthew.
I don't understand the code at first sight.
The "with ... do ..." syntax breaks the
"Python is executable pseudo-code" pattern.

And according the example given at Tav's web site:

with employees.select do (emp):
   if emp.salary > developer.salary:
   return fireEmployee(emp)
   else:
   return extendContract(emp)

It is neither shorter nor clearer than the same thing with existing Python 
syntax:


for emp in employees.select:
   # or should it be "select()"?
   if emp.salary > developer.salary:
   fireEmployee(emp)
   else:
   extendContract(emp)

BTW it seems to me that Python development might go the wrong direction.

Using Python for the development of commercial programs for years,
I never felt the need to use anything more complicated than generators or 
decorators.


Security, performance, and the "batteries included" are by far more 
important

than esotheric features which Joe Average doesn't understand anyway
(and therefore hopefully won't use it).

If there's anything where Python should be improved, it's static code 
analysis
(like pylint) in the standard lib and optional type declarations, which 
could be

used to assist pylint and friends as well as JIT compilers, Cython,
and not even more Meta-thingies.

Sorry, I just had to say this once.

Henning

___
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] Integrate BeautifulSoup into stdlib?

[Bill Janssen]

Martin v. Löwis  wrote:

> > If a library is well maintained then there seems to be little point in
> > moving it into the standard library as it may actually be harder to
> > maintain
> 
> It depends. For quickly evolving libraries, it might be harder to
> maintain them in the core, as you can't release as quickly as you
> desire. In other cases, it simplifies maintenance: whenever a
> systematic API change is added, all standard library modules get
> typically updated by whoever makes the systematic change. That is
> more productive than having each individual maintainer to figure out
> what to change in response.

This is a complicated issue.  But two sub-threads seem to be about (1)
modules dependent (or wrapping) a large, complicated third-party library
under active development, and (2) hard-to-routinely-test modules, like
imaplib.

Bill
___
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] Integrate BeautifulSoup into stdlib?

[Bill Janssen]

Martin v. Löwis  wrote:

> then there are the two (?) free-commercial
> distributions (ActivePython, and EPD).

Apple's system Python seems to qualify; it comes with a huge additional
library, including numpy and Twisted.

Bill
___
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] Integrate BeautifulSoup into stdlib?

[Jim Jewett]

Michael Foord wrote:
> Chris Withers wrote:
>> ... love to see ... but ... not optimistic

>> - python to grow a decent, cross platform, package management system

As stated, this may be impossible, because of the difference in what a
package should mean on Windows vs Unix.

If you just mean a way to add python packages from pypi as with
EasyInstall, then maybe.

>> - the standard library to actually shrink to a point where only
>> libraries that are not released elsewhere are included

In some environments, each new component must be approved.  Once
python is approved, the standard library is OK, but adding 7 packages
from pypi requires 7 more sets of approvals.

On the other hand, if there were a way to say "The PSF explicitly
endorses Packages X, Y, and Z as worthy of the stdlib; they are
distributed separately for administrative reasons", then the initial
request could be for "Python plus officially endorsed addons"

That said, it may make sense to just give greater prominence to
existing repackagers, such as ActiveState or Enthought.

> If a library is well maintained then there seems to be little point in
> moving it into the standard library

The official endorsement is in many cases more important than shared
distribution.

-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

[Python-Dev] Python 3.0 grammar ambiguous?

[Fabio Zadrozny]

Hi All,

I'm trying to parse Python 3.0 following the Python 3.0 grammar from:
http://svn.python.org/projects/python/branches/py3k/Grammar/Grammar

Now, when getting to the arglist, it seems that the grammar is
ambiguous, and I was wondering how does Python disambiguate that (I'll
not put the whole grammar here, just the part that appears to be
ambiguous):

arglist: (argument ',')*
(argument [',']
 |'*' test (',' argument)* [',' '**' test]
 |'**' test
 )

argument: test [comp_for]
test: or_test
or_test: and_test
and_test: not_test
not_test: 'not' not_test | comparison
comparison: star_expr
star_expr: ['*'] expr


So, with that construct, having call(arglist) in a format:
call(*test), the grammar would find it to be consumed in the argument
construction (because of the start_expr) and not in the arglist in the
'*' test (because the construct is ambiguous and the argument
construct comes first), so, I was wondering how does Python
disambiguate that... anyone has any pointers on it? It appears that
happened while adding PEP 3132.

Am I missing something here?

Thanks,

Fabio
___
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 3.0 grammar ambiguous?

[Martin v. Löwis]

Fabio Zadrozny wrote:
> I was wondering how does Python
> disambiguate that... anyone has any pointers on it?

That is easy to answer:

py> parser.expr("f(*x)").totuple()
(258, (326, (303, (304, (305, (306, (307, (309, (310, (311, (312, (313,
(314, (315, (316, (317, (1, 'f')), (321, (7, '('), (329, (16, '*'),
(303, (304, (305, (306, (307, (309, (310, (311, (312, (313, (314, (315,
(316, (317, (1, 'x', (8, ')', (4, ''),
(0, ''))
py> symbol.arglist
329

So much for the "how", I don't know why it makes this choice; notice
that this is the better choice, though:

py> f((*x))
  File "", line 1
SyntaxError: can use starred expression only as assignment target

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] Integrate BeautifulSoup into stdlib?

[Nick Coghlan]

Jim Jewett wrote:
> That said, it may make sense to just give greater prominence to
> existing repackagers, such as ActiveState or Enthought.

Perhaps we should think about linking to the relevant
ActiveState/Enthought distributions from the pydotorg download pages?

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
---
___
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 3.0 grammar ambiguous?

[Fabio Zadrozny]

>> I was wondering how does Python
>> disambiguate that... anyone has any pointers on it?
>
> That is easy to answer:
>
> py> parser.expr("f(*x)").totuple()
> (258, (326, (303, (304, (305, (306, (307, (309, (310, (311, (312, (313,
> (314, (315, (316, (317, (1, 'f')), (321, (7, '('), (329, (16, '*'),
> (303, (304, (305, (306, (307, (309, (310, (311, (312, (313, (314, (315,
> (316, (317, (1, 'x', (8, ')', (4, ''),
> (0, ''))
> py> symbol.arglist
> 329
>
> So much for the "how", I don't know why it makes this choice; notice
> that this is the better choice, though:
>
> py> f((*x))
>  File "", line 1
> SyntaxError: can use starred expression only as assignment target


Yeap, very strange that it works... I can't get it to work in JavaCC.

I'm considering setting arglist as
((argument() [','])+  ['**' test])
| '**' test

Because it is able to handle the constructs removing the ambiguity,
and make things right semantically later on, but I don't like the idea
of being so different from the official grammar (although I'm running
out of choices).

Thanks,

Fabio
___
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 3.0 grammar ambiguous?

[Nick Coghlan]

Fabio Zadrozny wrote:
> Because it is able to handle the constructs removing the ambiguity,
> and make things right semantically later on, but I don't like the idea
> of being so different from the official grammar (although I'm running
> out of choices).

I'm not sure it is the same (or at least related) problem, but a parsing
ambiguity was also reported for the lambda varargslist in 2.x:
http://bugs.python.org/issue2009

I think I'd be happier with fiddling the Grammar to eliminate these
problems if Guido was to chime in as the author of pgen though... (since
pgen appears to be able to make sense of the grammar as it currently
stands, while other parsers sometimes have trouble)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
---
___
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 3.0 grammar ambiguous?

[Guido van Rossum]

On Sun, Mar 8, 2009 at 2:18 PM, Nick Coghlan  wrote:
> Fabio Zadrozny wrote:
>> Because it is able to handle the constructs removing the ambiguity,
>> and make things right semantically later on, but I don't like the idea
>> of being so different from the official grammar (although I'm running
>> out of choices).
>
> I'm not sure it is the same (or at least related) problem, but a parsing
> ambiguity was also reported for the lambda varargslist in 2.x:
> http://bugs.python.org/issue2009
>
> I think I'd be happier with fiddling the Grammar to eliminate these
> problems if Guido was to chime in as the author of pgen though... (since
> pgen appears to be able to make sense of the grammar as it currently
> stands, while other parsers sometimes have trouble)

To be honest I wasn't aware of this ambiguity. It seems that whoever
wrote the patch for argument unpacking (a, b, *c = ...) got "lucky"
with an ambiguous grammar. This surprises me, because IIRC usually
pgen doesn't like ambiguities. Other parser generators usually have
some way to deal with ambiguous grammars, but they also usually have
features that make it unnecessary to use the exact same grammar as
pgen -- for example, most parser generators are able to backtrack or
look ahead more than one token, so that they can distinguish between
"a = b" and "a" once the '=' token is seen, rather than having to
commit to parse an expression first.

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

Re: [Python-Dev] Python 3.0 grammar ambiguous?

[Martin v. Löwis]

> To be honest I wasn't aware of this ambiguity. It seems that whoever
> wrote the patch for argument unpacking (a, b, *c = ...) got "lucky"
> with an ambiguous grammar. This surprises me, because IIRC usually
> pgen doesn't like ambiguities. 

So how does it resolve the ambiguity?

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] Python 3.0 grammar ambiguous?

[Guido van Rossum]

On Sun, Mar 8, 2009 at 3:28 PM, "Martin v. Löwis"  wrote:
>> To be honest I wasn't aware of this ambiguity. It seems that whoever
>> wrote the patch for argument unpacking (a, b, *c = ...) got "lucky"
>> with an ambiguous grammar. This surprises me, because IIRC usually
>> pgen doesn't like ambiguities.
>
> So how does it resolve the ambiguity?

I have no idea. :-(

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

Re: [Python-Dev] Python 3.0 grammar ambiguous?

[Fabio Zadrozny]

> To be honest I wasn't aware of this ambiguity. It seems that whoever
> wrote the patch for argument unpacking (a, b, *c = ...) got "lucky"
> with an ambiguous grammar. This surprises me, because IIRC usually
> pgen doesn't like ambiguities. Other parser generators usually have
> some way to deal with ambiguous grammars, but they also usually have
> features that make it unnecessary to use the exact same grammar as
> pgen -- for example, most parser generators are able to backtrack or
> look ahead more than one token, so that they can distinguish between
> "a = b" and "a" once the '=' token is seen, rather than having to
> commit to parse an expression first.

JavaCC can actually do that, but in the current construct, the
ambiguity is not dependent on a lookahead, because both '*' test and
star_expr will match it equally well -- because they're actually the
same thing grammar-wise (so, there's no way to disambiguate without a
semantic handling later on)

After taking a 2nd look, I think that probably the best solution would
be creating a new testlist to be used from the expr_stmt -- something
like testlist_start_expr.

E.g.:

testlist: test (',' test)* [',']
testlist_star_expr:  [test | star_expr] (',' [test | star_expr])* [',']

And also, star_expr could probably be just
'*' NAME
(to make it faster to match -- or could it match something else?)

Note that I still haven't tested this -- I'll have time to do it
tomorrow on my JavaCC grammar (so, I can give you a better feedback if
this actually works).

Regards,

Fabio
___
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] BZR mirror and pushing to Launchpad

[R. David Murray]

I just posted a (tiny) patch to the tracker, and for the
exercise of it I thought I would push the branch out to Launchpad
as suggested in the wiki (http://wiki.python.org/moin/Bazaar).
It looks like it is uploading every file in the branch instead
of the delta from the trunk.  Did I do something wrong in my local
bzr setup, or is this the expected behavior?

-- R. David Murray   http://www.bitdance.com
___
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] BZR mirror and pushing to Launchpad

[Ross Light]

Yes, this is the expected behavior.  Bazaar will upload all of the
revisions since it is not stacking off of another branch.  You could
try using the Launchpad or Python.org mirrors as a stacking branch, as
described here:

http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#using-stacked-branches

Cheers,
Ross Light

On Sun, Mar 8, 2009 at 6:09 PM, R. David Murray  wrote:
>
> I just posted a (tiny) patch to the tracker, and for the
> exercise of it I thought I would push the branch out to Launchpad
> as suggested in the wiki (http://wiki.python.org/moin/Bazaar).
> It looks like it is uploading every file in the branch instead
> of the delta from the trunk.  Did I do something wrong in my local
> bzr setup, or is this the expected behavior?
>
> -- R. David Murray           http://www.bitdance.com
> ___
> 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/rlight2%40gmail.com
___
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] BZR mirror and pushing to Launchpad

[Andrew Bennetts]

R. David Murray wrote:
> I just posted a (tiny) patch to the tracker, and for the
> exercise of it I thought I would push the branch out to Launchpad
> as suggested in the wiki (http://wiki.python.org/moin/Bazaar).
> It looks like it is uploading every file in the branch instead
> of the delta from the trunk.  Did I do something wrong in my local
> bzr setup, or is this the expected behavior?

It should Just Work, i.e. pushing that branch to Launchpad should stack
automatically.  I just spoke to one of the code.launchpad.net developers and
everything seems to be working normally on his end.  Can you provide a bit
more information about exactly what you did, so we can try to reproduce the
problem?

Also, as this may be more of an issue with Launchpad than the Python bzr
import, it might be better to continue this conversation on launchpad-users
(subscribe at https://launchpad.net/~launchpad-users) rather than
python-dev.  I guess it depends on whether or not python-dev would consider
this noise or not...

-Andrew.

___
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] BZR mirror and pushing to Launchpad

[Andrew Bennetts]

Ross Light wrote:
> Yes, this is the expected behavior.  Bazaar will upload all of the
> revisions since it is not stacking off of another branch.  You could
> try using the Launchpad or Python.org mirrors as a stacking branch, as
> described here:
> 
> http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#using-stacked-branches

Actually, the Launchpad code server is configured to make bzr automatically
stack on the appropriate branch.  The docs you point to there are about manually
specifying the branch to stack on.

-Andrew.

___
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] IDLE maintenance

[Mitchell L Model]

I've been trying to decipher the various mentions of IDLE maintenance 
on this list to determine the likely future (not necessarily feature 
addition, just keeping it working with each new version of Python 
and, I suppose, Tk) , who is currently responsible for it, and who 
will be responsible for it. Presumably these questions have official 
answers somewhere, but I wouldn't know where to find them.


I have several strong reasons to want IDLE to survive, including 
using it in teaching and writing, where it becomes absurd to provide 
instructions full of variations based on different IDE's. IDLE is 
sufficient for introductory courses and books, and useful for many 
purposes even beyond that. The community should want to minimize the 
entry friction new users experience, and new users in these times 
will not necessarily have any experience with command-line shells or 
editors like vi and emacs. IDLE is at just the right level for 
someone new to Python to just jump in and start exploring or even for 
someone with reasonable Python experience investigating a new area of 
the library.


As I said, I don't know the plans or people surrounding IDLE are. If 
it needs a new maintainer I hereby volunteer. Discussions about my 
qualifications should probably be conducted through email to me 
personally, rather than through this mailing list, using the address 
I use when submitting issues to the tracker: m...@acm.org.

--
Mitchell L Model, Ph.D.
m...@acm.orgMLM Consulting
(508) 358-8055 (v)  42 Oxbow Road
(508) 641-7772 (m)  Wayland, MA 01778
___
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] Integrate BeautifulSoup into stdlib?

[Larry Bugbee]

In light of this, what I'd love to see (but sadly can't really help
with, and am not optimistic about happening) is for:

- python to grow a decent, cross platform, package management system

- the standard library to actually shrink to a point where only
libraries that are not released elsewhere are included

I'd be interested to know how many users of python also felt this  
way ;-)




I don't like the standard library to shrink. It's good that batteries
are included.

I have mixed feelings. It is great that the batteries are included,  
but

some batteries are showing their age or not maintained (who maintains
IDLE? - does the calendar module really warrant being in the standard
library? - imaplib is really not useful and IMAPClient which isn't in
the standard library is much better [1]).

If a library is well maintained then there seems to be little point in
moving it into the standard library as it may actually be harder to
maintain, and if a library has no active developers then do we really
want it in the standard library...

On the other hand there are some standard tools that a significant
portion of the community use (Python Imaging Library and the PyWin32
extensions for example) that aren't in the standard library.

I think other developers have similar mixed feelings, or at least  
there

are enough people on both sides of the fence that it is very hard to
make changes. Perhaps this is the way it should be.


Batteries Included should not be interpreted as Soup and Nuts or the  
Kitchen Sink.  There are a lot of good, no, outstanding libraries out  
there that are excellent candidates for the standard library.  IMO,  
the standard library should include those things that would be truly  
helpful getting small projects started.  Beyond that the needs of the  
project will likely be specialized to the point that one should be  
using libraries beyond the standard libraries.  Heck, there are things  
I use frequently that I'd like to be "standard", but could be an  
imposition on the rest of the Python community.  The last thing I want  
to see is a library so large that we spend time figuring out how to  
cull unwanted items.


Beautiful Soup and html5lib are good, but specialized libraries, and  
not, IMO, of *general* interest.  The same goes for lxml, which by the  
way, I like and have used.  ...but it doesn't have to be in the  
standard library to be useful.


I'd like to suggest that any new candidate for the standard library be  
discussed and then set aside for a cooling off period of ONE YEAR.  If  
then folks can all agree the library is not only Goodness, but of  
general interest, especially for bootstrapping small projects, then  
take a vote, or the BDFL can decide.


A key criteria should be, "Will the new library help small projects  
get started by providing basic capabilities without introducing a  
steep learning curve?"


Larry




___
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] BZR mirror and pushing to Launchpad

[Ross Light]

On Sun, Mar 8, 2009 at 7:40 PM, Andrew Bennetts
 wrote:
> Actually, the Launchpad code server is configured to make bzr automatically
> stack on the appropriate branch.  The docs you point to there are about 
> manually
> specifying the branch to stack on.
>
> -Andrew.

However, my understanding is that Launchpad will not automatically
stack if you are using the Python.org branch; you must use the
Launchpad mirror.  If you want to stack off the Python.org branch,
then I think you need to manually stack.

Cheers,
Ross Light

(sorry for possible dupe posting, I thought my mail client was sending
to python-dev, but it didn't seem to)
___
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] BZR mirror and pushing to Launchpad

[Andrew Bennetts]

Ross Light wrote:
[...]
> However, my understanding is that Launchpad will not automatically
> stack if you are using the Python.org branch; you must use the
> Launchpad mirror.  If you want to stack off the Python.org branch,
> then I think you need to manually stack.

It is true that if the source branch that you push to Launchpad is not in a
stacking-capable format, then the automatic stacking will not happen.  But
that shouldn't be the case with the Python.org branch;
 uses the latest format which is
stacking-capable.

On the other hand, it does appear that
 is a branch that is
not stacking-capable.  I'm not sure how this could happen by following the
instructions on the the wiki page.

-Andrew.

___
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] Integrate BeautifulSoup into stdlib?

[Raymond Hettinger]

This is precisely the reason why I want Python to continue including its
batteries. If we give that up, it will not come back, and users get
frustrated that they have to collect stuff from many places, and that
the stuff doesn't fit together completely.


I concur.


Raymond

___
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] PEP 239 - Rational

[Lie Ryan]

PEP 239 says that Rational type was Rejected, but some time ago this 
decision is reverted, and now python 3.0 and python 2.6 includes a 
fractions.Fraction type. Shouldn't this PEP be updated? (At least to 
include a note of its obsoleted status or to point to the reversion)


___
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