[issue24654] PEP 492 - example benchmark doesn't work (TypeError)
Yury Selivanov added the comment:
Fixed in https://hg.python.org/peps/rev/7ad183c1d9be
I'll quote the commit message here:
pep-492: Update benchmark code
Since coroutines now have a distinct type, they do not support
iteration. Instead of doing 'list(o)', we now do 'o.send(None)'
until StopIteration.
Note, that the updated timings are due to the difference of
doing a loop in Python vs doing it in C ('list()' vs 'while True').
Marcin and Terry, thanks for reporting this!
--
resolution: - fixed
stage: needs patch - resolved
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24654
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3616] finalizer
Ilya Kulakov added the comment: This issue is marked as closed as a duplicate without a reference to the original task. I still have this issues on Python 3.4.2, on Windows when shutil.rmtree fails to -- nosy: +Ilya.Kulakov title: shutil.rmtree() fails on invalid filename - finalizer ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3616 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24654] PEP 492 - example benchmark doesn't work (TypeError)
Stefan Behnel added the comment: Thanks for updating the micro-benchmark. Just FYI (and sorry for hijacking this ticket), I ran it through Cython. Here are the numbers: Cython 0.23 (latest master) binary(21) * 3: total 1.609s abinary(21) * 3: total 1.514s CPython 3.5 (latest branch) binary(21) * 3: total 4.653s abinary(21) * 3: total 4.750s The low factor between the two shows (IMO) that using a type slot function for await was a very good idea. Streamlining FetchStopIteration might bring another bit. I also tried the same thing with alternating recursively between the Python and Cython implementation by changing it to l = await cy_abinary(n - 1) r = await py_abinary(n - 1) binary(21) * 3: total 3.835s abinary(21) * 3: total 3.952s So even the slow fallback paths seem pretty efficient on both sides. -- nosy: +scoder ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24654 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24659] dict() built-in fails on iterators with a keys attribute
Christian Barcenas added the comment:
Should have clarified that the specific issue that is outlined in #5945 is that
PyMapping_Check returns 1 on sequences (e.g. lists), which would mean something
like x = [('one', 1), ('two', 2)]; dict(x) would fail in 3.x because x would be
incorrectly evaluated as a mapping rather than as an iterable.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24659
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3616] finalizer
STINNER Victor added the comment: Hi, the issue was fixed in Python 3. On Windows, you must use Unicode. Otherwise, you can get errors like that. On other platforms, Unicode is now also the best choice on Python 3. See the second message for the superseder issue. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3616 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24659] dict() built-in fails on iterators with a keys attribute
New submission from Christian Barcenas:
I noticed an inconsistency today between the dict() documentation vs.
implementation.
The documentation for the dict() built-in [1] states that the function accepts
an optional positional argument that is either a mapping object [2] or an
iterable object [3].
Consider the following:
import collections.abc
class MyIterable(object):
def __init__(self):
self._data = [('one', 1), ('two', 2)]
def __iter__(self):
return iter(self._data)
class MyIterableWithKeysMethod(MyIterable):
def keys(self):
return And now for something completely different
class MyIterableWithKeysAttribute(MyIterable):
keys = It's just a flesh wound!
assert issubclass(MyIterable, collections.abc.Iterable)
assert issubclass(MyIterableWithKeysMethod, collections.abc.Iterable)
assert issubclass(MyIterableWithKeysAttribute, collections.abc.Iterable)
assert not issubclass(MyIterable, collections.abc.Mapping)
assert not issubclass(MyIterableWithKeysMethod, collections.abc.Mapping)
assert not issubclass(MyIterableWithKeysAttribute, collections.abc.Mapping)
# OK
assert dict(MyIterable()) == {'one': 1, 'two': 2}
# Traceback (most recent call last):
# File stdin, line 1, in module
# TypeError: 'MyIterableWithKeysMethod' object is not subscriptable
assert dict(MyIterableWithKeysMethod()) == {'one': 1, 'two': 2}
# Traceback (most recent call last):
# File stdin, line 1, in module
# TypeError: attribute of type 'str' is not callable
assert dict(MyIterableWithKeysAttribute()) == {'one': 1, 'two': 2}
The last two assertions should not fail, and it appears that the offending code
can be found in Objects/dictobject.c's dict_update_common:
else if (arg != NULL) {
_Py_IDENTIFIER(keys);
if (_PyObject_HasAttrId(arg, PyId_keys))
result = PyDict_Merge(self, arg, 1);
else
result = PyDict_MergeFromSeq2(self, arg, 1);
}
PyDict_Merge is used to merge key-value pairs if the optional parameter is a
mapping, and PyDict_MergeFromSeq2 is used if the parameter is an iterable.
My immediate thought was to substitute the _PyObject_HasAttrId call with
PyMapping_Check which I believe would work in 2.7, but due to #5945 I don't
think this fix would work in 3.x.
Thoughts?
[1] https://docs.python.org/3.6/library/stdtypes.html#dict
[2] https://docs.python.org/3.6/glossary.html#term-mapping
[3] https://docs.python.org/3.6/glossary.html#term-iterable
--
assignee: docs@python
components: Documentation, Interpreter Core
messages: 246890
nosy: christian.barcenas, docs@python
priority: normal
severity: normal
status: open
title: dict() built-in fails on iterators with a keys attribute
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24659
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
EuroPython 2015: More attendee tips
Some more last-minute news and tips for attendees. Be sure to check our attendee tips page for more information. Bilbao tram service on strike - Just like in Berlin last year, there will be some inconvenience due to strikes in Bilbao. The Bilbao tram service has been on strike since July 15th and it may well last until the end of Summer. The tram services will stop from 11:55 - 14.00 and 17:55 - 20.00 CEST each day and only maintain minimum service at other times. See “Paralizado el servicio de tranvía en Bilbao por huelga de sus trabajadores” for more details (in Spanish): http://www.elmundo.es/pais-vasco/2015/07/15/55a66b6aca47414f298b457e.html We had originally wanted to provide free public transport for attendees, but given the strikes during conference rush hours, we decided to drop this. Note that buses and the metro will still operate as usual. Great weather - You will not only benefit from excellent talks, but also receive lots of Vitamin D in Bilbao. The weather forecast for the week is excellent: *lots of sunshine* and between 28°-30° Celsius: http://www.bbc.com/weather/3128026 So while the tram is on strike, you can walk and get an ice cream instead of a tram ticket. Speaker preparations If you are a speaker, please read the nice guide written by Harry Percival: Tips for speakers https://ep2015.europython.eu/en/speakers/tips/ In particular, please check your talk time. The session chairs will have to make sure that all speakers only use the assigned talk time, so that the tracks don’t run out of sync. There are also some important technical things to prepare your talk at the conference: * *test your notebook* with the projector in the room where you will be holding your talk * make sure you have the right VGA adapters with you * make sure the projector resolution is supported by your notebook It’s best to do all of the above a few hours or a day before your talk. In case of problems, you can then try to find alternative solutions, e.g. borrow someone’s notebook for the talk. Enjoy, -- EuroPython 2015 Team http://ep2015.europython.eu/ http://www.europython-society.org/ -- https://mail.python.org/mailman/listinfo/python-list
[issue24659] dict() built-in fails on iterators with a keys attribute
Martin Panter added the comment: It is at least an omission from the documentation. The glossary https://docs.python.org/dev/glossary.html#term-mapping refers to the Mapping ABC. From Christian’s point of view, the quack of an iterator with just a “keys” attribute sounds more like an iterator than a mapping. I think the documentation for the dict() constructor should say how to ensure the iterable and mapping modes are triggered. Perhaps dict.update() should also, because it appears to also treat non-dict() “mappings” differently to plain iterators. -- nosy: +vadmium ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24659 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24661] CGIHTTPServer: premature unescaping of query string
New submission from John S: I created a simple CGI script that outputs the query string passed to it: ``` #!/usr/bin/env python import os print 'Content-Type: text/html\n\n' print os.environ['QUERY_STRING'] ``` I saved it as cgi-bin/test.cgi and made it executable. I then ran `python -m CGIHTTPModule` and opened http://localhost:8000/cgi-bin/test.cgi?H%26M in a web browser. The output was HM when it should have been H%26M I tried with Python 2.7.5, 2.7.3 and 2.6.6 and they all correctly output H%26M. The test.cgi file is attached. -- components: Library (Lib) files: test.cgi messages: 246900 nosy: johnseman priority: normal severity: normal status: open title: CGIHTTPServer: premature unescaping of query string versions: Python 2.7 Added file: http://bugs.python.org/file39943/test.cgi ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24661 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Need assistance
You don't have to index them. You can unpack them into a tuple of first, middle, last Laura (who is trying not to do somebody's homework for them, since I'm not the person who needs to learn this). -- https://mail.python.org/mailman/listinfo/python-list
[issue24660] Heapq + functools.partial : TypeError: unorderable types
Josh Rosenberg added the comment: Neither of those example should work (and neither do on my 3.4.0 installation). Heaps must have sortable components; you could only include callables (which are not sortable) in the tuples being sorted if you guarantee that some element(s) before the callable will ensure the elements are ordered without falling back on comparing the callable members. This isn't a bug; heapq.heapify() *should* fail in this case, and in any case where sorted() would fail due to uncomparable objects. -- nosy: +josh.r ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24660 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10845] test_multiprocessing failure under Windows
Changes by Gabi Davar grizzly@gmail.com: -- nosy: +Gabi.Davar ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10845 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24656] remove assret from mock error checking
Ethan Furman added the comment: Better patch: fixes NEWS, tests, and docs, as well as the code. -- Added file: http://bugs.python.org/file39945/remove_assret.stoneleaf.02.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24656 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24659] dict() built-in fails on iterators with a keys attribute
R. David Murray added the comment: Well, this is an example of duck typing, something we commonly do in Python. I'm not convinced this is a bug. -- nosy: +r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24659 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24660] Heapq + functools.partial : TypeError: unorderable types
New submission from Марк Коренберг: import heapq from functools import partial qwe = [(0, lambda x: 42), (0, lambda x: 56)] heapq.heapify(qwe) qwe = [(0, partial(lambda x: 42)), (0, partial(lambda x: 56))] heapq.heapify(qwe) Traceback (most recent call last): File /usr/lib/python3.4/code.py, line 90, in runcode exec(code, self.locals) File input, line 1, in module TypeError: unorderable types: functools.partial() functools.partial() So it is not realiable to use heapq if element of the array is (int, callable) -- components: Library (Lib) messages: 246894 nosy: mmarkk priority: normal severity: normal status: open title: Heapq + functools.partial : TypeError: unorderable types type: behavior versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24660 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24660] Heapq + functools.partial : TypeError: unorderable types
Martin Panter added the comment: I can’t compare non-partial functions either. How did your first heapify() call succeed? Python 3.4.3 (default, Mar 25 2015, 17:13:50) [GCC 4.9.2 20150304 (prerelease)] on linux Type help, copyright, credits or license for more information. import heapq from functools import partial qwe = [(0, lambda x: 42), (0, lambda x: 56)] heapq.heapify(qwe) Traceback (most recent call last): File stdin, line 1, in module TypeError: unorderable types: function() function() (lambda x: 42) (lambda x: 56) Traceback (most recent call last): File stdin, line 1, in module TypeError: unorderable types: function() function() This is not a problem specific to “heapq”. This is how function objects, lambda objects, bound class methods, etc, are meant to work. Python doesn’t implement ordering comparisons for them. This is kind of explained at https://docs.python.org/dev/reference/expressions.html#comparisons. See Issue 12067 if you want to help improve this section of the documentation. If you don’t care about the order, perhaps you could ensure the first item in each tuple is unique, or add a dummy item in the middle that ensures the tuples have a definite order: (0, 0, lambda x: 42) (0, 1, lambda x: 56) True -- nosy: +vadmium resolution: - not a bug status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24660 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23573] Avoid redundant allocations in str.find and like
Serhiy Storchaka added the comment: Here is a patch that restores optimization of bytes.rfind() and bytearray.rfind() with 1-byte argument on Linux (it also reverts bc1a178b3bc8). -- nosy: +christian.heimes resolution: fixed - stage: resolved - patch review Added file: http://bugs.python.org/file39944/issue23573_bytes_rfind_memrchr.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23573 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Need assistance
Am 18.07.2015 um 02:40 schrieb Denis McMahon:
On Thu, 16 Jul 2015 19:15:38 -0700, craig.sirna wrote:
The assignment wants us to take a users first, middle and last name in a
single input ( name=('enter your full name: )).
Then we must display the full name rearranged in Last, First Middle
order.
To generate a list of words from a string, split the string up on the
spaces between words. See the split method of strings.
Having a list of words, get a copy of the list in reverse order. See the
reversed function (and maybe the list function).
That won't really help, because the desired order is, with the example
the OP used: Sirna Daniel Craig. So here indexing is necessary, but
indexing of the list elements, not of the characters in the string.
(Necessary is too strong, because this could be done with rpartition.
But I doubt that's the right answer for a beginner course.)
--
https://mail.python.org/mailman/listinfo/python-list
[issue24660] Heapq + functools.partial : TypeError: unorderable types
Марк Коренберг added the comment: Exactly the same with bound class methods -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24660 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23883] __all__ lists are incomplete
Martin Panter added the comment: That raiseExecptions thing looks like a typo to me. The code should probably be monkey patching the module variable, and restoring it after the test. Then you wouldn’t need to add your extra typoed version to the blacklist. In the logging module, I reckon raiseExceptions (non-typoed) should actually be added to __all__. It is documented under Handler.handleError(). pickletools.OpcodeInfo: It is briefly mentioned as the type of the first item of genops(). I don’t have a strong opinion, but I tended to agree with your previous patch which added it to __all__. threading.ThreadError: It is not documented, but it was already in __all__. I think it should be restored, in case someone’s code is relying on it. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23883 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24656] remove assret from mock error checking
Changes by Ethan Furman et...@stoneleaf.us: -- stage: - patch review type: - behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24656 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10716] Modernize pydoc to use better HTML and separate CSS
Frédéric Jolliton added the comment: Oh god. The HTML produced by pydoc is awful. This is absolutely nothing modern about it. The code itself hurts my brain. It feels very old (14 years old..), and the HTML production is overly complex, and hard to check regarding correct quoting/escaping. Generating modern HTML5/CSS would mean: - Using h1, h2, for section title, - Forget about br (this element should never be used nowadays), - Forget about hr (let the CSS decide when to insert a visual separator after/before a given element), - Don't use code for block of code. This is an inline element. Use pre class=code for example. - Don't use table all over the place for formatting everything (use li for the list of modules for instance), - Drop these useless dd/dd (empty!) - No need to replace \n by br, or to replace space by nbsp;. The formatting can be achieved by white-space: pre in CSS. - a name=.. or a id=.. could be replaced by span id=.. class=.. to distinguish them from hyperlinks. - the table docclass could be a serie of h2 (or h3) title followed by the content of the section. The table seems useless because there are no particular requirement for an alignment. - and so on, and so on, .. Actually, I think this need a complete rewrite. This is a useful tool to have included with Python, but this need a serious refresh. To me, a modern documentation is something like this (from the Rust documentation): https://doc.rust-lang.org/std/option/enum.Option.html https://doc.rust-lang.org/std/option/index.html (Look at the generated HTML too. It's rather straightforward.) -- nosy: +Frédéric Jolliton ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10716 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24664] build failure with _Py_BEGIN_SUPPRESS_IPH undefined
Steve Dower added the comment: I was going to guess it was timemodule.c. You need to make distclean or hg purge to clean up your repo. This seems to be some sort of gcc/configure issue. So far everyone else who has seen this has fixed it by cleaning their repo. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24664 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: A new module for performing tail-call elimination
Terry Reedy wrote: Problems with branching recursion (multiple recursive calls per call) are rare except for very deep trees and graphs. And if your recursion is branching, tail calls won't help you, except in certain special cases (such as the quicksort example) where you can predict in advance which branches are safe to recurse down. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: A new module for performing tail-call elimination
Marko Rauhamaa wrote: At any rate, it demonstrates how the idiom has its place in Python. Perhaps it does, but I think I'd still prefer it to be explicit. The call in Marko's example is not actually a tail call as written. To make it a tail call, a return would need to be added: return child.setvalue(keyseq, value, offset + 1) To someone reading the code, it's not obvious why the return is there. It looks redundant, and is likely to get removed by someone who thinks it's a mistake. Using a dedicated keyword would make it clear that tail call behaviour is being relied upon, and avoid looking like a spurious return. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
[issue24206] Issues with equality of inspect objects
Roundup Robot added the comment: New changeset 5ec2bfbe8115 by Serhiy Storchaka in branch '3.4': Issue #24206: Fixed __eq__ and __ne__ methods of inspect classes. https://hg.python.org/cpython/rev/5ec2bfbe8115 New changeset 66a5f66b4049 by Serhiy Storchaka in branch '3.5': Issue #24206: Fixed __eq__ and __ne__ methods of inspect classes. https://hg.python.org/cpython/rev/66a5f66b4049 New changeset adc9869c6d0d by Serhiy Storchaka in branch 'default': Issue #24206: Fixed __eq__ and __ne__ methods of inspect classes. https://hg.python.org/cpython/rev/adc9869c6d0d -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24206 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24407] Use after free in PyDict_merge
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com: -- nosy: +Arfrever ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24407 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24664] build failure with _Py_BEGIN_SUPPRESS_IPH undefined
Mark Lawrence added the comment: There is a reference in the patch file to #23524. -- nosy: +BreamoreBoy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24664 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24664] build failure with _Py_BEGIN_SUPPRESS_IPH undefined
Zbyszek Jędrzejewski-Szmek added the comment:
Oh, for the record, the build failure:
building 'time' extension
gcc -pthread -fPIC -Wno-unused-result -Wsign-compare -Wunreachable-code
-DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes
-Werror=declaration-after-statement -I../Include -I. -IInclude
-I/usr/local/include -I/home/zbyszek/python/cpython/Include
-I/home/zbyszek/python/cpython/build -c
/home/zbyszek/python/cpython/Modules/timemodule.c -o
build/temp.linux-x86_64-3.6/home/zbyszek/python/cpython/Modules/timemodule.o
/home/zbyszek/python/cpython/Modules/timemodule.c: In function ‘time_strftime’:
/home/zbyszek/python/cpython/Modules/timemodule.c:656:9: error: unknown type
name ‘_Py_BEGIN_SUPPRESS_IPH’
_Py_BEGIN_SUPPRESS_IPH
^
/home/zbyszek/python/cpython/Modules/timemodule.c:656:9: error: ISO C90 forbids
mixed declarations and code [-Werror=declaration-after-statement]
/home/zbyszek/python/cpython/Modules/timemodule.c:658:9: error:
‘_Py_END_SUPPRESS_IPH’ undeclared (first use in this function)
_Py_END_SUPPRESS_IPH
^
/home/zbyszek/python/cpython/Modules/timemodule.c:658:9: note: each undeclared
identifier is reported only once for each function it appears in
/home/zbyszek/python/cpython/Modules/timemodule.c:662:9: error: expected ‘;’
before ‘if’
if (buflen 0 || i = 256 * fmtlen) {
^
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24664
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Noob in Python. Problem with fairly simple test case
On Friday, July 17, 2015 at 3:39:02 PM UTC-5, Laura Creighton wrote: I think kivy is doing a very nice job of python-on-the-mobile. Have you looked? Please do not rant at me, just tell me what you think. Hello Laura, I'm not sure if you're replying to me (as there is no quoted context) but since you mentioned rant i suppose that you could be referring be me? I mean, i don't know what gave you the impression that i would rant at anyone? But don't worry dear, i've always self-censored my rants when females are listening -- oops, gonna get some flac for that comment! O:-) First off. I don't remember seeing you here before. So allow me to say that having a female presence in this group is quite refreshing. I hope you continue to participate! Also, I have a lot to say on this subject, and most of what i say below is intended as a general response, so please don't take any of my words as a personal attack. Thanks. Regarding Kivy I was not aware of this project until you mentioned it. However, i'm skeptical because: (1) it will suffer from latency issues, especially on the mobile platforms, and (2) but even if not, i feel projects like this are only encouraging the stagnation of our evolution towards multi-device compatibility. The road to enlightenment is paved with introspection For the last few decades we have been consumed with the task of bringing multi-platform-ism to every language or API or software or whatever. And this was a noble pursuit indeed! HOWEVER, We are now moving into a new age. Not of cross-platform-ism (where we want to write code *ONCE* and have it run on Linux, Windows, and Mac) but were we want to write code *ONCE* and have it run on a desktop, or a notebook, or a phone, or a watch, or a refrigerator, or even a HUD in our spaceship! I believe it's high time that we move away from religious ideologies codified in selfish syntaxes and selfish interfaces. Because, we seek out these segregating policies just so we can say hey, we're different, when in reality, we're all the same underneath. For example: printing to stdout is printing to stdout - no matter what syntax you choose to use. Likewise, iterating over a collection of items, or creating an object that implements the OOP paradigm, or writing a stream into a storage medium - the fundamentals of these concepts do not change simply by plastering them with selfish identities. Neither is the concept of a GUI window any different if that window was created in Windows, Linux, or Mac. I could provide example after example (ad nauseum) of how we're creating these selfish syntaxes and selfish interface, but i think you get the point. This need to fulfill the underlying selfish desires that we, as humans harbor, is preventing us (as programmers, software engineers, hardware producers, and most importantly - end users) from reaching computing Nirvana. No programmer should ever need to re-write the same code numerous times so that it can run on multiple devices. We, are injecting needless superfluity into this system. And for no more reason than our need to fulfill selfish desires! Why are we *NOT* working together to create a single, linear, and scaleable system of producing software, A system that compiles all the best ideas, and throws the remainder into the refuse bin of history. The only system i've seen that has made *ANY* attempt (as feeble as it may be) is DHTML. But even with it's modern look and feel, it lacks the necessary hooks into the diverse platforms to get any real work done. However, utilizing the Trojan horse of browser ubiquity, and expanding on it, may be much less work than rebuilding the entire system from the ground up (something to ponder...) Most of what we're doing, in the programming language design field, is fighting over who's version of superficial CSS is going to be the official version. Our partisan efforts are merely adolescent accessorizing. But we lack the introspective ability to notice the vanity and futility of our efforts. If you want to know why i rant so much, it's because i'm both saddened and angry that we waste our time on these petty battles. When, in fact, we could achieve greatness by working towards a common goal. Utopia's eventually fail Rick! I'm aware of that! I'm aware that conflict is the invisible force that breathes life into the cogs of evolution. But your superficial understanding of my proposal is not a failure of my proposal. ON THE CONTRARY! For example. We can *ALL* remember how every cell phone manufacture had their own selfish implementation of a charging port. Heck, every time you
[issue24656] remove assret from mock error checking
Changes by Berker Peksag berker.pek...@gmail.com: -- nosy: +kushal.das, ncoghlan, rbcollins ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24656 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24641] Log type of unserializable value when raising JSON TypeError
Bob Ippolito added the comment: This seems like a very reasonable proposal. It would be great if we could also include a path in the error message (e.g. `obj[foo][1][bar]`) as well to provide enough context to track down the error quickly. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24641 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24206] Issues with equality of inspect objects
Changes by Serhiy Storchaka storch...@gmail.com: -- assignee: - serhiy.storchaka resolution: - fixed stage: patch review - resolved status: open - closed versions: +Python 3.4, Python 3.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24206 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24568] Misc/NEWS: free-after-use - use-after-free
Arfrever Frehtes Taifersar Arahesis added the comment: Still not fixed. -- nosy: +Arfrever, benjamin.peterson resolution: fixed - stage: resolved - status: closed - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24568 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24655] _ssl.c: Missing do for do {} while(0) idiom
Changes by Berker Peksag berker.pek...@gmail.com: -- stage: commit review - resolved ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24655 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: A new module for performing tail-call elimination
Marko Rauhamaa wrote: I don't know how recursion makes a difference It makes a difference because people don't expect frames to disappear from tracebacks when they're not consciously doing recursion. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
[issue10716] Modernize pydoc to use better HTML and separate CSS
Alex Walters added the comment: Isn't this whats sphinx's apidoc is for? -- nosy: +tritium ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10716 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
RE: Need assistance
Hi Laura, There are edge cases where this may fail (and let's see if Craig catches this on his own). Cheers, Joseph -Original Message- From: Python-list [mailto:python-list-bounces+joseph.lee22590=gmail@python.org] On Behalf Of Laura Creighton Sent: Saturday, July 18, 2015 5:16 AM To: Sibylle Koczian nulla.epist...@web.de Cc: python-list@python.org; l...@openend.se Subject: Re: Need assistance You don't have to index them. You can unpack them into a tuple of first, middle, last Laura (who is trying not to do somebody's homework for them, since I'm not the person who needs to learn this). -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
[issue24642] Will there be an MSI installer?
Roundup Robot added the comment: New changeset 9f60ec6d6586 by Steve Dower in branch '3.5': Issue #24642: Improves help text displayed in the Windows installer. https://hg.python.org/cpython/rev/9f60ec6d6586 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24642 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Need assistance
On 18/07/2015 18:34, Mark Lawrence wrote:
What is an {HP calculator} roll operation?
HP calculators were proper in that they used RPN entry.
i.e. 2 enter 2 + would show 4 instead of 2 + 2 =
Gawd it's so long but ISTR there were 3 stack registers and the display.
So you could press
1 enter
2 enter
3 enter
4
and Z = 1, Y = 2, X = 3 and display = 4. Roll would rotate the entries
through the display register.
ROLL and Z = 2, Y = 3, X = 4 and display = 1
and so on. There was an INV ROLL to go the other way.
The 3 level stack was equivalent to nesting parentheses three times. I
only had a TI-59 as it was half the price of an HP67. The TI had more
memories and program steps and was faster. But it didn't say HP on the
front!
--
https://mail.python.org/mailman/listinfo/python-list
[issue24659] dict() built-in fails on iterators with a keys attribute
Christian Barcenas added the comment: I'm aware of duck typing but I don't think this is the right place for it. (Although ABCs are ostensibly a kind of duck typing, as they do not require implementing classes to inherit from the ABC.) As Martin noticed, the glossary directly defines a mapping as a class that implements the Mapping ABC, and likewise the definition of an iterable under the glossary would satisfy the Iterable ABC. I think this is not just a documentation issue: the quack of a mapping has been well-defined and consistent since Python 2.7. Same for iterables. (It is worth noting that 2.6's definition of mapping was indeed just any object with a __getitem__ method https://docs.python.org/2.7/glossary.html#term-mapping) I think the documentation for the dict() constructor should say how to ensure the iterable and mapping modes are triggered. Doesn't it do this already by referencing the definitions of iterable and mapping? These ABCs are used in other built-ins such as any() and eval(). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24659 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Need assistance
On 18/07/2015 17:18, Dennis Lee Bieber wrote:
On Sat, 18 Jul 2015 14:16:11 +0200, Laura Creighton l...@openend.se
declaimed the following:
You don't have to index them. You can unpack them into a tuple
of first, middle, last
Laura (who is trying not to do somebody's homework for them, since
I'm not the person who needs to learn this).
That only works if the input IS three names (My Birth Certificate reads
Dennis Lee James Bieber; and I often used to include my confirmation name
into the thing; I've grown out of that phase but do still sometimes use
dljjb as initials).
This https://www.python.org/dev/peps/pep-3132/ might be handy in this case.
Simple .split() and a {HP calculator} roll operation should get the
desired order.
What is an {HP calculator} roll operation?
--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.
Mark Lawrence
--
https://mail.python.org/mailman/listinfo/python-list
[issue24663] ast.literal_eval does not handle empty set literals
Ezio Melotti added the comment: I believe this is by design, since set() -- like str(), list(), dict(), etc -- is not a literal. I don't think set() should be special-cased either. Perhaps you could tell us more about your use case? -- nosy: +ezio.melotti resolution: - not a bug status: open - pending ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24663 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24663] ast.literal_eval does not handle empty set literals
Changes by Ezio Melotti ezio.melo...@gmail.com: -- stage: - resolved ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24663 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Need assistance
On 18/07/2015 20:10, Joel Goldstick wrote:
On Sat, Jul 18, 2015 at 2:51 PM, mm0fmf via Python-list
python-list@python.org wrote:
On 18/07/2015 18:34, Mark Lawrence wrote:
What is an {HP calculator} roll operation?
HP calculators were proper in that they used RPN entry.
i.e. 2 enter 2 + would show 4 instead of 2 + 2 =
Gawd it's so long but ISTR there were 3 stack registers and the display. So
you could press
1 enter
2 enter
3 enter
4
and Z = 1, Y = 2, X = 3 and display = 4. Roll would rotate the entries
through the display register.
ROLL and Z = 2, Y = 3, X = 4 and display = 1
and so on. There was an INV ROLL to go the other way.
The 3 level stack was equivalent to nesting parentheses three times. I only
had a TI-59 as it was half the price of an HP67. The TI had more memories
and program steps and was faster. But it didn't say HP on the front!
I have an hp35. But to be 'really' cool you have to have an hp35 that
just says hp. Those were the very first ones
I want a real HP16C and have been tempted to buy one from eBay.
--
https://mail.python.org/mailman/listinfo/python-list
[issue24663] ast.literal_eval does not handle empty set literals
Filip Haglund added the comment: Okey, then this is not a bug. I can just handle this special case myself. Thanks! -- status: pending - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24663 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24664] build failure with _Py_BEGIN_SUPPRESS_IPH undefined
New submission from Zbyszek Jędrzejewski-Szmek: I'm not sure if I'm doing something wrong, because other people should be seeing this too... Anyway, attached patch fixes the issue for me. -- components: Interpreter Core, Library (Lib) files: 0001-Always-define-_Py_-_SUPPRESS_IPH-macros.patch keywords: patch messages: 246910 nosy: zbysz priority: normal severity: normal status: open title: build failure with _Py_BEGIN_SUPPRESS_IPH undefined versions: Python 3.6 Added file: http://bugs.python.org/file39947/0001-Always-define-_Py_-_SUPPRESS_IPH-macros.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24664 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24655] _ssl.c: Missing do for do {} while(0) idiom
Roundup Robot added the comment: New changeset 24cf6b4d72c2 by Benjamin Peterson in branch '3.4': improve style of the convert macro (#24655) https://hg.python.org/cpython/rev/24cf6b4d72c2 New changeset bffa3b5fd2d8 by Benjamin Peterson in branch '3.5': merge 3.4 (#24655) https://hg.python.org/cpython/rev/bffa3b5fd2d8 New changeset 35d6606b2480 by Benjamin Peterson in branch 'default': merge 3.5 (#24655) https://hg.python.org/cpython/rev/35d6606b2480 New changeset e4f9562d625d by Benjamin Peterson in branch '2.7': improve style of the convert macro (#24655) https://hg.python.org/cpython/rev/e4f9562d625d -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24655 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24655] _ssl.c: Missing do for do {} while(0) idiom
Changes by Benjamin Peterson benja...@python.org: -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24655 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Need assistance
On Sat, Jul 18, 2015 at 2:51 PM, mm0fmf via Python-list
python-list@python.org wrote:
On 18/07/2015 18:34, Mark Lawrence wrote:
What is an {HP calculator} roll operation?
HP calculators were proper in that they used RPN entry.
i.e. 2 enter 2 + would show 4 instead of 2 + 2 =
Gawd it's so long but ISTR there were 3 stack registers and the display. So
you could press
1 enter
2 enter
3 enter
4
and Z = 1, Y = 2, X = 3 and display = 4. Roll would rotate the entries
through the display register.
ROLL and Z = 2, Y = 3, X = 4 and display = 1
and so on. There was an INV ROLL to go the other way.
The 3 level stack was equivalent to nesting parentheses three times. I only
had a TI-59 as it was half the price of an HP67. The TI had more memories
and program steps and was faster. But it didn't say HP on the front!
I have an hp35. But to be 'really' cool you have to have an hp35 that
just says hp. Those were the very first ones
--
Joel Goldstick
http://joelgoldstick.com
--
https://mail.python.org/mailman/listinfo/python-list
[issue24665] CJK support for textwrap
New submission from Serhiy Storchaka: This is new feature and can be added only in 3.6. Issue12499 looks related. See also issue12568. -- nosy: +georg.brandl, pitrou, serhiy.storchaka versions: +Python 3.6 -Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24665 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Should non-security 2.7 bugs be fixed?
On Sunday, July 19, 2015 at 8:04:20 AM UTC+5:30, Devin Jeanpierre wrote: On Sat, Jul 18, 2015 at 6:34 PM, Terry Reedy wrote: On 7/18/2015 8:27 PM, Mark Lawrence wrote: On 19/07/2015 00:36, Terry Reedy wrote: Programmers don't much like doing maintainance work when they're paid to do it, so why would they volunteer to do it? Right. So I am asking: if a 3.x user volunteers a 3.x patch and a 3.x core developer reviews and edits the patch until it is ready to commit, why should either of them volunteer to do a 2.7 backport that they will not use? Because it helps even more people. The reason people make upstream contributions is so that the world benefits. If you only wanted to help yourself, you'd just patch CPython locally, and not bother contributing anything upstream. I am suggesting that if there are 10x as many 2.7only programmers as 3.xonly programmers, and none of the 2.7 programmers is willing to do the backport *of an already accepted patch*, then maybe it should not be done at all. That just isn't true. I have backported 3.x patches. Other people have backported entire modules. It gets really boring submitting 2.7-specific patches, though, when they aren't accepted, and the committers have such a hostile attitude towards it. I was told by core devs that, instead of fixing bugs in Python 2, I should just rewrite my app in Python 3. It has even been implied that bugs in Python 2 are *good*, because that might help with Python 3 adoption. Then even if you do the work to fix *ANY* bug there is no guarantee that it gets committed. I am discussing the situation where there *is* a near guarantee (if the backport works and does not break anything and has not been so heavily revised as to require a separate review). That is not how I have experienced contribution to CPython. No, the patches are *not* guaranteed, and in my experience they are not likely to be accepted. If the issue was closed as fixed before I contributed the backported patch, does anyone even see it? Not to mention actively hostile attitude to discussions that could at the moment be tangential to current CPython. See (and whole thread) https://mail.python.org/pipermail/python-ideas/2015-May/033708.html JFTR: My kids (um... students) have just managed to add devanagari numerals to python. ie we can now do १ + २ 3 [The devanagari equivalent of 12334567890 is १२३४५६७८९० And also for those who may not be familiar, devanagari is the script for sanskrit, hindi and a slew of (north) Indian languages ] Regarding this as a fork of python is technically (legalistically) correct but pragmatically ridiculous [unless my students spell as 'Linus Torvalds' or somethin...]. Note that while I dont regard that specific answer as representative of the python-community at large, it is also true that a little help -- even brusque RTFM answers¹ -- would have seen us farther than If this is what you are up to, get out of here tl;dr: Not so much a complaint but a indicator that people who could potentially contribute are being prevented from entering -- ¹ For me, RTFM is always welcome if accompanied by which FM -- https://mail.python.org/mailman/listinfo/python-list
Re: Should non-security 2.7 bugs be fixed?
On Saturday, July 18, 2015 at 10:52:51 PM UTC-5, Rustom Mody wrote: tl;dr: Not so much a complaint but a indicator that people who could potentially contribute are being prevented from entering EXACTLY! If this community fails, it won't be due to old members walking out of the back door, no, it will be because the front door was slammed shut and nails were driven into the frame, preventing new members from entering! We are not in a freaking zombie movie people! We're in a freaking community! And communities require doors to be unlocked during business hours. Communities require welcome mats. But mostly of all, communities require hospitality. -- https://mail.python.org/mailman/listinfo/python-list
Re: Should non-security 2.7 bugs be fixed?
On Sun, 19 Jul 2015 12:33 pm, Devin Jeanpierre wrote: [...] Because it helps even more people. The reason people make upstream contributions is so that the world benefits. If you only wanted to help yourself, you'd just patch CPython locally, and not bother contributing anything upstream. And have your patch disappear when you upgrade Python? No thanks. [...] It gets really boring submitting 2.7-specific patches, though, when they aren't accepted, and the committers have such a hostile attitude towards it. I was told by core devs that, instead of fixing bugs in Python 2, I should just rewrite my app in Python 3. Really? Can you point us to this discussion? If you are right, and that was an official pronouncement, then it seems that non-security bug fixes to 2.7 are forbidden. I suspect though that it's not quite that black and white. Perhaps there was some doubt about whether or not the patch in question was fixing a bug or adding a feature (a behavioural change). Or the core dev in question was speaking for themselves, not for all. It has even been implied that bugs in Python 2 are *good*, because that might help with Python 3 adoption. Really? Can you point us to this discussion? As they say on Wikipedia, Citation Needed. I would like to see the context before taking that at face value. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
[issue24666] Buffered I/O does not take file position into account when reading blocks
Changes by Serhiy Storchaka storch...@gmail.com: -- nosy: +benjamin.peterson, pitrou, stutzbach ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24666 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Integers with leading zeroes
In Python 2, integer literals with leading zeroes are treated as octal, so 09 is a syntax error and 010 is 8. This is confusing to those not raised on C-style octal literals, so in Python 3 leading zeroes are prohibited in int literals. Octal is instead written using the prefix 0o, similar to hex 0x and binary 0b. Consequently Python 3 makes both 09 and 010 a syntax error. However there is one exception: zero itself is allowed any number of leading zeroes, so 0 is a legal way to write zero as a base-10 int literal. Does anyone use that (mis)feature? -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Integers with leading zeroes
On Sat, Jul 18, 2015 at 11:39 PM, Steven D'Aprano st...@pearwood.info wrote: In Python 2, integer literals with leading zeroes are treated as octal, so 09 is a syntax error and 010 is 8. This is confusing to those not raised on C-style octal literals, so in Python 3 leading zeroes are prohibited in int literals. Octal is instead written using the prefix 0o, similar to hex 0x and binary 0b. Consequently Python 3 makes both 09 and 010 a syntax error. However there is one exception: zero itself is allowed any number of leading zeroes, so 0 is a legal way to write zero as a base-10 int literal. It's obviously a base-8 literal, not a base-10 literal. :-P Does anyone use that (mis)feature? I don't, but why should it matter? -- https://mail.python.org/mailman/listinfo/python-list
Re: Proposed keyword to transfer control to another function
On Saturday, July 18, 2015 at 9:18:32 AM UTC+5:30, Serhiy Storchaka wrote: On 17.07.15 02:46, Chris Angelico wrote: Out of the lengthy thread on tail call optimization has come one broad theory that might be of interest, so I'm spinning it off into its own thread. The concept is like the Unix exec[vlpe] family of functions: replace the current stack frame with a new one. This can be used for explicit tail recursion without repeated stack frames, or for a pre-check that then disappears out of the stack. Like any other feature, it can be misused to make debugging difficult, but among consenting adults, hopefully it can be used sensibly. I think there is no chance that this proposition will be accepted by Guido, because it makes debugging harder. I personally thought Chris was being tongue-in-cheek with this suggestion. Taking it more seriously, here are some thoughts. Given: 1. A new keyword is a more deep change than a new optimzation flag 2. The tail-call site is (arguably!) more crucial than the tail-call So why not have a tco decorator such that @tco def foo(...): body will have tail-calls in body optimized? My guess is that someone who knows enough of python's code generator may even be able to do it in pure python; ie with no change to the language in foo.__code__.co_code, replace code of the form ... call; ret... with ...goto... -- https://mail.python.org/mailman/listinfo/python-list
Re: Should non-security 2.7 bugs be fixed?
Terry Reedy tjre...@udel.edu writes: I am suggesting that if there are 10x as many 2.7only programmers as 3.xonly programmers, and none of the 2.7 programmers is willing to do the backport *of an already accepted patch*, then maybe it should not be done at all. The patch acceptance/approval process is frankly daunting. -- https://mail.python.org/mailman/listinfo/python-list
Re: Should non-security 2.7 bugs be fixed?
On Sunday, July 19, 2015 at 9:16:08 AM UTC+5:30, Paul Rubin wrote: Terry Reedy writes: I am suggesting that if there are 10x as many 2.7only programmers as 3.xonly programmers, and none of the 2.7 programmers is willing to do the backport *of an already accepted patch*, then maybe it should not be done at all. The patch acceptance/approval process is frankly daunting. And it should be. Ive used python for some 15 years now and more than any particular language aspect or feature, the aspect that keeps it in my core tool box is its reliability: Mostly it does what I expect, and allowing a teacher to open the interpreter in a class and hack real-time on coding depends on a certain stability that I personally find very valuable. So I would like to make a distinction between *approvals* being daunting and *discussions* (for patches) being tolerated though (mostly) not being accepted. Of course I accept that this can be unrealistic: Having to email: Sorry -- Unacceptable can itself get out of hand if/when the number of well-meaning ignoramus suggestions crosses a threshold -- https://mail.python.org/mailman/listinfo/python-list
Devanagari int literals [was Re: Should non-security 2.7 bugs be fixed?]
On Sun, 19 Jul 2015 01:52 pm, Rustom Mody wrote:
Not to mention actively hostile attitude to discussions that could at the
moment be tangential to current CPython. See (and whole thread)
https://mail.python.org/pipermail/python-ideas/2015-May/033708.html
I stand by my comments there. I have no disagreement with your aim to build
a specialised language for teaching functional programming. I don't believe
that should be Python.
JFTR: My kids (um... students) have just managed to add devanagari
numerals to python.
ie we can now do
१ + २
3
That is actually quite awesome, and I would support a new feature that set
the numeric characters to a particular script, e.g. Latin, Arabic,
Devanagari, whatever, and printed them in that same script. It seems
unfortunate that १ + २ prints as 3 rather than ३.
Python already, and has for many years, supported non-ASCII digits in string
conversions. This is in Python 2.4:
py int(u'१२')
12
py float(u'.१२')
0.12
so the feature goes back a long time.
I think that Python should allow int and float literals using any sequences
of digits from the same language, e.g. 12 or १२ but not १2. One might have
an interpreter hook which displayed ints and floats using non-ASCII digits,
or one might even build that function into the intepreter, e.g. have a
global setting which tells ints and floats what digits to use, e.g.:
sys.setdigits('Devanagari')
I would support this, or something like this, as a language feature. If we
can write Python using Hindi identifiers, why not Hindi numerals?
Regarding this as a fork of python is technically (legalistically) correct
but pragmatically ridiculous [unless my students spell as 'Linus Torvalds'
or somethin...].
There's a grey area between a fork and a local patch. Ever fork begins as a
local patch. It only becomes a fork if you go public with it, give it a new
name, etc. Forks can be highly respected, e.g. Stackless is a fork of
CPython.
--
Steven
--
https://mail.python.org/mailman/listinfo/python-list
[issue24666] Buffered I/O does not take file position into account when reading blocks
New submission from Eric Pruitt: When buffering data from a file, the buffered I/O does not take into account the current file descriptor position. In the following example, I open a file and seek forward 1,000 bytes: f = open(test-file, rb) f.seek(1000) 1000 f.readline() The filesystem on which test-file resides has a block size of 4,096 bytes, so on the backend, I would expect Python to read 3,096 bytes so the next read will be aligned with the filesystem blocks. What actually happens is that Python reads a 4,096 bytes. This is the output from an strace attached to the interpreter above: Process 16543 attached lseek(4, 0, SEEK_CUR) = 0 lseek(4, 1000, SEEK_SET)= 1000 read(4, \000\000\000\000\000\000\000\000\000\000..., 4096) = 4096 -- components: IO messages: 246931 nosy: ericpruitt priority: normal severity: normal status: open title: Buffered I/O does not take file position into account when reading blocks type: behavior versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24666 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Devanagari int literals [was Re: Should non-security 2.7 bugs be fixed?]
On Sun, Jul 19, 2015 at 2:45 PM, Steven D'Aprano st...@pearwood.info wrote:
I think that Python should allow int and float literals using any sequences
of digits from the same language, e.g. 12 or १२ but not १2.
I would agree with this. Actually, given that int(१२) works just
fine, I was surprised that it didn't already work in syntax.
One might have
an interpreter hook which displayed ints and floats using non-ASCII digits,
or one might even build that function into the intepreter, e.g. have a
global setting which tells ints and floats what digits to use, e.g.:
sys.setdigits('Devanagari')
Easiest way to play with this would be a sys.displayhook, I think; I
suspect it would be problematic to change int.__str__ or int.__repr__.
But for interactive work, yep, definitely, it should be easy enough to
make int and float display appropriately.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: Should non-security 2.7 bugs be fixed?
Mark Lawrence breamore...@yahoo.co.uk writes: ... If the vast majority of Python programmers are focused on 2.7, why are volunteers to help fix 2.7 bugs so scarce? I have not done much work related to Python bug fixing. But, I had bad experience with other open source projects: many of my patches (and bug reports) have been ignored over decades. This caused me to change my attitude: I now report bugs (sometimes with patches) and publish a potential solution in a separate package (-- dm.zopepatches.*, dm.zodbpatches.*). This way, affected people can use a solution even if the core developpers don't care. From my point of view: if you want help with fixing bugs, you must ensure that there is a high probability that those contributions really find their way into the main development lines. As I understand from other messages in this thread, this is also a problem with Python bug fixing. Does they all consider it perfect (or sufficient) as is? I have not much blame for Python 2.7. I see a few minor points * pdb is quite weak - but I could fix some (but by far not all) aspects in dm.pdb. * https has been weakly handled in earlier versions, but someone has done the Python 3 backport work in an external package before the backport finally arrived in Python 2.7. Should the core developers who do not personally use 2.7 stop backporting, because no one cares if they do? I am grateful that the above mentioned https backport was finally integrated into Python 2.7 -- even though I find it acceptable to use an external package to get it. Thus, there are people who care. Of course, I will not tell core developers that they must do backporting. If they don't more external packages will come into existence which contain (unofficial) backports. -- https://mail.python.org/mailman/listinfo/python-list
Extending BaseHTTPServer The Easy Way
Here is the beginning of the README.md for https://github.com/J-Adrian-Zimmer/ProgrammableServer.git If you are a Python programmer wanting to set up a server for your own application, if you don't need a high volume, general purpose server and are put off by the complexities of Apache and BaseHTTPServer, then ProgrammableServer may be for you. It is easy to setup and, if necessary, reconfigure. With ProgrammableServer, you can create a simple or complex application whose demands on a web server are few. You do this by writing one or more expanders each of which handles a single kind of request. Writing an expander is made easier because you have a choice of mixins to include. An expander mixin consists of a few functions that provide an environment customized to your needs. -- https://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations/
Simplifying Subclassing of SimpleHTTPRequestHandler
If you are a Python programmer wanting to set up an open-source server for your own application, if you don't need a high volume, general purpose server and are put off by the complexities of Apache and BaseHTTPServer, then ProgrammableServer may be for you. It is easy to setup and, if necessary, reconfigure. With ProgrammableServer, you can create a simple or complex application whose demands on a web server are few. You do this by writing one or more *expanders* each of which handles a single kind of request. Writing an expander is made easier because you have a choice of mixins to include. An expander mixin consists of a few functions that provide an environment customized to your needs. See more at: https://github.com/J-Adrian-Zimmer/ProgrammableServer.git -- https://mail.python.org/mailman/listinfo/python-announce-list Support the Python Software Foundation: http://www.python.org/psf/donations/
[issue23054] ConnectionError: ('Connection aborted.', BadStatusLine(''''))
Chris Mattmann added the comment: Hi there, we are experiencing this in tika-python too, see: https://github.com/chrismattmann/tika-python/issues/44 -- nosy: +chrismattmann ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23054 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24568] Misc/NEWS: free-after-use - use-after-free
Roundup Robot added the comment: New changeset 669d6b5c1734 by Raymond Hettinger in branch '2.7': Issue #24568: fix typo. https://hg.python.org/cpython/rev/669d6b5c1734 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24568 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24568] Misc/NEWS: free-after-use - use-after-free
Changes by Raymond Hettinger raymond.hettin...@gmail.com: -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24568 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Proposed keyword to transfer control to another function
Chris Angelico wrote:
Possible alternate syntax:
transfer func[, (arg1, arg2, arg3)[, {'kw1': val1, 'kw2': val2}]]
This makes it very clear that this is NOT accepting an arbitrary
expression, but MUST be used with a single function and its arguments.
Downside: It doesn't look like a function call any more. Upside: It's
easy to parse.
Personally I'd be fine with your initial syntax, but
something else might be needed to get it past Guido.
He didn't like my 'cocall f()' construct in PEP 3152,
which is syntactically isomorphic to 'transfer f()'.
Is there anything that I've missed out in speccing this up? I've a
suspicion that this might turn out to be as complicated as 'yield
from' in all its handling of edge cases.
Presumably it would only work on functions implemented
in Python? It's no use discarding the Python stack frame
unless the C recursion in the ceval loop can be avoided
as well.
Current candidates:
transfer, goto, recurse, and anything else you suggest.
Another possibility is chain, which I've seen in some
contexts for an sh exec-like operation.
--
Greg
--
https://mail.python.org/mailman/listinfo/python-list
Re: Need assistance
On Jul 18, 2015, at 1:34 PM, Mark Lawrence breamore...@yahoo.co.uk wrote:
[byte]
What is an {HP calculator} roll operation?
The original Hewlett Packard “Scientific” calculators (HP-35, 45, 65, etc) that
used Polish notation (operand, operand, operation; with no “=“ sign) had a
stack. That stack itself could be manipulated (e.g., interchange X and Y). One
of the stack manipulation commands was “Roll” which moved the top entry into X
and pushed remaining elements up one. Later versions had both Roll-up and
Roll-down, Roll-down moved the X entry to the top of the stack and dropped the
other elements.
Bill (Who still uses an HP-45 emulator on his iPhone)
--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.
Mark Lawrence
--
https://mail.python.org/mailman/listinfo/python-list
--
https://mail.python.org/mailman/listinfo/python-list
[issue24656] remove assret from mock error checking
Ethan Furman added the comment: Addressed comments from berker.peksag. -- Added file: http://bugs.python.org/file39948/remove_assret.stoneleaf.03.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24656 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24659] dict() built-in fails on iterators with a keys attribute
Changes by Raymond Hettinger raymond.hettin...@gmail.com: -- assignee: docs@python - rhettinger nosy: +rhettinger ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24659 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: A new module for performing tail-call elimination
On 18/07/2015 23:39, Gregory Ewing wrote: Marko Rauhamaa wrote: At any rate, it demonstrates how the idiom has its place in Python. Perhaps it does, but I think I'd still prefer it to be explicit. The call in Marko's example is not actually a tail call as written. To make it a tail call, a return would need to be added: return child.setvalue(keyseq, value, offset + 1) To someone reading the code, it's not obvious why the return is there. It looks redundant, and is likely to get removed by someone who thinks it's a mistake. A time to use perhaps the most abused part of any programming language, a comment? Using a dedicated keyword would make it clear that tail call behaviour is being relied upon, and avoid looking like a spurious return. +1 -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
[issue8450] httplib: false BadStatusLine() raised
Martin Panter added the comment:
Issue 3566 has added a new exception subclass, RemoteDisconnected, in 3.5.
People are still complaining about the old BadStatusLine exception in Python 2
though. See Issue 23054.
Python 2 could still get better documentation of the BadStatusLine exception.
Currently it gives the impression that it only happens when the “strict”
parameter is True, and a status line was received that was not understood.
The exception message could also be improved. Due to Issue 7427, there is a
special case to make the message literally two quote signs (''), representing
an empty string. Perhaps messages like “End of stream signalled”, “No status
line”, or “Empty status line” would be clearer.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8450
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Should non-security 2.7 bugs be fixed?
On Sun, Jul 19, 2015 at 9:36 AM, Terry Reedy tjre...@udel.edu wrote: If the vast majority of Python programmers are focused on 2.7, why are volunteers to help fix 2.7 bugs so scarce? Does they all consider it perfect (or sufficient) as is? Should the core developers who do not personally use 2.7 stop backporting, because no one cares if they do? I use Linux on all my computers, but I wouldn't be volunteering to help fix kernel bugs, because I'm not competent to. I also compile C code now and then, but don't offer to fix GCC bugs. There may well be huge numbers of people who write Python code who don't feel they can contribute in that way (whether or not that's strictly true - after all, half of Python is written in Python anyway). ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Should non-security 2.7 bugs be fixed?
On 19/07/2015 00:36, Terry Reedy wrote: I asked the following as an off-topic aside in a reply on another thread. I got one response which presented a point I had not considered. I would like more viewpoints from 2.7 users. Background: each x.y.0 release normally gets up to 2 years of bugfixes, until x.(y+1).0 is released. For 2.7, released summer 2010, the bugfix period was initially extended to 5 years, ending about now. At the spring pycon last year, the period was extended to 10 years, with an emphasis on security and build fixed. My general question is what other fixes should be made? Some specific forms of this question are the following. If the vast majority of Python programmers are focused on 2.7, why are volunteers to help fix 2.7 bugs so scarce? Does they all consider it perfect (or sufficient) as is? Should the core developers who do not personally use 2.7 stop backporting, because no one cares if they do? Programmers don't much like doing maintainance work when they're paid to do it, so why would they volunteer to do it? Then even if you do the work to fix *ANY* bug there is no guarantee that it gets committed. The last Summary of Python tracker Issues over on python-dev giving 4947 open issues of which 2260 have patches speaks for itself. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Need assistance
On Sat, 18 Jul 2015 12:35:10 +0200, Sibylle Koczian wrote: Am 18.07.2015 um 02:40 schrieb Denis McMahon: Having a list of words, get a copy of the list in reverse order. See the reversed function (and maybe the list function). That won't really help, because the desired order is, with the example the OP used: Sirna Daniel Craig. So here indexing is necessary, but indexing of the list elements, not of the characters in the string. Oh, then it's even easier, yes, it's mainly a case of list indexing. 1) Split the original string into a list of words (string.split() method) 2) create a sublist (s1) of the last element 3) create another sublist (s2) of the first to penultimate elements 4) combine the two sublists 5) use the string.join() method to combine the sublist elements into a single string I think most pythonistas would probably combine steps 2 through 4 in a single line of code, possibly even steps 2 through 5. -- Denis McMahon, denismfmcma...@gmail.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Possibly Pythonic Tail Call Optimization (TCO/TRE)
Antoon Pardon wrote: It seems a bit strange that with the immense value that is given to stack frames, that these wouldn't be available somehow. There was discussion recently about the idea of providing access to the frame of a suspended generator, so that debuggers can inspect the stack of an asyncio task that's not currently running. The same mechanism ought to allow the state of an arbitrary generator to be examined. You'd need to explicitly ask for it, though -- it wouldn't appear in stack traces automatically. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: Noob in Python. Problem with fairly simple test case
On Friday, July 17, 2015 at 5:46:01 PM UTC-5, Terry Reedy wrote: But these relative numbers are, as near as I can tell, restricted to the english-speaking world, perhaps extended to the latin-1 based world. Anyone who wants unicode identifiers must use Python 3 (or a translated Python like ChinesePython). Anyone seriously working with Unicode will find 3.3+ more pleasant, if not required (especially on Windows). I'll have to admit you make a good point here. Although the argument is diminished by observing that Ruby is far more popular in Asia than Python. Python seems to be mainly a Scandinavian, European, and American toy. For the most part anyway. There are always exceptions to any rule. I mean, think about it: who besides Xah Lee has an Asian name here? And it's been years since we've heard from him! O:-D On Amazon, the first hit for 'Japanese Python' is Dive into Python 3 (Japanese edition). As near as I can tell, there is no Japanese edition for the original Dive into Python (2). As I remember, half the Python books I saw in Japan *3 years ago* were for Python 3. Overall, I suspect that Python 3 penetration is greater in Asia. I would agree with that assessment, simply because of the Unicode factor. But i don't believe it's a large audience. And don't get me wrong, i'm not wishing for the numbers to go one way or another. I just simply want to find the truth. Rick, I only care about porting of public libraries. Leave your private code in Python 2. Continue writing new code in Python 2 if you wish. I only object to those who pressure others to not port to or writes in Python 3. I don't want to pressure anyone in either direction. We, as the greater python community, did not vote to break backwards compatibility, it was dropped on us like an Acme anvil. But what we _can_ choose, is the version that suits our needs best. I have chosen to remain with 2.x. I encourage others to decide for themselves. I don't think pushing 3.x is any less evil than pushing 2.x -- unless the programmer is a python neophyte. In that case, go with 3.x. If you want to help 2.7 become better, we need people test and backport patches to 2.7. Since 2.x bugs me as much as 3.x seems to bug you, I am considering not backporting until someone volunteers to help. What do you need help with? Can you be more specific? Of course, a few people on this list are under the impression that i cannot write Python code unless Tkinter is imported first. I guess they think Tkinter is some sort of magic module that endows it's importer with mad skills (such as those i posses). Or, it could be that they're unwilling to give me any credit. Who knows? I never did participate in office politics anyway. I'm always too busy getting things done! Now my question for you or anyone else: If the vast majority of Python programmers are focused on 2.7, why are volunteers to help fix 2.7 bugs so scarce? Does they all consider it perfect (or sufficient) as is? Should the core developers who do not personally use 2.7 stop backporting, because no one cares if they do? My guess is that most have become disenfranchised. Perhaps some have moved to other languages. Perhaps some are surviving on old code annuities and don't need to work anymore. The number of programmers in this world is very small, and Python programmers represent a very small subset of _that_ small subset. Which means, small numerical losses can result in extreme damage to the intellectual fortitude of a community like ours. The days when the Python community could spare a few minds is over, -- as we have entered an era of Pythonic depression. Perhaps one day we'll look back on these tough times and tell fabulously exaggerated stories of how rugged individualism, and a pinch of community spirit, freed the world from the dark clutches of evil. HISTORY IS DEFINED BY THE WINNERS Let me know where i can be of assistance. It's always a great pleasure to make utter fools of my rivals. :-) -- https://mail.python.org/mailman/listinfo/python-list
[issue10716] Modernize pydoc to use better HTML and separate CSS
Changes by Raymond Hettinger raymond.hettin...@gmail.com: -- keywords: +easy -patch versions: +Python 3.6 -Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10716 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24568] Misc/NEWS: free-after-use - use-after-free
Changes by Raymond Hettinger raymond.hettin...@gmail.com: -- assignee: docs@python - rhettinger nosy: +rhettinger ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24568 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24656] remove assret from mock error checking
Michael Foord added the comment: -1 The whole thread is absurd. I'm travelling for europython and only have internet access on my phone until tomorrow at the earliest. On Saturday, 18 July 2015, Berker Peksag rep...@bugs.python.org wrote: Changes by Berker Peksag berker.pek...@gmail.com: -- nosy: +kushal.das, ncoghlan, rbcollins ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24656 ___ -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24656 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Proposed keyword to transfer control to another function
On Sun, Jul 19, 2015 at 9:32 AM, Gregory Ewing
greg.ew...@canterbury.ac.nz wrote:
Chris Angelico wrote:
Possible alternate syntax:
transfer func[, (arg1, arg2, arg3)[, {'kw1': val1, 'kw2': val2}]]
This makes it very clear that this is NOT accepting an arbitrary
expression, but MUST be used with a single function and its arguments.
Downside: It doesn't look like a function call any more. Upside: It's
easy to parse.
Personally I'd be fine with your initial syntax, but
something else might be needed to get it past Guido.
He didn't like my 'cocall f()' construct in PEP 3152,
which is syntactically isomorphic to 'transfer f()'.
Maybe it should get written up and rejected, then, to be something to
point to any time anyone advocates TCO.
Is there anything that I've missed out in speccing this up? I've a
suspicion that this might turn out to be as complicated as 'yield
from' in all its handling of edge cases.
Presumably it would only work on functions implemented
in Python? It's no use discarding the Python stack frame
unless the C recursion in the ceval loop can be avoided
as well.
Hmm. Conceptually, I'd like it to work like this:
def f(x):
return from g(x+1)
x = f(3)
# absolutely identical to
x = g(4)
Is it possible to strip away the current Python stack frame and
replace it with a C stack frame? That would be the most logical, if
it's viable. It'd also mean that other Python implementations are all
looking at things on the same footing. Obviously 'return from' (or
whatever keyword is used) would be valid only from a Python function,
but ideally it could chain to a function written in any form.
Current candidates:
transfer, goto, recurse, and anything else you suggest.
Another possibility is chain, which I've seen in some
contexts for an sh exec-like operation.
Hah, that brings me back! Chaining was attempted from a REXX batch
file. I never understood why typing the name of a batch file would do
a one-way chain/exec rather than a more logical call. Unix has that
much better.
Downside: The name chain is highly likely to exist in people's code.
I'm liking return from, as it's currently illegal, uses existing
keywords, and parallels with yield from. But as a term for
describing what happens, chain works well.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: A new module for performing tail-call elimination
On 2015-07-18 23:39, Gregory Ewing wrote: Marko Rauhamaa wrote: At any rate, it demonstrates how the idiom has its place in Python. Perhaps it does, but I think I'd still prefer it to be explicit. The call in Marko's example is not actually a tail call as written. To make it a tail call, a return would need to be added: return child.setvalue(keyseq, value, offset + 1) To someone reading the code, it's not obvious why the return is there. It looks redundant, and is likely to get removed by someone who thinks it's a mistake. Using a dedicated keyword would make it clear that tail call behaviour is being relied upon, and avoid looking like a spurious return. Of the current reserved words, the choice is between 'continue' and 'pass'. How clear is: continue child.setvalue(keyseq, value, offset + 1) ? I think the problem is that it reads like it's something to do with co-routines. -- https://mail.python.org/mailman/listinfo/python-list
Re: Should non-security 2.7 bugs be fixed?
On 7/18/2015 7:50 PM, Devin Jeanpierre wrote: Considering CPython is officially accepting performance improvements I was not exactly aware of that. to 2.7, surely bug fixes are also allowed? Of course, allowed. But should they be made, and if so, by who? I have contributed both performance improvements and bug fixes to 2.7. In my experience, the problem is not the lack of contributors, it's the lack of code reviewers. I understand the general problem quite well. But feeling that one would have to do a 2.7 backport after writing, editing, or reviewing a 3.x patch can discourage doing a review in the first place. I am at that point now with respect to Idle patches. I think this is something everyone should care about. The really great thing about working on a project like Python is that not only do you help the programmers who use Python, but also the users who use the software that those programmers create. Python 2.7 is important in the software ecosystem of the world. Fixing bugs and making performance improvements can sometimes significantly help the 1B people who use the software written in Python 2.7. -- Devin On Sat, Jul 18, 2015 at 4:36 PM, Terry Reedy tjre...@udel.edu wrote: I asked the following as an off-topic aside in a reply on another thread. I got one response which presented a point I had not considered. I would like more viewpoints from 2.7 users. Background: each x.y.0 release normally gets up to 2 years of bugfixes, until x.(y+1).0 is released. For 2.7, released summer 2010, the bugfix period was initially extended to 5 years, ending about now. At the spring pycon last year, the period was extended to 10 years, with an emphasis on security and build fixed. My general question is what other fixes should be made? Some specific forms of this question are the following. If the vast majority of Python programmers are focused on 2.7, why are volunteers to help fix 2.7 bugs so scarce? Does they all consider it perfect (or sufficient) as is? Should the core developers who do not personally use 2.7 stop backporting, because no one cares if they do? -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
[issue24661] CGIHTTPServer: premature unescaping of query string
Eric V. Smith added the comment: I would expect the cgi script to receive the unescaped values. Can you point to some reference that says otherwise? -- nosy: +eric.smith ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24661 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24664] build failure with _Py_BEGIN_SUPPRESS_IPH undefined
Changes by Zachary Ware zachary.w...@gmail.com: -- resolution: - not a bug stage: - resolved ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24664 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24664] build failure with _Py_BEGIN_SUPPRESS_IPH undefined
Zbyszek Jędrzejewski-Szmek added the comment: Indeed, make distclean fixes the problem. -- status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24664 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Should non-security 2.7 bugs be fixed?
I asked the following as an off-topic aside in a reply on another thread. I got one response which presented a point I had not considered. I would like more viewpoints from 2.7 users. Background: each x.y.0 release normally gets up to 2 years of bugfixes, until x.(y+1).0 is released. For 2.7, released summer 2010, the bugfix period was initially extended to 5 years, ending about now. At the spring pycon last year, the period was extended to 10 years, with an emphasis on security and build fixed. My general question is what other fixes should be made? Some specific forms of this question are the following. If the vast majority of Python programmers are focused on 2.7, why are volunteers to help fix 2.7 bugs so scarce? Does they all consider it perfect (or sufficient) as is? Should the core developers who do not personally use 2.7 stop backporting, because no one cares if they do? -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Should non-security 2.7 bugs be fixed?
Considering CPython is officially accepting performance improvements to 2.7, surely bug fixes are also allowed? I have contributed both performance improvements and bug fixes to 2.7. In my experience, the problem is not the lack of contributors, it's the lack of code reviewers. I think this is something everyone should care about. The really great thing about working on a project like Python is that not only do you help the programmers who use Python, but also the users who use the software that those programmers create. Python 2.7 is important in the software ecosystem of the world. Fixing bugs and making performance improvements can sometimes significantly help the 1B people who use the software written in Python 2.7. -- Devin On Sat, Jul 18, 2015 at 4:36 PM, Terry Reedy tjre...@udel.edu wrote: I asked the following as an off-topic aside in a reply on another thread. I got one response which presented a point I had not considered. I would like more viewpoints from 2.7 users. Background: each x.y.0 release normally gets up to 2 years of bugfixes, until x.(y+1).0 is released. For 2.7, released summer 2010, the bugfix period was initially extended to 5 years, ending about now. At the spring pycon last year, the period was extended to 10 years, with an emphasis on security and build fixed. My general question is what other fixes should be made? Some specific forms of this question are the following. If the vast majority of Python programmers are focused on 2.7, why are volunteers to help fix 2.7 bugs so scarce? Does they all consider it perfect (or sufficient) as is? Should the core developers who do not personally use 2.7 stop backporting, because no one cares if they do? -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: Need assistance
On 2015-07-18 19:28, William Ray Wing wrote:
On Jul 18, 2015, at 1:34 PM, Mark Lawrence breamore...@yahoo.co.uk wrote:
[byte]
What is an {HP calculator} roll operation?
The original Hewlett Packard “Scientific” calculators (HP-35, 45, 65, etc) that
used Polish notation (operand, operand, operation; with no “=“ sign) had a
stack.
FYI, Polish Notation is a prefix notation; the operation comes first.
What you're talking about is Reverse Polish Notation, where the
operation comes last.
That stack itself could be manipulated (e.g., interchange X and Y).
One of the stack manipulation commands was “Roll” which moved the top
entry into X and pushed remaining elements up one. Later versions had
both Roll-up and Roll-down, Roll-down moved the X entry to the top of
the stack and dropped the other elements.
Bill (Who still uses an HP-45 emulator on his iPhone)
--
https://mail.python.org/mailman/listinfo/python-list
[issue24659] dict() built-in fails on iterators with a keys attribute
Raymond Hettinger added the comment:
I'm aware of duck typing but I don't think this
is the right place for it.
The code for dicts is very old, stable, and unlikely to change. Also, the
logic of checking for .keys() is immortalized in the
collections.abc.MutableMapping update() method.
For the most part, consumers of iterables, sequences, and mappings are allowed
to use duct-typing (this is a feature of the language, not a bug).
The docs can be improved in a number of places. For example the docstring on
the dict constructor is out of sync with the dict.update() method:
print(dict.__doc__)
dict() - new empty dictionary
dict(mapping) - new dictionary initialized from a mapping object's
(key, value) pairs
dict(iterable) - new dictionary initialized as if via:
d = {}
for k, v in iterable:
d[k] = v
dict(**kwargs) - new dictionary initialized with the name=value pairs
in the keyword argument list. For example: dict(one=1, two=2)
print(dict.update.__doc__)
D.update([E, ]**F) - None. Update D from dict/iterable E and F.
If E is present and has a .keys() method, then does: for k in E: D[k] =
E[k]
If E is present and lacks a .keys() method, then does: for k, v in E: D[k]
= v
In either case, this is followed by: for k in F: D[k] = F[k]
In addition, the glossary entries for iterable, sequence, and mapping need to
be improved to distinguish between their somewhat vague use in a general sense
versus the specific meaning of isinstance(obj, Mapping). Unless the docs
specify a check for the latter, they almost always do some form of duck-typing
or a check for concrete built-in class or subclass.
Terms like mapping and sequence are often used somewhat generally both
inside and outside the Python world. Sometimes mapping is used in the
mathematic sense (pairing each member of the domain with each member of the
range), http://www.icoachmath.com/math_dictionary/mapping.html, and sometimes
in the sense of a subset of dict capabilities (i.e. has __getitem__ and keys).
The docs for PyMapping_Check() need to be updated to indicate the known
limitations of the check and to disambiguate it from isinstance(obj, Mapping).
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24659
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23054] ConnectionError: ('Connection aborted.', BadStatusLine(''''))
Martin Panter added the comment: There is hopefully a better RemoteDisconnected exception and documentation in 3.5, thanks to Issue 3566. In Python 2, I think this is the same as Issue 8450. -- resolution: - duplicate status: open - closed superseder: - httplib: false BadStatusLine() raised ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23054 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8450] httplib: false BadStatusLine() raised
Changes by Martin Panter vadmium...@gmail.com: -- components: +Documentation ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8450 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Should non-security 2.7 bugs be fixed?
On 7/18/2015 8:27 PM, Mark Lawrence wrote: On 19/07/2015 00:36, Terry Reedy wrote: I asked the following as an off-topic aside in a reply on another thread. I got one response which presented a point I had not considered. I would like more viewpoints from 2.7 users. Background: each x.y.0 release normally gets up to 2 years of bugfixes, until x.(y+1).0 is released. For 2.7, released summer 2010, the bugfix period was initially extended to 5 years, ending about now. At the spring pycon last year, the period was extended to 10 years, with an emphasis on security and build fixed. My general question is what other fixes should be made? Some specific forms of this question are the following. If the vast majority of Python programmers are focused on 2.7, why are volunteers to help fix 2.7 bugs so scarce? Does they all consider it perfect (or sufficient) as is? Should the core developers who do not personally use 2.7 stop backporting, because no one cares if they do? Programmers don't much like doing maintainance work when they're paid to do it, so why would they volunteer to do it? Right. So I am asking: if a 3.x user volunteers a 3.x patch and a 3.x core developer reviews and edits the patch until it is ready to commit, why should either of them volunteer to do a 2.7 backport that they will not use? I am suggesting that if there are 10x as many 2.7only programmers as 3.xonly programmers, and none of the 2.7 programmers is willing to do the backport *of an already accepted patch*, then maybe it should not be done at all. Then even if you do the work to fix *ANY* bug there is no guarantee that it gets committed. I am discussing the situation where there *is* a near guarantee (if the backport works and does not break anything and has not been so heavily revised as to require a separate review). -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Should non-security 2.7 bugs be fixed?
On Saturday, July 18, 2015 at 6:37:41 PM UTC-5, Terry Reedy wrote: If the vast majority of Python programmers are focused on 2.7, why are volunteers to help fix 2.7 bugs so scarce? Because newer code is always more buggy than older code (when both get significant attention that is). There were quite a few growing pains after Py3 was released. All of this required massive attention. This explains the hype for Py3. Does they all consider it perfect (or sufficient) as is? No, but it works, and it works without bug-fixing old repos. Should the core developers who do not personally use 2.7 stop backporting, because no one cares if they do? I think that would be an awful mistake. The last thing you want is rumors spreading that Python is buggy. Even if only Python2 becomes buggy, it's bugginess with affect Python3's reputation. TEAMLEADER: Should we use Python for project X? MEMBER1: I don't know, i heard Python was buggy??? MEMBER2: *AND* the community is fractured! Member3: Which begs the question: Which version is going be around in few years? MEMBER4: And what if his holiness decides to break compatibility again? MEMBER5: Perhaps this time he'll make print a method of some new stdout object! TEAMLEADER: Yup. Let's make this easy and go with Ruby. A bad reputation can ruin a language. I would warn against allowing any version of Python to become buggy. Security or otherwise. The future of Python is literally hanging by a thread. -- https://mail.python.org/mailman/listinfo/python-list
Re: Should non-security 2.7 bugs be fixed?
On Sat, Jul 18, 2015 at 6:34 PM, Terry Reedy tjre...@udel.edu wrote: On 7/18/2015 8:27 PM, Mark Lawrence wrote: On 19/07/2015 00:36, Terry Reedy wrote: Programmers don't much like doing maintainance work when they're paid to do it, so why would they volunteer to do it? Right. So I am asking: if a 3.x user volunteers a 3.x patch and a 3.x core developer reviews and edits the patch until it is ready to commit, why should either of them volunteer to do a 2.7 backport that they will not use? Because it helps even more people. The reason people make upstream contributions is so that the world benefits. If you only wanted to help yourself, you'd just patch CPython locally, and not bother contributing anything upstream. I am suggesting that if there are 10x as many 2.7only programmers as 3.xonly programmers, and none of the 2.7 programmers is willing to do the backport *of an already accepted patch*, then maybe it should not be done at all. That just isn't true. I have backported 3.x patches. Other people have backported entire modules. It gets really boring submitting 2.7-specific patches, though, when they aren't accepted, and the committers have such a hostile attitude towards it. I was told by core devs that, instead of fixing bugs in Python 2, I should just rewrite my app in Python 3. It has even been implied that bugs in Python 2 are *good*, because that might help with Python 3 adoption. Then even if you do the work to fix *ANY* bug there is no guarantee that it gets committed. I am discussing the situation where there *is* a near guarantee (if the backport works and does not break anything and has not been so heavily revised as to require a separate review). That is not how I have experienced contribution to CPython. No, the patches are *not* guaranteed, and in my experience they are not likely to be accepted. If the issue was closed as fixed before I contributed the backported patch, does anyone even see it? -- Devin -- https://mail.python.org/mailman/listinfo/python-list
[issue24665] CJK support for textwrap
Changes by Florent Gallaire fgalla...@gmail.com: -- components: Library (Lib) files: CJK.patch keywords: patch nosy: fgallaire priority: normal severity: normal status: open title: CJK support for textwrap type: enhancement versions: Python 2.7 Added file: http://bugs.python.org/file39949/CJK.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24665 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Should non-security 2.7 bugs be fixed?
On Sat, Jul 18, 2015 at 9:13 PM, Terry Reedy tjre...@udel.edu wrote: I understand the general problem quite well. But feeling that one would have to do a 2.7 backport after writing, editing, or reviewing a 3.x patch can discourage doing a review in the first place. I am at that point now with respect to Idle patches. I wonder if it would be worth the significant one-time effort to port IDLE to 2/3, so that future bugfixes/improvements don't require any extra effort than testing them with all versions. -- Zach -- https://mail.python.org/mailman/listinfo/python-list
