[issue10513] sqlite3.InterfaceError after commit

[Benjamin Peterson]

Changes by Benjamin Peterson :


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

___
Python tracker 

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

[issue29006] 2.7.13 _sqlite more prone to "database table is locked"

[Roundup Robot]

Roundup Robot added the comment:

New changeset dd13098a5dc2 by Benjamin Peterson in branch '2.7':
revert 030e100f048a (#29006, #10513)
https://hg.python.org/cpython/rev/dd13098a5dc2

--
nosy: +python-dev

___
Python tracker 

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

[issue10513] sqlite3.InterfaceError after commit

[Roundup Robot]

Roundup Robot added the comment:

New changeset dd13098a5dc2 by Benjamin Peterson in branch '2.7':
revert 030e100f048a (#29006, #10513)
https://hg.python.org/cpython/rev/dd13098a5dc2

--

___
Python tracker 

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

[issue29099] sqlite3 timestamp converter cannot handle timezone

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Naive and aware objects should not be mixed. Their actually are different 
types. The converter doesn't return str or bytes when can't parse an input as a 
datetime, and it shouldn't return a naive datetime if can't find a timezone.

SQLite date and time functions imply UTC if timezone is omitted. This is a 
reason for returning aware UTC datetime objects. On other side, Python is more 
powerful programming language, it distinguish naive and aware datetime objects, 
and it is unlikely that these two types are mixed in one database column. It is 
better to raise an error that silently return possible wrong result. It 
exceptional case user can write special converter or just call SQLite 
datetime() for unifying data format.

I think the old code unlikely will be broken if preserve an exception type and 
don't change conditions for raising an error. New error message can contain 
full input string and suggest to use the timestamptz converter if it looks as a 
datetime with timezone.

--

___
Python tracker 

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

[issue29241] sys._enablelegacywindowsfsencoding() don't apply to os.fsencode and os.fsdecode

[JGoutin]

JGoutin added the comment:

import sys

# Force the use of legacy encoding like versions of Python prior to 3.6.
sys._enablelegacywindowsfsencoding()

# Show actual file system encoding
encoding = sys.getfilesystemencoding()
print('File system encoding:', encoding)

# os.fsencode(filename) VS filename.encode(File system encoding)
import os
print(os.fsencode('é'), 'é'.encode(encoding))

>>> File system encoding: mbcs
>>> b'\xc3\xa9' b'\xe9'


The result is the same.

--

___
Python tracker 

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

[issue29099] sqlite3 timestamp converter cannot handle timezone

[Xiang Zhang]

Xiang Zhang added the comment:

> I think the timestamptz converter should either interpret strings without 
> timezone as UTC (and perhaps understand the "Z" suffix as sqlite3 date() 
> function) or raises an error. It should never return naive datetime.

Currently timestamptz just convert back what the user passed in, no matter 
naive or aware objects. What to do with them is left to the app. If we raise an 
error, could users use naive and aware objects together? And interpreting 
strings without timezone as UTC seems will mistranslate the object. For 
example, pass in datetime.datetime.now() and translate it back as UTC may not 
be right.

> The timestamp converter needs better error reporting when get an input with a 
> timezone.

I thought about it but our intention to introduce a new converter is not to 
break old code. Doesn't add error reporting violate the intention? Users' code 
may not catch the error now.

--

___
Python tracker 

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

[issue29099] sqlite3 timestamp converter cannot handle timezone

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

I think the timestamptz converter should either interpret strings without 
timezone as UTC (and perhaps understand the "Z" suffix as sqlite3 date() 
function) or raises an error. It should never return naive datetime.

The timestamp converter needs better error reporting when get an input with a 
timezone.

--

___
Python tracker 

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

[issue29099] sqlite3 timestamp converter cannot handle timezone

[Xiang Zhang]

Xiang Zhang added the comment:

timestamptz.patch implements a new converter that's able to convert aware 
datetime objects.

--
stage: needs patch -> patch review
Added file: http://bugs.python.org/file46265/timestamptz.patch

___
Python tracker 

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

[issue22343] Install bash activate script on Windows when using venv

[Kevin Christopher Henry]

Kevin Christopher Henry added the comment:

I can confirm that LF endings work fine on Cygwin, and it's hard to imagine any 
bash implementation not handling that properly.

--

___
Python tracker 

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

[issue29247] Document return value of epoll.poll

[Nathaniel Smith]

New submission from Nathaniel Smith:

The documentation for select.epoll.poll doesn't document the return value at 
all, which is somewhat important information :-)

I think it's a list of (fd, eventmask) tuples?

https://docs.python.org/3.7/library/select.html#select.epoll.poll

--
assignee: docs@python
components: Documentation
messages: 285285
nosy: docs@python, njs
priority: normal
severity: normal
status: open
title: Document return value of epoll.poll
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

[issue29246] typing.Union raises RecursionError when comparing Union to other type

[Jim Fasarakis-Hilliard]

Changes by Jim Fasarakis-Hilliard :


--
type: crash -> behavior
versions:  -Python 2.7, Python 3.3, Python 3.4

___
Python tracker 

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

[issue11681] -b option undocumented

[Nick Coghlan]

Nick Coghlan added the comment:

Added some review comments on the patch. The only critical one was changing a 
:class:`bytes` reference to :class:`unicode`, but I also suggested it may be 
worth mentioning that it *doesn't* enable warnings about all binary/text 
comparisons the way the Python 3 one does.

--

___
Python tracker 

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

[issue11681] -b option undocumented

[Nick Coghlan]

Nick Coghlan added the comment:

Right, the lack of transitivity comes from the fact that:

>>> u"3" == str(3)
True

Is really shorthand for:

>>> u"3" == str(3).decode("ascii")
True

However, the implicit decoding only triggers for *exactly* bytes instances, so 
in the bytearray case it needs to be explicit:

>>> u"3" == bytearray(b"3").decode("ascii")
True

--

___
Python tracker 

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

[issue24875] pyvenv doesn´t install PIP inside a new venv with --system-site-package

[Thomas Nyberg]

Thomas Nyberg added the comment:

Hi Mark Haase,

I've gone through both of your patches and they both work for me as they 
should. I'm not sure why the first one isn't working for you, since it works 
for me. That one seems like it's solving the problem the "right" way. In any 
case, the second patch works for me as well so if that works for you, then at 
least we can confirm that it works for both your version of OSX and debian 8 
which I'm running.

To any other higher powers: is Mark's second patch acceptable?

--

___
Python tracker 

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

[issue29218] distutils: Remove unused install_misc class

[Greg Ward]

Greg Ward added the comment:

LGTM, after a cursory glance at the code history. Been a lng time since I 
understood this stuff deeply, though!

--

___
Python tracker 

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

[issue29240] Implementation of the PEP 540: Add a new UTF-8 mode

[INADA Naoki]

INADA Naoki added the comment:

> Hum, pep540-3.patch doesn't work if the locale encoding is different than 
> ASCII and UTF-8. argv must be reencoded:

I want to skip reencoding.
On UTF-8 mode, arbitrary bytes in cmdline (e.g. broken filename passed by xarg) 
should be able to roundtrip by UTF-8/surrogateescape.

I don't trust wcstombs/mbstowcs.  It may not guarantee round tripping of 
arbitrary bytes.

Can -X utf8 option be processed before Py_Main()?

--

___
Python tracker 

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

[issue29246] typing.Union raises RecursionError when comparing Union to other type

[Spiro Sideris]

New submission from Spiro Sideris:

The typing.Union module raises a RecursionError when comparing a Union with no 
additional tree_args to a type that is not a Union.

An example of the stack trace with the added test looks like the following:

0:00:00 [1/1] test_typing
test test_typing failed -- Traceback (most recent call last):
  File "/Users/spiro/Development/open_source/cpython/Lib/test/test_typing.py", 
line 221, in test_union_compare_other
self.assertNotEqual(Union, object)
  File "/Users/spiro/Development/open_source/cpython/Lib/unittest/case.py", 
line 827, in assertNotEqual
if not first != second:
  File "/Users/spiro/Development/open_source/cpython/Lib/typing.py", line 760, 
in __eq__
return self._subs_tree() == other#return self._subs_tree() is not self and 
self._subs_tree() == other
  File "/Users/spiro/Development/open_source/cpython/Lib/typing.py", line 760, 
in __eq__
return self._subs_tree() == other#return self._subs_tree() is not self and 
self._subs_tree() == other
  File "/Users/spiro/Development/open_source/cpython/Lib/typing.py", line 760, 
in __eq__
return self._subs_tree() == other#return self._subs_tree() is not self and 
self._subs_tree() == other
  [Previous line repeated 233 more times]
  File "/Users/spiro/Development/open_source/cpython/Lib/typing.py", line 759, 
in __eq__
if not isinstance(other, _Union):
RecursionError: maximum recursion depth exceeded in __instancecheck__

test_typing failed

1 test failed:
test_typing

Total duration: 316 ms
Tests result: FAILURE

The test compares a Union with no tree_args to another type.

--
components: Library (Lib)
files: spirowork.patch
keywords: patch
messages: 285279
nosy: spiside
priority: normal
severity: normal
status: open
title: typing.Union raises RecursionError when comparing Union to other type
type: crash
versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7
Added file: http://bugs.python.org/file46264/spirowork.patch

___
Python tracker 

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

[issue29240] Implementation of the PEP 540: Add a new UTF-8 mode

[STINNER Victor]

STINNER Victor added the comment:

I only tested the the PEP 540 implementation on Linux.

The PEP and its implementation should adjusted for Windows, especially 
Windows-only env vars like PYTHONLEGACYWINDOWSFSENCODING.

Changes are maybe also needed for Mac OS X and Android, which always use UTF-8. 
Currently, the locale encoding is still used on these platforms (ex: by 
open()). Is it possible to a locale encoding different than UTF-8 on Android 
for example?

--

___
Python tracker 

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

[issue29240] Implementation of the PEP 540: Add a new UTF-8 mode

[STINNER Victor]

STINNER Victor added the comment:

Hum, pep540-3.patch doesn't work if the locale encoding is different than ASCII 
and UTF-8. argv must be reencoded:

$ LC_ALL=fr_FR ./python -X utf8 -c 'import sys; print(ascii(sys.argv))' $(echo 
-ne "\xff")
['-c', '\xff']

The result should not depend on the locale, it should be the same than:

$ LC_ALL=fr_FR.utf8 ./python -X utf8 -c 'import sys; print(ascii(sys.argv))' 
$(echo -ne "\xff")
['-c', '\udcff']

$ LC_ALL=C ./python -X utf8 -c 'import sys; print(ascii(sys.argv))' $(echo -ne 
"\xff")
['-c', '\udcff']

--

___
Python tracker 

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

[issue29240] Implementation of the PEP 540: Add a new UTF-8 mode

[STINNER Victor]

STINNER Victor added the comment:

Oops, I introduced an obvious bug in my latest refactoring. It's now fixed in 
the patch version 3: pep540-3.patch.

--
Added file: http://bugs.python.org/file46263/pep540-3.patch

___
Python tracker 

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

[issue29240] Implementation of the PEP 540: Add a new UTF-8 mode

[STINNER Victor]

STINNER Victor added the comment:

pep540-2.patch: Patch version 2, updated to the latest version of the PEP 540. 
It has no more FIXME/TODO and has more unit tests. The main change is that the 
strict mode doesn't use strict anymore for OS data, but keeps surrogateescape. 
See the PEP for the rationale (especially the "Use the strict error handler for 
operating system data" alternative).

--
Added file: http://bugs.python.org/file46262/pep540-2.patch

___
Python tracker 

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

[issue29057] Compiler failure on Mac OS X - sys/random.h

[George King]

George King added the comment:

I reinstalled the command line tools by downloading from 
developer.apple.com/download/more and the problem went away. No idea how they 
broke; I had previously installed the same version. In any case, sorry for the 
noise.

--

___
Python tracker 

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

[issue6331] Add unicode script info to the unicode database

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
nosy:  -pitrou

___
Python tracker 

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

[issue23407] os.walk always follows Windows junctions

[Eric Fahlgren]

Eric Fahlgren added the comment:

> # Junctions are not recognized as links.
> self.assertFalse(os.path.islink(self.junction))

If the above comment is intended as a statement of fact, then it's inconsistent 
with the implementation of Py_DeleteFileW ( 
https://hg.python.org/cpython/file/v3.6.0/Modules/posixmodule.c#l4178 ).

--
nosy: +eric.fahlgren

___
Python tracker 

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

[issue11681] -b option undocumented

[Greg Bengeult]

Greg Bengeult added the comment:

I have attached a patch for 2.7 that adds -b and -bb to the command line 
documentation in Modules/main.c and Doc/library/cmdline.rst, following the 
suggested text provided by Martin.

Interestingly, unicode(), bytearray(), and str() don't seem to be transitive in 
2.7.

>>> u"3" == str(3)
True

>>> str(3) == bytearray("3")
True

>>> u"3" == bytearray("3")
False

--
nosy: +gbengeult
Added file: http://bugs.python.org/file46261/b_option.patch

___
Python tracker 

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

[issue27603] Migrate IDLE context menu items to shell extension

[Shane Smith]

Shane Smith added the comment:

Since you're a developer, I'm sure you need a lot of versions installed so you 
can check for backwards combatibility (spelling intentional).  But until 
recently, only the most recent IDLE was in the context menu, so I'm guessing 
your workflow for that checking doesn't depend on the context menu.  (I liked 
the old way, BTW, but I can see how someone might not).

But so long as you're doing it the current way, it remains easily hacked back 
to the way I like it, so I don't have a whole lot to complain about.  Carry on, 
good sir.

--

___
Python tracker 

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

[issue6331] Add unicode script info to the unicode database

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
versions: +Python 3.7 -Python 3.6

___
Python tracker 

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

[issue16684] Unicode property value abbreviated names and long names

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
versions: +Python 3.7 -Python 3.4

___
Python tracker 

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

[issue16684] Unicode property value abbreviated names and long names

[Pander]

Pander added the comment:

Any updates or ideas on how to move this forward? Meanwhile, should the issue 
relate to version 3.6? Thanks. Ah, see also https://bugs.python.org/issue6331 
please

--

___
Python tracker 

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

[issue6331] Add unicode script info to the unicode database

[Pander]

Pander added the comment:

Any updates or ideas on how to move this forward? See also 
https://bugs.python.org/issue16684 Thanks.

--

___
Python tracker 

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

[issue29245] Can't write to NamedTemporaryFile

[R. David Murray]

R. David Murray added the comment:

Yes, it is intended behavior, and it is documented.  The default mode for 
NamedTemporaryFile (and TemporaryFile) is shown in the docs as "w+b".

I suppose that used to be more convenient in python2 where there was almost no 
distinction between binary and text on unix, but I think we are unlikely to 
change the default at this point.

--
nosy: +r.david.murray
resolution:  -> not a bug
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

[issue29231] Broken MSIs in Python 3.5+

[KeyWeeUsr]

KeyWeeUsr added the comment:

> Ah, you're using the full installer, which has the non-debug versions 
> embedded and therefore does not ever need to download them.

Hm, makes sense now, however, isn't that a bug? I mean, even if it's embeded... 
I'm just curious ^^

> If you start from the web installer...

Aha, there's my problem! After using the web installer everything seems ok for 
me. Python now runs happily!

RE the unsupported: yeah, I kind of ignored that intentionally. Don't get me 
wrong, but the functionality you so badly want to push away is a wonderful 
thing. Ok, there's venv, I'm mostly satisfied with that or system-wide 
interpreter, but there are cases when you have to debug some annoying problems 
and you might broke the installation before thus a hypotetical issue arises. 
Maybe you deleted a file unintentionally, put a header for compilation here or 
there, renamed something...

What is the first thing someone asks you on for example IRC? "Have you tried a 
fresh Python installation?" Uhm, sure, because it's so easy if the installer 
throws things everywhere it can (registry, p, ...).

That's mostly not an issue, simple "Repair" is enough unless... you have a 
large build environment and reinstalling the environment from scratch could 
take a **long** while depending on the complexity of the environment. How do 
you test a fresh installation then? <-- Really, that's a serious question. I 
could come only with this before, though nuget coule be usable too ^^

Also, the network installer is almost the same thing as common MSI, but without 
elevation. It's like ~500kB or something and does basically this - adds keys to 
registry, to p, etc with a folder that you choose for installing via the 
network installer afaik. I just skip the part that makes Python unportable or 
burned into the system. What I do is basically what you do after compilation. 
Take binaries and put them somewhere, so that they run, nothing less, nothing 
more.

Thanks for your help, guys :)

--
resolution: not a bug -> works for me

___
Python tracker 

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

[issue29245] Can't write to NamedTemporaryFile

[Kevin Bonham]

New submission from Kevin Bonham:

Python 3.6.0 (default, Dec 24 2016, 08:01:42) 
[GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.42.1)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from tempfile import NamedTemporaryFile
>>> tmp = NamedTemporaryFile()
>>> tmp.write("hello world!")
Traceback (most recent call last):
  File "", line 1, in 
  File 
"/usr/local/Cellar/python3/3.6.0/Frameworks/Python.framework/Versions/3.6/lib/python3.6/tempfile.py",
 line 483, in func_wrapper
return func(*args, **kwargs)
TypeError: a bytes-like object is required, not 'str'
>>> type(tmp)


The more verbose error points to issue #18879 
(http://bugs.python.org/issue18879), which seems very similar to my problem, 
but is marked as resolved.

---
TypeError Traceback (most recent call last)
 in ()
> 1 tmp_file.write("blah")

/usr/local/Cellar/python3/3.6.0/Frameworks/Python.framework/Versions/3.6/lib/python3.6/tempfile.py
 in func_wrapper(*args, **kwargs)
481 @_functools.wraps(func)
482 def func_wrapper(*args, **kwargs):
--> 483 return func(*args, **kwargs)
484 # Avoid closing the file as long as the wrapper is alive,
485 # see issue #18879.

TypeError: a bytes-like object is required, not 'str'

This also seems like it might be related to http://bugs.python.org/issue28867, 
though I'm getting the same behavior with TemporaryFile:

>>> from tempfile import TemporaryFile
>>> tmp2 = TemporaryFile()
>>> tmp2.write("Hello World")
Traceback (most recent call last):
  File "", line 1, in 
TypeError: a bytes-like object is required, not 'str'


I can do:

>>> with open(tmp.name, "w") as t:
... t.write("Hello world!")


Is this intended behavior? The docs still say that these functions should 
return file-like objects.

--
components: Library (Lib)
messages: 285266
nosy: Kevin Bonham
priority: normal
severity: normal
status: open
title: Can't write to NamedTemporaryFile
type: behavior
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

[issue29057] Compiler failure on Mac OS X - sys/random.h

[Ned Deily]

Ned Deily added the comment:

Sorry, George, but I'm unable to reproduce the failure you observe following 
your recipe.  The only thing I can suggest off the top of my head is that you 
might have out-of-date system header files installed in /usr/include.  Those 
files are installed with:

sudo xcode-select --install

They don't get installed or updated by just installing Xcode itself.  See if 
that helps.

--

___
Python tracker 

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

[issue29231] Broken MSIs in Python 3.5+

[Paul Moore]

Paul Moore added the comment:

> Fully usable, portable

*and unsupported* - you apparently ignored that point from Steve's comment

> and working Python interpreter

That's (essentially) pure luck. I don't think I've ever seen any
suggestion that the /a flag for *any* MSI installer (Python or
otherwise) will produce a working install - it's designed (and
documented by Microsoft) as being to allow system admins to unpack the
MSI onto a network share from where it can be installed onto user
machines (for details see
https://msdn.microsoft.com/en-us/library/windows/desktop/aa367541(v=vs.85).aspx).

--

___
Python tracker 

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

[issue29231] Broken MSIs in Python 3.5+

[Steve Dower]

Steve Dower added the comment:

Ah, you're using the full installer, which has the non-debug versions embedded 
and therefore does not ever need to download them.

If you start from the web installer, it will download the MSIs for the 
non-debug components as well. But as I said, you're in totally unsupported 
territory by not running the proper installer. See if the nuget packages are 
more helpful.

--

___
Python tracker 

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

[issue29231] Broken MSIs in Python 3.5+

[KeyWeeUsr]

KeyWeeUsr added the comment:

python-3.5.2.exe /layout 

11.01.2017  19:30  .
11.01.2017  19:30  ..
11.01.2017  19:30 3 035 136 core_d.msi
11.01.2017  19:30 2 240 512 core_pdb.msi
11.01.2017  19:3098 304 dev_d.msi
11.01.2017  19:30   110 592 exe_d.msi
11.01.2017  19:30   102 400 exe_pdb.msi
11.01.2017  19:30 5 378 048 lib_d.msi
11.01.2017  19:30 4 820 992 lib_pdb.msi
29.10.2016  11:1329 269 656 python-3.5.2.exe
11.01.2017  19:30 1 179 648 tcltk_d.msi
11.01.2017  19:30   139 264 tcltk_pdb.msi
11.01.2017  19:30   331 776 test_d.msi
11.01.2017  19:30   286 720 test_pdb.msi
  12 File(s) 46 993 048 bytes
   2 Dir(s)   1 245 736 960 bytes free
---
msiexec /a exe_d.msi targetdir=%cd%\

Msiexec window has title "Python 3.5.2 Executables (32-bit debug)" and the 
targetdir contains:

11.01.2017  19:36  .
11.01.2017  19:36  ..
25.06.2016  21:5751 712 pythonw_d.exe
25.06.2016  21:57   364 544 pythonw_d.pdb
25.06.2016  21:5751 712 python_d.exe
25.06.2016  21:57   364 544 python_d.pdb
   4 File(s)832 512 bytes
   2 Dir(s)   1 264 963 584 bytes free

Notice, that everywhere is "_d" I talk about so much.

> ...and puts them in a location where they will be used later without 
> redownloading...

Yes, in a state that only the EXE installer is able to use them.

> *hypothetical*

msiexec /a python-2.7.13.msi targetdir=%cd%\

11.01.2017  19:45  .
11.01.2017  19:45  ..
11.01.2017  19:45  DLLs
11.01.2017  19:45  Doc
11.01.2017  19:45  include
11.01.2017  19:45  Lib
11.01.2017  19:45  libs
17.12.2016  20:4938 591 LICENSE.txt
17.12.2016  20:34   474 595 NEWS.txt
11.01.2017  19:45   835 584 python-2.7.13.msi
17.12.2016  20:4427 136 python.exe
17.12.2016  20:43 2 639 872 python27.dll
17.12.2016  20:4427 648 pythonw.exe
03.12.2016  21:0156 938 README.txt
11.01.2017  19:45  tcl
11.01.2017  19:45  Tools
17.12.2016  20:44   111 104 w9xpopen.exe
   8 File(s)  4 211 468 bytes
   9 Dir(s)   1 162 199 040 bytes free

Fully usable, portable and working Python interpreter for Python installers 
<3.5.0 without a single beep about admin rights (kivy, numpy, scipy, cython, 
mingwpy, etc.). With some workaround probably even usable for ALLUSERS=1, but 
I'm not going to try that on my system.

How is Debug installer not an issue/bug in a Python Release? Am I missing 
something or is it ok to unpack Debug installers from an official installer and 
not the actually used ones, the ones that produce Release that works?

--

___
Python tracker 

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

[issue29244] Python 3.6 unnecessarily requires inttypes.h

[rdb]

rdb added the comment:

As far as I know, there should not be any ABI issues.  We've been building 
extension modules with non-matching MSVC versions for years without issues.

I find it hard to think of downsides to such a trivial fix.  It is somewhat 
frustrating that we will have to resort to shipping custom Python versions with 
patched headers.  Some people are constrained to older MSVC versions for 
reasons not in their control.

--

___
Python tracker 

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

[issue29244] Python 3.6 unnecessarily requires inttypes.h

[Brett Cannon]

Brett Cannon added the comment:

Everything Zach said is accurate, so closing as "wont fix".

--
nosy: +brett.cannon
resolution:  -> wont fix
status: open -> closed

___
Python tracker 

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

[issue29243] --enable-optimizations makes common build commands always need to compile from scratch

[Brett Cannon]

Brett Cannon added the comment:

Since optimizations uses PGO which should do a fresh run, that's why there's 
the clearing of the state.

I'm personally not bothered by it as you really should only being doing an 
optimized build once when you do the first install and then you're done. But if 
or anyone else can come up with a way to not clear out the results while not 
accidentally using stale PGO-collected stats or builds then I don't see why we 
can't speed it up.

--
nosy: +brett.cannon
type:  -> enhancement

___
Python tracker 

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

[issue29244] Python 3.6 unnecessarily requires inttypes.h

[Zachary Ware]

Zachary Ware added the comment:

VS 2010 is not a supported compiler version for 3.6 (or 3.5) and VS 2012 is not 
a supported compiler for any version of Python. Extension modules built by 
those versions for use with Python 3.6 as supplied by python.org will only work 
in very particular circumstances which cannot be relied upon. Furthermore, VS 
2015 community edition is free (as in beer) and perfectly suitable for building 
both Python and extension modules.

I'd recommend closing as won't fix, but if another committer feels strongly 
enough about it I'll defer to them.

--
nosy: +zach.ware

___
Python tracker 

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

[issue27603] Migrate IDLE context menu items to shell extension

[Steve Dower]

Steve Dower added the comment:

The last time I saw collected data on usage (based on Visual Studio users), 
there was no clear majority of "number of interpreter versions", but 3 was the 
most common (2 and 4 were roughly equal, 5 and 6 were more popular than 1).

The nesting also makes it considerably simpler for the installer to handle, 
since there are totally independent components contributing to the file 
association. This is very difficult to achieve in a reliable way (wrt 
upgrades/downgrades/uninstalls/repairs/order-of-install/etc.), and having the 
context menu here is the best balance of reliability, usability and ease of 
implementation.

Using the shell extension to generate the menu would also work well, as that is 
part of the launcher and independent of any particular Python installer. It can 
also automatically un-nest the menu when it's going to be short enough, or show 
the latest version at the top and nest all others. Ultimately though, 
implementing that requires somebody's time, and until somebody is motivated 
enough to do the work, it won't happen.

So your suggestion is valid, it just isn't motivating enough for me to make the 
change. That doesn't mean someone else can't do it, and from a personal level I 
will oppose a straight un-nesting (as I'm one of the outliers who has 20+ 
copies of Python installed on my machines :) ), but I'm totally in favour of a 
well implemented shell extension to make it more complete and easier to use.

--

___
Python tracker 

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

[issue29231] Broken MSIs in Python 3.5+

[Steve Dower]

Steve Dower added the comment:

"msiexec /a" does not install anything - it converts the MSI into a source 
layout for lazy network installs. It is, and always has been, completely 
unsupported as an approach to installing Python, and we are under no obligation 
to maintain it.

Copy-pasting the install folder after installation is also unsupported. We 
obviously can't stop you doing it, and at times it is the best way to achieve 
certain things, but it is not supported and we do not have to make it work 
better.

The /layout command is intended for full offline installs: it downloads all 
optional packages without evaluating any conditions and puts them in a location 
where they will be used later without redownloading.

You've always been able to use only a single micro version of Python at a time 
when installing it. That has not changed (and will not, as it's by design). We 
have added new package formats that do not install the full development kit, 
and it sounds like the nuget packages (a.k.a. zip files by a different name) 
are perfect for you.

I have no idea what the "-d" suffix is, unless you mean the "_d.msi" modules 
which contain different files from the non-"_d" versions. The internals of the 
installer are just that - internals - but FYI there are typically 3 installers 
for each component. For example, "exe.msi" contains the files related to 
launching an interactive shell (including licenses, shortcuts, and icons); 
"exe_pdb.msi" contains the PDB files associated with files in exe.msi; 
"exe_d.msi" contains a debug build for those who are debugging native 
extensions and want consistent build settings between Python and their 
extension.

Your criticism of the *hypothetical* single MSI installer doesn't make any 
sense, since that installer does not exist. I included those points to show 
what restrictions would be necessary to avoid any such single MSI installer 
breaking users who would prefer to use the EXE installer.

There is no bug here, so I'm closing the issue.

--
resolution:  -> not a bug
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

[issue29244] Python 3.6 unnecessarily requires inttypes.h

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
components: +Build -Extension Modules
nosy: +benjamin.peterson
type:  -> compile error
versions: +Python 3.7

___
Python tracker 

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

[issue22343] Install bash activate script on Windows when using venv

[Vinay Sajip]

Vinay Sajip added the comment:

If we do this, the activate script will have LF (POSIX) line endings on 
Windows. Will this work for things like cygwin, Git-bash etc?

--

___
Python tracker 

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

[issue20804] Sentinels identity lost when pickled (unittest.mock)

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Thank you for your review Michael.

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

___
Python tracker 

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

[issue29213] python -m venv activate.bat has weird mix of line endings

[Vinay Sajip]

Vinay Sajip added the comment:

Although we don't currently have binaries under venv/scripts, that might change 
in the future. The logic could be changed to:

with open(srcfile, 'rb') as f:
data = f.read()
if not srcfile.endswith('.exe'):
try:
data = data.decode('utf-8')
data = self.replace_variables(data, context)
data = data.encode('utf-8')
except UnicodeError as e:
data = None
logger.warning('unable to copy script %r, '
   'may be binary: %s', srcfile, e)
if data is not None:
with open(dstfile, 'wb') as f:
f.write(data)
shutil.copymode(srcfile, dstfile)

All the files in the nt subdirectory have CRLF endings, and the above should 
preserve them (whatever they are).

--

___
Python tracker 

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

[issue20804] Sentinels identity lost when pickled (unittest.mock)

[Roundup Robot]

Roundup Robot added the comment:

New changeset 398b73dbb1a0 by Serhiy Storchaka in branch '3.5':
Issue #20804: Document the limitation of the unittest.mock.sentinel attributes.
https://hg.python.org/cpython/rev/398b73dbb1a0

--

___
Python tracker 

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

[issue20804] Sentinels identity lost when pickled (unittest.mock)

[Roundup Robot]

Roundup Robot added the comment:

New changeset 98f061402fcf by Serhiy Storchaka in branch 'default':
Issue #20804: The unittest.mock.sentinel attributes now preserve their
https://hg.python.org/cpython/rev/98f061402fcf

--
nosy: +python-dev

___
Python tracker 

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

[issue29244] Python 3.6 unnecessarily requires inttypes.h

[rdb]

New submission from rdb:

Python 3.6 now requires inttypes.h on all platforms.  However, this is not 
provided by MSVC 2010 and 2012, which is still used by some people who build 
extension modules for Python.

MSVC 2010 does provide stdint.h, and replacing the inttypes.h include with an 
include to stdint.h seems to work fine.

I would suggest a fix along the lines of this:

#if defined(_MSC_VER) && _MSC_VER < 1800
#include 
#else
#include 
#endif

Alternatively, the HAVE_INTTYPES_H definition could be used to fall back to 
stdint.h, and it could be undefined for the MSVC build.

--
components: Extension Modules
messages: 285250
nosy: rdb
priority: normal
severity: normal
status: open
title: Python 3.6 unnecessarily requires inttypes.h
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

[issue20804] Sentinels identity lost when pickled (unittest.mock)

[Michael Foord]

Michael Foord added the comment:

LGTM Serhiy - thank you for your work. Appreciated.

--

___
Python tracker 

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

[issue29220] Python 3.6 regression/change using logging.addLevelName() to clear a name

[Vinay Sajip]

Changes by Vinay Sajip :


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

___
Python tracker 

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

[issue29220] Python 3.6 regression/change using logging.addLevelName() to clear a name

[Roundup Robot]

Roundup Robot added the comment:

New changeset adf8312f377f by Vinay Sajip in branch '3.5':
Issue #29220: Improved fix and test.
https://hg.python.org/cpython/rev/adf8312f377f

New changeset a76eed0baa0f by Vinay Sajip in branch 'default':
Issue #29220: Merged fixes from 3.6.
https://hg.python.org/cpython/rev/a76eed0baa0f

--

___
Python tracker 

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

[issue29231] Broken MSIs in Python 3.5+

[KeyWeeUsr]

KeyWeeUsr added the comment:

Re blog post "Why are there so many Python installers?"

> As a result, the old installer always requires administrative privileges just 
> in case you choose to install for all users. This prevents installation of 
> Python on machines where you do not have full control over the system.

So not true. Read the first command I used, that doesn't require any permission 
at all. I was able to install Python without any registry or P stuff at 
"Guest" account in an internet cafe where you couldn't even throw stuff to the 
Trash with the same MSI installer. Notice the "/a" switch, not "/i" (install).

Secondly, I'm glad for the change, but the installer is still in an imperfect 
shape - leaves traces. That makes you able to use only a single version (as 
mentioned before). Unless, of course, you don't want to copy the whole 
folder, which although works is also stupid and still requires at least one 
successful installation with traces in the system.

> Always requires administrator privileges <-- no
Only allows installation for all users <-- no
Only allows configuration at the command line (via msiexec) <-- not sure what 
the "configuration" means in this context
Prevents the executable installer from installing for all users <-- I didn't 
really use that, but... what? Seems weird. Have you tried with "/a ALLUSERS=1"? 
It should purge the elevation.

Anyway, this has nothing to do with the issue, because what I'm talking about 
are MSIs that are _extracted_ from the current EXE installer via "/layout" 
switch. There comes the problem - you can't install from those MSIs (not 
directly, but probably works with EXE as a casual python installation - I don't 
want that), because the MSIs are ***corrupted*** in some weird way, probably 
some debug command is called together with the "/layout" judging from the "-d" 
string in the filenames - useful only for debugging the inside of the MSIs, 
otherwise completely unusable. Please, just try to do what I wrote to see 
what's actually going on.

If there is any way how to fix the "/layout" to unpack correctly, ++ for the 
new installer. Otherwise, although the EXE has a lot of features I use for 
system-wide interpreter, I hate the change.

--

___
Python tracker 

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

[issue28759] access to mkfifo, mknod and hard links is controled by SELinux MAC on Android

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

I don't know what is a good name for such helper. supported_operation() looks 
too general. Maybe ask on Python-Dev?

--

___
Python tracker 

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

[issue29099] sqlite3 timestamp converter cannot handle timezone

[Marc-Andre Lemburg]

Marc-Andre Lemburg added the comment:

On 11.01.2017 17:04, Xiang Zhang wrote:
> I am not sure it's worth to make it even optional in 3.7. Discarding tzinfo 
> sounds weird, and worse, the behaviour is not deterministic, it could also 
> fail with an exception.

Best practice is to store all date/time values using UTC (or some
other fixed timezone) in databases and to manage the timezone/locale
information elsewhere.

The TZ info then becomes redundant and only results in more
database space being used as well as slower queries (due to the extra
TZ calculations being done; many databases internally store the
values as UTC to avoid having to do TZ calculations at query time).

Of course, there are use cases, where you'd still want to work
with TZ values in the database, so an extra converter for this
sounds like a good plan.

--

___
Python tracker 

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

[issue29099] sqlite3 timestamp converter cannot handle timezone

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
stage: commit review -> needs patch
type: behavior -> enhancement
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

[issue29099] sqlite3 timestamp converter cannot handle timezone

[Marc-Andre Lemburg]

Marc-Andre Lemburg added the comment:

On 11.01.2017 17:08, Serhiy Storchaka wrote:
> 
> The naive datetime converter is registered under the name "timestamp". The 
> aware datetime converter or the universal datetime converter (if it is 
> needed) can be registered under different names.

This sounds like a good idea.

Perhaps use "timestamptz" or something similar.

--

___
Python tracker 

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

[issue20804] Sentinels identity lost when pickled (unittest.mock)

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Updated patch contains doc changes.

--
type: behavior -> enhancement
versions:  -Python 3.5, Python 3.6
Added file: http://bugs.python.org/file46260/mock_sentinel_pickle2.patch

___
Python tracker 

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

[issue27603] Migrate IDLE context menu items to shell extension

[Shane Smith]

Shane Smith added the comment:

I'm fine with a single implementation, so long as the implementation is what's 
best for the majority of users.  Not my intent to increase the burden of work.

So, let me ask the question alluded to in my first post: when is a nested menu 
actually desirable?  I would argue that the vast majority of users have one or 
two versions of Python installed at any given time.  And for that number, a 
flat menu is certainly preferred.

The X.Y version numbering in the context menu introduced as a result of 
issue23546 solves said issue.  I'm merely suggesting de-nesting the menu.

--

___
Python tracker 

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

[issue20804] Sentinels identity lost when pickled (unittest.mock)

[Michael Foord]

Michael Foord added the comment:

It's a new feature.

--

___
Python tracker 

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

[issue29231] Broken MSIs in Python 3.5+

[Steve Dower]

Steve Dower added the comment:

I discussed installers on my blog at http://stevedower.id.au a while back. 
There are some other options linked from there, and also rationale for why 
things are how they are.

--

___
Python tracker 

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

[issue20804] Sentinels identity lost when pickled (unittest.mock)

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

sentinel-doc.patch documents the contrary behaviour -- not preserving an 
identity and equality.

I haven't included doc changes because I don't know how to treat this change. 
As a bug fix, as a new feature, or as a new feature backported to maintained 
releases? If this is a new feature, it needs an entry in Whant's New and a 
versionchanged directive in the module documentation. If this is a bug fix, it 
likely doesn't need any special documenting.

--

___
Python tracker 

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

[issue29241] sys._enablelegacywindowsfsencoding() don't apply to os.fsencode and os.fsdecode

[Steve Dower]

Steve Dower added the comment:

If you import os first then that's acceptable and we should document it more 
clearly. Try calling enable before importing os.

I wouldn't be surprised if os is imported automatically, in which case we need 
to figure out some alternate caching mechanism that can be reset by the enable 
call (or demonstrate that the caching is of no benefit).

--

___
Python tracker 

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

[issue27603] Migrate IDLE context menu items to shell extension

[Steve Dower]

Steve Dower added the comment:

More user choice here is actually an incredibly huge burden. Managing file 
associations across a range of versions, many of which can no longer be 
updated, is hard enough without offering options. Not to mention the extra user 
interface required.

Personally, I'd rather the options be third party installers or tools. There's 
nothing stopping someone making an idle "installer" that sets up context menus 
and default actions however it likes. It would probably break uninstall/upgrade 
scenarios for the core Python install, but at least it's not a burden on our 
(very few) volunteers to diagnose, fix and prevent.

If or when the shell extension takes over the context menu (currently blocked 
on someone volunteering to do the implementation and testing), it may be 
possible to have registry keys to change the behavior. But I wouldn't count on 
it being highly configurable - that's not the aim of the main distro.

--

___
Python tracker 

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

[issue29057] Compiler failure on Mac OS X - sys/random.h

[George King]

George King added the comment:

This is using the latest apple toolchain on latest macOS 10.12.2:

$ gcc --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr 
--with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 8.0.0 (clang-800.0.42.1)
Target: x86_64-apple-darwin16.3.0
Thread model: posix
InstalledDir: 
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

$ make --version
GNU Make 3.81
Copyright (C) 2006  Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.

This program built for i386-apple-darwin11.3.0

--

___
Python tracker 

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

[issue29057] Compiler failure on Mac OS X - sys/random.h

[George King]

George King added the comment:

Still seeing this problem. Here was my exact process:

$ git clone g...@github.com:python/cpython.git
$ cd cpython
$ git checkout 2.7
$ mkdir build
$ cd build
$ ../configure
$ make

In file included from ../Python/random.c:7:
/usr/include/sys/random.h:37:32: error: unknown type name 'u_int'

--

___
Python tracker 

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

[issue28231] zipfile does not support pathlib

[Ethan Furman]

Ethan Furman added the comment:

Any path/file attributes, etc, inside a ZipFile should be str.  ZipFile should 
also function properly if path/file requests are given as os.PathLike objects.

--

___
Python tracker 

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

[issue29240] Implementation of the PEP 540: Add a new UTF-8 mode

[INADA Naoki]

Changes by INADA Naoki :


--
nosy: +inada.naoki

___
Python tracker 

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

[issue29243] --enable-optimizations makes common build commands always need to compile from scratch

[Xiang Zhang]

New submission from Xiang Zhang:

In 3.6 we get --enable-optimizations. One thing I find annoyed with this flag 
is that it makes some build commands compile from scratch since it always 
clears the environment first. For example, with the commands listed at the top 
of Makefile:

./configure
make 
make test
make install

It compiles 3 times and considering the optimized build needs more time every 
time, it lasts long.

I am not sure this is a problem and feel free to close it.

--
components: Build
messages: 285233
nosy: xiang.zhang
priority: normal
severity: normal
status: open
title: --enable-optimizations makes common build commands always need to 
compile from scratch
versions: Python 3.6, Python 3.7

___
Python tracker 

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

[issue29099] sqlite3 timestamp converter cannot handle timezone

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

The naive datetime converter is registered under the name "timestamp". The 
aware datetime converter or the universal datetime converter (if it is needed) 
can be registered under different names.

--

___
Python tracker 

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

[issue29099] sqlite3 timestamp converter cannot handle timezone

[Xiang Zhang]

Xiang Zhang added the comment:

I asked whether this should be treated as an enhancement or bug fix. Now with 
your concerns I think it fits as enhancement more.

> Is it possible to make the support optional for 3.5 and 3.6 and only enable 
> it for 3.7 (with the possibility of disabling it again) ?

How about just make it just into 3.7 and just document only naive datetime 
objects are supported in 3.5, 3.6 and 2.7.
I am not sure it's worth to make it even optional in 3.7. Discarding tzinfo 
sounds weird, and worse, the behaviour is not deterministic, it could also fail 
with an exception.

--

___
Python tracker 

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

[issue29099] sqlite3 timestamp converter cannot handle timezone

[Marc-Andre Lemburg]

Marc-Andre Lemburg added the comment:

I don't think this can be considered a bug fix, since it changes behavior for 
applications that read data from SQLite databases which were not created by 
Python.

Those application may now see datetime values with tz infos and will likely not 
be prepared to handle all the problems associated with this.

Is it possible to make the support optional for 3.5 and 3.6 and only enable it 
for 3.7 (with the possibility of disabling it again) ?

--

___
Python tracker 

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

[issue29099] sqlite3 timestamp converter cannot handle timezone

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Agreed. And maybe raise more informative error for datetimes with a timezone.

I'm also not sure about 3.5 and 3.6. Datetimes with timezones were never 
supported. Currently all returned ditetime objects are naive. Getting an aware 
datetime can confuse applications.

--

___
Python tracker 

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

[issue29242] Crash on GC when compiling PyPy

[Dingyuan Wang]

New submission from Dingyuan Wang:

When compiling the PyPy default branch [1] on a Debian testing machine with 
Python 2.7.13, cpython randomly crashes.

(gdb) bt
#0  update_refs () at ../Modules/gcmodule.c:332
#1  collect.lto_priv () at ../Modules/gcmodule.c:924
#2  0x5562a804 in collect_generations () at ../Modules/gcmodule.c:1050
#3  _PyObject_GC_Malloc () at ../Modules/gcmodule.c:1511
#4  0x55640ef5 in PyType_GenericAlloc (nitems=0, type=0x55a9dd20 
<_PyExc_AttributeError>) at ../Objects/typeobject.c:781
#5  BaseException_new.lto_priv.68 () at ../Objects/exceptions.c:34
#6  0x55642093 in type_call.lto_priv () at ../Objects/typeobject.c:749
#7  0x5563c5f3 in PyObject_Call () at ../Objects/abstract.c:2547
#8  0x5565a490 in PyEval_CallObjectWithKeywords () at 
../Python/ceval.c:4221
#9  0x556695d0 in PyErr_NormalizeException () at ../Python/errors.c:192
#10 0x55656cad in PyEval_EvalFrameEx () at ../Python/ceval.c:3251
#11 0x5564e525 in PyEval_EvalCodeEx () at ../Python/ceval.c:3584
#12 0x5566ac2e in function_call.lto_priv () at 
../Objects/funcobject.c:523
#13 0x5563c5f3 in PyObject_Call () at ../Objects/abstract.c:2547
#14 0x5568102e in instancemethod_call.lto_priv () at 
../Objects/classobject.c:2602
#15 0x5563c5f3 in PyObject_Call () at ../Objects/abstract.c:2547
#16 0x556f333a in call_method.lto_priv () at 
../Objects/typeobject.c:1283
#17 0x5573eb8f in slot_tp_setattro.lto_priv () at 
../Objects/typeobject.c:5654
#18 0x556667e9 in PyObject_SetAttr () at ../Objects/object.c:1247
#19 0x55650ec3 in PyEval_EvalFrameEx () at ../Python/ceval.c:2253
#20 0x5564e525 in PyEval_EvalCodeEx () at ../Python/ceval.c:3584
#21 0x5566ac2e in function_call.lto_priv () at 
../Objects/funcobject.c:523
#22 0x5563c5f3 in PyObject_Call () at ../Objects/abstract.c:2547
#23 0x5568102e in instancemethod_call.lto_priv () at 
../Objects/classobject.c:2602
#24 0x5563c5f3 in PyObject_Call () at ../Objects/abstract.c:2547
#25 0x5565a4dd in PyEval_CallObjectWithKeywords () at 
../Python/ceval.c:4221
#26 0x556f3e31 in slot_tp_hash.lto_priv () at 
../Objects/typeobject.c:5506
#27 0x5568c908 in dict_subscript.lto_priv () at 
../Objects/dictobject.c:1202
#28 0x5565618e in PyEval_EvalFrameEx () at ../Python/ceval.c:1539
#29 0x5564e525 in PyEval_EvalCodeEx () at ../Python/ceval.c:3584
#30 0x5566ac2e in function_call.lto_priv () at 
../Objects/funcobject.c:523
#31 0x5563c5f3 in PyObject_Call () at ../Objects/abstract.c:2547
#32 0x5568102e in instancemethod_call.lto_priv () at 
../Objects/classobject.c:2602
#33 0x5563c5f3 in PyObject_Call () at ../Objects/abstract.c:2547
#34 0x5565a490 in PyEval_CallObjectWithKeywords () at 
../Python/ceval.c:4221
#35 0x5569ff3a in instance_subscript.lto_priv () at 
../Objects/classobject.c:1105
#36 0x5565618e in PyEval_EvalFrameEx () at ../Python/ceval.c:1539
#37 0x5564e525 in PyEval_EvalCodeEx () at ../Python/ceval.c:3584
#38 0x5566ac2e in function_call.lto_priv () at 
../Objects/funcobject.c:523
#39 0x5563c5f3 in PyObject_Call () at ../Objects/abstract.c:2547
#40 0x55672dd9 in slot_tp_new.lto_priv () at 
../Objects/typeobject.c:5849
#41 0x55642093 in type_call.lto_priv () at ../Objects/typeobject.c:749
#42 0x5563c5f3 in PyObject_Call () at ../Objects/abstract.c:2547
#43 0x55655e8f in do_call (nk=, na=1, 
pp_stack=0x7fffb950, func=) at 
../Python/ceval.c:4569
#44 call_function (oparg=, pp_stack=0x7fffb950) at 
../Python/ceval.c:4374
#45 PyEval_EvalFrameEx () at ../Python/ceval.c:2989
#46 0x55655c7f in fast_function (nk=, na=, n=, pp_stack=0x7fffbaa0, func=) at ../Python/ceval.c:4437
#47 call_function (oparg=, pp_stack=0x7fffbaa0) at 
../Python/ceval.c:4372
#48 PyEval_EvalFrameEx () at ../Python/ceval.c:2989
#49 0x55655c7f in fast_function (nk=, na=, n=, pp_stack=0x7fffbbf0, func=) at ../Python/ceval.c:4437
#50 call_function (oparg=, pp_stack=0x7fffbbf0) at 
../Python/ceval.c:4372
#51 PyEval_EvalFrameEx () at ../Python/ceval.c:2989
#52 0x55655c7f in fast_function (nk=, na=, n=, pp_stack=0x7fffbd40, func=) at ../Python/ceval.c:4437
---Type  to continue, or q  to quit---
#53 call_function (oparg=, pp_stack=0x7fffbd40) at 
../Python/ceval.c:4372
#54 PyEval_EvalFrameEx () at ../Python/ceval.c:2989
#55 0x55655c7f in fast_function (nk=, na=, n=, pp_stack=0x7fffbe90, func=) at ../Python/ceval.c:4437
#56 call_function (oparg=, pp_stack=0x7fffbe90) at 
../Python/ceval.c:4372
#57 PyEval_EvalFrameEx () at ../Python/ceval.c:2989
#58 0x55655c7f in fast_function (nk=, na=, n=, pp_stack=0x7fffbfe0, func=) at ../Python/ceval.c:4437
#59 call_function (oparg=, pp_stack=0x7fffbfe0) at 
../Python/ceval.c:4372
#60 

[issue29099] sqlite3 timestamp converter cannot handle timezone

[Xiang Zhang]

Xiang Zhang added the comment:

> LGTM except that arguments of assertEqual() should be swapped.

Thanks Serhiy! I'll take care of that. One problem remained is what to do with 
2.7. There is no timezone object in 2.7. My preference is just pointing out the 
limitation that only naive datetime object is supported in the doc.

--

___
Python tracker 

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

[issue29220] Python 3.6 regression/change using logging.addLevelName() to clear a name

[Vinay Sajip]

Vinay Sajip added the comment:

OK, will apply to 3.5 -> default.

--

___
Python tracker 

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

[issue29220] Python 3.6 regression/change using logging.addLevelName() to clear a name

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

I'm sure. e4b6faf22e8d is in 3.5 branch.

--

___
Python tracker 

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

[issue29220] Python 3.6 regression/change using logging.addLevelName() to clear a name

[Vinay Sajip]

Vinay Sajip added the comment:

> The fix should be applied to 3.5.

Are you sure?

$ python3.5
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.
>>> import logging
>>> logging.getLevelName(logging.NOTSET)
'NOTSET'
>>> logging.getLevelName('NOTSET')
0
>>> 

I think just 3.6 and default are affected - doesn't 3.5 seem OK?

--

___
Python tracker 

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

[issue27603] Migrate IDLE context menu items to shell extension

[Shane Smith]

Shane Smith added the comment:

Hi Vedran, that seems to now be the default behavior, regardless of previous 
installs (my 3.6 was a clean install, and it's still nested).  Kind of a pain 
if you want to edit with IDLE frequently.

While we wait for a more integrated solution, the hackish way to restore 
desired behavior is to run a .bat file containing:

REG DELETE "HKEY_CLASSES_ROOT\Python.File\shell\editwithidle"

Then run a .reg file (also just a text file with altered extension so windows 
knows what to do with it) with:

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\Python.File\shell\Edit with IDLE 3.6\command]
@="\"C:\\Program Files\\Python36\\pythonw.exe\" -m idlelib \"%L\" %*"

--

___
Python tracker 

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

[issue1294959] Problems with /usr/lib64 builds.

[Charalampos Stratakis]

Charalampos Stratakis added the comment:

The downstream patch we currently use in Fedora [0].

[0] http://pkgs.fedoraproject.org/cgit/rpms/python3.git/plain/00102-lib64.patch

--
nosy: +cstratak

___
Python tracker 

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

[issue15216] Support setting the encoding on a text stream after creation

[INADA Naoki]

INADA Naoki added the comment:

set_encoding-8.patch dropped support of changing encoding after read.
It is based on set_encoding-newline.patch

--
Added file: http://bugs.python.org/file46259/set_encoding-8.patch

___
Python tracker 

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

[issue29241] sys._enablelegacywindowsfsencoding() don't apply to os.fsencode and os.fsdecode

[JGoutin]

New submission from JGoutin:

The doc say that calling "sys._enablelegacywindowsfsencoding()" is equivalent 
to use "PYTHONLEGACYWINDOWSFSENCODING" environment variable.

In fact, this no apply to "os.fsencode" and "os.fsdecode".

Example with Python 3.6 64Bits on Windows 7 64 bits :


EXAMPLE CODE 1 (sys._enablelegacywindowsfsencoding()): 

import sys
import os

# Force the use of legacy encoding like versions of Python prior to 3.6.
sys._enablelegacywindowsfsencoding()

# Show actual file system encoding
encoding = sys.getfilesystemencoding()
print('File system encoding:', encoding)

# os.fsencode(filename) VS filename.encode(File system encoding)
print(os.fsencode('é'), 'é'.encode(encoding))

>>> File system encoding: mbcs
>>> b'\xc3\xa9' b'\xe9'


First is encoded with "utf-8" and not "mbcs" (The actual File system encoding)


EXAMPLE CODE 2 (PYTHONLEGACYWINDOWSFSENCODING): 

import sys
import os

# Force the use of legacy encoding like versions of Python prior to 3.6.
# "PYTHONLEGACYWINDOWSFSENCODING" environment variable set before running 
Python.

# Show actual file system encoding
encoding = sys.getfilesystemencoding()
print('File system encoding:', encoding)

# os.fsencode(filename) VS filename.encode(File system encoding)
print(os.fsencode('é'), 'é'.encode(encoding))

>>> File system encoding: mbcs
>>> b'\xe9' b'\xe9'


Everything encoded with "mbcs" (The actual File system encoding)


In "os.fsencode" and "os.fsdecode" encoding and errors are cached on start and 
never updated by "sys._enablelegacywindowsfsencoding()" after.

--
components: Windows
messages: 285220
nosy: JGoutin, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: sys._enablelegacywindowsfsencoding() don't apply to os.fsencode and 
os.fsdecode
type: behavior
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

[issue29239] Fix wrong issue number in what's new entry

[Martin Panter]

Martin Panter added the comment:

Thanks Jim

--
nosy: +martin.panter
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
versions: +Python 3.7

___
Python tracker 

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

[issue15657] Error in Python 3 docs for PyMethodDef

[Roundup Robot]

Roundup Robot added the comment:

New changeset d7d2d24003f5 by Martin Panter in branch '3.5':
Issue #15657: METH_KEYWORDS cannot be used alone in Python 3
https://hg.python.org/cpython/rev/d7d2d24003f5

New changeset c140e72492a4 by Martin Panter in branch '3.6':
Issue #15657: Delete incorrect statement from PyMethodDef documentation
https://hg.python.org/cpython/rev/c140e72492a4

New changeset 021fd2ff7ca4 by Martin Panter in branch '3.6':
Issue #15657: Merge other doc fix from 3.5
https://hg.python.org/cpython/rev/021fd2ff7ca4

New changeset 1058e151049a by Martin Panter in branch 'default':
Issue #15657: Merge METH_KEYWORDS doc from 3.6
https://hg.python.org/cpython/rev/1058e151049a

--

___
Python tracker 

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

[issue29239] Fix wrong issue number in what's new entry

[Roundup Robot]

New submission from Roundup Robot:

New changeset 114b03fa4c04 by Martin Panter in branch '3.6':
Issue #29239: Fix --enable-optimizations bug number
https://hg.python.org/cpython/rev/114b03fa4c04

New changeset 4e29c7f2b3e5 by Martin Panter in branch 'default':
Issue #29239: Merge bug number from 3.6
https://hg.python.org/cpython/rev/4e29c7f2b3e5

--
nosy: +python-dev

___
Python tracker 

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

[issue29240] Implementation of the PEP 540: Add a new UTF-8 mode

[STINNER Victor]

STINNER Victor added the comment:

Examples with pep540_cli.py.

Python 3.5:

$ python3 pep540_cli.py 
sys.argv: ['pep540_cli.py']
stdin: UTF-8/strict
stdout: UTF-8/strict
stderr: UTF-8/backslashreplace
open(): UTF-8/strict

$ LC_ALL=C python3 pep540_cli.py 
sys.argv: ['pep540_cli.py']
stdin: ANSI_X3.4-1968/surrogateescape
stdout: ANSI_X3.4-1968/surrogateescape
stderr: ANSI_X3.4-1968/backslashreplace
open(): ANSI_X3.4-1968/strict


Patched Python 3.7:


$ ./python pep540_cli.py 
UTF-8 mode: 0
sys.argv: ['pep540_cli.py']
stdin: UTF-8/strict
stdout: UTF-8/strict
stderr: UTF-8/backslashreplace
open(): UTF-8/strict

$ LC_ALL=C ./python pep540_cli.py 
UTF-8 mode: 1
sys.argv: ['pep540_cli.py']
stdin: utf-8/surrogateescape
stdout: utf-8/surrogateescape
stderr: utf-8/backslashreplace
open(): utf-8/surrogateescape

$ ./python -X utf8 pep540_cli.py 
UTF-8 mode: 1
sys.argv: ['pep540_cli.py']
stdin: utf-8/surrogateescape
stdout: utf-8/surrogateescape
stderr: utf-8/backslashreplace
open(): utf-8/surrogateescape

$ ./python -X utf8=strict pep540_cli.py 
UTF-8 mode: 2
sys.argv: ['pep540_cli.py']
stdin: utf-8/strict
stdout: utf-8/strict
stderr: utf-8/backslashreplace
open(): utf-8/strict

--

___
Python tracker 

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

[issue29240] Implementation of the PEP 540: Add a new UTF-8 mode

[STINNER Victor]

STINNER Victor added the comment:

pep540.patch: first draft

Changes:

* Add sys.flags.utf8mode
* Add -X utf8 command line option
* Add PYTHONUTF8 environment variable
* sys.stdin, sys.stdout and sys.stderr encoding and errors are modified in 
UTF-8 mode
* open() default encoding and errors is modified in the UTF-8 mode
* Add Lib/test/test_utf8mode.py
* Skip a few tests relying on the locale encoding if the UTF-8 mode is enabled
* Document changes

Allowed options:

* Disable UTF-8 mode: -X utf8=0 or PYTHONUTF8=0
* Enable UTF-8 mode: -X utf8=1 or PYTHONUTF8=1
* Enable UTf-8 Strict mode: -X utf8=strict or PYTHONUTF8=strict
* Other -X utf8 and PYTHONUTF8 values cause a fatal error

Prioririties (highest to lowest):

* open() encoding and errors arguments
* PYTHONIOENCODING
* UTF-8 mode
* os.device_encoding()
* locale encoding

TODO:

* re-encode sys.argv from the local encoding to UTF-8 in Py_Main() when the 
UTF-8 mode is enabled
* support strict mode in Py_DecodeLocale() and Py_EncodeLocale()

--
keywords: +patch
Added file: http://bugs.python.org/file46258/pep540.patch

___
Python tracker 

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

[issue29240] Implementation of the PEP 540: Add a new UTF-8 mode

[STINNER Victor]

New submission from STINNER Victor:

This issue tracks the implementation of the PEP 540.

Attached pep540_cli.py script can be used to play with it.

--
components: Interpreter Core, Library (Lib), Unicode
files: pep540_cli.py
messages: 285214
nosy: ezio.melotti, haypo
priority: normal
pull_requests: 15
severity: normal
status: open
title: Implementation of the PEP 540: Add a new UTF-8 mode
type: enhancement
versions: Python 3.7
Added file: http://bugs.python.org/file46257/pep540_cli.py

___
Python tracker 

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

[issue29116] Make str and bytes error messages on concatenation conform with other sequences

[Jim Fasarakis-Hilliard]

Jim Fasarakis-Hilliard added the comment:

As I currently see this: 

 - The error message for str can be changed to the one used for other sequences 
'can only concatenate str (not "type") to str'

 - The error message for arrays can be changed to use concatenate instead of 
append, too.

For bytes I see a conundrum, on one hand it can be changed to mention the 
buffer protocol which might confuse new users more than it helps them or, it 
can try and mention the objects that currently conform to it which might be 
exhaustive and long.

--

___
Python tracker 

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

[issue20804] Sentinels identity lost when pickled (unittest.mock)

[Michael Foord]

Michael Foord added the comment:

I think option 3 is the correct semantic behaviour for sentinels, and if there 
are already examples of this in the standard library then it *doesn't* violate 
expected behaviour of pickling and copying (sentinel and singleton objects can 
be permitted to retain this property through copying and pickling if it is a 
document facet of their behaviour and a natural result of their use cases).

Sentinels exist *purely* to have unique, *identifiable* objects. So retaining 
identity is their "expected behaviour" as identity is their defining feature. 

So Serhiy, if you're happy that you've implemented this correctly - with tests 
and documentation updates (I see a separate doc patch) - go ahead and commit.

--

___
Python tracker 

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

[issue29099] sqlite3 timestamp converter cannot handle timezone

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

LGTM except that arguments of assertEqual() should be swapped.

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

[issue15216] Support setting the encoding on a text stream after creation

[INADA Naoki]

INADA Naoki added the comment:

> Inada, I think you messed up the positioning of bits of the patch. E.g. there 
> are now test methods declared > inside a helper function (rather than a test 
> class).

I'm sorry.  `patch -p1` merged previous patch into wrong place, and test passed 
accidently.

> Since it seems other people are in favour of this API, I would like to expand 
> it a bit to cover two uses  cases (see set_encoding-newline.patch):
> 
> * change the error handler without affecting the main character encoding
> * set the newline encoding (also suggested by Serhiy)

+1.  Since stdio is configured before running Python program, TextIOWrapper 
should be configurable after creation, as possible.

> Regarding Serhiy’s other suggestion about buffering parameters, perhaps 
> TextIOWrapper.line_buffering could become a writable attribute instead, and 
> the class could grow a similar write_through attribute. I don’t think these 
> affect encoding or decoding, so they could be treated independently.

Could them go another new issue?
This issue is too long to read already.

> The algorithm for rewinding unread data is complicated and can fail. What is 
> the advantage of using it? What is the use case for reading from a stream and 
> then changing the encoding, without a guarantee that it will work?
>
> Even if it is enhanced to never “fail”, it will still have strange behaviour, 
> such as data loss when a decoder is fed a single byte and produces multiple 
> characters (e.g. CR newline, backslashreplace, UTF-7).

When I posted the set_encoding-7.patch, I hadn't read io module deeply.  I just 
solved conflict and ran test.
After that, I read the code and I feel same thing (see msg285111 and msg285112).
Let's drop support changing encoding while reading.
It's significant step that allowing changing stdin encoding only before reading 
anything from it.


> One step in the right direction IMO would be to only support calling 
> set_encoding() when no extra read data has been buffered (or to explicitly 
> say that any buffered data is silently dropped). So there is no support for 
> changing the encoding halfway through a disk file, but it may be appropriate 
> if you can regulate the bytes being read, e.g. from a terminal (user input), 
> pipe, socket, etc.

Totally agree.


> But I would be happy enough without set_encoding(), and with something like 
> my rewrap() function at the bottom of 
> . It returns a 
> fresh TextIOWrapper, but when you exit the context manager you can continue 
> to reuse the old stream with the old settings.

I want one obvious way to control encoding and error handler from Python, (not 
from environment variable).
Rewrapping stream seems hacky way, rather than obvious way.

--

___
Python tracker 

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

[issue29214] Standard open() does not allow to specify file permissions.

[Christian Heimes]

Christian Heimes added the comment:

I like the partial opener trick. Can we have the examples in the public 
documentation of open(), too?

--

___
Python tracker 

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

[issue29239] Fix wrong issue number in what's new entry

[Jim Fasarakis-Hilliard]

Changes by Jim Fasarakis-Hilliard :


--
assignee: docs@python
components: Documentation
files: fix_issue.patch
keywords: patch
nosy: Jim Fasarakis-Hilliard, docs@python
priority: normal
severity: normal
status: open
title: Fix wrong issue number in what's new entry
versions: Python 3.6
Added file: http://bugs.python.org/file46256/fix_issue.patch

___
Python tracker 

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

[issue20804] Sentinels identity lost when pickled (unittest.mock)

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

I just don't know well the purpose of sentinels, and don't . I see fourth 
possible options:

1. Raise an exception when copy or pickle a sentinel. This is an option when we 
want to be sure that copying and pickling are not involved and we get the same 
object as passed.

2. Create an unique sentinel with unique unambiguous name when copy or unpickle 
a sentinel. This is a behavior of commonly used sentinels (object(), 
['sentinel'], etc), and current behavior of mock.sentinel (except that the name 
is left the same and this is confusing).

3. Preserve identity when copy or pickle/unpickle a sentinel. This is an option 
when test a function that uses multiprocessing or persistent cache and should 
restore an equivalent object. This is a behavior of enums, classes, functions 
or other global named objects.

4. Preserve equality but not identity when copy or pickle/unpickle a sentinel. 
This is similar to the third option.

All options look reasonable to me. I don't know what case is more common, what 
behavior is more expectable.

--

___
Python tracker 

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

[issue29006] 2.7.13 _sqlite more prone to "database table is locked"

[Armin Rigo]

Armin Rigo added the comment:

If I had a say, I would indeed revert 030e100f048a (2.7 branch) and 
81f614dd8136 (3.5 branch) as well as forward-port the revert to 3.6 and trunk.  
Then we wait for someone that really knows why the change was done in the first 
place.

--

___
Python tracker 

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

[issue29220] Python 3.6 regression/change using logging.addLevelName() to clear a name

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

> Historically, getLevelName() gets the name for a level *but also the level 
> for a name*

Ah, then getLevelName() was broken by issue27937.

>>> logging.getLevelName('NOTSET')
'Level NOTSET'

The fix should be applied to 3.5.

--
resolution: fixed -> 
stage: resolved -> needs patch
status: closed -> open
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

[issue15216] Support setting the encoding on a text stream after creation

[Martin Panter]

Martin Panter added the comment:

Inada, I think you messed up the positioning of bits of the patch. E.g. there 
are now test methods declared inside a helper function (rather than a test 
class).

Since it seems other people are in favour of this API, I would like to expand 
it a bit to cover two uses cases (see set_encoding-newline.patch):

* change the error handler without affecting the main character encoding
* set the newline encoding (also suggested by Serhiy)

Regarding Serhiy’s other suggestion about buffering parameters, perhaps 
TextIOWrapper.line_buffering could become a writable attribute instead, and the 
class could grow a similar write_through attribute. I don’t think these affect 
encoding or decoding, so they could be treated independently.

The algorithm for rewinding unread data is complicated and can fail. What is 
the advantage of using it? What is the use case for reading from a stream and 
then changing the encoding, without a guarantee that it will work?

Even if it is enhanced to never “fail”, it will still have strange behaviour, 
such as data loss when a decoder is fed a single byte and produces multiple 
characters (e.g. CR newline, backslashreplace, UTF-7).

One step in the right direction IMO would be to only support calling 
set_encoding() when no extra read data has been buffered (or to explicitly say 
that any buffered data is silently dropped). So there is no support for 
changing the encoding halfway through a disk file, but it may be appropriate if 
you can regulate the bytes being read, e.g. from a terminal (user input), pipe, 
socket, etc.

But I would be happy enough without set_encoding(), and with something like my 
rewrap() function at the bottom of 
. It returns a fresh 
TextIOWrapper, but when you exit the context manager you can continue to reuse 
the old stream with the old settings.

--
Added file: http://bugs.python.org/file46255/set_encoding-newline.patch

___
Python tracker 

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

[issue29220] Python 3.6 regression/change using logging.addLevelName() to clear a name

[Vinay Sajip]

Vinay Sajip added the comment:

> I think that even with empty name the output contains extra separators

Not sure what you mean - please clarify with an example.

> I would add an indentation for the second "if" ... or even use multiple 
> returns for the sake of microoptimization

I will do a further update soon.

> I don't understand the use of _nameToLevel. getLevelName('CRITICAL') returns 
> 50, that even is not a string.

Historically, getLevelName() gets the name for a level *but also the level for 
a name* (I perhaps should have done a separate API for that, like 
getLevelForName(), but it's too late now due to backward compatibility 
requirements - it's been like this for a long time.)

--

___
Python tracker 

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