Am 09.03.2010 14:42, schrieb Jeremy Hylton:
On Sat, Mar 6, 2010 at 11:27 AM, Gregg Lind gregg.l...@gmail.com wrote:
Python-devs,
I'm writing to you for some help in understanding the Python grammar. As an
excuse to deep dive into Python's tokenizer / grammar, I decided (as a
hideous,
Peter Portante wrote:
http://code.google.com/p/re2/
On 3/11/10 8:52 PM, Neal Becker ndbeck...@gmail.com wrote:
http://swtch.com/~rsc/regexp/regexp1.html
Both interesting links. I'll add another one to the list:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Nick Coghlan wrote:
Peter Portante wrote:
http://code.google.com/p/re2/
On 3/11/10 8:52 PM, Neal Becker ndbeck...@gmail.com wrote:
http://swtch.com/~rsc/regexp/regexp1.html
Both interesting links. I'll add another one to the list:
I have some regex-intensive Python that might benefit from this, but I don't
think I have enough skill to do a set of Python bindings.
An ideal first cut would be to enable this:
import re2 as re
I live in hope...
Brent L
___
Python-Dev
==
PyPy 1.2: Just-in-Time Compilation
==
PyPy 1.2 has been released. The highlight of this release is
to be the first that ships with a Just-in-Time compiler that is
known to be faster than CPython (and unladen swallow) on some
On Fri, Mar 12, 2010 at 8:12 AM, Nick Coghlan ncogh...@gmail.com wrote:
[snip]
To bring this on-topic for python-dev by considering how it could apply
to Python's default re engine, I think the key issue is that any updates
to the default engine would need to remain backwards compatible with
There are major practical problems associated with making such a leap
directly (Google's re2 engine is in C++ rather than C and we'd have
to keep the existing implementation around regardless to handle the
features that re2 doesn't support).
Collin I don't see why C++
On Mar 04, 2010, at 11:34 PM, Nick Coghlan wrote:
The remaining open question to my mind is whether or not there should be
a -X option to control the bytecode generation. E.g.:
-Xcache_bytecode=no (don't write bytecode files at all)
-B and $PYTHONDONTWRITEBYTECODE will still be supported and
On Fri, Mar 12, 2010 at 11:29 AM, s...@pobox.com wrote:
There are major practical problems associated with making such a leap
directly (Google's re2 engine is in C++ rather than C and we'd have
to keep the existing implementation around regardless to handle the
features that
Le Fri, 12 Mar 2010 13:29:09 -0600,
s...@pobox.com a écrit :
Traditionally Python has run on some (minority) platforms where C++
was unavailable.
Is this concern still valid? We are in the 2010s now.
I'm not saying I want us to put some C++ in the core interpreter, but
the portability
On Mar 12, 2010, at 05:03 PM, Antoine Pitrou wrote:
Le Fri, 12 Mar 2010 13:29:09 -0600,
s...@pobox.com a écrit :
Traditionally Python has run on some (minority) platforms where C++
was unavailable.
Is this concern still valid?
Certainly not if Unladen Swallow blazes the trail.
-Barry
Antoine Pitrou:
Is this concern still valid? We are in the 2010s now.
I'm not saying I want us to put some C++ in the core interpreter, but
the portability argument sounds a little old...
There are still viable platforms which only support subsets of C++.
IIRC, Android does not support
On 12/03/2010 19:53, Barry Warsaw wrote:
On Mar 04, 2010, at 11:34 PM, Nick Coghlan wrote:
The remaining open question to my mind is whether or not there should be
a -X option to control the bytecode generation. E.g.:
-Xcache_bytecode=no (don't write bytecode files at all)
-B and
On 12/03/2010 22:48, Michael Foord wrote:
On 12/03/2010 19:53, Barry Warsaw wrote:
On Mar 04, 2010, at 11:34 PM, Nick Coghlan wrote:
The remaining open question to my mind is whether or not there should be
a -X option to control the bytecode generation. E.g.:
-Xcache_bytecode=no (don't
On Mar 12, 2010, at 10:48 PM, Michael Foord wrote:
On 12/03/2010 19:53, Barry Warsaw wrote:
I believe we've decided /not/ to support creation of bytecode-only
distributions out of the box.
I thought Guido said on this topic [1]:
FWIW, I started at -1 and am still -1. I think the PEP is
On Fri, Mar 12, 2010 at 2:18 PM, Neil Hodgson nyamaton...@gmail.com wrote:
Antoine Pitrou:
Is this concern still valid? We are in the 2010s now.
I'm not saying I want us to put some C++ in the core interpreter, but
the portability argument sounds a little old...
There are still viable
Am 12.03.2010 20:29, schrieb s...@pobox.com:
There are major practical problems associated with making such a leap
directly (Google's re2 engine is in C++ rather than C and we'd have
to keep the existing implementation around regardless to handle the
features that re2
Collin re2 is not a full replacement for Python's current regex
Collin semantics: it would only serve as an accelerator for a subset of
Collin the current regex language. Given that, it makes perfect sense
Collin that it would be optional on such minority platforms (much like
On 12 Mar 2010, at 15:22, s...@pobox.com wrote:
Collin re2 is not a full replacement for Python's current regex
Collin semantics: it would only serve as an accelerator for a subset of
Collin the current regex language. Given that, it makes perfect sense
Collin that it would be optional
On Fri, Mar 12, 2010 at 4:03 PM, Antoine Pitrou solip...@pitrou.net wrote:
Le Fri, 12 Mar 2010 13:29:09 -0600,
s...@pobox.com a écrit :
Traditionally Python has run on some (minority) platforms where C++
was unavailable.
Is this concern still valid? We are in the 2010s now.
I'm not
Antoine s...@pobox.com a écrit :
Traditionally Python has run on some (minority) platforms where C++
was unavailable.
Antoine Is this concern still valid? We are in the 2010s now.
Like I said, *minority* platforms. Here are some which come to mind as
quite possibly not
On Fri, Mar 12, 2010 at 7:54 PM, s...@pobox.com wrote:
Antoine s...@pobox.com a écrit :
Traditionally Python has run on some (minority) platforms where C++
was unavailable.
Antoine Is this concern still valid? We are in the 2010s now.
Like I said, *minority* platforms.
22 matches
Mail list logo
