Python regular expressions just ain't PCRE
I'm kind of disappointed with the re regular expressions module. In
particular, the lack of support for recursion ( (?R) or (?n) ) is a
major drawback to me. There are so many great things that can be
accomplished with regular expressions this way, such as validating a
mathematical expression or parsing a language with nested parens,
quoting or expressions.
Another feature I'm missing is once-only subpatterns and possessive
quantifiers ( (?>...) and ?+ *+ ++ {...}+ ) which are great to avoid
deep recursion and inefficiency in some complex patterns with nested
quantifiers. Even java.util.regex supports them.
Are there any plans to support these features in re? These would be
great features for Python 2.6, they wouldn't clutter anything, and
they'd mean one less reason left to use Perl instead of Python.
Note: I know there are LALR parser generators/parsers for Python, but
the very reason why re exists is to provide a much simpler, more
productive way to parse or validate simple languages and process text.
(The pyparse/yappy/yapps/ argument could have been used to skip regular
expression support in the language, or to deprecate re. Would you want
that? And following the same rule, why would we have Python when
there's C?)
--
http://mail.python.org/mailman/listinfo/python-list
Re: Python regular expressions just ain't PCRE
On May 5, 5:12 am, "Terry Reedy" <[EMAIL PROTECTED]> wrote: > I believe the current Python re module was written to replace the Python > wrapping of pcre in order to support unicode. I don't know how PCRE was back then, but right now it supports UTF-8 Unicode patterns and strings, and Unicode character properties. Maybe it could be reintroduced into Python? > I don't remember those being in the pcre Python once had. Perhaps they are > new. At least today, PCRE supports recursion and recursion check, possessive quantifiers and once-only subpatterns (disables backtracking in a subpattern), callouts (user functions to call at given points), and other interesting, powerful features. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python regular expressions just ain't PCRE
On May 5, 7:19 am, Marc 'BlackJack' Rintsch <[EMAIL PROTECTED]> wrote: > In <[EMAIL PROTECTED]>, Wiseman wrote: > > Note: I know there are LALR parser generators/parsers for Python, but > > the very reason why re exists is to provide a much simpler, more > > productive way to parse or validate simple languages and process text. > > (The pyparse/yappy/yapps/ > generator here> argument could have been used to skip regular > > expression support in the language, or to deprecate re. Would you want > > that? And following the same rule, why would we have Python when > > there's C?) > > I don't follow your reasoning here. `re` is useful for matching tokens > for a higher level parser and C is useful for writing parts that need > hardware access or "raw speed" where pure Python is too slow. > > Regular expressions can become very unreadable compared to Python source > code or EBNF grammars but modeling the tokens in EBNF or Python objects > isn't as compact and readable as simple regular expressions. So both `re` > and higher level parsers are useful together and don't supersede each > other. > > The same holds for C and Python. IMHO. > > Ciao, > Marc 'BlackJack' Rintsch Sure, they don't supersede each other and they don't need to. My point was that the more things you can do with regexes (not really regular expressions anymore), the better -as long as they are powerful enough for what you need to accomplish and they don't become a giant Perl- style hack, of course-, because regular expressions are a built-in, standard feature of Python, and they are much faster to use and write than Python code or some LALR parser definition, and they are more generally known and understood. You aren't going to parse a programming language with a regex, but you can save a lot of time if you can parse simple, but not so simple languages with them. Regular expressions offer a productive alternative to full-fledged parsers for the cases where you don't need them. So saying if you want feature X or feature Y in regular expressions you should use a Bison-like parser sounds a bit like an excuse, because the very reason why regular expressions like these exist is to avoid using big, complex parsers for simple cases. As an analogy, I mentioned Python vs. C: you want to develop high-level languages because they are simpler and more productive than working with C, even if you can do anything with the later. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python regular expressions just ain't PCRE
On May 5, 6:28 pm, [EMAIL PROTECTED] wrote: > I'm not sure what your skill level is, but I would suggest studying the > code, starting in on a patch for one or more of these features, and then > corresponding with the module's maintainers to improve your patch to the > point where it can be accepted. I'll consider creating a new PCRE module for Python that uses the latest version PCRE library. It'll depend on my time availability, but I can write Python extensions, and I haven't used PCRE in a long time, and I recall it was a bit of a hassle, but I could get it done. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python regular expressions just ain't PCRE
On May 5, 10:06 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote: > -1 on this from me. In the past 10 years as a professional > programmer, I've used the wierd extended "regex" features maybe 5 > times total, whether it be in Perl or Python. In contrast, I've had > to work around the slowness of PCRE-style engines by forking off a > grep() or something similar practically every other month. I use these complex features every month on my job, and performance is rarely an issue, at least for our particular application of PCRE. By the way, if you're concerned about performance, you should be interested on once-only subpatterns. -- http://mail.python.org/mailman/listinfo/python-list
Re: Python regular expressions just ain't PCRE
On May 5, 10:44 pm, John Machin <[EMAIL PROTECTED]> wrote:
> "UTF-8 Unicode" is meaningless. Python has internal unicode string
> objects, with comprehensive support for converting to/from str (8-bit)
> string objects. The re module supports unicode patterns and strings.
> PCRE "supports" patterns and strings which are encoded in UTF-8. This
> is quite different, a kludge, incomparable. Operations which inspect/
> modify UTF-8-encoded data are of interest only to folk who are
> constrained to use a language which has nothing resembling a proper
> unicode datatype.
Sure, I know it's a mediocre support for Unicode for an application,
but we're not talking an application here. If I get the PCRE module
done, I'll just PyArg_ParseTuple(args, "et#", "utf-8", &str, &len),
which will be fine for Python's Unicode support and what PCRE does,
and I won't have to deal with this string at all so I couldn't care
less how it's encoded and if I have proper Unicode support in C or
not. (I'm unsure of how Pyrex or SWIG would treat this so I'll just
hand-craft it. It's not like it would be complex; most of the magic
will be pure C, dealing with PCRE's API.)
> There's also the YAGNI factor; most folk would restrict using regular
> expressions to simple grep-like functionality and data validation --
> e.g. re.match("[A-Z][A-Z]?[0-9]{6}[0-9A]$", idno). The few who want to
> recognise yet another little language tend to reach for parsers, using
> regular expressions only in the lexing phase.
Well, I find these features very useful. I've used a complex, LALR
parser to parse complex grammars, but I've solved many problems with
just the PCRE lib. Either way seeing nobody's interested on these
features, I'll see if I can expose PCRE to Python myself; it sounds
like the fairest solution because it doesn't even deal with the re
module - you can do whatever you want with it (though I'd rather have
it stay as it is or enhance it), and I'll still have PCRE. That's if I
find the time to do it though, even having no life.
--
http://mail.python.org/mailman/listinfo/python-list
Python Problem
Hi, The line: import enchant works perfectly OK when I call a Python progrma (sp.py) from IDLE (WInXP). When I try to run it ftom the command line (python sp.py) the response is: Traceback (most recent call last): File "sp.py", line 3, in import enchant ImportError: No module named enchant Searching my computer (the whole of drive c:\) I could not find ANY file called enchant.*. Does anyone know what is wrong? Thanks ((:-() Meir -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Problem
Carsten. I want to thank you for your help. I could not check this until this morning. Now that I checked your answer - THANK YOU. I do have 2 installations of Python on my machine. Once I called Python with a full path - my program orked as expected. Meir -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Problem
Hi, OK - it works in WindowsXP. I installed "enchant" on my SuSE 10.0 (using YAST). The enchant Suse package looks like a general Linux package, not a Python specific. Running the program in Python I am getting the same error message from the line: "import enchant". ImportError: No module named enchant What am I missing? Thanks ((:-() Meir >Hi, > >The line: > >import enchant > >works perfectly OK when I call a Python progrma (sp.py) from IDLE >(WInXP). When I try to run it ftom the command line (python sp.py) the >response is: > >Traceback (most recent call last): > File "sp.py", line 3, in > import enchant >ImportError: No module named enchant > >Searching my computer (the whole of drive c:\) I could not find ANY >file called enchant.*. > >Does anyone know what is wrong? > >Thanks > >((:-() Meir > -- http://mail.python.org/mailman/listinfo/python-list
Re: Python Problem
Marc, Thank you. I followed the instructions in given at pyenchant.sourceforge.net and got the application to work. ((;-)) Meir PS: My challenge now is to port the application to Redhat. I already know that Redhat is missing the pyenchant package - I hope the same installation process will solve the problem. It also missing "threading" and this will be the story for another day. I'll appreciate any hint from anyone who've already solved such a problem M On 12 Sep 2007 07:33:52 GMT, Marc 'BlackJack' Rintsch <[EMAIL PROTECTED]> wrote: >On Wed, 12 Sep 2007 09:09:02 +0200, A.T.Hofkamp wrote: > >> On 2007-09-11, Wiseman <[EMAIL PROTECTED]> wrote: >>> >>> Hi, >>> >>> OK - it works in WindowsXP. >>> I installed "enchant" on my SuSE 10.0 (using YAST). >>> The enchant Suse package looks like a general Linux package, not a >>> Python specific. >> >> You'd seem to be right judging by this web-page: >> http://www.novell.com/products/linuxpackages/suselinux/enchant.html >> >> As you can see, there is no file installed at a path with "python" in it. >> >>> What am I missing? >> >> Python bindings to the library perhaps? >> You may be more lucky with an enchant-dev package (if it exists). I am >> however >> not a Suse user and not an echant user (well, not from my Python code at >> least). > >PyEnchant seems to be an independent project: > > http://pyenchant.sourceforge.net/ > >So there is either an extra package for SuSE or the OP has to build it >himself. > >Ciao, > Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
ssl error with the python mac binary
Hey, I've been using the latest mac ppc/i386 binaries from python.org (https://www.python.org/ftp/python/2.7.8/python-2.7.8-macosx10.5.dmg). >From what I can tell this version is linked against a pretty old version of OpenSSL (OpenSSL 0.9.7l 28 Sep 2006) which doesn't seem to be able to handle new sha-256 certificates. For example I'm unable to use pip (I guess the certificate was updated recently) Searching for gnureadline Reading https://pypi.python.org/simple/gnureadline/ Download error on https://pypi.python.org/simple/gnureadline/: [Errno 1] _ssl.c:510: error:0D0890A1:asn1 encoding routines:ASN1_verify:unknown message digest algorithm -- Some packages may not be found! Am I right in thinking this is an issue with the build of python itself? Is there a way I can upgrade the version of OpenSSL linked with python- or force the python build to look elsewhere for the library? Or will I have to build my own from source? Thanks! Paul -- https://mail.python.org/mailman/listinfo/python-list
Re: ssl error with the python mac binary
On 10 November 2014 22:51, Ned Deily wrote: > In article > , > Paul Wiseman wrote: >> I've been using the latest mac ppc/i386 binaries from python.org >> (https://www.python.org/ftp/python/2.7.8/python-2.7.8-macosx10.5.dmg). >> From what I can tell this version is linked against a pretty old >> version of OpenSSL (OpenSSL 0.9.7l 28 Sep 2006) which doesn't seem to >> be able to handle new sha-256 certificates. >> >> For example I'm unable to use pip (I guess the certificate was updated >> recently) > > Yes, the current python.org certificate does seem to cause problems for > that version of OpenSSL, unfortunately. > >> Am I right in thinking this is an issue with the build of python >> itself? Is there a way I can upgrade the version of OpenSSL linked >> with python- or force the python build to look elsewhere for the >> library? Or will I have to build my own from source? > > In the Pythons from the python.org OS X installers, the Python _ssl and > _hashlib extension modules are dynamically linked with the > system-supplied OpenSSL libraries. If actually running on OS X 10.5, > one would have to rebuild _ssl.so and _hashlib.so, linking them with a > locally-supplied version of a newer OpenSSL, since different versions of > OpenSSL are not ABI-compatible, e.g. 0.9.7 vs 0.9.8 vs 1.0.1. If > running on OS X 10.6 or later, another option might be to install from > the 64-bit/32-bit installer which is a good idea to do anyway. I'm currently using the installer with py2app to make a distributable app that targets 10.5+ (including ppc). To save having more than one build I use this for all downloads. Although I'm starting to consider making a second 32/64 distributable. Are there many major drawbacks for distributing this i386/ppc binary for all versions of OSX up 10.9 and 10.10? > For pip > usage, a workaround would be to manually download distributions from > PyPI (or elsewhere) using a web browser and then use pip to install from > the downloaded file. The next version of pip is expected to have a > --no-check-certificate option that bypasses the certificate check at the > cost of reduced security. Unfortunately the app is contacting a service which I'm unable to contact via plain http, which also happens to have the same type of certificate resulting in the same ssl error. (I have been going directly to pypi though :) > For the upcoming Python 2.7.9 release > (planned for early December), I intend to have the Pythons in the > python.org OS X installers use their own versions of OpenSSL and thus no > longer depend on the now-deprecated system OpenSSL. > That's great news! Thanks for this! I've always found building things on mac a huge pain and wasn't much looking forward to the prospect of trying to build a 32/ppc python build on a 64 bit 10.10 machine (would that even be possible?). > -- > Ned Deily, > [email protected] > > -- > https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: ssl error with the python mac binary
On 12 November 2014 19:52, Ned Deily wrote: > In article > , > Paul Wiseman wrote: >> I'm currently using the installer with py2app to make a distributable >> app that targets 10.5+ (including ppc). To save having more than one >> build I use this for all downloads. Although I'm starting to consider >> making a second 32/64 distributable. Are there many major drawbacks >> for distributing this i386/ppc binary for all versions of OSX up 10.9 >> and 10.10? > > For a standalone app, not really. The main difference is that, by using > the older 10.5 ABI, a few functions in the os module are not available > (if they were implemented first in OS X 10.6 or later) and/or they may > work a little differently. AFAIK, the most impactful difference, by > far, is the OpenSSL version difference you have run into. Up to now, I > don't recall any compatibility problems with 10.5 ABI programs running > on later versions of OS X or, for the most part, mixing extension > modules compiled to later ABIs with a 10.5 Python, although there might > be issues with mixing versions of C++ modules (Python and its standard > library do not use C++ themselves). But, of course, there's no > guarantee that something won't break in a future release of OS X. So > far, so good. > Yea, I'm a bit worried that apple will break it on a future release- I think I will start looking into making a second build. I wonder what are the chances they'll make a 64bit only OSX one day? >> That's great news! Thanks for this! I've always found building things >> on mac a huge pain and wasn't much looking forward to the prospect of >> trying to build a 32/ppc python build on a 64 bit 10.10 machine (would >> that even be possible?). > > It's possible: I do it. But I cheat a bit: I have 10.5 running in a > virtual machine on a 10.10 host. In theory, it's possible to build > natively on 10.10. The trick is getting a version of Xcode 3 installed > on 10.10 since support for building ppc archs was removed in Xcode 4. I > also cheat a bit there: I happen to still have copies of Xcode 3.1.4 and > 3.2.6 installed on 10.10 because I made sure to preserve them through > upgrades from 10.6 days. IIRC, directly installing the necessary > components from 3.2.6 on newer systems would require some hacking. Then > you have to be really vigilant that the build never strays from the old > SDK and tools, which is not something we claim to support at the moment. > The VM approach is quite safe and reliable. > I never thought about a VM for this for some reason- I have a few as well for basic testing on older OSX versions. I remember having to re-enable ppc in later versions of Xcode (http://stackoverflow.com/q/5333490/659346) when I was building some extensions for the app. That was a bit of a pain. Thanks for your help though! look forward to the 2.7.9 release :) > -- > Ned Deily, > [email protected] > > -- > https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: ssl error with the python mac binary
On 10 November 2014 at 22:51, Ned Deily wrote:
> In article
> ,
> Paul Wiseman wrote:
> > I've been using the latest mac ppc/i386 binaries from python.org
> > (https://www.python.org/ftp/python/2.7.8/python-2.7.8-macosx10.5.dmg).
> > From what I can tell this version is linked against a pretty old
> > version of OpenSSL (OpenSSL 0.9.7l 28 Sep 2006) which doesn't seem to
> > be able to handle new sha-256 certificates.
> >
> > For example I'm unable to use pip (I guess the certificate was updated
> > recently)
>
> Yes, the current python.org certificate does seem to cause problems for
> that version of OpenSSL, unfortunately.
>
> > Am I right in thinking this is an issue with the build of python
> > itself? Is there a way I can upgrade the version of OpenSSL linked
> > with python- or force the python build to look elsewhere for the
> > library? Or will I have to build my own from source?
>
> In the Pythons from the python.org OS X installers, the Python _ssl and
> _hashlib extension modules are dynamically linked with the
> system-supplied OpenSSL libraries. If actually running on OS X 10.5,
> one would have to rebuild _ssl.so and _hashlib.so, linking them with a
> locally-supplied version of a newer OpenSSL, since different versions of
> OpenSSL are not ABI-compatible, e.g. 0.9.7 vs 0.9.8 vs 1.0.1. If
> running on OS X 10.6 or later, another option might be to install from
> the 64-bit/32-bit installer which is a good idea to do anyway. For pip
> usage, a workaround would be to manually download distributions from
> PyPI (or elsewhere) using a web browser and then use pip to install from
> the downloaded file. The next version of pip is expected to have a
> --no-check-certificate option that bypasses the certificate check at the
> cost of reduced security. For the upcoming Python 2.7.9 release
> (planned for early December), I intend to have the Pythons in the
> python.org OS X installers use their own versions of OpenSSL and thus no
> longer depend on the now-deprecated system OpenSSL.
>
>
I just gave 2.7.9rc1 a go and seems like it is still linked to the same
version of openssl?
Python 2.7.9rc1 (v2.7.9rc1:40eada278702, Nov 25 2014, 17:10:11)
[GCC 4.2.1 (Apple Inc. build 5577)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>>
>>> import requests
>>> requests.get("https://python.org";)
Traceback (most recent call last):
File "", line 1, in
File
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/requests-2.4.3-py2.7.egg/requests/api.py",
line 60, in get
return request('get', url, **kwargs)
File
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/requests-2.4.3-py2.7.egg/requests/api.py",
line 49, in request
return session.request(method=method, url=url, **kwargs)
File
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/requests-2.4.3-py2.7.egg/requests/sessions.py",
line 457, in request
resp = self.send(prep, **send_kwargs)
File
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/requests-2.4.3-py2.7.egg/requests/sessions.py",
line 569, in send
r = adapter.send(request, **kwargs)
File
"/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/requests-2.4.3-py2.7.egg/requests/adapters.py",
line 420, in send
raise SSLError(e, request=request)
requests.exceptions.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate
verify failed (_ssl.c:581)
>>>
>>> import ssl
>>> ssl.OPENSSL_VERSION
'OpenSSL 0.9.7l 28 Sep 2006'
> --
> Ned Deily,
> [email protected]
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
--
https://mail.python.org/mailman/listinfo/python-list
Re: ssl error with the python mac binary
On 1 December 2014 at 22:59, Ned Deily wrote: > In article > , > Paul Wiseman wrote: > > I just gave 2.7.9rc1 a go and seems like it is still linked to the same > > version of openssl? > > Yes, it still is for rc1. Unfortunately, I was not able to get > everything done in time for rc1 and I didn't want to hold up rc1's > release as there are a lot of other changes that need exposure. The > final release installer *will* have the new version of openssl. > > Awesome thanks Ned! look forward to it :) > -- > Ned Deily, > [email protected] > > -- > https://mail.python.org/mailman/listinfo/python-list > -- https://mail.python.org/mailman/listinfo/python-list
Re: Simulate `bash` behaviour using Python and named pipes.
On 5 August 2013 14:09, Luca Cerone wrote:
> Hi everybody,
> I am trying to understand how to use named pipes in python to launch
> external processes (in a Linux environment).
>
> As an example I am trying to "imitate" the behaviour of the following sets
> of commands is bash:
>
> > mkfifo named_pipe
> > ls -lah > named_pipe &
> > cat < named_pipe
>
> In Python I have tried the following commands:
>
> import os
> import subprocess as sp
>
> os.mkfifo("named_pipe",0777) #equivalent to mkfifo in bash..
> fw = open("named_pipe",'w')
> #at this point the system hangs...
>
> My idea it was to use subprocess.Popen and redirect stdout to fw...
> next open named_pipe for reading and giving it as input to cat (still
> using Popen).
>
> I know it is a simple (and rather stupid) example, but I can't manage to
> make it work..
>
>
> How would you implement such simple scenario?
>
> Thanks a lot in advance for the help!!!
>
>
You can pipe using subprocess
p1 = subprocess.Popen(["ls", "-lah"], stdout=subprocess.PIPE)
p2 = subprocess.Popen(["cat"], stdin=p1.stdout)
p1.wait()
p2.wait()
You can also pass a file object to p1's stdout and p2's stdin if you want
to pipe via a file.
with open("named_pipe", "rw") as named_pipe:
p1 = subprocess.Popen(["ls", "-lah"], stdout=named_pipe)
p2 = subprocess.Popen(["cat"], stdin=named_pipe)
p1.wait()
p2.wait()
> Luca
> --
> http://mail.python.org/mailman/listinfo/python-list
>
--
http://mail.python.org/mailman/listinfo/python-list
Re: error with files
The line should be:
file1.write(file_data)
you could write
file.write(file1, file_data)
but that would be an odd way to do it :)
On 18 August 2014 10:41, ngangsia akumbo wrote:
> error
>
> yems ~ # nano testfile1
> yems ~ # python testfile1
> Enter file name: g
> write in data: g
> Traceback (most recent call last):
> File "testfile1", line 11, in
> file.write(file1)
> TypeError: function takes exactly 1 argument (0 given)
>
>
>
> import os.path
>
> save_here = '/home/yems/newfile/'
> file_name = raw_input("Enter file name: ")
> filesname = os.path.join(save_here, file_name+".txt")
>
> file1 = open(filesname, 'w')
>
> file_data = raw_input('write in data: ')
>
> file.write(file1)
>
> file1.close()
> --
> https://mail.python.org/mailman/listinfo/python-list
--
https://mail.python.org/mailman/listinfo/python-list
