GV

GeezerVison

The World Wide Web, restored to 800 pixels of glory.

Home|About|Gaming cabinet|Archives|How it works|Starter sites

On this site

  • Sign in
  • ActionsCI/CD and automation
  • CodespacesCloud development environments
  • All Features
  • Documentation
  • Training
  • Certifications
  • Build with Copilot
  • Customize Copilot
  • Integrations
  • Trending repos
  • GitHub Sponsors
  • Developer articles
  • Enterprises

This view

  • Original page
  • New address

GeezerVison is showing github.com — bpo-10746: ctypes: Fix PEP 3118 type codes for c_long, c_bool, c_int by pv · Pull Request #31 · python/cpython

Conversation

@pv

@pv pv commented Feb 11, 2017 •
edited by bedevere-bot
Loading

Uh oh!

There was an error while loading. Please reload this page.

Copy link
Copy Markdown
Contributor

Ctypes currently produces wrong pep3118 type codes for several types.
E.g. memoryview(ctypes.c_long()).format gives "<l" on 64-bit platforms,
but it should be "<q" instead for sizeof(c_long) == 8

The problem is that the '<>' endian specification in the struct syntax
also turns on the "standard size" mode, which makes type characters have
a platform-independent meaning, which does not match with the codes used
internally in ctypes. The struct module format syntax also does not
allow specifying native-size non-native-endian items.

This commit adds a converter function that maps the internal ctypes
codes to appropriate struct module standard-size codes in the pep3118
format strings. The tests are modified to check for this.

Example of the current problem in practice:

>>> import numpy, ctypes
>>> numpy.asarray(memoryview(ctypes.c_long(42)))
/usr/lib64/python3.5/site-packages/numpy/core/numeric.py:482: RuntimeWarning: Item size computed from the PEP 3118 buffer format string does not match the actual item size.
  return array(a, dtype, copy=False, order=order)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib64/python3.5/site-packages/numpy/core/numeric.py", line 482, in asarray
    return array(a, dtype, copy=False, order=order)
ValueError: setting an array element with a sequence.
  • struct format string syntax
  • bpo-10746

https://bugs.python.org/issue10746

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.
All reactions
@the-knights-who-say-ni

the-knights-who-say-ni commented Feb 11, 2017

Copy link
Copy Markdown

Hello, and thanks for your contribution!

I'm a bot set up to make sure that the project can legally accept your contribution by verifying you have signed the PSF contributor agreement (CLA).

Unfortunately our records indicate you have not signed the CLA. For legal reasons we need you to sign this before we can look at your contribution. Please follow these steps to rectify the issue:

  1. Sign the PSF contributor agreement
  2. Wait at least a day and then check "Your Details" on bugs.python.org to see if your account has been marked as having signed the CLA (the delay is due to a person having to manually check your signed CLA)
  3. Reply here saying you have completed the above steps

Thanks again to your contribution and we look forward to looking at it!
All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.
@the-knights-who-say-ni the-knights-who-say-ni added the CLA not signed label Feb 11, 2017
@codecov

codecov Bot commented Feb 11, 2017

Copy link
Copy Markdown

Codecov Report

Merging #31 into master will increase coverage by <.01%.
The diff coverage is 84.61%.

@@            Coverage Diff             @@
##           master      #31      +/-   ##
==========================================
+ Coverage   82.37%   82.37%   +<.01%     
==========================================
  Files        1427     1427              
  Lines      350948   350957       +9     
==========================================
+ Hits       289088   289114      +26     
+ Misses      61860    61843      -17

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update e7ffb99...b4cf54b. Read the comment docs.
All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.
@zware zware removed the CLA not signed label Feb 14, 2017
@the-knights-who-say-ni the-knights-who-say-ni added the CLA signed label Feb 14, 2017
@pv

pv commented Feb 14, 2017 via email

Copy link
Copy Markdown
Contributor Author
CLA signed.
All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.
pitrou
pitrou requested changes Jun 6, 2017
View reviewed changes
Comment thread Modules/_ctypes/_ctypes.c Outdated

@pitrou pitrou Jun 6, 2017

Copy link
Copy Markdown
Member

There was a problem hiding this comment.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This function should be declared static.

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.
All reactions
Comment thread Lib/ctypes/test/test_pep3118.py Outdated

@pitrou pitrou Jun 6, 2017

Copy link
Copy Markdown
Member

There was a problem hiding this comment.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't understand this line. Can you show an example where tp._type_ is necessary?

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.
All reactions

@pv pv Jun 22, 2017

Copy link
Copy Markdown
Contributor Author

There was a problem hiding this comment.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I must say I don't understand it either anymore. It may be leftover from refactoring.
Since the tests seem to pass, I now simplified it.

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.
All reactions

@pv pv Jun 22, 2017 •
edited
Loading

Uh oh!

There was an error while loading. Please reload this page.

Copy link
Copy Markdown
Contributor Author

There was a problem hiding this comment.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah no, it was due to a int/long failure on windows:

======================================================================
FAIL: test_native_types (ctypes.test.test_pep3118.Test)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\projects\cpython\lib\ctypes\test\test_pep3118.py", line 56, in test_native_types
    normalize(replace_type_codes(fmt)))
AssertionError: '<l' != '<i'
- <l
+ <i

Added explanatory comment in the test.

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.
All reactions
Comment thread Modules/_ctypes/_ctypes.c Outdated

@pitrou pitrou Jun 6, 2017

Copy link
Copy Markdown
Member

There was a problem hiding this comment.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be nice to add a non-empty error message, for example "SIZEOF_INT is not one of the expected values".

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.
All reactions
Comment thread Modules/_ctypes/_ctypes.c Outdated

@pitrou pitrou Jun 6, 2017

Copy link
Copy Markdown
Member

There was a problem hiding this comment.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ditto.

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.
All reactions
Comment thread Modules/_ctypes/_ctypes.c Outdated

@pitrou pitrou Jun 6, 2017

Copy link
Copy Markdown
Member

There was a problem hiding this comment.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ditto.

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.
All reactions
@pv

pv commented Jun 22, 2017

Copy link
Copy Markdown
Contributor Author

Sorry for the delay, updated the PR based on comments.
All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.
@pv
pv force-pushed the bpo-10746 branch 2 times, most recently from d43d02d to eed2ee1 Compare June 22, 2017 23:02
@pv
pv force-pushed the bpo-10746 branch from eed2ee1 to 54f9123 Compare July 28, 2017 23:27
@pv
pv force-pushed the bpo-10746 branch from 54f9123 to b3435a0 Compare August 26, 2017 06:42
@pv

pv commented Aug 26, 2017

Copy link
Copy Markdown
Contributor Author

ping?
All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.
@pitrou

pitrou commented Aug 26, 2017

Copy link
Copy Markdown
Member

Sorry for the delay.
All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.
pitrou
pitrou reviewed Aug 26, 2017
View reviewed changes
Comment thread Lib/ctypes/test/test_pep3118.py Outdated

@pitrou pitrou Aug 26, 2017

Copy link
Copy Markdown
Member

There was a problem hiding this comment.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I still find this difficult to read and understand. Can't you rewrite the unit tests and the native_types array to get rid of the double indirection?

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.
All reactions
pitrou
pitrou reviewed Aug 26, 2017
View reviewed changes
Comment thread Lib/ctypes/test/test_pep3118.py Outdated

@pitrou pitrou Aug 26, 2017

Copy link
Copy Markdown
Member

There was a problem hiding this comment.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Internal ctypes type codes are not even documented, are they?

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.
All reactions
@pitrou

pitrou commented Aug 26, 2017

Copy link
Copy Markdown
Member

Thanks for persisting. I am not really happy about the way this hacks around the current structure of the tests. It adds a lot of complication that seems pointless given the task at hand (we're just checking a mapping, right?).
All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.
@pv

pv commented Aug 26, 2017 via email

Copy link
Copy Markdown
Contributor Author
A static translation table does not exist, because the size of the types, and also which type code is produced for some of the integer types when multiple equivalent possibilities exist, is platform and possibly compiler dependent. If you are suggesting to write all possibilities explicitly, you have to write different tables for win32, win64, linux32, etc. Can you specify more precisely what you object to: - using replace in strings to produce appropriate codes rather than writing them explicitly, - not hardcoding codes for equivalent integer types, - something else? 26.8.2017 11.04 "Antoine Pitrou" <[email protected]> kirjoitti:
…
Thanks for persisting. I am not really happy about the way this hacks around the current structure of the tests. It adds a lot of complication that seems pointless given the task at hand (we're just checking a mapping, right?). — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#31 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AACI5qKVqObam9UqEqb2IfRqEGfrycROks5sb9-AgaJpZM4L-Rci> .
All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.
@pv

pv commented Aug 26, 2017 via email

Copy link
Copy Markdown
Contributor Author
The internal types codes are not documented. But do you have better suggestions how to write the strings? They cannot be written in PEP3118 format because the produced strings are platform etc dependent. 26.8.2017 11.04 "Antoine Pitrou" <[email protected]> kirjoitti:
…
Thanks for persisting. I am not really happy about the way this hacks around the current structure of the tests. It adds a lot of complication that seems pointless given the task at hand (we're just checking a mapping, right?). — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#31 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AACI5qKVqObam9UqEqb2IfRqEGfrycROks5sb9-AgaJpZM4L-Rci> .
All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.
@pv

pv commented Aug 26, 2017 via email

Copy link
Copy Markdown
Contributor Author
This of course was ignored previously in the tests, because the ctypes implementation of this stuff was just wrong. 26.8.2017 11.37 "Pauli Virtanen" <[email protected]> kirjoitti: The internal types codes are not documented. But do you have better suggestions how to write the strings? They cannot be written in PEP3118 format because the produced strings are platform etc dependent. 26.8.2017 11.04 "Antoine Pitrou" <[email protected]> kirjoitti:
…
Thanks for persisting. I am not really happy about the way this hacks around the current structure of the tests. It adds a lot of complication that seems pointless given the task at hand (we're just checking a mapping, right?). — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#31 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AACI5qKVqObam9UqEqb2IfRqEGfrycROks5sb9-AgaJpZM4L-Rci> .
All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.
@pitrou

pitrou commented Aug 26, 2017

Copy link
Copy Markdown
Member

My main gripe here is that you shouldn't need code_map at all, let alone the complicated double indirection inside that table. Just add/replace whatever information is missing to native_types.

Also we don't care at all about ctypes internal code types, so the tests would be clearer if they didn't involve them.
All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.
@pv

pv commented Aug 26, 2017 via email

Copy link
Copy Markdown
Contributor Author
The expected pep strings are platform-dependent. Do you agree with that statement? Do you mean the entries in the native_types table should be translate_typecodes("...") calls in the table itself. Or, do you mean code_map should be replaced by a slew of if statemebts encoding the platform dependence? 26.8.2017 19.49 "Antoine Pitrou" <[email protected]> kirjoitti:
…
My main gripe here is that you shouldn't need code_map at all, let alone the complicated double indirection inside that table. Just add/replace whatever information is missing to native_types. Also we don't care at all about ctypes internal code types, so the tests would be clearer if they didn't involve them. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#31 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AACI5i6dyAcsuUqZDCKqIIkcgKtizybgks5scEyagaJpZM4L-Rci> .
All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.
@pv

pv commented Aug 26, 2017 via email

Copy link
Copy Markdown
Contributor Author
I think I need railroad track now :) Could you give an example how you would like the test for the pep3118 format string for c_long to look like? 26.8.2017 20.08 "Pauli Virtanen" <[email protected]> kirjoitti: The expected pep strings are platform-dependent. Do you agree with that statement? Do you mean the entries in the native_types table should be translate_typecodes("...") calls in the table itself. Or, do you mean code_map should be replaced by a slew of if statemebts encoding the platform dependence? 26.8.2017 19.49 "Antoine Pitrou" <[email protected]> kirjoitti:
…
My main gripe here is that you shouldn't need code_map at all, let alone the complicated double indirection inside that table. Just add/replace whatever information is missing to native_types. Also we don't care at all about ctypes internal code types, so the tests would be clearer if they didn't involve them. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#31 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AACI5i6dyAcsuUqZDCKqIIkcgKtizybgks5scEyagaJpZM4L-Rci> .
All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.
@pitrou

pitrou commented Aug 26, 2017

Copy link
Copy Markdown
Member

You are already encoding platform-dependent information (the size mappings) in code_map? Why don't you fold that into native_types?
All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.
@pv

pv commented Aug 26, 2017 via email •
edited
Loading

Uh oh!

There was an error while loading. Please reload this page.

Copy link
Copy Markdown
Contributor Author
native_types and the other tables contain also compound types where these type codes appear. To me the present approach appeared the simplest solution without code repetition. 26.8.2017 20.13 "Pauli Virtanen" <[email protected]> kirjoitti:
…
I think I need railroad track now :) Could you give an example how you would like the test for the pep3118 format string for c_long to look like? 26.8.2017 20.08 "Pauli Virtanen" ***@***.***> kirjoitti: The expected pep strings are platform-dependent. Do you agree with that statement? Do you mean the entries in the native_types table should be translate_typecodes("...") calls in the table itself. Or, do you mean code_map should be replaced by a slew of if statemebts encoding the platform dependence? 26.8.2017 19.49 "Antoine Pitrou" ***@***.***> kirjoitti: > My main gripe here is that you shouldn't need code_map at all, let alone > the complicated double indirection inside that table. Just add/replace > whatever information is missing to native_types. > > Also we don't care at all about ctypes internal code types, so the tests > would be clearer if they didn't involve them. > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > <#31 (comment)>, or mute > the thread > <https://github.com/notifications/unsubscribe-auth/AACI5i6dyAcsuUqZDCKqIIkcgKtizybgks5scEyagaJpZM4L-Rci> > . >
All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.
@pv
pv force-pushed the bpo-10746 branch from f9bf424 to 179b1de Compare August 26, 2017 21:24
@pv

pv commented Aug 26, 2017

Copy link
Copy Markdown
Contributor Author

Ok, once more then, without magic. Is this what you wanted?
All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.
@pitrou

pitrou commented Aug 28, 2017

Copy link
Copy Markdown
Member

Thank you! :-) I find this much better. In particular, it's explicit that the exact type code does not depend only on the type size but also on whether c_int aliases c_long, for example (which is a weird oddity, but I guess it's not this PR's responsability to change that).

One additional thing: can you add a NEWS entry? We nowadays use the blurb CLI tool for that.
All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.
pitrou
pitrou approved these changes Aug 28, 2017
View reviewed changes
@bedevere-bot bedevere-bot added the awaiting merge label Aug 28, 2017
@eric-wieser eric-wieser mentioned this pull request Sep 2, 2017
dtype and struct integer format characters are deceptively similar, yet different numpy/numpy#9642
Open
pitrou pushed a commit that referenced this pull request Sep 2, 2017
@pv @pitrou
[2.7] bpo-10746: Fix ctypes PEP 3118 type codes for c_long, c_bool, c…
990b2d0 
…_int (GH-31) (#3242)

[2.7] bpo-10746: Fix ctypes PEP 3118 type codes for c_long, c_bool, c_int (GH-31)

Ctypes currently produces wrong pep3118 type codes for several types.
E.g. memoryview(ctypes.c_long()).format gives "<l" on 64-bit platforms,
but it should be "<q" instead for sizeof(c_long) == 8

The problem is that the '<>' endian specification in the struct syntax
also turns on the "standard size" mode, which makes type characters have
a platform-independent meaning, which does not match with the codes used
internally in ctypes.  The struct module format syntax also does not
allow specifying native-size non-native-endian items.

This commit adds a converter function that maps the internal ctypes
codes to appropriate struct module standard-size codes in the pep3118
format strings. The tests are modified to check for this..
(cherry picked from commit 07f1658)
GadgetSteve pushed a commit to GadgetSteve/cpython that referenced this pull request Sep 10, 2017
@pv @GadgetSteve
bpo-10746: Fix ctypes PEP 3118 type codes for c_long, c_bool, c_int (p…
a774b66 
…ython#31)

Ctypes currently produces wrong pep3118 type codes for several types.
E.g. memoryview(ctypes.c_long()).format gives "<l" on 64-bit platforms,
but it should be "<q" instead for sizeof(c_long) == 8

The problem is that the '<>' endian specification in the struct syntax
also turns on the "standard size" mode, which makes type characters have
a platform-independent meaning, which does not match with the codes used
internally in ctypes.  The struct module format syntax also does not
allow specifying native-size non-native-endian items.

This commit adds a converter function that maps the internal ctypes
codes to appropriate struct module standard-size codes in the pep3118
format strings. The tests are modified to check for this.
@eric-wieser eric-wieser mentioned this pull request May 24, 2018
BUG: gh-10882 may have broken ctypes compatibility in older versions of python numpy/numpy#11150
Closed
@mdboom mdboom mentioned this pull request Aug 25, 2022
Assert and incorrect error message when loading source file containing invalid UTF-8 #96268
Closed
@ziegenbalg ziegenbalg mentioned this pull request Nov 30, 2022
double free in io.TextIOWrapper #72573
Closed
jaraco pushed a commit that referenced this pull request Dec 2, 2022
@Mariatta
Check if payload contains "committer" info. (GH-31)
70317f4 
There were cases where data["commit"]["committer"] is null.
jaraco pushed a commit to jaraco/cpython that referenced this pull request Feb 17, 2023
@warsaw
Support text open(), though not by default (python#32)
8475c05 
Closes python#31
Fidget-Spinner referenced this pull request in pylbbv/pylbbv May 27, 2023
@JuliaPoo
Fix: BB_TEST_ITER wrong type propagation (#31)
66143f9
nanjekyejoannah added a commit to nanjekyejoannah/cpython that referenced this pull request Jul 28, 2023
@bors @nanjekyejoannah
Merge python#31
d888130 
31: Only warn in file init r=ltratt a=nanjekyejoannah

Fixes python#29 

Co-authored-by: Joannah Nanjekye <[email protected]>
@gvanrossum gvanrossum mentioned this pull request Aug 22, 2023
heap-use-after-free in _PyFunction_LookupByVersion #108253
Closed
@LinanV LinanV mentioned this pull request Oct 23, 2023
Objects/typeobject.c: No such file or directory. #111203
Closed
@stasos24 stasos24 mentioned this pull request Oct 24, 2023
Modules/cjkcodecs/_codecs_iso2022.c - read out of bounds #101180
Closed
@williamhu020 williamhu020 mentioned this pull request Nov 5, 2023
Use the API C of 'Py-NewInterpreterFromConfig' to exit unexpectedly in multiple threads. #111751
Closed
@kcatss kcatss mentioned this pull request Nov 15, 2023
Use-after-free in unregister() of atexit module #112127
Closed
@kcatss kcatss mentioned this pull request Jan 14, 2024
crash in long_vectorcall in longobject.c #114050
Closed
@kcatss kcatss mentioned this pull request Feb 20, 2024
Use After Free at _heapreplace_max #115706
Closed
@ngoldbaum ngoldbaum mentioned this pull request Sep 23, 2024
Crash running PyO3 tests with --test-threads=1000 #124375
Closed
This was referenced Feb 11, 2025
segmentfault when pip installing setuptools #129992
Closed
segmentfault when pip installing setuptools #129993
Closed
@DominiquePACCO DominiquePACCO mentioned this pull request Jun 3, 2025
PdfWriter add_page adds (re)writes old page instead of new #135062
Closed
@StanFromIreland StanFromIreland mentioned this pull request Oct 29, 2025
gh-129117: Expose _PyUnicode_IsXidContinue/Start in unicodedata #140269
Merged
@efimov-mikhail efimov-mikhail mentioned this pull request Nov 5, 2025
memory leak in threading stack size #141044
Open
picnixz added a commit to picnixz/cpython that referenced this pull request Dec 8, 2025
@picnixz
Fix and improve Objects/lazyimportobject.c (python#31)
023f806 
* re-order imports

* simplify static type definition

* fix undefined behaviors

* reject keyword arguments for `lazy_import`
@sergey-miryanov sergey-miryanov mentioned this pull request Dec 18, 2025
Observed memory leak in ssl library: Python 3.14 GC issue #142516
Closed
@Qanux Qanux mentioned this pull request Feb 11, 2026
heap-buffer-overflow in functools.partial.__repr__() #144475
Closed
@ngoldbaum ngoldbaum mentioned this pull request Mar 6, 2026
Remove deprecated and undocumented function ctypes.SetPointerType #133866
Closed
@johng johng mentioned this pull request Jul 19, 2026
use-after-free: functools partial #154189
Closed
@djarfluka djarfluka mentioned this pull request Sep 12, 2026
Heap UAF in io.TextIOWrapper read path via reentrant detach() #157363
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@pitrou pitrou pitrou approved these changes

Uh oh!

There was an error while loading. Please reload this page.

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

Uh oh!

There was an error while loading. Please reload this page.

6 participants

@pv @the-knights-who-say-ni @pitrou @Mariatta @zware @bedevere-bot
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
You are visitor 01402503 — GeezerVison does not store the pages you look up.
Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.