[issue25809] "Invalid" tests on locales

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Thank you Martin.

--

___
Python tracker 

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

[issue6478] time.tzset does not reset _strptime's locale time cache

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


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

___
Python tracker 

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

[issue25843] lambdas on the same line may incorrectly share code objects

[Raymond Hettinger]

Raymond Hettinger added the comment:

FWIW, the bug is present in PyPy as well.

--

___
Python tracker 

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

[issue25823] Speed-up oparg decoding on little-endian machines

[Armin Rigo]

Armin Rigo added the comment:

Fwiw, I made a trivial benchmark in C that loads aligned and misaligned shorts 
( http://paste.pound-python.org/show/HwnbCI3Pqsj8bx25Yfwp/ ).  It shows that 
the memcpy() version takes only 65% of the time taken by the two-bytes-loaded 
version on a 2010 laptop.  It takes 75% of the time on a modern server.  On a 
recent little-endian PowerPC machine, 96%.  On aarch64, only 45% faster (i.e. 
more than twice faster).  This is all with gcc.  It seems that using memcpy() 
is definitely a win nowadays.

--
nosy: +arigo

___
Python tracker 

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

[issue25823] Speed-up oparg decoding on little-endian machines

[Armin Rigo]

Armin Rigo added the comment:

(Typo: "only 45% faster" should be "only 45% of the time")

--

___
Python tracker 

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

[issue16394] Reducing tee() memory footprint

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
nosy:  -serhiy.storchaka

___
Python tracker 

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

[issue25846] Use of Py_ARRAY_LENGTH on pointer in posixmodule.c, win32_wchdir

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
nosy: +haypo
type:  -> behavior

___
Python tracker 

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

[issue25843] lambdas on the same line may incorrectly share code objects

[Ezio Melotti]

Changes by Ezio Melotti :


--
nosy: +ezio.melotti

___
Python tracker 

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

[issue25823] Speed-up oparg decoding on little-endian machines

[Antoine Pitrou]

Antoine Pitrou added the comment:

Or just bite the bullet and make all opcodes 16-bit (and make sure the bytecode 
string is aligned ;-)).

Still, someone ought to run the benchmarks suite on this. Tuple-unpacking 
nano-benchmarks are not very enlightening ;-)

--
nosy: +pitrou

___
Python tracker 

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

[issue25277] test_sigwaitinfo() of test_eintr hangs on randomly on FreeBSD buildbots

[Martin Panter]

Martin Panter added the comment:

Did you consider blocking the signal before spawning the child? I haven’t used 
signals much, so I could be wrong, but it seems sigwaitinfo() is meant to be 
called with the signal blocked. Something like this:

pthread_sigmask(SIG_BLOCK, {signum})
try:
t0 = ...
...  # Spawn child, call sigwaitinfo(), etc
finally:
pthread_sigmask(SIG_UNBLOCK, {signum})
self.assertGreaterEqual(dt, ...)

--
nosy: +martin.panter

___
Python tracker 

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

[issue25809] "Invalid" tests on locales

[Martin Panter]

Martin Panter added the comment:

The koobs-freebsd11 buildbots are starting to look greener now

--
resolution:  -> fixed
stage: commit 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

[issue25234] test_eintr.test_os_open hangs under Xcode 7

[Martin Panter]

Martin Panter added the comment:

The Yosemite ICC 3.5 buildbot seems to be intermittently hanging test_os_open() 
and test_open(). Currently it shows five builds. Build 396 hung at 
test_os_open(); build 400 hung at test_open(), and the other three passed.

http://buildbot.python.org/all/builders/x86-64%20Yosemite%20ICC%20Debug%203.5

Slave information
Buildbot-Slave 0.8.12
OSX 10.10.3 (Yosemite) Mac Mini VMWare VM 2x2.86 GHz 8GB

--
nosy: +martin.panter
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

[issue17781] optimize compilation options

[Alecsandru Patrascu]

Alecsandru Patrascu added the comment:

Hi, I added a dedicated issue just for LTO only when using GCC and CLANG 
(http://bugs.python.org/issue25702), that works well with PGO also.

--
nosy: +alecsandru.patrascu

___
Python tracker 

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

[issue25827] Support ICC in configure

[Alecsandru Patrascu]

Alecsandru Patrascu added the comment:

Thank you David for including me in this issue. 

On ICC, when executing the instrumented applications, it will generate dynamic 
information file that has a unique name and .dyn suffix. From my previous 
experience with GCC and CLANG PGO patch (issue24915), also the output of the 
autoconf will have to be included in the final diff.

Regarding the place for adding the '-fp-model strict' flags, I had the same 
dillema when working on the LTO patch (issue25702), because I needed the flags 
to be propagated to _all_ compilation and linking phases, and finally decided 
to add them to the CONFIGURE_CFLAGS, CONFIGURE_CFLAGS_NODIST, 
CONFIGURE_CPPFLAGS, CONFIGURE_LDFLAGS variables in the Makefile.pre.in file. 
You can try there also and keep the BASECFLAGS clean .

--

___
Python tracker 

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

[issue25823] Speed-up oparg decoding on little-endian machines

[Mark Dickinson]

Mark Dickinson added the comment:

Raymond: I only used the word "dramatic" in the context of deliberately 
introducing new *undefined behaviour* into the core of CPython, which seems 
like something that should be avoided without a really good reason.

I have no objections to Serhiy's patch, which doesn't introduce undefined 
behaviour.

--

___
Python tracker 

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

[issue25798] Update python.org installers to use OpenSSL 1.0.2e

[Terry J. Reedy]

Terry J. Reedy added the comment:

Close this?

--
nosy: +terry.reedy

___
Python tracker 

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

[issue25843] lambdas on the same line may incorrectly share code objects

[Ismail Donmez]

Changes by Ismail Donmez :


--
nosy: +donmez

___
Python tracker 

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

[issue25843] lambdas on the same line may incorrectly share code objects

[Nick Coghlan]

Nick Coghlan added the comment:

>From what I can see:

* checking constant types in addition to their values should be a two line 
change (plus tests)
* checking the column number in addition to the line number would be a more 
comprehensive fix, but also a constructor API change (since PyCode_New doesn't 
currently accept a column parameter)

The "values of the same constant type that are distinct but equivalent may 
still compare equal" case is obscure enough that I think the lower impact 
change is likely a better option, especially as 3.x currently "handles" the 
"lambda: -0.0" case by having both the unfolded 0.0 and the folded -0.0 in the 
constant list.


Additional detail for those interested:

The lowest impact fix from a code change would be to add a type equivalence 
check for constants as Raymond first suggested, as that only involves adding an 
extra check to code_richcompare: 
https://hg.python.org/cpython/file/tip/Objects/codeobject.c#l416

However, the idea of tracking "co_firstcolno" in addition to "co_firstlineno" 
is a more robust fix, as it means any lexically distinct code objects will 
necessarily be considered distinct by the interpreter. The downside is that it 
means touching more code and adding a new public API, since PyCode_New doesn't 
currently accept a "firstcolno" parameter - code objects are implicitly assumed 
to be one-per-line.

Out of curiosity, I also went looking for the code in the code generator that 
collapses the "equivalent" code objects together. The issue is that constants 
are stored in a dict (mapping them to their co_consts index) during compilation 
and assembly, so equivalent objects will be merged together (and refer to the 
index of the first one defined).

--
nosy: +ncoghlan

___
Python tracker 

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

[issue25847] CPython not using Visual Studio code analysis!

[R. David Murray]

R. David Murray added the comment:

Is analyze something that can be used from the command line only, or does it 
require the GUI?  Also, we aren't likely to make the code more complex in order 
to deal with shortcomings in analyze's algorithms (meaning in that case we 
couldn't turn it on automatically).  For valgrind, for example, we have an 
exceptions list, and similarly for covarity.  Does analyze support something 
similar?

I'm surprised it is catching things that coverity doesn't.

--
nosy: +christian.heimes, r.david.murray

___
Python tracker 

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

[issue9949] os.path.realpath on Windows does not follow symbolic links

[SilentGhost]

Changes by SilentGhost :


--
components: +Windows
keywords: +needs review -patch
nosy: +paul.moore, steve.dower
versions: +Python 3.6 -Python 3.5

___
Python tracker 

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

[issue25809] "Invalid" tests on locales

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

I would commit the patch on 3.4 too. Patches that just fixes tests or 
documentation can be applied even at this stage.

--

___
Python tracker 

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

[issue25848] Tkinter tests failed on Windows buildbots

[Serhiy Storchaka]

New submission from Serhiy Storchaka:

Tkinter related tests are failed on 4 of 6 Windows 3.4 buildbots.

http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.4/builds/1418/steps/test/logs/stdio
http://buildbot.python.org/all/builders/AMD64%20Windows10%203.4/builds/220/steps/test/logs/stdio
http://buildbot.python.org/all/builders/AMD64%20Windows8%203.4/builds/779/steps/test/logs/stdio
http://buildbot.python.org/all/builders/AMD64%20Windows8.1%20Non-Debug%203.4/builds/333/steps/test/logs/stdio

==
ERROR: setUpModule (test.test_tcl)
--
Traceback (most recent call last):
  File "C:\buildbot.python.org\3.4.kloth-win64\build\lib\test\test_tcl.py", 
line 685, in setUpModule
tcl = Tcl()
  File "C:\buildbot.python.org\3.4.kloth-win64\build\lib\tkinter\__init__.py", 
line 1955, in Tcl
return Tk(screenName, baseName, className, useTk)
  File "C:\buildbot.python.org\3.4.kloth-win64\build\lib\tkinter\__init__.py", 
line 1856, in __init__
self.tk = _tkinter.create(screenName, baseName, className, interactive, 
wantobjects, useTk, sync, use)
_tkinter.TclError: Can't find a usable init.tcl in the following directories: 
C:/buildbot.python.org/3.4.kloth-win64/build/PCbuild/lib/tcl8.6 
C:/buildbot.python.org/3.4.kloth-win64/build/PCbuild/lib/tcl8.6 
C:/buildbot.python.org/3.4.kloth-win64/build/lib/tcl8.6 
C:/buildbot.python.org/3.4.kloth-win64/build/PCbuild/library 
C:/buildbot.python.org/3.4.kloth-win64/build/library 
C:/buildbot.python.org/3.4.kloth-win64/build/tcl8.6.1/library 
C:/buildbot.python.org/3.4.kloth-win64/tcl8.6.1/library



This probably means that Tcl wasn't installed properly.


--

Is this a test suite defect, or there is an issue with using Tkinter on 
Windows? In latter case this is a release blocker.

--
components: Tests, Tkinter, Windows
messages: 256287
nosy: larry, paul.moore, serhiy.storchaka, steve.dower, tim.golden, zach.ware
priority: release blocker
severity: normal
status: open
title: Tkinter tests failed on Windows buildbots
type: behavior
versions: Python 3.4

___
Python tracker 

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

[issue7283] test_site failure when .local/lib/pythonX.Y/site-packages hasn't been created yet

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

This problem still occurs.

http://buildbot.python.org/all/builders/x86-64%20Ubuntu%2014.04%20ICC%20Debug%203.5/builds/275/steps/test/logs/stdio

==
FAIL: test_s_option (test.test_site.HelperFunctionsTests)
--
Traceback (most recent call last):
  File "/buildarea/3.5.intel-ubuntu-icc/build/Lib/test/test_site.py", line 169, 
in test_s_option
self.assertIn(usersite, sys.path)
AssertionError: '/var/lib/buildbot/.local/lib/python3.5/site-packages' not 
found in ['', '/usr/local/lib/python35.zip', 
'/buildarea/3.5.intel-ubuntu-icc/build/Lib', 
'/buildarea/3.5.intel-ubuntu-icc/build/Lib/plat-linux', 
'/buildarea/3.5.intel-ubuntu-icc/build/build/lib.linux-x86_64-3.5-pydebug']

--

On 3.5 the test is failed randomly, on 3.4 it is failed all time.

I can't reproduce this locally. If remove ~/.local/lib/pythonX.Y and run 
test_site, it creates the directory and modifies sys.path (this is a bug).

$ rm -rf ~/.local/lib/python3.4
$ ./python -m test.regrtest -uall -vv test_site
...
Ran 21 tests in 0.277s

OK (skipped=2)
Warning -- sys.path was modified by test_site
  Before: (3071378764, ['', '/usr/local/lib/python34.zip', 
'/home/serhiy/py/cpython3.4/Lib', '/home/serhiy/py/cpython3.4/Lib/plat-linux', 
'/home/serhiy/py/cpython3.4/build/lib.linux-i686-3.4'], ['', 
'/usr/local/lib/python34.zip', '/home/serhiy/py/cpython3.4/Lib', 
'/home/serhiy/py/cpython3.4/Lib/plat-linux', 
'/home/serhiy/py/cpython3.4/build/lib.linux-i686-3.4'])
  After:  (3071378764, ['', '/usr/local/lib/python34.zip', 
'/home/serhiy/py/cpython3.4/Lib', '/home/serhiy/py/cpython3.4/Lib/plat-linux', 
'/home/serhiy/py/cpython3.4/build/lib.linux-i686-3.4'], ['', 
'/usr/local/lib/python34.zip', '/home/serhiy/py/cpython3.4/Lib', 
'/home/serhiy/py/cpython3.4/Lib/plat-linux', 
'/home/serhiy/py/cpython3.4/build/lib.linux-i686-3.4', 
'/home/serhiy/.local/lib/python3.4/site-packages']) 
1 test altered the execution environment:
test_site

--
nosy: +serhiy.storchaka
resolution: out of date -> 
stage: resolved -> 
status: closed -> open
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

[issue25843] lambdas on the same line may incorrectly share code objects

[Raymond Hettinger]

Raymond Hettinger added the comment:

Interestingly, co_filename is not used as part of the equivalence criteria, so 
code object equivalence can be fooled across multiple input files.  Fortunately 
in this case, the false equivalence isn't relied on by the code generator.

  $ cat a.py
  def f():
  return 1

  $ cat b.py
  def f():
  return 1.0

  $ ./python.exe -q
  >>> import a, b
  >>> a.f.__code__ == b.f.__code__  # False equivalence
  True
  >>> a.f()
  1
  >>> b.f() # Generated code is correct
  1.0

Besides aliasing int/float/decimal/fraction/complex/bool, codeobj.__eq__() can 
also alias str/unicode on Python 2.7.  Likewise, 0.0 and -0.0 can be conflated. 
 NaNs don't seem to be a problem.

I think we should focus on fixing the spec for code object equivalents.  
Perhaps the test can be simplified to use (co_firstlineno, co_firstrowno, 
co_filename).

--
nosy: +arigo, fijall

___
Python tracker 

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

[issue25849] files, opened in unicode (text): write() returns symbols count, but seek() expect offset in bytes

[Марк Коренберг]

New submission from Марк Коренберг:

It seems, that we should deprecate .seek() on files, opened in text mode.

Since it is not possible to seek to position between symbols. Yes, it is 
possible to decode UTF-8 (or other charset) starting from beginning of the file 
and count symbols, but it is EXTREMELY SLOW, and is not what user expect. If 
so, seeking from end of file back to begin may be implemented in even more hard 
and error-prone way.

Moreover, I consider that we should disallow seek in text files except seek() 
to begin of the file (position 0) or end of file (seek(0, SEEK_END)).

Seel also issue25190 #25190 about something related for that.

--
components: IO, Library (Lib), Unicode
messages: 256291
nosy: ezio.melotti, haypo, mmarkk
priority: normal
severity: normal
status: open
title: files, opened in unicode (text): write() returns symbols count, but 
seek() expect offset in bytes
versions: Python 3.3, Python 3.4, 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

[issue25190] Define StringIO seek offset as code point offset

[Марк Коренберг]

Марк Коренберг added the comment:

#25849 ?

--
nosy: +mmarkk

___
Python tracker 

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

[issue25849] files, opened in unicode (text): write() returns symbols count, but seek() expect offset in bytes

[R. David Murray]

R. David Murray added the comment:

As mentioned in those issues, currently the peek/seek token is a black box.  
That doesn't mean it isn't useful.  Those issues are talking about potential 
ways to make it more useful, so any discussion should occur there.

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

[issue25798] Update python.org installers to use OpenSSL 1.0.2e

[Steve Dower]

Steve Dower added the comment:

It hasn't been fixed for Windows yet.

--

___
Python tracker 

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

[issue25848] Tkinter tests failed on Windows buildbots

[Steve Dower]

Steve Dower added the comment:

I was encountering this recently trying to set up a build machine for the 
release, and it seems to be a build issue.

Martin is building the release and apparently has it working.

--
nosy: +loewis

___
Python tracker 

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

[issue25850] Building extensions with MSVC 2015 Express fails

[Sami Salonen]

New submission from Sami Salonen:

MSVC 2015 Express doesn't include the 64-bit compiler [1], and this causes 
distutils to fail to load proper compiler settings when using a 64-bit machine 
to compile extensions for 64-bit python. _msvccompiler.py tries to call 
"vcvarsall.bat amd64", but the VC\bin\amd64 directory contains only one file 
"vcmeta.dll".

[1] https://msdn.microsoft.com/en-us/library/hs24szh9(v=vs.140).aspx

--
components: Distutils, Extension Modules, Windows
messages: 256296
nosy: Sami Salonen, dstufft, eric.araujo, paul.moore, steve.dower, tim.golden, 
zach.ware
priority: normal
severity: normal
status: open
title: Building extensions with MSVC 2015 Express fails
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

[issue25809] "Invalid" tests on locales

[Martin Panter]

Martin Panter added the comment:

Okay I am happy to do that, but I am unsure of the procedure. Do I just commit 
to 3.4, merge forward, and push? Would this be picked up in the final 3.4.4 
release, or only in a potential 3.4.5 release? Would I have to check with Larry 
first?

--

___
Python tracker 

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

[issue25851] installing 3.5 on windows server 2003 x86 R2 Standard Edition Sp2 ENU,

[Laura Creighton]

New submission from Laura Creighton:

Another one in to webmaster.

Somebody tried to install 3.5 on his windows server 2003 x86 R2 Standard 
Edition Sp2 ENU, and was told that Vista or later is required.

Is this correct behaviour, or did we forget about such people?  Near as
I can tell some of them can still be on their very last gasp of 
being supported by Microsoft.

--
messages: 256298
nosy: lac
priority: normal
severity: normal
status: open
title: installing 3.5 on windows server 2003 x86 R2 Standard Edition Sp2 ENU,

___
Python tracker 

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

[issue25851] installing 3.5 on windows server 2003 x86 R2 Standard Edition Sp2 ENU,

[Laura Creighton]

Changes by Laura Creighton :


--
components: +Installation, Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware
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

[issue25852] smtplib's SMTP.connect() should store the server name in ._host for .starttls()

[W. Trevor King]

New submission from W. Trevor King:

With the current tip, starttls uses ._host when calling wrap_socket [1], but 
._host is only setup in SMTP.__init__ [2].  Before #22921 [3] starttls would 
ignore ._host when SNI wasn't available locally.  But as far as I can tell, 
starttls has never used _host when connection happens via an explicit connect() 
call.  This leads to errors like [4]:

  >>> smtp = smtplib.SMTP()
  >>> smtp.connect(host="smtp.gmail.com", port=587)
  >>> smtp.ehlo()
  >>> smtp.starttls()
  File "smtp_test.py", line 10, in 
smtp.starttls()
  File "/usr/lib/python3.4/smtplib.py", line 676, in starttls
server_hostname=server_hostname)
  File "/usr/lib/python3.4/ssl.py", line 344, in wrap_socket
_context=self)
  File "/usr/lib/python3.4/ssl.py", line 540, in __init__
self.do_handshake()
  File "/usr/lib/python3.4/ssl.py", line 767, in do_handshake
self._sslobj.do_handshake()
  ssl.SSLError: [SSL: TLSV1_ALERT_DECODE_ERROR] tlsv1 alert decode error 
(_ssl.c:598)

I think a better approach would be to move the ._host set into .connect (patch 
attached).  It would still happen in SMTP(host=…) because [5], but would also 
allow starttls when users use SMTP() and then call connect(host=…) explicitly.

I've formatted the patch with Git, but its simple enough that it should be easy 
to apply in Mercurial.  Still, let me know if I can make applying it easier by 
rerolling the patch.

[1]: https://hg.python.org/cpython/file/323c10701e5d/Lib/smtplib.py#l766
[2]: https://hg.python.org/cpython/file/323c10701e5d/Lib/smtplib.py#l244
[3]: http://bugs.python.org/issue22921
[4]: 
http://stackoverflow.com/questions/23616803/smtplib-smtp-starttls-fails-with-tlsv1-alert-decode-error
[5]: https://hg.python.org/cpython/file/323c10701e5d/Lib/smtplib.py#l251

--
components: Library (Lib)
files: 0001-smtplib-Set-SMTP._host-in-.connect.patch
keywords: patch
messages: 256299
nosy: labrat
priority: normal
severity: normal
status: open
title: smtplib's SMTP.connect() should store the server name in ._host for 
.starttls()
type: behavior
versions: Python 3.3, Python 3.4, Python 3.5
Added file: 
http://bugs.python.org/file41291/0001-smtplib-Set-SMTP._host-in-.connect.patch

___
Python tracker 

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

[issue25851] installing 3.5 on windows server 2003 x86 R2 Standard Edition Sp2 ENU,

[Eryk Sun]

Eryk Sun added the comment:

It's the correct behavior. 3.5 supports all versions of Windows that had 
mainstream or extended support as of its release on 2015-09-13. Windows Server 
2003 R2 extended support ended on 2015-07-14 [1].

[1]: 
https://support.microsoft.com/en-us/lifecycle/search?sort=PN&alpha=Windows%20Server%202003%20R2

--
nosy: +eryksun
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

[issue25853] Compile error with pytime.h - struct timespec declared inside parameter list

[jamespharvey20]

New submission from jamespharvey20:

When including pytime.h:

n file included from /usr/include/python3.5m/Python.h:65:0,
 from src/package.c:25:
/usr/include/python3.5m/pytime.h:136:56: error: ‘struct timespec’ declared 
inside parameter list [-Werror]
 PyAPI_FUNC(int) _PyTime_AsTimespec(_PyTime_t t, struct timespec *ts);
^
/usr/include/python3.5m/pytime.h:136:56: error: its scope is only this 
definition or declaration, which is probably not what you want [-Werror]
cc1: all warnings being treated as errors
error: command 'gcc' failed with exit status 1

--
components: Library (Lib)
messages: 256301
nosy: jamespharvey20
priority: normal
severity: normal
status: open
title: Compile error with pytime.h - struct timespec declared inside parameter 
list
type: compile error
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

[issue25190] Define StringIO seek offset as code point offset

[Martin Panter]

Martin Panter added the comment:

Mark: This issue is about StringIO only. I am not proposing any change to 
TextIOBase or how on-disk text files are handled.

I intend to propose a patch to make StringIO more liberal, but haven’t got 
around to it yet. Do you think it would be worthwhile? IMO it would make 
StringIO a fairly efficient mutable text buffer. The alternatives [list(str), 
array("u")] are slower and/or use more than 4 bytes per character.

--

___
Python tracker 

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

[issue25853] Compile error with pytime.h - struct timespec declared inside parameter list

[jamespharvey20]

jamespharvey20 added the comment:

This is using https://www.python.org/ftp/python/3.5.1/Python-3.5.1.tar.xz

GCC v5.3.0

Using Werror obviously

--

___
Python tracker 

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

[issue25843] lambdas on the same line may incorrectly share code objects

[Torsten Landschoff]

Changes by Torsten Landschoff :


--
nosy: +torsten

___
Python tracker 

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

[issue25852] smtplib's SMTP.connect() should store the server name in ._host for .starttls()

[R. David Murray]

Changes by R. David Murray :


--
components: +email
nosy: +barry, r.david.murray
stage:  -> patch review

___
Python tracker 

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

[issue24203] Deprecate threading.Thread.isDaemon etc

[Berker Peksag]

Berker Peksag added the comment:

+1 for deprecating them. Removing them would make porting code from Python 2 
harder so I think it's better to keep them for a while.

--
components: +Library (Lib)
keywords: +patch
nosy: +berker.peksag
stage:  -> patch review
title: Depreciate threading.Thread.isDaemon etc -> Deprecate 
threading.Thread.isDaemon etc
type:  -> enhancement
versions: +Python 3.6
Added file: http://bugs.python.org/file41292/issue24203.diff

___
Python tracker 

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

[issue25852] smtplib's SMTP.connect() should store the server name in ._host for .starttls()

[SilentGhost]

SilentGhost added the comment:

Here is a usable patch, there doesn't seem to be a test for starttls, but it's 
still would be a good idea to add a test for this issue.

--
nosy: +SilentGhost
versions: +Python 3.6 -Python 3.3
Added file: http://bugs.python.org/file41293/issue25852.diff

___
Python tracker 

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

[issue25851] installing 3.5 on windows server 2003 x86 R2 Standard Edition Sp2 ENU,

[Mark Lawrence]

Mark Lawrence added the comment:

See also https://www.python.org/dev/peps/pep-0011/#microsoft-windows.

--
nosy: +BreamoreBoy

___
Python tracker 

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

[issue25854] rest in _interpolate_some is a list not str

[Andrei Tumbar]

New submission from Andrei Tumbar:

Create a list called _rest from rest
then will del rest
instead of while rest:
for rest in _rest

--
components: Interpreter Core
files: configparser.py
messages: 256307
nosy: Andrei Tumbar
priority: normal
severity: normal
status: open
title: rest in _interpolate_some is a list not str
type: compile error
versions: Python 3.4
Added file: http://bugs.python.org/file41294/configparser.py

___
Python tracker 

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

[issue21436] Consider leaving importlib.abc.Loader.load_module()

[Berker Peksag]

Changes by Berker Peksag :


--
status: open -> closed

___
Python tracker 

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

[issue25854] rest in _interpolate_some is a list not str

[SilentGhost]

SilentGhost added the comment:

I'm not sure what problem exactly you're trying to report / solve here. I'd 
suggest you add an explanation of an issue you're experiencing. In any case 
your current change seem to be breaking too many things.

--
components: +Library (Lib) -Interpreter Core
nosy: +SilentGhost
type: compile error -> behavior

___
Python tracker 

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

[issue25850] Building extensions with MSVC 2015 Express fails

[Zachary Ware]

Zachary Ware added the comment:

I'm inclined to close this as 'not a bug'.  There's not much we can do about 
that (if you want 64 bit extensions, you need a 64 bit compiler), and 2015 
Community Edition does include the 64 bit compiler (if you select it).

I'm not sure if there's anything to be done in distutils to handle things more 
gracefully.

--

___
Python tracker 

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

[issue25847] CPython not using Visual Studio code analysis!

[Raymond Hettinger]

Changes by Raymond Hettinger :


--
nosy: +loewis

___
Python tracker 

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

[issue24203] Deprecate threading.Thread.isDaemon etc

[Raymond Hettinger]

Raymond Hettinger added the comment:

> Removing them would make porting code from Python 2 harder
> so I think it's better to keep them for a while.

So, no deprecations.  The API is now a bit redundant but it isn't broken or 
problematic in any way.  We don't have to deprecate this for any reason other 
than to satisfy a personal sense of neatness and compactness.

This API has long history.  See  
https://docs.python.org/release/1.5.2/lib/thread-objects.html.   The older the 
API, the more likely that there is a lot of existing code that relies on the 
API (including public and private projects that no longer have an active 
maintainer or adequate tests).

For the sake of developers who rely on the standard library being "standard" 
and for the mountains of existing code on PyPI, we need to have a strong 
aversion to unnecessary deprecations.  The deprecations cause headaches for 
users, they present obstacles to upgrading Python, and they increase the 
likelihood that package distributors will monkey-patch or duplicate the code to 
restore prior behavior (for example, the Hypothesis project will likely have to 
duplicate the code that was recently taken out of the inspect module in favor 
of signature objects).

Put me down for a -1 on a unnecessary deprecation.  We should put more focus on 
proposed new APIs and making sure that they are something we want to live with 
for a very long time.  The saying is that the standard library is where code 
goes to die and it should preferably be dead-on-arrival (one reason that 
Requests is not be added to the standard library is that the code is still 
living and evolving).

--
nosy: +rhettinger

___
Python tracker 

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

[issue25854] rest in _interpolate_some is a list not str

[Raymond Hettinger]

Changes by Raymond Hettinger :


--
assignee:  -> rhettinger
nosy: +rhettinger

___
Python tracker 

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

[issue25854] rest in _interpolate_some is a list not str

[Raymond Hettinger]

Raymond Hettinger added the comment:

The proposed patch (switching from a while-loop to a for-loop) doesn't make 
sense with respect to the manipulations that are done in the body of the loop.  
It breaks Lib/test/test_configparser.py.

Closing this one because there doesn't appear to be any useful content.

--
keywords: +patch
resolution:  -> rejected
status: open -> closed
Added file: http://bugs.python.org/file41295/proposed.diff

___
Python tracker 

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

[issue7283] test_site failure when .local/lib/pythonX.Y/site-packages hasn't been created yet

[Martin Panter]

Martin Panter added the comment:

I can’t imagine why the buildbot is failing either.

The directory is created and added to sys.path when test_site is imported:

if site.ENABLE_USER_SITE and not os.path.isdir(site.USER_SITE):
# need to add user site directory for tests
os.makedirs(site.USER_SITE)
site.addsitedir(site.USER_SITE)

Maybe it should be changed to skip test_s_option() if the directory is missing; 
I dunno. Another option might be to create it just for the test, and then 
remove it, but that risks interfering with concurrent tests.

--
nosy: +martin.panter

___
Python tracker 

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

[issue25850] Building extensions with MSVC 2015 Express fails

[Steve Dower]

Steve Dower added the comment:

There is: we can fall back on the cross compilers if the native ones are not 
there.

Not a huge change, and safe enough.

--

___
Python tracker 

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

[issue25855] str.title()

[Jon Sobocinski]

New submission from Jon Sobocinski:

Perhaps not a bug, but an odd behavior of pythons built in .title() method. 
When calling this method on a string such as this: "bill's", python will change 
the string to "Bill'S". This seems like a behavior that may want to be changed.

--
components: Library (Lib)
messages: 256314
nosy: Jon Sobocinski
priority: normal
severity: normal
status: open
title: str.title()
type: behavior
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

[issue25234] test_eintr.test_os_open hangs under Xcode 7

[Brett Cannon]

Brett Cannon added the comment:

I'm still getting the occasional hang for this so I'm going to skip the test 
under OS X.

--
assignee:  -> brett.cannon

___
Python tracker 

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

[issue25844] Pylauncher, launcher.c: Assigning NULL to a pointer instead of testing against NULL

[Brett Cannon]

Changes by Brett Cannon :


--
stage:  -> test needed
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

[issue25847] CPython not using Visual Studio code analysis!

[Brett Cannon]

Changes by Brett Cannon :


--
components: +Windows -Build

___
Python tracker 

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

[issue25855] str.title()

[Ezio Melotti]

Ezio Melotti added the comment:

This is by design: https://docs.python.org/3/library/stdtypes.html#str.title

--
nosy: +ezio.melotti
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

[issue25843] lambdas on the same line may incorrectly share code objects

[Armin Rigo]

Armin Rigo added the comment:

Other possible minimal fixes:

* compile.c:compiler_addop(): special-case code objects too, and stick their 
identity in the tuple 't'.

* or, in compile.c:makecode(), append the first row number to co_consts.

--

___
Python tracker 

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