Re: [Python-Dev] The devguide is now hosted on GitHub

[Benjamin Peterson]

Should we just make the RTD one canonical and serve redirects on
docs.python.org?

On Fri, Jul 22, 2016, at 13:04, Brett Cannon wrote:
> https://github.com/python/devguide
> 
> I have also moved all issues over as well and hooked up Read The Docs so
> that there's a mirror which is always up-to-date (vs.
> docs.python.org/devguide which is on a cronjob).
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/benjamin%40python.org
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Convert from unsigned long long to PyLong

[Tian JiaLin]

Hey Guys,

I found the mistake I made, basically I'm using a tool called Sentry to
capture the exceptions.
The value returned from the Python is 2^64-1, which is -1 from
mysql_affected_rows.
Sentry is using JSON format as the a kind of storage, apparently the MAX
SAFE INTEGER

is
2^53 -1.

Sorry for the indeliberated report of this issue and thanks for all of you
helps.

On Sat, Jul 23, 2016 at 12:06 AM, Tian JiaLin 
wrote:

> Yes, you are right.  Definitely "long" in Python can represent a number
> much bigger than the native.
>
> But the range of returned value from mysql_affected_rows within 0 ~ 2^64-1.
> No matter how it's converted, the converted value in Python also should in
> the range of 0 ~ 2^64 - 1.
>
> On Fri, Jul 22, 2016 at 11:50 PM, Eric Snow 
> wrote:
>
>> On Fri, Jul 22, 2016 at 3:02 AM, Stefan Ring  wrote:
>> > So to sum this up, you claim that PyLong_FromUnsignedLongLong can
>> > somehow produce a number larger than the value range of a 64 bit
>> > number (0x10180). I have a hard time believing this.
>>
>> Perhaps I misunderstood your meaning, but Python's integers (AKA
>> "PyLong") can be bigger that a machine-native integer (e.g. 64 bits):
>>
>> "All integers are implemented as “long” integer objects of *arbitrary
>> size*." (emphasis mine)
>>
>> (https://docs.python.org/3.5//c-api/long.html)
>>
>> -eric
>>
>
>
>
> --
> kenshin
>
> http://kenbeit.com
> Just Follow Your Heart
>



-- 
kenshin

http://kenbeit.com
Just Follow Your Heart
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Should we fix these errors?

[Christian Heimes]

On 2016-07-22 17:31, Chris Angelico wrote:
> On Sat, Jul 23, 2016 at 12:36 AM, Guido van Rossum  wrote:
>> Somebody did some research and found some bugs in CPython (IIUC). The
>> published some questionable fragments. If there's a volunteer we could
>> probably easily fix these. (I know we already have occasional Coverity
>> scans and there are other tools too (anybody try lgtm yet?) But this
>> seems honest research (also Python leaves Ruby in the dust :-):
>>
>> http://www.viva64.com/en/b/0414/
> 
> First and foremost: All of these purported bugs appear to have been
> found by compiling on Windows. Does Coverity test a Windows build? If
> not, can we get it to? These look like the exact types of errors that
> Coverity *would* discover.

No, it doesn't. The Coverity Scan builds only run on X86_64 Linux
platforms. When I took over Coverity Scan for CPython many years ago it
was not possible to support multiple platforms and target with the free
edition. I never tried to upload builds from different platforms because
I feared that it might play havoc with the scan history. Should I check
with Coverity again?

Some of these issues have been found by Coverity and I even have patches
for them, e.g. N6 is CID#1299595. I have 13 patches that I haven't
published and merged yet. None of the issues is critical, though. Since
I forgot how to use hg I have been waiting for the github migration.

Christian
From f84cfa464e4b7d03776afabe9c0819d491c5617b Mon Sep 17 00:00:00 2001
From: Christian Heimes 
Date: Fri, 19 Feb 2016 16:22:23 +0100
Subject: [PATCH 04/13] Fix dereferencing before NULL check in
 _PyState_AddModule()

_PyState_AddModule() accesses a member of PyModuleDef* def first and
then check def for NULL. The other way around is right.

CID 1299595
---
 Python/pystate.c | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/Python/pystate.c b/Python/pystate.c
index ba4dd4c2b5f37ca20f8b9c5afb30053b074f2e50..3fe8ff486ed6838baa92597060af8bcc0ca7e356 100644
--- a/Python/pystate.c
+++ b/Python/pystate.c
@@ -283,14 +283,15 @@ int
 _PyState_AddModule(PyObject* module, struct PyModuleDef* def)
 {
 PyInterpreterState *state;
-if (def->m_slots) {
-PyErr_SetString(PyExc_SystemError,
-"PyState_AddModule called on module with slots");
-return -1;
-}
-state = GET_INTERP_STATE();
+
 if (!def)
 return -1;
+if (def->m_slots) {
+PyErr_SetString(PyExc_SystemError,
+"PyState_AddModule called on module with slots");
+return -1;
+}
+state = GET_INTERP_STATE();
 if (!state->modules_by_index) {
 state->modules_by_index = PyList_New(0);
 if (!state->modules_by_index)
-- 
2.7.4

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] The devguide is now hosted on GitHub

[Wes Turner]

https://cpython-devguide.readthedocs.io/

Thanks!

On Friday, July 22, 2016, Brett Cannon  wrote:

> It's in the README of the repo, but it's
> http://cpython-devguide.readthedocs.io/
>
> On Fri, 22 Jul 2016 at 14:09 Tres Seaver  > wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On 07/22/2016 04:04 PM, Brett Cannon wrote:
>> > https://github.com/python/devguide
>> >
>> > I have also moved all issues over as well and hooked up Read The Docs
>> > so that there's a mirror which is always up-to-date (vs.
>> > docs.python.org/devguide which is on a cronjob).
>>
>> What is the RTD project name?
>>
>>
>> Tres.
>> - --
>> ===
>> Tres Seaver  +1 540-429-0999  tsea...@palladion.com
>> 
>> Palladion Software   "Excellence by Design"http://palladion.com
>> -BEGIN PGP SIGNATURE-
>> Version: GnuPG v1
>>
>> iQIcBAEBAgAGBQJXkos+AAoJEPKpaDSJE9HY6PAP/AzvI1diFpjjhgQARkmCSvrT
>> MugaShX60PGQDUtTTVCmlZg0Ca6mWgbiaX8JS/kYQuc3SI2JIs+lD/mdCydWKYfx
>> Gzks/rzaS60NkXZjb/yW7Vs+2wQo2EWHC/uzKRDGT7m0yijQW0WQaACgWEtSo0v3
>> 6FzIyxQyYi1UVD10Iw7TWCvYxk2F33QXha5hOsq2N3Zs9Vopkj9p2KeViCxs4UuX
>> VT2hZam/X6ZPkEkHlRkuZM4UpYM3Zt5+dmrODI5ieXjsUngvfcVhVvay33tStlH9
>> DJYGPgAWCzNkiScDCWk8+iXkLqJAQusVms6HbgQcToRj2ySbWdtn+EMFp9Y+baGl
>> GBFQoiHhj1nw9yFf4pGgO4xRyvwc4vfTs7PJnZnOxLI7STaRL6L5TpXSuFGVN0Sw
>> 6AumK4mzXidK4efpROUGmLcc3SjuB266jmYDPmNmrqKtHXTIycEgwIjSeWFrMXOE
>> zxQ/TeKiAIr05np22LyXFmm64ryaZjoXqkPdo1fHh6rp456t3o2rkxk4ghuMH4xs
>> IA4V/LBW1BlWr+4P+JIDP+vhyZ45J5SHKvX3OY1OaRDyWHHTEA7qSic6x6CKfUWv
>> o7cr0Kx6ehdwmDUGMfzcGUCoWoNrydKlh0PM2UEAyX+e6RY/5sq1NiKRfrHrO17L
>> Mznm6AZXZXi3D8MkEEDa
>> =+fVX
>> -END PGP SIGNATURE-
>>
>> ___
>> Python-Dev mailing list
>> Python-Dev@python.org
>> 
>> https://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe:
>> https://mail.python.org/mailman/options/python-dev/brett%40python.org
>>
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] The devguide is now hosted on GitHub

[Brett Cannon]

It's in the README of the repo, but it's
http://cpython-devguide.readthedocs.io/

On Fri, 22 Jul 2016 at 14:09 Tres Seaver  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 07/22/2016 04:04 PM, Brett Cannon wrote:
> > https://github.com/python/devguide
> >
> > I have also moved all issues over as well and hooked up Read The Docs
> > so that there's a mirror which is always up-to-date (vs.
> > docs.python.org/devguide which is on a cronjob).
>
> What is the RTD project name?
>
>
> Tres.
> - --
> ===
> Tres Seaver  +1 540-429-0999  tsea...@palladion.com
> Palladion Software   "Excellence by Design"http://palladion.com
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
>
> iQIcBAEBAgAGBQJXkos+AAoJEPKpaDSJE9HY6PAP/AzvI1diFpjjhgQARkmCSvrT
> MugaShX60PGQDUtTTVCmlZg0Ca6mWgbiaX8JS/kYQuc3SI2JIs+lD/mdCydWKYfx
> Gzks/rzaS60NkXZjb/yW7Vs+2wQo2EWHC/uzKRDGT7m0yijQW0WQaACgWEtSo0v3
> 6FzIyxQyYi1UVD10Iw7TWCvYxk2F33QXha5hOsq2N3Zs9Vopkj9p2KeViCxs4UuX
> VT2hZam/X6ZPkEkHlRkuZM4UpYM3Zt5+dmrODI5ieXjsUngvfcVhVvay33tStlH9
> DJYGPgAWCzNkiScDCWk8+iXkLqJAQusVms6HbgQcToRj2ySbWdtn+EMFp9Y+baGl
> GBFQoiHhj1nw9yFf4pGgO4xRyvwc4vfTs7PJnZnOxLI7STaRL6L5TpXSuFGVN0Sw
> 6AumK4mzXidK4efpROUGmLcc3SjuB266jmYDPmNmrqKtHXTIycEgwIjSeWFrMXOE
> zxQ/TeKiAIr05np22LyXFmm64ryaZjoXqkPdo1fHh6rp456t3o2rkxk4ghuMH4xs
> IA4V/LBW1BlWr+4P+JIDP+vhyZ45J5SHKvX3OY1OaRDyWHHTEA7qSic6x6CKfUWv
> o7cr0Kx6ehdwmDUGMfzcGUCoWoNrydKlh0PM2UEAyX+e6RY/5sq1NiKRfrHrO17L
> Mznm6AZXZXi3D8MkEEDa
> =+fVX
> -END PGP SIGNATURE-
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/brett%40python.org
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] The devguide is now hosted on GitHub

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/22/2016 04:04 PM, Brett Cannon wrote:
> https://github.com/python/devguide
> 
> I have also moved all issues over as well and hooked up Read The Docs
> so that there's a mirror which is always up-to-date (vs. 
> docs.python.org/devguide which is on a cronjob).

What is the RTD project name?


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJXkos+AAoJEPKpaDSJE9HY6PAP/AzvI1diFpjjhgQARkmCSvrT
MugaShX60PGQDUtTTVCmlZg0Ca6mWgbiaX8JS/kYQuc3SI2JIs+lD/mdCydWKYfx
Gzks/rzaS60NkXZjb/yW7Vs+2wQo2EWHC/uzKRDGT7m0yijQW0WQaACgWEtSo0v3
6FzIyxQyYi1UVD10Iw7TWCvYxk2F33QXha5hOsq2N3Zs9Vopkj9p2KeViCxs4UuX
VT2hZam/X6ZPkEkHlRkuZM4UpYM3Zt5+dmrODI5ieXjsUngvfcVhVvay33tStlH9
DJYGPgAWCzNkiScDCWk8+iXkLqJAQusVms6HbgQcToRj2ySbWdtn+EMFp9Y+baGl
GBFQoiHhj1nw9yFf4pGgO4xRyvwc4vfTs7PJnZnOxLI7STaRL6L5TpXSuFGVN0Sw
6AumK4mzXidK4efpROUGmLcc3SjuB266jmYDPmNmrqKtHXTIycEgwIjSeWFrMXOE
zxQ/TeKiAIr05np22LyXFmm64ryaZjoXqkPdo1fHh6rp456t3o2rkxk4ghuMH4xs
IA4V/LBW1BlWr+4P+JIDP+vhyZ45J5SHKvX3OY1OaRDyWHHTEA7qSic6x6CKfUWv
o7cr0Kx6ehdwmDUGMfzcGUCoWoNrydKlh0PM2UEAyX+e6RY/5sq1NiKRfrHrO17L
Mznm6AZXZXi3D8MkEEDa
=+fVX
-END PGP SIGNATURE-

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] The devguide is now hosted on GitHub

[Stephane Wirtel]

Congratulations Brett,

Thank you so much for this job.

> On 22 juil. 2016, at 10:04 PM, Brett Cannon  wrote:
> 
> https://github.com/python/devguide
> 
> I have also moved all issues over as well and hooked up Read The Docs so that 
> there's a mirror which is always up-to-date (vs. docs.python.org/devguide 
> which is on a cronjob).
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> https://mail.python.org/mailman/options/python-dev/stephane%40wirtel.be
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] The devguide is now hosted on GitHub

[Eric Snow]

Thanks for doing all this, Brett. :)

-eric

On Fri, Jul 22, 2016 at 2:04 PM, Brett Cannon  wrote:
> https://github.com/python/devguide
>
> I have also moved all issues over as well and hooked up Read The Docs so
> that there's a mirror which is always up-to-date (vs.
> docs.python.org/devguide which is on a cronjob).
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/ericsnowcurrently%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] The devguide is now hosted on GitHub

[Brett Cannon]

https://github.com/python/devguide

I have also moved all issues over as well and hooked up Read The Docs so
that there's a mirror which is always up-to-date (vs.
docs.python.org/devguide which is on a cronjob).
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Should we fix these errors?

[Victor Stinner]

2016-07-22 18:21 GMT+02:00 Random832 :
>> I just fixed it:
>> https://hg.python.org/cpython/rev/6c11f52ab9db
>
> Does INVALID_SOCKET exist on non-windows systems?

Yes, it was already used in almost all places.

When I read again the code, in fact I found other places with "fd < 0"
or "fd = -1". I fixed more code in a second change:
https://hg.python.org/cpython/rev/025281485318

Victor
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Convert from unsigned long long to PyLong

[Random832]

On Fri, Jul 22, 2016, at 11:50, Eric Snow wrote:
> On Fri, Jul 22, 2016 at 3:02 AM, Stefan Ring  wrote:
> > So to sum this up, you claim that PyLong_FromUnsignedLongLong can
> > somehow produce a number larger than the value range of a 64 bit
> > number (0x10180). I have a hard time believing this.
> 
> Perhaps I misunderstood your meaning, but Python's integers (AKA
> "PyLong") can be bigger that a machine-native integer (e.g. 64 bits):

Yes, but you can't (or shouldn't be able to) get those values from a
conversion from a machine-native type such as
PyLong_FromUnsignedLongLong.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Should we fix these errors?

[Random832]

On Fri, Jul 22, 2016, at 11:35, Victor Stinner wrote:
> Oh, the first one is a regression that I introduced in the
> implementation of the PEP 475 (retry syscall on EINTR). I don't think
> that it can be triggered in practice, because socket handles on
> Windows are small numbers, so unlikely to be seen as negative.

The problem as I understand it isn't that handles will be seen as
negative, the problem is that the error return will be seen as
*non*-negative.

> I just fixed it:
> https://hg.python.org/cpython/rev/6c11f52ab9db

Does INVALID_SOCKET exist on non-windows systems? (It's probably safe to
compare against -1, the relevant functions are defined in POSIX as
returning -1 rather than an unspecified negative value)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Convert from unsigned long long to PyLong

[Tian JiaLin]

Yes, you are right.  Definitely "long" in Python can represent a number
much bigger than the native.

But the range of returned value from mysql_affected_rows within 0 ~ 2^64-1.
No matter how it's converted, the converted value in Python also should in
the range of 0 ~ 2^64 - 1.

On Fri, Jul 22, 2016 at 11:50 PM, Eric Snow 
wrote:

> On Fri, Jul 22, 2016 at 3:02 AM, Stefan Ring  wrote:
> > So to sum this up, you claim that PyLong_FromUnsignedLongLong can
> > somehow produce a number larger than the value range of a 64 bit
> > number (0x10180). I have a hard time believing this.
>
> Perhaps I misunderstood your meaning, but Python's integers (AKA
> "PyLong") can be bigger that a machine-native integer (e.g. 64 bits):
>
> "All integers are implemented as “long” integer objects of *arbitrary
> size*." (emphasis mine)
>
> (https://docs.python.org/3.5//c-api/long.html)
>
> -eric
>



-- 
kenshin

http://kenbeit.com
Just Follow Your Heart
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Summary of Python tracker Issues

[Python tracker]

ACTIVITY SUMMARY (2016-07-15 - 2016-07-22)
Python tracker at http://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open5586 (+24)
  closed 33762 (+47)
  total  39348 (+71)

Open issues with patches: 2441 


Issues opened (42)
==

#25507: IDLE: user code 'import tkinter; tkinter.font' should fail
http://bugs.python.org/issue25507  reopened by terry.reedy

#27521: Misleading compress level header on files created with gzip
http://bugs.python.org/issue27521  opened by ddorda

#27524: Update os.path for PEP 519/__fspath__()
http://bugs.python.org/issue27524  opened by brett.cannon

#27526: test_venv.TestEnsurePip fails mysteriously when /tmp is too sm
http://bugs.python.org/issue27526  opened by r.david.murray

#27530: Non-Critical Compiler WARNING: Python Embedding C++11 does not
http://bugs.python.org/issue27530  opened by Daniel Lord

#27534: IDLE: Reduce number and time for user process imports
http://bugs.python.org/issue27534  opened by terry.reedy

#27535: Memory leaks when opening tons of files
http://bugs.python.org/issue27535  opened by Александр 
Карпинский

#27536: Convert readme to reStructuredText
http://bugs.python.org/issue27536  opened by louis.taylor

#27539: negative Fraction ** negative int not normalized
http://bugs.python.org/issue27539  opened by Vedran.Čačić

#27540: msvcrt.ungetwch() calls _ungetch()
http://bugs.python.org/issue27540  opened by arigo

#27541: Repr of collection's subclasses
http://bugs.python.org/issue27541  opened by serhiy.storchaka

#27544: Document the ABCs for instance/subclass checks of dict view ty
http://bugs.python.org/issue27544  opened by story645

#27546: Integrate tkinter and asyncio (and async)
http://bugs.python.org/issue27546  opened by terry.reedy

#27547: Integer Overflow Crash On float(array.array())
http://bugs.python.org/issue27547  opened by pabstersac

#27558: SystemError with bare `raise` in threading or multiprocessing
http://bugs.python.org/issue27558  opened by Romuald

#27561: Warn against subclassing builtins, and overriding their method
http://bugs.python.org/issue27561  opened by Kirk Hansen

#27562: Import error encodings (Windows xp compatibility)
http://bugs.python.org/issue27562  opened by Iovan Irinel

#27564: 2.7.12 Windows Installer package broken.
http://bugs.python.org/issue27564  opened by busfault

#27565: Offer error context manager for code.interact
http://bugs.python.org/issue27565  opened by Claudiu Saftoiu

#27566: Tools/freeze/winmakemakefile.py clean target should use 'del' 
http://bugs.python.org/issue27566  opened by David D

#27568: "HTTPoxy", use of HTTP_PROXY flag supplied by attacker in CGI 
http://bugs.python.org/issue27568  opened by remram

#27569: Windows install problems
http://bugs.python.org/issue27569  opened by ricardoe

#27570: Avoid memcpy(. . ., NULL, 0) etc calls
http://bugs.python.org/issue27570  opened by martin.panter

#27572: Support bytes-like objects when base is given to int()
http://bugs.python.org/issue27572  opened by xiang.zhang

#27573: code.interact() should print an exit message
http://bugs.python.org/issue27573  opened by steven.daprano

#27574: Faster parsing keyword arguments
http://bugs.python.org/issue27574  opened by serhiy.storchaka

#27575: dict viewkeys intersection slow for large dicts
http://bugs.python.org/issue27575  opened by David Su2

#27576: An unexpected difference between dict and OrderedDict
http://bugs.python.org/issue27576  opened by belopolsky

#27577: Make implementation and doc of tuple and list more compliant
http://bugs.python.org/issue27577  opened by xiang.zhang

#27578: inspect.findsource raises exception with empty __init__.py
http://bugs.python.org/issue27578  opened by Alexander Todorov

#27579: Add a tutorial for AsyncIO in the documentation
http://bugs.python.org/issue27579  opened by matrixise

#27580: CSV Null Byte Error
http://bugs.python.org/issue27580  opened by bobbyocean

#27581: Fix overflow check in PySequence_Tuple
http://bugs.python.org/issue27581  opened by xiang.zhang

#27582: Mispositioned SyntaxError caret for unknown code points
http://bugs.python.org/issue27582  opened by ncoghlan

#27583: configparser: modifying default_section at runtime
http://bugs.python.org/issue27583  opened by rk

#27584: New addition of vSockets to the python socket module
http://bugs.python.org/issue27584  opened by Cathy Avery

#27585: asyncio.Lock deadlock after cancellation
http://bugs.python.org/issue27585  opened by sss

#27587: Issues, reported by PVS-Studio static analyzer
http://bugs.python.org/issue27587  opened by pavel-belikov

#27588: Type (typing) objects are hashable and comparable for equality
http://bugs.python.org/issue27588  opened by Gareth.Rees

#27589: asyncio doc: issue in as_completed() doc
http://bugs.python.org/issue27589  opened by haypo

#27590: tarfile module next() method hides 

Re: [Python-Dev] Convert from unsigned long long to PyLong

[Eric Snow]

On Fri, Jul 22, 2016 at 3:02 AM, Stefan Ring  wrote:
> So to sum this up, you claim that PyLong_FromUnsignedLongLong can
> somehow produce a number larger than the value range of a 64 bit
> number (0x10180). I have a hard time believing this.

Perhaps I misunderstood your meaning, but Python's integers (AKA
"PyLong") can be bigger that a machine-native integer (e.g. 64 bits):

"All integers are implemented as “long” integer objects of *arbitrary
size*." (emphasis mine)

(https://docs.python.org/3.5//c-api/long.html)

-eric
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Should we fix these errors?

[Victor Stinner]

Oh, the first one is a regression that I introduced in the
implementation of the PEP 475 (retry syscall on EINTR). I don't think
that it can be triggered in practice, because socket handles on
Windows are small numbers, so unlikely to be seen as negative.

I just fixed it:
https://hg.python.org/cpython/rev/6c11f52ab9db

Victor

2016-07-22 16:36 GMT+02:00 Guido van Rossum :
> Somebody did some research and found some bugs in CPython (IIUC). The
> published some questionable fragments. If there's a volunteer we could
> probably easily fix these. (I know we already have occasional Coverity
> scans and there are other tools too (anybody try lgtm yet?) But this
> seems honest research (also Python leaves Ruby in the dust :-):
>
> http://www.viva64.com/en/b/0414/
>
> --
> --Guido van Rossum (python.org/~guido)
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> https://mail.python.org/mailman/options/python-dev/victor.stinner%40gmail.com
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Should we fix these errors?

[Chris Angelico]

On Sat, Jul 23, 2016 at 12:36 AM, Guido van Rossum  wrote:
> Somebody did some research and found some bugs in CPython (IIUC). The
> published some questionable fragments. If there's a volunteer we could
> probably easily fix these. (I know we already have occasional Coverity
> scans and there are other tools too (anybody try lgtm yet?) But this
> seems honest research (also Python leaves Ruby in the dust :-):
>
> http://www.viva64.com/en/b/0414/

First and foremost: All of these purported bugs appear to have been
found by compiling on Windows. Does Coverity test a Windows build? If
not, can we get it to? These look like the exact types of errors that
Coverity *would* discover.

Fragment N1 is accurate in current Python. (Although the wording of
the report leaves something to be desired. "The SOCKET type in Windows
is unsigned, so comparing it against null is meaningless." - only "x <
0" (not null) is meaningless.) It's lines 1702 and 2026 in current
Python. What's the best solution? Create a macro VALID_SOCKET with two
different definitions, one using "x < 0" and the other using "x !=
INVALID_SOCKET"?

Fragment N2 doesn't appear to be in CPython 3.6 though. I can't find a
file called a_print.c, nor anything with ASN1_PRINTABLE_type in it.
Third party code? 2.7 only? I've no idea.

(It'd be so much more helpful if file paths had been given instead of
just fragment codes. The error messages include file names without
paths in them.)

Fragment N3: Looks like a legit issue.
http://bugs.python.org/issue27591 created with patch.

Fragment N4, N5, N6a: Can't find bn_lib.c, dh_ameth.c, or cms_env.c in
the cpython tree anywhere. Google suggests that they could be part of
OpenSSL (which could be true of a_print.c from N2). Does Python bundle
any OpenSSL source anywhere?

Fragment N6b (there's a completely unrelated issue paired up in N6): I
don't understand all of what's being said here. The error message
quoted refers to _elementtree.c:917, which is an understandable false
positive for the static checker; the problem can't happen, though,
because line 913 checks for NULL and will construct a new empty list,
and line 916 iterates up to the new list's length, so line 917 can
never be reached if self->extra is NULL. But their analyzer can't know
that. On the other hand, the paragraph and code snippet are referring
to _PyState_AddModule in Modules/pystate.c, which is never called with
def=NULL anywhere else in CPython; unless it's intended to be public,
the check on line 292 could simply be removed.

Conclusion: CPython may need some better static checking in Windows
mode, but probably not desperately enough to buy their product (which
is presumably the point of that blog).

ChrisA
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Convert from unsigned long long to PyLong

[Tian JiaLin]

I know it's hard to believe this, I wish I'm wrong. But after looking into
the code for one week,
I didn't find any other code change the number. I will go through them
again make sure I didn't miss anything.

Thanks for the reply.

On Fri, Jul 22, 2016 at 5:02 PM, Stefan Ring  wrote:

> So to sum this up, you claim that PyLong_FromUnsignedLongLong can
> somehow produce a number larger than the value range of a 64 bit
> number (0x10180). I have a hard time believing this.
>
> Most likely you are looking in the wrong place, mysql_affected_rows
> returns 2^64-1, and some Python code later adds 0x181 to that number.
>



-- 
kenshin

http://kenbeit.com
Just Follow Your Heart
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Should we fix these errors?

[Guido van Rossum]

Somebody did some research and found some bugs in CPython (IIUC). The
published some questionable fragments. If there's a volunteer we could
probably easily fix these. (I know we already have occasional Coverity
scans and there are other tools too (anybody try lgtm yet?) But this
seems honest research (also Python leaves Ruby in the dust :-):

http://www.viva64.com/en/b/0414/

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Convert from unsigned long long to PyLong

[Stefan Ring]

So to sum this up, you claim that PyLong_FromUnsignedLongLong can
somehow produce a number larger than the value range of a 64 bit
number (0x10180). I have a hard time believing this.

Most likely you are looking in the wrong place, mysql_affected_rows
returns 2^64-1, and some Python code later adds 0x181 to that number.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Convert from unsigned long long to PyLong

[Tian JiaLin]

HI There,

Maybe I should not post this in the dev group, but I think it has some
relationship on the Python core.

I'm using MySQLdb as the MySQL client. Recently I got a weird problem of
this library. After looking into it, I suspect the problem may related to
the conversion from unsigned long to PyLongObject.

Here is the detail, If you are familiar with MySQLdb, the following snippet
is a way to query the data from MySQL:


connection = MySQLdb.connect(...)

connection.autocommit(True)
try:
cursor = connection.cursor()
if not cursor.execute(sql, values) > 0:
return None
row = cursor.fetchone()
finally:
connection.close()
return row[0]


Sometimes the return value of execute method would be 18446744073709552000
even there is no matched data available. I checked the source code of the
library, the underlying implementation is
https://github.com/farcepest/MySQLdb1/blob/master/_mysql.c#L835,

static PyObject *
_mysql_ConnectionObject_affected_rows(
_mysql_ConnectionObject *self,
PyObject *args)
{
if (!PyArg_ParseTuple(args, "")) return NULL;
check_connection(self);
return PyLong_FromUnsignedLongLong(mysql_affected_rows(&(self->
connection)));
}

And here is the official doc for mysql_affected_rows
http://dev.mysql.com/doc/refman/5.7/en/mysql-affected-rows.html.

Let me give a superficial understanding, please correct me if I were wrong.

In a 64-bit system, the mysql_affected_rows is supposed to return a number
of unsigned long, which means the range should be 0 ~ 2^64
(18446744073709551616), How could it be possible the function
PyLong_FromUnsignedLongLong return a converted value larger than 2^64,
that's what I don't understand.

Does anyone have some ideas of it?


The versions of the components I used:

Python: 2.7.6
MySQL 5.7.11
MySQLdb 1.2.5


Thanks
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com