Nick Coghlan [EMAIL PROTECTED] added the comment:
Looks like we'll be living with the slowdown for 3.0, so marking this as
a high priority item for 3.1.
(Given that the API doesn't change, I wonder if this could be included
in a 3.0.1 release?)
--
priority: - high
versions: +Python
Nick Coghlan [EMAIL PROTECTED] added the comment:
This issue was missing a priority setting.
Alexander's range-sequence patch still applies cleanly to the Py3k
branch, and make test still runs correctly after applying it.
As Alexander notes above, range_contains does still need slightly better
Changes by Nick Coghlan [EMAIL PROTECTED]:
Removed file:
http://bugs.python.org/file11345/issue2690-range-sequence-ncoghlan.diff
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2690
Nick Coghlan [EMAIL PROTECTED] added the comment:
My initial patch had a few problems - I removed it and uploaded a
corrected version.
Added file:
http://bugs.python.org/file11346/issue2690-range-sequence-ncoghlan.diff
___
Python tracker [EMAIL PROTECTED
Nick Coghlan [EMAIL PROTECTED] added the comment:
Good catch Antoine (I missed that in Alexander's patch) - working on
that now.
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2690
Nick Coghlan [EMAIL PROTECTED] added the comment:
v2 of my updated patch attached to fix the issue Antoine noted.
Also gets rid of some tab-instead-of-spaces indenting issues in the
file, and avoids hardcoding PyRange_Type when creating new instances.
However, the patch still has issues
Nick Coghlan [EMAIL PROTECTED] added the comment:
Given the problems with it, I'm dropping this to normal priority and
punting to 3.1.
(the release blocker status was just temporary to ensure we got a
decision on it before rc1 - it previously didn't have a priority set)
--
keywords
Nick Coghlan [EMAIL PROTECTED] added the comment:
Raymond Hettinger wrote:
I think this should be deferred to Py3.1.
This decision was not widely discussed and I think it likely that some
users will
be surprised and dismayed. The release
candidate seems to be the wrong time to
yank
Nick Coghlan [EMAIL PROTECTED] added the comment:
Attached patch raises Py3k warnings rather than plain deprecation
warnings, so it looks good to me (some of the discussions on python-dev
gave the impression that may have been getting full deprecation
warnings, implying its potential removal
Nick Coghlan [EMAIL PROTECTED] added the comment:
Patch looks good to me (I've only looked at the patch - not the other
possible misuses of PyByteArray_ that Amaury noted)
--
nosy: +ncoghlan
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org
Nick Coghlan [EMAIL PROTECTED] added the comment:
I was actually pretty sure the intention was to add Py3k warnings, but
the exact phrase being used in the python-dev thread was deprecation
warnings which made folks a little nervous.
___
Python tracker [EMAIL
Nick Coghlan [EMAIL PROTECTED] added the comment:
Reopening this because I disagree with the fix - I would prefer to see
catch_warnings() reverted back to the API and implementation* it used
prior to the test_support-warnings migration.
That version had perfectly clear semantics when no warning
Nick Coghlan [EMAIL PROTECTED] added the comment:
It turns out the warnings.catch_warnings version has re-entrancy issues
due to the fact that it can't use @contextmanager:
Python 2.6b3+ (trunk:66143M, Sep 2 2008, 20:04:43)
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2
Type help, copyright
Nick Coghlan [EMAIL PROTECTED] added the comment:
I also have to comment on the makes the API simpler to use note in the
checkin message. No, no it doesn't. See all those warning[-1] calls in
the current unit tests? They're all unhelpful, because if a warning
doesn't get raised, you're going
Changes by Nick Coghlan [EMAIL PROTECTED]:
--
assignee: - ncoghlan
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3781
___
___
Python-bugs-list mailing
Nick Coghlan [EMAIL PROTECTED] added the comment:
test.test_support *is* a public API (it's even documented).
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3781
Nick Coghlan [EMAIL PROTECTED] added the comment:
In working on the reversion patch, I just noticed that r66321 also
incorrectly removed a whole pile of w.reset() calls.
When using a single catch_warning() context to test two or more
operations which may raise the same warning, you *must* call
Nick Coghlan [EMAIL PROTECTED] added the comment:
Fully reverting the relocation also required reverting r66197 (a belated
checkin of test_py3kwarn for the r66135 changes).
There was also a change to test_warnings that had to be reverted (it
appeared to have been mistakenly checked in as part
Nick Coghlan [EMAIL PROTECTED] added the comment:
Reversion patch attached - it does indeed recreate some nasty
dependencies from the main areas of the standard library on to the
regression test suite. That's enough to kill the idea of a complete
reversion as far as I'm concerned - I'll get
Nick Coghlan [EMAIL PROTECTED] added the comment:
No worries - the only reason I suggested full reversion at all is
because I had temporarily forgotten why the relocation had become so
necessary (i.e. we needed the feature ourselves in the main part of the
standard library to avoid emitting
Nick Coghlan [EMAIL PROTECTED] added the comment:
Not quite that basic for the warnings.catch_warnings() part. I plan to
leave the current warnings.catch_warnings() alone (aside from adding
some re-entrancy checks), and add back a
test.test_support.check_warnings() that uses a WarningsRecorder
Nick Coghlan [EMAIL PROTECTED] added the comment:
Cleanup patch now attached. Details of changes:
- warnings.catch_warnings() now has reentry guards (and associated
tests) to prevent silent errors when misused
- added back a test_support.check_warnings() convenience wrapper
(deliberately
Nick Coghlan [EMAIL PROTECTED] added the comment:
Applied to trunk for 2.6 in r66386.
--
priority: release blocker - deferred blocker
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3781
Nick Coghlan [EMAIL PROTECTED] added the comment:
Blocked merge in the py3k branch since it requires some fiddling to
handle the change from test.test_support to test.support. I'll post a
new patch here for the py3k forward port when I can (I may not make it
before 3.0b4 though, so unassigning
Nick Coghlan [EMAIL PROTECTED] added the comment:
Setting this to a release blocker, because it is affecting Neal's
automated execution of the regression test suite with a debug build.
--
nosy: +ncoghlan
priority: - release blocker
___
Python
Nick Coghlan [EMAIL PROTECTED] added the comment:
Scratch that - it's more likely to be Neal's setup which is at fault,
which I will be questioning on python-dev shortly (there are 3 other
tests which are failing/getting skipped in Neal's regression test suite)
--
priority: release
Nick Coghlan ncogh...@gmail.com added the comment:
Assigned to Benjamin for assessment - this should be considered for rc2
since it's still broken in 3.1:
f = open('setup.py', 'rb')
len(f.peek(10))
4096
len(f.peek(1))
4096
len(f.peek(4095))
4096
len(f.peek(10095))
4096
Brought up
Nick Coghlan ncogh...@gmail.com added the comment:
It's not the docstring that is wrong for the current behaviour, it's the
IO.BufferedReader documentation:
peek([n])
Return 1 (or n if specified) bytes from a buffer without advancing
the position. Only a single read on the raw stream
Nick Coghlan ncogh...@gmail.com added the comment:
The doc revision definitely does a better job of characterising the
current underspecified behaviour :)
I agree with Antoine that at most a single read would be better wording.
--
___
Python tracker
New submission from Nick Coghlan ncogh...@gmail.com:
Just a placeholder to remind me to implement the suggestion from
python-dev of updating the contextlib.nested docs to show:
1. The one remaining valid use case (variable number of context managers)
2. The warnings module incantation needed
Nick Coghlan ncogh...@gmail.com added the comment:
That's a good point actually - with 3.1's in-between status and the
lack of deprecation in 2.6, nested() is going to have to stick around
for 2.7/3.2 anyway.
So PendingDeprecation now with full deprecation in 2.7/3.2 when we will
hopefully have
Nick Coghlan ncogh...@gmail.com added the comment:
In light of Raymond's comments (which make sense to me), I'm just
updating the documentation and leaving the full deprecation warning in
place.
The new docs are deliberately explicit about *why* trying to use the
current form of nested
Nick Coghlan ncogh...@gmail.com added the comment:
And done for 3.1 in r73466
--
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6288
Nick Coghlan ncogh...@gmail.com added the comment:
Good point - I forgot about the docstring.
Yes, I think that should be changed to use the new wording up to the new
example (similar to the way the old docstring stopped at the example).
Reopening until that is done (although reducing from
Nick Coghlan ncogh...@gmail.com added the comment:
Docstring updated in r73518 (2.7) and r73520 (3.1)
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6288
Nick Coghlan ncogh...@gmail.com added the comment:
It doesn't work in 2.6 or 3.0 because, as stated above, it was only due
to a bug that it even appeared to work at all in 2.5 (it was always
meant to be disallowed because it puts dodgy data in the import
machinery's internal records if you do
Nick Coghlan ncogh...@gmail.com added the comment:
If you need to support Python 2.6 as well as 3.1, the simplest thing to
do is just tell people to run pygame.tests.main always (i.e.
completely skip the idea of executing the package directly and always
run a submodule instead).
The reason
Nick Coghlan ncogh...@gmail.com added the comment:
Given that dumps(type(Ellipsis)) and dumps(type(NotImplemented)) don't
work either, I am reclassifying this as a documentation bug.
The thing about the types of these three objects (None, Ellipsis,
NotImplemented) is that they are all designed
Changes by Nick Coghlan ncogh...@gmail.com:
--
assignee: - jnoller
nosy: +jnoller
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6461
Nick Coghlan ncogh...@gmail.com added the comment:
Confirmed - it's actually pressing Ctrl-D after entering text on the
line that seems to cause strange behaviour. For example, in the
following, the only letters I typed were test and then I just pressed
Ctrl-D 4 times and got the output seen
Nick Coghlan ncogh...@gmail.com added the comment:
Copying my suggestion (minus examples) over from the python-ideas thread:
We could define it as trying the three modes in order (first 'eval',
then 'single', then 'exec') moving on to the next option if it raises
syntax error:
from dis import
Nick Coghlan ncogh...@gmail.com added the comment:
As per Georg's suggestion, a better approach would look like:
from dis import dis
def dis_str(source):
try:
c = compile(source, '', 'eval')
except SyntaxError:
c = compile(source, '', 'exec')
return dis(c
Changes by Nick Coghlan ncogh...@gmail.com:
--
nosy: +ncoghlan
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6626
___
___
Python-bugs-list mailing
Changes by Nick Coghlan ncogh...@gmail.com:
--
nosy: +ncoghlan
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6627
___
___
Python-bugs-list mailing
Nick Coghlan ncogh...@gmail.com added the comment:
Reopening - this should be rejected by the compiler as a SyntaxError,
since it is the comprehension equivalent of writing return Value
inside a generator function.
Specifically, in 3.x, the equivalent written out code is:
while True
Nick Coghlan ncogh...@gmail.com added the comment:
You would also run in to the usual problems with any form of DRM: the
password *will* exist in memory in order for zipimport to be able to use
it, so anyone that really wants the password will be able to get hold of it.
It also isn't as simple
New submission from Nick Coghlan ncogh...@gmail.com:
Currently, the runpy._run_module_as_main() function allows a launch
script to mimic Python's -m switch fairly well.
This RFE suggests making it possible to mimic other command line
behaviour of the CPython interpreter in a documented fashion
Changes by Nick Coghlan ncogh...@gmail.com:
--
assignee: - ncoghlan
versions: +Python 3.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6816
Changes by Nick Coghlan ncogh...@gmail.com:
--
versions: +Python 2.7
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6816
___
___
Python-bugs-list
Nick Coghlan ncogh...@gmail.com added the comment:
Poking the timbot - this seems like a good idea to me (and it also means
C extension developers would be able to use a debug build of Python to
look for errors in their own use of these APIs).
--
nosy: +tim_one
Nick Coghlan ncogh...@gmail.com added the comment:
Only +0 purely because I haven't used argparse myself yet.
Otherwise I would probably be +1, since I have several scripts that have
fairly kludgy hacked together optparse based approaches to handling
positional arguments, subparsers
Nick Coghlan ncogh...@gmail.com added the comment:
It must be convenient to operate in an environment where you can install
new software so easily Armin.
For those of us that operate in environments where every new piece of
software has to go through contracts review to ensure that we can both
Nick Coghlan ncogh...@gmail.com added the comment:
Probably too late for 2.6.3 - assigning to Barry to check anyway.
--
assignee: - barry
nosy: +barry, ncoghlan
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5949
Nick Coghlan ncogh...@gmail.com added the comment:
hasattr(type(x), __call__) is technically a more valid replacement due
to the usual matter of metaclass confusion.
(Although putting special methods on instance objects is a recipe for
trouble in more ways than just this one).
--
nosy
Nick Coghlan ncogh...@gmail.com added the comment:
Although we should seriously consider properly exposing special method
lookup at the Python level...
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7006
New submission from Nick Coghlan ncogh...@gmail.com:
The alignment flag to format() is not right aligning numbers
properly on trunk and the py3k branch:
format(0x1234, +#08x)
'+0x01234'
format(0x1234, 0=+#8x)
'+0x01234'
format(0x1234, 0+#8x)
'+0x01234'
That last one should be:
format
Nick Coghlan ncogh...@gmail.com added the comment:
Just checked, and yep, it's a duplicate of 6902 - the problem does
indeed go away if I use a different formatting character.
--
resolution: - duplicate
status: open - closed
superseder: - Built-in types format incorrectly with 0
Nick Coghlan ncogh...@gmail.com added the comment:
Note that the 2.6 branch didn't seem to suffer this problem when I
checked it earlier tonight.
--
nosy: +ncoghlan
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6902
Nick Coghlan ncogh...@gmail.com added the comment:
I'm glad someone with more roundtuits than I had the same idea after the
logging error in 2.6.3 :)
The regrtest change isn't needed any more since RDM checked that concept
in separately - the test update itself looks fine though (and applies
Nick Coghlan ncogh...@gmail.com added the comment:
The thread safety problem comes from the fact that performing file IO as
mimetypes.init() does will release the GIL - if you want to ensure
thread safety in that context, you have to do your own locking.
mimetypes ignore this thread
Nick Coghlan ncogh...@gmail.com added the comment:
Putting this here for the record rather than leaving it in Rietveld:
I appreciate the desire for a cleaner API for handling mimetypes, but
this isn't the way to get it. Finding projects that have their own
mimetypes implementations, asking them
Nick Coghlan ncogh...@gmail.com added the comment:
Knew I forgot to mention something - I'm not on OS X at all (Linux,
Ubuntu 8.04). I was only looking at this bug because RDM cross-linked it
to the mimetypes patch I was reviewing this evening.
Running the threadboom code, it passes fine for me
Nick Coghlan ncogh...@gmail.com added the comment:
Must have missed running the full test suite before checking that one
in. Whoops...
Anyway, the culprit is a couple of copy_reg calls that the os module
runs on import to register pickle support methods. CleanImport's
simplistic approach
Nick Coghlan ncogh...@gmail.com added the comment:
Should be OK again as of r75481.
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7164
New submission from Nick Coghlan ncogh...@gmail.com:
The xmlrpc tests were changed to use a StringIO object instead of a
temporary file (this change reflects the corresponding change made on
the 2.x trunk).
The tests then started failing, since xmlrpc.server assumes sys.stdout
will provide
Nick Coghlan ncogh...@gmail.com added the comment:
Fine by me (I was very close to changing the test when I first triggered
the problem, but wasn't sure silencing the error was the right thing to do).
Assigning back to myself to add a comment to the relevant line (i.e.
that relying
Nick Coghlan ncogh...@gmail.com added the comment:
It's not the current directory that's the problem, it's the current
drive. Windows has no absolute root directory - instead, it has a root
directory for each drive. That means that \\dir is a path relative to
the current drive rather than
Nick Coghlan ncogh...@gmail.com added the comment:
The path *returned* is relative to the start point. The target path is
figured out normally (i.e. relative to the current directory if an
absolute path is not given).
In your example, you aren't passing in an absolute Windows path - you
give
Nick Coghlan ncogh...@gmail.com added the comment:
os.relpath *does* give you a relative path between two directories.
The problem you are encountering is that, on Windows, a relative path
doesn't even *exist* if the two directories are on different drives
(which is exactly what the error
Nick Coghlan ncogh...@gmail.com added the comment:
If the idea is to create the one obvious way for interning, calling
the method and corresponding C function intern isn't painting a
bikeshed, it's meeting the design spec :)
Adding a new method also avoids a whole host of issues with the Set
Nick Coghlan ncogh...@gmail.com added the comment:
This is a largely inevitable consequence of the conversion from a
statement to a function - the interpreter eval loop for the exec
statement used to do some fancy footwork to make locals() modifications
work, but with exec becoming just another
Nick Coghlan ncogh...@gmail.com added the comment:
Descoped idea to just provide runpy.run_path (filesystem path equivalent
of runpy.run_module)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6816
Nick Coghlan ncogh...@gmail.com added the comment:
2.7: r76286
3.2 merge is still a work in progress
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6816
Nick Coghlan ncogh...@gmail.com added the comment:
pydoc removes the scriptdir from sys.path. When run under -m, that
means it removes the standard library directory!
It works in 2.x because os.popen doesn't rely on subprocess there -
instead it comes direct from the builtin posix module
Nick Coghlan ncogh...@gmail.com added the comment:
Fixed in r76312 and subsequent checkins (pydoc was corrupting sys.path
when run under -m and getting away with it in 2.x, but breaking os.popen
in 3.x)
--
___
Python tracker rep...@bugs.python.org
Changes by Nick Coghlan ncogh...@gmail.com:
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7328
Nick Coghlan ncogh...@gmail.com added the comment:
The windows errors are most likely due to the fact that I'm not doubling
the backslashes in the file paths before passing them to
assertRaisesRegex() as the regular expression pattern.
The reference leak is also interesting, since there isn't
Nick Coghlan ncogh...@gmail.com added the comment:
Hmm, definitely not the path importer cache - regrtest already takes
that into account by reverting it to its original state before checking
the reference counts.
--
___
Python tracker rep
Nick Coghlan ncogh...@gmail.com added the comment:
There's another cache in zipimport that wasn't being cleared when
hunting refleaks. I've updated that on the trunk and will include it in
the forward port to 3k (along with a fix for the Windows path separator
problem
New submission from Nick Coghlan ncogh...@gmail.com:
I ran into a few gratuitous conflicts forward porting the command line
testing cleanup. This should be eliminated by making script_helper
sufficiently flexible to cover both the 2.x and 3.x use cases.
--
assignee: ncoghlan
components
Nick Coghlan ncogh...@gmail.com added the comment:
Added to Py3k in r76324 (including the fixes made on 2.x after the
original checkin)
--
resolution: - accepted
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Changes by Nick Coghlan ncogh...@gmail.com:
--
priority: normal - low
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7331
___
___
Python-bugs-list
Nick Coghlan ncogh...@gmail.com added the comment:
Lowering priority due to implementation of explicit syntax for multiple
context managers in a single with statement
--
priority: - low
___
Python tracker rep...@bugs.python.org
http
Nick Coghlan ncogh...@gmail.com added the comment:
Antoine Pitrou wrote:
Antoine Pitrou pit...@free.fr added the comment:
I also think isinstance(x, collections.Callable) is the correct
replacement. Even though it might give a different answer on weird
corner cases, it is semantically what
Nick Coghlan ncogh...@gmail.com added the comment:
Hmm, I think I need to use a more robust regex escaping approach... I
never knew the OS level temp dir creation could get that creative.
--
___
Python tracker rep...@bugs.python.org
http
Nick Coghlan ncogh...@gmail.com added the comment:
It turns out this problem was breaking pydoc -m completely in Python 3.x
(os.popen was breaking since it couldn't find the subprocess module -
see #7238).
A more robust fix that retains the three lines, but modifies them to
avoid deleting
Nick Coghlan ncogh...@gmail.com added the comment:
I fixed the tests to use the proper escaping function from the re module
instead of directly doubling backslashes, so that error shouldn't happen
any more.
(Was it one of the unstable buildbots that picked this up? I didn't see
anything come
New submission from Nick Coghlan ncogh...@gmail.com:
As the subject line says: the wsgiref unit tests fail on the new Windows
7 buildbot.
It appears to be happening every run, but here's one example:
http://www.python.org/dev/buildbot/trunk/builders/x86%20Windows7%20trunk/builds/25/steps/test
Nick Coghlan ncogh...@gmail.com added the comment:
Patch looks good to me.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5037
___
___
Python
Nick Coghlan ncogh...@gmail.com added the comment:
Reviewed patch diff - looks good to me. It's an obscure corner case, but
the patch is pretty straightforward so we may as well clean it up.
--
___
Python tracker rep...@bugs.python.org
http
Nick Coghlan ncogh...@gmail.com added the comment:
Unassigned from Barry since this isn't an RM review issue anymore
--
assignee: barry -
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5949
Changes by Nick Coghlan ncogh...@gmail.com:
--
priority: - high
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5949
___
___
Python-bugs-list
Nick Coghlan ncogh...@gmail.com added the comment:
A few pointers in case anyone decides to follow this up further:
Zipfile execution is just a special case of normal zipimport: the
zipfile's name is placed at the head of sys.path and a (very) rough
equivalent of import __main__ is then invoked
Nick Coghlan ncogh...@gmail.com added the comment:
Antoine Pitrou wrote:
Antoine Pitrou pit...@free.fr added the comment:
(Was it one of the unstable buildbots that picked this up? I didn't see
anything come through on the checkins list)
Buildbot failures have stopped being e-mailed long
New submission from Nick Coghlan ncogh...@gmail.com:
Fairly straightforward one - __import__ is no longer the preferred tool
for doing runtime imports, so its documentation should point to
imputil.import_module
(this is a little more than just a see also, some of the existing
wording
Nick Coghlan ncogh...@gmail.com added the comment:
Given that you had to use ctypes to create the symlinks on Windows in
the first place, I'd say you're right :)
Probably the first step would be to make sure the nt OS and path modules
get Windows symlink support (although even that may
Nick Coghlan ncogh...@gmail.com added the comment:
s/imputil/importlib/
Details, details...
--
title: __import__ docs should reference imputil.import_module - __import__
docs should reference importlib.import_module
___
Python tracker rep
Nick Coghlan ncogh...@gmail.com added the comment:
Following this down the rabbit hole a little further: Issue #2517 (the
origin of my checkin) was just a restoration of the __unicode__ slot
implementation that had been ripped out in r51837 due to Issue #1551432.
At the time of the r64791
Nick Coghlan ncogh...@gmail.com added the comment:
As Antoine said, there's a reason BaseException now implements both
__str__ and __unicode__ and doesn't implement the latter in terms of the
former - it's the only way to consistently support Unicode arguments
that can't be encoded to an 8-bit
Nick Coghlan ncogh...@gmail.com added the comment:
I agree the 2.6 implementation creates backwards compatibility problems
with subclasses that only override __str__ that we didn't recognise at
the time.
An alternative approach that should work even for the KeyError case
701 - 800 of 6264 matches
Mail list logo
