[issue31898] Add `recommended-packages.txt` to `venv` documentation

[Nick Coghlan]

Nick Coghlan  added the comment:

https://bugs.python.org/issue31899 is a follow-up issue to discuss whether or 
not it would make sense to expand these recommendations to cover explicit 
compatibility testing against these libraries for CPython updates

--

___
Python tracker 

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

[issue31899] Ensure backwards compatibility with recommended packages

[Nick Coghlan]

New submission from Nick Coghlan :

This is a potential follow-up to issue 31898, whereby the recommended packages 
list could be taken into account as part of CPython's own testing regime. The 
gist of the idea would be to:

1. Update the recommended-packages list to nominate particular *versions* of 
those dependencies (the latest available version as of each CPython maintenance 
release)
2. Add a new "-uthird-party" resource definition to the regression test suite
3. Add a new regression test that installed the recommended packages into a 
virtual environment and ran their tests when that resource was enabled


It's a separate issue, since this would be more work to maintain than the 
simple "we recommend these packages" list proposed in issue 31898.

--
assignee: ncoghlan
components: Tests
messages: 305211
nosy: ncoghlan
priority: low
severity: normal
stage: test needed
status: open
title: Ensure backwards compatibility with recommended packages
type: enhancement
versions: 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

[issue31898] Add `recommended-packages.txt` to `venv` documentation

[Nick Coghlan]

Change by Nick Coghlan :


--
stage:  -> needs patch
type:  -> enhancement

___
Python tracker 

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

[issue31898] Add `recommended-packages.txt` to `venv` documentation

[Nick Coghlan]

New submission from Nick Coghlan :

As per the python-ideas thread starting at 
https://mail.python.org/pipermail/python-ideas/2017-October/047508.html, this 
is proposal to add a `pip -r` compatible `recommended-packages.txt` file to the 
`venv` documentation that summarises replacement module recommendations in 
other parts of the standard library documentation.

Suggested entries are:

requests# Recommendation in urllib.request docs
regex   # Recommendation in re docs
cffi# More typesafe alternative to ctypes
six # Python 2/3 compatibility library
setuptools  # Alternative to distutils that supports modern packaging standards

I'm also tempted to suggest pytz as the preferred source of up-to-date named 
timezones, but I'm not sure how often that's really needed in situations where 
you can't just depend on it explicitly instead.

--
assignee: ncoghlan
components: Documentation
messages: 305210
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Add `recommended-packages.txt` to `venv` documentation
versions: 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

[issue31897] RecursionError in plistlib.loads

[Ned Williamson]

Ned Williamson  added the comment:

```
import plistlib
dat = 
b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00AAAnAAA'
plistlib.loads(dat, fmt=plistlib.FMT_BINARY)
```
raises
```
Traceback (most recent call last):
  File "repro.py", line 3, in 
plistlib.loads(dat, fmt=plistlib.FMT_BINARY)
  File "/usr/lib/python3.5/plistlib.py", line 1006, in loads
fp, fmt=fmt, use_builtin_types=use_builtin_types, dict_type=dict_type)
  File "/usr/lib/python3.5/plistlib.py", line 997, in load
return p.parse(fp)
  File "/usr/lib/python3.5/plistlib.py", line 622, in parse
self._object_offsets = self._read_ints(num_objects, offset_size)
  File "/usr/lib/python3.5/plistlib.py", line 644, in _read_ints
for i in range(0, size * n, size))
ValueError: range() arg 3 must not be zero
```

--

___
Python tracker 

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

[issue31897] RecursionError in plistlib.loads

[Ned Williamson]

Ned Williamson  added the comment:

```
import plistlib
dat = 
b'AAAwAAA\xc9A\x9cAA\x00\x00\x00\x00\x00\x00\x00\x0b\x00\x00A\x04\xb2\xaaAA'
plistlib.loads(dat, fmt=plistlib.FMT_BINARY)
```
raises
```
Traceback (most recent call last):
  File "repro.py", line 3, in 
plistlib.loads(dat, fmt=plistlib.FMT_BINARY)
  File "/usr/lib/python3.5/plistlib.py", line 1006, in loads
fp, fmt=fmt, use_builtin_types=use_builtin_types, dict_type=dict_type)
  File "/usr/lib/python3.5/plistlib.py", line 997, in load
return p.parse(fp)
  File "/usr/lib/python3.5/plistlib.py", line 621, in parse
self._fp.seek(offset_table_offset)
OverflowError: Python int too large to convert to C ssize_t
```

--

___
Python tracker 

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

[issue31897] RecursionError in plistlib.loads

[Ned Williamson]

Ned Williamson  added the comment:

I'm filing related bugs under this same issue.

```
import plistlib
dat = 
b'Q\xe4\xfeAIwAAA\xc9A\xc1AAA\xc1AAA\x9cAAnAAA\x00\x00\x00\x00\x00\x00\x00\x0b\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00AA'
plistlib.loads(dat, fmt=plistlib.FMT_BINARY)
```
raises

```
Traceback (most recent call last):
  File "repro.py", line 3, in 
plistlib.loads(dat, fmt=plistlib.FMT_BINARY)
  File "/usr/lib/python3.5/plistlib.py", line 1006, in loads
fp, fmt=fmt, use_builtin_types=use_builtin_types, dict_type=dict_type)
  File "/usr/lib/python3.5/plistlib.py", line 997, in load
return p.parse(fp)
  File "/usr/lib/python3.5/plistlib.py", line 623, in parse
return self._read_object(self._object_offsets[top_object])
  File "/usr/lib/python3.5/plistlib.py", line 699, in _read_object
result =  self._fp.read(s).decode('ascii')
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe4 in position 0: ordinal 
not in range(128)
```

It seems only `InvalidFileException` should be raised by this function.

--

___
Python tracker 

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

[issue31897] RecursionError in plistlib.loads

[Ned Williamson]

Ned Williamson  added the comment:

The crashing version numbers are from testing on the release Python 3.5, but I 
think we can just fix this in 3.7+.

--

___
Python tracker 

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

[issue31897] RecursionError in plistlib.loads

[Ned Williamson]

New submission from Ned Williamson :

Hi,

The following program crashes for me using the current Python3.7 master:

```
import plistlib
plistlib.loads(b'\xdd\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'
   b'\xda\x0cw\xb7\x00\x00\x00\x00\x00\x00\x00\xc7\x00'
   b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\xd6\xd5\x00'
   b'\x00\x00\x00\x00\x00\x00\x04\x00\x00\x00\x00\x00'
   b'\x00\x00\x00\x00\x10\x00\x00\x00\x00\x00\x00',
   fmt=plistlib.FMT_BINARY)
```

The last few lines look like
```
  File "/usr/lib/python3.5/plistlib.py", line 728, in _read_object
] = self._read_object(self._object_offsets[o])
  File "/usr/lib/python3.5/plistlib.py", line 728, in _read_object
] = self._read_object(self._object_offsets[o])
  File "/usr/lib/python3.5/plistlib.py", line 723, in _read_object
key_refs = self._read_refs(s)
  File "/usr/lib/python3.5/plistlib.py", line 647, in _read_refs
return self._read_ints(n, self._ref_size)
  File "/usr/lib/python3.5/plistlib.py", line 644, in _read_ints
for i in range(0, size * n, size))
RecursionError: maximum recursion depth exceeded in comparison
```

This bug was found using an alpha version of python-fuzz.

--
messages: 305205
nosy: Ned Williamson
priority: normal
severity: normal
status: open
title: RecursionError in plistlib.loads
type: crash
versions: Python 3.7

___
Python tracker 

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

[issue31896] In function define class inherit ctypes.structure, and using ctypes.pointer leak memory

[Yang Big]

New submission from Yang Big :

Here my code:
  2 import sys
  3 import ctypes
  4  
  5  
  6 def hi():
  7 class timespec(ctypes.Structure):
  8 ┆   """Time specification, as described in clock_gettime(3)."""
  9 ┆   _fields_ = (('tv_sec', ctypes.c_long),
 10 ┆   ┆   ┆   ┆   ('tv_nsec', ctypes.c_long))
 11  
 12  
 13 ts = timespec()
 14 po = ctypes.pointer(ts)
 15  
 16  
 17 def main():
 18 while True:
 19 ┆   test = hi()
 20  
 21 if __name__ == "__main__":
 22 sys  2 import sys
  3 import ctypes
  4  
  5  
  6 def hi():
  7 class timespec(ctypes.Structure):
  8 ┆   """Time specification, as described in clock_gettime(3)."""
  9 ┆   _fields_ = (('tv_sec', ctypes.c_long),
 10 ┆   ┆   ┆   ┆   ('tv_nsec', ctypes.c_long))
 11  
 12  
 13 ts = timespec()
 14 po = ctypes.pointer(ts)
 15  
 16  
 17 def main():
 18 while True:
 19 ┆   test = hi()
 20  
 21 if __name__ == "__main__":
 22 sys.exit(main())

run this code, i find that the program occupy more and more VmRss
my python is 2.7.11, in python3 i also find this problem. 
   Is this normal？I am a newbie with python, not very familiar with some 
python's internal principle. 
   Tanks.

--
components: ctypes
messages: 305204
nosy: Yang Big, amaury.forgeotdarc, belopolsky, meador.inge
priority: normal
severity: normal
status: open
title: In function define class inherit ctypes.structure, and using 
ctypes.pointer leak memory
type: resource usage
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

[issue31894] test_timestamp_naive failed on NetBSD

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

> The documentation only says “datetime.timestamp” calls “mktime”

Indeed.  See 
.

This is a documentation bug.  Since 3.6 the timestamp does not call
mktime.  In fact, mktime should not be called anywhere in the datetime
module. See 
.

For the explanation of why mktime is not a good API, see PEP 495.

On Sun, Oct 29, 2017 at 9:30 PM, Martin Panter  wrote:
>
> Martin Panter  added the comment:
>
> Are you sure it is a “system” bug? As far as I understand, at least Posix 
> does not require support for local time before 1970. See 
> .
>
> But why is localtime(14400) relevant? The documentation only says 
> “datetime.timestamp” calls “mktime”, which should be valid since the UTC-5 
> timezone offset will give a positive timestamp. Perhaps is this similar to 
> Issue 29097, probing a date before 1970?
>
> --
> nosy: +martin.panter
>
> ___
> Python tracker 
> 
> ___

--

___
Python tracker 

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

[issue31895] Native hijri calendar support

[Steven D'Aprano]

Steven D'Aprano  added the comment:

Python 2.7 is in feature freeze, so 3.7 is the absolute earliest this could be 
introduced. Given how close we are to 3.7 feature freeze, 3.8 is more likely.

I don't think we would have any objections to supporting hijri calendar, in 
principle, but as a practical matter I expect that none of the core developers 
are probably qualified to write, review, support and maintain it. (I could be 
wrong, of course.) And what interface is required?

I'm not convinced that the datetime module is the right place for this. In the 
long run, we should expect that Python may support multiple calendars: Western, 
Arabic, Jewish, Asian calendars, and more. I think that would make datetime too 
big and clunky.

I think the best approach would be to provide a third-party package on PyPI, 
and once it has proven itself, it could be proposed for the standard library.

--
nosy: +steven.daprano
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

[issue31894] test_timestamp_naive failed on NetBSD

[Martin Panter]

Martin Panter  added the comment:

Are you sure it is a “system” bug? As far as I understand, at least Posix does 
not require support for local time before 1970. See 
.

But why is localtime(14400) relevant? The documentation only says 
“datetime.timestamp” calls “mktime”, which should be valid since the UTC-5 
timezone offset will give a positive timestamp. Perhaps is this similar to 
Issue 29097, probing a date before 1970?

--
nosy: +martin.panter

___
Python tracker 

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

[issue31895] Native hijri calendar support

[Haneef]

Haneef  added the comment:

This feature can be added to the 
(datetime.py)[https://docs.python.org/3/library/datetime.html], Java has done a 
similar move and it makes the whole process a lot easier.

The Hijri calendar is used across the globe by various websites and developers, 
some have even made libraries.

--

___
Python tracker 

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

[issue31895] Native hijri calendar support

[Haneef]

New submission from Haneef :

There should be native support for converting between Hijri (Umm al-Qura), 
Gregorian, Julian and UnixTime calendars.

Many big players have included native support for Hijri calendar in their SDKs 
and software. Below are some:

(Java Hijri calendar 
support)[https://docs.oracle.com/javase/8/docs/api/java/time/chrono/HijrahChronology.html]
(Apple supports the Hijri calendar in 5 of their SDKs (Software Development 
Kits))[https://developer.apple.com/documentation/foundation/calendar.identifier]
(Microsoft Windows supports Hijri calendar 
naively)[https://www.microsoft.com/middleeast/msdn/ArabicCalendar.aspx]
(Microsoft Office has native 
support)[https://blogs.technet.microsoft.com/office_global_experience/2010/01/13/um-al-qura-calendar-support-in-office-2010/]
(Android Hijri calendar 
support)[https://developer.android.com/reference/android/icu/util/IslamicCalendar.html]
(Google Calendar allows Hijri calendar as an alternate 
calendar)[https://www.maketecheasier.com/display-alternate-calendar-google-calendar/]

--
messages: 305199
nosy: haneef95
priority: normal
severity: normal
status: open
title: Native hijri calendar support
type: enhancement
versions: Python 2.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

[issue31894] test_timestamp_naive failed on NetBSD

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

I am not sure.  This is a system bug and we often provide work-arounds
or even reimplementations of buggy time functions in the time and
datetime modules. Whether or not this is something that is worth
fixing is a question for the affected NetBSD users.

I would say, for the purposes of this issue - add a skip for NetBSD to
the failing test and add a test for another date that can be included
on all systems.

If motivated, please open a separate issue for the time.localtime() bug.

--

___
Python tracker 

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

[issue31894] test_timestamp_naive failed on NetBSD

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

I'm not a datetime expert. What is the better way to skip the test? Is it worth 
to change the date to say (1970, 3, 9) for which the correct result is obtained 
on this system?

--

___
Python tracker 

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

[issue31894] test_timestamp_naive failed on NetBSD

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

I posted a wrong command, but fortunately I am in New York, so it did not matter

$ TZ=EST+05EDT,M3.2.0,M11.1.0 python -c 'import 
time;print(time.localtime(14400)[:])'
(1969, 12, 31, 23, 0, 0, 2, 365, 0)

--

___
Python tracker 

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

[issue31894] test_timestamp_naive failed on NetBSD

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

I hate this long form display!

Next time please use time.localtime(14400)[:].

Do you agree that this is a system bug?  On my Mac, I get

$ python -c 'import time; print(time.localtime(14400)[:])'
(1969, 12, 31, 23, 0, 0, 2, 365, 0)

--

___
Python tracker 

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

[issue31894] test_timestamp_naive failed on NetBSD

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

$ TZ=EST+05EDT,M3.2.0,M11.1.0 ./python -c 'import time; 
print(time.localtime(14400))'
time.struct_time(tm_year=1970, tm_mon=1, tm_mday=1, tm_hour=0, tm_min=0, 
tm_sec=0, tm_wday=3, tm_yday=1, tm_isdst=1)

--

___
Python tracker 

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

[issue31894] test_timestamp_naive failed on NetBSD

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

I don't have access to NetBSD and this looks like a bug in the system 
implementation of localtime.  The timestamp method is implemented by probing 
system localtime in the vicinity of UTC timestamp.

What does time.localtime(14400) with these TZ settings?

--

___
Python tracker 

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

[issue31894] test_timestamp_naive failed on NetBSD

[Serhiy Storchaka]

New submission from Serhiy Storchaka :

$ ./python -m test -vuall test_datetime
...
==
FAIL: test_timestamp_naive (test.datetimetester.TestDateTime_Pure)
--
Traceback (most recent call last):
  File "/home/serhiy/py/cpython3.7/Lib/test/support/__init__.py", line 1622, in 
inner
return func(*args, **kwds)
  File "/home/serhiy/py/cpython3.7/Lib/test/datetimetester.py", line 1977, in 
test_timestamp_naive
self.assertEqual(t.timestamp(), 18000.0)
AssertionError: 14400.0 != 18000.0


...

Simple reproducer:

$ TZ=EST+05EDT,M3.2.0,M11.1.0 ./python -c 'import datetime; 
print(datetime.datetime(1970, 1, 1).timestamp())'
14400.0

It should print 18000.0 (5 hours) instead of 14400.0 (4 hours).

--
components: Library (Lib), Tests
messages: 305192
nosy: belopolsky, serhiy.storchaka
priority: normal
severity: normal
status: open
title: test_timestamp_naive failed on NetBSD
type: behavior
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

[issue31630] math.tan has poor accuracy near pi/2 on OpenBSD and NetBSD

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

I have got both (!) results in the same binary on NetBSD (gcc 4.8.5).

tan(1.57079632679489611) = 1978937966095219.00
tan(0x1.921fb54442d16p+0) = 0x1.c1f559a01adccp+50
tan(1.57079632679489611) = 1978945885716843.00
tan(0x1.921fb54442d16p+0) = 0x1.c1f5cfa3105acp+50

Seems the first result is calculated at compile time while the second result is 
calculated at run time.

On OpenBSD (gcc 4.2.1):

tan(1.57079632679489611) = 1978945885716843.00
tan(0x1.921fb54442d16p+0) = 0x1.c1f5cfa3105acp+50
tan(1.57079632679489611) = 1978945885716843.00
tan(0x1.921fb54442d16p+0) = 0x1.c1f5cfa3105acp+50

On Linux (gcc 7.2.0) and FreeBSD (clang 4.0.0):

tan(1.57079632679489611) = 1978937966095219.00
tan(0x1.921fb54442d16p+0) = 0x1.c1f559a01adccp+50
tan(1.57079632679489611) = 1978937966095219.00
tan(0x1.921fb54442d16p+0) = 0x1.c1f559a01adccp+50

--
Added file: https://bugs.python.org/file47245/tan_pi2.c

___
Python tracker 

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

[issue31630] math.tan has poor accuracy near pi/2 on OpenBSD and NetBSD

[Stefan Krah]

Stefan Krah  added the comment:

Also, does this occur in a VM on on the bare metal or both?

What leaves me puzzled is that I cannot reproduce the Linux x86 report
with almost the exact same compiler. But I'm on x64 and use -m32.

--

___
Python tracker 

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

[issue31630] math.tan has poor accuracy near pi/2 on OpenBSD and NetBSD

[Tim Peters]

Tim Peters  added the comment:

BTW, has anyone tried running a tiny C program on these platforms to see what 
tan(1.5707963267948961) delivers?  The kind of code fdlibm uses is sensitive 
not only to compiler (mis)optimization, but also to stuff like how the FPU's 
"precision control" is set, and to whether fused multiply-add is being used, 
and ...

--

___
Python tracker 

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

[issue31630] math.tan has poor accuracy near pi/2 on OpenBSD and NetBSD

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
components: +Tests -Extension Modules
title: math.tan has poor accuracy near pi/2 on OpenBSD -> math.tan has poor 
accuracy near pi/2 on OpenBSD and NetBSD
versions: +Python 2.7, 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

[issue31630] math.tan has poor accuracy near pi/2 on OpenBSD

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
keywords: +patch
pull_requests: +4138
stage:  -> patch review

___
Python tracker 

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

[issue31630] math.tan has poor accuracy near pi/2 on OpenBSD

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

There is the same result on NetBSD 7.1.

--

___
Python tracker 

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

[issue31304] Update doc for starmap_async error_back kwarg

[Pablo Galindo Salgado]

Change by Pablo Galindo Salgado :


--
keywords: +patch
pull_requests: +4137
stage: needs patch -> patch review

___
Python tracker 

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

[issue26228] pty.spawn hangs on FreeBSD 9.3, 10.x

[Cornelius Diekmann]

Change by Cornelius Diekmann :


--
pull_requests: +4136

___
Python tracker 

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

[issue31893] Issues with kqueue

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
keywords: +patch
pull_requests: +4135
stage:  -> patch review

___
Python tracker 

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

[issue31893] Issues with kqueue

[Serhiy Storchaka]

New submission from Serhiy Storchaka :

In Modules/selectmodule.c it is assumed that the kevent structure is defined on 
FreeBSD and NetBSD as:

 struct kevent {
 uintptr_t ident;
 short filter;
 u_short   flags;
 u_int fflags;
 intptr_t  data;
 uintptr_t udata;
 };

and on OpenBSD as:

 struct kevent {
 u_int ident;
 short filter;
 u_short   flags;
 u_int fflags;
 intptr_t  data;
 int   udata;
 };


Actually it is defined on FreeBSD as:

 struct kevent {
 uintptr_t ident;
 short filter;
 u_short   flags;
 u_int fflags;
 intptr_t  data;
 void  *udata;
 };

On OpenBSD as:

 struct kevent {
 uintptr_t ident;
 short filter;
 u_short   flags;
 u_int fflags;
 int64_t   data;
 void  *udata;
 };

And on NetBSD as:

 struct kevent {
 uintptr_t ident;
 uint32_t  filter;
 uint32_t  flags;
 uint32_t  fflags;
 int64_t   data;
 intptr_t  udata;
 };

Other issues are related to rich comparison. Due to integer overflows the 
ordering is not transitive. The rich comparison protocol is not properly 
supported, comparing a kevent_event object with a non-kevent_event object don't 
falls back to the rich comparison methods of the right arguments.

--
assignee: serhiy.storchaka
components: Extension Modules, FreeBSD
messages: 305187
nosy: koobs, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Issues with kqueue
type: behavior
versions: Python 2.7, 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

[issue31749] Request: Human readable byte amounts in the standard library

[Martin Panter]

Martin Panter  added the comment:

Ken Kundert started a related discussion a while back on Python-ideas: 
.
 This was about SI-prefixed units in general; not restricted to bytes. Also, 
the “timeit” module already does auto-scaling across nsec, usec, msec, and sec.

I think supporting decimal SI prefixes (for µs, mL, km, MW, etc) is more 
important than the binary versions (KiB, MiB, GiB). And units of 1,024,000 are 
definitely too niche.

I think a new format type “:h” may be the way forward. Perhaps it would add an 
SI prefix, and then the user could append their unit:

>>> f"{123901842:h}B"  # Six significant digits by default (like “:g”)
"123.902 MB"
>>> f"{123901842:.5h}B"  # Drop trailing zeros
"123.9 MB"
>>> f"{12:+6h}m"  # Sign and width options may be useful
"  +12 m"
>>> f"{12e99:h}m"  # Exponential notation for extreme values
"1.2e100 m"
>>> f"{12e99:H}m"  # Capitalize E, INF, etc (but not k for kilo-, etc)
"1.2E100 m"
>>> f"{123901:#.5h}m"  # Alternative form keeps trailing zeros
"123.90 km"
>>> f"{123:.2h}m"  # Precision < 3 may not be respected
"123 m"
>>> f"{123:#.2h}m"  # Maybe alternative form could respect the precision
"0.12 km"
>>> f"{123901842:.4h}B".replace(" ", "")  # Avoid the space
"123.9MB"
>>> f"{123901842:.4h}B".replace(" ", "")  # Alternative space
"123.9MB"
>>> f"{123901842:.4h}B".replace(".", ",")  # Alternative to decimal point
"123,9 MB"
>>> f"{12e-6:h}sec"  # Non-ASCII by default
"12 µsec"
>>> f"{12e-6:h}sec".replace("\N{MICRO SIGN}", "u")  # ASCII compatibility
"12 usec"

Squares and cubes may be a minor stumbling block: 0.001 m² is one thousand 
square millimetres, but f"{0.001:.3h}m²" would return "1 mm²".

--
nosy: +martin.panter

___
Python tracker 

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

[issue31886] Multiprocessing.Pool hangs after re-spawning several worker process.

[Antoine Pitrou]

Change by Antoine Pitrou :


--
nosy: +Olivier.Grisel, tomMoral

___
Python tracker 

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

[issue31886] Multiprocessing.Pool hangs after re-spawning several worker process.

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Generally speaking, queues can remain in an inconsistent state after a process 
crash (because the process might have crashed just after acquiring a shared 
semaphore or sending part of a large message).  It's not obvious to me how we 
could make them safer, at least under Unix where there's no widely-available 
message-oriented communication facility that I know of.

--
nosy: +davin, pitrou
versions: +Python 3.7

___
Python tracker 

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

[issue20047] bytearray partition bug

[Serhiy Storchaka]

Change by Serhiy Storchaka :


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

[issue20047] bytearray partition bug

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:


New changeset 107f3cc791d223dc06b7c80f0de672e88ae6a8d1 by Serhiy Storchaka in 
branch '2.7':
[2.7] bpo-20047: Make bytearray methods partition() and rpartition() rejecting 
(GH-4158) (#4163)
https://github.com/python/cpython/commit/107f3cc791d223dc06b7c80f0de672e88ae6a8d1


--

___
Python tracker 

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

[issue20047] bytearray partition bug

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:


New changeset 9ea5a3a45b35d01b602e7e4da4f72b2db407e5c6 by Serhiy Storchaka in 
branch '3.6':
[3.6] bpo-20047: Make bytearray methods partition() and rpartition() rejecting 
(GH-4158) (#4162)
https://github.com/python/cpython/commit/9ea5a3a45b35d01b602e7e4da4f72b2db407e5c6


--

___
Python tracker 

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

[issue31892] ssl.get_server_certificate should allow specifying certificate / key type

[Hanno Boeck]

New submission from Hanno Boeck :

The function ssl.get_server_certificate() from the ssl module is supposed to 
allow fetching the certificate of a TLS server.

However in its current form it provides no way to specify a key type. Many 
popular hosts (e.g. facebook, google) support both ECDSA and RSA these days, 
depending on the cipher suites one uses to try to connect to them.

If one wants to fetch the RSA certificate of e.g. facbeook this is not possible 
with the current python ssl module, as it will always output the ECDSA 
certificate. One can create a connection with an SSLContext that has only RSA 
ciphers set, but it's not possible to get the certificate out of an SSLContext. 
And the get_server_certificate function provides neither a way to bind it to a 
context nor a way to specify ciphers or key types.

I think there should be an optional parameter to get_server_certificate that 
allows asking for a specific key type.

--
assignee: christian.heimes
components: SSL
messages: 305182
nosy: christian.heimes, hanno
priority: normal
severity: normal
status: open
title: ssl.get_server_certificate should allow specifying certificate / key type
type: enhancement

___
Python tracker 

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

[issue25720] Fix curses module compilation with ncurses6

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

I'll try to test this on NetBSD after fixing curses on NetBSD. It uses a 
different implementation of curses which don't support is_pad.

--
dependencies: +Make curses compiling on NetBSD 7.1 and tests passing
versions: +Python 2.7, Python 3.6 -Python 3.5

___
Python tracker 

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

[issue31891] Make curses compiling on NetBSD 7.1 and tests passing

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
nosy: +twouters

___
Python tracker 

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

[issue31891] Make curses compiling on NetBSD 7.1 and tests passing

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
keywords: +patch
pull_requests: +4134
stage:  -> patch review

___
Python tracker 

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

[issue31891] Make curses compiling on NetBSD 7.1 and tests passing

[Serhiy Storchaka]

New submission from Serhiy Storchaka :

NetBSD perhaps is the last open OS that don't use ncurses. For now the _curses 
module is not compiled on NetBSD. Its curses implementation doesn't contain 
several ncurses functions.  included for non-ncurses implementations 
defines a couple of macros that conflict with local variable names. The 
hardcoded signature of setupterm differs from the signature in . The 
fallback implementation of has_key() depends on KEY_* constants that are absent 
in NetBSD curses too. It seems to me that curses is broken on NetBSD for very 
long time.

The proposed PR fixes building of the _curses module and makes curses tests 
passing. This of course doesn't guaranties that curses works correctly on 
NetBSD, our curses tests are rudimentary.

There were other NetBSD specific guards in the code. They are no longer needed 
because the guarded functions already are supported in NetBSD for long time. 
There are issue9667 and issue21457 for removing unneeded conditional 
compilation.

--
assignee: serhiy.storchaka
components: Extension Modules
messages: 305180
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: Make curses compiling on NetBSD 7.1 and tests passing
type: compile error
versions: Python 2.7, 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

[issue8070] Infinite loop in PyRun_InteractiveLoopFlags() if PyRun_InteractiveOneFlags() raises an error

[Xavier de Gaye]

Xavier de Gaye  added the comment:

The infinite loop may occur if one of the functions called by 
PyRun_InteractiveOneObject() returns persistently -1. This may be the case when 
there is no more memory and is handled by issue 30696.

It is not possible anymore to reproduce the infinite loop reported in the 
initial post. See how the 'enc' parameter of PyParser_ASTFromFileObject() is 
NULL in the following gdb session:

$ gdb -q python -q
Reading symbols from python...done.
(gdb) run
Starting program: /path_to/src/python/master/python
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
Python 3.7.0a2+ (heads/master:bdf4298ae2, Oct 29 2017, 09:44:50) 
[GCC 7.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> 
Program received signal SIGINT, Interrupt.
0x7719daa7 in select () from /usr/lib/libc.so.6
(gdb) break PyParser_ASTFromFileObject
Breakpoint 1 at 0x555b38d1: file Python/pythonrun.c, line 1181.
(gdb) continue
Continuing.
sys.stdin = None

Breakpoint 1, PyParser_ASTFromFileObject (fp=fp@entry=0x77461860 
<_IO_2_1_stdin_>, 
filename=filename@entry='', enc=enc@entry=0x0, 
start=start@entry=256, 
ps1=ps1@entry=0x76e7b220 ">>> ", ps2=ps2@entry=0x76e7beb8 "... ", 
flags=0x7fffe338, errcode=0x7fffe244, arena=0x76eb2160) at 
Python/pythonrun.c:1181
1181{
(gdb) continue
Continuing.
>>> print(chr(0xe9))
é

Breakpoint 1, PyParser_ASTFromFileObject (fp=fp@entry=0x77461860 
<_IO_2_1_stdin_>, 
filename=filename@entry='', enc=enc@entry=0x0, 
start=start@entry=256, 
ps1=ps1@entry=0x76e7b220 ">>> ", ps2=ps2@entry=0x76e7beb8 "... ", 
flags=0x7fffe338, errcode=0x7fffe244, arena=0x76eb2160) at 
Python/pythonrun.c:1181
1181{
(gdb) continue
Continuing.
>>> 


Closing as out of date.

--
nosy: +xdegaye
resolution:  -> out of date
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

[issue25720] Fix curses module compilation with ncurses6

[Masayuki Yamamoto]

Masayuki Yamamoto  added the comment:

I opened PR 4164 to improve the is_pad configure check and previous PR was 
closed.

--

___
Python tracker 

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

[issue25720] Fix curses module compilation with ncurses6

[Masayuki Yamamoto]

Change by Masayuki Yamamoto :


--
pull_requests: +4133

___
Python tracker 

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

[issue20047] bytearray partition bug

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
pull_requests: +4132

___
Python tracker 

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

[issue20047] bytearray partition bug

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
pull_requests: +4131

___
Python tracker 

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