Mailman 3 September 2015 - Python-Dev

The changes I am planning to NumPy I'd like to make only available on Python 3
by Travis Oliphant 12 Sep '15

12 Sep '15

If it helps anyone in their interest level. My intention would be to make these changes to NumPy only available on Python 3 as a way to help continue adoption of Python 3. -Travis -- *Travis Oliphant* *Co-founder and CEO* @teoliphant 512-222-5440 http://www.continuum.io

1 0

Looking for a developer who will work with me for at least 6 months to fix NumPy's dtype system.
by Travis Oliphant 12 Sep '15

12 Sep '15

Hi all, Apologies for cross-posting, but I need to get the word out and twitter doesn't provide enough explanation. I've been working on a second edition of my "Guide to NumPy" book. It's been a time-pressured activity, but it's helped me put more meat around my ideas for how to fix NumPy's dtype system -- which I've been contemplating off an on for 8 years. I'm pretty sure I know exactly how to do it --- in a way that fits more cleanly into Python. It will take 3-6 months and will have residual efforts needed that will last another 6 months --- making more types available with NumPy, improving calculations etc. This work will be done completely in public view and allow for public comment. It will not solve *all* of NumPy's problems, but it will put NumPy's dtype system on the footing it in retrospect should have been put on in the first place (if I had known then what I know now). It won't be a grandiose rewrite. It will be a pretty surgical fix to a few key places in the code. However, it will break the ABI and require recompilation of NumPy extensions (and so would need to be called NumPy 2.0). This is unavoidable, but I don't see any problem with breaking the ABI today given how easy it is to get distributions of Python these days from a variety of sources (including using conda --- but not only using conda). For those that remember what happened in Python dev land, the changes will be similar to when Guido changed Python 1.5.2 to Python 2.0. I can mentor and work closely with someone who will work on this and we will invite full participation and feedback from whomever in the community also wants to participate --- but I can't do it myself full time (and it needs someone full time+). Fortunately, I can pay someone to do it if they are willing to commit at least 6 months (it is not required to work at Continuum for this, but you can have a job at Continuum if you want one). I'm only looking for people who have enough experience with C or preferably the Python C-API. You also have to *want* to work on this. You need to be willing to work with me on the project directly and work to have a mind-meld with my ideas which will undoubtedly give rise to additional perspectives and ideas for later work for you. When I wrote NumPy 1.0, I put in 80+ hour weeks for about 6 months or more and then 60+ weeks for another year. I was pretty obsessed with it. This won't need quite that effort, but it will need something like it. Being able to move to Austin is a plus but not required. I can sponsor a visa for the right candidate as well (though it's not guaranteed you will get one with the immigration policies what they are). This is a labor of love for so many of us and my desire to help the dtype situation in NumPy comes from the same space that my desire to work on NumPy in the first place came. I will be interviewing people to work on this as not everyone who may want to will really be qualified to do it --- especially with so many people writing Cython these days instead of good-ole C-API code :-) Feel free to spread the news to anyone you can. I won't say more until I've found someone to work with me on this --- because I won't have the time to follow-up with any questions or comments. Even if I can't find someone I will publish the ideas --- but that also takes time and effort that is in short supply for me right now. If there is someone willing to fund this work, please let me know as well -- that could free up more of my time. Best, -Travis -- *Travis Oliphant* *Co-founder and CEO* @teoliphant 512-222-5440 http://www.continuum.io

1 0

Choosing an official stance towards module deprecation in Python 3
by Brett Cannon 12 Sep '15

12 Sep '15

There are two discussions going on in the issue tracker about deprecating some modules and it has led to the inevitable discussion of Python 2/3 compatibility (I'm not even going to bother mentioning the issue #s as this thread is not about the modules specifically but module deprecation in general). Because I'm tired of rehashing the same discussion every time a module deprecation comes up I would like to make an official decision that we can follow any time we decide to deprecate a module. The approaches to module deprecation I have seen are: 1. Nothing changes to the deprecation process; you deprecate a module and remove it in one to two releases 2. Deprecate the module but with no plans for removal until Python 2.7 reaches its EOL (I have been calling this Python 4) 3. Document the deprecation but no actual code deprecation I'm personally in the #2 camp. I want users to be fully aware that the module in question is not being updated and possibly not even getting non-critical bugfixes, but it's still there in Python 3 in order to make sure that you can have code which straddles Python 2 & 3 more easily. I don't like #1 because when the module exists in python 2.7 as it makes transitioning from Python 2 a bit harder. Leaving code in the stdlib as deprecated isn't going to kill us, especially if we make it clear the code only exists for transitioning purposes and you very well may have to work around any bugs you come across (and yes, this means changing my stance for the formatter module's deprecation). I don't like #3 because if you have an API memorized or you copied some code you found online you very well may not realize a module is deprecated. It's not difficult to silence a deprecation warning and you can make it so that even if you use -Werror your deprecated module imports continue to work without throwing an exception while all other deprecations do throw an exception. Whatever decision we come to I will update PEP 4 and then personally go through the various deprecated modules in Python 3.6 and tweak them as necessary to follow whatever policy we come up with.

10 15

Partial function application
by Herbert Kruitbosch 11 Sep '15

11 Sep '15

Dear developers, First of all, I'm a programmer for a data science company and I recently graduated. That being said, I have wondered why python does not have syntactical support (like syntax sugar) for partial function application. I think partial function application is a powerful concept, but also think that the implementation in functional.partial as described here: https://www.python.org/dev/peps/pep-0309/ is too verbose. Moreover I think the functional programming paradigm is a powerful one in general, especially when implemented as much as possible in an iterative language as python avoiding the typical problems we have with purely functional languages like Haskell. An plea for this concept is that, for example, small pieces Haskell (or functional) code can be extremely expressive and concise. I was wondering if there are considerations for including partial function application syntactically. I very often find myself writing statements as: data_sorted = sort(data, key = lambda x: x[0]) where I would prefer data_sorted = sort(data, key = #1[0]) where the #1 is similar to the one used in Mathematica for the same purpose. That is, an expression with #1 becomes an anonymous function which takes one argument, and, obviously, if a #n is included, the anonymous function takes n arguments. Notice that #1[0] does not seem like partial function application, however it is if you (C++'isly) assume that the deference operation [] is a function dereference(subscriptable, subscript). Obviously, I am only expecting that you get these type of suggestions all the time and that there is a good change you do not find it adequate for many reasons, for example keeping the language compact. I this case, I would also like to hear so. Yours sincerely and thank you in advance, Herbert

3 3

Summary of Python tracker Issues
by Python tracker 11 Sep '15

11 Sep '15

ACTIVITY SUMMARY (2015-09-04 - 2015-09-11) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open 5076 (+19) closed 31753 (+49) total 36829 (+68) Open issues with patches: 2258 Issues opened (46) ================== #8232: webbrowser.open incomplete on Windows http://bugs.python.org/issue8232 reopened by larry #24199: Idle: remove idlelib.idlever.py and its use in About dialog http://bugs.python.org/issue24199 reopened by terry.reedy #25001: Make --nowindows argument to regrtest propagate when running w http://bugs.python.org/issue25001 opened by brett.cannon #25002: Deprecate asyncore/asynchat http://bugs.python.org/issue25002 opened by gvanrossum #25003: os.urandom() should call getrandom(2) not getentropy(2) on Sol http://bugs.python.org/issue25003 opened by jbeck #25006: List pybind11 binding generator http://bugs.python.org/issue25006 opened by wenzel #25007: Add support of copy protocol to zlib compressors and decompres http://bugs.python.org/issue25007 opened by serhiy.storchaka #25008: Deprecate smtpd http://bugs.python.org/issue25008 opened by brett.cannon #25011: Smarter rl complete: hide private and special names http://bugs.python.org/issue25011 opened by serhiy.storchaka #25012: pathlib should allow converting to absolute paths without reso http://bugs.python.org/issue25012 opened by mu_mind #25013: run_pdb() in test_pdb.py always returns stderr as None http://bugs.python.org/issue25013 opened by xdegaye #25015: Idle: scroll Text faster with mouse wheel http://bugs.python.org/issue25015 opened by terry.reedy #25017: htmllib deprecated: Which library to use? Missing sane default http://bugs.python.org/issue25017 opened by guettli #25020: IDLE - centralize ui policies and small utilities http://bugs.python.org/issue25020 opened by markroseman #25021: product_setstate() Out-of-bounds Read http://bugs.python.org/issue25021 opened by JohnLeitch #25023: time.strftime('%a'), ValueError: embedded null byte, in ko loc http://bugs.python.org/issue25023 opened by sy LEE #25024: Allow passing "delete=False" to TemporaryDirectory http://bugs.python.org/issue25024 opened by Antony.Lee #25026: (FreeBSD/OSX) Fix fcntl module to accept 'unsigned long' type http://bugs.python.org/issue25026 opened by koobs #25027: Python 3.5.0rc3 on Windows can not load more than 127 C extens http://bugs.python.org/issue25027 opened by cgohlke #25031: IDLE - file list improvements http://bugs.python.org/issue25031 opened by markroseman #25032: IDLE - same menubar across application http://bugs.python.org/issue25032 opened by markroseman #25034: string.Formatter accepts empty fields but displays wrong when http://bugs.python.org/issue25034 opened by anthon #25035: Getter/setter for argparse keys http://bugs.python.org/issue25035 opened by Sworddragon #25036: IDLE - infrastructure changes so editors don't assume they're http://bugs.python.org/issue25036 opened by markroseman #25039: Docs: Link to Stackless Python in Design and History FAQ secti http://bugs.python.org/issue25039 opened by Winterflower #25040: xml.sax.make_parser makes bad use of parser_list argument defa http://bugs.python.org/issue25040 opened by Gautier Portet #25041: document AF_PACKET socket address format http://bugs.python.org/issue25041 opened by Tim.Tisdall #25042: Create an "embedding SDK" distribution? http://bugs.python.org/issue25042 opened by paul.moore #25043: document socket constants for Bluetooth http://bugs.python.org/issue25043 opened by Tim.Tisdall #25044: bring BTPROTO_SCO inline with other Bluetooth protocols http://bugs.python.org/issue25044 opened by Tim.Tisdall #25045: smtplib throws exception TypeError: readline() http://bugs.python.org/issue25045 opened by phlambotte #25047: xml.etree.ElementTree encoding declaration should be capital ( http://bugs.python.org/issue25047 opened by zimeon #25049: Strange behavior under doctest: staticmethods have different _ http://bugs.python.org/issue25049 opened by jneb #25050: windows installer does not allow 32 and 64 installs side by si http://bugs.python.org/issue25050 opened by Adam.Groszer #25053: Possible race condition in Pool http://bugs.python.org/issue25053 opened by Stanislaw Izaak Pitucha #25054: Capturing start of line '^' http://bugs.python.org/issue25054 opened by Alcolo Alcolo #25056: no support for Bluetooth LE in socket http://bugs.python.org/issue25056 opened by Tim.Tisdall #25057: Make parameter of io.base to be positional and keyword http://bugs.python.org/issue25057 opened by introom #25058: Right square bracket argparse metavar http://bugs.python.org/issue25058 opened by cortopy #25059: Mistake in input-output tutorial regarding print() seperator http://bugs.python.org/issue25059 opened by Saimadhav.Heblikar #25061: Add native enum support for argparse http://bugs.python.org/issue25061 opened by desbma #25063: shutil.copyfileobj should internally use os.sendfile when poss http://bugs.python.org/issue25063 opened by desbma #25064: Adjust tempfile documentation for bytes filename support http://bugs.python.org/issue25064 opened by martin.panter #25066: Better repr for multiprocessing.synchronize objects http://bugs.python.org/issue25066 opened by davin #25068: The proxy key's string should ignore case. http://bugs.python.org/issue25068 opened by Chuang Cao #25070: Python 2.6 - Python 3.4 allows unparenthesized generator with http://bugs.python.org/issue25070 opened by ztane Most recent 15 issues with no replies (15) ========================================== #25064: Adjust tempfile documentation for bytes filename support http://bugs.python.org/issue25064 #25056: no support for Bluetooth LE in socket http://bugs.python.org/issue25056 #25049: Strange behavior under doctest: staticmethods have different _ http://bugs.python.org/issue25049 #25036: IDLE - infrastructure changes so editors don't assume they're http://bugs.python.org/issue25036 #25032: IDLE - same menubar across application http://bugs.python.org/issue25032 #25020: IDLE - centralize ui policies and small utilities http://bugs.python.org/issue25020 #25007: Add support of copy protocol to zlib compressors and decompres http://bugs.python.org/issue25007 #25006: List pybind11 binding generator http://bugs.python.org/issue25006 #24997: mock.call_args compares as equal and not equal http://bugs.python.org/issue24997 #24985: Python install test fails - OpenSSL - "dh key too small" http://bugs.python.org/issue24985 #24970: Make distutils.Command an ABC http://bugs.python.org/issue24970 #24942: Remove domain from ipaddress.reverse_pointer property and add http://bugs.python.org/issue24942 #24940: RotatingFileHandler uses tell in non-binary mode to determine http://bugs.python.org/issue24940 #24936: Idle: handle 'raise' properly when running with subprocess (2. http://bugs.python.org/issue24936 #24925: Allow doctest to find line number of __test__ strings if forma http://bugs.python.org/issue24925 Most recent 15 issues waiting for review (15) ============================================= #25066: Better repr for multiprocessing.synchronize objects http://bugs.python.org/issue25066 #25064: Adjust tempfile documentation for bytes filename support http://bugs.python.org/issue25064 #25057: Make parameter of io.base to be positional and keyword http://bugs.python.org/issue25057 #25043: document socket constants for Bluetooth http://bugs.python.org/issue25043 #25036: IDLE - infrastructure changes so editors don't assume they're http://bugs.python.org/issue25036 #25034: string.Formatter accepts empty fields but displays wrong when http://bugs.python.org/issue25034 #25031: IDLE - file list improvements http://bugs.python.org/issue25031 #25027: Python 3.5.0rc3 on Windows can not load more than 127 C extens http://bugs.python.org/issue25027 #25021: product_setstate() Out-of-bounds Read http://bugs.python.org/issue25021 #25013: run_pdb() in test_pdb.py always returns stderr as None http://bugs.python.org/issue25013 #25011: Smarter rl complete: hide private and special names http://bugs.python.org/issue25011 #25003: os.urandom() should call getrandom(2) not getentropy(2) on Sol http://bugs.python.org/issue25003 #24988: IDLE: debugger context menus not working on Mac http://bugs.python.org/issue24988 #24982: shutil.make_archive doesn't archive empty directories http://bugs.python.org/issue24982 #24980: Allow for providing 'on_new_thread' callback to 'concurrent.fu http://bugs.python.org/issue24980 Top 10 most discussed issues (10) ================================= #23517: datetime.utcfromtimestamp rounds results incorrectly http://bugs.python.org/issue23517 52 msgs #25002: Deprecate asyncore/asynchat http://bugs.python.org/issue25002 17 msgs #25027: Python 3.5.0rc3 on Windows can not load more than 127 C extens http://bugs.python.org/issue25027 17 msgs #24999: Segfault in test_re.test_sre_character_class_literals() when P http://bugs.python.org/issue24999 16 msgs #25003: os.urandom() should call getrandom(2) not getentropy(2) on Sol http://bugs.python.org/issue25003 15 msgs #23551: IDLE to provide menu link to PIP gui. http://bugs.python.org/issue23551 12 msgs #8232: webbrowser.open incomplete on Windows http://bugs.python.org/issue8232 9 msgs #24915: Profile Guided Optimization improvements (better training, llv http://bugs.python.org/issue24915 9 msgs #22980: C extension naming doesn't take bitness into account http://bugs.python.org/issue22980 8 msgs #24965: Implement PEP 498: Literal String Formatting http://bugs.python.org/issue24965 8 msgs Issues closed (48) ================== #15989: Possible integer overflow of PyLong_AsLong() results http://bugs.python.org/issue15989 closed by serhiy.storchaka #16180: cannot quit pdb when there is a syntax error in the debuggee ( http://bugs.python.org/issue16180 closed by terry.reedy #17849: Missing size argument in readline() method for httplib's class http://bugs.python.org/issue17849 closed by martin.panter #23144: html.parser.HTMLParser: setting 'convert_charrefs = True' lead http://bugs.python.org/issue23144 closed by ezio.melotti #23406: interning and list comprehension leads to unexpected behavior http://bugs.python.org/issue23406 closed by martin.panter #23415: add-to-pydotorg does not support .exe installers for Windows http://bugs.python.org/issue23415 closed by larry #24225: Idlelib: changing file names http://bugs.python.org/issue24225 closed by terry.reedy #24272: PEP 484 docs http://bugs.python.org/issue24272 closed by gvanrossum #24305: The new import system makes it inconvenient to correctly issue http://bugs.python.org/issue24305 closed by larry #24488: ConfigParser.getboolean fails on boolean options http://bugs.python.org/issue24488 closed by lukasz.langa #24585: Windows installer does not detect existing installs http://bugs.python.org/issue24585 closed by steve.dower #24635: test_typing is flaky http://bugs.python.org/issue24635 closed by larry #24684: socket.getaddrinfo(host) doesn't ensure that host.encode() ret http://bugs.python.org/issue24684 closed by haypo #24748: Change of behavior for importlib between 3.4 and 3.5 with DLL http://bugs.python.org/issue24748 closed by larry #24889: Idle: always start with focus http://bugs.python.org/issue24889 closed by terry.reedy #24910: Windows MSIs don't have unique display names http://bugs.python.org/issue24910 closed by steve.dower #24912: The type of cached objects is mutable http://bugs.python.org/issue24912 closed by gvanrossum #24917: time_strftime() Buffer Over-read http://bugs.python.org/issue24917 closed by steve.dower #24938: Measure if _warnings.c is still worth having http://bugs.python.org/issue24938 closed by brett.cannon #24956: Default value for an argument that is not in the choices list http://bugs.python.org/issue24956 closed by r.david.murray #24957: python -m pdb error.py: stuck in unexitable infinite prompt l http://bugs.python.org/issue24957 closed by terry.reedy #24969: functools.lru_cache: a way to set decorator arguments at runti http://bugs.python.org/issue24969 closed by rhettinger #24984: document AF_BLUETOOTH socket address formats http://bugs.python.org/issue24984 closed by berker.peksag #25000: _mock_call does not properly grab args and kwargs http://bugs.python.org/issue25000 closed by michael.foord #25004: test_mmap should catch f.close() failure in LargeMmapTests._ma http://bugs.python.org/issue25004 closed by martin.panter #25005: webbrowser breaks on query strings with multiple fields on Win http://bugs.python.org/issue25005 closed by larry #25009: queue.Queue() does not validate the maxsize argument http://bugs.python.org/issue25009 closed by rhettinger #25010: minor typo in PCBuild readme.txt http://bugs.python.org/issue25010 closed by python-dev #25014: Add contextlib.itercm() http://bugs.python.org/issue25014 closed by ncoghlan #25016: defaultdict's pop gives a KeyError http://bugs.python.org/issue25016 closed by r.david.murray #25018: test_shutil.test_make_archive() fails on Windows 8.1 http://bugs.python.org/issue25018 closed by serhiy.storchaka #25019: xmlparse_setattro() Type Confusion http://bugs.python.org/issue25019 closed by serhiy.storchaka #25022: Remove PC/example_nt/ http://bugs.python.org/issue25022 closed by python-dev #25025: Missing 3.5.0 RC3 tarballs (FTP) on Fastly nodes http://bugs.python.org/issue25025 closed by berker.peksag #25028: Reading unicode json string fails depending on LANG env http://bugs.python.org/issue25028 closed by martin.panter #25029: MemoryError in test_strptime http://bugs.python.org/issue25029 closed by steve.dower #25030: io.[Text]IOBase.seek doesn't take keyword parameter http://bugs.python.org/issue25030 closed by martin.panter #25033: Python 2.7.10 make - fails on some Standard Library Modules http://bugs.python.org/issue25033 closed by r.david.murray #25037: ValueError: invalid literal for int() with base 16: b'[\r\n' http://bugs.python.org/issue25037 closed by martin.panter #25038: test_os.TestSendfile.test_keywords() introduced a regression http://bugs.python.org/issue25038 closed by martin.panter #25046: ImportError: No module named Multiprocessing http://bugs.python.org/issue25046 closed by r.david.murray #25048: %e Directive Missing in Datetime Documentation http://bugs.python.org/issue25048 closed by r.david.murray #25051: 'compile' refuses BOM. http://bugs.python.org/issue25051 closed by eryksun #25060: BUILD_MAP stack effect suboptimal http://bugs.python.org/issue25060 closed by python-dev #25062: Doc linter error: [2] library/typing.rst:358: default role us http://bugs.python.org/issue25062 closed by zach.ware #25065: https://docs.python.org/library should redirect to Python 3 do http://bugs.python.org/issue25065 closed by zach.ware #25067: Spam http://bugs.python.org/issue25067 closed by zach.ware #25069: Clean issue when generator not exhausted (garbage collector re http://bugs.python.org/issue25069 closed by r.david.murray

1 0

Re: [Python-Dev] cpython (3.5): whatsnew/3.5: Editorialization pass on library section
by Serhiy Storchaka 10 Sep '15

10 Sep '15

On 11.09.15 00:36, yury.selivanov wrote: > https://hg.python.org/cpython/rev/3265f33df731 > changeset: 97874:3265f33df731 > branch: 3.5 > parent: 97872:70c97a626c41 > user: Yury Selivanov <yselivanov(a)sprymix.com> > date: Thu Sep 10 17:35:38 2015 -0400 > summary: > whatsnew/3.5: Editorialization pass on library section > > Patch by Elvis Pranskevichus > io > -- > > -* New Python implementation of :class:`io.FileIO` to make dependency on > - ``_io`` module optional. > - (Contributed by Serhiy Storchaka in :issue:`21859`.) > +:class:`io.FileIO` has been implemented in Python which makes C implementation > +of :mod:`io` module entirely optional. (Contributed by Serhiy Storchaka > +in :issue:`21859`.) Unfortunately this is not true. Python implementation is required to make the _io module optional, but it is not enough. io and _pyio still depend from _io (issue17984). May be it is not worth to mention this change at all. End users unlikely will encounter Python implementation.

2 1

Yet another "A better story for multi-core Python" comment
by Gary Robinson 10 Sep '15

10 Sep '15

Folks, If it’s out of line in some way for me to make this comment on this list, let me know and I’ll stop! But I do feel strongly about one issue and think it’s worth mentioning, so here goes. I read the "A better story for multi-core Python” with great interest because the GIL has actually been a major hindrance to me. I know that for many uses, it’s a non-issue. But it was for me. My situation was that I had a huge (technically mutable, but unchanging) data structure which needed a lot of analysis. CPU time was a major factor — things took days to run. But even so, my time as a programmer was much more important than CPU time. I needed to prototype different algorithms very quickly. Even Cython would have slowed me down too much. Also, I had a lot of reason to want to make use of the many great statistical functions in SciPy, so Python was an excellent choice for me in that way. So, even though pure Python might not be the right choice for this program in a production environment, it was the right choice for me at the time. And, if I could have accessed as many cores as I wanted, it may have been good enough in production too. But my work was hampered by one thing: There was a huge data structure that all the analysis needed to access. Using a database would have slowed things down too much. Ideally, I needed to access this same structure from many cores at once. On a Power8 system, for example, with its larger number of cores, performance may well have been good enough for production. In any case, my experimentation and prototyping would have gone more quickly with more cores. But this data structure was simply too big. Replicating it in different processes used memory far too quickly and was the limiting factor on the number of cores I could use. (I could fork with the big data structure already in memory, but copy-on-write issues due to reference counting caused multiple copies to exist anyway.) So, one thing I am hoping comes out of any effort in the “A better story” direction would be a way to share large data structures between processes. Two possible solutions: 1) More the reference counts away from data structures, so copy-on-write isn’t an issue. That sounds like a lot of work — I have no idea whether it’s practical. It has been mentioned in the “A better story” discussion, but I wanted to bring it up again in the context of my specific use-case. Also, it seems worth reiterating that even though copy-on-write forking is a Unix thing, the midipix project appears to bring it to Windows as well. (http://midipix.org) 2) Have a mode where a particular data structure is not reference counted or garbage collected. The programmer would be entirely responsible for manually calling del on the structure if he wants to free that memory. I would imagine this would be controversial because Python is currently designed in a very different way. However, I see no actual risk if one were to use an @manual_memory_management decorator or some technique like that to make it very clear that the programmer is taking responsibility. I.e., in general, information sharing between subinterpreters would occur through message passing. But there would be the option of the programmer taking responsibility of memory management for a particular structure. In my case, the amount of work required for this would have been approximately zero — once the structure was created, it was needed for the lifetime of the process. Under this second solution, there would be little need to actually remove the reference counts from the data structures — they just wouldn’t be accessed. Maybe it’s not a practical solution, if only because of the overhead of Python needing to check whether a given structure is manually managed or not. In that case, the first solution makes more sense. In any case I thought this was worth mentioning, because it has been a real problem for me, and I assume it has been a real problem for other people as well. If a solution is both possible and practical, that would be great. Thank you for listening, Gary -- Gary Robinson garyrob(a)me.com http://www.garyrobinson.net

12 16

Can't post to bugs.python.org
by Serhiy Storchaka 10 Sep '15

10 Sep '15

I can't neither post a message to existing issue nor open a new issue. The irker854 bot on IRC channel #python-dev cites my message and the tracker updates activity time of existing issue, but doesn't show my message and doesn't reflect changes of status. Posting via e-mail doesn't work as well. Web server replies: An error has occurred A problem was encountered processing your request. The tracker maintainers have been notified of the problem. E-mail server replies: Subject: Failed issue tracker submission You are not a registered user. Please register at: http://bugs.python.org/user?@template=register ...before sending mail to the tracker.

2 2

Embedding Python 3.5
by Paul Moore 09 Sep '15

09 Sep '15

First of all, an apology. I know this is probably going to be of limited interest for many on python-dev, but I'm honestly not sure where there's a better audience for the question. As it's related to how people should use the new "embeddable" distribution of Python 3.5, I'm hoping it's sufficiently relevant - but if not, feel free to direct me to a better forum. I've been trying to use the new embeddable distribution to build a Windows installation of vim that includes a Python interpreter, rather than relying on the user having a system install of Python on PATH. This strikes me as precisely the sort of usage that the embeddable distribution would be great for. And indeed, it works fine for that. But when it comes to distribution, I have an issue. The problem is that for vim to find the Python DLL, it needs to be alongside vim.exe (there's a small complication here I'll come to later, but let's ignore that for now). So I unzip the embeddable distribution into the directory containing vim.exe. However, I want that directory on PATH (so I can run vim from the command line). Now, as the embeddable distribution includes python.exe, this pollutes my PATH with an extra copy of python, which may or may not be picked up in preference to my "real" python, depending on how I install python. That's bad - I can delete python.exe and pythonw.exe from my vim installation, but I still have a load of Python DLLs on PATH that could potentially mess up other Python installations on my machine (I honestly don't know how likely that is, particularly if I distribute my vim build to other users with different setups). What I'd like to do is to put the Python stuff in a subdirectory of the Vim installation, so it's safely isolated. In the case of vim, I can do this, as vim has an option to dynamically load the Python DLL via LoadLibrary, and I can patch vim to look in <vim dir>\python before searching PATH. But the LoadLibrary stuff is horribly fragile, and I doubt anyone else embedding Pthon in their application is likely to do that - they will probably just link to python35.dll at load-time. I'm not aware of any way to adjust the loader's search path for DLLs to include a subdirectory that's not on PATH, so it seems to me that there's no good way to avoid having the embeddable distribution visible via the user's PATH. For vim, I'll probably go for the dynamic loading approach with a patch to look in a subdirectory. But have I missed any other approaches that make an embedded Python more isolated from the user's system? Paul

3 4

Re: [Python-Dev] devguide: Drop myself from issue assignment list
by Serhiy Storchaka 09 Sep '15

09 Sep '15

On 28.06.15 09:14, nick.coghlan wrote: > https://hg.python.org/devguide/rev/452f840bac9f > changeset: 749:452f840bac9f > user: Nick Coghlan <ncoghlan(a)gmail.com> > date: Sun Jun 28 16:13:54 2015 +1000 > summary: > Drop myself from issue assignment list > > files: > experts.rst | 6 +++--- > 1 files changed, 3 insertions(+), 3 deletions(-) > > > diff --git a/experts.rst b/experts.rst > --- a/experts.rst > +++ b/experts.rst > @@ -1,4 +1,4 @@ > -.. _experts: > + .. _experts: Was this change made intentionally? May be it broke the completion in Nosy List on the tracker.

1 2