Re: [Python-Dev] New regex module for 3.2?
Am 09.07.2010 02:35, schrieb MRAB: >> That's not what I'm asking. I'm asking what happens if you take an >> existing Python installation's re module, move it aside, and drop >> regex in its place as "re.py". >> >> Doing that and then running Python's own test suite as well as the >> test suites of major Python applications and frameworks like Twisted, >> Zope and Django would provide solid evidence that the new version >> really *is* backwards compatible, rather than that it is *meant* to be >> backwards compatible. >> > I had to recompile the .pyd to change its internal name from "regex" to > "re", but apart from that it passed Python's own test suite except for > where I expected it to fail: > > 1. Some of the inline flags are scoped; for example, putting "(?i)" at > the end of a regex will now have no effect because it's no longer a > global, all-or-nothing, flag. That is problematic. I've often seen people put these flags at the end of a regex, probably for readability purposes. IMHO it would be better to limit flag scoping to the explicit (?flags-flags: ) groups. > 2. The .sub method will treat unmatched groups in an expansion as empty > strings. The re module raises an exception in such cases, which means > that users currently need a workaround. That is a change for the better, I would say. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ 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] Py_Buffer and pep3118
Hello there. I´m in the process of upgrading code to use python 2.7 and the new Py_Buffer objects. I have, however, come across an inconsistency in the documentation, both in the pep and the python docs, with the actual implementation. In addition to the different function signatures mentioned in issue 8946, the Py_Buffer member 'obj' is undocumented. The inline comment in object.h mentiones that it is a "borrowed reference" but this appears inconsistent with the implementation of PyBuffer_Release(). In short, what the documentation fails to mention (and the pep) is whether posessing a locked Py_Buffer structure also constitutes holding a reference to the exporting object? I think it does, but is this guaranteed to be so? Also, is the PyBuffer_Release() guaranteed to be "safe" to call multiple times (as the current implementation is)? Kristján ___ 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] query: docstring formatting in python distutils code
Georg Brandl writes: > Am 08.07.2010 17:44, schrieb Martin Geisler: >> Steve Holden writes: >> >>> Martin Geisler wrote: "Stephen J. Turnbull" writes: > Just ask Martin, there are too many possibilities here to worry > about. If maybe we want it, and he is willing to contribute the > parts he wrote to Python under Python's license, then we can worry > about whether we really want it and about how much any required > hoop-jumping will cost. I would be happy to relicense it under the Python license. >>> >>> I believe the ideal outcome, if it is possible, is for you to sign a >>> contributor agreement. This will license your material to the PSF in >>> such a way that we can release it under whatever license we deem >>> necessary. >> >> Sure, I'll be happy to sign a contributor agreement if you guys think it >> worthwhile to use my little parser and formatter. > > Problem is, in the case of help() we have no way of knowing whether the > given __doc__ string is supposed to be (mini)reST. Of course, reverting > to showing the plain content on parsing errors is one possibility, but > I can still imagine instances where something is successfully interpreted > as reST, but intended to be read and understood verbatim by the author. The minirst module is actually designed to never fail: the text is first divided into paragraphs, and the paragraphs are then looked at one by one to see if they look like something more specific like a list. > It's different for Hg, of course, there you can just decide that help > texts have to be reST. Right, good point. At first I figured that you could also "just" convert the docstrings in Python, but since the help builtin is used on lots of code outside of Python this isn't really enough. -- Martin Geisler aragost Trifork -- Professional Mercurial support http://aragost.com/mercurial/ ___ 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] query: docstring formatting in python distutils code
On Fri, Jul 9, 2010 at 2:51 AM, Georg Brandl wrote: > Yes, but[tm] it is not always easy to find the correct module to look for > __docformat__ when given an object. True. That PEP was written before decorators were common, in particular. That's changed the landscape in substantial ways. It may be that at this point, there's no good way to deal with formatting in docstrings at anything other than the project level, where policies for the code can be set if desired. Ideally, the format of a docstring would be captured along with the docstring itself. -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ 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] Py_Buffer and pep3118
In addition, the PyBufferProcs documentation has not bee updated to reflect the new buffer interface. From: python-dev-bounces+kristjan=ccpgames@python.org [mailto:python-dev-bounces+kristjan=ccpgames@python.org] On Behalf Of Kristján Valur Jónsson Sent: 9. júlí 2010 08:39 To: Python-Dev Subject: [Python-Dev] Py_Buffer and pep3118 Hello there. I´m in the process of upgrading code to use python 2.7 and the new Py_Buffer objects. I have, however, come across an inconsistency in the documentation, both in the pep and the python docs, with the actual implementation. In addition to the different function signatures mentioned in issue 8946, the Py_Buffer member 'obj' is undocumented. The inline comment in object.h mentiones that it is a "borrowed reference" but this appears inconsistent with the implementation of PyBuffer_Release(). In short, what the documentation fails to mention (and the pep) is whether posessing a locked Py_Buffer structure also constitutes holding a reference to the exporting object? I think it does, but is this guaranteed to be so? Also, is the PyBuffer_Release() guaranteed to be "safe" to call multiple times (as the current implementation is)? Kristján ___ 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] Full unicode support for the import machinery
On Fri, Jul 9, 2010 at 10:11 AM, Victor Stinner wrote: > I created an svn branch because I think that it's easier to review short > commits than one unique huge patch. The branch also helps me to share the > branch between different computers, and allow other people to review the > commits (and/or contribute!). Thanks for doing that, it does indeed make it much easier to follow your train of thought. The overall approach looks sane, and while I haven't done a line-by-line review of every patch on the branch, the ones I did examine in detail all looked correct. I'll try to keep up as you make more changes. You're a brave soul, venturing into that there-is-no-Unicode-there-is-only-ASCII maze, but you've already made substantial improvements. The addition of new more Unicode friendly C APIs for errors and warnings should be of general use outside this work as well (but given where you're up to, I don't advocate trying to cherry pick them off the branch). 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] Py_Buffer and pep3118
On Fri, 9 Jul 2010 08:38:53 + Kristján Valur Jónsson wrote: > > In short, what the documentation fails to mention (and the pep) is whether > posessing a > locked Py_Buffer structure also constitutes holding a reference to the > exporting object? It does. > I think it does, but is this guaranteed to be so? Now that's a good question. This was changed so that every producer of tp_buffer doesn't have to do it by itself. In any case, acquiring the buffer means it will be valid until it is released, which is what you should primarily care about. > Also, is the PyBuffer_Release() guaranteed to be "safe" to call > multiple times (as the current implementation is)? It's not, but we could make it so. 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] query: docstring formatting in python distutils code
On Jul 07, 2010, at 12:50 PM, Brett Cannon wrote: >On Wed, Jul 7, 2010 at 11:46, Antoine Pitrou >wrote: >> On Wed, 7 Jul 2010 14:12:17 -0400 >> Barry Warsaw wrote: >>> On Jul 07, 2010, at 07:30 PM, Georg Brandl wrote: >>> >>> >Overall, I think that we can make stdlib docstrings valid reST -- >>> >even if it's reST without much markup -- but valid, so that people >>> >pulling in stdlib doc- strings into Sphinx docs won't get ugly >>> >warnings. >>> > >>> >What I would *not* like to see is heavy markup and Sphinx >>> >specifics -- that would only make sense if we included the >>> >docstrings in the docs, and I don't see that coming. >>> >>> Does it make sense to add (reST-style) epydoc markup for API >>> signatures? E.g. >> >> It really looks ugly (and annoying to decipher) when viewed in plain >> text. > >I agree. And it is highly repetitive since the signature information >is right there already. All of that info in those annotations can >easily be written in paragraph form if needed and honestly would read >better to my eyes. I actually find it easier to glean the signature details from a regularized docstring than from prose. Especially for autogenerated API documentation, the formal specification lends a consistency to the output that prose doesn't often provide. IME, there isn't much (unnecessary) repeating yourself. Either way, we need to be diligent in accurately describing the signature and semantics of our APIs. -Barry signature.asc Description: 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] New regex module for 3.2?
On Thu, Jul 8, 2010 at 10:52 PM, MRAB wrote: > Hi all, > > I re-implemented the re module, adding new features and speed > improvements. It's available at: > > http://pypi.python.org/pypi/regex > > under the name "regex" so that it can be tried alongside "re". > > I'd be interested in any comments or feedback. How does it compare with > "re" in terms of speed on real-world data? The benchmarks suggest it > should be faster, or at worst comparable. And where are the benchmarks? In particular it would be interesting to see it compared both to re from stdlib and re2 from http://code.google.com/p/re2/ -- anatoly t. ___ 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] A grammatical oddity: trailing commas in argument lists.
While looking at a parser module issue (http://bugs.python.org/issue9154) I noticed that Python's grammar doesn't permit trailing commas after keyword-only args. That is, def f(a, b,): pass is valid syntax, while def f(*, a, b,): pass is not. I was just curious whether the latter was deliberate or an oversight. And if an oversight, is it worth fixing after the moratorium expires? (See also http://bugs.python.org/issue2009.) Mark ___ 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] New regex module for 3.2?
On Fri, Jul 9, 2010 at 7:06 AM, anatoly techtonik wrote: > On Thu, Jul 8, 2010 at 10:52 PM, MRAB wrote: >> Hi all, >> >> I re-implemented the re module, adding new features and speed >> improvements. It's available at: >> >> http://pypi.python.org/pypi/regex >> >> under the name "regex" so that it can be tried alongside "re". >> >> I'd be interested in any comments or feedback. How does it compare with >> "re" in terms of speed on real-world data? The benchmarks suggest it >> should be faster, or at worst comparable. > > And where are the benchmarks? > In particular it would be interesting to see it compared both to re > from stdlib and re2 from http://code.google.com/p/re2/ While the re2 comparison might be interesting from an abstract standpoint, it intentionally supports a different regex language from Python so that it can run faster and use less memory. Since re2 can never replace Python's re module, it doesn't make sense to hold MRAB's new module to that standard. ___ 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] Summary of Python tracker Issues
ACTIVITY SUMMARY (2010-07-02 - 2010-07-09) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 2813 open (+52) / 18217 closed (+15) / 21030 total (+67) Open issues with patches: 1133 Average duration of open issues: 706 days. Median duration of open issues: 503 days. Open Issues Breakdown open 2779 (+51) languishing14 ( +0) pending19 ( +1) Issues Created Or Reopened (75) ___ backport 3.0-style \u/\U processing in raw strings when unicod 2010-07-07 http://bugs.python.org/issue2570reopened alexandre.vassalotti patch audioop: check that length is a multiple of the size 2010-07-04 CLOSED http://bugs.python.org/issue7673reopened pitrou patch sys.getwindowsversion as PyStructSequence 2010-07-08 CLOSED http://bugs.python.org/issue7766reopened brian.curtin patch, patch, needs review dis module documentation gives no indication of the dangers of 2010-07-05 http://bugs.python.org/issue7829reopened tjreedy needs review `make patchcheck` should check the whitespace of .c/.h files 2010-07-05 http://bugs.python.org/issue8912reopened belopolsky patch, needs review Year range in timetuple2010-07-05 http://bugs.python.org/issue9005reopened belopolsky patch Separate compilation of time and datetime modules 2010-07-04 http://bugs.python.org/issue9012reopened doko patch str.capitalize() should not lower the rest of the string 2010-07-04 CLOSED http://bugs.python.org/issue9091reopened tjreedy patch test_coercion fails in refleak runs2010-07-02 CLOSED http://bugs.python.org/issue9145created pitrou Segfault in hashlib in OpenSSL FIPS mode using non-FIPS-compli 2010-07-02 http://bugs.python.org/issue9146created dmalcolm patch dis.show_code() variant that accepts source strings (and retur 2010-07-03 http://bugs.python.org/issue9147created ncoghlan os.execve puts process to background on windows2010-07-03 http://bugs.python.org/issue9148created techtonik colorsys.py function rgb_to_hls2010-07-03 CLOSED http://bugs.python.org/issue9149created David.Hood IDLE should not save trailing whitespace after strip trailing 2010-07-03 http://bugs.python.org/issue9150created rhprogrammer Demo/classes/Dates.py does not work in 3.x 2010-07-03 CLOSED http://bugs.python.org/issue9151created belopolsky patch, easy Dead code in datetime module 2010-07-04 CLOSED http://bugs.python.org/issue9152created belopolsky patch, easy Run tests and demos as part of the test suite 2010-07-04 http://bugs.python.org/issue9153created merwok Parser module doesn't understand function annotations. 2010-07-04 http://bugs.python.org/issue9154created mark.dickinson patch Reserve COMPARE_OP for rich c
Re: [Python-Dev] A grammatical oddity: trailing commas in argument lists.
On 7/9/10 10:40 AM, Mark Dickinson wrote: While looking at a parser module issue (http://bugs.python.org/issue9154) I noticed that Python's grammar doesn't permit trailing commas after keyword-only args. That is, def f(a, b,): pass is valid syntax, while def f(*, a, b,): pass is not. I was just curious whether the latter was deliberate or an oversight. And if an oversight, is it worth fixing after the moratorium expires? (See also http://bugs.python.org/issue2009.) I use trailing commas all the time in argument lists. I don't use keyword-only args much, but I will when I switch to 3.x. I'd like to see this fixed. I'd argue it's a bug fix, but that's me. -- Eric. ___ 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] Can ftp url start with file:// ?
Senthil Kumaran wrote: > On Fri, Jul 09, 2010 at 02:23:40PM +1000, Steven D'Aprano wrote: > > > Is this is valid ftp url? > > > > > > # file://ftp.example.com/blah.txt (an ftp URL) > > > > > > My answer is no. When we have the scheme specifically mentioned as > > > file:// it is no point in considering it as ftp url (which should > > > start with ftp://). > > > > I agree. Just because the host is *called* ftp doesn't mean you should > > use the ftp protocol to get the file. > > It was not just for the host being called ftp.example.com > > It was for a pattern that file:/// is local file (correct) and > file://localhost/somepath is again local file (correct again) but > file://anyhost.domain/file.txt is actually ftp (pretty weird). RFC 1738 explicitly says that "file:///" is pretty much useless for anything except host=localhost: ``The file URL scheme is unusual in that it does not specify an Internet protocol or access method for such files; as such, its utility in network protocols between hosts is limited.'' So, FTP is *not* the "default protocol". On the other hand, if actually begins with "ftp.", it's a pretty good guess that FTP will work. Similarly, if actually begins with "www.", it's a pretty good guess that HTTP will work. This seems to me like a practicality-vs.-purity consideration. 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] New regex module for 3.2?
anatoly techtonik wrote: On Thu, Jul 8, 2010 at 10:52 PM, MRAB wrote: Hi all, I re-implemented the re module, adding new features and speed improvements. It's available at: http://pypi.python.org/pypi/regex under the name "regex" so that it can be tried alongside "re". I'd be interested in any comments or feedback. How does it compare with "re" in terms of speed on real-world data? The benchmarks suggest it should be faster, or at worst comparable. And where are the benchmarks? In particular it would be interesting to see it compared both to re from stdlib and re2 from http://code.google.com/p/re2/ The benchmarks bm_regex_effbot.py and bm_regex_v8.py both perform multiple runs of the tests multiple times, giving just the total times for each set. Here are the averages: Python26 BENCHMARKre regex ratio bm_regex_effbot 0.135secs 0.083secs 1.63 bm_regex_v8 0.153secs 0.085secs 1.80 Python31 BENCHMARKre regex ratio bm_regex_effbot 0.138secs 0.083secs 1.66 bm_regex_v8 0.170secs 0.091secs 1.87 ___ 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] Can ftp url start with file:// ?
On Fri, Jul 9, 2010 at 12:41, Bill Janssen wrote:
> So, FTP is *not* the "default protocol". On the other hand, if
> actually begins with "ftp.", it's a pretty good guess that FTP will
> work.
Actually, FTP *is* the default protocol for most URLs with hostnames in
urllib.py.
urllib.open_file() delegates to open_ftp() if there's a any host other than
the exact string "localhost", and open_local_file() otherwise.
>>> import urllib
>>> f =urllib.urlopen('file:///foo.txt')
>>> f =urllib.urlopen('file://localhost/foo.txt')
>>> f = urllib.urlopen('file://www.google.com/')
Traceback (most recent call last):
File "", line 1, in
File "c:\python25\lib\urllib.py", line 82, in urlopen
return opener.open(url)
File "c:\python25\lib\urllib.py", line 190, in open
return getattr(self, name)(url)
File "c:\python25\lib\urllib.py", line 457, in open_file
return self.open_ftp(url)
File "c:\python25\lib\urllib.py", line 538, in open_ftp
ftpwrapper(user, passwd, host, port, dirs)
File "c:\python25\lib\urllib.py", line 844, in __init__
self.init()
File "c:\python25\lib\urllib.py", line 850, in init
self.ftp.connect(self.host, self.port)
File "c:\python25\lib\ftplib.py", line 129, in connect
raise socket.error, msg
IOError: [Errno ftp error] (10060, 'Operation timed out')
>>> f =urllib.urlopen('file://127.0.0.1/foo.txt')
Traceback (most recent call last):
File "", line 1, in
File "c:\python25\lib\urllib.py", line 82, in urlopen
return opener.open(url)
File "c:\python25\lib\urllib.py", line 190, in open
return getattr(self, name)(url)
File "c:\python25\lib\urllib.py", line 457, in open_file
return self.open_ftp(url)
File "c:\python25\lib\urllib.py", line 538, in open_ftp
ftpwrapper(user, passwd, host, port, dirs)
File "c:\python25\lib\urllib.py", line 844, in __init__
self.init()
File "c:\python25\lib\urllib.py", line 850, in init
self.ftp.connect(self.host, self.port)
File "c:\python25\lib\ftplib.py", line 129, in connect
raise socket.error, msg
IOError: [Errno ftp error] (10061, 'Connection refused')
--
Tim Lesher
___
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] A grammatical oddity: trailing commas in argument lists.
Am 09.07.2010 18:36, schrieb Eric Smith: > On 7/9/10 10:40 AM, Mark Dickinson wrote: >> While looking at a parser module issue >> (http://bugs.python.org/issue9154) I noticed that Python's grammar >> doesn't permit trailing commas after keyword-only args. That is, >> >> def f(a, b,): pass >> >> is valid syntax, while >> >> def f(*, a, b,): pass >> >> is not. I was just curious whether the latter was deliberate or an >> oversight. And if an oversight, is it worth fixing after the >> moratorium expires? (See also http://bugs.python.org/issue2009.) > > I use trailing commas all the time in argument lists. I don't use > keyword-only args much, but I will when I switch to 3.x. I'd like to see > this fixed. I'd argue it's a bug fix, but that's me. +1 Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ 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] Can ftp url start with file:// ?
To be clear, Python 2.x's urllib.urlopen() has this issue; 3.1's urllib.request.urlopen() rejects non-local hosts in a file URL. -- Tim Lesher ___ 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] Can ftp url start with file:// ?
Tim Lesher wrote:
> On Fri, Jul 9, 2010 at 12:41, Bill Janssen wrote:
>
> > So, FTP is *not* the "default protocol". On the other hand, if
> > actually begins with "ftp.", it's a pretty good guess that FTP will
> > work.
>
>
> Actually, FTP *is* the default protocol for most URLs with hostnames in
> urllib.py.
>
> urllib.open_file() delegates to open_ftp() if there's a any host other than
> the exact string "localhost", and open_local_file() otherwise.
I just meant to point out that it's not specified that way by any RFC.
And, while FTP might have been a good default choice last century when
urllib.py was originally written, times have changed. I'd suggest that
HTTP is a better (more likely to succeed) default choice in this century.
If we want to perpetuate these guessing heuristics, I'd suggest using
FTP if the hostname starts with "ftp.", and HTTP if the hostname starts
with "www.", and raise an error otherwise.
Bill
> >>> import urllib
> >>> f =urllib.urlopen('file:///foo.txt')
> >>> f =urllib.urlopen('file://localhost/foo.txt')
> >>> f = urllib.urlopen('file://www.google.com/')
> Traceback (most recent call last):
> File "", line 1, in
> File "c:\python25\lib\urllib.py", line 82, in urlopen
> return opener.open(url)
> File "c:\python25\lib\urllib.py", line 190, in open
> return getattr(self, name)(url)
> File "c:\python25\lib\urllib.py", line 457, in open_file
> return self.open_ftp(url)
> File "c:\python25\lib\urllib.py", line 538, in open_ftp
> ftpwrapper(user, passwd, host, port, dirs)
> File "c:\python25\lib\urllib.py", line 844, in __init__
> self.init()
> File "c:\python25\lib\urllib.py", line 850, in init
> self.ftp.connect(self.host, self.port)
> File "c:\python25\lib\ftplib.py", line 129, in connect
> raise socket.error, msg
> IOError: [Errno ftp error] (10060, 'Operation timed out')
> >>> f =urllib.urlopen('file://127.0.0.1/foo.txt')
> Traceback (most recent call last):
> File "", line 1, in
> File "c:\python25\lib\urllib.py", line 82, in urlopen
> return opener.open(url)
> File "c:\python25\lib\urllib.py", line 190, in open
> return getattr(self, name)(url)
> File "c:\python25\lib\urllib.py", line 457, in open_file
> return self.open_ftp(url)
> File "c:\python25\lib\urllib.py", line 538, in open_ftp
> ftpwrapper(user, passwd, host, port, dirs)
> File "c:\python25\lib\urllib.py", line 844, in __init__
> self.init()
> File "c:\python25\lib\urllib.py", line 850, in init
> self.ftp.connect(self.host, self.port)
> File "c:\python25\lib\ftplib.py", line 129, in connect
> raise socket.error, msg
> IOError: [Errno ftp error] (10061, 'Connection refused')
> --
> Tim Lesher
> ___
> 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/janssen%40parc.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] Can ftp url start with file:// ?
On 9 July 2010 19:04, Bill Janssen wrote: > If we want to perpetuate these guessing heuristics, I'd suggest using > FTP if the hostname starts with "ftp.", and HTTP if the hostname starts > with "www.", and raise an error otherwise. >From what Tim says, it sounds like guessing is only in 2.x. Removing the guessing clearly isn't a bug fix, so there's nothing to do in the 2.x line (as there won't be a 2.8). 3.1 already has the stricter (and in my view correct) behaviour, and I see no reason to introduce the 2.x behaviour into Python 3. So I'd say there's nothing to do. Paul. ___ 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] Can ftp url start with file:// ?
On Fri, Jul 9, 2010 at 2:04 PM, Bill Janssen wrote: > I'd suggest that > HTTP is a better (more likely to succeed) default choice in this century. FTP access also more often reflected the actual file hierarchy of the machine, so trying that path as a system path is more likely to work that I'd expect to see for HTTP. Really, I'd expect any non-local file: URLs to be kicked back to the application, and let it decide to re-write if it wants to. -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ 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] Can ftp url start with file:// ?
Paul Moore wrote: > On 9 July 2010 19:04, Bill Janssen wrote: >> If we want to perpetuate these guessing heuristics, I'd suggest using >> FTP if the hostname starts with "ftp.", and HTTP if the hostname starts >> with "www.", and raise an error otherwise. > >>From what Tim says, it sounds like guessing is only in 2.x. Removing > the guessing clearly isn't a bug fix, so there's nothing to do in the > 2.x line (as there won't be a 2.8). 3.1 already has the stricter (and > in my view correct) behaviour, and I see no reason to introduce the > 2.x behaviour into Python 3. > > So I'd say there's nothing to do. > Paul. This /could/ become a bugfix in 2.7.x if people thought it was a sufficiently egregious bug to need fixing. Given that the matter is only now coming to light it's probably bets to let sleeping dogs lie. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 DjangoCon US September 7-9, 2010http://djangocon.us/ See Python Video! http://python.mirocommunity.org/ Holden Web LLC http://www.holdenweb.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] New regex module for 3.2?
On Fri, Jul 9, 2010 at 10:28 AM, MRAB wrote: > anatoly techtonik wrote: >> >> On Thu, Jul 8, 2010 at 10:52 PM, MRAB wrote: >>> >>> Hi all, >>> >>> I re-implemented the re module, adding new features and speed >>> improvements. It's available at: >>> >>> http://pypi.python.org/pypi/regex >>> >>> under the name "regex" so that it can be tried alongside "re". >>> >>> I'd be interested in any comments or feedback. How does it compare with >>> "re" in terms of speed on real-world data? The benchmarks suggest it >>> should be faster, or at worst comparable. >> >> And where are the benchmarks? >> In particular it would be interesting to see it compared both to re >> from stdlib and re2 from http://code.google.com/p/re2/ >> > The benchmarks bm_regex_effbot.py and bm_regex_v8.py both perform > multiple runs of the tests multiple times, giving just the total times > for each set. Here are the averages: > > Python26 > BENCHMARK re regex ratio > bm_regex_effbot 0.135secs 0.083secs 1.63 > bm_regex_v8 0.153secs 0.085secs 1.80 > > > Python31 > BENCHMARK re regex ratio > bm_regex_effbot 0.138secs 0.083secs 1.66 > bm_regex_v8 0.170secs 0.091secs 1.87 Out of curiosity, what are the results for the bm_regex_compile benchmark? Collin ___ 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] query: docstring formatting in python distutils code
On Fri, Jul 9, 2010 at 06:28, Barry Warsaw wrote: > On Jul 07, 2010, at 12:50 PM, Brett Cannon wrote: > >>On Wed, Jul 7, 2010 at 11:46, Antoine Pitrou >>wrote: >>> On Wed, 7 Jul 2010 14:12:17 -0400 >>> Barry Warsaw wrote: On Jul 07, 2010, at 07:30 PM, Georg Brandl wrote: >Overall, I think that we can make stdlib docstrings valid reST -- >even if it's reST without much markup -- but valid, so that people >pulling in stdlib doc- strings into Sphinx docs won't get ugly >warnings. > >What I would *not* like to see is heavy markup and Sphinx >specifics -- that would only make sense if we included the >docstrings in the docs, and I don't see that coming. Does it make sense to add (reST-style) epydoc markup for API signatures? E.g. >>> >>> It really looks ugly (and annoying to decipher) when viewed in plain >>> text. >> >>I agree. And it is highly repetitive since the signature information >>is right there already. All of that info in those annotations can >>easily be written in paragraph form if needed and honestly would read >>better to my eyes. > > I actually find it easier to glean the signature details from a regularized > docstring than from prose. Especially for autogenerated API documentation, > the formal specification lends a consistency to the output that prose doesn't > often provide. IME, there isn't much (unnecessary) repeating yourself. The key point there is "autogenerated API documentation", which Python does not do. > > Either way, we need to be diligent in accurately describing the signature and > semantics of our APIs. Of course. I think this is going to be something our crazy FLUFL likes but the kids don't. =) -Brett > > -Barry > > ___ > 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/brett%40python.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] query: docstring formatting in python distutils code
On Jul 09, 2010, at 11:55 AM, Brett Cannon wrote: >I think this is going to be something our crazy FLUFL likes but the >kids don't. =) Don't worry. If you're lucky, you'll get old too. Your eyes will go bad and your mind will think more about tapioca. By then you might even remember that the FLUFL was right after all. :) -Barry signature.asc Description: 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] A grammatical oddity: trailing commas in argument lists.
On 7/9/2010 10:40 AM, Mark Dickinson wrote: While looking at a parser module issue (http://bugs.python.org/issue9154) I noticed that Python's grammar doesn't permit trailing commas after keyword-only args. That is, def f(a, b,): pass is valid syntax, while def f(*, a, b,): pass is not. I was just curious whether the latter was deliberate or an oversight. And if an oversight, is it worth fixing after the moratorium expires? (See also http://bugs.python.org/issue2009.) The way I read the grammar in the function definition section of the manual, a trailing comma is only allowed after a 'defparameter' that does not come after a *. In this sense, the above is not a bug. However, while the grammar in the call doc does not allow trailing commas, the following note says "A trailing comma may be present after the positional and keyword arguments but does not affect the semantics." This has the combined effect >>> def f(*,a): pass >>> f(a=1) >>> f(a=1,) >>> def f(*,a,): pass SyntaxError: invalid syntax This violates the important principle that allowed def and call arg sequences should match to the extent sensible and possible. In this sense, the SyntaxError is a bug. So I would fix this now for 3.2 and notify the other implementors. -- Terry Jan Reedy ___ 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] New regex module for 3.2?
Collin Winter wrote: On Fri, Jul 9, 2010 at 10:28 AM, MRAB wrote: anatoly techtonik wrote: On Thu, Jul 8, 2010 at 10:52 PM, MRAB wrote: Hi all, I re-implemented the re module, adding new features and speed improvements. It's available at: http://pypi.python.org/pypi/regex under the name "regex" so that it can be tried alongside "re". I'd be interested in any comments or feedback. How does it compare with "re" in terms of speed on real-world data? The benchmarks suggest it should be faster, or at worst comparable. And where are the benchmarks? In particular it would be interesting to see it compared both to re from stdlib and re2 from http://code.google.com/p/re2/ The benchmarks bm_regex_effbot.py and bm_regex_v8.py both perform multiple runs of the tests multiple times, giving just the total times for each set. Here are the averages: Python26 BENCHMARKre regex ratio bm_regex_effbot 0.135secs 0.083secs 1.63 bm_regex_v8 0.153secs 0.085secs 1.80 Python31 BENCHMARKre regex ratio bm_regex_effbot 0.138secs 0.083secs 1.66 bm_regex_v8 0.170secs 0.091secs 1.87 Out of curiosity, what are the results for the bm_regex_compile benchmark? I concentrated my efforts on the matching speed because regexes tend to be compiled only once, and are cached anyway, so I don't think it's as important. The results are: Python26 BENCHMARK re regex ratio bm_regex_compile 0.897secs 2.792secs 0.32 Python31 BENCHMARK re regex ratio bm_regex_compile 0.902secs 2.731secs 0.33 If anyone can demonstrate that it'll have a significant impact in practice then I will, of course, look into it further. ___ 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] A grammatical oddity: trailing commas in argument lists.
Terry wrote: > This violates the important principle that allowed def and call arg > sequences should match to the extent sensible and possible. In this > sense, the SyntaxError is a bug. So I would fix this now for 3.2 and > notify the other implementors. +1 on fixing it - trailing commas are awesome. I'm always annoyed in C# where I frequently can't use them. This seems like a bug fix level change that should be easy for the other implementations to fix. ___ 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] New regex module for 3.2?
On Fri, Jul 9, 2010 at 3:35 PM, MRAB wrote: > I concentrated my efforts on the matching speed because regexes tend to > be compiled only once, and are cached anyway, so I don't think it's as > important. I think most here will agree with that, but it might be good to keep in mind that the sre implementation has already made that trade-off once. I don't remember what the compilation slowdown was at the time, but I'd be surprised if Google can't find it, given sufficient fu. -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ 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] A grammatical oddity: trailing commas in argument lists.
On Fri, Jul 9, 2010 at 8:37 PM, Dino Viehland wrote: > Terry wrote: >> This violates the important principle that allowed def and call arg >> sequences should match to the extent sensible and possible. In this >> sense, the SyntaxError is a bug. So I would fix this now for 3.2 and >> notify the other implementors. > > +1 on fixing it - trailing commas are awesome. I'm always annoyed in > C# where I frequently can't use them. This seems like a bug fix level > change that should be easy for the other implementations to fix. Thanks for all the feedback. If the grammar is changed to allow "def f(*, a,): pass", that still leaves some more open questions: which of the following should be valid? (1) def f(*args,): pass (2) def f(**kwargs,): pass (3) def f(*,): pass Just for the sake of simplicity it would seem to make sense allow all these, even if there's no obvious immediate use; for me, it keeps the mental footprint of the language small---I don't have to remember when the comma is or isn't allowed. Note that (1) and (2) aren't valid (and never have been, as far as I know) in Python 2.x, though. (Neither is (3), of course, since keyword-only arguments are 3.x only.) (3) is a bit subtle: "def f(*): pass" is actually allowed by the grammar, but produces a SyntaxError later on, when the parse tree is converted to AST: >>> def f(*): pass ... File "", line 1 SyntaxError: named arguments must follow bare * So it probably doesn't matter much whether (3) is permitted by the grammar or not. -- Mark ___ 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] A grammatical oddity: trailing commas in argument lists.
Am 09.07.2010 22:26, schrieb Mark Dickinson: > On Fri, Jul 9, 2010 at 8:37 PM, Dino Viehland wrote: >> Terry wrote: >>> This violates the important principle that allowed def and call arg >>> sequences should match to the extent sensible and possible. In this >>> sense, the SyntaxError is a bug. So I would fix this now for 3.2 and >>> notify the other implementors. >> >> +1 on fixing it - trailing commas are awesome. I'm always annoyed in >> C# where I frequently can't use them. This seems like a bug fix level >> change that should be easy for the other implementations to fix. > > Thanks for all the feedback. > > If the grammar is changed to allow "def f(*, a,): pass", that still > leaves some more open questions: which of the following should be > valid? > > (1) def f(*args,): pass > (2) def f(**kwargs,): pass > (3) def f(*,): pass IMO all of them (though as you mention, (3) doesn't matter.) Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ 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] New regex module for 3.2?
H as long as we aren't the ones writing the check:) BJ --Original Message-- From: Fred Drake Sent: Fri, July 09, 2010 1:16 PM To: MRAB Cc: Python-Dev Subject: Re: [Python-Dev] New regex module for 3.2? On Fri, Jul 9, 2010 at 3:35 PM, MRAB wrote: > I concentrated my efforts on the matching speed because regexes tend to > be compiled only once, and are cached anyway, so I don't think it's as > important. I think most here will agree with that, but it might be good to keep in mind that the sre implementation has already made that trade-off once. I don't remember what the compilation slowdown was at the time, but I'd be surprised if Google can't find it, given sufficient fu. -Fred -- Fred L. Drake, Jr. "A storm broke loose in my mind." --Albert Einstein ___ 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/bj.wahl%40oracle.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] A grammatical oddity: trailing commas in argument lists.
On 7/9/2010 4:42 PM, Georg Brandl wrote: Am 09.07.2010 22:26, schrieb Mark Dickinson: On Fri, Jul 9, 2010 at 8:37 PM, Dino Viehland wrote: Terry wrote: This violates the important principle that allowed def and call arg sequences should match to the extent sensible and possible. In this sense, the SyntaxError is a bug. So I would fix this now for 3.2 and notify the other implementors. +1 on fixing it - trailing commas are awesome. I'm always annoyed in C# where I frequently can't use them. This seems like a bug fix level change that should be easy for the other implementations to fix. Thanks for all the feedback. If the grammar is changed to allow "def f(*, a,): pass", that still leaves some more open questions: which of the following should be valid? (1) def f(*args,): pass (2) def f(**kwargs,): pass (3) def f(*,): pass IMO all of them (though as you mention, (3) doesn't matter.) Agreed. It's one less thing to explain: "You can have a trailing comma in an argument list, unless there's a bare star, and in that case you can't have a comma; and also if ...". Ick. Eric. ___ 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] versioned .so files for Python 3.2
On Jul 08, 2010, at 09:14 AM, Georg Brandl wrote: >Am 07.07.2010 23:04, schrieb Georg Brandl: >> I can see where this is going... writing it into PEP 384 would >> automatically get the change accepted? I'm definitely not trying to get it in subversively. :) >I hit "Send" prematurely. I wanted to add that I'd be okay with this >change, be it in a new PEP or an old one. Cool. I'll take Nick up on the suggestion to summarize the thread via a new PEP. -Barry signature.asc Description: 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] A grammatical oddity: trailing commas in argument lists.
On 7/9/2010 4:26 PM, Mark Dickinson wrote: On Fri, Jul 9, 2010 at 8:37 PM, Dino Viehland wrote: Terry wrote: This violates the important principle that allowed def and call arg sequences should match to the extent sensible and possible. In this sense, the SyntaxError is a bug. So I would fix this now for 3.2 and notify the other implementors. +1 on fixing it - trailing commas are awesome. I'm always annoyed in C# where I frequently can't use them. This seems like a bug fix level change that should be easy for the other implementations to fix. Thanks for all the feedback. If the grammar is changed to allow "def f(*, a,): pass", that still leaves some more open questions: which of the following should be valid? (1) def f(*args,): pass (2) def f(**kwargs,): pass (3) def f(*,): pass I would follow the same principle of making def and call match. Currently >>> def f(*args,): pass SyntaxError: invalid syntax >>> def f(*args): pass >>> f(*(1,2,3),) SyntaxError: invalid syntax Giving the call doc "A trailing comma may be present after the positional and keyword arguments but does not affect the semantics.", I was not really expecting the second syntax error. Same behavior for f(**k,). So if you allow the definition, allow the call too. Just for the sake of simplicity it would seem to make sense allow all these, even if there's no obvious immediate use; for me, it keeps the mental footprint of the language small---I don't have to remember when the comma is or isn't allowed. Agreed. -- Terry Jan Reedy ___ 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] versioned .so files for Python 3.2
On Jul 08, 2010, at 01:47 AM, Matthias Klose wrote: >On 07.07.2010 20:40, Barry Warsaw wrote: >> Getting back to this after the US holiday. Thanks for running these >> numbers Scott. I've opened a bug in the Python tracker and attached >> my latest patch: >> >> http://bugs.python.org/issue9193 >> >> The one difference from previous versions of the patch is that >> the .so tag is now settable via "./configure >> --with-so-abi-tag=foo". This would generate shared libs like >> _multiprocessing.foo.so. > > - imo, it's wrong to lookup _multiprocessing.so first, before looking >up _multiprocessing.foo.so (at least for the use case to put the >extensions for multiple python versions into one directory). Good point. > - why is the flexibility of specifying the "foo" needed? The >naming for the __pycache__ files is fixed, why have it configurable >for extensions? The 'foo' part in the shared library name is equivalent to the part in __pycache__/baz..pyc, not specifically the __pycache__ part. Specifying the is necessary because extension modules built for Python 3.2 will not be compatible with extension modules built for Python 3.3 (in the absence of PEP 384), but they will live in the same directory. -Barry signature.asc Description: 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] A grammatical oddity: trailing commas in argument lists.
On Sat, Jul 10, 2010 at 5:31 AM, Terry Reedy wrote: > This violates the important principle that allowed def and call arg > sequences should match to the extent sensible and possible. In this sense, > the SyntaxError is a bug. So I would fix this now for 3.2 and notify the > other implementors. +1 for fixing it from me, unless any of the other implementations object. @Mark: my comment on the tracker issue had an implied "...unless you really want to" on the end :) 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
