[issue25772] Misleading descriptions about built-in type `super.`

[Juchen Zeng]

New submission from Juchen Zeng:

A few days ago, I was learning built-in type `super` through [python official 
doc](https://docs.python.org/2/library/functions.html#super).  
And I was mislead by its documentation, in the part of how `__mro__` resolution 
works. Below is the part which confuse me:

"""
super(type[, object-or-type])

# ISSUE IRRELEVANT DOC OMITTED

The __mro__ attribute of the type lists the method resolution search order used 
by both getattr() and super(). The attribute is dynamic and can change whenever 
the inheritance hierarchy is updated.
"""

>From the description of the doc we can see that `super()` takes two arguments, 
>the first is `type` and the second is an optional `object-or-type`. So, when I 
>saw the doc statement: `The __mro__ attribute of the type lists the method 
>resolution search order used by both getattr() and super(). `, I naturally 
>thought here the `type` refers to the compulsory first `type` argument. But 
>after doing a series of [experiments][EXP_REF]. It turns out in `super()` was 
>using the second `type`'s `__mro__` attribute! And if the second argument is 
>an object, it will use `object.__class__.__mro__` as its resolution order. 
>Unless a learner experimented it throughly like me, he will have lots of 
>difficulty to figured out that `type` mentioned in the doc refers to the 
>second optional argument. I think here the doc should be clearly specified 
>that the second argument's `__mro__` is what super relies on. I suggest to add 
>distinctions on arguments name or add more clarification informations in the 
>doc he
 re.

By the way, the python3 document has the same issue.  
If you decided to fix this, maybe you want to fix its python3 version, too.

 

[EXP_REF]: 
http://stackoverflow.com/questions/33890918/how-does-super-interacts-with-a-classs-mro-attribute-in-multiple-inheri/33891281#33891281

--
assignee: docs@python
components: Documentation
messages: 255643
nosy: Juchen Zeng, docs@python, eric.araujo, ezio.melotti, georg.brandl
priority: normal
severity: normal
status: open
title: Misleading descriptions about built-in type `super.`
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

[issue25770] expose name, args, and kwargs from methodcaller

[Stéphane Wirtel]

Stéphane Wirtel added the comment:

Hi,

I just tried your patch with the last revision and I have an error with the 
tests.

stephane@sg1 ~/s/h/cpython> ./python -m test test_operator
[1/1] test_operator
Fatal Python error: ./Modules/_operator.c:975 object at 0x7ff804c2e3d8 has 
negative ref count -1

Current thread 0x7ff806ee8700 (most recent call first):
  File "/home/stephane/src/hg.python.org/cpython/Lib/unittest/case.py", line 
600 in run
  File "/home/stephane/src/hg.python.org/cpython/Lib/unittest/case.py", line 
648 in __call__
  File "/home/stephane/src/hg.python.org/cpython/Lib/unittest/suite.py", line 
122 in run
  File "/home/stephane/src/hg.python.org/cpython/Lib/unittest/suite.py", line 
84 in __call__
  File "/home/stephane/src/hg.python.org/cpython/Lib/unittest/suite.py", line 
122 in run
  File "/home/stephane/src/hg.python.org/cpython/Lib/unittest/suite.py", line 
84 in __call__
  File "/home/stephane/src/hg.python.org/cpython/Lib/unittest/suite.py", line 
122 in run
  File "/home/stephane/src/hg.python.org/cpython/Lib/unittest/suite.py", line 
84 in __call__
  File "/home/stephane/src/hg.python.org/cpython/Lib/test/support/__init__.py", 
line 1679 in run
  File "/home/stephane/src/hg.python.org/cpython/Lib/test/support/__init__.py", 
line 1780 in _run_suite
  File "/home/stephane/src/hg.python.org/cpython/Lib/test/support/__init__.py", 
line 1814 in run_unittest
  File 
"/home/stephane/src/hg.python.org/cpython/Lib/test/libregrtest/runtest.py", 
line 161 in test_runner
  File 
"/home/stephane/src/hg.python.org/cpython/Lib/test/libregrtest/runtest.py", 
line 162 in runtest_inner
  File 
"/home/stephane/src/hg.python.org/cpython/Lib/test/libregrtest/runtest.py", 
line 126 in runtest
  File "/home/stephane/src/hg.python.org/cpython/Lib/test/libregrtest/main.py", 
line 295 in run_tests_sequential
  File "/home/stephane/src/hg.python.org/cpython/Lib/test/libregrtest/main.py", 
line 356 in run_tests
  File "/home/stephane/src/hg.python.org/cpython/Lib/test/libregrtest/main.py", 
line 392 in main
  File "/home/stephane/src/hg.python.org/cpython/Lib/test/libregrtest/main.py", 
line 433 in main
  File "/home/stephane/src/hg.python.org/cpython/Lib/test/libregrtest/main.py", 
line 455 in main_in_temp_cwd
  File "/home/stephane/src/hg.python.org/cpython/Lib/test/__main__.py", line 3 
in 
  File "/home/stephane/src/hg.python.org/cpython/Lib/runpy.py", line 85 in 
_run_code
  File "/home/stephane/src/hg.python.org/cpython/Lib/runpy.py", line 170 in 
_run_module_as_main
fish: “./python -m test test_operator” terminated by signal SIGABRT (Abort)
stephane@sg1 ~/s/h/cpython> 


stephane@sg1 ~/s/h/cpython> hg tip
changeset:   99407:734247d5d0f9
tag: tip
parent:  99404:ac0f7ed0e94d
parent:  99406:fee19d2d7713
user:Zachary Ware 
date:Mon Nov 30 22:57:22 2015 -0600
summary: Closes #25767: Merge with 3.5

--
nosy: +matrixise

___
Python tracker 

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

[issue25772] Misleading descriptions about built-in type `super.`

[Martin Panter]

Martin Panter added the comment:

I agree. I think Issue 23674 already covers this. I will try to propose some 
changes there.

--
nosy: +martin.panter
resolution:  -> duplicate
status: open -> closed
superseder:  -> super() documentation isn't very clear

___
Python tracker 

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

[issue25698] The copy_reg module becomes unexpectedly empty in test_cpickle

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

http://buildbot.python.org/all/builders/PPC64LE%20Fedora%202.7/builds/164/steps/test/logs/stdio

Failed a number of tests that directly or indirectly use copy_reg. First failed 
test is test_cpickle.

--
title: test regressions introduced with the fix for #22995 -> The copy_reg 
module becomes unexpectedly empty in test_cpickle
type:  -> behavior

___
Python tracker 

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

[issue25717] tempfile.TemporaryFile fails when dir option set to directory residing on host OS mount

[Bohuslav "Slavek" Kabrda]

Bohuslav "Slavek" Kabrda added the comment:

The patch looks good to me.

--

___
Python tracker 

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

[issue22138] patch.object doesn't restore function defaults

[Xiadong Zhu]

Xiadong Zhu added the comment:

How's the issue going on?

The situation to mock function's ``__defaults__`` attribute is general, as 
default argument is determinate after function definition, when we need to test 
a function such as:

def access_db(statement, backend=default_db_backend):
return default_db_backend.execute(statement)

that we must mock ``__defaults__`` attribute if we want to invoke it with 
default backend.

It has one year past, though I could patch the ``_patch`` class but it's dirty, 
is the issue a defect can be fixed or unsolvable?

--
nosy: +mailto1587

___
Python tracker 

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

[issue4709] Mingw-w64 and python on windows x64

[Henry Gomersall]

Henry Gomersall added the comment:

I want to second Ralf's comments about both the need for this and it being easy 
to get.

What is required to make this happen (specifically the easy to install build 
chain - pip install...)? It would be good to enumerate the outstanding issues.

The current difficulty of building extensions on Windows should not be 
underestimated. Microsoft seem to change how their various tools work, with 
different updated SDKs and removing tools and changing things (even 
retrospectively) quite regularly.

I've wasted quite a bit of time setting up windows machines to build the 
various flavours (bits and python version), only to find that the same strategy 
doesn't for some reason beyond my comprehension doesn't work on a different 
machine. Throw in different windows versions and the problem is pretty 
insurmountable and unsustainable.

To be clear, the current situation surely cannot be worse than a MinGW 
situation.

--
nosy: +Henry Gomersall

___
Python tracker 

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

[issue4709] Mingw-w64 and python on windows x64

[Henry Gomersall]

Henry Gomersall added the comment:

Of course, I mean:

*To be clear, the MinGW situation surely cannot be worse than the current 
situation.*

--

___
Python tracker 

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

[issue4709] Mingw-w64 and python on windows x64

[Duncan McBryde]

Changes by Duncan McBryde :


--
nosy: +Duncan McBryde

___
Python tracker 

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

[issue25177] OverflowError in statistics.mean when summing large floats

[Roundup Robot]

Roundup Robot added the comment:

New changeset 4bc9405c4f7b by Steven D'Aprano in branch '3.4':
Fix for issue #25177 with the mean of very small and very large numbers.
https://hg.python.org/cpython/rev/4bc9405c4f7b

New changeset ed45a09e5a69 by Steven D'Aprano in branch '3.5':
Fixed issue #25177, problems with the mean of very small and very large numbers.
https://hg.python.org/cpython/rev/ed45a09e5a69

New changeset 0eeb39fc8ff5 by Steven D'Aprano in branch 'default':
Issue #25177: Fixed problem with the mean of very small and very large numbers.
https://hg.python.org/cpython/rev/0eeb39fc8ff5

--
nosy: +python-dev

___
Python tracker 

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

[issue22138] patch.object doesn't restore function defaults

[Michael Foord]

Michael Foord added the comment:

Sean's patch looks good to me.

--

___
Python tracker 

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

[issue25768] compileall functions do not document return values

[Brett Cannon]

Brett Cannon added the comment:

At this point the return values are probably as official as they are going to 
be since these are such old functions.

If you want to write a patch, Nicholas, please see 
https://docs.python.org/devguide/ for instructions on how to do that.

--
nosy: +brett.cannon

___
Python tracker 

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

[issue25771] importlib: '.submodule' is not a relative name (no leading dot)

[Brett Cannon]

Brett Cannon added the comment:

So both proposed messages are correct depending on what you want to accomplish; 
it all depends on whether the leading dot was the mistake or the missing 
package was.

And the message does make some sense if you read it more like "'.submodule' is 
not a relative name (drop the leading dot)". I do agree, though, it's hard to 
read as written.

--
assignee:  -> brett.cannon
nosy: +brett.cannon

___
Python tracker 

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

[issue25773] Deprecate deleting with PyObject_SetAttr, PyObject_SetAttrString and PySequence_SetItem

[Serhiy Storchaka]

New submission from Serhiy Storchaka:

If the third argument of PyObject_SetAttr(), PyObject_SetAttrString() or 
PySequence_SetItem() is NULL, these functions delete an attribute or an item. 
This is rather undocumented implementation detail. There are special 
counterparts for deleting:  PyObject_DelAttr(), PyObject_DelAttrString() and 
PySequence_DelItem(). May be worth to depre

Proposed patch deprecates using these Set* functions for deleting and replaces 
them with appropriate Del* functions if needed.

Discussion on Python-Dev: 
http://comments.gmane.org/gmane.comp.python.devel/155474

Issue that documents deleting with Set* APIs: issue25701.

--
components: Interpreter Core
files: PyObject_SetAttr_deleting.patch
keywords: patch
messages: 255655
nosy: gvanrossum, martin.panter, ncoghlan, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Deprecate deleting with PyObject_SetAttr, PyObject_SetAttrString and 
PySequence_SetItem
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file41200/PyObject_SetAttr_deleting.patch

___
Python tracker 

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

[issue25772] Misleading descriptions about built-in `super.`

[R. David Murray]

R. David Murray added the comment:

Just FYI, 'super' is not a type, it is a function that returns a proxy.  (In 
python3 there is also compiler magic involved in the no-argument form, but it 
is still a function :)

--
nosy: +r.david.murray
title: Misleading descriptions about built-in type `super.` -> Misleading 
descriptions about built-in `super.`

___
Python tracker 

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

[issue22138] patch.object doesn't restore function defaults

[R. David Murray]

Changes by R. David Murray :


--
stage: needs patch -> commit review

___
Python tracker 

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

[issue25770] expose name, args, and kwargs from methodcaller

[Joe Jevnik]

Joe Jevnik added the comment:

Thanks for review, looking into the reference count issue.

--

___
Python tracker 

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

[issue25768] compileall functions do not document return values

[Nicholas Chammas]

Nicholas Chammas added the comment:

Exciting! I'm on it.

--

___
Python tracker 

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

[issue25601] test_cpickle failure on the ware-gentoo-x86 buildbot

[Barry A. Warsaw]

Barry A. Warsaw added the comment:

I'm duping this one to issue25698 because while it came later, it has a lot 
more information.  They are clearly the same bug.

--
nosy: +barry
superseder:  -> The copy_reg module becomes unexpectedly empty in test_cpickle

___
Python tracker 

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

[issue25601] test_cpickle failure on the ware-gentoo-x86 buildbot

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
resolution:  -> duplicate
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

[issue25698] The copy_reg module becomes unexpectedly empty in test_cpickle

[Barry A. Warsaw]

Barry A. Warsaw added the comment:

Well, one thing I noticed is that init_stuff() in cPickle.c can leak the 
copy_reg module object, if any of the subsequent PyObject_GetAttr*() calls 
fail.  They return -1 without decref'ing copyreg.  Probably not a horrible leak 
since it's probably rare, but it should be fixed on principle.

--

___
Python tracker 

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

[issue25698] The copy_reg module becomes unexpectedly empty in test_cpickle

[Barry A. Warsaw]

Barry A. Warsaw added the comment:

At the problematic breakpoint mentioned in msg255630, copy_reg is nearly empty.

(Pdb) sys.modules['copy_reg']

(Pdb) dir(sys.modules['copy_reg'])
['__builtins__', '__doc__', '__file__', '__name__', '__package__']
(Pdb) sys.modules['copy_reg'].__file__
'/build/python2.7-96oGYh/python2.7-2.7.11~rc1/Lib/copy_reg.pyc'
(Pdb) sys.modules['copy_reg'].__doc__ 
(Pdb) sys.modules['copy_reg'].__name__
'copy_reg'
(Pdb) sys.modules['copy_reg'].__package__

--

___
Python tracker 

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

[issue25698] The copy_reg module becomes unexpectedly empty in test_cpickle

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Was it empty before running any test_cpickle tests? Could you find after what 
test it becomes empty?

--

___
Python tracker 

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

[issue25772] Misleading descriptions about built-in `super.`

[Eryk Sun]

Eryk Sun added the comment:

> Just FYI, 'super' is not a type

No, super is a type:

>>> super


It's one of 3 types defined in Objects/typeobject.c: 

PyBaseObject_Type : "object"
PyType_Type   : "type"
PySuper_Type  : "super"

A super instance (CPython superobject) has the following members: 

 __thisclass__  : the class invoking super()
 __self__   : the instance invoking super()
 __self_class__ : the type of the instance invoking super()

super has a cutsom __getattribute__ (tp_getattro) slot, super_getattro, which 
proxies attribute access starting at the parent/sibling of __thisclass__ in the 
__mro__ of __self_class__. 

super even defines a __get__ descriptor (tp_descr_get) method, super_descr_get, 
though I've never used it as such.

--
nosy: +eryksun

___
Python tracker 

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

[issue25772] Misleading descriptions about built-in `super.`

[R. David Murray]

R. David Murray added the comment:

Heh.  OK, learn something new every day.

--

___
Python tracker 

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

[issue25768] compileall functions do not document return values

[Nicholas Chammas]

Nicholas Chammas added the comment:

OK, here's a patch.

I reviewed the doc style guide [0] but I'm not 100% sure if I'm using the 
appropriate tense. There are also a couple of lines that go a bit over 80 
characters, but the file already had a few of those.

Am happy to make any adjustments, if necessary.

[0] https://docs.python.org/devguide/documenting.html#style-guide

--
keywords: +patch
Added file: http://bugs.python.org/file41201/compileall-doc.patch

___
Python tracker 

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

[issue25768] compileall functions do not document return values

[Nicholas Chammas]

Nicholas Chammas added the comment:

And I just signed the contributor agreement. (Some banner showed up when I 
attached the patch to this issue asking me to do so.)

--

___
Python tracker 

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

[issue25698] The copy_reg module becomes unexpectedly empty in test_cpickle

[Barry A. Warsaw]

Barry A. Warsaw added the comment:

This just gets weirder.  I've narrowed it down to running this command:

build-static/python Lib/test/regrtest.py test_doctest test_cpickle

fails every time.  What's even weirder is that I hacked regrtest to print some 
useful information before and after each test run.  It prints the 
id(sys.modules['copy_reg']) and len(dir(sys.modules['copy_reg']))).  Here's the 
output for two test runs.  You can see that if test_doctest is run before 
test_cpickle, regrtest sees a different module in sys.modules['copy_reg'], but 
only *after* test_cpickle runs.  Using test_doctest2 instead is fine.

I'll note one other thing.  Doko mentioned that in our build environment, 
cPickle is built in, not an extension.

# build-static/python Lib/test/regrtest.py test_doctest test_cpickle
[1/2] test_doctest
('BEFORE =>', 140559940644712, 22)
('AFTER =>', 140559940644712, 22)
[2/2] test_cpickle
('BEFORE =>', 140559940644712, 22)
test test_cpickle failed -- multiple errors occurred; run in verbose mode for 
details
('AFTER =>', 140559897320928, 5)
1 test OK.
1 test failed:
test_cpickle

# build-static/python Lib/test/regrtest.py test_doctest2 test_cpickle
[1/2] test_doctest2
('BEFORE =>', 139794866929512, 22)
('AFTER =>', 139794866929512, 22)
[2/2] test_cpickle
('BEFORE =>', 139794866929512, 22)
('AFTER =>', 139794866929512, 22)
All 2 tests OK.

--

___
Python tracker 

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

[issue25698] The copy_reg module becomes unexpectedly empty in test_cpickle

[Barry A. Warsaw]

Barry A. Warsaw added the comment:

On Dec 01, 2015, at 06:26 PM, Barry A. Warsaw wrote:

>I'll note one other thing.  Doko mentioned that in our build environment,
>cPickle is built in, not an extension.

Which may be relevant because in a from-hg-head build of Python 2.7, this
problem doesn't occur.  I haven't tried 2.7.11 tarball yet.

--

___
Python tracker 

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

[issue25774] [benchmarks] Adjust to allow uploading benchmark data to codespeed

[Zachary Ware]

New submission from Zachary Ware:

Here's a patch to the benchmarks repo that allows running a benchmark on a 
single interpreter and returning raw data, and provides a script to upload the 
raw data to a codespeed instance.  It's a bit of a quick hack, but is effective.

This is a prerequisite to getting speed.python.org running.

--
components: Benchmarks
files: benchmarks.diff
hgrepos: 323
keywords: patch
messages: 255669
nosy: brett.cannon, pitrou, zach.ware
priority: normal
severity: normal
stage: patch review
status: open
title: [benchmarks] Adjust to allow uploading benchmark data to codespeed
type: enhancement
Added file: http://bugs.python.org/file41202/benchmarks.diff

___
Python tracker 

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

[issue25768] compileall functions do not document return values

[Brett Cannon]

Brett Cannon added the comment:

Thanks, Nicholas! I'll have a look when I have a chance (hopefully no later 
than Friday).

--
assignee: docs@python -> brett.cannon

___
Python tracker 

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

[issue25698] The copy_reg module becomes unexpectedly empty in test_cpickle

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Thanks Barry. Running test_cpickle after test_doctest I now can reproduce the 
problem in a from-hg-head build of Python 2.7.

--

___
Python tracker 

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

[issue25698] The copy_reg module becomes unexpectedly empty in test_cpickle

[Barry A. Warsaw]

Barry A. Warsaw added the comment:

On Dec 01, 2015, at 06:47 PM, Serhiy Storchaka wrote:

>Thanks Barry. Running test_cpickle after test_doctest I now can reproduce the
>problem in a from-hg-head build of Python 2.7.

That's interesting because I can't!  (Neither from the 2.7.11rc1 tarball.)

Did you make cPickle a built-in like Doko did?

--

___
Python tracker 

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

[issue25698] The copy_reg module becomes unexpectedly empty in test_cpickle

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Ah, sorry, I missed and mislead you. My tests were specially hacked to simulate 
a bug (sys.modules['copy_reg'] = object()). No, actually I can't reproduce it.

--

___
Python tracker 

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

[issue25698] The copy_reg module becomes unexpectedly empty in test_cpickle

[Barry A. Warsaw]

Barry A. Warsaw added the comment:

I added cPickle to Modules/Setup.local and rebuilt from hg.  cPickle's a 
built-in but I still can't reproduce the problem.

--

___
Python tracker 

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

[issue25768] compileall functions do not document return values

[Nicholas Chammas]

Nicholas Chammas added the comment:

:thumbsup: Take your time.

--

___
Python tracker 

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

[issue25775] Bug tracker emails go to spam

[Nicholas Chammas]

New submission from Nicholas Chammas:

Not sure where to report this. Is there a component for the bug tracker itself?

Anyway, Gmail sends emails from this bug tracker to spam and flags each one 
with the following message:

> Why is this message in Spam? It is in violation of Google's recommended email 
> sender guidelines.  Learn more
> https://support.google.com/mail/answer/81126?hl=en#authentication

Is this actionable? Is this a known issue?

--
messages: 255676
nosy: Nicholas Chammas
priority: normal
severity: normal
status: open
title: Bug tracker emails go to spam
type: behavior

___
Python tracker 

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

[issue25768] compileall functions do not document return values

[Nicholas Chammas]

Nicholas Chammas added the comment:

Oh derp. It appears this is dup of issue24386. Apologies.

--
status: open -> closed

___
Python tracker 

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

[issue25768] compileall functions do not document return values

[Nicholas Chammas]

Nicholas Chammas added the comment:

Whoops, wrong issue. Reopening.

--
status: closed -> open

___
Python tracker 

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

[issue25775] Bug tracker emails go to spam

[Nicholas Chammas]

Nicholas Chammas added the comment:

Oh derp. It appears this is dup of issue24386. Apologies.

--
status: open -> closed

___
Python tracker 

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

[issue25775] Bug tracker emails go to spam

[R. David Murray]

Changes by R. David Murray :


--
resolution:  -> duplicate
stage:  -> resolved
superseder:  -> Bug Tracker emails going to gmail spam

___
Python tracker 

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

[issue25731] Assigning and deleting __new__ attr on the class does not allow to create instances of this class

[Eryk Sun]

Changes by Eryk Sun :


--
nosy: +benjamin.peterson, twouters

___
Python tracker 

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

[issue25770] expose name, args, and kwargs from methodcaller

[Martin Panter]

Martin Panter added the comment:

Left a review comment which may help you chase that refleak

Also, as a new feature, surely it should be documented?

--
nosy: +martin.panter

___
Python tracker 

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

[issue25714] Consider isinstance(..., numbers.Integral) instead of isinstance(..., int) or isinstance(..., (int, long)) in datetime.py

[Matt Bogosian]

Matt Bogosian added the comment:

> I consider this as a bug and think that we should weak some of checks 
> isinstance(..., int) to isinstance(..., (int, long)). numbers.Integral is too 
> wide type, C implementation doesn't support it.

Oddly enough, the C implementation is what is working with `future` in this 
case (although I take your point regarding `numbers.Integral` being too wide; 
`future.types.newint` effectively behaves like a `long`, and 
`isinstance(future.types.newint(1), long)` returns `True`).

--

___
Python tracker 

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

[issue25770] expose name, args, and kwargs from methodcaller

[Joe Jevnik]

Joe Jevnik added the comment:

Thanks for pointing me at the refleak, uploading an update

--
Added file: http://bugs.python.org/file41203/methodcaller-attrs-1.patch

___
Python tracker 

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

[issue24731] Incorrect assert in str_subtype_new

[Kevin Modzelewski]

Kevin Modzelewski added the comment:

Awesome, thanks!

--

___
Python tracker 

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

[issue25770] expose name, args, and kwargs from methodcaller

[Joe Jevnik]

Joe Jevnik added the comment:

Added a test case for the mutation of keywords.

--
Added file: http://bugs.python.org/file41204/methodcaller-attrs-2.patch

___
Python tracker 

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

[issue23674] super() documentation isn't very clear

[Martin Panter]

Martin Panter added the comment:

Here are some specific changes I suggest:

1. Most confusing: super() uses the MRO of the second argument, not the first.

2. Clarify that is is not just the first argument that is skipped in the MRO, 
it is all preceding classes as well. The first argument does not have to be the 
class at the start of the MRO.

3. Revise signature and use consistent parameter names in text. Currently, 
“obj” and “type2” are only defined in the doc string. Perhaps super(subclass[, 
self]). Or maybe super(type[, obj]), matching error messages, or 
super(thisclass[, self]), matching the special attributes. Type and type2 are 
too confusing for my taste.

4. Link to the glossary rather than getattr().

5. Explain more about unbound super objects, when the second argument is 
omitted. Apparently they are descriptors; when you set them on a class and then 
“get” them in an instance, you get a new version bound to that instance. This 
is obscure, but I feel it might help the general understanding. [It seems you 
cannot bind a super() object to a class this way; maybe that is a bug.]

6. Explain more about “bound” super objects: getting a method from the super 
object binds the method to the second argument. [This also works for getting 
data properties, but not setting or deleting them; see Issue 14965.]

7. Not only isinstance() or issubclass() must be satisfied, but the first 
argument must be a concrete class. Virtual subclassing is not sufficient if the 
subclass is not in the MRO. This would address Issue 20503. Also, the first 
argument should be a derived class, not “object” itself.

--
versions:  -Python 3.2, Python 3.3

___
Python tracker 

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

[issue20503] super behaviour and abstract base classes (either implementation or documentation/error message is wrong)

[Martin Panter]

Martin Panter added the comment:

I am proposing some documentation changes in Issue 23674 which would address 
this.

--
assignee:  -> docs@python
components: +Documentation -Interpreter Core
dependencies: +super() documentation isn't very clear
nosy: +docs@python, martin.panter
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

[issue25177] OverflowError in statistics.mean when summing large floats

[Steven D'Aprano]

Steven D'Aprano added the comment:

Larry,

Is it too late to get this into 3.5rc1?

changeset 99407:ed45a09e5a69

Thanks.

--
nosy: +larry

___
Python tracker 

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

[issue25770] expose name, args, and kwargs from methodcaller

[Martin Panter]

Martin Panter added the comment:

This is a bit odd. You can mutate the keyword arguments, but you are not 
allowed to change the positional arguments (“args” is readonly). If you want 
this to be part of the supported API, it should be documented, but it seems 
like bad design IMO.

--

___
Python tracker 

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

[issue25770] expose name, args, and kwargs from methodcaller

[Joe Jevnik]

Joe Jevnik added the comment:

I only want this feature to keep the usage close to functools.partial. I was 
actually sort of surprised to see that mutation of the dict held in partial, 
but I would rather be consistent.

--

___
Python tracker 

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

[issue14285] Traceback wrong on ImportError while executing a package

[Martin Panter]

Martin Panter added the comment:

Now I have a deeper understanding I think this can be handled separately to 
Issue 16217.

This patch pulls together my previous two patches, and adds a fix. There are 
two aspects of my fix:

1. Import the package before calling find_spec() on the __main__ submodule. 
This means exceptions raised by the initialization code can be differentiated 
from exceptions from find_spec().

2. Change all the special ImportError exceptions raised inside runpy [and also 
one raised by InspectLoader.get_code()] to an internal _Error exception known 
only to runpy. Now I can be sure that all _Error exceptions are not caused by 
the initialization code, and I can stop catching ImportError, but still catch 
_Error and suppress the traceback. When runpy is invoked from the documented 
run_module() or run_path() APIs, _Error is not used, and it still raises 
ImportError to maintain backwards compatibility.

I think my patch should avoid the main problem in Issue 19771 as well.

Please review my patch. There are so many error possibilities; it is hard to be 
sure I have got them all right.

--
components: +Library (Lib)
stage:  -> patch review
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

[issue14285] Traceback wrong on ImportError while executing a package

[Martin Panter]

Changes by Martin Panter :


Added file: http://bugs.python.org/file41205/internal-error.patch

___
Python tracker 

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

[issue19771] runpy should check ImportError.name before wrapping it

[Martin Panter]

Martin Panter added the comment:

My new patch for Issue 14285 should avoid the main problem. However there would 
still be at least one leftover minor fix worth appyling: fix the exception 
message to use type(ex).__name__, not repr(type(ex)).

--
dependencies: +Traceback wrong on ImportError while executing a package
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

[issue14285] Traceback wrong on ImportError while executing a package

[Nick Coghlan]

Nick Coghlan added the comment:

Martin, your patch looks good to me, and is at the very least an improvement 
over the status quo (which clearly traps exceptions that it shouldn't), so I'd 
say go ahead and apply it.

Thanks for digging into this and figuring out a clean solution.

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

[issue25735] math.factorial doc should mention integer return type

[Sonali Gupta]

Sonali Gupta added the comment:

States that math.factorial(x) returns x factorial as an integer.

--
keywords: +patch
nosy: +mine0901
Added file: http://bugs.python.org/file41206/bug.patch

___
Python tracker 

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

[issue25770] expose name, args, and kwargs from methodcaller

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

"keywords" is unusual name. The most used name for the dict of keyword 
arguments is "kwargs".

$ find Lib/ -name '*.py' -exec egrep -ho '\*\*[a-zA-Z_0-9]+' '{}' + | sort | 
uniq -c | sort -nr | head
803 **kwargs
442 **kw
244 **kwds
...

If you want to have keyword arguments non-mutable, you can use 
types.MappingProxyType.

--
nosy: +serhiy.storchaka

___
Python tracker 

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

[issue25770] expose name, args, and kwargs from methodcaller

[Joe Jevnik]

Joe Jevnik added the comment:

I agree that it is a strange name and I also think that it could be immutable 
or a copy of the internal dict; however, I think that consistency with existing 
APIs in the standard library is more important. 'keywords' is still very clear 
in context and is used in 'functools.partial'. This feature is very similar to 
'partial' so I would like to follow the example set there.

I would not mind changing 'partial' to reflect this feedback; but, I imagine 
that will break people's code and be a harder sell. I would find it frustrating 
if 'partial' and 'methodcaller' spelled 'keywords' differently or had slightly 
different behavior when it comes to the keyword argument dictionary. Allowing 
the mutation is not that unintuitive if you look at the simple python 
translation I added to the docs.

--

___
Python tracker 

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