"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 u
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 e
[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!
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 practic
[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 sep
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
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
"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
> > 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_StdioReadlin
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 on
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 platform
> > 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
[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://w
> 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
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 Py
> "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 opti
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 b
[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 writte
[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
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.
--
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 cal
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 cl
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 "
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".
> Obviou
24 matches
Mail list logo
