On Fri, Mar 12, 2010 at 7:54 PM, 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.
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 possib
On Fri, Mar 12, 2010 at 4: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? We are in the 2010s now.
> I'm not saying I wan
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 op
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
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
On Fri, Mar 12, 2010 at 2:18 PM, Neil Hodgson 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 platforms which
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
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 wr
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 $P
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 e
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.
-Ba
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 argum
On Fri, Mar 12, 2010 at 11:29 AM, 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 re
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
>> 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
On Fri, Mar 12, 2010 at 8:12 AM, Nick Coghlan 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 all
> of the trick
==
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
real-
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 mailing
-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" wrote:
>>
>>> http://swtch.com/~rsc/regexp/regexp1.html
>
> Both interesting links. I'll add another one to the list:
> http://google
Peter Portante wrote:
> http://code.google.com/p/re2/
>
> On 3/11/10 8:52 PM, "Neal Becker" wrote:
>
>> http://swtch.com/~rsc/regexp/regexp1.html
Both interesting links. I'll add another one to the list:
http://google-opensource.blogspot.com/2010/03/re2-principled-approach-to-regular.html
To b
Am 09.03.2010 14:42, schrieb Jeremy Hylton:
> On Sat, Mar 6, 2010 at 11:27 AM, Gregg Lind 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, hideous joke) to
22 matches
Mail list logo
