[issue28723] tkinter, radiobutton, indicatoron=0 has no effect.

[Simon Holland]

Changes by Simon Holland :


--
nosy: +gpolo, serhiy.storchaka

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18235] _sysconfigdata.py wrong on AIX installations

[Michael Felt]

Michael Felt added the comment:

FYI: after manually creating the .../libpython3.5/config directory and copying 
three files (see below) I was able to "pip3 install cython" as test.

 At the packing area:
michael@x071:[/data/prj/python3/python3-3.5.2]ls Xany/opt/lib/python3.5/config
ld_so_aix   makexp_aix  python.exp

in the package:
michael@x071:[/data/prj/python3/python3-3.5.2]restore -Tqf installp/ppc/*.I | 
grep lib/python3.5/config
New volume on installp/ppc/aixtools.python3.3.5.2.0.I:
Cluster size is 51200 bytes (100 blocks).
The volume number is 1.
The backup date is: Wed Nov 16 21:48:37 UTC 2016
Files are backed up by name.
The user is root.
./opt/lib/python3.5/config
./opt/lib/python3.5/config/ld_so_aix
./opt/lib/python3.5/config/python.exp
./opt/lib/python3.5/config/makexp_aix
./opt/lib/python3.5/configparser.py
./opt/lib/python3.5/config-3.5m
./opt/lib/python3.5/config-3.5m/libpython3.5m.a
./opt/lib/python3.5/config-3.5m/Setup
./opt/lib/python3.5/config-3.5m/python-config.py
./opt/lib/python3.5/config-3.5m/config.c
./opt/lib/python3.5/config-3.5m/Setup.local
./opt/lib/python3.5/config-3.5m/config.c.in
./opt/lib/python3.5/config-3.5m/makesetup
./opt/lib/python3.5/config-3.5m/Setup.config
./opt/lib/python3.5/config-3.5m/install-sh
./opt/lib/python3.5/config-3.5m/Makefile
./opt/lib/python3.5/config-3.5m/python.o
The number of archived files is 7390.

Results:

+-+
 Installing Software...
+-+

installp:  APPLYING software for:
aixtools.python3.rte 3.5.2.0

Restoring files, please wait.
4250 files restored.
Finished processing all filesets.  (Total time:  1 mins 1 secs).

+-+
Summaries:
+-+

Installation Summary

NameLevel   PartEvent   Result
---
aixtools.python3.rte3.5.2.0 USR APPLY   SUCCESS

root@x064:[/data/prj/python3/python3-3.5.2]export OBJECT_MODE=64

root@x064:[/data/prj/python3/python3-3.5.2]pip3 install cython
Collecting cython
  Using cached Cython-0.25.1.tar.gz
Installing collected packages: cython
  Running setup.py install for cython ... done
Successfully installed cython-0.25.1
You are using pip version 8.1.1, however version 9.0.1 is available.
You should consider upgrading via the 'pip install --upgrade pip' command.

Question: if there is a patch since 3.5.2 was released - how do I pick this up 
in order to test (and maybe patch)? I am a bit lost in the hg/git discussion 
about where to go to get current status.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28712] Non-Windows mappings for a couple of Windows code pages

[STINNER Victor]

STINNER Victor added the comment:

Windows API doc is not easy to understand. I wrote this doc when I fixed
code pages in Python 3:
http://unicodebook.readthedocs.io/operating_systems.html#windows

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28723] tkinter, radiobutton, indicatoron=0 has no effect.

[Simon Holland]

New submission from Simon Holland:

tkinters radiobutton's have an option 'indicatoron=0'  which should display 
Radio Buttons as actual labelled buttons.  

button = tk.Radiobutton(self, text=option, variable = var, value = answer, 
indicatoron=0)

Screenshots of expected and actual results ... http://imgur.com/a/2fI02

taken from ... 
http://stackoverflow.com/questions/34459221/tkinter-radiobutton-indicatoron-value-doesnt-effect-anything

Kkinter 8.5 descrbes the functionality as so : 
Normally a checkbutton displays as its indicator a box that shows whether the 
checkbutton is set or not. You can get this behavior by setting indic- 
atoron=1. However, if you set indicatoron=0, the indicator disappears, and the 
entire widget becomes a push-push button that looks raised when it is cleared 
and sunken when it is set. You may want to increase the bor- derwidth value to 
make it easier to see the state of such a control.

--
components: Tkinter
files: u1mdKuC.png
messages: 281022
nosy: Inyoka
priority: normal
severity: normal
status: open
title: tkinter, radiobutton, indicatoron=0 has no effect.
type: behavior
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file45517/u1mdKuC.png

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28670] PEP 235: Implement on every POSIX system, and clean up the C code for `import'

[Nick Coghlan]

Nick Coghlan added the comment:

Michael, you seem to be operating under the assumption that the fact that the 
CPython VM assumes by default that Linux systems use consistent filesystem 
semantics is an accidental oversight.

It's not - it's a pervasive simplifying assumption that runs throughout various 
parts of the interpreter design, mainly in the form of scoping various settings 
to "the machine" based on the detected operating system that are in reality 
specific to a particular filesystem within the machine.

That's the reason what you propose is a feature request for Python 2.7 rather 
than a bug fix - you've picked one particular instance of that general 
assumption and proposed not making it anymore.

However, you've also indicated that Python 3 (and hence presumably the 
`importlib2` backport of the Python 3 import system to Python 2) have already 
removed that assumption in this particular case.

Hence my suggestion to discuss your concerns with Linux distribution providers 
- if something has changed in the past few years to make them more concerned 
about it, and they aren't satisfied with resolving it through their current 
Python 3 migration efforts [1,2], the use of `importlib2`, or the use of other 
filesystem interface bindings (such as PyFilesystem, GObject introspection, or 
Qt), then that would make a difference in the disposition of the issue report.

[1] https://wiki.ubuntu.com/Python
[2] http://fedora.portingdb.xyz/

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28699] Imap from ThreadPool behaves unexpectedly

[Davin Potts]

Davin Potts added the comment:

Though it still lacks a proper test, I'm attaching a preliminary patch to 
address the problematic behavior in 3.5/3.6/default in the hopes that others 
might help test it.

--
keywords: +patch
Added file: 
http://bugs.python.org/file45516/issue_28699_lacks_test_but_check_unsorted_py3x.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28712] Non-Windows mappings for a couple of Windows code pages

[Eryk Sun]

Eryk Sun added the comment:

The ANSI and OEM codepages are conveniently supported on a Windows system as 
the encodings 'mbcs' and 'oem' (new in 3.6). The best-fit mapping is used by 
the 'replace' error handler (see the encode_code_page_flags function in 
Objects/unicodeobject.c). For other Windows codepages, while it's not as 
convenient, you can use codecs.code_page_encode. For example:

>>> codecs.code_page_encode(1252, 'α', 'replace')
(b'a', 1)

For decoding, MB_ERR_INVALID_CHARS has no effect on decoding single-byte 
codepages because they map every byte. It only affects decoding byte sequences 
that are invalid in multibyte codepages such as 932 and 65001. Without this 
flag, invalid sequences are silently decoded as the codepage's Unicode default 
character. This is usually "?", but for 932 it's Katakana middle dot (U+30FB), 
and for UTF-8 it's U+FFFD. codecs.code_page_decode uses MB_ERR_INVALID_CHARS 
almost always, except not for UTF-7 (see the decode_code_page_flags function). 
So its 'replace' error handling is completely Python's own implementation. For 
example:

MultiByteToWideChar without MB_ERR_INVALID_CHARS:

>>> decode(932, b'\xe05', strict=False)
'\u30fb'

versus code_page_decode:

>>> codecs.code_page_decode(932, b'\xe05', 'replace', True)
('\ufffd5', 2)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28718] '*' matches entire path in fnmatch.translate

[Josh Rosenberg]

Josh Rosenberg added the comment:

Oops, altsep is None, not the empty string when there is only one separator. 
And I didn't handle inverting the match. Sigh. You get the idea.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28718] '*' matches entire path in fnmatch.translate

[Josh Rosenberg]

Josh Rosenberg added the comment:

Presumably something like:

r'(?:' + r'|'.join({re.escape(os.path.sep), re.escape(os.path.altsep)}) + r')'

would cover it completely. I switched to using non-capturing groups over a 
character class both to deal with the fact that escaping doesn't work the same 
way for character classes and to cover the possibility (no idea here) that some 
terrible OS might have a multicharacter path separator.

--
nosy: +josh.r

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26072] pdb fails to access variables closed over

[Chun-Yu Tseng]

Chun-Yu Tseng added the comment:

Your solution is quite neat. 
But it still misses use cases of the `global` statement:

  1  y = 2
  2
  3  def f():
  4  y = 9
  5  -> import pdb; pdb.set_trace();
  6
  7  f()
(Pdb) global y; y
9
(Pdb) global y; y += 1; y
10
(Pdb) globals()['y']
2

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28722] doctest example exit status

[Rajiv Bakulesh Shah]

New submission from Rajiv Bakulesh Shah:

It might be nice if the doctest example set the appropriate exit status.  
Apologies if this is beyond the scope of the example, but I thought it might be 
good practice.

Here is the file:
https://github.com/python/cpython/blob/master/Doc/library/doctest.rst

Here is the example as written:
if __name__ == "__main__":
import doctest
doctest.testmod()

Here is my proposal:
if __name__ == '__main__':
import doctest
import sys
results = doctest.testmod()
sys.exit(bool(results.failed))

I'm happy to fork the repo and submit a PR, if that makes things easier.  I'm 
not familiar with the protocol here.  Thanks for the great work!

--
assignee: docs@python
components: Documentation
messages: 281015
nosy: Brainix, docs@python
priority: normal
severity: normal
status: open
title: doctest example exit status
versions: Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28712] Non-Windows mappings for a couple of Windows code pages

[Mingye Wang]

Mingye Wang added the comment:

> Codecs are strict by default in Python. Call MultiByteToWideChar() with the 
> MB_ERR_INVALID_CHARS flag as Python does.

Great catch. Without MB_ERR_INVALID_CHARS or WC_NO_BEST_FIT_CHARS Windows would 
perform the "best fit" behavior described in the BestFit files, which is not 
marked explicitly (they didn't add '<< Best Fit Mapping' like in the readme) in 
these files and requires checking for existence of reverse mapping[1]. When 
MB_ERR_INVALID_CHARS is set, Windows would perform a strict check.
  [2]: 
http://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WindowsBestFit/readme.txt

By the way, will there be a 'mbcsbestfitreplace' error handler on Windows to 
invoke "best fit" behavior? It might be useful for interoperating with common 
Windows programs and users. (Implementation for other platforms can be 
constructed from WindowsBestFit charts, but it might be too large relative to 
its usefulness.)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28720] Add collections.abc.AsyncGenerator

[Yury Selivanov]

Yury Selivanov added the comment:

Thanks Ned. I went ahead and committed the patch.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28721] Fix asynchronous generators athrow() and aclose() to handle StopAsyncIteration

[Yury Selivanov]

Changes by Yury Selivanov :


--
resolution:  -> fixed
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28720] Add collections.abc.AsyncGenerator

[Yury Selivanov]

Changes by Yury Selivanov :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28720] Add collections.abc.AsyncGenerator

[Roundup Robot]

Roundup Robot added the comment:

New changeset ae1dba7e7d04 by Yury Selivanov in branch '3.6':
Issue #28720: Add collections.abc.AsyncGenerator.
https://hg.python.org/cpython/rev/ae1dba7e7d04

New changeset fb9c8fdef3ec by Yury Selivanov in branch 'default':
Merge 3.6 (issue #28720)
https://hg.python.org/cpython/rev/fb9c8fdef3ec

--
nosy: +python-dev

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28717] rounding error in % operator

[William McIlhagga]

William McIlhagga added the comment:

Thanks, maybe I should get off my ass and contribute to the documentation
then ...

On 16 November 2016 at 22:30, Mark Dickinson  wrote:

>
> Mark Dickinson added the comment:
>
> > Is this behaviour documented? Or are you just expected to know what C
> does?
>
> Indeed, it's not as well documented as it should be. I think that's partly
> for historical reasons: before Python 2.7, Python's % formatting
> more-or-less delegated directly to the underlying C sprintf library
> function, and so just inherited whatever the behaviour of that function
> happened to be on the target operating system. Because the C standard
> doesn't make guarantees about the behaviour of %f for ties, Python wasn't
> in a position to do so either.
>
> But that excuse doesn't work any more with Python 2.7 and Python 3.x,
> where on most (but still not all) platforms, we're consistently rounding
> results using the usual round-ties-to-even rounding mode.
>
> There's a currently open issue (#17259) to improve the documentation here.
>
> --
>
> ___
> Python tracker 
> 
> ___
>

-- 
Dr. William McIlhagga
Bradford School of Optometry & Vision Science,
Bradford University
Great Horton Road
Bradford BD7 1DP
UK

Room G23, Richmond tel. (44) (1274) 235957

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28710] Sphinx incompatible markup in configparser.ConfigParser.

[Patrick Lehmann]

Patrick Lehmann added the comment:

Here is the patch file created with:
PS> git diff > docstring_markup.patch

This patchfile effects all files with this markup in the CPython repository.


Kind regards
Patrick

--
keywords: +patch
Added file: http://bugs.python.org/file45515/docstring_markup.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28721] Fix asynchronous generators athrow() and aclose() to handle StopAsyncIteration

[Roundup Robot]

Roundup Robot added the comment:

New changeset 0f12a1d3a737 by Yury Selivanov in branch '3.6':
Issue #28721: Fix asynchronous generators aclose() and athrow()
https://hg.python.org/cpython/rev/0f12a1d3a737

New changeset 22cd78026ad1 by Yury Selivanov in branch 'default':
Merge 3.6 (issue #28721)
https://hg.python.org/cpython/rev/22cd78026ad1

--
nosy: +python-dev

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28721] Fix asynchronous generators athrow() and aclose() to handle StopAsyncIteration

[Yury Selivanov]

New submission from Yury Selivanov:

1. aclose() should not propagate StopAsyncIteration:

  async def agen():
 try:
yield
 except: 
pass
  gen = agen()
  await agen.asend(None)
  await agen.aclose()  # <- this shouldn't raise StopAsyncIteration

2. athrow() should propagate StopAsyncIteration when the exception was 
swallowed by the generator and it returned:

  async def agen():
 try:
yield
 except: 
pass
  gen = agen()
  await agen.asend(None)
  await agen.athrow(ValueError)  # <- this should raise StopAsyncIteration

--
assignee: yselivanov
components: Interpreter Core
files: agen.patch
keywords: patch
messages: 281008
nosy: ned.deily, yselivanov
priority: release blocker
severity: normal
stage: commit review
status: open
title: Fix asynchronous generators athrow() and aclose() to handle 
StopAsyncIteration
type: behavior
versions: Python 3.6, Python 3.7
Added file: http://bugs.python.org/file45514/agen.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28710] Sphinx incompatible markup in configparser.ConfigParser.

[R. David Murray]

R. David Murray added the comment:

We will accept github pull requests in the future (the transition is underway).

For now, you can create a diff file (using hg diff by preference, but git diff 
will work) and uploaded it to the issue.  For this issue, please only upload 
the docstring changes.  For other enhancement suggestions, open separate 
issues.  (This would be true even if we were accepting pull requests).

The existing docstring markup is probably a remnant of the days when the 
documentation was written in LaTeX.

Lukasz Langa is the current maintainer of this module.

--
nosy: +lukasz.langa, r.david.murray

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28719] zipfile increase in size

[Bert JW Regeer]

Bert JW Regeer added the comment:

Here's a dump from Python 3.6:

b'PK\x03\x04\x14\x00\x08\x00\x00\x00\xc0~pI\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x10\x00\x00\x00zinfo_or_arcnamefoo!es\x8c\x03\x00\x00\x00\x03\x00\x00\x00PK\x01\x02\x14\x03\x14\x00\x08\x00\x00\x00\xc0~pI!es\x8c\x03\x00\x00\x00\x03\x00\x00\x00\x10\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x80\x01\x00\x00\x00\x00zinfo_or_arcnamePK\x05\x06\x00\x00\x00\x00\x01\x00\x01\x00>\x00\x00\x00=\x00\x00\x00\x00\x00'

You are correct that ResponseBodyFile does not have a seek() method and is not 
seekable. Adding seek() to ResponseBodyFile might be a little more 
complicated...

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28710] Sphinx incompatible markup in configparser.ConfigParser.

[Patrick Lehmann]

Patrick Lehmann added the comment:

How can I supply a fix?

I have a branch with lots of fixes.
https://github.com/Paebbels/cpython/tree/paebbels/issue-28710?ts=2

Why don't you accept pull requests via GitHub?


Kind regards
Patrick

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28719] zipfile increase in size

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Please make a dump. It should include not just literally the string written, 
but headers and other special fields.

I tried with rbo = io.BytesIO(), and get rbo.tell() == 133. Should be a 
difference between io.BytesIO and ResponseBodyFile. Maybe ResponseBodyFile is 
not seekable.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28720] Add collections.abc.AsyncGenerator

[Ned Deily]

Ned Deily added the comment:

OK for 3.6.0b4

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28717] rounding error in % operator

[Mark Dickinson]

Mark Dickinson added the comment:

> Is this behaviour documented? Or are you just expected to know what C does?

Indeed, it's not as well documented as it should be. I think that's partly for 
historical reasons: before Python 2.7, Python's % formatting more-or-less 
delegated directly to the underlying C sprintf library function, and so just 
inherited whatever the behaviour of that function happened to be on the target 
operating system. Because the C standard doesn't make guarantees about the 
behaviour of %f for ties, Python wasn't in a position to do so either.

But that excuse doesn't work any more with Python 2.7 and Python 3.x, where on 
most (but still not all) platforms, we're consistently rounding results using 
the usual round-ties-to-even rounding mode.

There's a currently open issue (#17259) to improve the documentation here.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28719] zipfile increase in size

[Bert JW Regeer]

Bert JW Regeer added the comment:

It's literally the string written:

writer.writestr('zinfo_or_arcname', b'foo')

rbo in this case is a simple file like object.

I can get dumps from Python 3.5 and Python 3.6 if necessary.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28719] zipfile increase in size

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Could you get a dump of rbo data?

--
nosy: +serhiy.storchaka

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28716] Fractions instantiation revisited

[Wolfgang Maier]

Wolfgang Maier added the comment:

No, I don't think the numeric tower ABC should be replaced by duck-typing. One 
of the very reasons the fractions module exists is that it showcases how to use 
the numeric tower. If you want a class to be picked up as a Rational it should 
be registered as such. Pretty much the same goes for integer-like things. The 
direct type check for ints only exists to speed up the most obvious case, but 
anything integer-like should be registered as a numbers.Integral and it will 
just work with fractions. Beautiful stuff!

This is not the case for as_integer_ratio because that method is not defined in 
the numeric tower and this is why I think duck-typing could be of interest here 
(I'm not sure though whether its worth the somewhat decreased performance). My 
reasoning is that the standard constructor is anyway slower for floats and ints 
than the specialized classmethods for the two so people who really care about 
speed here (probably not too many) can just use the classmethods.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28716] Fractions instantiation revisited

[Josh Rosenberg]

Josh Rosenberg added the comment:

Similarly, type checking for int might be replaced with calling operator.index 
on the input and handling the TypeError; that way, anything that has declared 
itself logically int-like is handled without explicit type checking at all.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28716] Fractions instantiation revisited

[Josh Rosenberg]

Josh Rosenberg added the comment:

Might it make sense to make instantiation from numbers.Rational duck typing 
based as well? Just try to get the numerator and denominator attributes, on 
AttributeError, skip it and move on. Unless there is some concern that a 
non-Rational type might have both attributes and not intend them to mean it's a 
Rational?

--
nosy: +josh.r

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28717] rounding error in % operator

[William McIlhagga]

William McIlhagga added the comment:

OK, not wrong, just unexpected.

Is this behaviour documented? Or are you just expected to know what C does?

On 16 November 2016 at 21:37, Mark Dickinson  wrote:

>
> Mark Dickinson added the comment:
>
> You don't say why you think this behaviour is wrong, or what you'd expect
> to see instead.
>
> Nevertheless, this behaviour is by design: the code `'%.1f' % x` rounds
> `x` to the nearest one-digit-after-the-point decimal number, and returns a
> string representation of that number. In the case `x=0.25`, there is no
> single nearest number: `0.2` and `0.3` are equally close to `0.25`, so a
> choice between the two has to be made. In keeping with many other
> languages, Python chooses the value with even last digit. (The original
> behaviour is inherited from the typical behaviour of the standard library
> strtod or dtoa functions in C.)
>
> --
> nosy: +mark.dickinson
> resolution:  -> not a bug
> stage:  -> resolved
> status: open -> closed
>
> ___
> Python tracker 
> 
> ___
>

-- 
Dr. William McIlhagga
Bradford School of Optometry & Vision Science,
Bradford University
Great Horton Road
Bradford BD7 1DP
UK

Room G23, Richmond tel. (44) (1274) 235957

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28716] Fractions instantiation revisited

[Wolfgang Maier]

Wolfgang Maier added the comment:

sure, I just happened to have the profiling available since I used it to 
optimize things. Here's similar microbenchmarks using perf:

STRINGS
===

$ python -m perf timeit -s "from fractions import Fraction" 
"Fraction('1.23456e-7')"
.
Median +- std dev: 17.0 us +- 0.3 us

$ python -m perf timeit -s "from frc import Fraction" "Fraction('1.23456e-7')"
.
Median +- std dev: 8.95 us +- 0.16 us


$ python -m perf timeit -s "from fractions import Fraction" 
"Fraction('234/567')"
.
Median +- std dev: 12.6 us +- 0.1 us

$ python -m perf timeit -s "from frc import Fraction" "Fraction('234/567')"
.
Median +- std dev: 5.45 us +- 0.16 us


$ python -m perf timeit -s "from fractions import Fraction" "Fraction('123456')"
.
Median +- std dev: 12.4 us +- 0.6 us

$ python -m perf timeit -s "from frc import Fraction" "Fraction('123456')"
.
Median +- std dev: 5.77 us +- 0.12 us


$ python -m perf timeit -s "from fractions import Fraction; f=Fraction(3/4)" 
"Fraction(f)"
.
Median +- std dev: 4.36 us +- 0.06 us

$ python -m perf timeit -s "from frc import Fraction; f=Fraction(3/4)" 
"Fraction(f)"
.
Median +- std dev: 4.59 us +- 0.07 us


$ python -m perf timeit -s "from fractions import Fraction" -s "class 
myInt(int): pass" -s "i=myInt(123456)" "Fraction(i)"
.
Median +- std dev: 4.04 us +- 0.07 us

$ python -m perf timeit -s "from frc import Fraction" -s "class myInt(int): 
pass" -s "i=myInt(123456)" "Fraction(i)"
.
Median +- std dev: 4.27 us +- 0.06 us


FLOATS
==

$ python -m perf timeit -s "from fractions import Fraction" 
"Fraction(1.23456e-7)"
.
Median +- std dev: 6.30 us +- 0.28 us

$ python -m perf timeit -s "from frc import Fraction" "Fraction(1.23456e-7)"
.
Median +- std dev: 8.64 us +- 0.13 us


$ python -m perf timeit -s "from fractions import Fraction" 
"Fraction.from_float(1.23456e-7)"
.
Median +- std dev: 8.68 us +- 0.14 us

$ python -m perf timeit -s "from frc import Fraction" 
"Fraction.from_float(1.23456e-7)"
.
Median +- std dev: 3.37 us +- 0.17 us


DECIMALS (using C implementation this time)
===

$ python -m perf timeit -s "from fractions import Fraction; from decimal import 
Decimal; d=Decimal('123456')" "Fraction(d)".
Median +- std dev: 6.95 us +- 0.21 us

$ python -m perf timeit -s "from frc import Fraction; from decimal import 
Decimal; d=Decimal('123456')" "Fraction(d)"
.
Median +- std dev: 8.43 us +- 0.17 us


$ python -m perf timeit -s "from fractions import Fraction; from decimal import 
Decimal; d=Decimal('123456')" "Fraction.from_decimal(d)"
.
Median +- std dev: 11.6 us +- 0.2 us

$ python -m perf timeit -s "from frc import Fraction; from decimal import 
Decimal; d=Decimal('123456')" "Fraction.from_decimal(d)"
.
Median +- std dev: 4.14 us +- 0.28 us

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28717] rounding error in % operator

[Mark Dickinson]

Mark Dickinson added the comment:

You don't say why you think this behaviour is wrong, or what you'd expect to 
see instead.

Nevertheless, this behaviour is by design: the code `'%.1f' % x` rounds `x` to 
the nearest one-digit-after-the-point decimal number, and returns a string 
representation of that number. In the case `x=0.25`, there is no single nearest 
number: `0.2` and `0.3` are equally close to `0.25`, so a choice between the 
two has to be made. In keeping with many other languages, Python chooses the 
value with even last digit. (The original behaviour is inherited from the 
typical behaviour of the standard library strtod or dtoa functions in C.)

--
nosy: +mark.dickinson
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28720] Add collections.abc.AsyncGenerator

[Yury Selivanov]

Changes by Yury Selivanov :


Removed file: http://bugs.python.org/file45512/agen_abc.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28720] Add collections.abc.AsyncGenerator

[Yury Selivanov]

Changes by Yury Selivanov :


Added file: http://bugs.python.org/file45513/agen_abc.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28720] Add collections.abc.AsyncGenerator

[Yury Selivanov]

New submission from Yury Selivanov:

This patch adds collections.abc.AsyncGenerator (closely modelled after 
collections.abc.Generator).

Ned, is it OK if this goes into 3.6?  This is something I completely forgot to 
do as part of PEP 525.  This ABC is needed for asynchronous generators compiled 
with Cython and async-generator-like objects/wrappers.

I'll update the PEP if we can push this to 3.6.

--
assignee: yselivanov
components: Library (Lib)
files: agen_abc.patch
keywords: patch
messages: 280993
nosy: gvanrossum, ned.deily, yselivanov
priority: release blocker
severity: normal
stage: patch review
status: open
title: Add collections.abc.AsyncGenerator
type: enhancement
versions: Python 3.6, Python 3.7
Added file: http://bugs.python.org/file45512/agen_abc.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28719] zipfile increase in size

[Bert JW Regeer]

New submission from Bert JW Regeer:

I am the current maintainer of WebOb, and noticed that on Python 3.6 and 3.7 I 
noticed that a test started failing.

Granted, the test is checking the size of the file created and it is not the 
brightest idea in a test, but it's been stable since Python 2.5...

https://travis-ci.org/Pylons/webob/jobs/176505096#L224

shows the failure.

_ test_response_file_body_tell _
def test_response_file_body_tell():
import zipfile
from webob.response import ResponseBodyFile
rbo = ResponseBodyFile(Response())
assert rbo.tell() == 0
writer = zipfile.ZipFile(rbo, 'w')
writer.writestr('zinfo_or_arcname', b'foo')
writer.close()
>   assert rbo.tell() == 133
E   assert 145 == 133
E+  where 145 = >>()
E+where >> = >.tell
tests/test_response.py:608: AssertionError

I am not sure that this is necessarily a bug, but it would be good to know why 
files are no longer generated the same way.

--
messages: 280992
nosy: X-Istence
priority: normal
severity: normal
status: open
title: zipfile increase in size
type: resource usage
versions: Python 3.6, Python 3.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue18235] _sysconfigdata.py wrong on AIX installations

[Michael Felt]

Michael Felt added the comment:

As this is the issue still open with regard to issues with ld_so_aix...

The current release Python3-3.5.2 does not include ld_so_aix in the "make 
install DESTDIR=xxx output ("make install" also neglects to install ld_so_aix)

Installation Summary

NameLevel   PartEvent   Result
---
aixtools.python3.rte3.5.2.0 USR APPLY   SUCCESS
root@x064:[/data/prj/python3/python3-3.5.2]find /opt -name ld_so_aix
root@x064:[/data/prj/python3/python3-3.5.2]grep ld_so_aix /opt/lib/py*/_sys*.py
 'BLDSHARED': '/opt/lib/python3.5/config/ld_so_aix xlc_r '
 'LDCXXSHARED': '/opt/lib/python3.5/config/ld_so_aix xlc_r '
 'LDSHARED': '/opt/lib/python3.5/config/ld_so_aix xlc_r '

So, the last two variables are correct - BLDSHARED is not correct in 
_sysconfigdata.py because the file does not exist during the build process. 
However, the build succeeds, so apparently this value for BLDSHARED is not used 
during the build.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28712] Non-Windows mappings for a couple of Windows code pages

[Eryk Sun]

Eryk Sun added the comment:

I rewrote it using the csv module since I can't remember the escaping rules.

--
Added file: http://bugs.python.org/file45511/codepage_table.csv

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28712] Non-Windows mappings for a couple of Windows code pages

[Eryk Sun]

Changes by Eryk Sun :


Removed file: http://bugs.python.org/file45510/codepage_table.csv

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28712] Non-Windows mappings for a couple of Windows code pages

[Eryk Sun]

Eryk Sun added the comment:

I don't think the 2nd tuple element is useful when decoding a single byte. It 
either works or it doesn't, such as failing for non-ASCII bytes with multibyte 
codepages such as 932 and 950. 

I'm attaching the output from the following, which you should be able to open 
in a spreadsheet:

import codecs
codepages = [424, 856, 857, 864, 869, 874, 932, 949, 950,
 1250, 1251, 1252, 1253, 1254, 1255, 1257, 1258]
for cp in codepages:
table = []
for i in range(256):
try:
c = codecs.code_page_decode(cp, bytes([i]), None, True)
c = ascii(c[0])
except Exception:
c = None
table.append(c)
print(cp, *table, sep=',')

--
Added file: http://bugs.python.org/file45510/codepage_table.csv

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26072] pdb fails to access variables closed over

[Xavier de Gaye]

Xavier de Gaye added the comment:

This patch fixes the problems raised in this issue and allows accessing the 
globals at the Pdb prompt with the globals() dictionary:

(Pdb) list
  1 y = 2
  2
  3 def f():
  4 y = 9
  5 z = 10
  6  -> import pdb; pdb.set_trace();
  7 f()
[EOF]
(Pdb) globals()['y']
2

--
Added file: http://bugs.python.org/file45509/free_variables.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28685] Optimizing list.sort() by performing safety checks in advance

[Elliot Gorokhovsky]

Elliot Gorokhovsky added the comment:

Oh wait... uh... never mind... we want "faster" to refer to total time taken, 
so 1-def/ref is indeed the correct formula. I just got confused because perf 
outputs ref/dev, but that doesn't make sense for percents.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28712] Non-Windows mappings for a couple of Windows code pages

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

This would be helpful too if every byte is decoded to exactly 1 character.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28718] '*' matches entire path in fnmatch.translate

[Jim Nasby]

New submission from Jim Nasby:

A '*' in fnmatch.translate is converted into '.*', which will greedily match 
directory separators. This doesn't match shell behavior, which is that * will 
only match file names:

decibel@decina:[14:07]~$ls ~/tmp/*/1|head
ls: /Users/decibel/tmp/*/1: No such file or directory
decibel@decina:[14:07]~$ls ~/tmp/d*/base/1|head
112

>From a posix standpoint, this would easily be fixed by using '[^/]*' instead 
>of '.*'. I'm not sure how to make this work cross-platform though.

It's worth noting that some programs (rsync, git) support **, which would 
correctly translate to '.*'.

--
components: Library (Lib)
messages: 280985
nosy: Jim Nasby
priority: normal
severity: normal
status: open
title: '*' matches entire path in fnmatch.translate

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28717] rounding error in % operator

[William McIlhagga]

New submission from William McIlhagga:

'%.1f' % 0.25  yields the string '0.2'

'%.1f' % 0.75  yields the string '0.8'

This is wrong.

--
messages: 280984
nosy: William McIlhagga
priority: normal
severity: normal
status: open
title: rounding error in % operator
type: behavior
versions: Python 2.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28712] Non-Windows mappings for a couple of Windows code pages

[Eryk Sun]

Eryk Sun added the comment:

How about just the ASCII repr of the 256 decoded characters in CSV? I don't 
think the list of 2-tuple results is useful. For these single-byte codepages 
it's always 1 byte consumed.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28715] Check result of PyUnicode_AsUTF8

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

_PyUnicode_AsString is just an outdated alias to PyUnicode_AsUTF8.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28716] Fractions instantiation revisited

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Profiling give you only approximate results. In normal execution the effect of 
your changes can be opposite. Could you please provide benchmarks without using 
profiling?

--
nosy: +serhiy.storchaka

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28712] Non-Windows mappings for a couple of Windows code pages

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Thanks Eryk. Could you please run following script and attach the output?

import codecs
codepages = [424, 856, 857, 864, 869, 874, 932, 949, 950, 1250, 1251, 1252, 
1253, 1254, 1255, 1257, 1258]
for cp in codepages:
table = []
for i in range(256):
try:
c = codecs.code_page_decode(cp, bytes([i]), None, True)
except Exception:
c = None
table.append(c)
print(cp, ascii(table))

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28712] Non-Windows mappings for a couple of Windows code pages

[Eryk Sun]

Eryk Sun added the comment:

Serhiy, single-byte codepages map every byte value, even if it's just to a 
Unicode C1 control code [1]. 

For example:

import ctypes
kernel32 = ctypes.WinDLL('kernel32', use_last_error=True)

MB_ERR_INVALID_CHARS = 0x0008

def mbtwc_errcheck(result, func, args):
if not result and args[-1]:
raise ctypes.WinError(ctypes.get_last_error())
return args

kernel32.MultiByteToWideChar.errcheck = mbtwc_errcheck

def decode(codepage, data, strict=True):
flags = MB_ERR_INVALID_CHARS if strict else 0
n = kernel32.MultiByteToWideChar(codepage, flags,
 data, len(data),
 None, 0)
buf = (ctypes.c_wchar * n)()
kernel32.MultiByteToWideChar(codepage, flags,
 data, len(data),
 buf, n)
return buf.value


codepages = [437, 874] + list(range(1250, 1259))
for cp in codepages:
print('cp%d:' % cp, ascii(decode(cp, b'\x81\x8d')))

Output:

cp437: '\xfc\xec'
cp874: '\x81\x8d'
cp1250: '\x81\u0164'
cp1251: '\u0403\u040c'
cp1252: '\x81\x8d'
cp1253: '\x81\x8d'
cp1254: '\x81\x8d'
cp1255: '\x81\x8d'
cp1256: '\u067e\u0686'
cp1257: '\x81\xa8'
cp1258: '\x81\x8d'

[1]: https://en.wikipedia.org/wiki/C0_and_C1_control_codes

--
nosy: +eryksun

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28716] Fractions instantiation revisited

[R. David Murray]

Changes by R. David Murray :


--
nosy: +mark.dickinson

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21449] Replace _PyUnicode_CompareWithId with _PyUnicode_EqualToASCIIId

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
title: Replace _PyUnicode_CompareWithId with _PyUnicode_CompareWithIdEqual -> 
Replace _PyUnicode_CompareWithId with _PyUnicode_EqualToASCIIId

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28685] Optimizing list.sort() by performing safety checks in advance

[Elliot Gorokhovsky]

Elliot Gorokhovsky added the comment:

So thanks for pointing out that perf has a --compare_to option: it turns out I 
had calculated the times wrong! Specifically, I had used

(ref-dev)/ref

while I should have used

ref/dev

which is what perf --compare_to uses. Anyway, the actual times are even more 
incredible than I could have imagined! First, here's my benchmark script:

#!/bin/bash
rm ref.json dev.json 2> /dev/null
python-dev/python -m perf timeit -s "$1" "sorted(l)" --rigorous -o dev.json > 
/dev/null
python-ref/python -m perf timeit -s "$1" "sorted(l)" --rigorous -o ref.json > 
/dev/null
python-ref/python -m perf compare_to ref.json dev.json

And here are the results:

./bench.sh "import random; l=[random.uniform(-1,1) for _ in range(0,100)]"
Median +- std dev: [ref] 8.34 us +- 0.18 us -> [dev] 3.33 us +- 0.13 us: 2.50x 
faster

So it's 150% faster! (i.e. 150% + 100% = 250%). 150% faster sorting for 
floats!!! If we make them tuples, it's even more incredible:
Median +- std dev: [ref] 20.9 us +- 1.0 us -> [dev] 4.99 us +- 0.27 us: 4.19x 
faster

319% faster!!! And earlier, I had thought 75% was impressive... I mean, 319%!!! 
And again, this is an application that is directly useful: DEAP spends a great 
deal of time sorting tuples of floats, this will make their EAs run a lot 
faster.

"import random; l=[str(random.uniform(-1,1)) for _ in range(0,100)]"
Median +- std dev: [ref] 15.7 us +- 0.9 us -> [dev] 9.24 us +- 0.52 us: 1.70x 
faster

"import random; l=[int(random.uniform(-1,1)*2**15) for _ in range(0,100)]"
Median +- std dev: [ref] 8.59 us +- 0.19 us -> [dev] 4.35 us +- 0.13 us: 1.98x 
faster

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28670] PEP 235: Implement on every POSIX system, and clean up the C code for `import'

[Brett Cannon]

Changes by Brett Cannon :


--
nosy:  -brett.cannon

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28685] Optimizing list.sort() by performing safety checks in advance

[Elliot Gorokhovsky]

Changes by Elliot Gorokhovsky :


Added file: http://bugs.python.org/file45508/fastsort.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28716] Fractions instantiation revisited

[Wolfgang Maier]

New submission from Wolfgang Maier:

I've spent a bit of time lately trying to optimize the instantiation of 
Fractions. This is related to Issue22464, but instead of focusing on 
constructing Fractions from ints, my attempts revolve around improving 
instantiation from strings, floats and decimals.
I'm attaching a patch with all my changes for discussion, but here's an 
overview of what's in it:

CHANGES TO INSTANTIATION FROM STRINGS:

- isinstance checking for str is performed before the more expensive check for 
numbers.Rational (which has to go through abc)

- instantiation from strings doesn't use a regex pattern anymore for parsing; 
this is faster in many cases (and never slower) than the current version

- while reimplementing string parsing I added PEP 515 support (this is the only 
behavior change in the patch)

combined this gives me the following performance changes for instantiation of 
Fractions from different arguments (profiled with 1,000,000 random inputs each):

'x/y'-type of strings:
--
   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
old:
  100   12.1620.000   27.7780.000 fractions.py:84(__new__)
new:
  1009.6190.000   12.4280.000 frc.py:68(__new__)


scientific notation (e.g., '1.234E-7'):
---
   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
old:
  100   18.2090.000   37.3410.000 fractions.py:84(__new__)
new:
  100   15.5090.000   21.2520.000 frc.py:68(__new__)


integer strings (e.g. '123456'):

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
old:
  100   11.2720.000   26.2010.000 fractions.py:84(__new__)
new:
  1009.3470.000   12.4250.000 frc.py:68(__new__)


from other Fractions (to test effect on instantiation of numbers.Rational):
   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
old:
  1004.7080.000   10.0930.000 fractions.py:84(__new__)
new:
  1004.8350.000   10.5720.000 frc.py:68(__new__)

from int subclass (as another numbers.Rational):
   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
old:
  1003.4460.0008.0440.000 fractions.py:84(__new__)
new:
  1003.7950.0008.8360.000 frc.py:68(__new__)


SUMMARY of this part


+ very significant speedup for instatiation from strings of different forms 
with (near) negligible effects on instantiation from numbers.Rational.

+ correct parsing of PEP 515-like number strings

- possibly slower error bubbling with invalid input (untested)


CHANGES TO INSTANTIATION FROM FLOAT AND DECIMAL:

- no explicit check for float and decimal in standard constructor; instead, 
simply try to call as_integer_ratio as last resort (even after checking for 
numbers.Rational)

- speed up alternate from_float and from_decimal constructor class methods by 
rearranging type checks and making use of _normalize flag

- import decimal only on demand (when using from_decimal)


Resulting performance changes:

standard constructor with float:

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
old:
  1004.3620.000   12.4520.000 fractions.py:84(__new__)
new:
  1006.6930.000   16.0200.000 frc.py:68(__new__)

from_float:
---
   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
old:
  1003.1460.000   17.7690.000 fractions.py:193(from_float)
new:
  1002.5440.0007.5910.000 frc.py:205(from_float)

standard constructor with decimal:

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
old:
  1004.6720.000   20.7950.000 fractions.py:84(__new__)
new:
  1007.0970.000   24.5260.000 frc.py:68(__new__)

from_decimal:
-
   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
old:
  1005.0540.000   34.4730.000 fractions.py:207(from_decimal)
new:
  1002.9420.000   16.0130.000 frc.py:220(from_decimal)

SUMMARY of this part:
- standard constructor becomes a bit slower for floats and Decimals
specialized class methods become a lot faster (for Decimal the benchmarks are 
based on _pydecimal - with the C implementation the percent differences would 
be even larger)
- eliminates decimal from regularly imported modules
- allows Fraction instantiation from duck-typing classes that provide 
as_integer_ratio

I hope at least some of this is interesting.

--
components: Library (Lib)
files: fractions.patch
keywords: patch
messages: 280977
nosy: wolma
priority: normal
severity: normal
status: open
title: Fractions instantiation revisited
type: behavior
versions: Python 3.7
Added file: http://bugs.python.org/file45507/fractions.patch

[issue28701] Replace PyUnicode_CompareWithASCIIString with _PyUnicode_EqualToASCIIString

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
resolution:  -> fixed
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28701] Replace PyUnicode_CompareWithASCIIString with _PyUnicode_EqualToASCIIString

[Roundup Robot]

Roundup Robot added the comment:

New changeset 6dd22ed7140e by Serhiy Storchaka in branch '3.6':
Issue #28701: _PyUnicode_EqualToASCIIId and _PyUnicode_EqualToASCIIString now
https://hg.python.org/cpython/rev/6dd22ed7140e

New changeset 44874b20e612 by Serhiy Storchaka in branch 'default':
Issue #28701: _PyUnicode_EqualToASCIIId and _PyUnicode_EqualToASCIIString now
https://hg.python.org/cpython/rev/44874b20e612

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28701] Replace PyUnicode_CompareWithASCIIString with _PyUnicode_EqualToASCIIString

[STINNER Victor]

STINNER Victor added the comment:

_PyUnicode_EqualToASCII-runtime-check.diff LGTM.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28712] Non-Windows mappings for a couple of Windows code pages

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Codecs are strict by default in Python. Call MultiByteToWideChar() with the 
MB_ERR_INVALID_CHARS flag as Python does. You also could use 
_codecs.code_page_decode().

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28712] Non-Windows mappings for a couple of Windows code pages

[Ned Deily]

Ned Deily added the comment:

I'm not qualified to offer a technical opinion on Windows matters like this so, 
for 3.6, I leave it to your discretion, Steve.  If you do decide to push this 
change, please do so before 3.6.0b4 on Monday.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28715] Check result of PyUnicode_AsUTF8

[Serhiy Storchaka]

New submission from Serhiy Storchaka:

The function PyUnicode_AsUTF8() can fail, but not all callers check for error. 
Proposed patch adds missed checks. In some places the code is rewritten to not 
use PyUnicode_AsUTF8() at all.

--
components: Extension Modules, Interpreter Core
files: check-PyUnicode_AsUTF8.patch
keywords: patch
messages: 280972
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Check result of PyUnicode_AsUTF8
type: crash
versions: Python 3.5, Python 3.6, Python 3.7
Added file: http://bugs.python.org/file45506/check-PyUnicode_AsUTF8.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28712] Non-Windows mappings for a couple of Windows code pages

[Steve Dower]

Steve Dower added the comment:

No idea which is faster, but the tables have better compatibility.

However, I'm not sure that changing the tables in already released versions is 
a great idea, since it could "corrupt" programs without warning. Adding the 
release managers to weigh in - my gut feel is that targeted table fixes plus 
validation tests are okay for 3.6 if we hurry, but are probably not suitable 
for 2.7 or 3.5.

--
nosy: +benjamin.peterson, larry, ned.deily

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28712] Non-Windows mappings for a couple of Windows code pages

[Mingye Wang]

Mingye Wang added the comment:

... On the other hand, I am happy to use these Win32 functions if they are 
faster, but still the table should be made correct in the first place. (See 
also issue28343 (936) and issue28693 (950) for problems with DBCS Chinese code 
pages.)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28343] Bad encoding alias cp936 -> gbk: euro sign

[Mingye Wang]

Mingye Wang added the comment:

Update: the test script at issue28712 can be modified to show this issue too.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28693] No HKSCS support in Windows cp950

[Mingye Wang]

Mingye Wang added the comment:

Update: the test script at issue28712 can be modified to show this issue too.

--
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28343] Bad encoding alias cp936 -> gbk: euro sign

[Mingye Wang]

Changes by Mingye Wang :


--
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28712] Non-Windows mappings for a couple of Windows code pages

[Mingye Wang]

Mingye Wang added the comment:

Yes, it's a table issue. My suggested fix is to replace them all with 
WindowsBestFit tables, where MS currently redirects 
https://msdn.microsoft.com/en-us/globalization/mt767590 visitors to. These old 
"WINDOWS" tables appear abandoned since long ago.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28670] PEP 235: Implement on every POSIX system, and clean up the C code for `import'

[Michael Witten]

Michael Witten added the comment:

* Bugs, by their very nature, are often obscure; some of the worst
  in history have lain dormant, unseen, for years or perhaps even
  decades.

  Unsurprisingly, then, this bug is also a corner case that would be
  unknowingly triggered in practice only rarely; consequently, it is
  unsurprising that it has not been reported previously, despite the
  fact that the mistake is OBVIOUS in a retrospective (and literal!)
  reading of PEP 235, which is clearly naive in its view of the world
  of computing systems.

* Furthermore, in any computing system that is sufficiently complex,
  there is usually a workaround for any particular bug, which thus
  diminishes the impetus to report the problem at all; this just
  compounds the obscurity of the bug.

* The more obscure a bug, the less compelling the ratio of the
  reward to the solution effort, particularly when the objections
  are mired not in technical analysis, but rather in an incomplete
  understanding of the report, as well as perhaps some kind of
  political puffery.

  So, why bother even beginning a discussion of the issue?

  Indeed, this correspondence has proven to me (once again,
  unfortunately) that it's usually an utter waste of resources to
  attempt to solve problems purely for the benefit of others. Let
  the confused gnash their teeth, and let the clever hack their
  own way out of trouble. As long as my personal itch has been
  scratched in some way, that's good enough.

* How is it that you did not perceive the irrelevance of [at least
  the rest of] your reply?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28712] Non-Windows mappings for a couple of Windows code pages

[Steve Dower]

Steve Dower added the comment:

So is this a bug in the hardcoded encoding tables in Python? I briefly 
considered making them all use the OS functions, but then they'll be 
inconsistent with other platforms (where the tables should work fine).

Do you have a proposed fix? That will help illustrate where the problem is.

--
versions:  -Python 3.3, Python 3.4

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28712] Non-Windows mappings for a couple of Windows code pages

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28701] Replace PyUnicode_CompareWithASCIIString with _PyUnicode_EqualToASCIIString

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Following patch adds checks in debug mode that the right argument of 
_PyUnicode_EqualToASCIIString and _PyUnicode_EqualToASCIIId is ASCII-only 
string.

--
Added file: 
http://bugs.python.org/file45505/_PyUnicode_EqualToASCII-runtime-check.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28713] Recent tutorial for recent Python3 still uses IOError.

[Roundup Robot]

Roundup Robot added the comment:

New changeset 3375c111d1ff by Kushal Das in branch '3.6':
Closes #28713 uses OSError in the tutorial
https://hg.python.org/cpython/rev/3375c111d1ff

New changeset 15e5e476e4a1 by Kushal Das in branch 'default':
Closes #28713 uses OSError in the tutorial
https://hg.python.org/cpython/rev/15e5e476e4a1

--
nosy: +python-dev
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28713] Recent tutorial for recent Python3 still uses IOError.

[Kushal Das]

Kushal Das added the comment:

This following one line change should fix this one.

--
keywords: +patch
nosy: +kushal.das
Added file: http://bugs.python.org/file45504/issue28713.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28670] PEP 235: Implement on every POSIX system, and clean up the C code for `import'

[Nick Coghlan]

Nick Coghlan added the comment:

We work closely with Linux distribution providers, and a number of us work 
*for* commercial Linux distributors (most notably Red Hat and Canonical).

Linux distributions have already agreed that Python 2.7 is in maintenance mode, 
and already influence the process of backporting any Python 3 changes that they 
consider sufficiently valuable to their users.

(For example, Red Hat has backported the SSL/TLS improvements to the system 
Python in RHEL 7 and to the Python 2.7 Software Collection after OpenStack 
developers at Rackspace convinced myself and others that the old behaviours 
were genuinely problematic)

Thus, is you want to convince us that this is a bug that actually needs fixing 
rather than a new feature request, you need to come up with a convincing 
explanation for why no Linux distribution (whether community run or commercial) 
has seen fit to report it as a bug at any point in the past 15 years.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28714] Addition to Documentation of configparser.ConfigParser.write()

[George Fischhof]

Changes by George Fischhof :


--
title: Addition to Documentation of configparser.ConfigParser.write() 
documentaion -> Addition to Documentation of configparser.ConfigParser.write()

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28696] imap from ThreadPool hangs by an exception in a generator function

[Davin Potts]

Changes by Davin Potts :


--
superseder:  -> Imap from ThreadPool behaves unexpectedly

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28714] Addition to Documentation of configparser.ConfigParser.write() documentaion

[George Fischhof]

New submission from George Fischhof:

Hi There, 

I used configparser.ConfigParser.write() to update a config file.
And I found that my config wa duplicated.

The file was opened with mode 'r+' 
I figured out that write (I mean the write method of configparser) writes at 
actual file position.

I issued a file.seek(0) command before write and the result was good.


So I think documentaion should advice to user to reopen the file with mode 'w' 
or to issue a file.seek(0) command before using the ConfigParser.write()


I used the following python version on windows:
Python 3.5.1 (v3.5.1:37a07cee5969, Dec  6 2015, 01:38:48) [MSC v.1900 32 bit 
(Intel)] on win32

affected documentation:
https://docs.python.org/3.5/library/configparser.html#configparser.ConfigParser.write

Best Regards,
George Fischhof

--
assignee: docs@python
components: Documentation
messages: 280960
nosy: docs@python, georgefischhof
priority: normal
severity: normal
status: open
title: Addition to Documentation of configparser.ConfigParser.write() 
documentaion
versions: Python 3.5

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28712] Non-Windows mappings for a couple of Windows code pages

[Mingye Wang]

Changes by Mingye Wang :


Removed file: http://bugs.python.org/file45502/pycp.py

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28699] Imap from ThreadPool behaves unexpectedly

[Davin Potts]

Davin Potts added the comment:

This inconsistent behavior in imap on both Pool and ThreadPool is not what I 
would expect.

--
versions: +Python 3.6, Python 3.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28625] multiprocessing.Pool.imap swallows exceptions thrown by generators

[Davin Potts]

Davin Potts added the comment:

In issue28699, an important clue has been identified (a variation on the 
generator triggers a different, inconsistent behavior).  I will merge this 
issue into that one to keep us all on the same page.

--
superseder:  -> Imap from ThreadPool behaves unexpectedly

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28699] Imap from ThreadPool behaves unexpectedly

[Davin Potts]

Davin Potts added the comment:

To tie in the example given by @elias in issue28625, this inconsistency in 
behavior is not limited to ThreadPool -- it appears with a process Pool as well:


from multiprocessing import Pool


def double(x):
return 2 * x

def get_numbers():
raise Exception("oops")
yield 1
yield 2


>>> list(Pool(processes=2).imap(double, get_numbers()))  # returns list
[]
>>> list(Pool(processes=2).map(double, get_numbers()))
Traceback (most recent call last):
  ...
Exception: oops


def get_numbers_differently():
yield 1
raise Exception("oops")
yield 2


>>> list(Pool(processes=2).imap(double, get_numbers_differently()))  # now we 
>>> see exception
Traceback (most recent call last):
  ...
Exception: oops

--
assignee:  -> davin
nosy: +elias
stage:  -> needs patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28712] Non-Windows mappings for a couple of Windows code pages

[Mingye Wang]

Mingye Wang added the comment:

The output is already attached as win10_14959_py36.txt.

PS: after playing with ctypes, I got a version of pycp that works with Py < 3.3 
too (attached with comment).

--
Added file: http://bugs.python.org/file45503/pycp_ctypes.py

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28701] Replace PyUnicode_CompareWithASCIIString with _PyUnicode_EqualToASCIIString

[Roundup Robot]

Roundup Robot added the comment:

New changeset b607f835f170 by Serhiy Storchaka in branch '3.5':
Fixed an off-by-one error in _PyUnicode_EqualToASCIIString (issue #28701).
https://hg.python.org/cpython/rev/b607f835f170

New changeset 1369e51182b7 by Serhiy Storchaka in branch '3.6':
Fixed an off-by-one error in _PyUnicode_EqualToASCIIString (issue #28701).
https://hg.python.org/cpython/rev/1369e51182b7

New changeset ba14f8b61bd8 by Serhiy Storchaka in branch 'default':
Fixed an off-by-one error in _PyUnicode_EqualToASCIIString (issue #28701).
https://hg.python.org/cpython/rev/ba14f8b61bd8

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28670] PEP 235: Implement on every POSIX system, and clean up the C code for `import'

[Michael Witten]

Michael Witten added the comment:

* This is not a feature request;
  this is a bug fix for errant behavior.

  However, in the interest of civility, I have not re-opened this issue.

* > Python 2.7 DOES NOT support filesystem semantics that differ
  > from the "default" semantics for the host operating system.

  That statement makes no sense; the decisions being made here
  are based on nonsense.

* > folks that really want the behaviour you propose may upgrade to Python 3

  Ah. I'm getting the distinct impression that this is a political
  matter, rather than a technical matter.

  No wonder the responses have been incomprehensible.

  Here's an idea that echos your own: If you wish to pursue this outcome
  further, please take it to the issue tracker for your preferred Linux
  distribution and convince *them* that all the software they provide
  should be ported to Python 3. If multiple Linux distributions agree
  that it is no longer valuable to support Python 2, then that will add
  weight to your argument that there is little reason to fix its bugs,
  and that Python 3 is actually useful.

--
type: enhancement -> behavior

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21449] Replace _PyUnicode_CompareWithId with _PyUnicode_CompareWithIdEqual

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21449] Replace _PyUnicode_CompareWithId with _PyUnicode_CompareWithIdEqual

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Thank you Josh and Xiang for your contribution.

--
dependencies:  -Replace PyUnicode_CompareWithASCIIString with 
_PyUnicode_EqualToASCIIString
resolution:  -> fixed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21449] Replace _PyUnicode_CompareWithId with _PyUnicode_CompareWithIdEqual

[Roundup Robot]

Roundup Robot added the comment:

New changeset b995a6950139 by Serhiy Storchaka in branch '3.6':
Issue #21449: Removed private function _PyUnicode_CompareWithId.
https://hg.python.org/cpython/rev/b995a6950139

New changeset 9b053d3c74dc by Serhiy Storchaka in branch 'default':
Issue #21449: Removed private function _PyUnicode_CompareWithId.
https://hg.python.org/cpython/rev/9b053d3c74dc

--
nosy: +python-dev

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28712] Non-Windows mappings for a couple of Windows code pages

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

What is the output of new script?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2504] Add gettext.pgettext() and variants support

[Tristan Fisher]

Changes by Tristan Fisher :


--
nosy: +Tristan.Fisher

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21449] Replace _PyUnicode_CompareWithId with _PyUnicode_CompareWithIdEqual

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

New changeset faf04a995031 by Serhiy Storchaka in branch '3.5':
Issue #28701: Replace _PyUnicode_CompareWithId with _PyUnicode_EqualToASCIIId.
https://hg.python.org/cpython/rev/faf04a995031

New changeset ff3dacc98b3a by Serhiy Storchaka in branch '3.6':
Issue #28701: Replace _PyUnicode_CompareWithId with _PyUnicode_EqualToASCIIId.
https://hg.python.org/cpython/rev/ff3dacc98b3a

New changeset 765013f71bc4 by Serhiy Storchaka in branch 'default':
Issue #28701: Replace _PyUnicode_CompareWithId with _PyUnicode_EqualToASCIIId.
https://hg.python.org/cpython/rev/765013f71bc4

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28701] Replace PyUnicode_CompareWithASCIIString with _PyUnicode_EqualToASCIIString

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

The correct issue for above commits is issue21449.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28701] Replace PyUnicode_CompareWithASCIIString with _PyUnicode_EqualToASCIIString

[Roundup Robot]

Roundup Robot added the comment:

New changeset faf04a995031 by Serhiy Storchaka in branch '3.5':
Issue #28701: Replace _PyUnicode_CompareWithId with _PyUnicode_EqualToASCIIId.
https://hg.python.org/cpython/rev/faf04a995031

New changeset ff3dacc98b3a by Serhiy Storchaka in branch '3.6':
Issue #28701: Replace _PyUnicode_CompareWithId with _PyUnicode_EqualToASCIIId.
https://hg.python.org/cpython/rev/ff3dacc98b3a

New changeset 765013f71bc4 by Serhiy Storchaka in branch 'default':
Issue #28701: Replace _PyUnicode_CompareWithId with _PyUnicode_EqualToASCIIId.
https://hg.python.org/cpython/rev/765013f71bc4

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28701] Replace PyUnicode_CompareWithASCIIString with _PyUnicode_EqualToASCIIString

[STINNER Victor]

STINNER Victor added the comment:

I suggest "return 0 in release build and crash in debug build".

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28712] Non-Windows mappings for a couple of Windows code pages

[Mingye Wang]

Changes by Mingye Wang :


Removed file: http://bugs.python.org/file45497/pycp.py

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28712] Non-Windows mappings for a couple of Windows code pages

[Mingye Wang]

Changes by Mingye Wang :


Added file: http://bugs.python.org/file45502/pycp.py

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue28712] Non-Windows mappings for a couple of Windows code pages

[Mingye Wang]

Mingye Wang added the comment:

Ugh... This is weird. Attached is a correct version use Python 3.6's 'code 
page' methods. I have modified the script a little to make sure it runs on Py3.

--
Added file: http://bugs.python.org/file45501/win10_14959_py36.txt

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue27945] Various segfaults with dict

[INADA Naoki]

INADA Naoki added the comment:

OK, I'll run benchmark in this week.
But three patches seems don't affects to performance critical APIs.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com