[Fredrik Lundh]
> Am I the only who are getting mails from "iextream at naver.com"
> whenever I post to python-dev, btw?
>
> My Korean (?) isn't that good, so I'm not sure what they want...
Only thing I've seen from them is one post in the archives, on June 13:
http://mail.python.org/pipermai
Am I the only who are getting mails from "iextream at naver.com"
whenever I post to python-dev, btw?
My Korean (?) isn't that good, so I'm not sure what they want...
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/l
Guido wrote:
> > > They *are* cached and there is no cost to using the functions instead
> > > of the methods unless you have so many regexps in your program that
> > > the cache is cleared (the limit is 100).
> >
> > Sure there is; the cost of looking them up in the cache.
...
> > So in this (hi
Guido van Rossum wrote:
> I also notice that _compile() is needlessly written as a varargs
> function -- all its uses pass it exactly two arguments.
that's because the function uses [1] the argument tuple as the cache key,
and I wanted to make the "cache hit" path as fast as possible.
(but that
On 9/2/05, Gareth McCaughan <[EMAIL PROTECTED]> wrote:
> On Thursday 2005-09-01 18:09, Guido van Rossum wrote:
>
> > They *are* cached and there is no cost to using the functions instead
> > of the methods unless you have so many regexps in your program that
> > the cache is cleared (the limit is
On Thursday 2005-09-01 18:09, Guido van Rossum wrote:
> They *are* cached and there is no cost to using the functions instead
> of the methods unless you have so many regexps in your program that
> the cache is cleared (the limit is 100).
Sure there is; the cost of looking them up in the cache.
On 8/31/05, Stephen J. Turnbull <[EMAIL PROTECTED]> wrote:
> > "Michael" == Michael Chermside <[EMAIL PROTECTED]> writes:
>
> Michael> (2) is what we have today, but I would prefer (1) to
> Michael> gently encourage people to use the precompiled objects
> Michael> (which are distin
> "Greg" == Greg Ewing <[EMAIL PROTECTED]> writes:
Greg> Stephen J. Turnbull wrote:
>> But you could have string objects (or a derivative) grow a
>> "compiled_regexp" attribute internally.
Greg> That would make the core dependent on the re module, which I
Greg> think woul
Stephen J. Turnbull wrote:
> But you could have string objects (or a derivative) grow a
> "compiled_regexp" attribute internally.
That would make the core dependent on the re module,
which I think would be a bad idea.
Personally I like the way the compilation step is
made at least somewhat explic
> "Michael" == Michael Chermside <[EMAIL PROTECTED]> writes:
Michael> (2) is what we have today, but I would prefer (1) to
Michael> gently encourage people to use the precompiled objects
Michael> (which are distinctly faster when re-used).
Didn't Fredrik Lundh strongly imply that
"Fred L. Drake, Jr." <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> I'd rather see it reversed from what it is as well. While I don't have
> the
> time myself (and don't consider it a critical issue), I certainly won't
> revert a patch to make the change without good reason. :-)
On Tuesday 30 August 2005 17:35, Michael Chermside wrote:
> An excellent point. Obviously, EITHER (1) the module functions ought to
> be documented by reference to the RE object methods, or vice versa:
> (2) document the RE object methods by reference to the module functions.
Agreed. I think t
Barry Warsaw writes:
> Although it's mildly annoying that the docs describe the compiled method
> names in terms of the uncompiled functions. I always find myself
> looking up the regexp object's API only to be shuffled off to the
> module's API and then having to do the argument remapping myself.
13 matches
Mail list logo
