Re: [Python-Dev] Remove str.find in 3.0?
Josiah Carlson wrote: > Donovan Baarda <[EMAIL PROTECTED]> wrote: [...] > > One thing that has gotten my underwear in a twist is that no one has > really offered up a transition mechanism from "str.find working like now" > and some future "str.find or lack of" other than "use str.index". > Obviously, I personally find the removal of str.find to be a nonstarter > (don't make me catch exceptions or use regular expressions when both are > unnecessary, please), but a proper transition of str.find from -1 to > None on failure would be beneficial (can which one be chosen at runtime > via __future__ import?). > > During a transition which uses __future__, it would encourage the > /proper/ use of str.find in all modules and extensions in which use it... > > x = y.find(z) > if x >= 0: > #... > It does seem rather fragile to rely on the continuation of the current behavior >>> None >= 0 False for the correctness of "proper usage". Is this guaranteed in future implementations? Especially when: >>> type(None) >= 0 True > Forcing people to use the proper semantic in their modules so as to be > compatible with other modules which may or may not use str.find returns > None, would (I believe) result in an overall reduction (if not > elimination) of bugs stemming from str.find, and would prevent former > str.find users from stumbling down the try/except/else misuse that Tim > Peters highlighted. > Once "str.find() returns None to fail" becomes the norm then surely the correct usage would be x = y.find(z) if x is not None: #... which is still a rather ugly paradigm, but acceptable. So the transition is bound to be troubling. > Heck, if you can get the __future__ import working for choosing which > str.find to use (on a global, not per-module basis), I say toss it into > 2.6, or even 2.5 if there is really a push for this prior to 3.0 . The real problem is surely that one of find()'s legitimate return values evaluates false in a Boolean context. It's especially troubling that the value that does so doesn't indicate search failure. I'd prefer to live with the wart until 3.0 introduces something more satisfactory, or simply removes find() altogether. Otherwise the resulting code breakage when the future arrives just causes unnecessary pain. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 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] Remove str.find in 3.0?
Steve Holden <[EMAIL PROTECTED]> wrote: > > Josiah Carlson wrote: > > Donovan Baarda <[EMAIL PROTECTED]> wrote: > [...] > > > > One thing that has gotten my underwear in a twist is that no one has > > really offered up a transition mechanism from "str.find working like now" > > and some future "str.find or lack of" other than "use str.index". > > Obviously, I personally find the removal of str.find to be a nonstarter > > (don't make me catch exceptions or use regular expressions when both are > > unnecessary, please), but a proper transition of str.find from -1 to > > None on failure would be beneficial (can which one be chosen at runtime > > via __future__ import?). > > > > During a transition which uses __future__, it would encourage the > > /proper/ use of str.find in all modules and extensions in which use it... > > > > x = y.find(z) > > if x >= 0: > > #... > > > It does seem rather fragile to rely on the continuation of the current > behavior > > >>> None >= 0 > False Please see this previous post on None comparisons and why it is unlikely to change: http://mail.python.org/pipermail/python-dev/2003-December/041374.html > for the correctness of "proper usage". Is this guaranteed in future > implementations? Especially when: > > >>> type(None) >= 0 > True That is an interesting, but subjectively useless comparison: >>> type(0) >= 0 True >>> type(int) >= 0 True When do you ever compare the type of an object with the value of another object? > > Forcing people to use the proper semantic in their modules so as to be > > compatible with other modules which may or may not use str.find returns > > None, would (I believe) result in an overall reduction (if not > > elimination) of bugs stemming from str.find, and would prevent former > > str.find users from stumbling down the try/except/else misuse that Tim > > Peters highlighted. > > > Once "str.find() returns None to fail" becomes the norm then surely the > correct usage would be > > x = y.find(z) > if x is not None: > #... > > which is still a rather ugly paradigm, but acceptable. So the transition > is bound to be troubling. Perhaps, which is why I offered "x >= 0". > > Heck, if you can get the __future__ import working for choosing which > > str.find to use (on a global, not per-module basis), I say toss it into > > 2.6, or even 2.5 if there is really a push for this prior to 3.0 . > > The real problem is surely that one of find()'s legitimate return values > evaluates false in a Boolean context. It's especially troubling that the > value that does so doesn't indicate search failure. I'd prefer to live > with the wart until 3.0 introduces something more satisfactory, or > simply removes find() altogether. Otherwise the resulting code breakage > when the future arrives just causes unnecessary pain. Here's a current (horrible but common) solution: x = string.find(substring) + 1 if x: x -= 1 ... ...I'm up way to late. - Josiah ___ 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] info/advices about python readline implementation
Hi, Lisandro Dalcin and me are working on a common version of our patches ([1232343],[955928]) that we plan to submit soon (this would close the two previously proposed patches, and we plan also to review 5 other patches to push this one before 2.5 ;-) ). We would like this new patch to be as clean and as safe as possible, but to do so we would need some infos/advices from the list, and in particular peoples having worked in the readline C implementation, i.e. in modules Modules/readline.c, Parser/myreadline.c (PyOS_StdioReadline, PyOS_StdioReadline, vms__StdioReadline), Python/bltinmodule.c (builtin_raw_input). First a general question about implementation guidelines for CPython: -is it ok to initialize a static pointer to a non-null value (the address of a predefined function) at compile time? ANSI-C (or even pre-ansi C afaik) accept this, we have tested it on various linux and unix, and there are occurrences of similar construct in the python C sources, but not so many and not for function pointers (or I did not found it ;) ). We wonder if this can cause problem on some platforms not correctly implementing C standard(s) but that python have to support nonetheless, or if there is a feeling against it...The idea is to initialize PyOS_ReadlineFunctionPointer this way. Then something about the VMS platform support: -readline seems to make uses of the extern function vms__StdioReadline() on VMS...Where can we find the source or doc about this function? In particular, we would like to know if this function call (or can call) PyOS_StdioReadline, which would cause infinite recursion in some version of our patchwithout havind access to VMS for testing or info about vms__StdioReadline, this is impossible to know... Thanks for any info, Greg. ___ 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] Remove str.find in 3.0?
On 2005-08-26, Terry Reedy <[EMAIL PROTECTED]> wrote: > Can str.find be listed in PEP 3000 (under builtins) for removal? > Would anyone really object? > With all the discussion, I think you guys should realize that the find/index method are actually convenient function which do 2 things in one call: 1) If the key exists? 2) If the key exists, find it out. But whether you use find or index, at the end, you *have to* break it into 2 step at then end in order to make bug free code. Without find, you can do: if s in txt: i = txt.index(s) ... else: pass or: try: i = txt.index(s) ... except ValueError: pass With find: i = txt.index(s) if i >= 0: ... else: pass The code is about the same except with exception, the test of Exception is pushed far apart instead of immediately. No much coding was saved. ___ 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] test_bz2 and Python 2.4.1
Okay. Even though I know that most people here would probably find it difficult to give input when MinGW is used to build Python, I am going to post what I found out so far anyway concerning the test_bz2 situation for referencing purposes. Python version Mode usedLocation of testResult from CVS Python 2.5a0normal ../Lib/test/PASS Python 2.5a0normal CWD of Python PASS Python 2.5a0 interactive../Lib/test/PASS Python 2.5a0 interactiveCWD of Python PASS Python 2.4.1normal ../Lib/test/FAIL Python 2.4.1normal CWD of Python PASS Python 2.4.1 interactive../Lib/test/PASS Python 2.4.1 interactiveCWD of Python PASS For python 2.4.1, tried both bzip2-1.0.2, and bzip2-1.0.3 on Win98 SE, and WinXP Pro SP2, using MinGW 3.4.4. I'll try to see what else I can find out. _ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ ___ 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] Remove str.find in 3.0?
[Guido]
> Another observation: despite the derogatory remarks about regular
> expressions, they have one thing going for them: they provide a higher
> level of abstraction for string parsing, which this is all about.
> (They are higher level in that you don't have to be counting
> characters, which is about the lowest-level activity in programming --
> only counting bytes is lower!)
>
> Maybe if we had a *good* way of specifying string parsing we wouldn't
> be needing to call find() or index() so much at all! (A good example
> is the code that Raymond lifted from ConfigParser: a semicolon
> preceded by whitespace starts a comment, other semicolons don't.
> Surely there ought to be a better way to write that.)
A higher level abstraction is surely the way to go.
I looked over the use cases for find and index. As from cases which are
now covered by the "in" operator, it looks like you almost always want
the index to support a subsequent partition of the string.
That suggests that we need a variant of split() that has been customized
for typical find/index use cases. Perhaps introduce a new pair of
methods, partition() and rpartition() which work like this:
>>> s = 'http://www.python.org'
>>> s.partition('://')
('http', '://', 'www.python.org')
>>> s.rpartition('.')
('http://www.python', '.', 'org')
>>> s.partition('?')
(''http://www.python.org', '', '')
The idea is still preliminary and I have only applied it to a handful of
the library's find() and index() examples. Here are some of the design
considerations:
* The function always succeeds unless the separator argument is not a
string type or is an empty string. So, a typical call doesn't have to
be wrapped in a try-suite for normal usage.
* The split invariant is: s == ''.join(s.partition(t))
* The result of the partition is always a three element tuple. This
allows the results to be unpacked directly:
head, sep, tail = s.partition(t)
* The use cases for find() indicates a need to both test for the
presence of the split element and to then to make a slice at that point.
If we used a contains test for the first step, we could end-up having to
search the string twice (once for detection and once for splitting).
However, by providing the middle element of the result tuple, we can
determine found or not-found without an additional search. Accordingly,
the middle element has a nice Boolean interpretation with '' for
not-found and a non-empty string meaning found. Given
(a,b,c)=s.partition(p), the following invariant holds:
b == '' or b is p
* Returning the left, center, and right portions of the split supports a
simple programming pattern for repeated partitions:
while s:
head, part, s = s.partition(t)
. . .
Of course, if this idea survives the day, then I'll meet my own
requirements and write a context diff on the standard library. That
ought to give a good indication of how well the new methods meet
existing needs and whether the resulting code is better, cleaner,
clearer, faster, etc.
Raymond
___
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] Python 3.0 blocks?
[Guido van Rossum] > [Aahz] > > IIRC, one of your proposals for Python 3.0 was that single-line > > blocks would be banned. Is my memory wrong? > It's a proposal. I'm on the fence about it. A difficult decision indeed. Most single line blocks I've seen would be more legible if they were written with two lines each, so I'm carefully avoiding them as a personal rule. But each rule has exceptions. There are a few rare cases, usually sequences of repetitive code, where single line blocks well succeed in stressing both the repetitive structure and the differences, making the code more legible then. As someone well put it already, this is all about Python helping good coders at writing good code, against Python preventing bad coders from writing bad code. Sadly enough, looking around, it seems Python could be a bit more aggressive against bad practices in this particular case, even if this might hurt good coders once in a while. But I'm not sure! -- François Pinard http://pinard.progiciels-bpi.ca ___ 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] Remove str.find in 3.0?
Raymond Hettinger wrote: > [Guido] > >>Another observation: despite the derogatory remarks about regular >>expressions, they have one thing going for them: they provide a higher >>level of abstraction for string parsing, which this is all about. >>(They are higher level in that you don't have to be counting >>characters, which is about the lowest-level activity in programming -- >>only counting bytes is lower!) >> >>Maybe if we had a *good* way of specifying string parsing we wouldn't >>be needing to call find() or index() so much at all! (A good example >>is the code that Raymond lifted from ConfigParser: a semicolon >>preceded by whitespace starts a comment, other semicolons don't. >>Surely there ought to be a better way to write that.) > > A higher level abstraction is surely the way to go. I may be missing something, but why invent yet another parsing method - we already have the re module. I'd suggest to use it :-) If re is not fast enough or you want more control over the parsing process, you could also have a look at mxTextTools: http://www.egenix.com/files/python/mxTextTools.html -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Aug 28 2005) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ 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] [Python-checkins] python/dist/src setup.py, 1.219, 1.220
> "Martin" == Martin v Löwis <[EMAIL PROTECTED]> writes: Martin> Raymond Hettinger wrote: >> Do you have an ANSI-strict option with your compiler? Martin> gcc does have an option to force c89 compliance, but there Martin> is a good chance that Python stops compiling with option: Martin> on many systems, essential system headers fail to comply Martin> with C89 (in addition, activating that mode also makes Martin> many extensions unavailable). However, it might be a reasonable pre-checkin test to try compiling changed files with the option enabled, depending on the number of nonconforming system headers, etc., and grep the output for whinging about c89-nonconformance. -- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of TsukubaTennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software. ___ 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] Any detail list of change between version2.1-2.2-2.3-2.4 of Python?
On Sun, Aug 28, 2005, Terry Reedy wrote: > "FAN" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] >> >> You know Jython (Java version of Python) has only a stable version >> of 2.1, and two alpha version was release after 3 years. So if it >> wants to evolve to 2.2 , 2.3 or 2.4 as Python, some detail change >> list was need, and it's great if there are some test case script to >> test the new implemention version. So does Python has this kinds of >> things? Where can I find them or something like this? All changes are supposed to be in Misc/NEWS. You should also be able to use most of the test cases in Python itself, which are in Lib/test/ However, you should also read http://www.catb.org/~esr/faqs/smart-questions.html Had you read the various docs about Python development, you would certainly have figured out Lib/test/ on your own. > I believe this question is off-topic here, which is for dicussion of > future changes. If you ask the same question on comp.lang.python or > the mail or gmane.org equivalent, or perhaps in the search box at > python.org, I am sure you will get an answer. Because this is about the future of Jython, it's entirely appropriate for discussion here -- python-dev is *NOT* just for CPython. (It's similar to questions about porting.) As long as people ask questions of the appropriate level, that is. -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ The way to build large Python applications is to componentize and loosely-couple the hell out of everything. ___ 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] empty string api for files
> I'm not convinced. Where would you ever care about reading a file in > N-bytes chucks? This was once a standard paradigm for IBM mainframe files. I vaguely remember having to specify the block/record size when opening such files. I have no idea of today's practice though. Terry J. 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] Remove str.find in 3.0?
[Marc-Andre Lemburg]
> I may be missing something, but why invent yet another parsing
> method - we already have the re module. I'd suggest to
> use it :-)
>
> If re is not fast enough or you want more control over the
> parsing process, you could also have a look at mxTextTools:
>
> http://www.egenix.com/files/python/mxTextTools.html
Both are excellent tools. Neither is as lightweight, as trivial to
learn, or as transparently obvious as the proposed s.partition(sep).
The idea is to find a viable replacement for s.find().
Looking at sample code transformations shows that the high-power
mxTextTools and re approaches do not simplify code that currently uses
s.find(). In contrast, the proposed partition() method is a joy to use
and has no surprises. The following code transformation shows
unbeatable simplicity and clarity.
--- From CGIHTTPServer.py ---
def run_cgi(self):
"""Execute a CGI script."""
dir, rest = self.cgi_info
i = rest.rfind('?')
if i >= 0:
rest, query = rest[:i], rest[i+1:]
else:
query = ''
i = rest.find('/')
if i >= 0:
script, rest = rest[:i], rest[i:]
else:
script, rest = rest, ''
. . .
def run_cgi(self):
"""Execute a CGI script."""
dir, rest = self.cgi_info
rest, _, query = rest.rpartition('?')
script, _, rest = rest.partition('/')
. . .
The new proposal does not help every use case though. In
ConfigParser.py, the problem description reads, "a semi-colon is a
comment delimiter only if it follows a spacing character". This cries
out for a regular expression. In StringIO.py, since the task at hand IS
calculating an index, an indexless higher level construct doesn't help.
However, many of the other s.find() use cases in the library simplify as
readily and directly as the above cgi server example.
Raymond
---
P.S. FWIW, if you want to experiment with it, here a concrete
implementation of partition() expressed as a function:
def partition(s, t):
""" Returns a three element tuple, (head, sep, tail) where:
head + sep + tail == s
t not in head
sep == '' or sep is t
bool(sep) == (t in s) # sep indicates if the string was
found
>>> s = 'http://www.python.org'
>>> partition(s, '://')
('http', '://', 'www.python.org')
>>> partition(s, '?')
('http://www.python.org', '', '')
>>> partition(s, 'http://')
('', 'http://', 'www.python.org')
>>> partition(s, 'org')
('http://www.python.', 'org', '')
"""
if not isinstance(t, basestring) or not t:
raise ValueError('partititon argument must be a non-empty
string')
parts = s.split(t, 1)
if len(parts) == 1:
result = (s, '', '')
else:
result = (parts[0], t, parts[1])
assert len(result) == 3
assert ''.join(result) == s
assert result[1] == '' or result[1] is t
assert t not in result[0]
return result
import doctest
print doctest.testmod()
___
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] empty string api for files
> > I'm not convinced. Where would you ever care about reading a file in > > N-bytes chucks? > > This was once a standard paradigm for IBM mainframe files. I vaguely > remember having to specify the block/record size when opening such files. > I have no idea of today's practice though. I believe this still comes up in 100% of the cases where you're buffering reads of large binary files. Given lot of RAM, this probably doesn't come up as much nowadays. Raymond ___ 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] info/advices about python readline implementation
On 8/28/05, Gregory Lielens <[EMAIL PROTECTED]> wrote: >-is it ok to initialize a static pointer to a non-null value (the > address of a predefined function) at compile time? Yes. All of Python's standard types and modules use this idiom. > We wonder if this can cause problem on some platforms not correctly > implementing C standard(s) but that python have to support nonetheless, If a platform doesn't have a working C89 compiler, we generally wait for the compiler to be fixed (or for GCC to be ported). We might compromise when a platform doesn't support full POSIX, but this seems purely a language issue and there can be no excuses -- C89 is older than Python! > Then something about the VMS platform support: > -readline seems to make uses of the extern function > vms__StdioReadline() on VMS...Where can we find the source or doc about > this function? In particular, we would like to know if this function > call (or can call) PyOS_StdioReadline, which would cause infinite > recursion in some version of our patchwithout havind access to VMS > for testing or info about vms__StdioReadline, this is impossible to > know... I have no idea; Googling for it only showed up discussions of readline.c. You might write the authors of the patch that introduced it (the same Google query will find the info); if they don't respond, I'm not sure that it's worth worrying about. My personal guess is that it's probably a VMS internal function, which would reduce the probability of it calling back to PyOS_StdioReadline to zero. It can't be a Python specific thing, because it doesn't have a 'Py' prefix. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] PyPy release 0.7.0
Hi Python-dev'ers, The first Python implementation of Python is now also the second C implementation of Python :-) Samuele & Armin (& the rest of the team) -+-+- pypy-0.7.0: first PyPy-generated Python Implementations == What was once just an idea between a few people discussing on some nested mailing list thread and in a pub became reality ... the PyPy development team is happy to announce its first public release of a fully translatable self contained Python implementation. The 0.7 release showcases the results of our efforts in the last few months since the 0.6 preview release which have been partially funded by the European Union: - whole program type inference on our Python Interpreter implementation with full translation to two different machine-level targets: C and LLVM - a translation choice of using a refcounting or Boehm garbage collectors - the ability to translate with or without thread support - very complete language-level compliancy with CPython 2.4.1 What is PyPy (about)? PyPy is a MIT-licensed research-oriented reimplementation of Python written in Python itself, flexible and easy to experiment with. It translates itself to lower level languages. Our goals are to target a large variety of platforms, small and large, by providing a compilation toolsuite that can produce custom Python versions. Platform, Memory and Threading models are to become aspects of the translation process - as opposed to encoding low level details into a language implementation itself. Eventually, dynamic optimization techniques - implemented as another translation aspect - should become robust against language changes. Note that PyPy is mainly a research and development project and does not by itself focus on getting a production-ready Python implementation although we do hope and expect it to become a viable contender in that area sometime next year. Where to start? - Getting started:http://codespeak.net/pypy/dist/pypy/doc/getting-started.html PyPy Documentation: http://codespeak.net/pypy/dist/pypy/doc/ PyPy Homepage: http://codespeak.net/pypy/ The interpreter and object model implementations shipped with the 0.7 version can run on their own and implement the core language features of Python as of CPython 2.4. However, we still do not recommend using PyPy for anything else than for education, playing or research purposes. Ongoing work and near term goals - PyPy has been developed during approximately 15 coding sprints across Europe and the US. It continues to be a very dynamically and incrementally evolving project with many one-week meetings to follow. You are invited to consider coming to the next such meeting in Paris mid October 2005 where we intend to plan and head for an even more intense phase of the project involving building a JIT-Compiler and enabling unique features not found in other Python language implementations. PyPy has been a community effort from the start and it would not have got that far without the coding and feedback support from numerous people. Please feel free to give feedback and raise questions. contact points: http://codespeak.net/pypy/dist/pypy/doc/contact.html contributor list: http://codespeak.net/pypy/dist/pypy/doc/contributor.html have fun, the pypy team, of which here is a partial snapshot of mainly involved persons: Armin Rigo, Samuele Pedroni, Holger Krekel, Christian Tismer, Carl Friedrich Bolz, Michael Hudson, Eric van Riet Paap, Richard Emslie, Anders Chrigstroem, Anders Lehmann, Ludovic Aubry, Adrien Di Mascio, Niklaus Haldimann, Jacob Hallen, Bea During, Laura Creighton, and many contributors ... PyPy development and activities happen as an open source project and with the support of a consortium partially funded by a two year European Union IST research grant. Here is a list of the full partners of that consortium: Heinrich-Heine University (Germany), AB Strakt (Sweden) merlinux GmbH (Germany), tismerysoft GmbH(Germany) Logilab Paris (France), DFKI GmbH (Germany) ChangeMaker (Sweden), Impara (Germany) ___ 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] info/advices about python readline implementation
> > Then something about the VMS platform support: > > -readline seems to make uses of the extern function > > vms__StdioReadline() on VMS...Where can we find the source or doc about > > this function? In particular, we would like to know if this function > > call (or can call) PyOS_StdioReadline, which would cause infinite > > recursion in some version of our patchwithout havind access to VMS > > for testing or info about vms__StdioReadline, this is impossible to > > know... > > I have no idea; Googling for it only showed up discussions of > readline.c. You might write the authors of the patch that introduced > it (the same Google query will find the info); if they don't respond, > I'm not sure that it's worth worrying about. Googling only returned comments or queries by either Lisandro or me, but it was loewis (Martin v. Löwis ?) that comited this change in May 2003 with the comment Patch #708495: Port more stuff to OpenVMS. Tha patch was introduced by Jean-François Piéronne, who explained: myreadline.c Use of vms__StdioReadline > My personal guess is that it's probably a VMS internal function, which > would reduce the probability of it calling back to PyOS_StdioReadline > to zero. It can't be a Python specific thing, because it doesn't have > a 'Py' prefix. My guess too, especially as using PyOS_StdioReadline (which is not in the python API) would be asking for trouble...We will thus consider that there is no risk of infinite recursion, except if someone say otherwise... Thanks a lot for these fast and usefull informations! Greg. ___ 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] Remove str.find in 3.0?
"Raymond Hettinger" <[EMAIL PROTECTED]> wrote: > [Guido] > > Another observation: despite the derogatory remarks about regular > > expressions, they have one thing going for them: they provide a higher > > level of abstraction for string parsing, which this is all about. > > (They are higher level in that you don't have to be counting > > characters, which is about the lowest-level activity in programming -- > > only counting bytes is lower!) > > > > Maybe if we had a *good* way of specifying string parsing we wouldn't > > be needing to call find() or index() so much at all! (A good example > > is the code that Raymond lifted from ConfigParser: a semicolon > > preceded by whitespace starts a comment, other semicolons don't. > > Surely there ought to be a better way to write that.) > > A higher level abstraction is surely the way to go. Perhaps... > Of course, if this idea survives the day, then I'll meet my own > requirements and write a context diff on the standard library. That > ought to give a good indication of how well the new methods meet > existing needs and whether the resulting code is better, cleaner, > clearer, faster, etc. My first thought when reading the proposal was "that's just str.split/str.rsplit with maxsplit=1, returning the thing you split on, with 3 items always returned, what's the big deal?" Two second later it hit me, that is the big deal. Right now it is a bit of a pain to get string.split to return consistant numbers of return values; I myself have used: l,r = (x.split(y, 1)+[''])[:2] ...around 10 times - 10 times more than I really should have. Taking a wander through my code, this improves the look and flow in almost every case (the exceptions being where I should have rewritten to use 'substr in str' after I started using Python 2.3). Taking a walk through examples of str.rfind at koders.com leads me to believe that .partition/.rpartition would generally improve the flow, correctness, and beauty of code which had previously been using .find/.rfind. I hope the idea survives the day. - Josiah ___ 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] Remove str.find in 3.0?
Raymond Hettinger wrote:
> [Marc-Andre Lemburg]
>
>>I may be missing something, but why invent yet another parsing
>>method - we already have the re module. I'd suggest to
>>use it :-)
>>
>>If re is not fast enough or you want more control over the
>>parsing process, you could also have a look at mxTextTools:
>>
>>http://www.egenix.com/files/python/mxTextTools.html
>
>
> Both are excellent tools. Neither is as lightweight, as trivial to
> learn, or as transparently obvious as the proposed s.partition(sep).
> The idea is to find a viable replacement for s.find().
Your partition idea could be had with an additional argument
to .split() (e.g. keepsep=1); no need to learn a new method.
Also, as I understand Terry's request, .find() should be removed
in favor of just leaving .index() (which is the identical method
without the funny -1 return code logic).
So your proposal really doesn't have all that much to do
with Terry's request, but is a new and separate proposal
(which does have some value in few cases, but not enough
to warrant a new method).
> Looking at sample code transformations shows that the high-power
> mxTextTools and re approaches do not simplify code that currently uses
> s.find(). In contrast, the proposed partition() method is a joy to use
> and has no surprises. The following code transformation shows
> unbeatable simplicity and clarity.
>
>
> --- From CGIHTTPServer.py ---
>
> def run_cgi(self):
> """Execute a CGI script."""
> dir, rest = self.cgi_info
> i = rest.rfind('?')
> if i >= 0:
> rest, query = rest[:i], rest[i+1:]
> else:
> query = ''
> i = rest.find('/')
> if i >= 0:
> script, rest = rest[:i], rest[i:]
> else:
> script, rest = rest, ''
> . . .
>
>
> def run_cgi(self):
> """Execute a CGI script."""
> dir, rest = self.cgi_info
> rest, _, query = rest.rpartition('?')
> script, _, rest = rest.partition('/')
Wouldn't this do the same ?! ...
rest, query = rest.rsplit('?', maxsplit=1)
script, rest = rest.split('/', maxsplit=1)
> . . .
>
>
> The new proposal does not help every use case though. In
> ConfigParser.py, the problem description reads, "a semi-colon is a
> comment delimiter only if it follows a spacing character". This cries
> out for a regular expression. In StringIO.py, since the task at hand IS
> calculating an index, an indexless higher level construct doesn't help.
> However, many of the other s.find() use cases in the library simplify as
> readily and directly as the above cgi server example.
>
>
>
> Raymond
>
>
> ---
>
> P.S. FWIW, if you want to experiment with it, here a concrete
> implementation of partition() expressed as a function:
>
> def partition(s, t):
> """ Returns a three element tuple, (head, sep, tail) where:
>
> head + sep + tail == s
> t not in head
> sep == '' or sep is t
> bool(sep) == (t in s) # sep indicates if the string was
> found
>
> >>> s = 'http://www.python.org'
> >>> partition(s, '://')
> ('http', '://', 'www.python.org')
> >>> partition(s, '?')
> ('http://www.python.org', '', '')
> >>> partition(s, 'http://')
> ('', 'http://', 'www.python.org')
> >>> partition(s, 'org')
> ('http://www.python.', 'org', '')
>
> """
> if not isinstance(t, basestring) or not t:
> raise ValueError('partititon argument must be a non-empty
> string')
> parts = s.split(t, 1)
> if len(parts) == 1:
> result = (s, '', '')
> else:
> result = (parts[0], t, parts[1])
> assert len(result) == 3
> assert ''.join(result) == s
> assert result[1] == '' or result[1] is t
> assert t not in result[0]
> return result
>
>
> import doctest
> print doctest.testmod()
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Source (#1, Aug 28 2005)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free !
___
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] Remove str.find in 3.0?
Raymond Hettinger wrote:
> Looking at sample code transformations shows that the high-power
> mxTextTools and re approaches do not simplify code that currently uses
> s.find(). In contrast, the proposed partition() method is a joy to use
> and has no surprises. The following code transformation shows
> unbeatable simplicity and clarity.
+1
This doesn't cause any backward compatible issues as well!
> --- From CGIHTTPServer.py ---
>
> def run_cgi(self):
> """Execute a CGI script."""
> dir, rest = self.cgi_info
> i = rest.rfind('?')
> if i >= 0:
> rest, query = rest[:i], rest[i+1:]
> else:
> query = ''
> i = rest.find('/')
> if i >= 0:
> script, rest = rest[:i], rest[i:]
> else:
> script, rest = rest, ''
> . . .
>
>
> def run_cgi(self):
> """Execute a CGI script."""
> dir, rest = self.cgi_info
> rest, _, query = rest.rpartition('?')
> script, _, rest = rest.partition('/')
> . . .
+1
Much easier to read and understand!
Cheers,
Ron
___
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] Remove str.find in 3.0?
[M.-A. Lemburg]
> Also, as I understand Terry's request, .find() should be removed
> in favor of just leaving .index() (which is the identical method
> without the funny -1 return code logic).
>
> So your proposal really doesn't have all that much to do
> with Terry's request, but is a new and separate proposal
> (which does have some value in few cases, but not enough
> to warrant a new method).
It is new and separate, but it is also related. The core of Terry's
request is the assertion that str.find() is bug-prone and should not be
used. The principal arguments against accepting his request (advanced
by Tim) are that the str.index() alternative is slightly more awkward to
code, more likely to result in try-suites that catch more than intended,
and that the resulting code is slower. Those arguments fall to the
wayside if str.partition() becomes available as a superior alternative.
IOW, it makes Terry's request much more palatable.
> > def run_cgi(self):
> > """Execute a CGI script."""
> > dir, rest = self.cgi_info
> > rest, _, query = rest.rpartition('?')
> > script, _, rest = rest.partition('/')
[MAL]
> Wouldn't this do the same ?! ...
>
> rest, query = rest.rsplit('?', maxsplit=1)
> script, rest = rest.split('/', maxsplit=1)
No. The split() versions are buggy. They fail catastrophically when
the original string does not contain '?' or does not contain '/':
>>> rest = 'http://www.example.org/subdir'
>>> rest, query = rest.rsplit('?', 1)
Traceback (most recent call last):
File "", line 1, in -toplevel-
rest, query = rest.rsplit('?', 1)
ValueError: need more than 1 value to unpack
The whole point of str.partition() is to repackage str.split() in a way
that is conducive to fulfilling many of the existing use cases for
str.find() and str.index().
In going through the library examples, I've not found a single case
where a direct use of str.split() would improve code that currently uses
str.find().
Raymond
___
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] empty string api for files
Terry Reedy wrote: >>I'm not convinced. Where would you ever care about reading a file in >>N-bytes chucks? > > > This was once a standard paradigm for IBM mainframe files. I vaguely > remember having to specify the block/record size when opening such files. > I have no idea of today's practice though. > Indeed. Something like: SYSIN DD *,BLKSIZE=80 IIRC (which I may well not do after thirty years or so). People used to solve generic programming problems in JCL just for the hell of it. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 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] empty string api for files
[Steve Holden] > Terry Reedy wrote: > > This was once a standard paradigm for IBM mainframe files. I > > vaguely remember having to specify the block/record size when > > opening such files. I have no idea of today's practice though. > Indeed. Something like: > SYSIN DD *,BLKSIZE=80 Oh! The "*" is pretty magical, and came from HASP (Houston Automatic Spooling Program, if I remember well), and not from IBM. It took a lot of years before IBM even acknowledged the existence of HASP (in dark times when salesmen and engineers ought to strictly obey company mandated attitudes). Nevertheless, almost every IBM customer was installing HASP under the scene, because without the "*", people ought to specify on their DD cards the preallocation of disk space, even for spool files, as a number of cylinders and sectors for the primary extent, and a number of cylinders and sectors for all secondary extents. I later learned that IBM gave in, including HASP facilities as standard. > People used to solve generic programming problems in JCL just for the > hell of it. The hell is the right word to describe it! :-) I wonder if JCL could emulate a Turing Machine, but it at least addressed the Halting Problem! One-who-happily-forgot-all-bout-this-ly yours... P.S. - How is this related to Python? Luckily! -- that is: *not*! :-) -- François Pinard http://pinard.progiciels-bpi.ca ___ 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] Proof of the pudding: str.partition()
As promised, here is a full set of real-world comparative code
transformations using str.partition(). The patch isn't intended to be
applied; rather, it is here to test/demonstrate whether the new
construct offers benefits under a variety of use cases.
Overall, I found that partition() usefully encapsulated commonly
occurring low-level programming patterns. In most cases, it completely
eliminated the need for slicing and indices. In several cases, code was
simplified dramatically; in some, the simplification was minor; and in a
few cases, the complexity was about the same. No cases were made worse.
Most patterns using str.find() directly translated into an equivalent
using partition. The only awkwardness that arose was in cases where the
original code had a test like, "if s.find(pat) > 0". That case
translated to a double-term test, "if found and head". Also, some
pieces of code needed a tail that included the separator. That need was
met by inserting a line like "tail = sep + tail". And that solution led
to a minor naming discomfort for the middle term of the result tuple, it
was being used as both a Boolean found flag and as a string containing
the separator (hence conflicting the choice of names between "found" and
"sep").
In most cases, there was some increase in efficiency resulting fewer
total steps and tests, and from eliminating double searches. However,
in a few cases, the new code was less efficient because the fragment
only needed either the head or tail but not both as provided by
partition().
In every case, the code was clearer after the transformation. Also,
none of the transformations required str.partition() to be used in a
tricky way. In contrast, I found many contortions using str.find()
where I had to diagram every possible path to understand what the code
was trying to do or to assure myself that it worked.
The new methods excelled at reducing cyclomatic complexity by
eliminating conditional paths. The methods were especially helpful in
the context of multiple finds (i.e. split at the leftmost colon if
present within a group following the rightmost forward slash if
present). In several cases, the replaced code exactly matched the pure
python version of str.partition() -- this confirms that people are
routinely writing multi-step low-level in-line code that duplicates was
str.partition() does in a single step.
The more complex transformations were handled by first figuring out
exactly was the original code did under all possible cases and then
writing the partition() version to match that spec. The lesson was that
it is much easier to program from scratch using partition() than it is
to code using find(). The new method more naturally expresses a series
of parsing steps interleaved with other code.
With further ado, here are the comparative code fragments:
Index: CGIHTTPServer.py
===
*** 106,121
def run_cgi(self):
"""Execute a CGI script."""
dir, rest = self.cgi_info
! i = rest.rfind('?')
! if i >= 0:
! rest, query = rest[:i], rest[i+1:]
! else:
! query = ''
! i = rest.find('/')
! if i >= 0:
! script, rest = rest[:i], rest[i:]
! else:
! script, rest = rest, ''
scriptname = dir + '/' + script
scriptfile = self.translate_path(scriptname)
if not os.path.exists(scriptfile):
--- 106,113
def run_cgi(self):
"""Execute a CGI script."""
dir, rest = self.cgi_info
! rest, _, query = rest.rpartition('?')
! script, _, rest = rest.partition('/')
scriptname = dir + '/' + script
scriptfile = self.translate_path(scriptname)
if not os.path.exists(scriptfile):
Index: ConfigParser.py
===
*** 599,612
if depth > MAX_INTERPOLATION_DEPTH:
raise InterpolationDepthError(option, section, rest)
while rest:
! p = rest.find("%")
! if p < 0:
! accum.append(rest)
return
! if p > 0:
! accum.append(rest[:p])
! rest = rest[p:]
! # p is no longer used
c = rest[1:2]
if c == "%":
accum.append("%")
--- 599,611
if depth > MAX_INTERPOLATION_DEPTH:
raise InterpolationDepthError(option, section, rest)
while rest:
! head, sep, rest = rest.partition("%")
! if not sep:
! accum.append(head)
return
! rest = sep + rest
! if found and head:
! accum.append(head)
c = rest[1:2]
if c == "%":
accum.append("%")
Index: cgi.py
=
Re: [Python-Dev] Proof of the pudding: str.partition()
"Raymond Hettinger" <[EMAIL PROTECTED]> wrote: > As promised, here is a full set of real-world comparative code > transformations using str.partition(). The patch isn't intended to be > applied; rather, it is here to test/demonstrate whether the new > construct offers benefits under a variety of use cases. Having looked at many of Raymond's transformations earlier today (just emailing him a copy of my thoughts and changes minutes ago), I agree that this simplifies essentially every example I have seen translated, and translated myself. There are a handful of errors I found during my pass, most of which seem corrected in the version he has sent to python-dev (though not all). To those who are to reply in this thread, rather than nitpicking about the correctness of individual transformations (though perhaps you should email him directly about those), comment about how much better/worse they look. Vote to add str.partition to 2.5: +1 Vote to dump str.find sometime later if str.partition makes it: +1 - Josiah ___ 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
