[issue29463] Add `docstring` attribute to AST nodes

[Jeff Allen]

Jeff Allen added the comment:

Just terminology ... strictly speaking what you've done here is "add a *field* 
to the nodes Module, FunctionDef and ClassDef", rather than add an *attribute* 
-- that is, when one is consistent with the terms used in the ast module 
(https://docs.python.org/3/library/ast.html#node-classes) or Wang 
(https://docs.python.org/devguide/compiler.html#wang97).

--
nosy: +jeff.allen

___
Python tracker 

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

[issue29387] Tabs vs spaces FAQ out of date

[Jim DeLaHunt]

Jim DeLaHunt added the comment:

PR https://github.com/python/cpython/pull/41 to the new Github repo contains 
the following wording in Doc/faq/windows.rst:

Python raises :exc:`IndentationError` or :exc:`TabError` if mixed tabs 
and spaces are causing problems in leading whitespace.
You may also run the :mod:`tabnanny` module to check a directory tree 
in batch mode.

This is parallel wording with the contents of Martin's patch.

The PR may be enough to fix this issue.

--
pull_requests: +44

___
Python tracker 

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

[issue29521] Minor warning messages when compiling documentation

[Jim DeLaHunt]

Jim DeLaHunt added the comment:

I submitted a PR https://github.com/python/cpython/pull/41 to the new Github 
repo which finishes clearing the warnings in this bug report.

I would appreciate review and committing.

--
pull_requests: +43

___
Python tracker 

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

[issue29521] Minor warning messages when compiling documentation

[Jim DeLaHunt]

Jim DeLaHunt added the comment:

It looks like commit e7ffb99f842ebff97cffa0fc90b18be4e5abecf2 to the new GitHub 
python/cpython repo, by Ryan Gonzalez, fixed the problems in Doc/conf.py, 
Doc/Makefile, and Misc/NEWS . It did not fix the problems in Doc/make.bat or 
Doc/faq/windows.rst .  I'll make a new Pull Request on the new repo to fix 
these two parts.

That commit was related to https://github.com/python/cpython/pull/9. 

http://bugs.python.org/issue29527 talks about over 6000 warnings in the doc 
build, maybe including some of these. Another PR appeared to have fixed many of 
the warnings.

--

___
Python tracker 

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

Re: os.path.isfile

[Steve D'Aprano]

On Sun, 12 Feb 2017 03:20 pm, eryk sun wrote:

> On Sun, Feb 12, 2017 at 3:52 AM, Steve D'Aprano
>  wrote:
>> In Python, you should always use forward slashes for paths, even on
>> Windows.
> 
> There are cases where slash doesn't work (e.g. some command lines;
> \\?\ prefixed paths; registry subkey paths), so it's simpler to follow
> a rule to always convert paths to backslash on Windows, using
> os.path.normpath or pathlib.Path.

Okay, that makes sense. But we agree that when writing paths as string
literals, you should (nearly) always use forward slashes in Python.

Why not raw strings? Because raw strings aren't actually fully raw, and
consequently they don't allow the string to end with a backslash:


py> s = r'documents\'
  File "", line 1
s = r'documents\'
^
SyntaxError: EOL while scanning string literal


(I still don't understand why this isn't just treated as a bug in raw string
parsing and fixed...)



-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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

Re: int vs. float

[Steve D'Aprano]

On Sun, 12 Feb 2017 02:34 pm, Chris Angelico wrote:

> On Sun, Feb 12, 2017 at 2:27 PM, Steve D'Aprano
>  wrote:
>>>
>>> For example:
>>>
>>>>>> ast.literal_eval("( 1.0, 3 )").__class__.__name__
>>>'tuple'
>>
>>
>> In what way does returning a tuple match the requirement "return an int
>> or a float or generate an error message"?
> 
> Easy. You just use a version of Python in which tuple is a subclass of
> int.


Wouldn't a subclass of float be more appropriate? After all, floats have a
mantissa and an exponent, which kinda makes them a tuple...

*tongue firmly in cheek*


-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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

Re: os.path.isfile

[Chris Angelico]

On Sun, Feb 12, 2017 at 3:20 PM, eryk sun  wrote:
> On Sun, Feb 12, 2017 at 3:52 AM, Steve D'Aprano
>  wrote:
>> In Python, you should always use forward slashes for paths, even on Windows.
>
> There are cases where slash doesn't work (e.g. some command lines;
> \\?\ prefixed paths; registry subkey paths), so it's simpler to follow
> a rule to always convert paths to backslash on Windows, using
> os.path.normpath or pathlib.Path.

Registry subkeys aren't paths, and the other two cases are extremely
narrow. Convert slashes to backslashes ONLY in the cases where you
actually need to.

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

Re: os.path.isfile

[eryk sun]

On Sun, Feb 12, 2017 at 3:52 AM, Steve D'Aprano
 wrote:
> In Python, you should always use forward slashes for paths, even on Windows.

There are cases where slash doesn't work (e.g. some command lines;
\\?\ prefixed paths; registry subkey paths), so it's simpler to follow
a rule to always convert paths to backslash on Windows, using
os.path.normpath or pathlib.Path.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue28941] Update the link to Source Code in Python Docs from hg to github

[Mariatta Wijaya]

Changes by Mariatta Wijaya :


--
assignee: docs@python -> Mariatta

___
Python tracker 

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

Re: Rename file without overwriting existing files

[Steve D'Aprano]

On Fri, 10 Feb 2017 12:07 am, eryk sun wrote:

> On Thu, Feb 9, 2017 at 11:46 AM, Steve D'Aprano
>  wrote:
>>
>> So to summarise, os.rename(source, destination):
>>
>> - is atomic on POSIX systems, if source and destination are both on the
>>   same file system;
>> - may not be atomic on Windows?
>> - may over-write an existing destination on POSIX systems, but not on
>>   Windows;
>> - and it doesn't work across file systems.
> 
> On Windows in 2.7 and prior to 3.3, os.rename will silently copy and
> delete when the destination isn't on the same volume. 


Will the copy overwrite an existing file?


> It may even 
> silently leave the original file in place in some cases -- e.g. when
> the file is read-only and the user isn't allowed to modify the file
> attributes.
> 
> If the destination is on the same volume, renaming should be atomic
> via the system calls NtOpenFile and NtSetInformationFile. Ultimately
> it depends on the file system implementation of
> IRP_MJ_SET_INFORMATION, FileRenameInformation [1].
> 
>> The link/unlink trick:
>> - avoids over-writing existing files on POSIX systems at least;
>> - but maybe not Windows?
> 
> This works for renaming files on Windows as long as the file system
> supports hard links (e.g. NTFS). It's not documented on MSDN, but
> WinAPI CreateHardLink is implemented by calling NtSetInformationFile
> to set the FileLinkInformation, with ReplaceIfExists set to FALSE, so
> it fails if the destination exists. Note that this does not allow
> renaming directories. See the note for FileLinkInformation [1]; NTFS
> doesn't allow directory hard links. But why bother with this 'trick'
> on Windows?

I don't know, that's why I'm asking for guidance. I don't have a Windows
system to test on.

On Windows, how would you implement a file rename (potentially across file
system boundaries) which will not overwrite existing files? Just by calling
os.rename()?



-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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

[issue29474] Grammatical errors in weakref.WeakValueDictionary docs

[Mariatta Wijaya]

Changes by Mariatta Wijaya :


--
pull_requests: +41

___
Python tracker 

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

[issue29474] Grammatical errors in weakref.WeakValueDictionary docs

[Mariatta Wijaya]

Changes by Mariatta Wijaya :


--
pull_requests: +42

___
Python tracker 

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

[issue29474] Grammatical errors in weakref.WeakValueDictionary docs

[Mariatta Wijaya]

Changes by Mariatta Wijaya :


--
pull_requests: +40

___
Python tracker 

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

[issue29474] Grammatical errors in weakref.WeakValueDictionary docs

[Mariatta Wijaya]

Changes by Mariatta Wijaya :


--
pull_requests: +39

___
Python tracker 

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

[issue28929] Provide a link from documentation back to its source file

[Mariatta Wijaya]

Changes by Mariatta Wijaya :


--
pull_requests: +38

___
Python tracker 

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

[issue28929] Provide a link from documentation back to its source file

[Mariatta Wijaya]

Changes by Mariatta Wijaya :


--
pull_requests: +37

___
Python tracker 

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

[issue28929] Provide a link from documentation back to its source file

[Mariatta Wijaya]

Changes by Mariatta Wijaya :


--
pull_requests: +36

___
Python tracker 

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

[issue28929] Provide a link from documentation back to its source file

[Mariatta Wijaya]

Changes by Mariatta Wijaya :


--
pull_requests: +35

___
Python tracker 

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

Re: os.path.isfile

[Steve D'Aprano]

On Sat, 11 Feb 2017 05:11 am, epro...@gmail.com wrote:

> Hello NG
> 
> Python 3.5.2
> 
> Windows 10
> 
> os.path.isfile() no recognise file with double dot?
> 
> eg. match.cpython-35.pyc



I doubt that very much. I expect you are probably writing something like
this:


path = 'My Documents\testing\path\match.cpython-35.pyc'
os.path.isfile(path)

and not realising that you have a TAB character in your string from the \t,
or something similar.

In Python, you should always use forward slashes for paths, even on Windows.

path = 'My Documents/testing/path/match.cpython-35.pyc'

Try printing the repr() of your path.





-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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

Re: os.path.isfile

[Steve D'Aprano]

On Sat, 11 Feb 2017 06:50 am, Vincent Vande Vyvre wrote:

> Le 10/02/17 à 19:11, epro...@gmail.com a écrit :
>> Hello NG
>>
>> Python 3.5.2
>>
>> Windows 10
>>
>> os.path.isfile() no recognise file with double dot?
>>
>> eg. match.cpython-35.pyc
>>
>> Please somebody know something about that?
>>
>> Thank You in advance
>>
> Interesting, you're right.
> 
> Python 3.4.3 (default, Nov 17 2016, 01:08:31)
> [GCC 4.8.4] on linux
> Type "help", "copyright", "credits" or "license" for more information.
>  >>> import os
>  >>> 
>
os.path.isfile('/home/vincent/oqapy-3/trunk/__pycache__/grid.cpython-34.pyc
> ')
> False
> 
> 
> Why ?


How do you know that file exists?

Why choose such a long file name where you risk introducing spaces or
newlines due to word-wrapping?


I cannot replicate your result using Python 3.5 on Linux:


py> path = '/tmp/spam.eggs.cheese.txt'
py> with open(path, 'w') as f:
... f.write('something')
...
9
py> import os
py> print(os.path.isfile(path))
True


I expect that you have a space at the end of the file name:

'/home/vincent/oqapy-3/trunk/__pycache__/grid.cpython-34.pyc '

instead of 

'/home/vincent/oqapy-3/trunk/__pycache__/grid.cpython-34.pyc'


-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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

[issue28929] Provide a link from documentation back to its source file

[Mariatta Wijaya]

Changes by Mariatta Wijaya :


--
versions: +Python 2.7, Python 3.5, 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

Re: int vs. float

[Steve D'Aprano]

On Sat, 11 Feb 2017 06:00 pm, Amit Yaron wrote:

> Another option:
> Use 'float' instead of 'int'. and check using the method  'is_integer'
> of floating point numbers:
> 
>  >>> 3.5.is_integer()
> False
>  >>> 4.0.is_integer()
> True


A bad option...

py> float('12345678901234567')
1.2345678901234568e+16

Notice the last digit of the mantissa?


Beyond a certain value, *all* floats are integer, because floats don't have
enough precision to include a fractional portion. 

py> float('12345678901234567.12345').is_integer()
True


The safest way to treat this is to attempt to convert to an int, if that
succeeds return the int; if it fails, try to convert to a float, and if
that succeeds, return the float.



-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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

Re: int vs. float

[Chris Angelico]

On Sun, Feb 12, 2017 at 2:27 PM, Steve D'Aprano
 wrote:
>>
>> For example:
>>
>>>>> ast.literal_eval("( 1.0, 3 )").__class__.__name__
>>'tuple'
>
>
> In what way does returning a tuple match the requirement "return an int or a
> float or generate an error message"?

Easy. You just use a version of Python in which tuple is a subclass of int.

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

Re: int vs. float

[Steve D'Aprano]

On Sat, 11 Feb 2017 07:24 pm, Marko Rauhamaa wrote:

> boB Stepp :
> 
>> According to the OP's professor's challenge, the OP needs to recognize
>> an input of "4.0" as a float and "4" as an integer, and to respond
>> with an error message in the float case, or "decimal number" case as
>> the OP phrased it.  Apparently only positive integers are acceptable
>> input; all other inputs should generate an appropriate error message
>> by input type.
> 
> Haven't been following the discussion, but this should be simply:
> 
>ast.literal_eval("...")
> 
> For example:
> 
>>>> ast.literal_eval("( 1.0, 3 )").__class__.__name__
>'tuple'


In what way does returning a tuple match the requirement "return an int or a
float or generate an error message"?




-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

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

[issue29026] time.time() documentation should mention UTC timezone

[Eric Appelt]

Eric Appelt added the comment:

As we have moved to GitHub and mandatory reviews with Pull Requests, I have 
created a new patch in PR#34 which incorporates Victor's suggestions.

--

___
Python tracker 

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

[issue29527] Travis: doc job is broken

[Zachary Ware]

Zachary Ware added the comment:

PR16 made the Travis build situation better, but we still have some warnings to 
look into.  I thought we had a PR for that, but I can't seem to find it.

--
nosy: +zach.ware
pull_requests: +34

___
Python tracker 

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

[issue28739] PEP 498: docstrings as f-strings

[Joakim Soderlund]

Joakim Soderlund added the comment:

I got slightly confused here while playing around.

Python 3.6.0 (default, Jan 31 2017, 11:39:39) 
[GCC 4.9.2] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> class Huacaya:
...   f"""Huacaya!"""
... 
>>> class Suri:
...   f"""{'Suri!'}"""
... 
>>> Huacaya.__doc__ is None
False
>>> Suri.__doc__ is None
True

At first I thought f-strings *did* work as docstrings since it worked  just 
fine for the first class. But, the docstring suddenly vanished when putting an 
actual expression into it.

--
nosy: +JockeTF

___
Python tracker 

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

[issue29529] Backport Travis configuration

[Brett Cannon]

Brett Cannon added the comment:

https://github.com/python/core-workflow/issues/19 should be decided upon before 
backporting anything.

--
nosy: +inada.naoki

___
Python tracker 

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

Re: int vs. float

[Erik]

[Dan, this isn't "aimed" at you personally, it's just a follow-up on the 
general point I am (and I think you are also) making]


On 11/02/17 02:17, Dan Sommers wrote:

At least it works both ways:

Python 3.5.3 (default, Jan 19 2017, 14:11:04)
[GCC 6.3.0 20170118] on linux
Type "help", "copyright", "credits" or "license" for more information.

s = "3"
f = float(s)
i = int(s)


Yes, but Peter said "accept the number as a float, and then complain if 
int(num) != num.", so he meant use "i = int(f)" (i.e., convert the float 
to an int, not the original string).


Anyway, that's just as bad, but in a different way ;) Using your example:

Python 3.5.2 (default, Nov 17 2016, 17:05:23)
[GCC 5.4.0 20160609] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> s = "3"
>>> f = float(s)
>>> f
3.e+64
>>> i = int(f)
>>> i
3069679542094544616940918707231410151788522766336
>>> i == f
True
>>>

That's poor if "i" ends up being the value actually used later when the 
input is processed - it's NOT the value the user entered!


I imagine that this particular use-case is not trying to teach the OP 
about float/int issues, but about how to parse numerical strings from 
user-input (so these extreme cases are not expected to be part of the 
input range). I might be wrong, though.


However, these sorts of issues are a very important consideration for 
people writing real-world code where the input might be coming from an 
external source such as a database or output from a language which uses 
fixed-point or some other precise representation of decimals (e.g., COBOL).


Whenever you convert something that may not be an integer in the 
appropriate range to a float (using IEEE 754, at least) you must be 
aware that you may lose precision. The answer in this case is to do 
something similar to what Peter suggested, but to use Python's 'decimal' 
type as the intermediate representation rather than the float() type:


Python 3.5.2 (default, Nov 17 2016, 17:05:23)
[GCC 5.4.0 20160609] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from decimal import Decimal as dec
>>> s = "0.5"
>>> d = dec(s)
>>> i = int(d)
>>> d
Decimal('0.5')
>>> i
0
>>> i == d
False
>>> s = "3"
>>> d = dec(s)
>>> i = int(d)
>>> d
Decimal('3')
>>> i
3
>>> i == d
True


No surprises there ;)

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

[issue29536] test_hashlib failure on Ubuntu 16.04

[Sachin Kumar]

New submission from Sachin Kumar:

When executing 
./python -m test -v test_hashlib
on Python 3.7, the test fails.

This is the complete traceback:

CPython 3.7.0a0 (default, Feb 8 2017, 03:10:42) [GCC 5.4.0 20160609]
==   Linux-4.4.0-62-generic-x86_64-with-debian-stretch-sid little-endian
==   hash algorithm: siphash24 64bit
==  cwd: /XXX/build/test_python_14437
==  encodings: locale=UTF-8, FS=utf-8
Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, 
dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, 
verbose=0, bytes_warning=0, quiet=0, hash_randomization=1, isolated=0)
Run tests sequentially
0:00:00 [1/1] test_hashlib
test_algorithms_available (test.test_hashlib.HashLibTestCase) ... ok
test_algorithms_guaranteed (test.test_hashlib.HashLibTestCase) ... ok
test_blake2b (test.test_hashlib.HashLibTestCase) ... ok
test_blake2b_vectors (test.test_hashlib.HashLibTestCase) ... ERROR
test_blake2s (test.test_hashlib.HashLibTestCase) ... ok
test_blake2s_vectors (test.test_hashlib.HashLibTestCase) ... ERROR
test_blocksize_name (test.test_hashlib.HashLibTestCase) ... ok
test_blocksize_name_blake2 (test.test_hashlib.HashLibTestCase) ... ok
test_blocksize_name_sha3 (test.test_hashlib.HashLibTestCase) ... ok
test_case_blake2b_0 (test.test_hashlib.HashLibTestCase) ... ok
test_case_blake2b_1 (test.test_hashlib.HashLibTestCase) ... ok
test_case_blake2s_0 (test.test_hashlib.HashLibTestCase) ... ok
test_case_blake2s_1 (test.test_hashlib.HashLibTestCase) ... ok
test_case_md5_0 (test.test_hashlib.HashLibTestCase) ... ok
test_case_md5_1 (test.test_hashlib.HashLibTestCase) ... ok
test_case_md5_2 (test.test_hashlib.HashLibTestCase) ... ok
test_case_md5_huge (test.test_hashlib.HashLibTestCase) ... skipped 'not enough 
memory: 4.0G minimum needed'
test_case_md5_uintmax (test.test_hashlib.HashLibTestCase) ... skipped 'not 
enough memory: 4.0G minimum needed'
test_case_sha1_0 (test.test_hashlib.HashLibTestCase) ... ok
test_case_sha1_1 (test.test_hashlib.HashLibTestCase) ... ok
test_case_sha1_2 (test.test_hashlib.HashLibTestCase) ... ok
test_case_sha1_3 (test.test_hashlib.HashLibTestCase) ... ok
test_case_sha224_0 (test.test_hashlib.HashLibTestCase) ... ok
test_case_sha224_1 (test.test_hashlib.HashLibTestCase) ... ok
test_case_sha224_2 (test.test_hashlib.HashLibTestCase) ... ok
test_case_sha224_3 (test.test_hashlib.HashLibTestCase) ... ok
test_case_sha256_0 (test.test_hashlib.HashLibTestCase) ... ok
test_case_sha256_1 (test.test_hashlib.HashLibTestCase) ... ok
test_case_sha256_2 (test.test_hashlib.HashLibTestCase) ... ok
test_case_sha256_3 (test.test_hashlib.HashLibTestCase) ... ok
test_case_sha384_0 (test.test_hashlib.HashLibTestCase) ... ok
test_case_sha384_1 (test.test_hashlib.HashLibTestCase) ... ok
test_case_sha384_2 (test.test_hashlib.HashLibTestCase) ... ok
test_case_sha384_3 (test.test_hashlib.HashLibTestCase) ... ok
test_case_sha3_224_0 (test.test_hashlib.HashLibTestCase) ... ok
test_case_sha3_224_vector (test.test_hashlib.HashLibTestCase) ... ERROR
test_case_sha3_256_0 (test.test_hashlib.HashLibTestCase) ... ok
test_case_sha3_256_vector (test.test_hashlib.HashLibTestCase) ... ERROR
test_case_sha3_384_0 (test.test_hashlib.HashLibTestCase) ... ok
test_case_sha3_384_vector (test.test_hashlib.HashLibTestCase) ... ERROR
test_case_sha3_512_0 (test.test_hashlib.HashLibTestCase) ... ok
test_case_sha3_512_vector (test.test_hashlib.HashLibTestCase) ... ERROR
test_case_sha512_0 (test.test_hashlib.HashLibTestCase) ... ok
test_case_sha512_1 (test.test_hashlib.HashLibTestCase) ... ok
test_case_sha512_2 (test.test_hashlib.HashLibTestCase) ... ok
test_case_sha512_3 (test.test_hashlib.HashLibTestCase) ... ok
test_case_shake128_vector (test.test_hashlib.HashLibTestCase) ... ERROR
test_case_shake256_vector (test.test_hashlib.HashLibTestCase) ... ERROR
test_case_shake_128_0 (test.test_hashlib.HashLibTestCase) ... ok
test_case_shake_256_0 (test.test_hashlib.HashLibTestCase) ... ok
test_extra_sha3 (test.test_hashlib.HashLibTestCase) ... ok
test_get_builtin_constructor (test.test_hashlib.HashLibTestCase) ... ok
test_gil (test.test_hashlib.HashLibTestCase) ... ok
test_hash_array (test.test_hashlib.HashLibTestCase) ... ok
test_hexdigest (test.test_hashlib.HashLibTestCase) ... ok
test_large_update (test.test_hashlib.HashLibTestCase) ... ok
test_name_attribute (test.test_hashlib.HashLibTestCase) ... ok
test_no_unicode (test.test_hashlib.HashLibTestCase) ... ok
test_no_unicode_blake2 (test.test_hashlib.HashLibTestCase) ... ok
test_no_unicode_sha3 (test.test_hashlib.HashLibTestCase) ... ok
test_threaded_hashing (test.test_hashlib.HashLibTestCase) ... ok
test_unknown_hash (test.test_hashlib.HashLibTestCase) ... ok
test_pbkdf2_hmac_c (test.test_hashlib.KDFTests) ... ok
test_pbkdf2_hmac_py (test.test_hashlib.KDFTests) ... ok
test_scrypt (test.test_hashlib.KDFTests) ... skipped '   test requires OpenSSL 
> 1.1'

==
ERROR: 

[issue29530] Windows buildbots broken by the migration to GitHub (meta issue)

[Steve Dower]

Steve Dower added the comment:

> Does Git support per-file settings like the svn:eol-style property in 
> Subversion or .hgeol in Mercurial?

The .gitattributes file seems to be full of glob patterns, so I assume a full 
file path will work.

However, that doesn't help with tarballs. Fixing the tests is the best way.

--

___
Python tracker 

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

[issue29514] Add a test case that prevents magic number changes in minor releases

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Now I think that it would be safer to omit the function name in error message 
rather than fixing the compilation and bumping the magic number.

Nick, if you want I could write a patch that fixes the possible security issue 
for .pyc files with old magic number.

--

___
Python tracker 

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

[issue29530] Windows buildbots broken by the migration to GitHub (meta issue)

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Does Git support per-file settings like the svn:eol-style property in 
Subversion or .hgeol in Mercurial?

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue29514] Add a test case that prevents magic number changes in minor releases

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Could anyone please explain to me the comment from _bootstrap_external.py?

# Starting with the adoption of PEP 3147 in Python 3.2, every bump in magic
# number also includes a new "magic tag", i.e. a human readable string used
# to represent the magic number in __pycache__ directories.  When you change
# the magic number, you must also set a new unique magic tag.  Generally this
# can be named after the Python major version of the magic number bump, but
# it can really be anything, as long as it's different than anything else
# that's come before.  The tags are included in the following table, starting
# with Python 3.2a0.

--

___
Python tracker 

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

[issue29530] Windows buildbots broken by the migration to GitHub (meta issue)

[R. David Murray]

R. David Murray added the comment:

Some of the tests (notably email tests) are *testing* platform line endings.  
In tests that I rewrote I did my best to make the tests independent of the line 
endings of checked in files (that is, constructing the files-to-test in the 
test itself instead of checking them in), but I wouldn't be surprised if there 
were a few tests that weren't converted to that paradigm.  (I haven't looked to 
see if there are any test.test_email.test_email failures, which is where they'd 
be.)

--
nosy: +r.david.murray

___
Python tracker 

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

[issue29463] Add `docstring` attribute to AST nodes

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Therefore we loss the possibility to set a breakpoint on the docstring? It 
doesn't look a great lost.

--

___
Python tracker 

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

[issue29514] Add a test case that prevents magic number changes in minor releases

[Brett Cannon]

Brett Cannon added the comment:

OK, so it sounds like Serhiy had good reason to do what he did.

If we do add a test then I would argue that the message should be very clear 
that the magic number can change in a bugfix release but that it should be 
discussed with python-dev first so that downstream can be aware of the issue 
ahead of time (as Nick pointed out, it took a very special circumstance to make 
this come up and so chances are it shouldn't again, but institutional memory 
doesn't necessarily last 20 years either ;) .

--

___
Python tracker 

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

[issue29339] Interactive: Move to same indentation level as previousline

[12345 67890]

12345 67890 added the comment:

I guess the workflow has been fixed so that I can submit a PR! I wasn't 
expecting this so soon, but I will get around to this as soon as I have time.

--

___
Python tracker 

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

[issue29527] Travis: doc job is broken

[Brett Cannon]

Brett Cannon added the comment:

It really depends on why the warnings are there. If it's a configuration issue 
with how Misc/NEWS is being built then that can be fixed to deal with a lot of 
warnings upfront. Otherwise we can also strip out the references from Misc/NEWS 
to deal with the warnings.

--

___
Python tracker 

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

DJANGO image processing

[Xristos Xristoou]

I want to create a django app with the base64 help where the users can upload 
images(specific ".tiff" ext) using DJANGO forms without model and without that 
images store in my server. and i will the users can be get back new processing 
image.
i have success with encode/decode image with base64 and i can display that 
image in template using safari because that can display TIFF images.
here the code :
views.py
def convert_to_base64(image_file):
base64_string = base64.encodestring(image_file)
return "data:image/png;base64,"+base64_string

@csrf_exempt
def index(request):
form = ImageUploadForm(request.POST or None, request.FILES or None)
if request.method == "POST" and form.is_valid():
image_file = request.FILES['image'].read()
base64_string = convert_to_base64(image_file)
file = base64_string.decode('utf8')
   return render_to_response("blog/success.html", {"image_file":file})
return render_to_response('blog/calc.html', {'form': form}, 
RequestContext(request))
my problem is now after the base64 i cant use that image for image 
processing(work fine in standalone python script) and i take two error :
RuntimeError at /
not a string in the browser
and that message in command line :
"GET / HTTP/1.1" 200 346
ERROR 4: `II*' does not exist in the file system,
and is not recognised as a supported dataset name.
here the code :
@csrf_exempt
def index(request):
form = ImageUploadForm(request.POST or None, request.FILES or None)
if request.method == "POST" and form.is_valid():
image_file = request.FILES['image'].read()
base64_string = convert_to_base64(image_file)

file = base64_string.decode('utf8')
file_like = cStringIO.StringIO(image_file)
flow_direction_uri = "output.tif"
routing.flow_direction_d_inf(file_like, flow_direction_uri)
return render_to_response("blog/success.html", {"image_file":file})
return render_to_response('blog/calc.html', {'form': form}, 
RequestContext(request))
and if i use file = base64_string.decode('utf8') as input in my function then i 
take that error :
AttributeError at /
'NoneType' object has no attribute 'GetRasterBand'
and in command line i take to like that :
AIAAgACAAIAAgACAAIAAgACAAIAAgACA
AIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAA
gACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACA
AIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAA
with to many lines.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue29324] test_aead_aes_gcm fails on Kernel 4.9

[Christian Heimes]

Christian Heimes added the comment:

Thx Barry,

I'll try to find some time to verify the new Kernel API and commit the patch 
early next week.

--

___
Python tracker 

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

[issue29534] _decimal difference with _pydecimal

[Armin Rigo]

Armin Rigo added the comment:

Sorry!  It should be repr(a) inside the print.  Here is the fixed version:

class X(Decimal):
def __init__(self, a):
print('__init__:', repr(a))
X.from_float(42.5)   # __init__: Decimal('42.5')

X.from_float(42) # with _pydecimal: __init__: 42
 # with _decimal:   __init__: Decimal('42')

--

___
Python tracker 

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

[issue22807] uuid.uuid1() should use uuid_generate_time_safe() if available

[Barry A. Warsaw]

Changes by Barry A. Warsaw :


--
versions: +Python 3.3, 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

[issue29324] test_aead_aes_gcm fails on Kernel 4.9

[Barry A. Warsaw]

Barry A. Warsaw added the comment:

Confirmed that test_socket_aead_kernel49.patch fixes the problem for Ubuntu 
17.04.  It'll probably fix it for Debian Stretch too give its kernel version 
number, but I haven't tested that yet.

--

___
Python tracker 

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

[issue29530] Windows buildbots broken by the migration to GitHub (meta issue)

[Steve Dower]

Steve Dower added the comment:

My vote would be to make the tests not presume anything about line endings, to 
the point of converting test files on the fly to be sure.

I'm mostly free today (in a different city with nothing to do), so if my hotel 
internet will let me SSH to github then I can work on this today. If people are 
around, I'll be on IRC too.

--

___
Python tracker 

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

[issue29531] Update Doc/README.txt to README.rst

[Roger Sachan]

Changes by Roger Sachan :


--
pull_requests:  -29

___
Python tracker 

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

[issue29324] test_aead_aes_gcm fails on Kernel 4.9

[Barry A. Warsaw]

Changes by Barry A. Warsaw :


--
nosy: +barry

___
Python tracker 

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

[issue29534] _decimal difference with _pydecimal

[Stefan Krah]

Stefan Krah added the comment:

I get the the same output, perhaps I misunderstand something here:

>>> from _decimal import *
>>> class X(Decimal):
... def __init__(self, a):
... print('__init__:', a)
... 
>>> X.from_float(42.5)
__init__: 42.5
Decimal('42.5')
>>> X.from_float(42)
__init__: 42
Decimal('42')
>>> 
>>> 
>>> from _pydecimal import *
>>> class X(Decimal):
... def __init__(self, a):
... print('__init__:', a)
... 
>>> X.from_float(42.5) 
__init__: 42.5
Decimal('42.5')
>>> X.from_float(42) 
__init__: 42
Decimal('42')

--

___
Python tracker 

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

[issue29514] Add a test case that prevents magic number changes in minor releases

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

My apologies for breaking the world. But I considered this bug as security 
issue. Unlikely, but not impossible. The BUILD_MAP_UNPACK_WITH_CALL opcode is 
rarely used, but if it is used, it can cause reading arbitrary memory and 
either crashing or even exposing the content of this memory in error message 
that can be leaked to remote user. This hole would be better to close early. I 
expected this change would be included in 3.5.2.

The more robust solution would be to add the support of two magic numbers and 
check on loading whether the BUILD_MAP_UNPACK_WITH_CALL opcode is occurred in a 
precompiled file with old magic number. But this solution looked too excessive.

It would be nice to design a mechanism for possible future bytecode fixes.

--

___
Python tracker 

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

[issue29535] datetime hash is deterministic in some cases

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
nosy: +belopolsky
versions: +Python 3.6

___
Python tracker 

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

[issue29530] Windows buildbots broken by the migration to GitHub (meta issue)

[Zachary Ware]

Zachary Ware added the comment:

We really need to be able to function regardless of the core.autocrlf setting.  
See #27425 for more about the EOL issues.

--
dependencies: +Tests fail because of git's newline preferences on Windows

___
Python tracker 

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

[issue29530] Windows buildbots broken by the migration to GitHub (meta issue)

[Zachary Ware]

Changes by Zachary Ware :


--
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware
priority: normal -> critical
versions: +Python 2.7, Python 3.5, Python 3.6

___
Python tracker 

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

[issue29535] datetime hash is deterministic in some cases

[Christian Heimes]

Christian Heimes added the comment:

I only checked Python 2.7. For Python 3.x it's a bit more complicated:

timedelta: PyObject_Hash(), always the same hash value
date: _Py_HashBytes(), always a randomized hash value
time: _Py_HashBytes() for offset = None, PyObject_Hash() for offset != 0
datetime: _Py_HashBytes() for offset = None, PyObject_Hash() for offset != 0
timezone: PyObject_Hash() (inherited from object)

I don't know why the datetime module doesn't use hash randomization for 
datetime and time objects with an offset. MAL is the master of (date)time. He 
might know.

--
nosy: +lemburg

___
Python tracker 

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

[issue29530] Windows buildbots broken by the migration to GitHub (meta issue)

[Jeremy Kloth]

Jeremy Kloth added the comment:

Tests are now failing due to end-of-line (?) differences.

I did a quick reading of the devguide, but didn't see any mention of the 
settings to be used for Git on Windows wrt core.autocrlf.

--

___
Python tracker 

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

[issue29535] datetime hash is deterministic in some cases

[Armin Rigo]

Armin Rigo added the comment:

That's not what the docs say.  E.g.: 
https://docs.python.org/3/reference/datamodel.html#object.__hash__ says

By default, the __hash__() values of str, bytes and datetime objects are 
“salted” with an unpredictable random value. Although they remain constant 
within an individual Python process, they are not predictable between repeated 
invocations of Python.

Morever, this command really prints changing numbers:

~/svn/python/3.7-debug/python -c "import datetime;print(hash(d  
atetime.datetime(2016,10,10,0,0,0,0)))"

--

___
Python tracker 

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

[issue2292] Missing *-unpacking generalizations

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Issue26213 was opened for documenting bytecode changes. But 21 months and 3 
releases after the code patch the documentation is still not updated.

--
nosy: +larry, serhiy.storchaka

___
Python tracker 

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

pysnmp 4.3.3 has been released

[Ilya Etingof]

What’s new
=

* SNMPv3 Reeder AES192/256 key localization algorithm implemented
* Broken 3DES encryption fixed
* Switched from PyCrypto to PyCryptodome for SNMPv3 crypto operations
* TEXTUAL-CONVENTION implementation improved to emit/consume human-friendlier 
values

More changes noted in the CHANGELOG [1].

What is pysnmp


The pysnmp library is a complete implementation of SNMPv1/v2c/v3 network 
management protocol
all in pure-Python. MIBs are automatically supported out-of-the-box, bindings 
to popular asynchronous
frameworks such as asyncio or Twisted are shipped along with the package.

More information on library features and API documentation can be found on 
project’s GitHub page [2].

1. https://github.com/etingof/pysnmp/blob/master/CHANGES.txt
2. https://github.com/etingof/pysnmp

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

Support the Python Software Foundation:
http://www.python.org/psf/donations/

Twisted 17.1 Release Announcement

[Amber Hawkie Brown]

On behalf of Twisted Matrix Laboratories, I am honoured to announce the release 
of Twisted 17.1!

The highlights of this release are:

- twisted.web.client.Agent now supports IPv6! It's also now the primary web 
client in Twisted, with twisted.web.client.getPage being deprecated in favour 
of it and Treq.
- twisted.web.server has had many cleanups revolving around timing out inactive 
clients.
- twisted.internet.ssl.CertificateOptions has had its `method` argument 
deprecated, in favour of the new raiseMinimumTo, lowerMaximumSecurityTo, and 
insecurelyLowerMinimumTo arguments, which take TLSVersion arguments. This 
allows you to better give a range of versions of TLS you wish to negotiate, 
rather than forcing yourself to any one version.
- twisted.internet.ssl.CertificateOptions will use OpenSSL's 
MODE_RELEASE_BUFFERS, which will let it free unused memory that was held by 
idle TLS connections.
- You can now call the new twist runner with `python -m twisted`.
- twisted.conch.ssh now has some ECDH key exchange support and supports 
`hmac-sha2-384`.
- Better Unicode support in twisted.internet.reactor.spawnProcess, especially 
on Windows on Python 3.6.
- More Python 3 porting in Conch, and more under-the-hood changes to facilitate 
a Twisted-wide jump to new-style classes only on Python 2 in 2018/2019. This 
release has also been tested on Python 3.6 on Linux.
- Lots of deprecated code removals, to make a sleeker, less confusing Twisted.
- 60+ closed tickets.

For more information, check the NEWS file (link provided below).

You can find the downloads at > (or alternatively 
>). The NEWS file is also 
available at >.

Many thanks to everyone who had a part in this release - the supporters of the 
Twisted Software Foundation, the developers who contributed code as well as 
documentation, and all the people building great things with Twisted!

Twisted Regards,
Amber Brown (HawkOwl)


signature.asc
Description: Message signed with OpenPGP
-- 
https://mail.python.org/mailman/listinfo/python-announce-list

Support the Python Software Foundation:
http://www.python.org/psf/donations/

[issue26213] Document BUILD_*_UNPACK opcodes

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

At the same time the semantic of the BUILD_MAP opcode was changed. However the 
documentation was not updated and currently it doesn't match the 
implementation. This caused an issue in third-party projects that operate with 
bytecode.

See also issue28810 for documenting bytecode changes in 3.6.

--
priority: low -> high
type:  -> behavior
versions: +Python 3.5, Python 3.7

___
Python tracker 

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

[issue402227] make BUILD_MAP use it's argument

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

After all this change was implemented as a part of PEP 448 implementation 
(issue2292). But it was not documented and current documentation of the 
BUILD_MAP opcode doesn't match the implementation. See also issue26213.

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue29530] Windows buildbots broken by the migration to GitHub (meta issue)

[Jeremy Kloth]

Jeremy Kloth added the comment:

After ensuring that Git is available to the buildbot service, the initial 
update fails due to the existing build directory containing the Mercurial 
checkout.

After manually removing the contents of the build directories, the update task 
successfully completes.

--
nosy: +jkloth

___
Python tracker 

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

[issue29535] datetime hash is deterministic in some cases

[Christian Heimes]

Christian Heimes added the comment:

Only the hash of str and bytes are randomized/ The types date, datetime and 
time are not subject to hash randomization. Same for int, float, bool and None.

--
nosy: +christian.heimes

___
Python tracker 

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

[issue29535] datetime hash is deterministic in some cases

[Armin Rigo]

New submission from Armin Rigo:

The documentation on the hash randomization says that date, time and datetime 
have a hash based on strings, that is therefore nondeterministic in several 
runs of Python.  I may either be missing a caveat, or the actual implementation 
does not follow its promise in case a timezone is attached to the datetime or 
time object:

~/svn/python/3.7-debug/python -c "import datetime;print(hash(d  
atetime.datetime(2016,10,10,0,0,0,0,datetime.timezone(datetime.timedelta(0, 
36000)"
(this gives -6021186165085109055 all the time)

~/svn/python/3.7-debug/python -c "import 
datetime;print(hash(datetime.time(0,0,0,0, 
datetime.timezone(datetime.timedelta(0, 36000)"
(this gives -3850122659820237607 all the time)

--
messages: 287601
nosy: arigo
priority: normal
severity: normal
status: open
title: datetime hash is deterministic in some cases
type: security
versions: Python 3.5, Python 3.7

___
Python tracker 

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

[issue29534] _decimal difference with _pydecimal

[Stefan Krah]

Changes by Stefan Krah :


--
nosy: +mark.dickinson, rhettinger, skrah

___
Python tracker 

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

[issue29534] _decimal difference with _pydecimal

[Armin Rigo]

New submission from Armin Rigo:

A difference in behavior between _decimal and _pydecimal (it seems that 
_decimal is more consistent in this case):

class X(Decimal):
def __init__(self, a):
print('__init__:', a)
X.from_float(42.5)   # __init__: Decimal('42.5')

X.from_float(42) # with _pydecimal: __init__: 42
 # with _decimal:   __init__: Decimal('42')

--
messages: 287600
nosy: arigo
priority: normal
severity: normal
status: open
title: _decimal difference with _pydecimal
type: behavior
versions: Python 3.5, Python 3.7

___
Python tracker 

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

[issue29514] Add a test case that prevents magic number changes in minor releases

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue29514] Add a test case that prevents magic number changes in minor releases

[Nick Coghlan]

Nick Coghlan added the comment:

Providing some additional background:

- 3.5.3 was the *first time ever* in more than two decades that CPython changed 
the magic number in a maintenance release. It *wasn't* necessary to do so - it 
could have been left alone (as 3.5.0, 3.5.1, and 3.5.2 can read the revised 
bytecode just fine - no changes were made to ceval, only to the code 
generator). If the magic number had been left alone, recompilation would have 
been limited solely to folks with affected bytecode files, which is 
approximately zero people in practice (as anyone impacted by the problem would 
have been getting weird runtime behaviour and presumably found a way to work 
around it).

- because the pyc caches for system packages on Linux are in system-owned 
directories, they're generated either at build time (Fedora et al) or install 
time (Debian et al) by the package that owns the corresponding source files and 
then installed with elevated privileges (e.g. "sudo dnf install 
python-requests"). These files *do not* belong to the CPython package, they 
belong to the individual Python modules that depend on CPython, so messing with 
them when installing a new version of CPython would be a significant breach of 
distro policies

- as a result, removing CPython 3.5.3's ability to read pyc files generated by 
3.5.0, 3.5.1 or 3.5.2 means that either the distros have to regenerate all of 
their Python dependent packages (to force recompilation of the affected 
bytecode files), or else patch the system Python so it can still read the old 
pyc files (which is the approach Peter is currently pursuing, since requiring a 
mass rebuild for a maintenance update is *also* against distro policy)

Thus this request to take the previously unwritten de facto policy (which 
worked fine and clearly isn't a major limitation on CPython maintainability, 
since the one time it has been done in 20+ years didn't actually need to do it) 
and make it an explicit official policy that's enforced by the test suite.

The reason that none of these concerns apply to Python feature releases is 
because those are only rolled out as part of distro version upgrades (e.g. the 
switch from 3.5 to 3.6 as the system Python is one of the upgrades going from 
F25 to F26), where both distro maintainers and distro users already expect to 
have to rebuild and reinstall almost everything.

--

___
Python tracker 

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

[issue29532] functools.partial is not compatible between 2.7 and 3.5

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Yes, this can be considered a bug. Following patch fixes it.

--
components: +Library (Lib)
keywords: +patch
nosy: +serhiy.storchaka
stage:  -> patch review
versions: +Python 3.7 -Python 3.4
Added file: http://bugs.python.org/file46633/partial-copy-kwargs.patch

___
Python tracker 

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

Re: int vs. float

[Amit Yaron]

On 11/02/17 09:47, boB Stepp wrote:

On Sat, Feb 11, 2017 at 1:00 AM, Amit Yaron  wrote:

On 10/02/17 21:15, Peter Pearson wrote:


On Fri, 10 Feb 2017 13:59:45 +0200, Amit Yaron 
wrote:


On 10/02/17 04:33, adam14711...@gmail.com wrote:



My computer programming professor challenged me to figure out a way
to manipulate my program to display one error message if the user
input is a zero or a negative number, and a separate error message if
the user input is a decimal number.  My program starts out:


[snip]


What should happen if the user types "1.0"?

To be flexible about this possibility, you could accept the number
as a float, and then complain if int(num) != num.


Another option:
Use 'float' instead of 'int'. and check using the method  'is_integer' of
floating point numbers:


3.5.is_integer()

False

4.0.is_integer()

True


According to the OP's professor's challenge, the OP needs to recognize
an input of "4.0" as a float and "4" as an integer, and to respond
with an error message in the float case, or "decimal number" case as
the OP phrased it.  Apparently only positive integers are acceptable
input; all other inputs should generate an appropriate error message
by input type.



Here's the output of the int function with a  string argument:
>>> int("4.0")
Traceback (most recent call last):
  File "", line 1, in 

You can use exception handling to detect numbers that do not match the 
regular expression for integers, and comparisons to check if a number is 
negative.




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

[issue19675] Pool dies with excessive workers, but does not cleanup

[Camilla Montonen]

Changes by Camilla Montonen :


--
nosy: +Winterflower

___
Python tracker 

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

[issue29533] urllib2 works slowly with proxy on windows

[Julia Dolgova]

Changes by Julia Dolgova :


--
keywords: +patch
Added file: http://bugs.python.org/file46632/socket.patch

___
Python tracker 

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

[issue29533] urllib2 works slowly with proxy on windows

[Julia Dolgova]

Changes by Julia Dolgova :


Added file: http://bugs.python.org/file46630/test.py

___
Python tracker 

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

[issue29533] urllib2 works slowly with proxy on windows

[Julia Dolgova]

Changes by Julia Dolgova :


Added file: http://bugs.python.org/file46631/log.txt

___
Python tracker 

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

[issue29533] urllib2 works slowly with proxy on windows

[Julia Dolgova]

Changes by Julia Dolgova :


Added file: http://bugs.python.org/file46629/socket.py

___
Python tracker 

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

[issue29533] urllib2 works slowly with proxy on windows

[Julia Dolgova]

New submission from Julia Dolgova:

I've found that urllib works sometimes slowly on windows with proxy.

To reproduce the issue:
on Windows:
1. Turn on the option "use proxy" in "browser settings" in "control panel".
No real proxy needed. The problem will come out before addressing to proxy. 
Just don't pay attention to exception.
2. Make sure that the list of addresses for proxy bypass is not empty
3. Execute checklib.py with socket.py (attached here) in the same directory

The result output could be:
A (not a problem):
Before call to _socket.gethostbyaddr("docs.python.org")
After call to _socket.gethostbyaddr("docs.python.org")

B (little problem):
Before call to _socket.gethostbyaddr("docs.python.org")
Exception in call to _socket.gethostbyaddr("docs.python.org")

C (worse problem):
Before call to _socket.gethostbyaddr("docs.python.org")
(Delay)
Exception in call to _socket.gethostbyaddr("docs.python.org")

The result A,B or C depends on what DNS server you use, what url you pass into 
urllib2.urlopen(), and could differ at different time because dns is not a 
stable thing. 
However, no matter what result you have, this test shows that a hostname is 
passed into gethostbyaddr instead of IP as expected and described in MSDN. It 
should be changed to gethostbyname_ex here.

test.py compare performance of gethostbyaddr and gethostbyname_ex. 
It sets different dns servers on the system and calls these functions with 
different hostnames passed into. Run on my computer shows that gethostbyname_ex 
is 3 times more productive and doesn't raise exceptions.

-
Attached files:
checklib.py - just make a call to urllib2.urlopen("https://docs.python.org;)
socket.py - not a patched lib. Has debug lines near 141 line. Use it with 
checklib.py.
test.py - compare performance of gethostbyaddr with gethostbyname_ex
log.txt - result of test.py on my computer (Windows 8, 64 bit)
socket.patch - socket.py patch

--
components: Library (Lib), Windows
files: checklib.py
messages: 287597
nosy: juliadolgova, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: urllib2 works slowly with proxy on windows
type: performance
versions: Python 2.7
Added file: http://bugs.python.org/file46628/checklib.py

___
Python tracker 

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

[issue28837] 2to3 does not wrap zip correctly

[Stuart Berg]

Stuart Berg added the comment:

Patch submitted as github PR #24:
https://github.com/python/cpython/pull/24

--

___
Python tracker 

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

Re: int vs. float

[Marko Rauhamaa]

boB Stepp :

> According to the OP's professor's challenge, the OP needs to recognize
> an input of "4.0" as a float and "4" as an integer, and to respond
> with an error message in the float case, or "decimal number" case as
> the OP phrased it.  Apparently only positive integers are acceptable
> input; all other inputs should generate an appropriate error message
> by input type.

Haven't been following the discussion, but this should be simply:

   ast.literal_eval("...")

For example:

   >>> ast.literal_eval("( 1.0, 3 )").__class__.__name__
   'tuple'


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

[issue29532] functools.partial is not compatible between 2.7 and 3.5

[Steven D'Aprano]

Steven D'Aprano added the comment:

Confirmed that in Python 2.7 calling g() before and after modifying the dict 
prints 3 both times; calling g() before modifying the dict prints 3, then after 
modifying it prints 5.

Python 3.3 behaves like 2.7, so this sounds like a regression in 3.5 or maybe 
3.4.

--
nosy: +steven.daprano
versions: +Python 3.4, Python 3.6

___
Python tracker 

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