On Sat, Sep 27, 2008 at 2:16 PM, Giles Constant <[EMAIL PROTECTED]> wrote:
> Instead of:
> /\d+hello/
>
> How about (explanation of syntax to follow):
>
> boolean = match(input, "oneormore(digit).one('hello')")
Looks like you want pyparsing http://pyparsing.wikispaces.com/
__
On 9/27/08, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>> I think that the problem is important because it's a regression from 2.5
>> to
>> 2.6/3.0. Python 2.5 uses bytes filename, so it was possible to
>> open/unlink "invalid" unicode strings (since it's not unicode but bytes).
>
> I'd like to s
> "broken" systems will always exist. Code to deal with them must be
> possible to write in python 3.0.
Python 3.0 will have bugs. This might just be one of them. I can agree
that Python 3.x will need to support that somehow, but perhaps not 3.0.
Regards,
Martin
_
Giles Constant wrote:
How about (explanation of syntax to follow):
boolean = match(input, "oneormore(digit).one('hello')")
Take this a step further and use constructor functions
to build the RE.
from spiffy_re import one, oneormore
pattern = oneormore(digit) + one('hello')
match = pat
On Sun, Sep 28, 2008 at 2:13 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>> "broken" systems will always exist. Code to deal with them must be
>> possible to write in python 3.0.
>
> Python 3.0 will have bugs. This might just be one of them. I can agree
> that Python 3.x will need to support
On Sep 28, 2008, at 7:21 PM, Gregory P. Smith wrote:
On Sun, Sep 28, 2008 at 2:13 PM, "Martin v. Löwis"
<[EMAIL PROTECTED]> wrote:
"broken" systems will always exist. Code to deal with them must be
possible to write in python 3.0.
Python 3.0 will have bugs. This might just be one of them.
> This problem sure would be "practically" solved simply by switching the
> way the filesystemencoding is selected.
Great minds think alike :-) I just proposed a similar approach in the
tracker, with the following variations:
- applications can explicitly set the file system encoding. If they set
