Michiel Jan Laurens de Hoon wrote:
This is exactly the problem. Drawing one picture may consist of many
Python commands to draw the individual elements (for example, several
graphs overlaying each other). We don't know where in the window each
element will end up until we have the list of
Noam Raphael wrote:
That's a theoretical argument. In practice, if you do it in the
parser, you have two options:
1. Automatically dedent all strings.
2. Add a 'd' or some other letter before the string.
Option 1 breaks backwards compatibility, and makes the parser do
unexpected things.
Noam Raphael wrote:
It didn't. Strange freezes started to appear, only when working from
IDLE. This made me investigate a bit, and I've found that Tkinter
isn't run from a seperate thread - the dooneevent() function is called
repeatedly by PyOS_InputHook while the interpreter is idle.
[EMAIL PROTECTED] wrote:
I read the developer's FAQ and the output of svn up --help. Executing
svn up or svn info tells me I'm already at rev 41430, which is the
latest rev, right? Creating a fresh build subdirectory followed by
configure and make gives me this error:
Jim Jewett wrote:
(6) Mark Hammond suggests that it might be easier to
replace the interactive portions of python based on the
code module. matplotlib suggests using ipython
instead of standard python for similar reasons.
If that is really the simplest answer (and telling users
which IDE
Jim Jewett wrote:
really? Python comes with a module that makes it trivial to get
a fully working interpreter console ...
Using an event loop (or an external GUI) should not require
forking the entire interactive mode, no matter how trivial that
fork is.
repeating a bogus argument
Brett Cannon wrote:
I just finished fleshing out the dev FAQ
(http://www.python.org/dev/devfaq.html) with questions covering what
someone might need to know for regular usage. If anyone thinks I
didn't cover something I should have, let me know.
SVK!
/F
the runtime warning you get when you use non-ascii characters in
python source code points the poor user to this page:
http://www.python.org/peps/pep-0263.html
which tells the user to add a
# -*- coding: encoding name -*-
to the source, and then provides a more detailed syntax
[EMAIL PROTECTED] wrote:
I tried svn up to bring my sandbox up-to-date and got this output:
% svn up
UInclude/unicodeobject.h
subversion/libsvn_wc/update_editor.c:1609: (apr_err=155017)
svn: Checksum mismatch for
'Objects/.svn/text-base/unicodeobject.c.svn-base';
M.-A. Lemburg wrote:
I don't follow you here. The source code encoding
is only applied to Unicode literals (you are using string
literals in your example). String literals are passed
through as-is.
however, for Python 3000, it would be nice if the source-code encoding applied
to the *entire*
Alan McIntyre wrote:
When running make test I get some errors in test_array and
test_compile that did not occur in the build from CVS. Given the inputs
to long() have '.' characters in them, I assume that these tests really
should be failing as implemented, but I haven't dug into them to see
Guido van Rossum wrote:
A concern I'd have with fixing this is that Unicode objects also
support the buffer API. In any situation where either str or unicode
is accepted I'd be reluctant to guess whether a buffer object was
meant to be str-like or Unicode-like. I think this covers all the
Guido van Rossum wrote:
BTW, Queue.Queue violates a recent module naming standard; it is now
considered bad style to name the class and the module the same.
Modules and packages should have short all-lowercase names, classes
should be CapWords. Even the same but different case is bad style.
Guido van Rossum wrote:
BTW, Queue.Queue violates a recent module naming standard; it is now
considered bad style to name the class and the module the same.
Modules and packages should have short all-lowercase names, classes
should be CapWords. Even the same but different case is bad
Calvin Spealman wrote:
I mean, come on, its like making a module just to store a bunch of
unrelated types just to lump them together because they're types.
import types
/F
___
Python-Dev mailing list
Python-Dev@python.org
Nick Coghlan wrote:
9. Here's a proposed native context manager for decimal.Context:
# This would be a new decimal.Context method
@contextmanager
def __with__(self):
wouldn't it be better if the ContextWrapper class (or some variation thereof)
could
be used as a
Nick Coghlan wrote:
That's not what the decorator is for - it's there to turn the generator used
to implement the __with__ method into a context manager, rather than saying
anything about decimal.Context as a whole.
possibly, but using a decorated __with__ method doesn't make much
sense if
Martin Maly wrote:
I came across a case which I am not sure if by design or a bug in Python
(Python 2.4.1 (#65, Mar 30 2005, 09:13:57)). Consider following Python
module:
# module begin
module doc
class c:
print __doc__
__doc__ = class doc (1)
print __doc__
print
James Y Knight wrote:
Your point would be much easier to stomach if the str type could
*only* hold 7-bit ASCII.
why? strings are not mutable, so it's not like an ASCII string will suddenly
sprout
non-ASCII characters. what ends up in a string is defined by the string
source. if
you cannot
Antoine Pitrou wrote:
A good rule of thumb is to convert to unicode everything that is
semantically textual
and isn't pure ASCII.
(anyone who are tempted to argue otherwise should benchmark their
applications, both speed- and memorywise, and be prepared to come
up with very strong arguments
Antoine Pitrou wrote:
A good rule of thumb is to convert to unicode everything that is
semantically textual
and isn't pure ASCII.
How can you be sure that something that is /semantically textual/ will
always remain pure ASCII ?
is != will always remain
/F
Jim Fulton wrote:
I would argue that it's evil to change the default encoding
in the first place, except in this case to disable implicit
encoding or decoding.
absolutely. unfortunately, all attempts to add such information to the
sys module documentation seem to have failed...
(last time I
Josiah Carlson wrote:
and isn't pure ASCII.
How can you be sure that something that is /semantically textual/ will
always remain pure ASCII ? That's contradictory, unless your software
never goes out of the anglo-saxon world (and even...).
Non-unicode text input widgets. Works
Antoine Pitrou wrote:
Under the default encoding (and quite a few other encodings), that's true
for
plain ascii strings and Unicode strings.
If I have an unicode string containing legal characters greater than
0x7F, and I pass it to a function which converts it to str, the
conversion
Antoine Pitrou wrote:
If I have an unicode string containing legal characters greater than
0x7F, and I pass it to a function which converts it to str, the
conversion fails.
so? if it does that, it's not unicode safe.
[...]
what's that has to do with
my argument (which is that
Guido van Rossum wrote:
Containerish behavior isn't enough to warrant empty -- false; in
some sense every object is a container (at least every object with a
__dict__ attribute) and you sure don't want to map __len__ to
self.__dict__.__len__...
the ElementTree experience shows that doing
Guido van Rossum wrote:
I think they all looks great!
expression if expression?
looks like you've been doing too much Perl hacking lately ;-)
/F
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
M.-A. Lemburg wrote:
* Unicode variant (UCS2, UCS4)
don't forget the Py_UNICODE is wchar_t subvariant.
/F
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
Guido van Rossum wrote:
It has always been my choice to *only* use XXX. I hope there aren't
any developers contributing to the Python core who use any others?
[Python-2.4.1]$ grep FIXME */*.c */*.py | wc -l
12
[Python-2.4.1]$ grep TODO */*.c */*.py | wc -l
17
[Python-2.4.1]$ grep XXX
Phillip J. Eby wrote:
It is so simple to write application server in Python.
It is so difficult to make it scallable in CPython.
It seems you've never heard of fork(), which works just fine to scale
Python processes on multiprocessor boxes.
there's a version of fork hidden somewhere in
Michael Hudson wrote:
While you're at it, maybe we should switch to and || as well?
That's another thing I always mistype when switching between
languages...
You're joking, surely?
for Python 3000, I'd recommend switching to and then and or else instead
of the current ambiguous
Karl Chen wrote:
Hi, has anybody considered adding something like this:
a = [1, 2]
[ 'x', *a, 'y']
as syntactic sugar for
a = [1, 2]
[ 'x' ] + a + [ 'y' ].
Notes:
- This is a common operation
is it?
/F
___
Python-Dev
Rich Burridge wrote:
I'm involved with the team that's working towards installing Python 2.4.x
as part of a future release of the Solaris O/S.
We currently have Python 2.3.x installed. We are trying to determine just
how compatible these two release are (at both the binary and source
(oops. trying again)
Rich Burridge wrote:
I'm involved with the team that's working towards installing Python 2.4.x
as part of a future release of the Solaris O/S.
We currently have Python 2.3.x installed. We are trying to determine just
how compatible these two release are (at both the
Martin v. Löwis wrote:
Alternatively, couldn't LIST_APPEND check that this really is a list,
and, if it isn't, fall back to PyObject_CallMethod?
that's the obvious solution, of course. cf. existing shortcuts:
$ grep -n INLINE Python-2.4.1/Python/ceval.c
1103: /*
Phillip J. Eby wrote:
I think this is called a polymorphic inline cache, although it doesn't
seem very polymorphic if you're only caching one type. :)
if it's not polymorphic, it's an ordinary inline cache (aka call-site cache).
(see various Self papers for more on polymorphic caches)
/F
Greg Ewing wrote:
Maybe backquotes could be repurposed in Py3k for interpolated
string literals?
backquotes are a PITA to type on many non-US keyboards.
/F
___
Python-Dev mailing list
Python-Dev@python.org
Antoine Pitrou wrote:
- seamless unicode support: how about making the default Python
charset utf-8 instead of ascii ? right now, someone (say an American or
English) who does not design his app with non-ascii characters in mind
may have a surprise when users enter those characters in
Josiah Carlson wrote:
Perhaps a bit into the future, extending import semantics to notice .pyx
files, compare their checksum against a stored md5 in the compiled
.pyd/.so, and automatically recompiling them if they (or their includes)
have changed: +10 (I end up doing this kind of thing by
[EMAIL PROTECTED] wrote:
Greg If a Python function is clearly wrapping a C function, one doesn't
Greg expect to be able to pass strings with embedded NULs to it.
Isn't that just floating an implementation detail up to the programmer (who
may
well not be POSIX- or Unix-aware)?
so if
Greg Ewing wrote:
(you completely missed the point -- today's print mechanism works on *any*
object
that implements a write method, no just file objects. saying that oh,
all you need is
to add a method or here's a nice mixin doesn't give you a print
replacement)
While we're on the
Greg Ewing wrote:
Indeed, Python's bytecode compiler essentially *is*
a one-pass compiler
for a suitable setting of the look-ahead window size, at least. some Python
constructs cannot be compiled by a truly minimalistic one-pass compiler.
/F
Steven Bethard wrote:
Use the print() method of sys.stderr:
sys.stderr.print('error or help message')
so who's going to add print methods to all file-like objects?
The same people that added __iter__(), next(), readline(), readlines()
and writelines() to their file-like objects
who
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 was
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...
/F
___
Python-Dev mailing list
Python-Dev@python.org
Edward C. Jones write:
Here is an example from the Python Library Reference, Section 2.1
Built-in Functions:
class C(object):
def getx(self): return self.__x
def setx(self, value): self.__x = value
def delx(self): del self.__x
x = property(getx, setx, delx, I'm the 'x'
Steven Bethard wrote:
- Error and help messages, often with print sys.stderr
Use the print() method of sys.stderr:
sys.stderr.print('error or help message')
so who's going to add print methods to all file-like objects?
/F
___
Python-Dev
[EMAIL PROTECTED] wrote:
Fredrik Python strings are character buffers with a known length, not
Fredrik null-terminated C strings. the CPython implementation
Fredrik guarantees that the character buffer has a trailing NULL
Fredrik character, but that's mostly to make it easy to
Paul F. Dubois wrote:
Remove the print statementI laughed until my sides hurt. Hello? Try
dating girls and talking to normal people, geek boys.
We scientists still use these for debugging. We never 'move on' very far
from the tutorial. The salient feature about print statements is that
Steven Bethard wrote:
But that would be just as easy with a print() function. In the current
syntax:
print 'foo:', foo, 'bar:', bar, 'baz:', baz,
print 'frobble', frobble
In my proposed function:
print('foo:', foo, 'bar:', bar, 'baz:', baz,
'frobble', frobble)
To
Paul Moore wrote:
Sorry about that - I just get a bit tired of feeling like everyone's
characterising me as either a newbie, or as not writing real code...
Hey, I'm a newbie, and I only write simple things, but Python is for people
like me, too!
/F
[EMAIL PROTECTED] wrote:
As a Python programmer I'd get back what look like three strings: http,
:, and //www.python.org/. If each of them was a view onto part of the
original string, only the last one would truly refer to a NUL-terminated
sequence of characters. If I then wanted to see
Charles Cazabon wrote:
in fact, it does nothing for the program but merely has the interesting
side-effect of writing to stdout.
yeah, real programmers don't generate output.
/F
___
Python-Dev mailing list
Python-Dev@python.org
Ron Adam wrote:
I'm not familiar with piece, but it occurred to me it might be useful to
get attributes groups in some way. My first (passing) thought was to do...
host, port = host.partition(':').(head, sep)
Where that would be short calling a method to return them:
host, port
Phillip J. Eby wrote:
Yep, subscripting and slicing are more than adequate to handle *all* of
those use cases, even the ones that some people have been jumping through
odd hoops to express:
before = x.partition(sep)[0]
found = x.partition(sep)[1]
after = x.partition(sep)[2]
Michael Hoffman wrote:
Dare I ask whether the uncompiled versions should be considered for
removal in Python 3.0?
*puts on his asbestos jacket*
there are no uncompiled versions, so that's not a problem.
if you mean the function level api, it's there for convenience. if you're
using less
Phillip J. Eby wrote:
both split on a given token. partition splits once, and returns all three
parts, while piece returns the part you ask for
No, because looking at that URL, there is no piece that is the token split
on. partition() always returns 3 parts for 1 occurrence of the token,
Tim Peters wrote:
Anyone remember why setdefault's second argument is optional?
Some kind of symmetry with get, probably. if
d.get(x)
returns None if x doesn't exist, it makes some kind of sense that
d.setdefault(x)
returns None as well.
Anyone remember why nobody managed to come
Tim Peters wrote:
Anyone remember why nobody managed to come up with a better name
for setdefault (which is probably the worst name ever given to a method
in the standard Python distribution) ?
I suggested a perfect name at the time:
Ron Adam wrote:
For cases where single values are desired, attribues could work.
Slicing:
line = line.partition(';').head
line = line.partition('#').head
But it gets awkward as soon as you want more than one.
sep, port = host.partition(':').head,
Neil Schemenauer wrote:
The PEP has been rewritten based on a suggestion by Guido to change
str() rather than adding a new built-in function. Based on my testing, I
believe the idea is feasible.
note that this breaks chapter 3 of the tutorial:
Gareth McCaughan wrote:
It's valid C99, meaning this is an unsigned long long.
since when does Python require C99 compilers?
/F
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
Nicholas Bastin wrote:
It's a mature product. I would hope that that would count for
something. I've had enough corrupted subversion repositories that I'm
not crazy about the thought of using it in a production system. I
know I'm not the only person with this experience.
compared to
Darryl Dixon wrote:
Microsoft support capturing extended characters via _getch, but it requires
making a
second call to getch() if one of the 'magic' returns is encountered in the
first call (0x00
or 0xE0).
so why not do that in your python code?
The relevant chunk of code in Python
Skip Montanaro wrote:
That's fine, so XML-RPC is slower than Gherkin. I can't run the Gherkin
code, but my XML-RPC numbers are a bit different than yours:
XMLRPC encode 0.65 seconds
XMLRPC decode 2.61 seconds
That leads me to believe you're not using any sort of C XML decoder. (I
Gustavo Niemeyer wrote:
moving the main trunk and main development over to the Python CVS is
another thing, entirely.
(as I've said many times before, both the user community and the developer
community would benefit if the core standard library were made smaller, and
more
library.
Rewritten:
If Fredrik Lundh were supportive of the idea, I think the Standard
Library would benefit greatly from incorporating ElementTree.
shipping stable versions of ElementTree/cElementTree (or PIL, or python-
doc, or exemaker, or what else you might find useful) with official Python
moving the main trunk and main development over to the Python CVS is
another thing, entirely.
(as I've said many times before, both the user community and the developer
community would benefit if the core standard library were made smaller, and
more externally maintained packages were included
Guido van Rossum wrote:
I've written up the specs for my PEP 340 redux proposal as a
separate PEP, PEP 343.
http://python.org/peps/pep-0343.html
Those who have been following the thread Merging PEP 310 and PEP
340-redux? will recognize my proposal in that thread, which received
mostly
Michael Hudson wrote:
Looking at my above code, no (even though I think I've rendered the
point moot...). Compare and contrast:
@template
def redirected_stdout(out):
save_stdout = sys.stdout
sys.stdout = out
yield None
sys.stdout = save_stdout
class
Guido van Rossum wrote:
PEP 340 redux
=
Syntax:
do EXPR [as VAR]:
BLOCK
Translation:
abc = EXPR
[VAR =] abc.__enter__()
try:
BLOCK
finally:
abc.__exit__(*sys.exc_info()) # Not exactly
Pros:
- can use a decorated generator as EXPR
- separation of EXPR and
François Pinard wrote:
It happens once in a while that I want to comment out the except clauses
of a try statement, when I want the traceback of the inner raising, for
debugging purposes. Syntax forces me to also comment the `try:' line,
and indent out the lines following the `try:' line.
Guido van Rossum wrote:
(to save typing, you can use an empty string or even
put quotes around the exception name, but that may
make it harder to spot the change)
Yeah, but that will stop working in Python 3.0.
well, I tend to remove my debugging hacks once I've fixed
the bug. I
Guido van Rossum wrote:
Fredrik, what does your intuition tell you?
having been busy with other stuff for nearly a week, and seeing that the PEP is
now at
version 1.22, my intuition tells me that it's time to read the PEP again before
I have any
opinion on anything ;-)
/F
Thomas Heller wrote:
AFAIK, you can configure Python to use 16-bits or 32-bits Unicode chars,
independend from the size of wchar_t. The HAVE_USABLE_WCHAR_T macro
can be used by extension writers to determine if Py_UNICODE is the same as
wchar_t.
note that usable is more than just same size;
Guido van Rossum wrote:
I've written a PEP about this topic. It's PEP 340: Anonymous Block
Statements (http://python.org/peps/pep-0340.html).
Some highlights:
- temporarily sidestepping the syntax by proposing 'block' instead of 'with'
- __next__() argument simplified to StopIteration or
Phillip J. Eby wrote:
This interest is unrelated to anonymous blocks in any case; it's about
being able to simulate lightweight pseudo-threads ala Stackless, for use
with Twisted. I can do this now of course, but yield expressions as
described in PEP 340 would eliminate the need for the
Guido van Rossum wrote:
At the same time, having to use it as follows:
for f in with_file(filename):
for line in f:
print process(line)
is really ugly, so we need new syntax, which also helps with keeping
'for' semantically backwards compatible. So let's use
Facundo Batista wrote:
Is there a document that details which objects are cached in memory
(to not create the same object multiple times, for performance)?
why do you think you need to know?
If not, could please somebody point me out where this is implemented
for strings?
Objects/stringobject.c
Josiah Carlson wrote:
for my purposes, I've found that the #1 callback killer in contemporary
Python
is for-in:s support for the iterator protocol:
...
and get shorter code that runs faster. (see cElementTree's iterparse for
an excellent example. for typical use cases, it's nearly
Bob Ippolito wrote:
def strawman(self):
def sayGoodbye(mingleResult):
def goAway(goodbyeResult):
self.loseConnection()
self.send(goodbye).addCallback(goAway)
def mingle(helloResult):
self.send(nice weather we're having).addCallback(sayGoodbye)
Josiah Carlson wrote:
See the previous two discussions on thunks here on python-dev, and
notice how the only problem that seem bettered via blocks/thunks /in
Python/ are those which are of the form...
#setup
try:
block
finally:
#finalization
... and depending on the syntax, properties. I
Shane Hathaway wrote:
Brian's suggestion makes the code read more like an outline. In Brian's
example, the high-level intent stands out from the details
that assumes that when you call a library function, the high-level intent of
*your* code is obvious from the function name in the library, and
Brian Sabbey wrote:
If suites were commonly used as above to define properties, event handlers
and other callbacks, then I think most people would be able to comprehend
what the first example above is doing much more quickly than the second.
wonderful logic, there. good luck with your future
Bob Ippolito wrote:
It might be worth mentioning that if/when subversion is used to replace CVS,
unified diffs are
going to be the obvious way to do it, because I don't think that subversion
supports context diffs
without using an external diff command.
subversion? you meant bazaar-ng,
Tim Peters wrote:
[Fredrik Lundh]
is changing the marshal format really the right thing to do at this
point?
I don't see anything special about this point -- it's just sometime
between 2.4.1 and 2.5a0. What do you have in mind?
I was under the impression that the marshal format has been
Scott David Daniels wrote:
From yesterday's sprint
sprint? I was beginning to wonder why nobody cared about this;
guess I missed the announcement ;-)
At the least a change like this will catch the unpacking:
in marshal.c (around line 500) in function r_object:
PyFPE_START_PROTECT(atof,
Tim Peters wrote:
marshal shouldn't be representing doubles as decimal strings to begin
with. All code for (de)serialing C doubles should go thru
_PyFloat_Pack8() and _PyFloat_Unpack8(). cPickle (proto = 1) and
struct (std mode) already do; marshal is the oddball.
is changing the marshal
Skip Montanaro wrote:
Are float(inf) and float(nan) supported everywhere?
nope.
float(inf)
Traceback (most recent call last):
File stdin, line 1, in ?
ValueError: invalid literal for float(): inf
float(nan)
Traceback (most recent call last):
File stdin, line 1, in ?
ValueError: invalid
pickle doesn't have the INF=1.0 bug:
import pickle
pickle.loads(pickle.dumps(1e1))
...
ValueError: invalid literal for float(): 1.#INF
import cPickle
cPickle.loads(cPickle.dumps(1e1))
...
ValueError: could not convert string to float
import marshal
Raymond Hettinger wrote:
I used those addresses and sent notes to everyone who hasn't made a
recent checkin.
where recent obviously was defined as after 2.4 for checkins, and last week
for tracker activities.
python-dev was a lot more fun in the old days.
/F
Scott David Daniels wrote:
What should marshal / unmarshal do with floating point NaNs (the case we
are worrying about is Infinity) ? The current behavior is not perfect.
Michael Spencer chased down a supposed Idle problem to (on Win2k):
marshal.dumps(1e1) == 'f\x061.#INF'
[EMAIL PROTECTED] wrote:
(ie. the re library only returns the ~last~ match for named groups - not
a list of ~all~ the matches for the named groups. And the hierarchy of
those named groups is non-existant in the flat dictionary of matches
that results. )
are you 100% sure that this can be
Tim Peters wrote:
[Fredrik Lundh]
wouldn't be the first time...
How soon we forget wink.
oh, that was in the dark ages of Python 1.4. I've rebooted myself many times
since
then...
Fredrik introduced a pile of optimizations special-casing the snot out
of small integers into ceval.c
Donovan Baarda wrote:
Apparently lawyers have decided that you can't give code away. Intellectual
charity is illegal :-)
what else would a lawyer say? do you really expect lawyers to admit that there
are ways to do things that don't involve lawyers?
/F
Raymond Hettinger wrote:
Based on some ideas from Skip, I had tried transforming the likes of x
in (1,2,3) into x in frozenset([1,2,3]). When applicable, it
substantially simplified the generated code and converted the O(n)
lookup into an O(1) step. There were substantial savings even if
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.
Nick Coghlan wrote:
One thing that actually can motivate that test_subprocess takes 20% of the
overall time is that this test is a good generic Python stress test - this
test might catch some other startup race condition, for example.
test_decimal has a short version which tests basic
Raymond Hettinger wrote:
but refactoring the contains code to use find_internal sounds like a good
first step. any takers?
I'm up for it.
excellent!
just fyi, unless my benchmark is mistaken, the Unicode implementation has
the same problem:
str in - 25.8 µsec per loop
unicode in
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 usec per
501 - 600 of 622 matches
Mail list logo
