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
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
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:
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.
[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
[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
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
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:
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
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
[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:
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
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
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
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
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
[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
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
[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
19 matches
Mail list logo
