Guido van Rossum wrote:
> I think that ought to go into the guidlines for what's an acceptable
> __dir__ implementation. We don't try to stop people from overriding
> __add__ as subtraction either.
to me, overriding dir() is a lot more like overriding id() than over-
riding "+". I don't think a
Martin v. Löwis wrote:
> Patch #1067760 deals with passing of float values to file.seek;
> the original version tries to fix the current implementation
> by converting floats to long long, rather than plain C long
> (thus supporting files larger than 2GiB).
>
> I propose a different approach: pas
I guess I should remember, but what's the rationale for not including
even a single concrete "tzinfo" implementation in the standard library?
not even a UTC class?
or am I missing something?
___
Python-Dev mailing list
Python-Dev@python.org
http://m
Martin v. Löwis wrote:
>> I guess I should remember, but what's the rationale for not including
>> even a single concrete "tzinfo" implementation in the standard library?
>>
>> not even a UTC class?
>>
>> or am I missing something?
>
> If you are asking for a time-zone database
I was more think
Guido van Rossum wrote:
> IMO it was an oversight. Or we were all exhausted. I keep copying
> those three classes from the docs, which is silly. :-)
I'll whip up a patch. would the "embedded python module" approach I'm
using for _elementtree be okay, or should this go into a support library ?
(reposted from c.l.py)
the following FAQ item talks about using sleep to make sure that threads
run properly:
http://effbot.org/pyfaq/none-of-my-threads-seem-to-run-why.htm
I suspect it was originally written for the "thread" module, since as
far as I know, the "threading" module takes care of
Martin v. Löwis wrote:
> I'd like to share an observation on portability of extension
> modules to Python 2.5: python-ldap would crash on Solaris, see
>
> http://groups.google.com/group/comp.lang.python/msg/a678a969c90f21ab?dmode=source&hl=en
>
> It turns out that this was caused by a mismatch i
Ka-Ping Yee wrote:
> Wow. Did you catch this news?
>
> http://www-tech.mit.edu/V125/N65/coursevi.html
>
> The first four weeks of C1 will be a lot like the first
> four weeks of 6.001, Abelson said. The difference is
> that programming will be done in Python and not Scheme.
"This s
Armin Rigo wrote:
> Yuk! Not renamed to .py files. Distributing .py files that are
> actually bytecode looks like a new funny way to create confusion. No, I
> was half-heartedly musing about introducing Yet Another file extension
> (.pyc for caching and .pyX for importable bytecode, or possibly
tomer filiba wrote:
> no, it requires *infinity* to accomplish x - y == x; y != 0, for example:
>
> while limit > 0:
> limit -= len(chunk)
>
> with limit = posinf, the above code should be equivalent to "while True".
that's a remarkably stupid way to count bytes. if you want to argue for
Talin wrote:
> But it isn't just the docs that are at fault here - otherwise, I'd be
> posting this on a different mailing list. It seems like the whole
> architecture is 'diff'-based, a series of patches on top of patches,
> which are in need of some serious refactoring.
so to summarize, you
Guido van Rossum wrote:
> Are you opposed changing tokenize? If so, why (apart from
> compatibility)? ISTM that it would be a good thing if it reported
> everything except horizontal whitespace.
it would be a good thing if it could, optionally, be made to report
horizontal whitespace as well.
Guido van Rossum wrote:
>> it would be a good thing if it could, optionally, be made to report
>> horizontal whitespace as well.
>
> It's remarkably easy to get this out of the existing API
sure, but it would be even easier if I didn't have to write that code
myself (last time I did that, I nee
Frank Lomax wrote:
> The PSU does not, nor ever has existed. Any statement implying
> otherwise is false and subversive. There is no PSU and even if there
> is, it has no influence whatsoev
it's a bit interesting that every time someone writes something along
those lines, their computer's P
Martin v. Löwis wrote:
>> Like I said, it's possible to split Python without making things
>> complicated for newbies.
>
> You may have that said, but I don't believe its truth. For example,
> most distributions won't include Tkinter in the "standard" Python
> installation: Tkinter depends on _tk
Martin v. Löwis wrote:
> Several issues need to be taken into account:
the most important issue is that if you want an object to behave as a
sequence of something, you need to decide what that something is before
you start tinkering with the syntax.
under Ben's simple proposal, m[:][1] and m[1
Martin v. Löwis wrote:
> Ah, right; I misread his proposal as saying that m[:] should return
> [m[0]] + list(m.groups()) (rather, I expected that m.groups() would
> include m.group(0)).
match groups are numbered 1..N, not 0..(N-1), in both the API and in the
RE syntax (and we don't have much con
Martin v. Löwis wrote:
>> match groups are numbered 1..N, not 0..(N-1), in both the API and in the
>> RE syntax (and we don't have much control over the latter).
>
> py> m = re.match("a(b)","ab")
> py> m.group(0)
> 'ab'
> py> m.group(1)
> 'b'
0 isn't a group, it's an alias for the full match.
Martin v. Löwis wrote:
>> I know what the Zen says about special cases, but in this case the rules
>> were apparently broken with impunity.
>
> Well, the proposal was to interpret m[i] as m.group(i), for all values
> of i. I can't see anything confusing with that.
it can quickly become rather co
Martin v. Löwis wrote:
>> it can quickly become rather confusing if you also interpret m[:] as
>> m.groups(), not to mention if you add len() and arbitrary slicing to
>> the mix. what about m[] and m[i,j,k], btw?
>
> I take it that you are objecting to that feature, then?
I haven't seen a comp
Ka-Ping Yee wrote:
> I'd say, don't pretend m is a sequence. Pretend it's a mapping.
> Then the conceptual issues go away.
almost; that would mean returning KeyError instead of IndexError for
groups that don't exist, which means that the common pattern
a, b, c = m.groups()
cannot be rewr
Ben Wing wrote:
> i'm ok either way -- that is, either with the proposal i previously
> published, or with this restricted idea.
ok, I'll whip up a patch for the minimal version of the proposal, if
nobody beats me to it (all that's needed is a as_sequence struct with a
item slot that basically
Alastair Houghton wrote:
> (The current groups() method *doesn't* match those expectations,
> incidentally. I know I've been tripped up in the past because it
> didn't include the full match as element 0.)
that's because there is no "group 0" in a regular expression; that's
just a historica
Martin v. Löwis wrote:
> In any case, having Python in the LSB means that ISVs (software
> vendors) who target LSB (rather than targetting specific Linux
> distributions) could develop their applications also in Python
> (whereas now they have to use C or C++).
... without having to include a Pyt
Steven Bethard wrote:
> Fredrik Lundh has been working on a `new Python FAQ`_
footnote: working on cleaning up the old FAQ, to be precise. it'll end
up on python.org, as soon as Andrew Kuchling gets around to complete his
FAQ renderer (which may take a while, since he's busy wi
over at my work copy of the python language reference, Adrian Holovaty
asked about the exact semantics of the __str__ hook:
http://effbot.org/pyref/__str__
"The return value must be a string object." Does this mean it can be a
*Unicode* string object? This distinction is ambiguous to me
M.-A. Lemburg wrote:
> This was added to make the transition to all Unicode in 3k easier:
thanks for the clarification.
do you recall when this was added? 2.5?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/list
Michael Urman wrote:
> The idea that slicing a match object should produce a match object
> sounds like a foolish consistency to me.
well, the idea that adding m[x] as a convenience alias for m.group(x)
automatically turns m into a list-style sequence that also has to
support full slicing sound
Talin wrote:
> Maybe instead of considering a match object to be a sequence, a match
> object should be considered a map?
sure, except for one small thing. from earlier in this thread:
> Ka-Ping Yee wrote:
>
>> I'd say, don't pretend m is a sequence. Pretend it's a mapping.
>> Then the co
Talin wrote:
> The original proposal was to make m[n] a synonym for m.group(n).
> "group()" is clearly map-like in its behavior.
so have you checked what exception m.group(n) raises when you try to
access a group that doesn't exist ?
frankly, speaking as the original SRE author, I will now fli
Guido van Rossum wrote:
> That was the month of October.
>
> If people believe these numbers are real, we're doing great!!!
2.5 was of course released in september, so I assume that part of
what you're seeing is simply tinkerers upgrading their existing
installations.
plotting weekly figures f
Kurt B. Kaiser wrote:
> Going mainstream :-))
indeed. from what I can tell on my local market, we've "crossed the chasm"
[1], and
are seeing wider range of "pragmatists" adding Python to the tool chain.
> The Rails buzz seems to be jumping to Python lately.
fwiw, the people I see pick up Pyth
Martin v. Löwis wrote:
>> I've just been putting together a podcasting doodad and have included
>> resuming
>> support in it. Is this something that's already in the pipeline or should I
>> abstract it out to urllib and submit a patch?
>
> Not sure where you got the impression that 206 is "res
Martin v. Löwis wrote:
>> given that urllib2 already supports partial requests, I'm not sure I see
>> the point of reimplementing this on top of httplib. an example:
>>
>>import urllib2
>>
>>request = urllib2.Request("http://www.pythonware.com/daily/index.htm";)
>>request.add_header(
Guido van Rossum wrote:
> Even apart from the website that Samuele found, the content sounded
> genuine. Just not something I feel like dealing with (too many
> surveys).
from what I can tell, it was blasted to everyone with a sourceforge
account, which indicates that they're don't really care w
Talin wrote:
> Rather than fixing on a standard markup, I would like to see support for
> a __markup__ module variable which specifies the specific markup
> language that is used in that module. Doc processors could inspect that
> variable and then load the appropriate markup translator.
Ideally,
Guido van Rossum wrote:
> My suspicion is that building Python for an 64-bit address space is
> still a somewhat academic exercise.
arbitrary 64-bit systems, perhaps. the first Python system I ever built was
deployed
on an LP64 system back in 1995. it's still running, and is still being
maint
Martin v. Löwis wrote:
> I never considered it an extension. Ask 10 people around you to see
> what a leading dot on Unix in a file name means, and I would be
> suprised if more than one answered "it separates the file name from
> the extension". Most of them likely include "hidden file" in their
Guido van Rossum wrote:
>> What about reimplementing commands.* using subprocess? Or providing a
>> commands.*-compatible interface in the subprocess module?
>
> What does that buy us?
multi-platform support? (commands is Unixoid only, right?)
_
Bartlomiej Wolowiec wrote:
> For some time I'm interested in regular expressions and Finite State Machine.
> Recently, I saw that Python uses "Secret Labs' Regular Expression Engine",
> which very often works too slow. Its pesymistic time complexity is O(2^n),
> although other solutions, with time
On Fri, Aug 22, 2008 at 3:25 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>> So while we could say: "we provide access to the Unicode 5.1.0
>> database", we cannot say: "we support Unicode 5.1.0", simply because
>> we have not reviewed the all the necessary changes and implications.
>
> Mark's
On Fri, Aug 22, 2008 at 4:59 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>> (how's the 3.2/4.1 dual support implemented? do we have two distinct
>> datasets, or are the differences encoded in some clever way? would it
>> make sense to split the unicodedata module into three separate
>> modul
when did Python-Dev turn into a members only list, btw?
---
Your mail to 'Python-Dev' with the subject
Re: Unicode 5.1.0
Is being held until the list moderator can review it for approval.
The reason it is being held:
Post by non-member to a members-only list
---
___
Tres Seaver wrote:
- -1. The feature exists to allow adherence to PEP-8, "Limit all lines to
a maximum of 79 characters.", without requiring runtime concatenation
costs. I use it frequently when assembling and testing message strings,
for instance.
removing it is a bad idea for the reasons a
>Isaac Morland wrote:
This would avoid accidentally leaving out commas in list construction,
but tuple construction would still have the same problem.
Tuple construction already has a "no comma, no tuple" problem. That
problem remains, but as soon as you add a comma, you'll get the same
pro
when I'm trying to build extensions under Python 2.6 on Windows XP, the
build process terminates with single line that says:
error: None
which is about as useless as an error message can be. Googling for this
brings up a few hits which all seem to involve setuptools (and none of
the hits
Amaury Forgeot d'Arc wrote:
when I'm trying to build extensions under Python 2.6 on Windows XP, the
build process terminates with single line that says:
error: None
which is about as useless as an error message can be. Googling for this
brings up a few hits which all seem to involve setupt
Thomas Heller wrote:
I'm beginning to suspect that I have a botched VS install on this
machine, though. I'll investigate.
Do you get a traceback when you set the DISTUTILS_DEBUG environment
> variable?
Indeed I do:
...
File "c:\python26\lib\distutils\msvc9compiler.py", line 436, in com
Barry Warsaw wrote:
I agree. This seriously feels like new, potentially high risk code to
be adding this late in the game. The BDFL can always override, but
unless someone is really convincing that this is low risk high benefit,
I'd vote no for 2.6/3.0.
at least two Unicode experts have st
Barry Warsaw wrote:
You don't mean the experts claimed they weren't important, right?
Unimportant changes definitely don't need to go in now .
Well, at least Guido managed to figure out what I was trying to say ;-)
___
Python-Dev mailing list
Pyt
Kilian Klimek wrote:
Saying "your method must accept an extra parameter (which most people
call 'self') that carries all object attributes" is hardly any more
explicit then saying "there is a special variable (which is always named
'this') that carries all object attributes".
in this context
Guido van Rossum wrote:
I can't reproduce this as described.
Which Windows version? This sounds like one of those things that could
well vary by Windows version; if it works for you in Vista it may well
be broken in XP. It could also vary by other setup parameters besides
PATHEXT.
It works t
Curt Hagenlocher wrote:
I've found the documentation for CreateProcess
(http://msdn.microsoft.com/en-us/library/ms682425.aspx) to be pretty
reliable. And the mention of a ".com" in the docs suggests that the
description has been around for a while...
And I just described it as pretty vague ;-
(using 3.0a4)
>>> exec(open("file.py"))
Traceback (most recent call last):
File "", line 1, in
TypeError: exec() arg 1 must be a string, file, or code object, not
TextIOWrapper
so what's "file" referring to here?
(the above works under 2.5, of course)
___
Fredrik Lundh wrote:
(using 3.0a4)
ahem. I could have sworn that I installed a beta, but I guess the
Windows builds weren't fully synchronized when I did that. I still get
the same error after updating to 3.0b2, though.
(the download page still says "This is an alpha rel
Benjamin Peterson wrote:
Does anybody ever complain about not being able to use isinstance on
twisted.application.Application? (At least it's documented as a
function there.)
the threading "non-classes" are documented to be factory functions on
the module page.
___
Antoine Pitrou wrote:
event_class = Event().__class__ ?
Not pretty I know :-)
somewhat prettier, assuming 2.3 or newer:
>>> import threading
>>> e = threading.Event()
>>> type(e)
>>> isinstance(e, type(threading.Event()))
True
(but pretty OT)
Terry Reedy wrote:
In particular, built-in functions, in spite of of being labeled
'builtin_function_or_method', are not usable as methods because they
lack the __get__ method needed to bind function to instance.
They're not usable as Python-level instance methods, but they're
definitely usa
Barry Warsaw wrote:
I'm not going to release rc1 tonight. There are too many open release
blockers that I don't want to defer, and I'd like the buildbots to churn
through the bsddb removal on all platforms.
I'd like to try again on Friday and stick to rc2 on the 17th.
any news on this fro
Barry Warsaw wrote:
(I have a few minor ET fixes, and possibly a Unicode 5.1 patch, but
have had absolutely no time to spend on that. is the window still open?)
There are 8 open release blockers, a few of which have patches that need
review. So I think we are still not ready to release rc1.
Olemis Lang wrote:
Fetching external item into 'docutils'
svn: Can't connect to host 'svn.berlios.de': A connection attempt
failed because the connected party did not properly respond after a
period of time, or established connection failed because connected
host has failed to respond.
> Pleas
C. Titus Brown wrote:
over on the pygr list, we were recently discussing a mildly confusing
edit I made:
assert 'seq1' in self.db, self.db.keys()
This was interpreted by someone as being
assert 'seq1' in (self.db, self.db.keys())
which is very different from the actual meaning,
a
the "Code Migration and Modernization" PEP hasn't been updated for 2.5
and 2.6.
http://www.python.org/dev/peps/pep-0290/
surely there's something new in 2.5 and 2.6 that might be worth mentioning?
___
Python-Dev mailing list
Python-Dev@python.o
Brett Cannon wrote:
You sit in front of a bunch of people answering questions asked by the
audience. You know, a panel. =) It's just a Q&A session so that PyCon
attendees can ask python-dev a bunch of random questions. Demystifies
some things and puts faces to python-dev.
and using moderator.a
http://drj11.wordpress.com/2008/10/02/python-and-bragging-about-c89/
mentions that Objects/frameobject.c contains a C99-style comment, which
means that Python 2.6 won't build on AIX.
shouldn't we use a suitable gcc option for the buildbots to prevent that
from happening?
_
Bjorn Tillenius wrote:
> There are some issues regarding the use of unicode in doctests. Consider
> the following three tests.
>
>>>> foo = u'föö'
>>>> foo
>u'f\xf6\xf6'
>
>>>> foo
>u'f\u00f6\u00f6'
>
>>>> foo
>u'föö'
>
> To me, those are identical.
really? if a functi
Raymond Hettinger wrote:
> Hmph. The xmllib module has been deprecated since Py2.0 but is not
> listed in PEP 4.
>
> Question: Do we have to keep it for another two years because of that
> omission?
>
> It seems somewhat silly to keep an obsolete, supplanted module that
> doesn't full support XM
>> I've been trying to get Tile to work with python.
>> It can make your tkinter apps look like
>> http://tktable.sourceforge.net/tile/screenshots/demo-alt-unix.png
>> See http://tktable.sourceforge.net/tile/
>
> Sorry, this is not a good place to get Python support; python-dev is for
> people acti
> One thing that bugs me: the article says 3 or 4 times that Python is
> slow, each time with a refutation ("but it's so flexible", "but it's
> fast enough") but still, they sure seem to harp on the point.
fwiw, IDG's Computer Sweden, "sweden's leading IT-newspaper" has a
surprisingly big Python
John J Lee wrote:
> the idea spreads that Python-built .exe's are so big because they're just
> an interpreter plus a script.
that's why exemaker is so great, of course: all EXE files are 4 kilobytes.
as for the PYC files, hide them in a ZIP archive named DAT, HLP, OCX,
or even DLL, and you're d
> . Multiple assignment is slower than individual assignment. For
> example "x,y=a,b" is slower than "x=a; y=b". However, multiple
> assignment is faster for variable swaps. For example, "x,y=y,x" is
> faster than "t=x; x=y; y=t".
marginally faster in 2.4, a lot slower in earlier versions. may
Martin v. Löwis wrote:
>> Third party modules would link against this DLL independent of which
>> python is being used.
>
> I believe this is not implementable: How can the DLL know which Python
> DLL to use?
the Python interpreter could initialize this DLL, using some suitable mechanism.
altern
Guido van Rossum wrote:
> > fwiw, IDG's Computer Sweden, "sweden's leading IT-newspaper" has a
> > surprisingly big Python article in their most recent issue:
> >
> > PYTHON FEELS WELL
> > Better performance biggest news in 2.4
> >
(hmm. I seem to have accidentally deleted a line here..
Stephan Deibel wrote:
> BTW, I can't resist my own favorite speed anecdote: I once wrote a
> one-off script to process down a couple of gigabytes of variously
> fragmented web logs into month-by-month files. I thought I was being
> naive doing f.readline() in a for loop with some date parsing co
Raymond Hettinger wrote:
> Perhaps a rather quick Py2.4.1 would be in order.
sounds like a good idea. +1 from here.
___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.
Armin Rigo wrote:
> Some code in the 'py' lib used to use marshal to send simple objects between
> the main process and a subprocess. We ran into trouble when we extended the
> idea to a subprocess that would actually run via ssh on a remote machine, and
> the remote machine's Python version didn
hi andre,
>I have problem with re-install python 2.3.4, when I execute ./configure is
>appear one message in
>config.log, follow below :
> configure:1710: gccconftest.cc >&5
> gcc: installation problem, cannot exec `cc1plus': No such file or directory
> configure:1713: $? = 1
>
> My gnu/lin
back in Python 2.1 (and before), an object could define how copy.copy should
work simply by definining a __copy__ method. here's the relevant portion:
...
try:
copierfunction = _copy_dispatch[type(x)]
except KeyError:
try:
copier = x.__copy__
except
Guido van Rossum wrote:
> The only thing this intends to break /.../
it breaks classic C types:
>>> import cElementTree
>>> x = cElementTree.Element("tag")
>>> x
>>> x.__copy__
>>> x.__copy__()
>>> import copy
>>> y = copy.copy(x)
Traceback (most recent call last):
File "", line 1, in ?
F
Just van Rossum wrote:
> ...and then there are those Python users who have no formal CS
> background at all. Python is used quite a bit by people who's main job
> is not programming.
...and among us who do programming as a main job, I can assure that I'm
not the only one who, if told by a compute
Alex Martelli wrote:
> Problem: to write unit tests showing that the current copy.py misbehaves with
> a classic extension
> type, I need a classic extension type which defines __copy__ and __deepcopy__
> just like /F's
> cElementTree does. So, I made one: a small trycopy.c and accompanying
Stuart Bishop wrote:
> I don't think it is possible for plpythonu to fix this by simply translating
> the line endings, as
> this would require significant knowledge of Python syntax to do correctly
> (triple quoted strings
> and character escaping I think).
of course it's possible: that's wh
Just van Rossum wrote:
> I don't think that in general you want to fold multiple empty lines into
> one. This would be my prefered regex:
>
>s = re.sub(r"\r\n?", "\n", s)
>
> Catches both DOS and old-style Mac line endings. Alternatively, you can
> use s.splitlines():
>
>s = "\n".join(s.sp
Stuart Bishop wrote:
> Do people consider this a bug that should be fixed in Python 2.4.1 and Python
> 2.3.6 (if it ever
> exists), or is the resposibility for doing this transformation on the
> application that embeds
> Python?
the text you quoted is pretty clear on this:
It is envision
Neal Norwitz wrote:
> The patch adds a new method type (flags) METH_ARGS that is used in
> PyMethodDef. METH_ARGS means the min and max # of arguments are
> specified in the PyMethodDef by adding 2 new fields.
> * the defn of the MethodDef (# args) is separate from the function defn
> * potential
Guido van Rossum wrote:
>> As a trivial example, here's how to skip the head of a zero-numbered list:
>>
>>for i, item in enumerate("ABCDEF")[1:]:
>> print i, item
>>
>> Is this idea a non-starter, or should I spend my holiday on Wednesday
>> finishing
>> it off and writing the documenta
Guido van Rossum wrote:
>> I'd like to see iterators become as easy to work with as lists are. At the
>> moment, anything that returns an iterator forces you to use the relatively
>> cumbersome itertools.islice mechanism, rather than Python's native slice
>> syntax.
>
> Sorry. Still -1.
can we pe
Bob Ippolito wrote:
> Wouldn't it be nicer to have a facility that let you send messages between
> processes and manage
> concurrency properly instead? You'll need most of this anyway to do
> multithreading sanely, and
> the benefit to the multiple process model is that you can scale to multi
> Reduce the usage of the types module.
> Index: xmlrpclib.py
> ===
> RCS file: /cvsroot/python/python/dist/src/Lib/xmlrpclib.py,v
# Notes:
# this version is designed to work with Python 2.1 or newer.
> -dispatch[IntType
[EMAIL PROTECTED] wrote:
> @@ -399,9 +393,8 @@
> del self[name] # Won't fail if it doesn't exist
> self.dict[name.lower()] = value
> text = name + ": " + value
> -lines = text.split("\n")
> -for line in lines:
> -self.headers.append(line + "\n")
>> @@ -399,9 +393,8 @@
>> del self[name] # Won't fail if it doesn't exist
>> self.dict[name.lower()] = value
>> text = name + ": " + value
>> -lines = text.split("\n")
>> -for line in lines:
>> -self.headers.append(line + "\n")
>> +self.h
James Y Knight wrote:
> However, last time this topic came up, this Tim Peters guy argued against it.
> ;)
>
> Quoting http://mail.python.org/pipermail/python-dev/2004-November/050049.html:
>
>> Python doesn't promise to return a postive integer for id(), although
>> it may have been nicer if it
does anyone remember if there were any big changes in pymalloc between
the 2.1 series (where it was introduced) and 2.3 (where it was enabled by
default).
or in other words, is the 2.1.3 pymalloc stable enough for production use?
(we're having serious memory fragmentation problems on a 2.1.3 syst
any special reason why "in" is faster if the substring is found, but
a lot slower if it's not in there?
timeit -s "s = 'not there'*100" "s.find('not there') != -1"
100 loops, best of 3: 0.749 usec per loop
timeit -s "s = 'not there'*100" "'not there' in s"
1000 loops, best of 3: 0.122 use
A.M. Kuchling wrote:
>> time. But I would also hope that it would be smart enough to know that it
>> doesn't need to look past the 2nd character in 'not the xyz' when it is
>> searching for 'not there' (due to the lengths of the sequences).
>
> Assuming stringobject.c:string_contains is the right
Mike Brown wrote:
>> any special reason why "in" is faster if the substring is found, but
>> a lot slower if it's not in there?
>
> Just guessing here, but in general I would think that it would stop searching
> as soon as it found it, whereas until then, it keeps looking, which takes more
> time.
Guido van Rossum wrote:
> Which is exactly how s.find() wins this race. (I guess it loses when
> it's found by having to do the "find" lookup.) Maybe string_contains
> should just call string_find_internal()?
I somehow suspected that "in" did some extra work in case the "find"
failed; guess I sho
> memcmp still compiles to REP CMPB on many x86 compilers, and the setup
> overhead for memcmp sucks on modern x86 hardware
make that "compiles to REPE CMPSB" and "the setup overhead for
REPE CMPSB"
___
Python-Dev mailing list
Python-Dev@python.or
Scott David Daniels wrote:
> Looking for "not there" in "not the xyz"*100 using Boyer-Moore should do
> about 300 probes once the table is set (the underscores below):
>
> not the xyznot the xyznot the xyz...
> not ther_
> not the__
>not ther_
>
"Gregory P. Smith" wrote:
> I don't quite like the module name 'hashes' that i chose for the
> generic interface (too close to the builtin hash() function). Other
> suggestions on a module name? 'digest' comes to mind.
hashtools, hashlib, and _hash are common names for helper modules like this.
101 - 200 of 732 matches
Mail list logo
