date:20160117


Alexander Riccio added the comment:

If there are few enough instances, then using a #pragma warning(suppress:4232) 
is probably the best idea.

--

___
Python tracker 

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

[issue26137] [idea] use the Microsoft Antimalware Scan Interface


New submission from Alexander Riccio:

I'm really not sure what it'd look like, or how it'd work, but CPython should 
take advantage of Microsoft's Antimalware Scan Interface, which is new to 
Windows 10. It's designed for applications like interpreters, which can execute 
u trusted code that may not be visible to antimalware.

--
components: Interpreter Core, Windows
messages: 258455
nosy: Alexander Riccio, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: [idea] use the Microsoft Antimalware Scan Interface
type: enhancement

___
Python tracker 

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

[issue26137] [idea] use the Microsoft Antimalware Scan Interface


Alexander Riccio added the comment:

See "Windows 10 to offer application developers new malware defenses" 
https://blogs.technet.microsoft.com/mmpc/2015/06/09/windows-10-to-offer-application-developers-new-malware-defenses/
 for an example of how AMSI works with PowerShell.

I think the applicability to CPython is self-evident.

--

___
Python tracker 

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

[issue26137] [idea] use the Microsoft Antimalware Scan Interface


Alexander Riccio added the comment:

See also: "Security Focus: Defending PowerShell with the Anti-Malware Scan 
Interface (AMSI)" 
http://blogs.technet.com/b/poshchap/archive/2015/10/16/security-focus-defending-powershell-with-windows-defender.aspx

--

___
Python tracker 

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

[issue26137] [idea] use the Microsoft Antimalware Scan Interface


Alexander Riccio added the comment:

When I say "I'm really not sure what it'd look like, or how it'd work" I mean 
at the C level. At a higher level, there are many places that I imagine are 
good places to use AMSI: Perhaps expressions passed in from the command line 
(-c) should be scanned; maybe pip packages should be scanned on installation, 
and maybe untrusted packages should be scanned right before execution...

Then it's a matter of calling the AMSI APIs in the right places; I don't know 
where those are.

--

___
Python tracker 

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

[issue26039] More flexibility in zipfile interface

2016-01-17 Thread Thomas Kluyver


Thomas Kluyver added the comment:

zipinfo-from-file.patch has an orthogonal but related change: the code in 
ZipFile.write() to construct a ZipInfo object from a filesystem file is pulled 
out to a classmethod ZipInfo.from_file().

Together, these changes make it much easier to control how a file is written to 
a zip file, like this:

zi = ZipInfo.from_file(blah)
# ... manipulate zi...
with open(blah, 'rb') as src, zf.open(zi, 'w') as dest:
# copy of the read/write loop - maybe this should be
# pulled out separately as well?

If these changes make it in, I might put a backported copy of the module on 
PyPI so I can start using it without waiting for Python 3.6.

--
Added file: http://bugs.python.org/file41637/zipinfo-from-file.patch

___
Python tracker 

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

[issue25878] CPython on Windows builds with /W3, not /W4


Stefan Krah added the comment:

I would expect linking to behave "as if" the abstract machine defined
by the standard were executing the code.

We already had one function pointer equality issue due to COMDAT folding,
so I agree that we should leave the warning on.

--

___
Python tracker 

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

[issue26138] Disable /W4 warning (non-standard dllimport behavior)


Changes by Stefan Krah :


--
nosy: skrah
priority: normal
severity: normal
status: open
title: Disable /W4 warning (non-standard dllimport behavior)

___
Python tracker 

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

[issue26139] libmpdec: disable /W4 warning (non-standard dllimport behavior)


New submission from Stefan Krah:

See: #25878

--
assignee: skrah
components: Extension Modules
messages: 258461
nosy: skrah
priority: normal
severity: normal
status: open
title: libmpdec: disable /W4 warning (non-standard dllimport behavior)
type: compile error
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

[issue26139] libmpdec: disable /W4 warning (non-standard dllimport behavior)


Roundup Robot added the comment:

New changeset df78978dacab by Stefan Krah in branch 'default':
Issue #26139: libmpdec: disable /W4 warning (non-standard dllimport behavior).
https://hg.python.org/cpython/rev/df78978dacab

--
nosy: +python-dev

___
Python tracker 

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

[issue26138] Disable /W4 warning (non-standard dllimport behavior)


Changes by Stefan Krah :


--
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
type:  -> compile error

___
Python tracker 

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

[issue26139] libmpdec: disable /W4 warning (non-standard dllimport behavior)


Changes by Stefan Krah :


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

___
Python tracker 

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

[issue25878] CPython on Windows builds with /W3, not /W4


Stefan Krah added the comment:

Pragma added for libmpdec in #26139.

--

___
Python tracker 

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

[issue26140] inspect.iscoroutinefunction raises TypeError when checks Mock of function or coroutinefunction

2016-01-17 Thread Hiroyuki Takagi


New submission from Hiroyuki Takagi:

inspect.iscoroutinefunction and asyncio.iscoroutinefunction with patch of 
issue25599 (https://bugs.python.org/issue25599) raise TypeError when used to 
check Mock object which mocks function or coroutinefunction.

How to reproduce:

- For the mock of function

>>> from unittest.mock import Mock
>>> import inspect
>>> def a():...
... 
>>> inspect.iscoroutinefunction(Mock(a))

Expected: False
Actual: 
Traceback (most recent call last):
  File "", line 1, in 
  File ".../cpython/Lib/inspect.py", line 187, in iscoroutinefunction
object.__code__.co_flags & CO_COROUTINE)
TypeError: unsupported operand type(s) for &: 'Mock' and 'int'


- For the mock of coroutine-function

>>> async def b():...
... 
>>> inspect.iscoroutinefunction(Mock(b))

Expected: True
Actual:
Traceback (most recent call last):
  File "", line 1, in 
  File ".../cpython/Lib/inspect.py", line 187, in iscoroutinefunction
object.__code__.co_flags & CO_COROUTINE)
TypeError: unsupported operand type(s) for &: 'Mock' and 'int'


Without the patch of issue25599, asyncio.iscoroutinefunction does not raise 
error and returns Mock object. But I don't think it is expected behavior, as 
discussed in that issue.

I wrote a patch to solve this problem.

--
components: asyncio
files: mock.patch
keywords: patch
messages: 258464
nosy: gvanrossum, haypo, miyakogi, yselivanov
priority: normal
severity: normal
status: open
title: inspect.iscoroutinefunction raises TypeError when checks Mock of 
function or coroutinefunction
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file41638/mock.patch

___
Python tracker 

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

[issue25954] Python 3.5.1 installer fails on Windows 7

2016-01-17 Thread Ned Batchelder


Ned Batchelder added the comment:

Steve, I do have that update installed.

--

___
Python tracker 

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

[issue24780] unittest assertEqual difference output foiled by newlines

2016-01-17 Thread Elena Oat


Elena Oat added the comment:

The issue is not related only to the caret. In fact, as seen in the below 
output, the issue occurs anytime there's a newline character in the beginning 
or middle of the string to be compared. 

In short, if a newline is present in the string and it's in the beginning or 
middle, a newline character should be put at the end of the string, too. This 
will make the output look sensible. If, however, the newline is not present at 
the end, the output is not really readable (the new line is missing).

As we (me and Manvi B.) understand, the caret appears in the output only when 
the strings are similar enough, i.e. their similarity ratio is high enough. 
Otherwise, compare function doesn't show the carets in places of difference. 
This can also be seen in test case test_trailingnewline_2.

This issue occurs, probably, due to using splitlines method.


==
FAIL: test_notrailingnewline_0 (__main__.AssertEqualTest)
--
Traceback (most recent call last):
  File "test.py", line 8, in test_notrailingnewline_0
self.assertEqual("abcDefehiJkl", "abcdefGhijkl")
AssertionError: 'abcDefehiJkl' != 'abcdefGhijkl'
- abcDefehiJkl
?^  ^  ^
+ abcdefGhijkl
?^  ^  ^


==
FAIL: test_notrailingnewline_1 (__main__.AssertEqualTest)
--
Traceback (most recent call last):
  File "test.py", line 14, in test_notrailingnewline_1
self.assertEqual("a\nbcdf", "a\nbddf")
AssertionError: 'a\nbcdf' != 'a\nbddf'
  a
- bcdf?  ^
+ bddf?  ^


==
FAIL: test_notrailingnewline_2 (__main__.AssertEqualTest)
--
Traceback (most recent call last):
  File "test.py", line 18, in test_notrailingnewline_2
self.assertEqual("a\nbcdf", "a\nbddg")
AssertionError: 'a\nbcdf' != 'a\nbddg'
  a
- bcdf+ bddg

==
FAIL: test_starting_and_ending_newline_0 (__main__.AssertEqualTest)
--
Traceback (most recent call last):
  File "test.py", line 12, in test_starting_and_ending_newline_0
self.assertEqual("\nabcDefehiJkl\n", "\nabcdefGhijkl\n")
AssertionError: '\nabcDefehiJkl\n' != '\nabcdefGhijkl\n'
  
- abcDefehiJkl
?^  ^  ^
+ abcdefGhijkl
?^  ^  ^


==
FAIL: test_startingnewline_0 (__main__.AssertEqualTest)
--
Traceback (most recent call last):
  File "test.py", line 10, in test_startingnewline_0
self.assertEqual("\nabcDefehiJkl", "\nabcdefGhijkl")
AssertionError: '\nabcDefehiJkl' != '\nabcdefGhijkl'
  
- abcDefehiJkl?^  ^  ^
+ abcdefGhijkl?^  ^  ^


==
FAIL: test_trailingnewline_0 (__main__.AssertEqualTest)
--
Traceback (most recent call last):
  File "test.py", line 6, in test_trailingnewline_0
self.assertEqual("abcDefehiJkl\n", "abcdefGhijkl\n")
AssertionError: 'abcDefehiJkl\n' != 'abcdefGhijkl\n'
- abcDefehiJkl
?^  ^  ^
+ abcdefGhijkl
?^  ^  ^


==
FAIL: test_trailingnewline_1 (__main__.AssertEqualTest)
--
Traceback (most recent call last):
  File "test.py", line 16, in test_trailingnewline_1
self.assertEqual("a\nbcdf\n", "a\nbddf\n")
AssertionError: 'a\nbcdf\n' != 'a\nbddf\n'
  a
- bcdf
?  ^
+ bddf
?  ^


==
FAIL: test_trailingnewline_2 (__main__.AssertEqualTest)
--
Traceback (most recent call last):
  File "test.py", line 20, in test_trailingnewline_2
self.assertEqual("a\nbcdf\n", "a\nbddg\n")
AssertionError: 'a\nbcdf\n' != 'a\nbddg\n'
  a
- bcdf
+ bddg


--
Ran 8 tests in 0.007s

FAILED (failures=8)

--
nosy: +Elena.Oat
Added file: http://bugs.python.org/file41639/test2.py

___
Python tracker 

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

[issue26129] Difference in behaviour with grp.getgrgid and pwd.getpwuid


SilentGhost added the comment:

I'm adding Larry since it was his implementation of _Py_Uid_Converter in 
issue15301 that seems to lead to this behaviour.

--
nosy: +SilentGhost, larry
versions: +Python 3.6 -Python 2.7, Python 3.5

___
Python tracker 

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

[issue26129] Difference in behaviour with grp.getgrgid and pwd.getpwuid

2016-01-17 Thread Larry Hastings


Larry Hastings added the comment:

Nope.  Argument Clinic was merged in 3.4, and in 3.3 pwd.getpwuid wouldn't 
accept strings.  So this isn't a bug introduced in the Clinic conversion in 
3.4, this is historical behavior, and we can't change it now.

If anything, I'd prefer that grp.getgrid *didn't* accept strings, but it's too 
late to change that too.  "Helpfully" automatically calling int() on an 
argument is un-pythonic.

(To answer your specific questions: they probably shouldn't have different 
behaviors, and I assume there's no particular reason for the difference.  It's 
probably that they had different implementors, and one did a sloppier job than 
the other.)

--
resolution:  -> wont fix
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

[issue25982] multiprocessing docs for Namespace lacks class definition


Changes by SilentGhost :


--
components: +Documentation

___
Python tracker 

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

[issue24906] asyncore asynchat hanging on ssl


Changes by SilentGhost :


--
nosy: +giampaolo.rodola, josiahcarlson, stutzbach

___
Python tracker 

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

[issue25724] SSLv3 test failure on Ubuntu 16.04 LTS


Changes by SilentGhost :


--
nosy: +alex, christian.heimes, dstufft, giampaolo.rodola, janssen, pitrou
stage:  -> patch review
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

[issue26137] [idea] use the Microsoft Antimalware Scan Interface

2016-01-17 Thread Steve Dower


Steve Dower added the comment:

I actually have a prototype of this already, though I haven't benchmarked the 
impact yet.

Brett and I were concerned that the applicability wasn't apparent enough given 
the cost involved, so we've been (slowly) preparing a PEP, mainly to have that 
record of why it's been added. I'll assign to myself, and keep an eye on 
python-dev for follow-up.

--
assignee:  -> steve.dower
nosy: +brett.cannon
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

[issue25724] SSLv3 test failure on Ubuntu 16.04 LTS

2016-01-17 Thread Antoine Pitrou


Antoine Pitrou added the comment:

>From a procedural point of view, I think it would be reasonable to wait for 
>the 16.04 release (or at least feature freeze), in case there are other 
>breakages pending.

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

[issue25954] Python 3.5.1 installer fails on Windows 7

2016-01-17 Thread Steve Dower


Steve Dower added the comment:

Is your installation working okay then? You seemed to imply that in an earlier 
message, but I just want to confirm before closing the issue.

--

___
Python tracker 

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

[issue26129] Difference in behaviour with grp.getgrgid and pwd.getpwuid

2016-01-17 Thread Serhiy Storchaka


Serhiy Storchaka added the comment:

This looks as unintentional consequences of ab0221811771.

I think the current behavior of grp.getgrgid() is not correct, because it 
accepts str, float and other types. Python is strong-typed language and 
shouldn't make unwanted implicit type conversions. I guess the purpose was to 
support long arguments in Python 2.

There is similar problem with grp.getgrnam() in 2.7. It accepts arguments of 
any types and convert them to str by calling str(). I guess the purpose was to 
support unicode arguments. In 3.x only str is accepted.

Proposed patch deprecates accepting non-integer arguments in grp.getgrgid(). 
May be we can just remove this without starting deprecating process. I don't 
know.

--
keywords: +patch
nosy: +brett.cannon, serhiy.storchaka
resolution: wont fix -> 
stage: resolved -> patch review
status: closed -> open
Added file: http://bugs.python.org/file41640/grp_getgrgid_non_integer_gid.patch

___
Python tracker 

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

[issue19475] Add timespec optional flag to datetime isoformat() to choose the precision


SilentGhost added the comment:

> I there anything else I can do for this?
I think you've done all you could, it's just someone needs to commit it.  I 
don't think they're being rude on purpose - it's just that there are so many 
committers in the nosy list that no one is feeling like it's their job.

--

___
Python tracker 

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

[issue26106] Move licences to literal blocks

2016-01-17 Thread Julien


Julien added the comment:

@georg.brandl is right, a parsed-literal block should work: Does not appear in 
pot files, and |release| replaced: nice.

I attached a new patch.

--
Added file: http://bugs.python.org/file41641/literal-licence.patch

___
Python tracker 

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

[issue26141] typing module documentation incomplete

2016-01-17 Thread Ben Darnell


New submission from Ben Darnell:

The typing module docs at https://docs.python.org/3/library/typing.html do not 
include everything that is documented in the PEP 
(https://www.python.org/dev/peps/pep-0484/#the-typing-module). Specifically, 
`AnyStr` is mentioned but not defined, the `@overload` decorator is missing, 
and so are the new-to-3.5 types Awaitable, AsyncIterable, AsyncIterator.

--
assignee: docs@python
components: Documentation
messages: 258475
nosy: Ben.Darnell, docs@python
priority: normal
severity: normal
status: open
title: typing module documentation incomplete
versions: Python 3.5

___
Python tracker 

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

[issue26129] Difference in behaviour with grp.getgrgid and pwd.getpwuid

2016-01-17 Thread Brett Cannon


Brett Cannon added the comment:

A single deprecation cycle should be enough since it obviously shouldn't work 
with floats and strings might make sense but updating code to not use them is 
easy enough.

--

___
Python tracker 

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

[issue19475] Add timespec optional flag to datetime isoformat() to choose the precision


Guido van Rossum added the comment:

I think Alexander has commit rights, he did most of the review, I trust him
to commit it.

--

___
Python tracker 

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

[issue25627] distutils : file "bdist_rpm.py" does not quote filenames when executing the rpm command


SilentGhost added the comment:

Eric, Donald, is any one of you able to test this?

--

___
Python tracker 

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

[issue19475] Add timespec optional flag to datetime isoformat() to choose the precision


Terry J. Reedy added the comment:

Not seeing any indication that this has been tested on Windows, I applied, 
compiled (32 bit), and ran test_datetime on Win10 without error.  I did not 
rebuild the doc.

--

___
Python tracker 

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

[issue19475] Add timespec optional flag to datetime isoformat() to choose the precision


Changes by Alexander Belopolsky :


--
assignee:  -> belopolsky
stage: patch review -> commit review

___
Python tracker 

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

[issue19475] Add timespec optional flag to datetime isoformat() to choose the precision


Alexander Belopolsky added the comment:

Is issue19475_v12.patch the final patch?  I don't see it addressing Guido's 
suggestion in msg256470 to add milli- and nanoseconds options.

--

___
Python tracker 

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

[issue19475] Add timespec optional flag to datetime isoformat() to choose the precision


SilentGhost added the comment:

Yes, version 12 is the final patch. It doesn't add those options. To copy my 
opinion from the rietveld (https://bugs.python.org/review/19475/#msg14): 

> I don't really think nanoseconds belong here. If they don't
> exist anywhere else in the module, why should they be suddenly introduced 
> here?
> of all places. It would be fine to use some generic solution that would enable
> or ease their addition in the future, but they shall not be added at this 
> time.

(there are altogether 27 messages there, which everyone's naturally CCed on).

--

___
Python tracker 

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

[issue19475] Add timespec optional flag to datetime isoformat() to choose the precision


Alexander Belopolsky added the comment:

I left some comments on Rietveld.

--
stage: commit review -> needs patch

___
Python tracker 

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

[issue19475] Add timespec optional flag to datetime isoformat() to choose the precision


Alexander Belopolsky added the comment:

> I don't really think nanoseconds belong here.

What about milliseconds?  I'll leave it for Guido to make a call on 
nanoseconds.  My vote is +0.5.

> If they don't
> exist anywhere else in the module, why should they be suddenly 
> introduced here?

The timespec feature is modeled after GNU date --iso-8601[=timespec] option 
which does support nanoseconds.  It is fairly common to support nanoseconds 
these days and it does not cost much to implement.

--

___
Python tracker 

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

[issue26106] Move licences to literal blocks

2016-01-17 Thread Julien


Julien added the comment:

And uploaded the result: http://www.afpy.org/doc/python/3.5/license.html

--

___
Python tracker 

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

[issue19475] Add timespec optional flag to datetime isoformat() to choose the precision


SilentGhost added the comment:

> What about milliseconds?  I'll leave it for Guido to make a call on 
> nanoseconds.  My vote is +0.5.
The only reason I didn't mention milliseconds because they exist in timedelta 
instantiation. And really, being the only place in the whole module they're as 
confusing there as would be nanoseconds.

> > If they don't
> > exist anywhere else in the module, why should they be suddenly 
> > introduced here?

> The timespec feature is modeled after GNU date --iso-8601[=timespec] option 
> which does support nanoseconds.  It is fairly common to support nanoseconds 
> these days and it does not cost much to implement.

Yes, but the module does not support nanoseconds. And putting any such options 
would require a huge banner saying that the nanosecond option will just always 
result in three zeros at the end. My suggestion is not to pretend that we 
suddenly "support" nanoseconds, but rather to follow the actual implementation 
of the module and add the support for nanoseconds timespec when the module 
actually adds support for them.

--

___
Python tracker 

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

[issue26142] Formatting bug on https://docs.python.org/2.7/c-api/intro.html

2016-01-17 Thread Jim Nasby


New submission from Jim Nasby:

The code for the set_all() example has a formatting bug:

return -1;
}
Py_DECREF(index);
}

it should be

return -1;
}
Py_DECREF(index);
}

--
assignee: docs@python
components: Documentation
messages: 258486
nosy: Jim Nasby, docs@python
priority: normal
severity: normal
status: open
title: Formatting bug on https://docs.python.org/2.7/c-api/intro.html
type: behavior
versions: Python 2.7

___
Python tracker 

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

[issue26139] libmpdec: disable /W4 warning (non-standard dllimport behavior)


Alexander Riccio added the comment:

#pragma warning(disable : 4232) is almost always NOT what you want. 

See: http://www.viva64.com/en/k/0048/

--
nosy: +Alexander Riccio

___
Python tracker 

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

[issue26142] Formatting bug on https://docs.python.org/2.7/c-api/intro.html


Roundup Robot added the comment:

New changeset 4f1ed606410b by Senthil Kumaran in branch '2.7':
Issue26142 - Fix a formatting bug in c-api intro doc.
https://hg.python.org/cpython/rev/4f1ed606410b

--
nosy: +python-dev

___
Python tracker 

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

[issue26142] Formatting bug on https://docs.python.org/2.7/c-api/intro.html


Senthil Kumaran added the comment:

Thanks for reporting. Fixed.

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

___
Python tracker 

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

[issue26017] Update https://docs.python.org/3/installing/index.html to always quote arguments


Roundup Robot added the comment:

New changeset 31debd0dc0dc by Senthil Kumaran in branch '3.5':
Issue26017 - Suggest enclosing command args in double quotes when using 
characters which get interpreted by shell.
https://hg.python.org/cpython/rev/31debd0dc0dc

New changeset 18ae23b69e08 by Senthil Kumaran in branch 'default':
Merge from 3.5
https://hg.python.org/cpython/rev/18ae23b69e08

--
nosy: +python-dev

___
Python tracker 

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

[issue26017] Update https://docs.python.org/3/installing/index.html to always quote arguments


Roundup Robot added the comment:

New changeset 668827be66d6 by Senthil Kumaran in branch '2.7':
Issue26017 - Suggest enclosing command args in double quotes when using 
characters which get interpreted by shell.
https://hg.python.org/cpython/rev/668827be66d6

--

___
Python tracker 

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

[issue26017] Update https://docs.python.org/3/installing/index.html to always quote arguments


Senthil Kumaran added the comment:

Thanks for the review/comment Ezio. Agree with your suggestion and made the 
change accordingly.

--
assignee: docs@python -> orsenthil
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed
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

[issue19475] Add timespec optional flag to datetime isoformat() to choose the precision


Guido van Rossum added the comment:

You can leave out the nanoseconds but please do add the milliseconds. I'm sure 
they would find more use than the option to show only the hours.

--

___
Python tracker 

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

[issue26140] inspect.iscoroutinefunction raises TypeError when checks Mock of function or coroutinefunction


Guido van Rossum added the comment:

Why fix this in mock rather than in the iscoroutinefunction functions? (Not
a rhetorical question -- I really am not sure what the better place is to
fix this, or if we should even consider fixing it.)

--

___
Python tracker 

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

[issue26134] HTTPPasswordMgrWithPriorAuth does not work with DigestAuthentication


Changes by Senthil Kumaran :


--
nosy: +orsenthil

___
Python tracker 

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

[issue6500] urllib2 maximum recursion depth exceeded


Senthil Kumaran added the comment:

@Serhiy, the patch looks good to me. This change is an excellent idea. Please 
commit it.

--
assignee: berker.peksag -> serhiy.storchaka
stage: patch review -> commit review

___
Python tracker 

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

[issue26143] Ensure that IDLE's stdlib imports are from the stdlib


New submission from Terry J. Reedy:

In the past few months, there has been an increase "IDLE fails to start" 
reports that are apparently due to shadowing of stdlib modules by user modules 
in the same directly as as user code.  For instance, a beginner creates 
turtle.py and then writes "import turtle" in the same file or another in the 
same directory.

Note that only Python-coded modules can be shadowed. Imports of builtin modules 
that are not accelerators for a .py module are handled internally and do not 
involve sys.path.  (If turtle were builtin, turtle.py would not interfere with 
'import turtle.) In particular, sys is builtin and 'import sys' is guaranteed 
to work and give access to sys.path.

CPython avoids shadowing of the stdlib in its own imports.  Perhaps it does not 
add '', standing for the current working directory, to the front of sys.path 
until after its imports are done.  A self-contained application can avoid the 
problem by properly naming its own modules.  An application like IDLE that runs 
user code needs to protect itself from user files.  It does not now.

IDLE normally runs with two processes. I believe shadowing is more a problem 
for the user process that executes user code, with the working directory set to 
that of the user code.  (I believe that this is one reason why user code must 
be saved, to a particular directory, before it is run.)  Since, with one 
exception, all imports in run.py are done before running user code, I believe a 
sufficient fix would be temporarily delete '' while run.py does its own imports.

By default, the IDLE gui process should not have a problem.  The working 
directory is that of python.exe, which initially has no conflicting files.  To 
guard against user additions, '' could be permanently removed.  However, for 
option -n single-process mode, it would have to be restored (a reason for 
wanting to remove that mode).  I am not sure of the effect of all the other 
options.  At present, I believe, all imports are done at startup.  So the same 
idea used for the user process might work, at least for the present.

Automated tests would be nice.  I might want to some day 
limit initial imports to the minimum needed to show the initial window (or 
windows), so IDLE might start faster.  But they are not trivial.  And there is 
the time factor. A single cold start of IDLE takes as long (about 4 seconds on 
my machine) as the average test file in the test suite.

--
messages: 258496
nosy: terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Ensure that IDLE's stdlib imports are from the stdlib
type: behavior

___
Python tracker 

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

[issue26069] Remove the Deprecated API in trace module


Roundup Robot added the comment:

New changeset 715d8a739f3b by Senthil Kumaran in branch 'default':
Issue26069 - Update whatsnew/3.6.rst on traceback module's api removals.
https://hg.python.org/cpython/rev/715d8a739f3b

--

___
Python tracker 

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

[issue25514] Improve IDLE's "subprocess didn't make connection" message

Terry J. Reedy added the comment:

I have seen another report that is likely due to masking. I don't know why
this has suddenly become seemingly much more common, but I have made fixing the
problem a priority. See new issue #26143.

I would like to narrow this issue to the user process, and broaden it to
reporting all currently plausible causes of non-connection. I revised the
title to say this.

I am looking at
https://stackoverflow.com/questions/15888186/cant-run-python-via-idle-from-explorer-2013-idles-subprocess-didnt-make-c
to see what causes people have found or think they have found.

1. Antivirus/firewall (4 people, linux iptables, Windows firewall, antivisus ,
so not a myth ;-)
2. Shadow files, as described above, and in the python directory (about as
common, tkinter,py, subprocess.py).
3. Registry problem (some people can fix, but most should re-install after
complete removal).
4. Zombie pythonw process (kill with Windows Task manager).
5. Permissions (run as admin, though should not be needed with proper install)
?. Multiple installed versions clash due to misconfiguration?

https://stackoverflow.com/questions/874757/python-idle-subprocess-error
Add:
?. example program that reads and writes (test)
6. Running after stopping run with ^C (temporary, I believe Restart Shell will
fix) Call this a timing issue.
<>
7. Modem rebot (rather obsolete answer for most of us).

There are plenty of miscellaneous possibilities to add even if masking, the
most common reason, is fixed.

--
title: better startup error messages in IDLE when stdlib modules shadowed ->
Improve IDLE's "subprocess didn't make connection" message

___
Python tracker

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

[issue26143] Ensure that IDLE's stdlib imports are from the stdlib


Terry J. Reedy added the comment:

Looking at 
https://stackoverflow.com/questions/15888186/cant-run-python-via-idle-from-explorer-2013-idles-subprocess-didnt-make-c
 and https://stackoverflow.com/questions/874757/python-idle-subprocess-error it 
seems that people have put things like tkinter.py, random.py, and subprocess.py 
in the python directory, along side of python.exe.  So the IDLE process 
definitely also needs a patch.

--
assignee:  -> terry.reedy

___
Python tracker 

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

[issue26144] test_pkg test_4 and/or test_7 sometimes fail

2016-01-17 Thread Martin Panter


New submission from Martin Panter:

It doesn’t always fail, and sometimes only one or the other test fails. Also, 
it seems to depend on the way the tests are run. I have never seen it fail with 
“python -m test -v”. Two commands where it does often fail for me:

./python -m test -w test_pkg
./python -m unittest -v test.test_pkg

Here is the output when both tests fail:

test_1 (test.test_pkg.TestPkg) ... ok
test_2 (test.test_pkg.TestPkg) ... ok
test_3 (test.test_pkg.TestPkg) ... ok
test_4 (test.test_pkg.TestPkg) ... ERROR
test_5 (test.test_pkg.TestPkg) ... ok
test_6 (test.test_pkg.TestPkg) ... ok
test_7 (test.test_pkg.TestPkg) ... FAIL
test_8 (test.test_pkg.TestPkg) ... ok

==
ERROR: test_4 (test.test_pkg.TestPkg)
--
Traceback (most recent call last):
  File "/media/disk/home/proj/python/cpython/Lib/test/test_pkg.py", line 180, 
in test_4
self.run_code(s)
  File "/media/disk/home/proj/python/cpython/Lib/test/test_pkg.py", line 69, in 
run_code
exec(textwrap.dedent(code), globals(), {"self": self})
  File "", line 2, in 
  File "/tmp/tmprhpx80bw/t4.py", line 1, in 
RuntimeError: Shouldnt load t4.py

==
FAIL: test_7 (test.test_pkg.TestPkg)
--
Traceback (most recent call last):
  File "/media/disk/home/proj/python/cpython/Lib/test/test_pkg.py", line 260, 
in test_7
'__name__', '__package__', '__path__', '__spec__'])
AssertionError: Lists differ: ['__c[34 chars]__loader__', '__name__', 
'__package__', '__spec__'] != ['__c[34 chars]__loader__', '__name__', 
'__package__', '__path__', '__spec__']

First differing element 6:
__spec__
__path__

Second list contains 1 additional elements.
First extra element 7:
__spec__

  ['__cached__',
   '__doc__',
   '__file__',
   '__loader__',
   '__name__',
   '__package__',
+  '__path__',
   '__spec__']

--
Ran 8 tests in 0.038s

FAILED (failures=1, errors=1)

--
components: Tests
messages: 258500
nosy: martin.panter
priority: normal
severity: normal
status: open
title: test_pkg test_4 and/or test_7 sometimes fail
type: behavior
versions: 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

[issue557704] netrc module can't handle all passwords

2016-01-17 Thread Martin Dengler


Martin Dengler added the comment:

Anecdotal ( http://stackoverflow.com/a/12675195/2747741 ) evidence suggests 
other programs do indeed accept spaces, and a cursory browsing of the Perl 
source code ( 
http://perl5.git.perl.org/perl.git/blob/HEAD:/cpan/libnet/lib/Net/Netrc.pm#l120 
) indicates Perl at least supports (escaped) spaces in .netrc passwords.

Is there anything that I could do to make the patch I provided acceptable?

If not, could the bug be reopened as 1) the bug description mentions a valid 
use case that is not handled by the netrc module; and 2) there is precedent for 
this use case's implementation in other software.

--

___
Python tracker 

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

[issue557704] netrc module can't handle all passwords