Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Use Sphinx 1.4.9 for now #15

Closed
wants to merge 1 commit into from
Closed

Use Sphinx 1.4.9 for now #15

wants to merge 1 commit into from

Conversation

methane
Copy link
Member

@methane methane commented Feb 11, 2017

Sphinx 1.5 is more strict.
We should fix them before using Sphinx 1.5 on Travis.

@methane
Copy link
Member Author

methane commented Feb 11, 2017

test failed even with sphinx-1.4.9
#16 may fix it.

@methane methane closed this Feb 11, 2017
@methane methane deleted the sphinx-1.4 branch February 11, 2017 02:33
paulmon added a commit to paulmon/cpython that referenced this pull request Jan 10, 2019
@paulmon
Merge pull request python#15 from paulmon/win-arm32-fix-tests
abaaa92 
Win arm32 fix tests
gnprice added a commit to gnprice/cpython that referenced this pull request Aug 28, 2019
@gnprice
wip Fully implement the UAX python#15 quick-check algorithm.
322e702 
TODO:
 - news etc.?
 - test somehow?  at least make sure semantic tests are adequate
 - that "older version" path... shouldn't it be MAYBE?
 - mention explicitly in commit message that *this* is the actual
   algorithm from UAX python#15
 - think if there are counter-cases where this is slower.
   If caller treats MAYBE same as NO... e.g. if caller actually just
   wants to normalize?  May need to parametrize and offer both behaviors.

This lets us return a NO answer instead of MAYBE when that's what a
Quick_Check property tells us; or also when that's what the canonical
combining classes tell us, after a Quick_Check property has said "maybe".

At a quick test on my laptop, the existing code takes about 6.7 ms/MB
(so 6.7 ns per byte) when the quick check returns MAYBE and it has to
do the slow comparison:

  $ ./python -m timeit -s 'import unicodedata; s = "\uf900"*500000' -- \
      'unicodedata.is_normalized("NFD", s)'
  50 loops, best of 5: 6.67 msec per loop

With this patch, it gets the answer instantly (78 ns) on the same 1 MB
string:

  $ ./python -m timeit -s 'import unicodedata; s = "\uf900"*500000' -- \
      'unicodedata.is_normalized("NFD", s)'
  5000000 loops, best of 5: 78 nsec per loop
gnprice added a commit to gnprice/cpython that referenced this pull request Aug 28, 2019
@gnprice
bpo-37966: Fully implement the UAX python#15 quick-check algorithm.
2a222da 
The purpose of the `unicodedata.is_normalized` function is to answer
the question `str == unicodedata.normalized(form, str)` more
efficiently than writing just that, by using the "quick check"
optimization described in the Unicode standard in UAX python#15.

However, it turns out the code doesn't implement the full algorithm
from the standard, and as a result we often miss the optimization and
end up having to compute the whole normalized string after all.

Implement the standard's algorithm.  This greatly speeds up
`unicodedata.is_normalized` in many cases where our partial variant
of quick-check had been returning MAYBE and the standard algorithm
returns NO.

At a quick test on my desktop, the existing code takes about 4.4 ms/MB
(so 4.4 ns per byte) when the partial quick-check returns MAYBE and it
has to do the slow normalize-and-compare:

  $ build.base/python -m timeit -s 'import unicodedata; s = "\uf900"*500000' \
      -- 'unicodedata.is_normalized("NFD", s)'
  50 loops, best of 5: 4.39 msec per loop

With this patch, it gets the answer instantly (58 ns) on the same 1 MB
string:

  $ build.dev/python -m timeit -s 'import unicodedata; s = "\uf900"*500000' \
      -- 'unicodedata.is_normalized("NFD", s)'
  5000000 loops, best of 5: 58.2 nsec per loop
@gnprice gnprice mentioned this pull request Aug 28, 2019
Merged
gnprice added a commit to gnprice/cpython that referenced this pull request Aug 29, 2019
@gnprice
Move UAX python#15 link to doc-comment.
27e8122
@miss-islington miss-islington mentioned this pull request Sep 4, 2019
Merged
benjaminp pushed a commit that referenced this pull request Sep 4, 2019
@gnprice @benjaminp
closes bpo-37966: Fully implement the UAX #15 quick-check algorithm. (G…
2f09413 
…H-15558)

The purpose of the `unicodedata.is_normalized` function is to answer
the question `str == unicodedata.normalized(form, str)` more
efficiently than writing just that, by using the "quick check"
optimization described in the Unicode standard in UAX #15.

However, it turns out the code doesn't implement the full algorithm
from the standard, and as a result we often miss the optimization and
end up having to compute the whole normalized string after all.

Implement the standard's algorithm.  This greatly speeds up
`unicodedata.is_normalized` in many cases where our partial variant
of quick-check had been returning MAYBE and the standard algorithm
returns NO.

At a quick test on my desktop, the existing code takes about 4.4 ms/MB
(so 4.4 ns per byte) when the partial quick-check returns MAYBE and it
has to do the slow normalize-and-compare:

  $ build.base/python -m timeit -s 'import unicodedata; s = "\uf900"*500000' \
      -- 'unicodedata.is_normalized("NFD", s)'
  50 loops, best of 5: 4.39 msec per loop

With this patch, it gets the answer instantly (58 ns) on the same 1 MB
string:

  $ build.dev/python -m timeit -s 'import unicodedata; s = "\uf900"*500000' \
      -- 'unicodedata.is_normalized("NFD", s)'
  5000000 loops, best of 5: 58.2 nsec per loop

This restores a small optimization that the original version of this
code had for the `unicodedata.normalize` use case.

With this, that case is actually faster than in master!

$ build.base/python -m timeit -s 'import unicodedata; s = "\u0338"*500000' \
    -- 'unicodedata.normalize("NFD", s)'
500 loops, best of 5: 561 usec per loop

$ build.dev/python -m timeit -s 'import unicodedata; s = "\u0338"*500000' \
    -- 'unicodedata.normalize("NFD", s)'
500 loops, best of 5: 512 usec per loop
miss-islington pushed a commit to miss-islington/cpython that referenced this pull request Sep 4, 2019
@gnprice @miss-islington
closes bpo-37966: Fully implement the UAX pythonGH-15 quick-check alg…
f0f0d46 
…orithm. (pythonGH-15558)

The purpose of the `unicodedata.is_normalized` function is to answer
the question `str == unicodedata.normalized(form, str)` more
efficiently than writing just that, by using the "quick check"
optimization described in the Unicode standard in UAX pythonGH-15.

However, it turns out the code doesn't implement the full algorithm
from the standard, and as a result we often miss the optimization and
end up having to compute the whole normalized string after all.

Implement the standard's algorithm.  This greatly speeds up
`unicodedata.is_normalized` in many cases where our partial variant
of quick-check had been returning MAYBE and the standard algorithm
returns NO.

At a quick test on my desktop, the existing code takes about 4.4 ms/MB
(so 4.4 ns per byte) when the partial quick-check returns MAYBE and it
has to do the slow normalize-and-compare:

  $ build.base/python -m timeit -s 'import unicodedata; s = "\uf900"*500000' \
      -- 'unicodedata.is_normalized("NFD", s)'
  50 loops, best of 5: 4.39 msec per loop

With this patch, it gets the answer instantly (58 ns) on the same 1 MB
string:

  $ build.dev/python -m timeit -s 'import unicodedata; s = "\uf900"*500000' \
      -- 'unicodedata.is_normalized("NFD", s)'
  5000000 loops, best of 5: 58.2 nsec per loop

This restores a small optimization that the original version of this
code had for the `unicodedata.normalize` use case.

With this, that case is actually faster than in master!

$ build.base/python -m timeit -s 'import unicodedata; s = "\u0338"*500000' \
    -- 'unicodedata.normalize("NFD", s)'
500 loops, best of 5: 561 usec per loop

$ build.dev/python -m timeit -s 'import unicodedata; s = "\u0338"*500000' \
    -- 'unicodedata.normalize("NFD", s)'
500 loops, best of 5: 512 usec per loop
(cherry picked from commit 2f09413)

Co-authored-by: Greg Price <gnprice@gmail.com>
miss-islington added a commit that referenced this pull request Sep 4, 2019
@miss-islington @gnprice
closes bpo-37966: Fully implement the UAX GH-15 quick-check algorithm. (
4dd1c9d 
GH-15558)

The purpose of the `unicodedata.is_normalized` function is to answer
the question `str == unicodedata.normalized(form, str)` more
efficiently than writing just that, by using the "quick check"
optimization described in the Unicode standard in UAX GH-15.

However, it turns out the code doesn't implement the full algorithm
from the standard, and as a result we often miss the optimization and
end up having to compute the whole normalized string after all.

Implement the standard's algorithm.  This greatly speeds up
`unicodedata.is_normalized` in many cases where our partial variant
of quick-check had been returning MAYBE and the standard algorithm
returns NO.

At a quick test on my desktop, the existing code takes about 4.4 ms/MB
(so 4.4 ns per byte) when the partial quick-check returns MAYBE and it
has to do the slow normalize-and-compare:

  $ build.base/python -m timeit -s 'import unicodedata; s = "\uf900"*500000' \
      -- 'unicodedata.is_normalized("NFD", s)'
  50 loops, best of 5: 4.39 msec per loop

With this patch, it gets the answer instantly (58 ns) on the same 1 MB
string:

  $ build.dev/python -m timeit -s 'import unicodedata; s = "\uf900"*500000' \
      -- 'unicodedata.is_normalized("NFD", s)'
  5000000 loops, best of 5: 58.2 nsec per loop

This restores a small optimization that the original version of this
code had for the `unicodedata.normalize` use case.

With this, that case is actually faster than in master!

$ build.base/python -m timeit -s 'import unicodedata; s = "\u0338"*500000' \
    -- 'unicodedata.normalize("NFD", s)'
500 loops, best of 5: 561 usec per loop

$ build.dev/python -m timeit -s 'import unicodedata; s = "\u0338"*500000' \
    -- 'unicodedata.normalize("NFD", s)'
500 loops, best of 5: 512 usec per loop
(cherry picked from commit 2f09413)

Co-authored-by: Greg Price <gnprice@gmail.com>
lisroach pushed a commit to lisroach/cpython that referenced this pull request Sep 10, 2019
@gnprice @lisroach
closes bpo-37966: Fully implement the UAX python#15 quick-check algor…
1660824 
…ithm. (pythonGH-15558)

The purpose of the `unicodedata.is_normalized` function is to answer
the question `str == unicodedata.normalized(form, str)` more
efficiently than writing just that, by using the "quick check"
optimization described in the Unicode standard in UAX python#15.

However, it turns out the code doesn't implement the full algorithm
from the standard, and as a result we often miss the optimization and
end up having to compute the whole normalized string after all.

Implement the standard's algorithm.  This greatly speeds up
`unicodedata.is_normalized` in many cases where our partial variant
of quick-check had been returning MAYBE and the standard algorithm
returns NO.

At a quick test on my desktop, the existing code takes about 4.4 ms/MB
(so 4.4 ns per byte) when the partial quick-check returns MAYBE and it
has to do the slow normalize-and-compare:

  $ build.base/python -m timeit -s 'import unicodedata; s = "\uf900"*500000' \
      -- 'unicodedata.is_normalized("NFD", s)'
  50 loops, best of 5: 4.39 msec per loop

With this patch, it gets the answer instantly (58 ns) on the same 1 MB
string:

  $ build.dev/python -m timeit -s 'import unicodedata; s = "\uf900"*500000' \
      -- 'unicodedata.is_normalized("NFD", s)'
  5000000 loops, best of 5: 58.2 nsec per loop

This restores a small optimization that the original version of this
code had for the `unicodedata.normalize` use case.

With this, that case is actually faster than in master!

$ build.base/python -m timeit -s 'import unicodedata; s = "\u0338"*500000' \
    -- 'unicodedata.normalize("NFD", s)'
500 loops, best of 5: 561 usec per loop

$ build.dev/python -m timeit -s 'import unicodedata; s = "\u0338"*500000' \
    -- 'unicodedata.normalize("NFD", s)'
500 loops, best of 5: 512 usec per loop
DinoV pushed a commit to DinoV/cpython that referenced this pull request Jan 14, 2020
@gnprice @DinoV
closes bpo-37966: Fully implement the UAX python#15 quick-check algor…
a5375af 
…ithm. (pythonGH-15558)

The purpose of the `unicodedata.is_normalized` function is to answer
the question `str == unicodedata.normalized(form, str)` more
efficiently than writing just that, by using the "quick check"
optimization described in the Unicode standard in UAX python#15.

However, it turns out the code doesn't implement the full algorithm
from the standard, and as a result we often miss the optimization and
end up having to compute the whole normalized string after all.

Implement the standard's algorithm.  This greatly speeds up
`unicodedata.is_normalized` in many cases where our partial variant
of quick-check had been returning MAYBE and the standard algorithm
returns NO.

At a quick test on my desktop, the existing code takes about 4.4 ms/MB
(so 4.4 ns per byte) when the partial quick-check returns MAYBE and it
has to do the slow normalize-and-compare:

  $ build.base/python -m timeit -s 'import unicodedata; s = "\uf900"*500000' \
      -- 'unicodedata.is_normalized("NFD", s)'
  50 loops, best of 5: 4.39 msec per loop

With this patch, it gets the answer instantly (58 ns) on the same 1 MB
string:

  $ build.dev/python -m timeit -s 'import unicodedata; s = "\uf900"*500000' \
      -- 'unicodedata.is_normalized("NFD", s)'
  5000000 loops, best of 5: 58.2 nsec per loop

This restores a small optimization that the original version of this
code had for the `unicodedata.normalize` use case.

With this, that case is actually faster than in master!

$ build.base/python -m timeit -s 'import unicodedata; s = "\u0338"*500000' \
    -- 'unicodedata.normalize("NFD", s)'
500 loops, best of 5: 561 usec per loop

$ build.dev/python -m timeit -s 'import unicodedata; s = "\u0338"*500000' \
    -- 'unicodedata.normalize("NFD", s)'
500 loops, best of 5: 512 usec per loop
ethanhs added a commit to ethanhs/cpython that referenced this pull request Mar 16, 2020
@ethanhs
Make __parameters__ lazy (python#15)
e50136d 
Now we can also remove `__setstate__`.
@pablogsal pablogsal mentioned this pull request Jun 12, 2020
Closed
@shihai1991 shihai1991 mentioned this pull request Jun 23, 2020
Closed
websurfer5 pushed a commit to websurfer5/cpython that referenced this pull request Jul 20, 2020
@gnprice @websurfer5
closes bpo-37966: Fully implement the UAX python#15 quick-check algor…
cb61233 
…ithm. (pythonGH-15558)

The purpose of the `unicodedata.is_normalized` function is to answer
the question `str == unicodedata.normalized(form, str)` more
efficiently than writing just that, by using the "quick check"
optimization described in the Unicode standard in UAX python#15.

However, it turns out the code doesn't implement the full algorithm
from the standard, and as a result we often miss the optimization and
end up having to compute the whole normalized string after all.

Implement the standard's algorithm.  This greatly speeds up
`unicodedata.is_normalized` in many cases where our partial variant
of quick-check had been returning MAYBE and the standard algorithm
returns NO.

At a quick test on my desktop, the existing code takes about 4.4 ms/MB
(so 4.4 ns per byte) when the partial quick-check returns MAYBE and it
has to do the slow normalize-and-compare:

  $ build.base/python -m timeit -s 'import unicodedata; s = "\uf900"*500000' \
      -- 'unicodedata.is_normalized("NFD", s)'
  50 loops, best of 5: 4.39 msec per loop

With this patch, it gets the answer instantly (58 ns) on the same 1 MB
string:

  $ build.dev/python -m timeit -s 'import unicodedata; s = "\uf900"*500000' \
      -- 'unicodedata.is_normalized("NFD", s)'
  5000000 loops, best of 5: 58.2 nsec per loop

This restores a small optimization that the original version of this
code had for the `unicodedata.normalize` use case.

With this, that case is actually faster than in master!

$ build.base/python -m timeit -s 'import unicodedata; s = "\u0338"*500000' \
    -- 'unicodedata.normalize("NFD", s)'
500 loops, best of 5: 561 usec per loop

$ build.dev/python -m timeit -s 'import unicodedata; s = "\u0338"*500000' \
    -- 'unicodedata.normalize("NFD", s)'
500 loops, best of 5: 512 usec per loop
@larryhastings larryhastings mentioned this pull request Jun 7, 2022
Closed
@itachaaa itachaaa mentioned this pull request Aug 22, 2022
Open
@mdboom mdboom mentioned this pull request Aug 25, 2022
Closed
@mdboom mdboom mentioned this pull request Nov 22, 2022
Closed
@ziegenbalg ziegenbalg mentioned this pull request Nov 30, 2022
Closed
nanjekyejoannah added a commit to nanjekyejoannah/cpython that referenced this pull request Dec 1, 2022
@bors @nanjekyejoannah
Merge python#16
b1a20bf 
16: Warn for specific thread module methods r=ltratt a=nanjekyejoannah

Dont merge until python#13  and  python#14 are merged, some helper code cuts across.

This replaces python#15 

Threading module Notes

Python 2:

```
>>> from thread import get_ident
>>> from threading import get_ident
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: cannot import name get_ident
>>> import threading
>>> from threading import _get_ident
>>>
```

Python 3:

```
>>> from threading import get_ident
>>> from thread import get_ident
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ModuleNotFoundError: No module named 'thread'
>
```

**Note:**

There is no neutral way of porting

Co-authored-by: Joannah Nanjekye <jnanjekye@python.org>
@gvanrossum gvanrossum mentioned this pull request Aug 22, 2023
Closed
@LinanV LinanV mentioned this pull request Oct 23, 2023
Closed
@stasos24 stasos24 mentioned this pull request Oct 24, 2023
Closed
@williamhu020 williamhu020 mentioned this pull request Nov 5, 2023
Closed
@kcatss kcatss mentioned this pull request Nov 15, 2023
Open
@kcatss kcatss mentioned this pull request Jan 14, 2024
Closed
@kcatss kcatss mentioned this pull request Feb 12, 2024
Closed
@kcatss kcatss mentioned this pull request Feb 20, 2024
Closed
@ngoldbaum ngoldbaum mentioned this pull request Sep 23, 2024
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@vstinner vstinner vstinner approved these changes

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@methane @vstinner @the-knights-who-say-ni