[issue41211] PyLong_FromUnicodeObject document is wrong

[Inada Naoki]

Change by Inada Naoki :


--
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

[issue41211] PyLong_FromUnicodeObject document is wrong

[miss-islington]

miss-islington  added the comment:


New changeset 01c0925271a9e8c6a4b316efeb8fdcbed9eb17f4 by Miss Islington (bot) 
in branch '3.8':
bpo-41211: Doc: Fix PyLong_FromUnicode (GH-21331)
https://github.com/python/cpython/commit/01c0925271a9e8c6a4b316efeb8fdcbed9eb17f4


--

___
Python tracker 

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

[issue41211] PyLong_FromUnicodeObject document is wrong

[miss-islington]

Change by miss-islington :


--
pull_requests: +20482
pull_request: https://github.com/python/cpython/pull/21332

___
Python tracker 

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

[issue41211] PyLong_FromUnicodeObject document is wrong

[Inada Naoki]

Inada Naoki  added the comment:


New changeset 16f451744b7f4653ca9db4b4bedbb6fc5c0de154 by Inada Naoki in branch 
'3.9':
bpo-41211: Doc: Fix PyLong_FromUnicode (GH-21331)
https://github.com/python/cpython/commit/16f451744b7f4653ca9db4b4bedbb6fc5c0de154


--

___
Python tracker 

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

[issue39168] Generic type subscription is a huge toll on Python performance

[miss-islington]

miss-islington  added the comment:


New changeset 7fed75597fac11f9a6c769e2b6c6548fe0e4049d by Zackery Spytz in 
branch 'master':
bpo-39168: Remove the __new__ method of typing.Generic (GH-21327)
https://github.com/python/cpython/commit/7fed75597fac11f9a6c769e2b6c6548fe0e4049d


--
nosy: +miss-islington

___
Python tracker 

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

[issue39168] Generic type subscription is a huge toll on Python performance

[Guido van Rossum]

Guido van Rossum  added the comment:

Should this be backported? How far back?

--

___
Python tracker 

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

[issue41211] PyLong_FromUnicodeObject document is wrong

[Inada Naoki]

Change by Inada Naoki :


--
pull_requests: +20481
pull_request: https://github.com/python/cpython/pull/21331

___
Python tracker 

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

[issue41211] PyLong_FromUnicodeObject document is wrong

[miss-islington]

miss-islington  added the comment:


New changeset 4874e5908c38da4c7dcaecf6397832dda1e6dd08 by Miss Islington (bot) 
in branch '3.8':
bpo-41211: Doc: Fix PyLong_FromUnicodeObject (GH-21325)
https://github.com/python/cpython/commit/4874e5908c38da4c7dcaecf6397832dda1e6dd08


--

___
Python tracker 

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

[issue41211] PyLong_FromUnicodeObject document is wrong

[miss-islington]

miss-islington  added the comment:


New changeset 48f388f02f000fb9087a854c0dc77ce39bc2bb29 by Miss Islington (bot) 
in branch '3.9':
bpo-41211: Doc: Fix PyLong_FromUnicodeObject (GH-21325)
https://github.com/python/cpython/commit/48f388f02f000fb9087a854c0dc77ce39bc2bb29


--

___
Python tracker 

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

[issue32192] Provide importlib.util.lazy_import helper function

[Joannah Nanjekye]

Change by Joannah Nanjekye :


--
keywords: +patch
nosy: +nanjekyejoannah
nosy_count: 5.0 -> 6.0
pull_requests: +20480
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/21330

___
Python tracker 

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

[issue41211] PyLong_FromUnicodeObject document is wrong

[miss-islington]

Change by miss-islington :


--
pull_requests: +20479
pull_request: https://github.com/python/cpython/pull/21329

___
Python tracker 

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

[issue41211] PyLong_FromUnicodeObject document is wrong

[miss-islington]

Change by miss-islington :


--
nosy: +miss-islington
nosy_count: 2.0 -> 3.0
pull_requests: +20478
pull_request: https://github.com/python/cpython/pull/21328

___
Python tracker 

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

[issue41211] PyLong_FromUnicodeObject document is wrong

[Inada Naoki]

Inada Naoki  added the comment:


New changeset 9c8441712230660fedac818ed50e7cdd89e4c51d by Inada Naoki in branch 
'master':
bpo-41211: Doc: Fix PyLong_FromUnicodeObject (GH-21325)
https://github.com/python/cpython/commit/9c8441712230660fedac818ed50e7cdd89e4c51d


--

___
Python tracker 

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

[issue39168] Generic type subscription is a huge toll on Python performance

[Zackery Spytz]

Change by Zackery Spytz :


--
keywords: +patch
nosy: +ZackerySpytz
nosy_count: 6.0 -> 7.0
pull_requests: +20477
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21327

___
Python tracker 

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

[issue23802] patch: __deepcopy__ memo dict argument usage

[Joannah Nanjekye]

Change by Joannah Nanjekye :


--
nosy: +nanjekyejoannah
nosy_count: 3.0 -> 4.0
pull_requests: +20476
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21326

___
Python tracker 

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

[issue41211] PyLong_FromUnicodeObject document is wrong

[Inada Naoki]

Change by Inada Naoki :


--
keywords: +patch
pull_requests: +20475
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21325

___
Python tracker 

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

[issue41211] PyLong_FromUnicodeObject document is wrong

[Inada Naoki]

New submission from Inada Naoki :

```
.. c:function:: PyObject* PyLong_FromUnicodeObject(PyObject *u, int base)

   Convert a sequence of Unicode digits in the string *u* to a Python integer
   value.  The Unicode string is first encoded to a byte string using
   :c:func:`PyUnicode_EncodeDecimal` and then converted using
   :c:func:`PyLong_FromString`.
```

PyUnicode_EncodeDecimal is not used actually.
It uses private and undocumented `_PyUnicode_TransformDecimalAndSpaceToASCII` 
function instead.

The document of PyFloat_FromString() doesn't mention about how it convert 
unicode string to digits. Let's remove the second sentence.

--
assignee: docs@python
components: Documentation
messages: 373009
nosy: docs@python, inada.naoki
priority: normal
severity: normal
status: open
title: PyLong_FromUnicodeObject document is wrong
versions: Python 3.10, Python 3.8, Python 3.9

___
Python tracker 

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

[issue12165] Nonlocal does not include global; clarify doc

[Joannah Nanjekye]

Change by Joannah Nanjekye :


--
nosy: +nanjekyejoannah
stage:  -> needs patch

___
Python tracker 

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

[issue26205] Inconsistency concerning nested scopes

[Joannah Nanjekye]

Change by Joannah Nanjekye :


--
keywords: +patch
nosy: +nanjekyejoannah
nosy_count: 8.0 -> 9.0
pull_requests: +20474
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/21324

___
Python tracker 

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

[issue41210] LZMADecompressor.decompress(FORMAT_RAW) truncate output when input is paticular LZMA+BCJ data

[Hiroshi Miura]

New submission from Hiroshi Miura :

When decompressing a particular archive, result become truncated a last word. 
A test data attached is uncompressed size is 12800 bytes, and compressed using 
LZMA1+BCJ algorithm into 11327 bytes.
The data is a payload of a 7zip archive.

Here is a pytest code to reproduce it.


:: code-block::

def test_lzma_raw_decompressor_lzmabcj():
filters = []
filters.append({'id': lzma.FILTER_X86})
filters.append(lzma._decode_filter_properties(lzma.FILTER_LZMA1, 
b']\x00\x00\x01\x00'))
decompressor = lzma.LZMADecompressor(format=lzma.FORMAT_RAW, 
filters=filters)
with testdata_path.joinpath('lzmabcj.bin').open('rb') as infile:
out = decompressor.decompress(infile.read(11327))
assert len(out) == 12800


test become failure that len(out) become 12796 bytes, which lacks last 4 bytes, 
which should be b'\x00\x00\x00\x00'
When specifying  a filters  as a single LZMA1 decompression,  I got an expected 
length of data, 12800 bytes.(*1)

When creating a test data with LZMA2+BCJ and examines it, I got an expected 
data.
When specifying a filters as a single LZMA2 decompression against LZMA2+BCJ 
payload, a result is perfectly as same as (*1) data.
It indicate us that a pipeline of LZMA1/LZMA2 --> BCJ is in doubt. 


After investigation and understanding that _lzmamodule.c is a thin wrapper of 
liblzma, I found the problem can be reproduced in liblzma.
I've reported it to upstream xz-devel ML with a test code 
https://www.mail-archive.com/xz-devel@tukaani.org/msg00370.html

--
components: Extension Modules
files: lzmabcj.bin
messages: 373008
nosy: miurahr
priority: normal
severity: normal
status: open
title: LZMADecompressor.decompress(FORMAT_RAW) truncate output when input is 
paticular LZMA+BCJ  data
versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file49296/lzmabcj.bin

___
Python tracker 

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

[issue13322] The io module doesn't support non-blocking files

[Joshua Bronson]

Change by Joshua Bronson :


--
nosy: +jab

___
Python tracker 

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

Re: Formal Question to Steering Council (re recent PEP8 changes)

[Random832]

On Sat, Jul 4, 2020, at 18:17, Ethan Furman wrote:
> On 07/04/2020 10:32 AM, Random832 wrote:
> 
> > I said obvious because even if it was not obvious from the commit message 
> > itself, it had *already been explained* in the thread on the other mailing 
> > list
> 
> That would require Michael to have been reading the other mailing list 
> to know that.  Just because the information is out there, doesn't mean 
> everybody has seen it.

ok, you know what?

regardless of hairsplitting about how obvious or not it is what she meant, and 
whether or not "it's because of the name White" was a reasonable conclusion to 
jump to, none of that changes that the conclusion was, in fact, incorrect. So 
trying to fight with me for pointing that out and claiming I was offering my 
"opinion" was unreasonable. I was not offering an opinion, I was pointing out a 
factual error, and arguing that the error was reasonable to make rather than 
being obvious doesn't change that.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue32561] Add API to io objects for cache-only reads/writes

[Joshua Bronson]

Change by Joshua Bronson :


--
nosy: +jab

___
Python tracker 

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

[issue14189] C API documentation must document if returned object is a borrowed reference or strong reference

[Joannah Nanjekye]

Change by Joannah Nanjekye :


--
nosy: +nanjekyejoannah

___
Python tracker 

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

[issue41209] Scripts Folder is Empty

[James McCorkindale]

New submission from James McCorkindale :

The Scripts folder is empty and I'm not sure what's wrong. I'm trying to 
install modules and looked it up on the internet and I think I need this folder 
not to be empty. How should i fix this?

Thanks, James

--
components: Windows
messages: 373007
nosy: Jamesss04, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Scripts Folder is Empty
type: behavior
versions: Python 3.8

___
Python tracker 

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

[issue32958] socket module calls with long host names can fail with idna codec error

[Joseph Hackman]

Joseph Hackman  added the comment:

According to the DNS standard, hostnames with more than 63 characters per label 
(the sections between .) are not allowed 
[https://tools.ietf.org/html/rfc1035#section-2.3.1].

That said, enforcing that at the codec level might be the wrong choice. I threw 
together a quick patch moving the limits up to 250, and nothing blew up. It's 
unclear what the general usefulness of such a change would be, since DNS 
servers probably couldn't handle those requests anyway.

As for the original issue, if anybody is still doing something like that, could 
they provide a full example URL? I was unable to reproduce on HTTP (failed in a 
different place), or FTP.

--
nosy: +joseph.hackman

___
Python tracker 

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

[issue40874] Update to libmpdec-2.5.0

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Thanks for the clarification.  I agree this does not seem to be a very big 
deal, if slightly annoying for the packager who will have to deal with it.

--

___
Python tracker 

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

[issue31898] Add a `recommended-packages.txt` file

[Joannah Nanjekye]

Change by Joannah Nanjekye :


--
nosy: +nanjekyejoannah

___
Python tracker 

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

ANN: SciPy 1.5.1

[Tyler Reddy]

Hi all,

On behalf of the SciPy development team I'm pleased to announce
the release of SciPy 1.5.1, which is a bug fix release.

Sources and binary wheels can be found at:
https://pypi.org/project/scipy/
and at:  https://github.com/scipy/scipy/releases/tag/v1.5.1

One of a few ways to install this release with pip:

pip install scipy==1.5.1

==
SciPy 1.5.1 Release Notes
==

SciPy 1.5.1 is a bug-fix release with no new features
compared to 1.5.0. In particular, an issue where DLL loading
can fail for SciPy wheels on Windows with Python 3.6 has been
fixed.

Authors
===

* Peter Bell
* Loïc Estève
* Philipp Thölke +
* Tyler Reddy
* Paul van Mulbregt
* Pauli Virtanen
* Warren Weckesser

A total of 7 people contributed to this release.
People with a "+" by their names contributed a patch for the first time.
This list of names is automatically generated, and may not be fully
complete.

Issues closed for 1.5.1


* `#9108 `__: documentation:
scipy.spatial.KDTree vs. scipy.spatial.cKDTree
* `#12218 `__: Type error in
stats.ks_2samp when alternative != 'two-sided-
* `#12406 `__: DOC: Docstring
in stats.anderson function not properly formatted
* `#12418 `__: Regression in
hierarchy.dendogram


Pull requests for 1.5.1


* `#12280 `__: BUG: Fixes
gh-12218, TypeError converting int to float inside...
* `#12336 `__: BUG: KDTree
should reject complex input points
* `#12344 `__: MAINT: Don't use
numpy's aliases of Python builtin objects.
* `#12407 `__: DOC: Fix
docstring for dist param in anderson function
* `#12410 `__: CI: Run the Azure
Windows Python36 32bit tests with mode 'fast'
* `#12421 `__: Fix regression in
scipy 1.5.0 in dendogram when labels is a numpy...
* `#12462 `__: MAINT: move
distributor_init import after __config__ import


Checksums
=

MD5
~~~

b71e8115d61c604cc65e5ecc556131f6
 scipy-1.5.1-cp36-cp36m-macosx_10_9_x86_64.whl
0190c11f75ed28a7e56050182ca95a18  scipy-1.5.1-cp36-cp36m-manylinux1_i686.whl
c4dd717a3a0c3fe64380039e4fda663f
 scipy-1.5.1-cp36-cp36m-manylinux1_x86_64.whl
baad02c954e85e7fd3d4a9fd49fc6359  scipy-1.5.1-cp36-cp36m-win32.whl
9edc3a9aedf6bffccb17101c905126d0  scipy-1.5.1-cp36-cp36m-win_amd64.whl
83479a6de66a6bc2da0990fa71cf3cec
 scipy-1.5.1-cp37-cp37m-macosx_10_9_x86_64.whl
f2d5c8713b087545c5ec19cc8e46212c  scipy-1.5.1-cp37-cp37m-manylinux1_i686.whl
6a18a9636342574ae55d3a80136c550c
 scipy-1.5.1-cp37-cp37m-manylinux1_x86_64.whl
5da68faf5b32c539d1cb5390df010cc8  scipy-1.5.1-cp37-cp37m-win32.whl
2ca8c59a6712e91ac78b8540ab694b53  scipy-1.5.1-cp37-cp37m-win_amd64.whl
cceb059d0cf6a70e62452deb5571ba00
 scipy-1.5.1-cp38-cp38-macosx_10_9_x86_64.whl
8a65b30ccd72409704d3300922da2b7f  scipy-1.5.1-cp38-cp38-manylinux1_i686.whl
00181f52a7917d1c3d50e42a76a6df96
 scipy-1.5.1-cp38-cp38-manylinux1_x86_64.whl
2aa8b6ddceaebe7b33d71dbad0e208cc  scipy-1.5.1-cp38-cp38-win32.whl
a626585d08b0991c8f2df0caacdf9997  scipy-1.5.1-cp38-cp38-win_amd64.whl
f6986798b7d22ffc5f80b749d7ec27ca  scipy-1.5.1.tar.gz
e126a1a0ff954b924a8273faa7437fe3  scipy-1.5.1.tar.xz
3bce82b23d45d1a96ee270f23176746a  scipy-1.5.1.zip

SHA256
~~

058e84930407927f71963a4ad8c1dc96c4d2d075636a68578195648c81f78810
 scipy-1.5.1-cp36-cp36m-macosx_10_9_x86_64.whl
7908c85854c5b5b6d3ce7fefafac1ca3e23ff9ac41edabc2d46ae5dc9fa070ac
 scipy-1.5.1-cp36-cp36m-manylinux1_i686.whl
8302d69fb1528ea7c7f2a1ea640d354c981b6eb8192d1c175349874209397604
 scipy-1.5.1-cp36-cp36m-manylinux1_x86_64.whl
35d042d6499caf1a5d171baed0ebf01eb665b7af2ad98a8ff1b0e6e783654540
 scipy-1.5.1-cp36-cp36m-win32.whl
5e0bb43ff581811ab7f27425f6b96c1ddf7591ccad2e486c9af0b910c18f7185
 scipy-1.5.1-cp36-cp36m-win_amd64.whl
b4858ccbd88f4b53950fb9fc0069c1d9fea83d7cff2382e1d8b023d3f4883014
 scipy-1.5.1-cp37-cp37m-macosx_10_9_x86_64.whl
eb46d8b5947ca27b0bc972cecfba8130f088a83ab3d08c1a6033d9070b3046b3
 scipy-1.5.1-cp37-cp37m-manylinux1_i686.whl
fff15df01bef1243468be60c55178ed7576270b200aab08a7ffd5b8e0bbc340c
 scipy-1.5.1-cp37-cp37m-manylinux1_x86_64.whl
81859ed3aad620752dd2c07c32b5d3a80a0d47c5e3813904621954a78a0ae899
 scipy-1.5.1-cp37-cp37m-win32.whl
c05c6fe76228cc13c5214e9faf5f2a871a1da54473bc417ab9da310d0e5fff8b
 scipy-1.5.1-cp37-cp37m-win_amd64.whl
71742889393a724dfce755b6b61228677873d269a4234e51ddaf08b998433c91
 scipy-1.5.1-cp38-cp38-macosx_10_9_x86_64.whl
9323d268775991b79690f7b9a28a4e8b8c4f2b160ed9f8a90123127314e2d3c1
 scipy-1.5.1-cp38-cp38-manylinux1_i686.whl

[issue18080] setting CC no longer overrides default linker for extension module builds on OS X

[Jason R. Coombs]

Jason R. Coombs  added the comment:

Well, the issue is potentially ignorable, especially if distutils is deprecated 
and removed from CPython. Alternately, CPython could adopt the [patch from 
distutils](https://github.com/pypa/distutils/pull/1/commits/c3a052aefbba0d5fda10790e676223c0dc12f0ed)
 that corrects the issue. Would you like me to file a separate bug for this 
issue? Or apply that patch? Or something else?

--

___
Python tracker 

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

[issue40874] Update to libmpdec-2.5.0

[Stefan Krah]

Stefan Krah  added the comment:

> In any case, I would have had a hard time giving a competent opinion on this 
> issue.

Essentially it's a really simple Linux packaging issue for the
external libmpdec.  To have the exact same behavior for the external
libmpdec as for the included libmpdec, packagers must use:

  3.8  <--> 2.4.2
  3.9  <--> 2.5.0


ArchLinux had no problems.  Debian, and by extension Ubuntu, requires
3.8 and 3.9 to be on the same system during a transitional period, as
pointed out in msg372928 (which is really the most important message
of this whole thread).  

The commit that pinned _decimal to libmpdec version 2.5.0 broke this
use case, but there are workarounds.


My stance is that it is important that libmpdec is pinned so distros
don't use a divergent version.  Since there are multiple mitigations
for Debian, I don't feel particularly guilty.


Review of the commit that pinned 2.5.0 would have led to the exact
same outcome: I would have pointed that out on GitHub.

Note that with the Debian scheme there is never a good time to
update libmpdec, regardless of the release cycle.

--

___
Python tracker 

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

[issue37458] ast: Different FormattedValue expressions have same col_offset information

[Eric V. Smith]

Eric V. Smith  added the comment:

I think waiting until we decide what to do with the parser makes sense. This 
problem has been around for a while, and while it's unfortunate I don't think 
it's worth heroic measures to fix.

--

___
Python tracker 

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

[issue40874] Update to libmpdec-2.5.0

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Hmm, I'm only taking notice of this comment thread now.

(sorry, but due to spam filtering issues I only receive bpo e-mail 
notifications intermittently... and that's despite having tried two separate 
e-mail providers which otherwise give me no problems :-/)

In any case, I would have had a hard time giving a competent opinion on this 
issue.  But I'm a bit saddened by how heated the discussion went.  Hopefully 
this is all over.

--

___
Python tracker 

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

Re: Assign Excel cell value from Datepicker widget Selection using Python

[DL Neil via Python-list]

On 5/07/20 5:20 AM, narenchund...@gmail.com wrote:

I am trying to assign a widget to an excel cell. Convertion wont help me.Thanks



That's true - and false!

Unfortunately, these posts have revealed little about you and your level 
of understanding of Python specifically, and computer programming more 
generally. This lack of information creates an impression that you are 
not used to working within a professional team. The example could easily 
be a professional task, or a student assignment. In the latter case, we 
will be happy to help you learn, but are not keen to 'do your homework'. 
(also, please be advised that there is a separate Python-Tutor 
Discussion List)


To solve this problem requires an understanding of Python and how it 
works, plus ipy/Jupiter and their widgets, and Excel as seen through the 
openpyxl library. It is not a trivial task!



To the problem:-

First, we must understand how ipy.widgets work 
(https://minrk-ipywidgets.readthedocs.io/en/latest/examples/Widget%20Basics.html). 
A widget is not like Python's basic input() which displays a "prompt" 
and collects a (str) value for return across an assignment statement, eg


amount = input( "How much? " )

A widget is an instantiated class, and as such we must consider its 
"attributes" and "methods" - which has the pre-requisite of 
understanding how Python works with "objects".


The web.ref describes the value property. So, if the DatePicker()'s 
result is assigned to an intermediate variable, that could be 
printed-out, together with its type(). This will provide valuable 
information.


Then, assign the value property of that variable (which is actually an 
object; that class instantiated) to another intermediate variable - 
let's call that returned_date, and print its value and type.


Finally, we should be able to reconcile the above data-items with the 
workbook's format/type demands, so that the date can be assigned to the 
B2 cell...



Let us know how you get on (copy-paste any relevant code and errors into 
your email message, if relevant)...

--
Regards =dn
--
https://mail.python.org/mailman/listinfo/python-list

[issue39184] Many command execution functions are not raising auditing events

[Saiyang Gou]

Saiyang Gou  added the comment:

Since the original problem (command execution functions missing audit events) 
is already solved, we can close this issue now. Further discussions on 
additional audit hooks (e.g. for the networking modules) could go to issue 
37363.

--

___
Python tracker 

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

[issue39184] Many command execution functions are not raising auditing events

[Saiyang Gou]

Change by Saiyang Gou :


--
pull_requests: +20473
pull_request: https://github.com/python/cpython/pull/21322

___
Python tracker 

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

Re: Formal Question to Steering Council (re recent PEP8 changes)

[Ethan Furman]

On 07/04/2020 10:32 AM, Random832 wrote:


I said obvious because even if it was not obvious from the commit message 
itself, it had *already been explained* in the thread on the other mailing list


That would require Michael to have been reading the other mailing list to know 
that.  Just because the information is out there, doesn't mean everybody has 
seen it.

--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list

[issue37363] Additional PEP578 hooks

[Saiyang Gou]

Change by Saiyang Gou :


--
nosy: +gousaiyang
nosy_count: 4.0 -> 5.0
pull_requests: +20472
pull_request: https://github.com/python/cpython/pull/21321

___
Python tracker 

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

[issue1635741] Py_Finalize() doesn't clear all Python objects at exit

[mohamed koubaa]

Change by mohamed koubaa :


--
nosy: +koubaa
nosy_count: 16.0 -> 17.0
pull_requests: +20471
pull_request: https://github.com/python/cpython/pull/21319

___
Python tracker 

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

[issue41177] ConvertingList and ConvertingTuple lack iterators and ConvertingDict lacks items()

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

If you are going to make them public general purpose classes you need to 
implement also support of slices, __reversed__(), index(), remove(), count(), 
sort(), copy() in ConvertingList and more methods in ConvertingTuple, and 
ConvertingDict.

If it is not goal then I think that no any changes are needed. If they are 
internal classes they needed only features which are used internally by the 
module code.

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue41204] Use of unitialized variable `fields` along error path in code generated from asdl_c.py

[STINNER Victor]

STINNER Victor  added the comment:

Thanks for the report, it's not fixed.

--
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

[issue41204] Use of unitialized variable `fields` along error path in code generated from asdl_c.py

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 1f76453173267887ed05bb3783e862cb22365ae8 by Victor Stinner in 
branch 'master':
bpo-41204: Fix compiler warning in ast_type_init() (GH-21307)
https://github.com/python/cpython/commit/1f76453173267887ed05bb3783e862cb22365ae8


--

___
Python tracker 

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

[issue41177] ConvertingList and ConvertingTuple lack iterators and ConvertingDict lacks items()

[Vinay Sajip]

Vinay Sajip  added the comment:

> I think the other issue here is that the ConvertingX classes aren't 
> documented apart from comments in the code where they are defined.

That's deliberate - they're considered an internal implementation detail.

--

___
Python tracker 

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

[issue39542] Cleanup object.h header

[Stefan Krah]

Stefan Krah  added the comment:

I have no opinion about this commit (I did not benchmark anything,
but I wouldn't be surprised if Victor did).

I do have the opinion that unreviewed commits occur quite frequently
and nearly every committer has made some (or a lot), including the
committers who mention them.

They are not inherently bad, so I hope we can focus on the outcome.

--

___
Python tracker 

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

[issue39542] Cleanup object.h header

[Christian Heimes]

Change by Christian Heimes :


--
nosy:  -christian.heimes

___
Python tracker 

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

[issue39542] Cleanup object.h header

[Christian Heimes]

Christian Heimes  added the comment:

Stefan, stop it! I feel offended and harassed by you. Do not ever talk to me in 
public, private, or even insinuate to reference to my person in any public 
conversation.

--

___
Python tracker 

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

Re: Formal Question to Steering Council (re recent PEP8 changes)

[Random832]

On Sat, Jul 4, 2020, at 12:33, o1bigtenor wrote:
> I would point out that even suggesting that the issue be a *obvious 
> factual mistake* only serves to prove that you didn't read the thing 
> and I, at least, wonder why you're offering an opinion on any part of 
> the discussion. 

I said obvious because even if it was not obvious from the commit message 
itself, it had *already been explained* in the thread on the other mailing list 
by the time Michael Torrie posted (July 02 15:14) his assertion of "The fact 
she would conflate an author's name with some kind of race-related thing". I 
even recall raising the question of whether he had in fact read any of that 
discussion. After all, Ethan Furman made the same mistake in his original post, 
and was corrected *very* early on in the discussion, so repeating it several 
days later makes little sense.

*Regardless whether you agree or not* with the premise that "standard english" 
is a subtle means of enforcing white supremacy, the fact that some people do 
believe that is a far more plausible explanation for the statement in the 
commit message than the fact that one of the authors happens to have been named 
"White", and the idea that it was because of the latter only exists in the 
imagination of those determined to assume the worst of the person who wrote the 
commit message.





On Tue, Jun 30, 2020, at 08:44, Ethan Furman wrote:
> On 06/30/2020 05:03 AM, Łukasz Langa wrote:
> > 
> >> On 30 Jun 2020, at 12:44, Ethan Furman  >> > wrote:
> >>
> >> Of course I don't know if Keara or Guido knew any of this, but it 
> >> certainly feels to me that the commit message is ostracizing an entire 
> >> family line because they had the misfortune to have the wrong last name.  
> >> In fact, it seems like Strunk & White is making changes to be inclusive in 
> >> its advice -- exactly what I would have thought we wanted on our side 
> >> ("our side" being the diverse and welcoming side).
> > 
> > In any case, saying that Keara and Guido mistook the family name of one of 
> > the authors for skin color feels derogatory.
> 
> My apologies, that was not my intent.  As I said, I never knew what it 
> was until today (er, yesterday now).
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Assign Excel cell value from Datepicker widget Selection using Python

[narenchunduri]

I am trying to assign a widget to an excel cell. Convertion wont help me.Thanks
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue39542] Cleanup object.h header

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Let's just focus on getting it fixed before 3.9 goes out.

--

___
Python tracker 

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

Re: Formal Question to Steering Council (re recent PEP8 changes)

[o1bigtenor]

On Sat, Jul 4, 2020 at 10:41 AM Random832  wrote:

> On Fri, Jul 3, 2020, at 08:48, Rhodri James wrote:
> > As I said in my preamble, it doesn't matter whether you believe that is
> > true or think it's utter bollocks.  I asked the question to get the
> > Steering Council's opinion, not anyone else's.  If you collectively
> > really must rehash the arguments again, please have the decency to do so
> > in a different thread.
>
> The idea that the statement was in any way related to one of the authors
> being named "White" was an *obvious factual mistake* in your post.
> Regardless of anything else, that is *not a matter of opinion*, so saying
> whose opinion you wanted is irrelevant.
>

Copied from the commit:

Instead of requiring that comments be written in Strunk & White Standard
English, require instead that English-language comments be clear and easily
understandable by other English speakers. This accomplishes the same goal
without upholding relics of white supremacy. Many native English speakers
do not use Standard English as their native dialect, so requiring
conformation to Standard English centers whiteness in an inappropriate and
unnecessary way, and can alienate and put up barriers for people of color
and those whose native dialect of English is not Standard English. This
change is a simple way to correct that while maintaining the original
intent of the requirement.

I would point out that even suggesting that the issue be a *obvious factual
mistake* only serves to prove that you didn't read the thing and I, at
least, wonder why you're offering an opinion on any part of the discussion.

IMO the language in the commit is inflammatory and should either be revised
or it and the commit removed for its clear intellectual disfunction.

Regards

Regards
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Formal Question to Steering Council (re recent PEP8 changes)

[Random832]

On Fri, Jul 3, 2020, at 08:48, Rhodri James wrote:
> As I said in my preamble, it doesn't matter whether you believe that is 
> true or think it's utter bollocks.  I asked the question to get the 
> Steering Council's opinion, not anyone else's.  If you collectively 
> really must rehash the arguments again, please have the decency to do so 
> in a different thread.

The idea that the statement was in any way related to one of the authors being 
named "White" was an *obvious factual mistake* in your post. Regardless of 
anything else, that is *not a matter of opinion*, so saying whose opinion you 
wanted is irrelevant.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue41204] Use of unitialized variable `fields` along error path in code generated from asdl_c.py

[Batuhan Taskaya]

Change by Batuhan Taskaya :


--
nosy: +BTaskaya

___
Python tracker 

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

[issue37458] ast: Different FormattedValue expressions have same col_offset information

[Batuhan Taskaya]

Change by Batuhan Taskaya :


--
nosy: +BTaskaya

___
Python tracker 

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

[issue41195] Interface to OpenSSL's security level

[Antoine Pitrou]

Antoine Pitrou  added the comment:

No strong feelings on this, but the OpenSSL runtime is not always packaged by a 
Linux distribution.  (macOS, Windows and Anaconda come to mind)

If one wants to retain the setter facility, one could raise a RuntimeWarning if 
the user *lowers* the actual security level.

--
nosy: +pitrou

___
Python tracker 

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

[issue37458] ast: Different FormattedValue expressions have same col_offset information

[Lysandros Nikolaou]

Lysandros Nikolaou  added the comment:

> I still see this problem with 3.10, which I thought might have fixed this.
Nope, that's still true in 3.10.

>I'm working on overhauling how these are calculated. But it's complex, and is 
>taking a while.
In short, the FormattedValue nodes all have the exact same lineno's and 
col_offset's, which are also identical to those of the enclosing JoinedStr 
node. These values are equal to lineno and col_offset of the first STRING token 
and end_lineno and end_col_offset of the last STRING token (note that the 
grammar accepts a STRING+ node).

> any ideas on this?
Moving f-string parsing to the parser, which we've been talking about lately, 
would solve this. But this will probably take some time, since I currently do 
not have the time. It's probably going to be a good project for this coming 
fall.

Another alternative, in case we don't want to wait until then, would be for the 
handwritten f-string parser to have its own instances of a lineno and 
col_offset, so that they can be used when the FormattedValue nodes are created. 
This would probably also require some effort though, so I'm not sure we want to 
do it, before we really know if we're gonnna proceed with the "moving f-string 
parsing to PEG" project.

--

___
Python tracker 

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

[issue41128] Signal handlers should not hang during blocked main thread

[Josef Havránek]

Change by Josef Havránek :


--
nosy:  -Josef Havránek

___
Python tracker 

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

[issue41208] An exploitable segmentation fault in marshal module

[Iman Sharafodin]

New submission from Iman Sharafodin :

It seems that all versions of Python 3 are vulnerable to de-marshaling the 
attached file (Python file is included). I've tested on Python 3.10.0a0 
(heads/master:b40e434, Jul  4 2020), Python 3.6.11 and Python 3.7.2. This is 
due to lack of proper validation at Objects/tupleobject.c:413 
(heads/master:b40e434).
 
This is the result of GDB's Exploitable plugin (it's exploitable):
Description: Access violation during branch instruction
Short description: BranchAv (4/22)
Hash: e04b830dfb409a8bbf67bff96ff0df44.4d31b48b56e0c02ed51520182d91a457
Exploitability Classification: EXPLOITABLE
Explanation: The target crashed on a branch instruction, which may indicate 
that the control flow is tainted.
Other tags: AccessViolation (21/22)

--
components: Interpreter Core
files: Crash.zip
messages: 372990
nosy: Iman Sharafodin
priority: normal
severity: normal
status: open
title: An exploitable segmentation fault in marshal module
type: security
versions: Python 3.10
Added file: https://bugs.python.org/file49295/Crash.zip

___
Python tracker 

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

[issue37458] ast: Different FormattedValue expressions have same col_offset information

[Eric V. Smith]

Eric V. Smith  added the comment:

I still see this problem with 3.10, which I thought might have fixed this.

@lys.nikolaou: any ideas on this?

--
components: +Interpreter Core -Library (Lib)
nosy: +lys.nikolaou
versions: +Python 3.10 -Python 3.7, Python 3.8

___
Python tracker 

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

[issue40275] test.support has way too many imports

[hai shi]

Change by hai shi :


--
pull_requests: +20470
pull_request: https://github.com/python/cpython/pull/21317

___
Python tracker 

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

[issue41203] Replace references to OS X in documentation with macOS

[Ronald Oussoren]

Ronald Oussoren  added the comment:

As I mentioned in my review on the PR I'd prefer to keep using Macintosh where 
it is used to denote to MacOS 9 and earlier. Both out of nostalgia and because 
that older OS was substantially different from the current OS.

--

___
Python tracker 

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

[issue41203] Replace references to OS X in documentation with macOS

[Patrick Reader]

Change by Patrick Reader :


--
keywords: +patch
pull_requests: +20468
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/21316

___
Python tracker 

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

[issue40275] test.support has way too many imports

[hai shi]

Change by hai shi :


--
pull_requests: +20467
pull_request: https://github.com/python/cpython/pull/21315

___
Python tracker 

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

[issue41203] Replace references to OS X in documentation with macOS

[Patrick Reader]

Patrick Reader  added the comment:

While I'm at it, should I change "Macintosh" to "Mac"?

--

___
Python tracker 

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

[issue41205] Documentation Decimal power 0 to the 0 is Nan (versus 0 to the 0 which is 1)

[Stefan Krah]

Stefan Krah  added the comment:

Agreed, and it's even slightly worse with the ROUND_FLOOR special case:

>>> c.rounding = ROUND_FLOOR
>>> +Decimal("-0")
Decimal('-0')
>>> 

That's why there are three slightly different methods for applying the
context:

   1) context.create_decimal() ==> special case for NaN payloads.

   2) context.apply() (private method) ==> no special cases at all.

   3) Decimal.plus() ==> ROUND_FLOOR special case.

--

___
Python tracker 

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

[issue41191] PyType_FromModuleAndSpec is not mentioned in 3.9 What's new

[Dong-hee Na]

Change by Dong-hee Na :


--
nosy: +petr.viktorin, vstinner

___
Python tracker 

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

[issue40275] test.support has way too many imports

[hai shi]

Change by hai shi :


--
pull_requests: +20466
pull_request: https://github.com/python/cpython/pull/21314

___
Python tracker 

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

[issue41203] Replace references to OS X in documentation with macOS

[Patrick Reader]

Patrick Reader  added the comment:

I'm working on it

--

___
Python tracker 

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

[issue39542] Cleanup object.h header

[Stefan Krah]

Stefan Krah  added the comment:

Ah, I see that the subject has already been answered in the negative:

https://discuss.python.org/t/make-code-review-mandatory/4174

He must have forgotten.

--

___
Python tracker 

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

[issue39542] Cleanup object.h header

[Stefan Krah]

Stefan Krah  added the comment:

Christian Heimes has expressed an interest (quite rudely) in unreviewed commits 
elsewhere.  I wonder if that applies to everyone regardless of employer.

--
nosy: +christian.heimes, skrah

___
Python tracker 

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

[issue41205] Documentation Decimal power 0 to the 0 is Nan (versus 0 to the 0 which is 1)

[Mark Dickinson]

Mark Dickinson  added the comment:

I agree that the result is surprising and should be noted in the docs; we 
shouldn't expect all the decimal users to be familiar with the specification. 
Some of the other differences with float arithmetic *are* noted (e.g., the 
behaviour of `//` and `%`), but apparently not this one. We do document the 
behaviour of these corner cases for `math.pow`.

The part that I find really odd is that the specification says that 
`Decimal("inf")**Decimal(0)` is `1`. Treating one of 0**0 and inf**0 as 
undefined but not the other seems inconsistent to me. We'd probably want to 
note the behaviour of inf**0 in the docs, too. (I tried to argue with Mike 
Cowlishaw about this, but I lost.)

I'm not sure whether just noting this in the "power" documentation is enough: 
it's not clear to me that users using the ** operator would think to check the 
docs for the "power" method.

The other weirdly non-IEEE 754 behaviour (again, mandated by the standard) that 
bugs me from time to time is that the unary `-` and `+` operators will never 
give negative zero: Decimal("-0.0") and -Decimal("0.0") are not the same thing. 
That one's probably worth noting, too.

--

___
Python tracker 

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

[issue41203] Replace references to OS X in documentation with macOS

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Would you submit at PR>

--
nosy: +rhettinger
versions: +Python 3.10, Python 3.9

___
Python tracker 

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

[issue41205] Documentation Decimal power 0 to the 0 is Nan (versus 0 to the 0 which is 1)

[JD-Veiga]

JD-Veiga  added the comment:

Well, it is the way that it has been defined in `decimal` package and in the 
document that inspired this package (IBM's General Decimal Arithmetic 
Specification, The General Decimal Arithmetic Specification: 
http://speleotrove.com/decimal/decarith.html).

--

___
Python tracker 

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