[issue18489] IDLE Unit test for SearchEngine.py
Terry J. Reedy added the comment: As with searchdialogbase tests, I get the following in the console every time I run the test file within idle. ''' can't invoke event command: application has been destroyed while executing event generate $w ThemeChanged (procedure ttk::ThemeChanged line 6) invoked from within ttk::ThemeChanged ''' This seems like a bug somewhere, but where? Why is ttk involved? When I applied the patch, the tests ran, but left two tk windows. I added the missing root.destroy() calls. I plan to separate the class methods that search a text widget into a separate test case (or more). 10 lines are not yet covered. 6 should be easy. -- assignee: - terry.reedy stage: - patch review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18489 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18489] IDLE Unit test for SearchEngine.py
Changes by Terry J. Reedy tjre...@udel.edu: Added file: http://bugs.python.org/file31369/18489-test_searchengine4.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18489 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18761] Fix internal doc references for the email package
Roundup Robot added the comment: New changeset 7a1534dba050 by Serhiy Storchaka in branch '3.3': Issue #18761: Improved cross-references in email documentation. http://hg.python.org/cpython/rev/7a1534dba050 New changeset 464eed5ddb2e by Serhiy Storchaka in branch 'default': Issue #18761: Improved cross-references in email documentation. http://hg.python.org/cpython/rev/464eed5ddb2e New changeset 062533327ad2 by Serhiy Storchaka in branch '2.7': Issue #18761: Improved cross-references in email documentation. http://hg.python.org/cpython/rev/062533327ad2 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18761 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18778] email docstrings and comments say about Unicode strings
New submission from Serhiy Storchaka: email docstrings and comments uses the Unicode string term and refer to the unicode() built-in. In 3.x this should be corrected to string and str(). Perhaps some code (for example coercing a charset name to Unicode) is not needed more. -- components: email messages: 195605 nosy: barry, r.david.murray, serhiy.storchaka priority: normal severity: normal stage: needs patch status: open title: email docstrings and comments say about Unicode strings type: behavior versions: Python 3.3, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18778 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18761] Fix internal doc references for the email package
Serhiy Storchaka added the comment: Thank you for the review. -- assignee: docs@python - serhiy.storchaka resolution: - fixed stage: patch review - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18761 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17400] ipaddress.is_private needs to take into account of rfc6598
Freek Dijkstra added the comment: I don't understand your remark I think it would be pretty surprising for ipaddress to return True if it's not a network operator running the query. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17400 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17400] ipaddress.is_private needs to take into account of rfc6598
Freek Dijkstra added the comment: Edit: could you rephrase? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17400 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5537] LWPCookieJar cannot handle cookies with expirations of 2038 or greater on 32-bit platforms
Alex Quinn added the comment: This bug still exists in Python 2.7.3 32-bit on Linux. I wonder if this might be because the patch (posted 2011-02-18) used utcfromtimestamp(). datetime.datetime.utcfromtimestamp(2**32) will fail on 32-bit systems. The bug does NOT exist in Python 2.7.3 32-bit on Windows (64-bit OS). == 32-BIT PYTHON ON 32-BIT LINUX -- $ python -c import sys, cookielib; print sys.version; print cookielib.time2isoz(2322923767) 2.7.3 (default, Apr 10 2013, 05:46:21) [GCC 4.6.3] Traceback (most recent call last): File string, line 1, in module File /usr/lib/python2.7/cookielib.py, line 99, in time2isoz year, mon, mday, hour, min, sec = time.gmtime(t)[:6] ValueError: timestamp out of range for platform time_t == == 64-BIT PYTHON ON 64-BIT LINUX -- $ python -c import sys, cookielib; print sys.version; print cookielib.time2isoz(2322923767) 2.7.3 (default, Aug 3 2012, 17:21:07) [GCC 4.1.2 20080704 (Red Hat 4.1.2-52)] 2043-08-11 16:36:07Z == == 32-BIT PYTHON ON 64-BIT WINDOWS -- C:\python -c import sys, cookielib; print sys.version; print cookielib.time2isoz(2322923767) 2.7.3 (default, Apr 10 2012, 23:31:26) [MSC v.1500 32 bit (Intel)] 2043-08-11 16:36:07Z == -- nosy: +Alex Quinn Added file: http://bugs.python.org/file31370/monkey_patch_cookielib_time2isoz.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5537 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5537] LWPCookieJar cannot handle cookies with expirations of 2038 or greater on 32-bit platforms
Alex Quinn added the comment: For those who are affected by this bug, here's a snippet to monkey-patch cookielib on any Python 2.4 to 2.7. A more complete version of this was attached to my message a moment ago. == import cookielib try: cookielib.time2isoz(2**32) except ValueError: from datetime import datetime, timedelta def time2isoz(t=None): if t is None: dt = datetime.now() else: dt = datetime.utcfromtimestamp(0) + timedelta(seconds=int(t)) return %04d-%02d-%02d %02d:%02d:%02dZ%\ (dt.year, dt.month, dt.day, dt.hour, dt.minute, dt.second) cookielib.time2isoz = time2isoz == -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5537 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18779] Misleading documentations and comments in regular expression about alphanumerics and underscore
New submission from Vajrasky Kok:
According to:
http://oald8.oxfordlearnersdictionaries.com/dictionary/alphanumeric
http://en.wikipedia.org/wiki/Alphanumeric
Alphanumeric is defined as [A-Za-z0-9]. Underscore (_) is not one of them. One
of the documentation in Python (Doc/tutorial/stdlib2.rst) differentiates them
very clearly:
The format uses placeholder names formed by ``$`` with valid Python identifiers
(alphanumeric characters and underscores). Surrounding the placeholder with
braces allows it to be followed by more alphanumeric letters with no intervening
spaces. Writing ``$$`` creates a single escaped ``$``::
Yet, in documentations as well as comments in regex, we implicitely assumes
underscore belongs to alphanumeric.
Explicit is better than implicit!
Attached the patch to differentiate alphanumeric and underscore in
documentations and comments in regex.
This is important in case someone is confused with this code:
import re
re.split('\W', 'haha$hihi*huhu_hehe hoho')
['haha', 'hihi', 'huhu_hehe', 'hoho']
On the side note:
In Python code base, sometimes we write alphanumerics and underscores, yet
sometimes we write alphanumeric characters and underscore characters. Which
one again is the true way?
--
assignee: docs@python
components: Documentation
files: fix_alphanumeric_and_underscore_doc_in_regex.patch
keywords: patch
messages: 195611
nosy: akuchling, docs@python, vajrasky
priority: normal
severity: normal
status: open
title: Misleading documentations and comments in regular expression about
alphanumerics and underscore
versions: Python 3.3, Python 3.4
Added file:
http://bugs.python.org/file31371/fix_alphanumeric_and_underscore_doc_in_regex.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18779
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17400] ipaddress.is_private needs to take into account of rfc6598
Freek Dijkstra added the comment: A bit odd questions: What is the is_private() function intended to accomplish? I have been wondering what is_private() means, and how users of the library are going to use this function. I've actually failed to come up with any sensible use-case with the current implementation. So in the current state, without the modifications, my vote would be to remove the method, as it is more likely to add confusion than the be of a particular use. The most useful method (which I originally thought it was meant to do) is a function that indicates if a certain IP range is NATted (only an indication, since it requires a network to reliable test). However, that's not what the current function entails: it misses the 100.64.0.0/10 range, which is NATted, but includes the fc00::/7 unique local block, which is not NATted. I would be all in favour of such a is_natted() function, but that's not what this is. The is_private() function also does not simply list private IP addresses, when looking at the formal IETF definitions, since it includes fc00::/7, which are unique local addresses, which in practice used in a rather different way: IPv4 private IP addresses are often NATted (and routed after translation), while IPv6 unique local addresses are typically used for local non-routed networks. Also, the is_private() function does not list all non-globally assigned addresses. That should includes a lot more ranges, as listed on http://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml and http://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml. So far, the is_private() function seems to return True for addresses which are: * non-globally assigned (as opposed to regular unicast and multicast addresses) * available for manual assignment (as opposed to link-local addresses) * may be assigned by end-sites, but not by ISPs (as opposed to shared IP addresses and the small DS-Lite block) * is not intended for benchmarking purposes (as opposed to benchmarking IP addresses) Frankly, I wonder if this very particular information of enough interest to warrant a function on its own. In that case, I much rather see more generic (and hopefully more useful) functions such as is_natted() and for is_global(), is_forwardable() and is_reserved(), as defined by IANA. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17400 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18438] Obsolete url in comment inside decimal module
Changes by Serhiy Storchaka storch...@gmail.com: -- nosy: +facundobatista, skrah ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18438 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18777] Cannot compile _ssl.c using openssl 1.0
Antoine Pitrou added the comment: Rather than removing the call to CRYPTO_set_id_callback, it seems we should replace it with CRYPTO_THREADID_set_callback: « CRYPTO_THREADID and associated functions were introduced in OpenSSL 1.0.0 to replace (actually, deprecate) the previous CRYPTO_set_id_callback(), CRYPTO_get_id_callback(), and CRYPTO_thread_id() functions which assumed thread IDs to always be represented by 'unsigned long'. » http://www.openssl.org/docs/crypto/threads.html -- components: +Extension Modules nosy: +christian.heimes, giampaolo.rodola, janssen, pitrou priority: normal - critical stage: - needs patch versions: +Python 2.7, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18777 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18777] Cannot compile _ssl.c using openssl 1.0
Christian Heimes added the comment:
Something like that:
static void
_ssl_threadid_callback(CRYPTO_THREADID *id)
{
CRYPTO_THREADID_set_numeric(id, PyThread_get_thread_ident());
}
CRYPTO_THREADID_set_callback(_ssl_threadid_callback);
--
components: -Extension Modules
stage: needs patch - patch review
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18777
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18777] Cannot compile _ssl.c using openssl 1.0
Christian Heimes added the comment: I'm going to work on a modified patch. -- assignee: - christian.heimes components: +Extension Modules ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18777 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18777] Cannot compile _ssl.c using openssl 1.0
Antoine Pitrou added the comment: Indeed, only with the proper #ifdef's :-) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18777 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18779] Misleading documentations and comments in regular expression about alphanumerics and underscore
Changes by Serhiy Storchaka storch...@gmail.com: -- components: +Regular Expressions nosy: +ezio.melotti, mrabarnett, pitrou stage: - patch review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18779 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18779] Misleading documentations and comments in regular expression HOWTO
Antoine Pitrou added the comment: I was wondering which doc you were alluding it, before I noticed your patch is against the regex HOWTO. The HOWTO seems quite outdated wrt. Python 3. For example \w is not equivalent to [a-zA-Z0-9_], anymore, except with the ASCII flag. -- title: Misleading documentations and comments in regular expression about alphanumerics and underscore - Misleading documentations and comments in regular expression HOWTO ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18779 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18779] Misleading documentations and comments in regular expression HOWTO
Vajrasky Kok added the comment: In Lib/re.py, starting from line 77 (Python 3.4): \w Matches any alphanumeric character; equivalent to [a-zA-Z0-9_] in bytes patterns or string patterns with the ASCII flag. In string patterns without the ASCII flag, it will match the range of Unicode alphanumeric characters (letters plus digits plus underscore). With LOCALE, it will match the set [0-9_] plus characters defined as letters for the current locale. The prelude is Matches any alphanumeric character;. Yet, in any case (bytes, string patterns with ascii flag, string patterns without the ascii flag, strings with locale), the underscore is always included. Then why don't we change the prelude to Matches any alphanumeric character and underscore character;? In the description we explain the alphanumeric depending on it's unicode or not can be [A-Za-z0-9] or wider than that. The description is already okay but the prelude is misleading readers. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18779 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18771] Reduce the cost of hash collisions for set objects
Tal Einat added the comment: The following benchmarks were run with the second version of the patch (so2.diff), once before and once after. OSX 10.8 on a Macbook Pro, 2.5 GHz Core i5, two cores each with 256kb L2 cache, 3MB L3 cache: 1.32% less time for first benchmark (7.07 before, 6.98 after) 1.31% less time for second benchmark (9.81 before, 9.68 after) Ubuntu 12.10 64-bit, AMD Athlon II X2 250 Processor (3.0 GHz, 2MB L2 cache, 256KB total L1 per processor): 5% less time for first benchmark (13.6 before, 12.9 after) 11% less time for second benchmark (18.3 before, 16.3 after) Win7 64-bit, Intel Xeon E3-1230 V2 (quad-core, 3.30GHz, 256kb L2 cache per core, 8MB L3 cache): 1.8% less time for first benchmark (3.90 before, 3.83 after) 3.5% less time for second benchmark (7.27 before, 7.02 after) However, this processor has Intel SmartCache, which as far as I can tell means one processor can use other processors' caches if they are inactive. So I ran the benchmarks again with 4x larger data sets (revised benchmark script attached): 3.8% less time for first benchmark (19.3 before, 18.6 after) 7.5% less time for second benchmark (33.1 before, 30.6 after) -- nosy: +taleinat Added file: http://bugs.python.org/file31372/set_bench_smartcache.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18771 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18771] Reduce the cost of hash collisions for set objects
Tal Einat added the comment: Because of the unusually low differences, I tried running the benchmarks again on the MacBook (OSX 10.8). The first time was actually with so.diff, this time was with so2.diff. 0.69% less time for first benchmark (7.30 before, 7.25 after) 8.08% less time for second benchmark (10.85 before, 9.97 after) Strange... -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18771 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18771] Reduce the cost of hash collisions for set objects
Christian Heimes added the comment: Intel(R) Core(TM) i7-4770K CPU @ 3.50GHz on Ubuntu 13.04 X86_64 with GCC 4.7.3 1MB L2 cache test: 11.33sec / 10.83sec (4.4% faster) 8Mb L3 cache test: 22.16sec / 19.67sec (11% faster) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18771 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18771] Reduce the cost of hash collisions for set objects
Tal Einat added the comment: Sorry to be pedantic, but while 19.67sec is about 11.2% less than 22.16sec, it is actually about 12.6% faster (22.16/19.67 - 1). Regardless, that's a good result! And I'm happy that the modified benchmark is useful. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18771 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18771] Reduce the cost of hash collisions for set objects
Christian Heimes added the comment: Oh *curse*, you are right. Why do I always confuse the order? :| It looks like the performance boost increases with CPU cache size as well as the CPU's generation. The i7-4770K box at work is less than a week old. The CPU is currently the fast desktop CPU from Intel. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18771 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18652] Add itertools.first_true (return first true item in iterable)
R. David Murray added the comment: OK, now I have a place in the non-test email code where using this would lead to easier-to-read code. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18652 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18778] email docstrings and comments say about Unicode strings
R. David Murray added the comment: If you mean the code in Charset's __init__, if you change that you'll have backward compatibility issues. As the code currently stands it is legal to pass in a charset name that is bytes. And the string path of that if checks that it contains only ASCII characters, a check that is also still required. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18778 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18778] email docstrings and comments say about Unicode strings
R. David Murray added the comment: The comment, however, is clearly no longer appropriate :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18778 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18779] Misleading documentations and comments in regular expression HOWTO
R. David Murray added the comment: The answer to the question about alphanumerics versus alphanumeric characters is that is is mostly likely context-dependent, so I'd have to see particular examples to say which I though read better. So, there is no One True Answer for this question, I think. -- nosy: +r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18779 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18738] String formatting (% and str.format) issues with Enum
Eric V. Smith added the comment: Oh, I don't feel my time has been wasted. Where else can I have a discussion of __format__? With this patch, given this: class UpperString(str): def __format__(self, fmt): return str.__format__(self, fmt).upper() class UpperEnum(UpperString, Enum): pass class S(UpperEnum): a = 'a' b = 'b' this gives the (to me) surprising results of: format(S.a) 'S.a' format(S.a, '10') 'S.a ' format(S.a, '10s') 'A ' I'd expect this to always use UpperString.__format__, since it understands all str format specs. And before you say UpperString is contrived, I've used classes like it in the past: they're just like a string, but the __format__ method does something special after calling through to str.__format__. Which is why I think __format__ has to go in the derived type (IntEnum, in the originally reported case): only it can decide whether to call str.__format__ or the mix-in class's __format__. Now, whether or not Enum needs to support such classes with specialized __format___, I can't say. I suppose it's not super-important. But it will be difficult to explain all of this. Also, the patch give this: class E(IntEnum): ... one = 1 ... two = 2 ... format(E.one) 'E.one' format(E.one, 's') Traceback (most recent call last): File stdin, line 1, in module File /home/eric/local/python/cpython/Lib/enum.py, line 463, in __format__ return obj.__format__(val, format_spec) ValueError: Unknown format code 's' for object of type 'int' I can't format it using the 's' presentation type, despite the fact it looks like a string. I think you need to add 's' to your _remove_plain_format_chars. And consider this valid (but arguably pathological) code: format(datetime.datetime.now(), '10') '10' Despite this being a valid datetime format spec, your code would consider it a str spec. tl;dr: I think __format__ belongs in the class that understands how the subclass handles format specs. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18738 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18750] '' % [1] doesn't fail
Giacomo Alzetta added the comment: Note that the documentation for formatting with %, found here: http://docs.python.org/2/library/stdtypes.html#string-formatting-operations, states: If format requires a single argument, values may be a single non-tuple object. [5] Otherwise, values must be a tuple with exactly the number of items specified by the format string, or a single mapping object (for example, a dictionary). Note how it explicitly states that in an expression: format % value there are two different cases: - If format contains *exactly one* format specifier, then value can be any non-tuple item and it will be formatted as is. Otherwise, value MUST be either tuple or a mapping. In your example '' contains 0 format specifiers, hence you MUST use either a tuple or a dict. Any other object triggers undefined behaviour(in particular depending on whether the object define __geitem__ or not the formatting might or might not raise an exception etc.) AFAIK only few people know this, hence changing the code could potentially break a lot of code for apparently no reason. Since people should start to move to str.format instead of % this wart may not be worth fixing. -- nosy: +bakuriu ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18750 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18606] Add statistics module to standard library
Oscar Benjamin added the comment:
I've just checked over the new patch and it all looks good to me apart
from one quibble.
It is documented that statistics.sum() will respect rounding errors
due to decimal context (returning the same result that sum() would). I
would prefer it if statistics.sum would use compensated summation with
Decimals since in my view they are a floating point number
representation and are subject to arithmetic rounding error in the
same way as floats. I expect that the implementation of sum() will
change but it would be good to at least avoid documenting this IMO
undesirable behaviour.
So with the current implementation I can do:
from decimal import Decimal as D, localcontext, Context, ROUND_DOWN
data = [D(0.1375), D(0.2108), D(0.3061), D(0.0419)]
print(statistics.variance(data))
0.0125290958333
with localcontext() as ctx:
... ctx.prec = 2
... ctx.rounding = ROUND_DOWN
... print(statistics.variance(data))
...
0.010
The final result is not accurate to 2 d.p. rounded down. This is
because the decimal context has affected all intermediate computations
not just the final result. Why would anyone prefer this behaviour over
an implementation that could compensate for rounding errors and return
a more accurate result?
If statistics.sum and statistics.add_partial are modified in such a
way that they use the same compensated algorithm for Decimals as they
would for floats then you can have the following:
statistics.sum([D('-1e50'), D('1'), D('1e50')])
Decimal('1')
whereas it currently does:
statistics.sum([D('-1e50'), D('1'), D('1e50')])
Decimal('0E+23')
statistics.sum([D('-1e50'), D('1'), D('1e50')]) == 0
True
It still doesn't fix the variance calculation but I'm not sure exactly
how to do better than the current implementation for that. Either way
though I don't think the current behaviour should be a documented
guarantee. The meaning of honouring the context implies using a
specific sum algorithm, since an alternative algorithm would give a
different result and I don't think you should constrain yourself in
that way.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18606
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18780] SystemError when formatting int subclass
New submission from Serhiy Storchaka: class I(int): ... def __str__(self): ... return 'spam' ... '%i' % (I(42),) Traceback (most recent call last): File stdin, line 1, in module SystemError: Objects/unicodeobject.c:13595: bad argument to internal function This issue is related to issue18738 and will be fixed when use PyNumber_ToBase() for any int subclass (not only for bool). -- messages: 195631 nosy: haypo, serhiy.storchaka priority: normal severity: normal status: open title: SystemError when formatting int subclass type: crash versions: Python 3.3, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18780 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18738] String formatting (% and str.format) issues with Enum
Serhiy Storchaka added the comment: For C-style formatting see also issue18780. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18738 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18771] Reduce the cost of hash collisions for set objects
Raymond Hettinger added the comment: Wow, thanks for running these tests and posting the results :-) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18771 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18780] SystemError when formatting int subclass
STINNER Victor added the comment: formatlong() should copy the string if Py_REFCNT(str) != 1. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18780 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18771] Reduce the cost of hash collisions for set objects
Roundup Robot added the comment: New changeset a887596b841f by Raymond Hettinger in branch 'default': Issue18771: Reduce the cost of hash collisions for set objects. http://hg.python.org/cpython/rev/a887596b841f -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18771 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18771] Reduce the cost of hash collisions for set objects
Changes by Raymond Hettinger raymond.hettin...@gmail.com: -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18771 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18771] Reduce the cost of hash collisions for set objects
Christian Heimes added the comment: How about a Misc/NEWS and a Doc/whatsnew/3.4 entry, too? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18771 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18771] Reduce the cost of hash collisions for set objects
STINNER Victor added the comment: This optimization cannot be applied to the dict type? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18771 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18781] re.escape escapes underscore (Python 2.7)
New submission from Vajrasky Kok:
$ ./python --version
Python 2.7.5+
$ ./python
Python 2.7.5+ (2.7:062533327ad2, Aug 19 2013, 22:44:52)
[GCC 4.7.2 20121109 (Red Hat 4.7.2-8)] on linux2
Type help, copyright, credits or license for more information.
import re
re.escape('_')
'\\_'
Python 3.3 and 3.4 got it right and don't escape the underscore.
Because many people are still doing their livelihoods with Python 2.7 and I am
a compassionate person, here is the patch to fix the bug in Python 2.7.
--
components: Regular Expressions
files: dont_escape_underscore_in_regex_27.patch
keywords: patch
messages: 195638
nosy: ezio.melotti, mrabarnett, vajrasky
priority: normal
severity: normal
status: open
title: re.escape escapes underscore (Python 2.7)
type: behavior
versions: Python 2.7
Added file:
http://bugs.python.org/file31373/dont_escape_underscore_in_regex_27.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18781
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18777] Cannot compile _ssl.c using openssl 1.0
Christian Heimes added the comment: patch -- Added file: http://bugs.python.org/file31374/18777.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18777 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18781] re.escape escapes underscore (Python 2.7)
Ezio Melotti added the comment: This was considered a new feature when it was added in 3.2 (see #2650), so it was not backported to 2.7 because -- even if it was a minor change -- it was not 100% backward compatible. -- assignee: - ezio.melotti resolution: - rejected stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18781 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18782] sqlite3 row factory and multiprocessing map
New submission from Timothy O'Keefe:
If you run this code, you will get a segfault. If you a) remove the row factory
from the following code or b) use the standard library map() instead of
multiprocessing.Pool.map, then the code does not crash.
#!/usr/bin/env python
import sqlite3
import multiprocessing as mp
def main():
## --- create a database
conn = sqlite3.connect(':memory:')
conn.row_factory = sqlite3.Row
c = conn.cursor()
## --- create example table similar to python docs
c.execute('''CREATE TABLE stocks (date text, trans text, symbol text, qty
real, price real)''')
c.execute(INSERT INTO stocks VALUES
('2006-01-05','BUY','GOOG',100,869.29))
c.execute(INSERT INTO stocks VALUES
('1992-01-06','SELL','AAPL',20,512.99))
c.execute(SELECT * FROM stocks)
## --- map fun over cursor iterable (fun does nothing)
pool = mp.Pool(processes=mp.cpu_count())
features = pool.map(fun, c)
def fun(row):
return row
if __name__ == __main__:
main()
--
messages: 195641
nosy: tokeefe
priority: normal
severity: normal
status: open
title: sqlite3 row factory and multiprocessing map
type: crash
versions: Python 2.7
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18782
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18777] Cannot compile _ssl.c using openssl 1.0
Roundup Robot added the comment: New changeset f967ded6f9dd by Christian Heimes in branch '3.3': Issue #18777: The ssl module now uses the new CRYPTO_THREADID API of http://hg.python.org/cpython/rev/f967ded6f9dd New changeset 28e68f4807a2 by Christian Heimes in branch 'default': Issue #18777: The ssl module now uses the new CRYPTO_THREADID API of http://hg.python.org/cpython/rev/28e68f4807a2 New changeset 5d691723bfbd by Christian Heimes in branch '2.7': Issue #18777: The ssl module now uses the new CRYPTO_THREADID API of http://hg.python.org/cpython/rev/5d691723bfbd -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18777 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18777] Cannot compile _ssl.c using openssl 1.0
Changes by Christian Heimes li...@cheimes.de: -- resolution: - fixed stage: patch review - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18777 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18774] There is still last bit of GNU Pth code in signalmodule.c
Roundup Robot added the comment: New changeset a02339bda413 by Raymond Hettinger in branch 'default': Issue 18774: Update news and whatsnew for the set optimizations http://hg.python.org/cpython/rev/a02339bda413 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18774 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18771] Reduce the cost of hash collisions for set objects
Raymond Hettinger added the comment: Victor, this should also work for dictionaries as well. Fundamentally, the concepts of loop-unrolling and exploiting cache locality should apply to any hash table implementation. That said, the dicts are more complex than sets due to 1) storing the hash/key/value 2) key-sharing, and 3) different access patterns. So, it will require more effort than just porting over the patch. Feel free to open a new tracker item for that one. It will take more work but will potentially have a much greater pay-off. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18771 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17276] HMAC: deprecate default hash
Christian Heimes added the comment: assertWarns() is much easier than the block I have copied and pasted. Thanks. :) -- Added file: http://bugs.python.org/file31375/17276-2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17276 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18606] Add statistics module to standard library
Steven D'Aprano added the comment:
On 19/08/13 23:15, Oscar Benjamin wrote:
So with the current implementation I can do:
from decimal import Decimal as D, localcontext, Context, ROUND_DOWN
data = [D(0.1375), D(0.2108), D(0.3061), D(0.0419)]
print(statistics.variance(data))
0.0125290958333
with localcontext() as ctx:
... ctx.prec = 2
... ctx.rounding = ROUND_DOWN
... print(statistics.variance(data))
...
0.010
The final result is not accurate to 2 d.p. rounded down. This is
because the decimal context has affected all intermediate computations
not just the final result.
Yes. But that's the whole point of setting the context to always round down. If
summation didn't always round down, it would be a bug.
If you set the precision to a higher value, you can avoid the need for
compensated summation. I'm not prepared to pick and choose which contexts I'll
honour. If I honour those with a high precision, I'll honour those with a low
precision too. I'm not going to check the context, and if it is too low
(according to whom?) set it higher.
Why would anyone prefer this behaviour over
an implementation that could compensate for rounding errors and return
a more accurate result?
Because that's what the Decimal standard requires (as I understand it), and
besides you might be trying to match calculations on some machine with a lower
precision, or different rounding modes. Say, a pocket calculator, or a Cray, or
something. Or demonstrating why rounding matters.
Perhaps it will cause less confusion if I add an example to show a use for
higher precision as well.
If statistics.sum and statistics.add_partial are modified in such a
way that they use the same compensated algorithm for Decimals as they
would for floats then you can have the following:
statistics.sum([D('-1e50'), D('1'), D('1e50')])
Decimal('1')
statistics.sum can already do that:
py with localcontext() as ctx:
... ctx.prec = 50
... x = statistics.sum([D('-1e50'), D('1'), D('1e50')])
...
py x
Decimal('1')
I think the current behaviour is the right thing to do, but I appreciate the
points you raise. I'd love to hear from someone who understands the Decimal
module better than I do and can confirm that the current behaviour is in the
spirit of the Decimal module.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18606
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16255] subrocess.Popen needs /bin/sh but Android only has /system/bin/sh
Changes by Andrew Svetlov andrew.svet...@gmail.com: -- dependencies: +add function to os module for getting path to default shell ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16255 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16255] subrocess.Popen needs /bin/sh but Android only has /system/bin/sh
Changes by Andrew Svetlov andrew.svet...@gmail.com: -- versions: -Python 2.7, Python 3.2, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16255 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17560] problem using multiprocessing with really big objects?
Olivier Grisel added the comment: I have implemented a custom subclass of the multiprocessing Pool to be able plug custom pickling strategy for this specific use case in joblib: https://github.com/joblib/joblib/blob/master/joblib/pool.py#L327 In particular it can: - detect mmap-backed numpy - transform large memory backed numpy arrays into numpy.memmap instances prior to pickling using the /dev/shm partition when available or TMPDIR otherwise. Here is some doc: https://github.com/joblib/joblib/blob/master/doc/parallel_numpy.rst I could submit the part that makes it possible to customize the picklers of multiprocessing.pool.Pool instance to the standard library if people are interested. The numpy specific stuff would stay in third party projects such as joblib but at least that would make it easier for people to plug their own optimizations without having to override half of the multiprocessing class hierarchy. -- nosy: +Olivier.Grisel ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17560 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17560] problem using multiprocessing with really big objects?
Olivier Grisel added the comment: I forgot to end a sentence in my last comment: - detect mmap-backed numpy should read: - detect mmap-backed numpy arrays and pickle only the filename and other buffer metadata to reconstruct a mmap-backed array in the worker processes instead of copying the data around. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17560 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18772] Fix gdb plugin for new sets dummy object
Antoine Pitrou added the comment: Raymond, if you don't have time for this issue, I'd prefer your patch to be reverted. It hasn't been proven to accelerate any benchmark, and the problems it triggered need solving. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18772 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18783] No more refer to Python long
New submission from Serhiy Storchaka: Here is a patch which removes (almost all) mentions of Python long type from docstrings, exception messages and comments. -- files: no_long.patch keywords: patch messages: 195650 nosy: serhiy.storchaka priority: normal severity: normal stage: patch review status: open title: No more refer to Python long versions: Python 3.3, Python 3.4 Added file: http://bugs.python.org/file31376/no_long.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18783 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18778] email docstrings and comments say about Unicode strings
Serhiy Storchaka added the comment: It is just unusual to accept a bytes object as a charset name. Of course if it is needed for Charset's __init__ the code should not be removed. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18778 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18784] minor uuid.py loading optimization
New submission from Evgeny Sologubov: Please see the patch attached. It quite is primitive and self-explanatory: the code wouldn't attempt to load *libc* via ctypes.CDLL, if all necessary functions are already found in *libuuid*. This patch also can serve as a work-around solution to issue #17213 (which I encountered on cygwin+python27) -- components: Library (Lib), Windows, ctypes files: uuid.patch keywords: patch messages: 195653 nosy: eugals priority: normal severity: normal status: open title: minor uuid.py loading optimization type: performance versions: Python 2.7 Added file: http://bugs.python.org/file31377/uuid.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18784 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16396] Importing ctypes.wintypes on Linux gives a traceback
Amaury Forgeot d'Arc added the comment: I think it's the opposite: when Unix support was added to ctypes, 'import ctypes.wintypes' was not considered. By that logic, the patch is a new feature. IMO historical arguments are moot :-) I agree with the conclusion tough: the patch will not break code that carefully catches ValueError, and so it suitable for 2.7. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16396 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18772] Fix gdb plugin for new sets dummy object
Dave Malcolm added the comment: Antoine's patch looks reasonable to me, FWIW. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18772 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18772] Fix gdb plugin for new sets dummy object
Changes by Raymond Hettinger raymond.hettin...@gmail.com: -- assignee: - rhettinger ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18772 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18784] minor uuid.py loading optimization
Changes by Antoine Pitrou pit...@free.fr: -- nosy: +serhiy.storchaka ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18784 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17998] internal error in regular expression engine
Serhiy Storchaka added the comment: For other related issues see issue18672 and issue18684. -- resolution: - fixed stage: test needed - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17998 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18750] '' % [1] doesn't fail
Serhiy Storchaka added the comment: Since people should start to move to str.format instead of % this wart may not be worth fixing. ''.format_map([1]) '' However I agree that this is not worth fixing. -- nosy: +serhiy.storchaka ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18750 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17560] problem using multiprocessing with really big objects?
Richard Oudkerk added the comment: I could submit the part that makes it possible to customize the picklers of multiprocessing.pool.Pool instance to the standard library if people are interested. 2.7 and 3.3 are in bugfix mode now, so they will not change. In 3.3 you can do from multiprocessing.forking import ForkingPickler ForkingPickler.register(MyType, reduce_MyType) Is this sufficient for you needs? This is private (and its definition has moved in 3.4) but it could be made public. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17560 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18778] email docstrings and comments say about Unicode strings
R. David Murray added the comment: Yeah, if I could have a do-over of the 3.0 port, I'd probably drop the acceptance of byte strings. Maybe we can deprecate it. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18778 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15809] IDLE console uses incorrect encoding.
Changes by ali mr.da...@gmail.com: -- nosy: +irdb ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15809 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18772] Fix gdb plugin for new sets dummy object
Raymond Hettinger added the comment: This is a bummer. The internal comments made the claim that any python object would suffice. The use of a unicode object was unfortunate because it isn't guaranteed to be unique (i.e. a user can legitimately store dummy as a valid member of a set). As a consequence, the tight loops for the hash table lookups had to add special case checks for the dummy variables. Eliminating those checks made the generated code shorter and faster. It also paved the way for a future optimization for non-debug builds to eliminate all non-essential increfs and decrefs to the dummy object. In other words, we're paying a price for the dummy object being printable as a string. Antoine, thanks to the link to the python-dev discussion. I hope we can come with a solution that doesn't involve going back to unicode objects. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18772 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18782] sqlite3 row factory and multiprocessing map
Ned Deily added the comment: What platform are you running on? Please run the following script in the same environment as you get the segfault and report the results. #!/usr/bin/env python import multiprocessing import platform import sqlite3 import sys print(sys.version) print(sqlite3.version) print(sqlite3.sqlite_version) print(multiprocessing.__version__) print(multiprocessing.cpu_count()) print(platform.platform()) For what it's worth, I was not able to reproduce this behavior using several different environments. Also, what happens if you add pool.close() pool.join() following the pool.map call? -- nosy: +ned.deily ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18782 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2537] re.compile(r'((x|y+)*)*') should fail
Roundup Robot added the comment: New changeset 7ab07f15d78c by Serhiy Storchaka in branch '3.3': Issue #2537: Remove breaked check which prevented valid regular expressions. http://hg.python.org/cpython/rev/7ab07f15d78c New changeset f4271cc2dfb5 by Serhiy Storchaka in branch 'default': Issue #2537: Remove breaked check which prevented valid regular expressions. http://hg.python.org/cpython/rev/f4271cc2dfb5 New changeset 7b867a46a8b4 by Serhiy Storchaka in branch '2.7': Issue #2537: Remove breaked check which prevented valid regular expressions. http://hg.python.org/cpython/rev/7b867a46a8b4 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2537 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18647] re.error: nothing to repeat
Roundup Robot added the comment: New changeset de049e9abdf7 by Serhiy Storchaka in branch '3.3': Issue #18647: Correctly bound calculated min/max width of a subexpression. http://hg.python.org/cpython/rev/de049e9abdf7 New changeset e47f2dc564bc by Serhiy Storchaka in branch 'default': Issue #18647: Correctly bound calculated min/max width of a subexpression. http://hg.python.org/cpython/rev/e47f2dc564bc New changeset d10c287c200c by Serhiy Storchaka in branch '2.7': Issue #18647: Correctly bound calculated min/max width of a subexpression. http://hg.python.org/cpython/rev/d10c287c200c New changeset 19ed2fbb8e6b by Serhiy Storchaka in branch '3.3': Issue #18647: A regular expression in the doctest module rewritten so that http://hg.python.org/cpython/rev/19ed2fbb8e6b New changeset 8b24818c7327 by Serhiy Storchaka in branch 'default': Issue #18647: A regular expression in the doctest module rewritten so that http://hg.python.org/cpython/rev/8b24818c7327 New changeset c2dc99ec46bc by Serhiy Storchaka in branch '2.7': Issue #18647: A regular expression in the doctest module rewritten so that http://hg.python.org/cpython/rev/c2dc99ec46bc New changeset 7ab07f15d78c by Serhiy Storchaka in branch '3.3': Issue #2537: Remove breaked check which prevented valid regular expressions. http://hg.python.org/cpython/rev/7ab07f15d78c New changeset f4271cc2dfb5 by Serhiy Storchaka in branch 'default': Issue #2537: Remove breaked check which prevented valid regular expressions. http://hg.python.org/cpython/rev/f4271cc2dfb5 New changeset 7b867a46a8b4 by Serhiy Storchaka in branch '2.7': Issue #2537: Remove breaked check which prevented valid regular expressions. http://hg.python.org/cpython/rev/7b867a46a8b4 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18647 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1633953] re.compile((.*$){1,4}, re.MULTILINE) fails
Serhiy Storchaka added the comment: Fixed in issue2537. See also issue18647. -- nosy: +serhiy.storchaka resolution: - duplicate stage: - committed/rejected status: open - closed superseder: - re.compile(r'((x|y+)*)*') should fail ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1633953 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2537] re.compile(r'((x|y+)*)*') should not fail
Serhiy Storchaka added the comment: This issue is a duplicate of issue1633953. See also issue18647. After some fixes in other parts of the re module this check has become even more invalid. -- resolution: - fixed stage: - committed/rejected status: open - closed title: re.compile(r'((x|y+)*)*') should fail - re.compile(r'((x|y+)*)*') should not fail versions: +Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2537 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18647] re.error: nothing to repeat
Changes by Serhiy Storchaka storch...@gmail.com: -- stage: - commit review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18647 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18782] sqlite3 row factory and multiprocessing map
Timothy O'Keefe added the comment:
Could you change the dummy function to do something other than simply return
the row? For example:
#!/usr/bin/env python
import sqlite3
import multiprocessing as mp
def main():
## --- create a database
conn = sqlite3.connect(':memory:')
conn.row_factory = sqlite3.Row
c = conn.cursor()
## --- create example table similar to python docs
c.execute('''CREATE TABLE stocks (date text, trans text, symbol text, qty
real, price real)''')
c.execute(INSERT INTO stocks VALUES
('2006-01-05','BUY','GOOG',100,869.29))
c.execute(INSERT INTO stocks VALUES
('1992-01-06','SELL','AAPL',20,512.99))
c.execute(SELECT * FROM stocks)
## --- map fun over cursor (fun does little to nothing)
pool = mp.Pool(processes=mp.cpu_count())
rows = pool.map(fun, c)
def fun(row):
_ = len(row)
return row
if __name__ == __main__:
main()
In this example the code simply hangs. For whatever reason, I can no longer
provoke the segfault.
Regardless, there is something going on. Here are the results from the print
statements you asked for:
2.7.2 (default, Oct 11 2012, 20:14:37)
[GCC 4.2.1 Compatible Apple Clang 4.0 (tags/Apple/clang-418.0.60)]
2.6.0
3.7.12
0.70a1
4
Darwin-12.4.0-x86_64-i386-64bit
I have also tried this on Ubuntu 12.04:
2.7.3 (default, Apr 10 2013, 06:20:15)
[GCC 4.6.3]
2.6.0
3.7.9
0.70a1
4
Linux-3.2.0-24-generic-x86_64-with-Ubuntu-12.04-precise
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18782
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18712] Pure Python operator.index doesn't match the C version.
Zachary Ware added the comment: A lot of this discussion has flown a rather unfortunate distance over my head, especially since I've barely had time to follow it. But it looks to me like--given the number of other places that do the same thing as operator.index currently does--there needs to be a simple way to do the right thing somewhere accessible, which probably means a builtin. On the other hand, it seems to me like 'a.__index__()' *should* be the right thing to do, but I get the feeling that making that so would be an astronomically huge change without much real benefit and lots of opportunities to break everything. I suspect I'm also missing something fundamental in why it's not the right thing to do. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18712 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18782] sqlite3 row factory and multiprocessing map
Richard Oudkerk added the comment: Adding the line features[0][0] to the end of main() produces a segfault for me on Linux. The FAQ for sqlite3 says that Under Unix, you should not carry an open SQLite database across a fork() system call into the child process. Problems will result if you do. -- see http://www.sqlite.org/faq.html. So assuming you are using Unix, this is probably not a Python bug. (And anyway, I would not expect the pickling of row objects to work correctly.) -- nosy: +sbt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18782 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18571] Implementation of the PEP 446: non-inheritable file descriptors
Changes by STINNER Victor victor.stin...@gmail.com: Added file: http://bugs.python.org/file31378/00df7fc6d2ef.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18571 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13461] Error on test_issue_1395_5 with Python 2.7 and VS2010
Changes by Serhiy Storchaka storch...@gmail.com: -- assignee: - serhiy.storchaka ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13461 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7732] imp.find_module crashes Python if there exists a directory named __init__.py
Antoine Pitrou added the comment: The bug still fails on a regular basis on the Windows buildbots: == FAIL: test_bug7732 (test.test_imp.ImportTests) -- Traceback (most recent call last): File E:\Data\buildslave\cpython\3.x.snakebite-win2k3r2sp2-x86\build\lib\test\test_imp.py, line 285, in test_bug7732 imp.find_module, support.TESTFN, [.]) AssertionError: ImportError not raised by find_module -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7732 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18785] Add get_body and iter_attachments to provisional email API
New submission from R. David Murray: I'm working on completing the API changes for the email package for 3.4. This means I'm adding some more stuff to the current provisional API, which I will then aim to make non-provisional in 3.5. I've made a complete proposal to the email-sig, and have gotten some positive feedback but no detailed reviews yet. One part of the new API proposal is independent of the rest, and I've documented that part and implemented it. I'm posting the patch for that part. The patch includes some of the documentation for the rest, though not all of it...you can ignore all the doc changes in the new doc page except for the docs for the three new methods implemented by the patch for the purposes of reviewing this patch, though of course feedback on the (incomplete) rest is welcome. I'm posting this now because this part of the enhancement can be reviewed independently of the other changes. Note: I'm aware that MIMEMessage duplicates the name of a class in the mime subpackage. By the time I'm done that class will be deprecated (in 3.5). I haven't got that approved by the SIG yet, though, so it may change :) -- components: email files: get_body_iter_attachments.patch keywords: patch messages: 195669 nosy: barry, r.david.murray priority: normal severity: normal stage: patch review status: open title: Add get_body and iter_attachments to provisional email API type: enhancement versions: Python 3.4 Added file: http://bugs.python.org/file31379/get_body_iter_attachments.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18785 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18606] Add statistics module to standard library
Oscar Benjamin added the comment: On 19 August 2013 17:35, Steven D'Aprano rep...@bugs.python.org wrote: Steven D'Aprano added the comment: On 19/08/13 23:15, Oscar Benjamin wrote: The final result is not accurate to 2 d.p. rounded down. This is because the decimal context has affected all intermediate computations not just the final result. Yes. But that's the whole point of setting the context to always round down. If summation didn't always round down, it would be a bug. If individual binary summation (d1 + d2) didn't round down then that would be a bug. If you set the precision to a higher value, you can avoid the need for compensated summation. I'm not prepared to pick and choose which contexts I'll honour. If I honour those with a high precision, I'll honour those with a low precision too. I'm not going to check the context, and if it is too low (according to whom?) set it higher. I often write functions like this: def compute_stuff(x): with localcontext() as ctx: ctx.prec +=2 y = ... # Compute in higher precision return +y # __pos__ reverts to the default precision The final result is rounded according to the default context but the intermediate computation is performed in such a way that the final result is (hopefully) correct within its context. I'm not proposing that you do that, just that you don't commit to respecting inaccurate results. Why would anyone prefer this behaviour over an implementation that could compensate for rounding errors and return a more accurate result? Because that's what the Decimal standard requires (as I understand it), and besides you might be trying to match calculations on some machine with a lower precision, or different rounding modes. Say, a pocket calculator, or a Cray, or something. Or demonstrating why rounding matters. No that's not what the Decimal standard requires. Okay I haven't fully read it but I am familiar with these standards and I've read a good bit of IEEE-754. The standard places constrainst on low-level arithmetic operations that you as an implementer of high-level algorithms can use to ensure that your code is accurate. Following your reasoning above I should say that math.fsum and your statistics.sum are both in violation of IEEE-754 since fsum([a, b, c, d, e]) is not equivalent to a+b)+c)+d)+e) under the current rounding scheme. They are not in violation of the standard: both functions use the guarantees of the standard to guarantee their own accuracy. Both go to some lengths to avoid producing output with the rounding errors that sum() would produce. I think the current behaviour is the right thing to do, but I appreciate the points you raise. I'd love to hear from someone who understands the Decimal module better than I do and can confirm that the current behaviour is in the spirit of the Decimal module. I use the Decimal module for multi-precision real arithmetic. That may not be the typical use-case but to me Decimal is a floating point type just like float. Precisely the same reasoning that leads to fsum applies to Decimal just as it does to float (BTW I've posted on Rayomnd Hettinger's recipe a modification that might make it work for Decimal but no reply yet.) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18606 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17560] problem using multiprocessing with really big objects?
Olivier Grisel added the comment: In 3.3 you can do from multiprocessing.forking import ForkingPickler ForkingPickler.register(MyType, reduce_MyType) Is this sufficient for you needs? This is private (and its definition has moved in 3.4) but it could be made public. Indeed I forgot that the multiprocessing pickler was made already made pluggable in Python 3.3. I needed backward compat for python 2.6 in joblib hence I had to rewrite a bunch of the class hierarchy. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17560 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7732] imp.find_module crashes Python if there exists a directory named __init__.py
Roundup Robot added the comment: New changeset 4f7845be9e23 by Antoine Pitrou in branch 'default': Issue #7732: try to fix test_bug7732's flakiness on Windows by executing it in a fresh temporary directory. http://hg.python.org/cpython/rev/4f7845be9e23 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7732 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18786] test_multiprocessing_spawn crashes under PowerLinux
New submission from Antoine Pitrou:
http://buildbot.python.org/all/builders/PPC64%20PowerLinux%203.x
[319/379] test_multiprocessing_spawn
/home/shager/cpython-buildarea/3.x.edelsohn-powerlinux-ppc64/build/Lib/multiprocessing/semaphore_tracker.py:121:
UserWarning: semaphore_tracker: There appear to be 2 leaked semaphores to
clean up at shutdown
len(cache))
/home/shager/cpython-buildarea/3.x.edelsohn-powerlinux-ppc64/build/Lib/multiprocessing/semaphore_tracker.py:133:
UserWarning: semaphore_tracker: '/mp-t89tlie_': [Errno 2] No such file or
directory
warnings.warn('semaphore_tracker: %r: %s' % (name, e))
make: *** [buildbottest] User defined signal 1
Process PoolWorker-777:
Traceback (most recent call last):
File
/home/shager/cpython-buildarea/3.x.edelsohn-powerlinux-ppc64/build/Lib/multiprocessing/pool.py,
line 123, in worker
put((job, i, result))
File
/home/shager/cpython-buildarea/3.x.edelsohn-powerlinux-ppc64/build/Lib/multiprocessing/queues.py,
line 368, in put
self._writer.send_bytes(obj)
File
/home/shager/cpython-buildarea/3.x.edelsohn-powerlinux-ppc64/build/Lib/multiprocessing/connection.py,
line 202, in send_bytes
self._send_bytes(m[offset:offset + size])
File
/home/shager/cpython-buildarea/3.x.edelsohn-powerlinux-ppc64/build/Lib/multiprocessing/connection.py,
line 401, in _send_bytes
self._send(struct.pack(!i, n))
File
/home/shager/cpython-buildarea/3.x.edelsohn-powerlinux-ppc64/build/Lib/multiprocessing/connection.py,
line 371, in _send
n = write(self._handle, buf)
BrokenPipeError: [Errno 32] Broken pipe
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File
/home/shager/cpython-buildarea/3.x.edelsohn-powerlinux-ppc64/build/Lib/multiprocessing/process.py,
line 255, in _bootstrap
self.run()
File
/home/shager/cpython-buildarea/3.x.edelsohn-powerlinux-ppc64/build/Lib/multiprocessing/process.py,
line 92, in run
self._target(*self._args, **self._kwargs)
File
/home/shager/cpython-buildarea/3.x.edelsohn-powerlinux-ppc64/build/Lib/multiprocessing/pool.py,
line 128, in worker
put((job, i, (False, wrapped)))
File
/home/shager/cpython-buildarea/3.x.edelsohn-powerlinux-ppc64/build/Lib/multiprocessing/queues.py,
line 368, in put
self._writer.send_bytes(obj)
File
/home/shager/cpython-buildarea/3.x.edelsohn-powerlinux-ppc64/build/Lib/multiprocessing/connection.py,
line 202, in send_bytes
self._send_bytes(m[offset:offset + size])
File
/home/shager/cpython-buildarea/3.x.edelsohn-powerlinux-ppc64/build/Lib/multiprocessing/connection.py,
line 401, in _send_bytes
self._send(struct.pack(!i, n))
File
/home/shager/cpython-buildarea/3.x.edelsohn-powerlinux-ppc64/build/Lib/multiprocessing/connection.py,
line 371, in _send
n = write(self._handle, buf)
BrokenPipeError: [Errno 32] Broken pipe
/home/shager/cpython-buildarea/3.x.edelsohn-powerlinux-ppc64/build/Lib/multiprocessing/semaphore_tracker.py:121:
UserWarning: semaphore_tracker: There appear to be 4 leaked semaphores to
clean up at shutdown
len(cache))
program finished with exit code 2
elapsedTime=4624.019498
--
assignee: sbt
components: Library (Lib), Tests
messages: 195673
nosy: David.Edelsohn, pitrou, sbt
priority: critical
severity: normal
status: open
title: test_multiprocessing_spawn crashes under PowerLinux
type: crash
versions: Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18786
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18571] Implementation of the PEP 446: non-inheritable file descriptors
STINNER Victor added the comment: make_inheritable() should ignore errpipe_write, instead of changing twice the inheritable flag of errpipe_write. Done in the last patch (00df7fc6d2ef.diff). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18571 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16396] Importing ctypes.wintypes on Linux gives a traceback
Meador Inge added the comment: On Mon, Aug 12, 2013 at 7:11 AM, Ezio Melotti rep...@bugs.python.orgwrote: Even if the patch is applied only on 3.4, I would still like to see the ValueError turned into ImportError for 2.7/3.3. Why not raise an ImportError for all versions? I don't see how 'ctypes.wintypes' is ever actually useful on anything but Windows. Allowing it to successfully import on non-Windows systems seems misleading. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16396 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18704] IDLE: PEP8 Style Check Integration
Todd Rovito added the comment: Ezio, I think modern editors are expected to have this sort of functionality built into them [1]. XCode is simply amazing where it will pop up errors and quote the C99 standard [2]. We don't expect IDLE to have all that functionality but it seemed to us like it would be great to add pep8 or PyFlakes to IDLE. It is possible we could create an extension but that would void Python's motto batteries included. In addition tools like pep8 and PyFlakes could be useful for other purposes as well. JayKrish is checking with the authors of pep8 about license issues. As always we will defer to the judgement of Core Developers and could pursue either option. [1] Wikipeida Microsoft Visual Studio, http://en.wikipedia.org/wiki/Microsoft_Visual_Studio#Code_editor [2] XCode, http://en.wikipedia.org/wiki/XCode -- status: pending - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18704 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18704] IDLE: PEP8 Style Check Integration
Todd Rovito added the comment: Raymond, Would you prefer PyFlakes instead? Try to consider IDLE being for beginners so they need all the help they can get. Advanced users can always turn the extension off. Thanks for your input. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18704 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18704] IDLE: PEP8 Style Check Integration
Changes by Todd Rovito rovit...@gmail.com: -- nosy: +terry.reedy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18704 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18787] Misleading error from getspnam function of spwd module
New submission from Vajrasky Kok: As root: $ sudo python3 [sudo] password for ethan: Python 3.2.3 (default, Apr 10 2013, 05:07:54) [GCC 4.7.2] on linux2 Type help, copyright, credits or license for more information. import spwd spwd.getspnam(I_don't_exist) Traceback (most recent call last): File stdin, line 1, in module KeyError: 'getspnam(): name not found' spwd.getspnam(bin) spwd.struct_spwd(sp_nam='bin', sp_pwd='*', sp_lstchg=15259, sp_min=0, sp_max=9, sp_warn=7, sp_inact=-1, sp_expire=-1, sp_flag=-1) As normal user: $ python3 Python 3.2.3 (default, Apr 10 2013, 05:07:54) [GCC 4.7.2] on linux2 Type help, copyright, credits or license for more information. import spwd spwd.getspnam(I_don't_exist) Traceback (most recent call last): File stdin, line 1, in module KeyError: 'getspnam(): name not found' spwd.getspnam(bin) Traceback (most recent call last): File stdin, line 1, in module KeyError: 'getspnam(): name not found' People can be confused. How could the name not found if the name actually exists? Attached the patch to differentiate the error whether the error is really 'name not found' or 'permission denied'. I use the error message from the getspnam manual: http://man7.org/linux/man-pages/man3/getspnam.3.html There is another error message from getspnam beside EACCES (permission denied), which is ERANGE, but I don't think we need to handle this. -- components: Extension Modules files: fix_error_message_getspnam.patch keywords: patch messages: 195678 nosy: vajrasky priority: normal severity: normal status: open title: Misleading error from getspnam function of spwd module type: behavior versions: Python 3.4 Added file: http://bugs.python.org/file31380/fix_error_message_getspnam.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18787 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18788] Proof of concept: implicit call syntax
New submission from Nick Coghlan: After watching one of the presenters at PyTexas struggle painfully with the fact print value doesn't work in Python 3, I decided I had to at least *try* to see if a general implicit call syntax was feasible within the constraints of the CPython parser. The attached patch shows that it is, indeed, possible to implement such a syntax by modifying the definition of expr_stmt to allow for an implicit trailing argument list (using the normal argument syntax). The key benefit of such a feature is that the following would once again be legal Python syntax: print Hello world! Ambiguous cases (such as expr * expr and expr ** expr) obey the rule that implicit calls are very *low* precedence, so you have to use parens to force the call interpretation. Similarly, a bare expression is not call - you must still append () to force a call without arguments. In addition to being a pain at the interactive prompt, the change of print from a statement to a function has also been noted as one of the biggest problems with compatibility of third party user scripts for Linux distros changing the default system Python to Python 3. This change would mean most Python 2 print statements either do nothing (no arguments), produce an unexpected trailing newline (trailing comma) or work exactly as they do in Python 2. Only those that use the Python 2 redirection syntax continue to trigger a syntax error in Python 3. While the *code* changes to achieve this behaviour turned out to be relatively small (most of the diff is in the autogenerated parser code), the documentation and general pedagogical impact could be substantially larger. If there's even an outside chance this could be accepted, I'm happy to work up a full PEP for it. -- files: implicit_call_statements.diff keywords: patch messages: 195679 nosy: gvanrossum, ncoghlan priority: normal severity: normal status: open title: Proof of concept: implicit call syntax Added file: http://bugs.python.org/file31381/implicit_call_statements.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18788 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18672] Fix format specifiers for debug output in _sre.c
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com: -- nosy: +Arfrever ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18672 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18684] Pointers point out of array bound in _sre.c
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com: -- nosy: +Arfrever ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18684 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
