[issue26993] Copy idlelib *.py files with new names

[Ned Deily]

Ned Deily added the comment:

Glad to be of help with regards to 8.4 :=)  With my 3.6 release manager hat on, 
I think the best way to think of this is as a new feature: call it "Ttk IDLE" 
or some such (and not idle2 vs idle3 which I think is confusing) and, rather 
than inventing something new, I suggest you should just follow the standard 
procedure for new feature development as documented in the Developers Guide.  
That is, create a temporary repository on hg.python.org and make all the 
changes in a new branch in that repo.  Or, if you'd rather work in private, 
just create your own local repo clone and branch within it.  When you are 
satisfied that it is ready to be integrated into the release, we can either 
merge the branch in or extract the changes as one big patch to be applied to 
the main cpython default branch.  And I'll be happy to help with making that 
happen when the time comes.  That way you and any one else wanting to work on 
IDLE can work unimpeded, you don't have to worry about temporary changes and h
 acks to accommodate two versions of IDLE in the same repo, the old version of 
IDLE continues to work in the main cpython default branch until TtkIDLE is 
ready, and the cpython repo is not cluttered with all the intermediate commits 
from the feature dev cycle (although they could be preserved during 
integration, if desired).  Plus, during feature development you should be able 
to use TtkIDLE from the feature repo with a standard 3.6 (or 3.5) binary 
install of Python.

As for timing, I would prefer to get such a major feature in by feature code 
cutoff but, as you say, IDLE is pretty self-contained so we can be flexible.  A 
similar argument would apply to 3.5.  But I think it makes sense to focus on 
3.6 first and then later separately consider dropping it all into 3.5.x, a 
decision that would be up to Larry as the 3.5 release manager.  For 3.6, I 
don't think there's a need for further discussion or to wait to begin, as long 
as the development work is done in a feature repo.  Have at it!

https://docs.python.org/devguide/committing.html#long-term-development-of-features

By the way, if you are essentially replacing the IDLE files, then (contrary to 
what I suggested earlier) you probably don't want to use hg mv to rename files. 
 Otherwise you can end up with needless merge conflicts between 3.x branches.  
In the feature branch, you can just do the equivalent of: hg rm Lib/idlelib and 
hg commit then copy any old idlelib files you want to retain back into 
Lib/idlelib, and do an hg add and hg commit.  Then the feature branch files are 
no longer "connected" to the old IDLE files from hg's perspective.  On the 
other hand, if you go the feature repo route, you won't have two copies of IDLE 
in the same branch at a time, so you don't *have* to rename files if you don't 
otherwise want to.  In any case, if the feature is integrated as one big 
commit, all of this can be handled at integration time.

--

___
Python tracker 

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

[issue26807] mock_open()().readline() fails at EOF

[Robert Collins]

Robert Collins added the comment:

Actually, further inspection and a teddybear with Angus Lees uncovers this:

diff --git a/Lib/unittest/test/testmock/testmock.py 
b/Lib/unittest/test/testmock/testmock.py
--- a/Lib/unittest/test/testmock/testmock.py
+++ b/Lib/unittest/test/testmock/testmock.py
@@ -1419,6 +1419,18 @@
 self.assertEqual('abc', first)
 self.assertEqual('abc', second)

+def test_mock_open_after_eof(self):
+# read, readline and readlines should work after end of file.
+_open = mock.mock_open(read_data='foo')
+h = _open('bar')
+h.read()
+self.assertEqual('', h.read())
+self.assertEqual('', h.read())
+self.assertEqual('', h.readline())
+self.assertEqual('', h.readline())
+self.assertEqual([], h.readlines())
+self.assertEqual([], h.readlines())
+
 def test_mock_parents(self):
 for Klass in Mock, MagicMock:
 m = Klass()



 ./python Lib/unittest/test/testmock/testmock.py
..sE
==
ERROR: test_mock_open_after_eof (__main__.MockTest)
--
Traceback (most recent call last):
  File "Lib/unittest/test/testmock/testmock.py", line 1430, in 
test_mock_open_after_eof
self.assertEqual('', h.readline())
  File "/home/robertc/work/cpython-3.5.hg/Lib/unittest/mock.py", line 917, in 
__call__
return _mock_self._mock_call(*args, **kwargs)
  File "/home/robertc/work/cpython-3.5.hg/Lib/unittest/mock.py", line 976, in 
_mock_call
result = next(effect)
StopIteration

--
Ran 80 tests in 0.197s

FAILED (errors=1, skipped=1)


That is, we need the yield '' to be infinite - while True: yield '', or the 
while True: to be outside the try:except.

--

___
Python tracker 

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

[issue26807] mock_open()().readline() fails at EOF

[Robert Collins]

Robert Collins added the comment:

./python Lib/unittest/test/testmock/testmock.py
..s.
--
Ran 80 tests in 0.180s

OK (skipped=1)


So thats great. I am going to have to stare that this quite hard to be sure I 
understand why it fails without the change away from 'for line in ' - but yes, 
this is the right place, and I'll commit it to 3.5 and 3.6 and backport it to 
the external mock tomorrow.

Thanks!

--

___
Python tracker 

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

[issue6422] timeit called from within Python should allow autoranging

[Nick Coghlan]

Nick Coghlan added the comment:

The embedded side-effects were my main concern with Scott's original patch, so 
Steven's callback-based approach strikes me as a definite improvement. However, 
the awkwardness of the revised calling code in main does make me wonder whether 
or not this might be better implemented as a generator rather than as a 
function accepting a callback:

try:
results = list(t.autorange())
except:
t.print_exc()
return 1
if verbose:
for number, time_taken in results:
msg = "{} loops -> {:.{}g} secs"
print(msg.format(number, time_taken, precision))

(Originally I had the "if verbose: print" embedded in a direct loop over 
t.autorange(), but writing it that way made it immediately clear that the scope 
of the exception handler was too broad, so I changed it to extract all the 
results and only then print them)

--

___
Python tracker 

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

[issue26993] Copy idlelib *.py files with new names

[Terry J. Reedy]

Terry J. Reedy added the comment:

Ned, thank you for the helpful response.  Yes, I *was* proposing two versions 
in 3.5 and subsequent releases until the current version could be deleted.  Its 
an ugly, least bad alternative that only made sense under the presumption that 
'idle2' had to remain in 3.6.   With that assumption dropped ...

I would be delighted to start renaming (and refactoring) existing files in 
default *now*.  Whether to renames all at once (the current #24225 proposal) or 
in batches would be a sub-issue of #24225.

I believe that the PEP 434 exemption from separating 'behavior' from 
'enhancement' issue applies during the beta period as well as after.  For IDLE, 
danger of accidental regression and thoroughness of testing are more relevant 
for deciding timing of commits.

As for 3.5, if we assume that substantial numbers of people, including 
instructors, will use the final 3.5 (likely 3.5.3) instead of 3.6.0, then it 
might be better for users to include 'idle3' in 3.5.3 as an option.  This could 
be done a couple of weeks before the release by copying 3.6 idlelib into, for 
instance, 3.5 idlelib._, editing imports, and adding a switch to the startup 
code.  If Ned's alternative is accepted, the backport decision should be 
deferred until there is something worth backporting.

--

___
Python tracker 

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

[issue27000] improve document of filter

[Xiang Zhang]

Xiang Zhang added the comment:

Not about code, just the doc. In my opinion, if ``bool`` is not called it is 
definitely not equivalent to ``(item for item in iterable if function(item))``, 
which actually calls the function, even there is nothing different in the 
result. But, this is a rather subjective and not important now. I am OK with 
all your opinions. And considering other interpreters, leaving it untouched is 
a good idea.

--

___
Python tracker 

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

[issue27000] improve document of filter

[Franklin? Lee]

Franklin? Lee added the comment:

In that case, I'm still wondering what you mean by "not equivalent". Are you 
saying there is code which will work only if the ``bool`` function is really 
called?

--

___
Python tracker 

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

[issue27000] improve document of filter

[Xiang Zhang]

Xiang Zhang added the comment:

It's OK. Thanks for all your info and do learn. BTW, Franklin, I knew what will 
happen when ``bool`` is passed.

--

___
Python tracker 

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

[issue23640] int.from_bytes() is broken for subclasses

[Eugene Toder]

Eugene Toder added the comment:

They sure do. Check the example in my comment, or if you prefer the source 
code, it's pretty clear as well: 
https://hg.python.org/cpython/file/fff0c783d3db/Modules/_datetimemodule.c#l2770

--

___
Python tracker 

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

[issue27001] Python Interface X-Plane 10.45

[Erik Rasmussen]

Erik Rasmussen added the comment:

X-plane is a simulator - and I used the attached Interface .. but since the
new version 2.7.11 it is not working .. and it DID work in version 2.7.10
...
Have tryed to downgrade Python... but not possible .. for some reason it
still registered as 2.7.11 , no matter what I do...
Any Ideas?

 -  Kindly / Mvh -
*E. Rasmussen*
Odense sø - DK

2016-05-12 2:10 GMT+02:00 R. David Murray :

>
> R. David Murray added the comment:
>
> I don't know what X-Plane is, but it isn't part of python.  You should
> talk to the maintainers of it, and if they find there's a bug in python
> causing problems, open a specific issue about whatever that bug is.  You
> could also try asking for help on the python-list mailing list.
>
> --
> nosy: +r.david.murray
> resolution:  -> third party
> stage:  -> resolved
> status: open -> closed
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

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

[issue23640] int.from_bytes() is broken for subclasses

[R. David Murray]

R. David Murray added the comment:

No, they do not return instances of the derived type, they return instances of 
the base type.  This is an intentional design decision that has been discussed 
elsewhere (including, I think, somewhere in this tracker).

--
nosy: +r.david.murray

___
Python tracker 

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

[issue27001] Python Interface X-Plane 10.45

[R. David Murray]

R. David Murray added the comment:

I don't know what X-Plane is, but it isn't part of python.  You should talk to 
the maintainers of it, and if they find there's a bug in python causing 
problems, open a specific issue about whatever that bug is.  You could also try 
asking for help on the python-list mailing list.

--
nosy: +r.david.murray
resolution:  -> third party
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

[issue27000] improve document of filter

[R. David Murray]

R. David Murray added the comment:

Thanks for wanting to improve the docs, but the docs are a specification of 
syntax and behavior, not of implementation.  So, the existing docs are correct, 
and changing them would over-specify the function.  Since Raymond has also 
voted for rejection, I'm closing this.

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

[issue26993] Copy idlelib *.py files with new names

[Ned Deily]

Ned Deily added the comment:

Terry, I'm all for having IDLE using the newer Ttk widgets and for refactoring 
to make it easier to enhance and maintain IDLE.  I'm not sure I understand the 
proposal to make two sets of IDLE files: does this mean there would be two 
versions of IDLE in one branch, e.g. Python 3.6?  That doesn't make sense to 
me.  One issue you mention is continuing to support Tk 8.4 (which lacks Ttk) on 
legacy systems.  Tk 8.4 support ended some years ago by the Tcl Core team. I 
think it is time for us to draw a line in the sand and say we no longer need to 
continue to support it for IDLE.  (It would be nice to not intentionally break 
basic non-IDLE Tkinter support for 8.4.)  I haven't yet announced any proposals 
for Mac installer support for 3.6 but I'm willing to commit to not requiring 
any Tcl/Tk 8.4 dependencies.   So, if we assume 8.4 is no longer an issue, what 
other issues remain?  I believe you've already stated that you will no longer 
attempt to keep the 2.7 version of IDLE in sync with the 
 latest IDLE 3; I thinks that's the right approach at this stage.  That means 
there will be only some backporting of selected IDLE bugfixes to 2.7 and we 
don't do any direct VCS merging between 2.7 and default anyway.  So it seems to 
me there is no reason why the default branch (e.g. what is going into 3.6) 
needs to retain any copies of IDLE files from the 2.7 branch.  In other words, 
all the file renamings (via hg mv or otherwise) and deletions just take place 
in default without disturbing 2.7.  If there are any external 
incompatibilities, it's fine to announce them as part of the 3.6 feature 
release.  This is assuming that the externally incompatible work is in place in 
time for the 3.6 feature code cutoff (3.6.0 beta 1, currently scheduled for 
2016-09-08).  As far as 3.5.n is concerned, the last bugfix release for 3.5 is 
likely to be less than a year away (assuming 3.6.0 releases by the end of 2016 
as planned).  So I would also recommend not making any refactoring changes for 
3.5,
  just important bugfixes similar to 2.7.  We should try to make it easier for 
you and the others working on IDLE.  And try to minimize the risks of 
inadvertent breakages going into maintenance releases.  Does that make sense?

--

___
Python tracker 

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

[issue27003] Python 3.5.1 fails at HTTPSTest with SSL CERT error

[SilentGhost]

Changes by SilentGhost :


--
components: +Extension Modules -Build
nosy: +alex, christian.heimes, dstufft, giampaolo.rodola, janssen, pitrou
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

[issue27003] Python 3.5.1 fails at HTTPSTest with SSL CERT error

[Bennet Fauber]

Bennet Fauber added the comment:

Just for the sake of completeness, I tested outside of the test harness.

/sw/arcts/centos7/python-dev/3.5.1/bin/python3
[bennet@flux-build-centos7-dev test]$ python3
Python 3.5.1 (default, May 11 2016, 08:50:05) 
[GCC 4.8.5 20150623 (Red Hat 4.8.5-4)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import http.client
>>> conn = http.client.HTTPSConnection("www.python.org")
>>> conn.request("GET", "/")
>>> r1 = conn.getresponse()
>>> print(r1.status, r1.reason)
200 OK

I think that indicates that it can do certificate verification of some sort and 
might be an indication that the issue is not with the setup but with the test.  
There was some discussion of making the tests independent of connectivity in 
Issue25940.

There are a couple of expired certs in the test directory, but they may not be 
used; e.g.,

nokia.pem,
Not After : Sep 20 23:59:59 2012 GMT
sha256.pem
Not After : Feb 17 23:59:59 2014 GMT

I should have included this in the first submission.  Sorry for any additional 
mail this may generate.

--

___
Python tracker 

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

[issue21099] Switch applicable importlib tests to use PEP 451 API

[Brett Cannon]

Brett Cannon added the comment:

Patch LGTM

--

___
Python tracker 

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

[issue26647] ceval: use Wordcode, 16-bit bytecode

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Oh, sorry for misleading. I was going to continue reviewing peephole.c after 
found issues would addressed. In any case the patch needs to be synchronized 
with current sources (I expected that changes for modulefinder is no longer 
needed and changes for dis will be simpler). Please also wrap long lines in 
peephole.c.

--

___
Python tracker 

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

[issue27000] improve document of filter

[Franklin? Lee]

Franklin? Lee added the comment:

> Although I still think it's telling readers incorrect info in the second 
> part. For ``bool``, it is not equivalent to ``(item for item in iterable if 
> function(item))`` but ``(item for item in iterable if item)``. For CPython, 
> you are not telling the truth.

What do you mean by, "it is not equivalent"? Are you saying that the first one 
will give a different result from the second? In general, when interpreting an 
object in a boolean context, Python will do the "equivalent" of calling 
``bool`` on it, where "equivalent" in the docs means "has the same result as". 
See, for example, the ``itertools`` docs:
https://docs.python.org/3/library/itertools.html#itertools.accumulate



In this case:

If ``filter`` is passed ``None`` or ``bool``, it will call "PyObject_IsTrue" on 
the object.

(https://github.com/python/cpython/blob/c750281ef5d8fa89d13990792163605302e972d4/Python/bltinmodule.c#L481)

"PyObject_IsTrue" is defined here:

https://github.com/python/cpython/blob/6aea3c26a22c5d7e3ffa3d725d8d75dac0e1b83b/Objects/object.c#L1223

On the other hand, ``bool`` is defined here, as "PyBool_Type":

https://github.com/python/cpython/blob/c750281ef5d8fa89d13990792163605302e972d4/Python/bltinmodule.c#L2686


"PyBool_Type" is defined here, with the ``bool.__new__`` function defined as 
"bool_new":

https://github.com/python/cpython/blob/2d264235f6e066611b412f7c2e1603866e0f7f1b/Objects/boolobject.c#L133

"bool_new" is defined here, using "PyObject_IsTrue":

https://github.com/python/cpython/blob/2d264235f6e066611b412f7c2e1603866e0f7f1b/Objects/boolobject.c#L43

Both "filter_next" and "bool_new" call "PyObject_IsTrue" and take 0 as False, 
positive as True, and negative as an error. So it's equivalent to calling 
``bool``, but the "bool_new" call is sort of inlined.

Does that clear things up?

--

___
Python tracker 

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

[issue27004] Handle script shbang options

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Yet one option:

- Add a wrapper /usr/bin/python2-s and pass it to to --executable.

$ cat /usr/bin/python2-s
#!/bin/sh
exec /usr/bin/python2 -s "$@"

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue27004] Handle script shbang options

[Orion Poplawski]

New submission from Orion Poplawski:

Fedora would like to enforce that python scripts installed into /usr/bin use 
the "-s" option.  We have tried to enforce this by doing:

python setup.py build --executable '/usr/bin/python2 -s'

However, as reported here: https://bugzilla.redhat.com/show_bug.cgi?id=1335203

this breaks scripts that already have options in them as the options are tacked 
onto the end, e.g.:

#!/usr/bin/python2 -s -E

Which linux doesn't handle.

It seems we have a couple options:

- Replace the entire shbang line with the argument to --executable
- Try to merge options into a single one (-sE)
- Have a separate option, say --executable-args to specify the options.  
Although the question still remains as to whether or not to replace the 
existing option or append.

--
components: Distutils
messages: 265343
nosy: dstufft, eric.araujo, opoplawski
priority: normal
severity: normal
status: open
title: Handle script shbang options
versions: Python 2.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

[issue26881] modulefinder should reuse the dis module

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Thank you Victor. Fixed.

> IMHO it's worth to add an optional argument to skip extended opcodes in
_unpack_opcodes() to simplify the code in modulefinder.

But this would complicate the code in dis.

If the disassembler would changed to skip extended opcodes, we would add this 
option in _unpack_opargs().

If there would be some Python 3 analogue of PEP 291, modulefinder would be 
changed to use public dis API.

--

___
Python tracker 

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

[issue26881] modulefinder should reuse the dis module

[Roundup Robot]

Roundup Robot added the comment:

New changeset d60040b3bb8c by Serhiy Storchaka in branch '3.5':
Removed duplicated NEWS entity for issue #26881.
https://hg.python.org/cpython/rev/d60040b3bb8c

--

___
Python tracker 

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

[issue26884] android: cross-compilation of extension module links to the wrong python library

[Xavier de Gaye]

Xavier de Gaye added the comment:

Another description of the problem:
* On the build system, the native python (in one of the search directories of 
PATH) has been built without --with-pydebug.
* The cross-compilation is done on this build system with --with-pydebug.
* The cross-compilation of all the Python extension modules fails with:
/bin/ld: error: cannot find -lpython3.6m
collect2: error: ld returned 1 exit status

--

___
Python tracker 

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

[issue27003] Python 3.5.1 fails at HTTPSTest with SSL CERT error

[Bennet Fauber]

New submission from Bennet Fauber:

I downloaded the source tar file for Python 3.5.1 and compiled.  Upon running 
make test, it fails at

test_networked_good_cert (test_httplib.HTTPSTest) ... ERROR

Abbreviated Traceback looks like:

==
ERROR: test_networked_good_cert (test_httplib.HTTPSTest)
--
Traceback (most recent call last):
  File "/tmp/bennet/Python-3.5.1/Lib/test/test_httplib.py", line 1325, in 
test_networked_good_cert
h.request('GET', '/')
. . . .
  File "/tmp/local/python-3.5.1/lib/python3.5/ssl.py", line 628, in do_handshake
self._sslobj.do_handshake()
ssl.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed 
(_ssl.c:645)

I have replicated this on CentOS 7, RHEL 6.5, and Ubuntu 16.04 Xenial with GCC 
versions 4.8.5, 4.8.5, and 5.3.1, respectively.

There was a previous bug reported about expired certificates that was closed.  
It appears that it's using CERT_localhost, defined at the top to be 
keycert.pem, and that appears to be valid:

[bennet@flux-build-centos7-dev test]$ openssl x509 -in keycert.pem -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 15548457918976213582 (0xd7c7381919afc24e)
. . . .
Validity
Not Before: Oct  8 23:01:56 2010 GMT
Not After : Oct  5 23:01:56 2020 GMT

I can replicate the test outside of make with the attached script.

I tried to be complete reporting and searching for this first; I apologize if I 
missed an obvious solution.

--
components: Build
files: test-python3-httplib.py
messages: 265339
nosy: Bennet Fauber
priority: normal
severity: normal
status: open
title: Python 3.5.1 fails at HTTPSTest with SSL CERT error
type: compile error
versions: Python 3.5
Added file: http://bugs.python.org/file42822/test-python3-httplib.py

___
Python tracker 

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

[issue26881] modulefinder should reuse the dis module

[Roundup Robot]

Roundup Robot added the comment:

New changeset f0a4d563b32e by Serhiy Storchaka in branch '3.5':
Issue #26881: Restored the name of scan_opcodes_25().
https://hg.python.org/cpython/rev/f0a4d563b32e

--

___
Python tracker 

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

[issue27000] improve document of filter

[Raymond Hettinger]

Raymond Hettinger added the comment:

> bool is not enough of a special case to call it out without 
> confusing the issue.

I concur.  It would be easy to make the docs less usable by elaborating on this 
special case.  For the most part, a user should use None if they just want to 
test the truth value of the input.

The docs for filter() have been through a number of revisions and much 
discussion.  Let's not undo previous efforts.  For the most part, these docs 
have been successful in communicating what filter() does.

--
nosy: +rhettinger

___
Python tracker 

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

[issue19717] resolve() fails when the path doesn't exist

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

I have written a patch that implements all three mode for posixpath.realpath() 
(issue27002). Having the implementation we can test and research it. After 
discussion this solution can be adopted for Path.resolve().

--
versions: +Python 3.6 -Python 3.4

___
Python tracker 

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

[issue27002] Support different modes in posixpath.realpath()

[Serhiy Storchaka]

New submission from Serhiy Storchaka:

For now posixpath.realpath() don't raise an exception if encounter broken link. 
Instead it just lefts broken link name and following path components 
unresolved. This is dangerous since broken link name can be collapsed with 
following ".." and resulting valid path can point at wrong location. May be 
this is even security issue.

On other hand, Path.resolve() raises an exception when encounters broken link. 
This is not always desirable, there is a wish to make it more lenient. See 
issue19717 for more information.

The readlink utility from GNU coreutils has three mode for resolving file path:

   -f, --canonicalize
  canonicalize by following every symlink in every component of the 
given name recursively; all but the last component must exist

   -e, --canonicalize-existing
  canonicalize by following every symlink in every component of the 
given name recursively, all components must exist

   -m, --canonicalize-missing
  canonicalize by following every symlink in every component of the 
given name recursively, without requirements on components existence

Current behavior of posixpath.realpath() is matches (besides one minor detail) 
to `readlink -m`. The behavior of Path.resolve() matches `readlink -e`.

Proposed preliminary patch implements the support of all three modes in 
posixpath.realpath(): CAN_MISSING, CAN_ALL_BUT_LAST and CAN_EXISTING. It 
exactly matches the behavior of readlink. The default mode is CAN_MISSING.

There is minor behavior difference in the default mode. If there is a file 
"file", a link "link" that points to "file" and a broken link "broken", then 
"broken/../link" was resolved to "link" and now it is resolved to "file".

The patch lacks the documentation. Ternary flag looks as not the best API. 
Binary flag would be better. But I don't know what can be dropped. CAN_MISSING 
is needed for compatibility, but it looks less useful and may be insecure (not 
more than normpath()). CAN_EXISTING and CAN_ALL_BUT_LAST is needed in different 
cases. I think that in many cases CAN_ALL_BUT_LAST is actually needed instead 
of CAN_MISSING.

After resolving this issue the solution will be adopted for Path.resolve().

--
components: Library (Lib)
files: realpath_mode.patch
keywords: patch
messages: 265335
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: Support different modes in posixpath.realpath()
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file42821/realpath_mode.patch

___
Python tracker 

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

[issue23640] int.from_bytes() is broken for subclasses

[Eugene Toder]

Eugene Toder added the comment:

There's a similar issue with replace() methods on date/time/datetime classes. 
They create instances of derived types without calling derived 
__new__/__init__, thus potentially leaving those uninitialized.

>>> from datetime import date
>>> class D(date):
...   def __init__(self, y, m, d):
... self.y = y
>>> D(2016,1,1).y
2016
>>> D(2016,1,1).replace(2015).y
Traceback (most recent call last):
  File "", line 1, in 
AttributeError: 'D' object has no attribute 'y'

--
nosy: +eltoder

___
Python tracker 

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

[issue27001] Python Interface X-Plane 10.45

[Erik Rasmussen]

New submission from Erik Rasmussen:

Hi Python!!  Thanks for your work on python .. really appreciated.

Program to integrate python in X-Plane 10.45+
It worked fine on Python 2.7.10 but after the new release
X-Plane Crashes completely with plugin .. ??  
Assistance please... 

Kindly
Erik (The Viking) Rasmussen
Odense, Denmark.

--
components: Windows
files: PythonInterface.rar
messages: 265333
nosy: Erik Rasmussen, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Python Interface X-Plane 10.45
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file42820/PythonInterface.rar

___
Python tracker 

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

[issue26999] Add child separator keyword to logging.basicConfig and use it in Logger.getChild()

[SilentGhost]

Changes by SilentGhost :


--
nosy: +vinay.sajip
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

[issue26881] modulefinder should reuse the dis module

[STINNER Victor]

STINNER Victor added the comment:

It looks like the change is mentionned twice in Misc/NEWS.

IMHO it's worth to add an optional argument to skip extended opcodes in
_unpack_opcodes() to simplify the code in modulefinder.

Is the scancode method public? If yes, I'm not sure that it's ok to rename
it in a minor release.

Thanks for the change, it prepares the work for wordcode.

--

___
Python tracker 

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

[issue27000] improve document of filter

[Xiang Zhang]

Xiang Zhang added the comment:

First I have to clarify that my mistake is not in understanding but in writing. 
What I mean by 'identify the return value True or False' is actually what you 
say, 'evaluate for truth or falsehood'. I also notice the lowercase false and 
true in the doc. I know they are deliberate. Sorry about this.

For ``bool``, I almost agree with you now. Although I still think it's telling 
readers incorrect info in the second part. For ``bool``, it is not equivalent 
to ``(item for item in iterable if function(item))`` but ``(item for item in 
iterable if item)``. For CPython, you are not telling the truth.

And for identity function, I insist. I don't see any advantage with this 
sentence other than confusion. I don't think this will affect other 
implementation either.

--

___
Python tracker 

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

[issue27000] improve document of filter

[Josh Rosenberg]

Josh Rosenberg added the comment:

bool is not enough of a special case to call it out without confusing the 
issue. No, the bool constructor is not actually called. But it will still 
behave as if it was called for all intents and purpose, it just skips the 
reference counting shenanigans for the actual True/False singleton objects. 
Drawing a distinction might make people worry that it wouldn't invoke __len__ 
or __bool__ as normal.

Similarly, for all intents and purposes, your mental model of the identity 
function is mostly correct (I suspect the wording meant to use "function" in 
the mathematical sense, but it works either way). Yes, it never actually calls 
a function, but that's irrelevant to observed behavior. Your only mistake is in 
assuming the function actually returns the specific values True or False; no 
filter function needs to return True or False, they simply evaluate for truth 
or falsehood (that's why filter's docs use "true" and "false" to describe it, 
not "True" and "False"). filter(str.strip, list_of_strings) is perfectly legal, 
and yields those strings that contain non-whitespace characters.

--
nosy: +josh.r

___
Python tracker 

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

[issue26039] More flexibility in zipfile write interface

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

I have added comments for tests and documentation. The implementation looks 
correct. But I prefer simpler solution on this stage. Here is something between 
zipfile-open-w5.patch and zipfile-open-w8.patch, close to zipfile-open-w5.patch 
with fixed issues.

* Writer doesn't use look and seeking.
* Writing while there are open read handlers is permitted.
* Reading while there is open write handler is forbidden.

This works in all cases when current code works. The ability to read while 
there is open write handler is separate new feature (and I don't know whether 
there is a need in it).

--
Added file: http://bugs.python.org/file42819/zipfile-open-w9.patch

___
Python tracker 

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

[issue27000] improve document of filter

[Josh Rosenberg]

Josh Rosenberg added the comment:

Franklin said it better: The only difference between documentation and behavior 
is invisible implementation details, which have no business being documented in 
any event (since they needlessly tie the hands of maintainers of CPython and 
other Python interpreters, while providing no useful benefit).

--

___
Python tracker 

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

[issue27000] improve document of filter

[Franklin? Lee]

Franklin? Lee added the comment:

Aren't these both implementation details? As in, they only affect efficiency, 
not effect, right?

--
nosy: +leewz

___
Python tracker 

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

[issue6422] timeit called from within Python should allow autoranging

[Antoine Pitrou]

Antoine Pitrou added the comment:

> I don't understand which repeat functionality you're referring to.

https://docs.python.org/3/library/timeit.html#timeit.Timer.repeat

(or, similarly, what timeit's __main__ does: report the minimum of all N runs)

--

___
Python tracker 

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

[issue27000] improve document of filter

[Xiang Zhang]

New submission from Xiang Zhang:

I think filter's doc can be improved[1]:

1. It doesn't mention ``bool``. ``bool`` is treated the same way as ``None``. 
It is not called. But this is not mentioned.
2. 'the identity function is assumed' is confusing, at least for me. It looks 
like when ``None`` is passed, *function* is set to a default func, lambda x: x. 
Then *function* is called and we identify the return value True or False. But 
this is not the truth. There is no default value and no function is applied. I 
think this should be deleted.

[1] https://docs.python.org/3/library/functions.html#filter

--
assignee: docs@python
components: Documentation
files: filter_doc.patch
keywords: patch
messages: 265325
nosy: docs@python, xiang.zhang
priority: normal
severity: normal
status: open
title: improve document of filter
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file42818/filter_doc.patch

___
Python tracker 

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

[issue6422] timeit called from within Python should allow autoranging

[Steven D'Aprano]

Steven D'Aprano added the comment:

> I would suggest making the 0.2 tunable as an optional argument.

Sounds like a good idea to me.

> I also notice the repeat functionality isn't included in the patch, is there 
> a reason?

I don't understand which repeat functionality you're referring to.

--

___
Python tracker 

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

[issue26857] gethostbyname_r() is broken on android

[Chi Hsuan Yen]

Chi Hsuan Yen added the comment:

I was thinking the (somewhat hacky) dlopen() approach so that gethostbyname_r() 
works in API 21 builds. If a universal build is not necessary this patch is OK.

--

___
Python tracker 

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

[issue6422] timeit called from within Python should allow autoranging

[Antoine Pitrou]

Antoine Pitrou added the comment:

I would suggest making the 0.2 tunable as an optional argument. Different 
applications (benchmarks) may want different duration / precision tradeoffs.
I also notice the repeat functionality isn't included in the patch, is there a 
reason?

--

___
Python tracker 

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

[issue26857] gethostbyname_r() is broken on android

[Xavier de Gaye]

Xavier de Gaye added the comment:

So what is problematic with this new patch ?  Obviously you need to build with 
API 23 to get gethostbyname_r() since it was not supported by android before, 
with the previous patch you don't get gethostbyname_r(), even when building 
with API 23.

--

___
Python tracker 

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

[issue18454] distutils crashes when uploading to PyPI having only the username (no pw) defined

[池昌言]

池昌言 added the comment:

Patch for Python 3.5, using getpass module

--
nosy: +池昌言
Added file: http://bugs.python.org/file42817/issue18454_py35_prompt.patch

___
Python tracker 

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

[issue6422] timeit called from within Python should allow autoranging

[Steven D'Aprano]

Steven D'Aprano added the comment:

This issue seems to have lost momentum, I'd like to revive it by proposing a 
slightly different interface for the autorange function.

Attached is a proof-of-concept patch. I've moved the code which determines the 
number of loops out of the main function into a new Timer method, 
``autorange``. The main difference between my approach and Scott's is that my 
autorange method doesn't do any printing directly, it takes an optional 
callback function. This lets the caller take responsibility for all output.

If this approach is acceptable, I hope to:

- (in 3.6) add tests and docs for the new method;

- (in 3.6 if time permits, otherwise 3.7) modify the timeit and repeat methods 
and functions so that they can optionally call autorange(), e.g. if the caller 
passes 0 as the number.

I'm not sure that there's a good reason to add a top-level autorange() function 
to match the timeit() and repeat() functions. Especially not once they gain the 
ability to autorange themselves.

I think my approach will be compatible with cleaning up and refactoring the 
main() function. At the moment, main() is a mess IMO, it handles argument 
processing, autoranging, units of time, and unreliable timing detection all 
from one function.

--
nosy: +steven.daprano
versions: +Python 3.6 -Python 3.5
Added file: http://bugs.python.org/file42816/timeit-autorange.patch

___
Python tracker 

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

[issue26983] float() can return not exact float instance

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Oh, sorry, how could I miss it?

--
Added file: http://bugs.python.org/file42815/float_exact2.patch

___
Python tracker 

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

[issue26998] Unable to import "site" in an embedded application

[AlexWMF]

AlexWMF added the comment:

I found the following PEP https://www.python.org/dev/peps/pep-0514/

According to this PEP, starting from python 2.7.11 the backward compatibility 
was broken, because .dll can't read from the following registry keys anymore:
HKEY_LOCAL_MACHINE\Software\Python\PythonCore\
HKEY_LOCAL_MACHINE\Software\Wow6432Node\Python\PythonCore\
HKEY_CURRENT_USER\Software\Python\PythonCore\
HKEY_CURRENT_USER\Software\Wow6432Node\Python\PythonCore\

That means, the python27.dll (x86/x86_64) tries to reads '2.7-32' and never see 
old keys like '2.7'

--

___
Python tracker 

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

[issue26983] float() can return not exact float instance

[Mark Dickinson]

Mark Dickinson added the comment:

Can you please attach the new patch?

--

___
Python tracker 

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

[issue26857] gethostbyname_r() is broken on android

[Chi Hsuan Yen]

Chi Hsuan Yen added the comment:

By the way, socketmodule_2.patch is problematic. Developers may choose to build 
CPython against API level 21 and run it on all devices with API level >= 21. In 
general Android keeps ABI compatibility between consecutive versions. That is, 
most binaries built for API 21 can be run on API 21, 22, 23 and 24. With this 
patch, developers have to build two versions of CPython, one for API < 23 and 
one for API >= 23, or gethostbyname_r() may not be used.

--

___
Python tracker 

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

[issue26998] Unable to import "site" in an embedded application

[AlexWMF]

AlexWMF added the comment:

The output of both x86 and x86_64 python interpreters is attached

--
Added file: http://bugs.python.org/file42814/Clipboard29.png

___
Python tracker 

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

[issue21099] Switch applicable importlib tests to use PEP 451 API

[Mark Lawrence]

Changes by Mark Lawrence :


--
nosy:  -BreamoreBoy

___
Python tracker 

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

[issue26998] Unable to import "site" in an embedded application

[AlexWMF]

AlexWMF added the comment:

Could you provide link to that PEP?
As I posted in the previous message, both x86 and x86_64 python27.dll have 
version string "2.7-32" (shown in sys.winver). Is this right? Any of installers 
(x86 nor x86_64) don't create "2.7-32" subkey.

I understand that python should work without set up of sys.path from the 
registry, but after start of embedded python instance, sys.path don't have any 
valid path where 'c:\Python27x64\lib' folder resides. sys.path have 
['c:\windows\system32\python27.zip', '.\Dlls', '.\Lib\'] and '.\\' expands to 
current application directory.
But directory is always different, not points to the python home.
When start the application which embeds x86_64 python, it just exits because 
can't find the 'site' module when tried to perform Py_InitializeEx(0).

--

___
Python tracker 

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

[issue26999] Add child separator keyword to logging.basicConfig and use it in Logger.getChild()

[Richard Neumann]

Changes by Richard Neumann :


--
title: Add child seperator keyword to logging.basicConfig and use it in 
Logger.getChild() -> Add child separator keyword to logging.basicConfig and use 
it in Logger.getChild()

___
Python tracker 

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

[issue26999] Add child seperator keyword to logging.basicConfig and use it in Logger.getChild()

[Richard Neumann]

New submission from Richard Neumann:

Currently Python's logging library has the Child-Separator hard-coded in 
Logger.getChild() as '.'.
It would be useful to have the ability to preset this via an optional 
basicConfig() argument like 'child_sep=' and preset it to '.' to retain the 
current behaviour.
In my case I will need to monkey-patch the getChild() method to use a different 
separator ('->') because I use '.' for different purposes within the loggers' 
names.
The current behaviour would lead to ugly and mistakable output.

--
components: Library (Lib)
messages: 265312
nosy: Richard Neumann
priority: normal
severity: normal
status: open
title: Add child seperator keyword to logging.basicConfig and use it in 
Logger.getChild()
type: enhancement
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

[issue26998] Unable to import "site" in an embedded application

[R. David Murray]

R. David Murray added the comment:

As far as I know the registry key is a supplament and not a requirement for a 
correctly functioning python.  There is an entire PEP about the registry keys 
and what to do with them...I'm not sure what the current status is on 2.7, but 
like I said, I believe that lack of registry keys should not keep python from 
working if it is installed correctly.  Python uses other methods to find its 
library.  Since you are in an embedded scenario, this probably means that 
there's something about the environment and/or disk layout that you haven't set 
up in the way that python expects it to be set up.  You migth try asking on 
python-list or the #python irc channel on freenode for help.  

I'm guessing this means there's something missing from the ebedding docs with 
respect to Windows, so I'm going to leave this open until that is confirmed or 
disproven :)

--
components: +Windows
nosy: +paul.moore, r.david.murray, steve.dower, tim.golden, zach.ware

___
Python tracker 

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

[issue26857] gethostbyname_r() is broken on android

[Chi Hsuan Yen]

Chi Hsuan Yen added the comment:

> Can people upgrade their devices or do they have to buy a new one?

AFAIK most models other than Nexus won't get updates with a bumped major 
version. (5.x => 6.x for example)

--

___
Python tracker 

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

[issue26857] gethostbyname_r() is broken on android

[Stefan Krah]

Stefan Krah added the comment:

How about supporting API >= 23 only? Can people upgrade their devices or do 
they have to buy a new one?

--
nosy: +Chi Hsuan Yen

___
Python tracker 

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

[issue26998] Unable to import "site" in an embedded application

[AlexWMF]

AlexWMF added the comment:

I've checked the x86_64 version of python27.dll.
It contains "2.7-32" as well as x86 python dll. So strange, seems like "-32" is 
always there, independently of target bitness.

--

___
Python tracker 

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

[issue26855] android: add platform.android_ver()

[Chi Hsuan Yen]

Chi Hsuan Yen added the comment:

Version 3.

Still using a try-catch clause to enclose the subprocess call, as _syscmd_ver 
does the same thing.

--
Added file: http://bugs.python.org/file42813/android_ver.patch

___
Python tracker 

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

[issue26439] ctypes.util.find_library fails when ldconfig/glibc not available (e.g., AIX)

[Michael Felt]

Michael Felt added the comment:

used diff -rNu Python-2.7.11 Python-2.7.11.4 to generate

Note: content same as those from yesterday - except 
Lib/ctype/test/test_loading.py is no longer changed. No longer needed.

--
Added file: http://bugs.python.org/file42812/Python2.issue26439.160511.patch

___
Python tracker 

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

[issue26439] ctypes.util.find_library fails when ldconfig/glibc not available (e.g., AIX)

[Michael Felt]

Michael Felt added the comment:

used diff -rNu Python-3.5.1 Python-3.5.1.1 to generate

--
Added file: http://bugs.python.org/file42811/Python3.issue26439.160511.patch

___
Python tracker 

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

[issue26439] ctypes.util.find_library fails when ldconfig/glibc not available (e.g., AIX)

[Michael Felt]

Michael Felt added the comment:

re:

AIX: CDLL("libcrypto.a(libcrypto.so.1.0.0)", DEFAULT_MODE | RTLD_MEMBER)

Officially it would be
dlopen("libcrypto.a(libcrypto.so.1.0.0)", RTLD_NOW | RTLD_MEMBER)

Further, that would only load the 32-bit version, as there is a legacy naming 
scheme for the 64-bit members (the same name may actually occur twice - once 
for each size)

Example: the ar command showing all members regardless of size:
root@x064:[/]ar -Xany tv /usr/lib/libcrypto.a
rwxr-xr-x 0/0 2967588 Jul 24 13:46 2015 libcrypto.so
rwxr-xr-x 0/0 2256131 Jul 24 13:43 2015 libcrypto.so.0.9.8
rwxr-xr-x 0/0 2967588 Jul 24 13:45 2015 libcrypto.so.1.0.0
rwxr-xr-x 0/0 3376521 Jul 24 13:46 2015 libcrypto64.so
rwxr-xr-x 0/0 2606185 Jul 24 13:44 2015 libcrypto64.so.0.9.8
rwxr-xr-x 0/0 3376521 Jul 24 13:45 2015 libcrypto64.so.1.0.0

Note: the default archives (ending in .so) are "same size, checksum, etc" as 
the .so.1.0.0 versioned members.

Also, this can be more complex - e.g., if LibreSSL is also included (I am 
re-working my packaging so that I will also have both 32 and 64-bit packaging, 
for now only 32-bit is available)

michael@x071:[/home/michael]ar -X32 tv /opt/lib/libcrypto.a
rwxr-xr-x 0/0 3060762 Jun 17 21:17 2015 libcrypto.so.33
rwxrwxr-x 0/0 2965597 Jul 25 16:57 2015 libcrypto.so
rwxrwxr-x 0/0 2253850 Jul 25 17:03 2015 libcrypto.so.0.9.8
rwxrwxr-x 0/0 2965597 Jul 25 17:03 2015 libcrypto.so.1.0.0

IMHO: this is a needless complication for a programmer using ctypes.cdll - but 
who am I?

>From the dlopen man page (aka InfoCenter)

Flags: (aka mode)
Specifies variations of the behavior of dlopen. Either RTLD_NOW or RTLD_LAZY 
must always be specified. Other flags may be OR'ed with RTLD_NOW or RTLD_LAZY.

RTLD_NOWLoad all dependents of the module being loaded and resolve all 
symbols.

RTLD_LAZY   Specifies the same behavior as RTLD_NOW. In a future release of 
the operating system, the behavior of the RTLD_LAZY may change so that loading 
of dependent modules is deferred of resolution of some symbols is deferred.

RTLD_MEMBER The dlopen subroutine can be used to load a module that is a 
member of an archive. The L_LOADMEMBER flag is used when the load subroutine is 
called. The module name FilePath names the archive and archive member according 
to the rules outlined in the load subroutine.

To be complete...

RTLD_GLOBAL Allows symbols in the module being loaded to be visible when 
resolving symbols used by other dlopen calls. These symbols will also be 
visible when the main application is opened with dlopen(NULL, mode).

RTLD_LOCAL  Prevent symbols in the module being loaded from being used when 
resolving symbols used by other dlopen calls. Symbols in the module being 
loaded can only be accessed by calling dlsym subroutine. 

If neither RTLD_GLOBAL nor RTLD_LOCAL is specified, the default is RTLD_LOCAL. 
If both flags are specified, RTLD_LOCAL is ignored.

--

___
Python tracker 

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

[issue26998] Unable to import "site" in an embedded application

[AlexWMF]

New submission from AlexWMF:

Unable to import "site" error occurs in an embedded application.
I have made small research and found why this module isn't visible for python 
core.

I have run the python 2.7.11 x86 (for all users) at my win 7x64.
The installer writes the registry key 
"Software\Wow6432Node\Python\PythonCore\%s\", where "%s" is equal to "32" on my 
machine.
Difference between x86 and x86_64 registry keys is only in "Wow6432Node" subkey 
in that key path. 
Tracing the application, I have got to getpythonregpath(...) function. This 
function reads the registry key to determine "PythonPath".
The python core tries to open the following key 
"Software\Wow6432Node\Python\PythonCore\2.7-32\PythonPath" and fails due to 
absence of that key.

In this case, the DLL was compiled with PyWin_DLLVersionString = "2.7-32".
Because of this, the python core can't open this key and the "sys.path" stays 
not fully filled with paths from registry.

The PyWin_DLLVersionString is compiles from MS_DLL_ID="$(SysWinVer)", which is 
equal to "2.7-32" on my system.
It's defined in .\PCbuild\python.props file as 
$(MajorVersionNumber).$(MinorVersionNumber)
$(SysWinVer)-32

So, the simplest solution of this bug is to fix installer to store proper key

--
components: Installation
messages: 265303
nosy: AlexWMF
priority: normal
severity: normal
status: open
title: Unable to import "site" in an embedded application
type: behavior
versions: Python 2.7

___
Python tracker 

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

[issue26439] ctypes.util.find_library fails when ldconfig/glibc not available (e.g., AIX)

[Michael Felt]

Michael Felt added the comment:

a) https://bugs.python.org/review/26439/#msg12, but getting HTML 500 error)

The call to find_library here is for "ease of use" with existing code who use, 
e.g., cdll("libcrypto.so"). This format fails unless someone has previously 
done, e.g.: (cd /usr/lib; ar -X32 x libcrypto.a; mkdir -p /usr/lib64; cd 
/usr/lib64; ar -X64 x ../lib/libcrypto.a)

What I do think would be a valid addition here is to look for a '/' in the name 
anywhere (i.e., path info in name, and skip aix.find_library(). IMHO - if a 
programmer is usiong a relative path - he/she should take full responsilibilty 
(and this is basically what find_library will return anyway)

However, If there is a syntax issue I can rework the aixutil.py so there are 
multiple entry points - e.g., find_library() finds the .a file, and 
find_member() finds an archive containing a member (and returns a suitable 
base(member) argument for dlopen() and/or add an (undocumented) argument to 
modify find_library() return value.

But I think that only creates complexity for the user/programmer - additional 
complexity is an additional for an error (of omission) to occur.

Here, as it is now, if find_library() was used to find the name, find_library() 
is not called again. Again, if there is a behavior you want to force - then it 
can be made stricter - but compatibility with existing programs (I have been 
looking at cloud-init and salt) would be weak/non-existent. And, if 
...startswith("aix") will be a very common addition to code.
Difficult to use is a reason programmers avoid a platform - and I would not 
like to see my favorite platform avoided because they had to add lots of 
"startswith("aix") - as one would always be forgotten, and then the attitude 
becomes - not going to bother with python on AIX. - my two bits.

p.s. Notice in the patches from yesterday - I have added the 'export' of 
RTLD_NOW and RTLD_MEMBER to Modules/_ctype/_ctype.c.
The "export" only occurs if the variable is defined, and the import only occurs 
in __init__.py behind 'startswith("aix")' blocks.

b) Yes, I can load and use GNU diff and resubmit (you can ignore them if you 
prefer - and I shall move the src/Python* to parallel with the build 
directories.

FYI: I tried to pip install Mercurial - but got an error message from an 
include file so the last bit did not compile. Problem for a later date - could 
be a user error on my part, or an AIX version dependency.

--

___
Python tracker 

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

[issue26996] Add secrets module as per PEP 506.

[Berker Peksag]

Berker Peksag added the comment:

If you have time, documenting this at 
https://docs.python.org/3.6/whatsnew/3.6.html#new-features would be great :)

--
nosy: +berker.peksag

___
Python tracker 

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

[issue26997] Docs for pdb should note that __future__ magic doesn't work

[Martin Jones]

New submission from Martin Jones:

when debugging a program at the pdb prompt, attempting to import from the 
__future__ module appears successful, but actually doesn't work:

(Pdb) from __future__ import division
(Pdb) 2/3
0

This leads to inconsistencies between statements evaluated on the pdb prompt 
and those evaluated in the program, which can hamper debugging. It would be 
good to have a note added to the 2.7 documentation for pdb along the lines of:

Note: importing from the __future__ module does not work under pdb.

--
assignee: docs@python
components: Documentation
messages: 265300
nosy: Martin Jones, docs@python
priority: normal
severity: normal
status: open
title: Docs for pdb should note that __future__ magic doesn't work
type: enhancement
versions: Python 2.7

___
Python tracker 

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

[issue25998] doctest terminates when accessing __wrapped__ raises an error

[Jakub Stasiak]

Changes by Jakub Stasiak :


--
nosy: +jstasiak

___
Python tracker 

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

[issue26983] float() can return not exact float instance

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Here is updated patch. Differences:

* Deprecation warning is now emitted in functions accepting floats (like 
math.sqrt).
* Improved error messages. Now reported wrong type name and a type of wrong 
__float__ method.
* float() now returns the same object for exact float argument.

Could you propose better warning message?

--

___
Python tracker 

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

[issue26983] float() can return not exact float instance

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
dependencies: +Add tests for parsing float and object arguments

___
Python tracker 

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

[issue26983] float() can return not exact float instance

[Mark Dickinson]

Mark Dickinson added the comment:

> As I understand, the conclusion of the Python-Dev discussion is that __int__, 
> __float__, __complex__, etc should return exact int, float, complex, not 
> subclasses.

Agreed; that matches my understanding. I'm only observing that it would be 
difficult (and likely undesirable) to actually enforce that `__int__` itself 
always returns an exact int: I'm not sure where that check would/could take 
place, and I'd expect that a direct user-level call to `my_object.__int__` 
probably wouldn't be subject to such a check. What we *can* do is check that 
the result of the `nb_int` call is always an int in the places we use it.

Or we could even go further, and write custom slot_nb_float and slot_nb_int 
functions in Objects/typeobject.c that incorporates those checks. What I don't 
think we can do is check that a *direct* call to `__int__` or `__float__` 
always returns something of the exact type.

--

___
Python tracker 

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

[issue26983] float() can return not exact float instance

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

The warning message is copied from __int__. As I understand, the conclusion of 
the Python-Dev discussion is that __int__, __float__, __complex__, etc should 
return exact int, float, complex, not subclasses. I have another patch that 
adds a warning for __complex__, and I am working on patches for other special 
methods. If my understanding is wrong, we should remove the deprecation warning 
for __int__.

--

___
Python tracker 

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

[issue11549] Build-out an AST optimizer, moving some functionality out of the peephole optimizer

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Regenerated for review.

--
nosy: +serhiy.storchaka
Added file: http://bugs.python.org/file42810/issue11549.patch

___
Python tracker 

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

[issue26983] float() can return not exact float instance

[Mark Dickinson]

Mark Dickinson added the comment:

+1 for the idea, and the patch LGTM.

I was initially a bit confused by the wording of the warning: presumably, we're 
not going to change Python to make returning an instance of a strict float 
subclass from __float__ illegal (I don't really see how that would be 
possible); we're just going to check the return type at the internal call sites 
to __float__ and raise if we get something other than an exact float. That is, 
I'd still expect this code to work on future versions of Python:

>>> class MyFloat(float): pass
... 
>>> class A:
... def __float__(self): return MyFloat()
... 
>>> a = A()
>>> a.__float__()
0.0

But these would both become an error in Python 3.7 (say):

>>> float(a)
0.0
>>> math.sqrt(a)
0.0

Does that match your thinking?

We should probably add issues for checking and fixing other places that 
__float__ is used internally (like the math module).

--

___
Python tracker 

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

[issue26855] android: add platform.android_ver()

[Xavier de Gaye]

Xavier de Gaye added the comment:

IMHO returning an integer for the sdk field would be better. The patch could 
use shutil.which() to avoid subprocess calls when getprop is not available. It 
would be better to use a 'try/except ValueError' clause instead of isdigit(). 
The OSError and UnicodeDecodeError exceptions should not be masked, as well as 
ValueError if sdk cannot be parsed as an int.

--

___
Python tracker 

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

[issue26993] Copy idlelib *.py files with new names

[Terry J. Reedy]

Terry J. Reedy added the comment:

In response to 1.  I considered copying idlelib as a whole as a serious 
possibility, meant to include it as an alternative, and am willing to 
reconsider my choice.  I specifically thought of something like idlelib3 or 
idlelib/idle3, but not _idlelib,  A complete copy in a new directory would be, 
as you say, a cleaner separation but it seemed like it would make import 
changes and startup more complicated.  It is also not obviously covered by PEP 
434 -- unless you say so.

For users, making idle2 the copy would immediately break current external 
imports.  Making idle3 the copy would break new external imports sometime in 
the future.  But using _idlelib would warn of that possibility.

For importat, IDLE itself uses uses all of 'from idlelib import module', 'from 
idlelib.module import callable', 'from idlelib.idle_test.htest import run', and 
unittest.main('idlelib.idle_test.test_module' (but no relative imports).  A new 
directory would greatly increase the number of changes and mean changing 
'idlelib' to 'something' now and 'something' back to 'idlelib' in the future.

I thought of using relative imports, but I have not used them and have read 
that they are limited, tricky, and discouraged.  I just did some experiments 
and it seems that they do not work when a file is run as __main__ instead of 
imported.  (Whatever the limitation, it is not obvious to me from the doc.)

I agree with 2. and 3. and will response to 4. in another message.

--

___
Python tracker 

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

[issue26857] gethostbyname_r() is broken on android

[Xavier de Gaye]

Xavier de Gaye added the comment:

gethostbyaddr_r() is implemented now on Android 6.0 (API 23). The attached 
patch has been tested on the android-21-x86 emulator (API 21) and 
android-23-x86 emulator (API 23). No new NDK has been released at Android 5.1 
(API 22) so there is no need to test the patch for this release.

--
resolution: fixed -> 
status: closed -> open
Added file: http://bugs.python.org/file42809/socketmodule_2.patch

___
Python tracker 

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