[issue15775] Add StopParser() to expat
Nemeskey Dávid added the comment: Amaury: see my previous comment. There are two problems with the method you proposed: 1. It is not mentioned in the documentation that exceptions are propagated through parse(). 2. Exceptions usually mean that an error has happened, and is not the preferred way for flow control (at least this is the policy in other languages e.g. Java, I don't know about Python). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15775 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15775] Add StopParser() to expat
Amaury Forgeot d'Arc added the comment: Your first point is true, even if the Python zen (try import this) states that Errors should never pass silently. For your second point: exceptions are a common thing in Python code. This is similar to the EAFP principle http://docs.python.org/glossary.html#term-eafp Also, this example http://docs.python.org/release/2.7.3/library/imp.html#examples shows that exceptions can be part of the normal flow control. -- assignee: - docs@python components: +Documentation nosy: +docs@python ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15775 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15868] leak in bytesio.c
New submission from Stefan Krah: Coverity found a leak in bytesio.c. Patch attached. -- components: Extension Modules files: bytesio_leak.diff keywords: patch messages: 169907 nosy: pitrou, skrah priority: normal severity: normal status: open title: leak in bytesio.c type: resource usage versions: Python 3.3 Added file: http://bugs.python.org/file27133/bytesio_leak.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15868 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11715] Building Python on multiarch Debian and Ubuntu
Ezio Melotti added the comment: Today I got the same problem on 3.2 too. I made a distclean and recompiled and got: Python build finished, but the necessary bits to build these modules were not found: _curses_curses_panel _dbm _gdbm _sqlite3 _ssl _tkinter bz2readline I tried to apply ma.diff and now I get: Python build finished, but the necessary bits to build these modules were not found: _curses_curses_panel _dbm _gdbm _tkinter bz2 -- nosy: +ezio.melotti status: closed - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11715 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15866] encode(..., 'xmlcharrefreplace') produces entities for surrogate pairs
Ezio Melotti added the comment: Attached patch against 3.2 seems to fix the problem. -- keywords: +patch stage: - patch review versions: +Python 3.2 Added file: http://bugs.python.org/file27134/issue15866.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15866 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15866] encode(..., 'xmlcharrefreplace') produces entities for surrogate pairs
Ezio Melotti added the comment: Note that there's similar code in charmap_encoding_error, PyUnicode_EncodeCharmap, PyUnicode_TranslateCharmap, and PyUnicode_EncodeDecimal, however I'm not sure how to reach these paths. -- nosy: +lemburg ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15866 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15869] Include .desktop file and icon
New submission from Dominik George: As a graphical application, IDLE, is shipped, a .desktop file should be included for intallation to /usr/share/applications. Furthermore, a 16x16 pixel version in XPM format of the Python icon should be shipped to accompany the menu entries. Attached is a tarball containing .desktop files for IDLE 2 and 3 as well as the icon. -- components: IDLE files: python-freedesktop-files.tar.bz2 messages: 169912 nosy: natureshadow priority: normal severity: normal status: open title: Include .desktop file and icon type: enhancement versions: Python 2.7, Python 3.2 Added file: http://bugs.python.org/file27135/python-freedesktop-files.tar.bz2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15869 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15866] encode(..., 'xmlcharrefreplace') produces entities for surrogate pairs
STINNER Victor added the comment:
Thanks to the PEP 393, this issue is already fixed in Python 3.3.
$ ./python
Python 3.3.0rc1+ (default:ba2c1def3710+, Sep 3 2012, 23:20:25)
[GCC 4.6.3 20120306 (Red Hat 4.6.3-2)] on linux
( u'\U0001f49d' ).encode('ascii', errors='xmlcharrefreplace')
b'#128157;'
--
nosy: +haypo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15866
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15775] Add StopParser(), ResumeParser, and GetParsingStatus to expat
Martin v. Löwis added the comment: Dávid: Another (similar) example is the Python for loop. In it's original form, it would increase an index and invoke __getitem__ until that *raised* IndexError. In the current definition, it converts the iterated-over object into an iterator, and keeps calling .next until that *raises* StopIteration. So raising an exception to indicate that something is finished is an established Python idiom. In any case, I still think adding StopParser is a useful addition, in particular since that would also allow giving True as the resumable argument. Any such change needs to be accompanied by also exposing XML_ResumeParser, and possibly XML_GetParsingStatus. Since we all agree that this is not an important change, I don't mind keeping this issue around until someone comes along to contribute code for it. -- title: Add StopParser() to expat - Add StopParser(), ResumeParser, and GetParsingStatus to expat ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15775 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1818] Add named tuple reader to CSV module
Changes by Ahsan Nawroj ahsan.naw...@gmail.com: -- nosy: +ainur0160 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1818 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1818] Add named tuple reader to CSV module
Changes by Ahsan Nawroj ahsan.naw...@gmail.com: -- nosy: -ainur0160 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1818 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11715] Building Python on multiarch Debian and Ubuntu
Ezio Melotti added the comment: 2.7 is affected too: Python build finished, but the necessary bits to build these modules were not found: _bsddb _curses_curses_panel _sqlite3 _ssl _tkinter bsddb185 bz2dbm gdbm readline sunaudiodev And after applying ma.diff: Python build finished, but the necessary bits to build these modules were not found: _bsddb _curses_curses_panel _tkinter bsddb185 bz2 dbmgdbm sunaudiodev -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11715 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14531] Backtrace should not attempt to open stdin file
Changes by Ahsan Nawroj ahsan.naw...@gmail.com: -- nosy: +ainur0160 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14531 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15867] It's hard to decypher how to build off of the provided objects from the importlib docs
Changes by Antoine Pitrou pit...@free.fr: -- nosy: +brett.cannon, ncoghlan ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15867 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15863] Fine-grained info about Python versions which support changes introduced in micro releases
Andrew Svetlov added the comment: Hash randomization is security patch. It is applied to 2.6.8, 2.7.3, 3.2.3 and 3.3. Python doc should not enumerate all affected releases. For example, if you read docs for 2.6 branch it shows you 2.6.8 version only and that's ok. -- nosy: +asvetlov ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15863 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15863] Fine-grained info about Python versions which support changes introduced in micro releases
Alexander Konovalenko added the comment: Andrew, I don't get it. :( Why not? The docs for Python 2.7 generally inform the reader in which Python version every feature appeared. That's really helpful if your code should run on earlier version of Python. You don't have to dig through the docs for older Python releases and compare them one to another; you can just read the latest docs and all information is there. How is the security patch case different? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15863 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15591] when building the extensions, stdout is lost when stdout is redirected
Christian Heimes added the comment: The fix doesn't work for me. With make -s I still see the output to stdout. Also there are much simpler ways to test for MAKEFLAGS: ifneq (,$(findstring s,$(MAKEFLAGS))) QUIET=-q else QUIET= endif then use $(QUIET) in the call to setup.py -- nosy: +christian.heimes resolution: fixed - status: closed - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15591 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15591] when building the extensions, stdout is lost when stdout is redirected
Matthias Klose added the comment: @benjamin: no, the extensions were never built in parallel @christian: no, that again would match the `s' when you have something like --jobserver in MAKEFLAGS. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15591 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15863] Fine-grained info about Python versions which support changes introduced in micro releases
Andrew Svetlov added the comment: Well, I can try to make patch. Please note: versionadded tag accepts only single version argument, you have to use couple of tags which looks weird. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15863 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15591] when building the extensions, stdout is lost when stdout is redirected
Christian Heimes added the comment: Ah, got it. GNU sorts the arguments in MAKEFLAGS. The s flag is always in the first word. $ make -j4 -s s --jobserver-fds=3,4 -j $ make --quiet -j4 s --jobserver-fds=3,4 -j This make code works well for me: ifeq (s,$(findstring s,$(word 1,$(MAKEFLAGS QUIET=-q else QUIET= endif I've attached a patch that also fixes the quiet option for ctypes configure script. -- Added file: http://bugs.python.org/file27136/quiet.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15591 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15591] when building the extensions, stdout is lost when stdout is redirected
Matthias Klose added the comment: even if you pass other options to make, and -s not as the first flag? and does this work for other makes different than GNU make too? But maybe we already require GNU make. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15591 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15591] when building the extensions, stdout is lost when stdout is redirected
Christian Heimes added the comment: The lines under each of my examples are the content of $MAKEFLAGS. It works when I pass the option in a different order and even with alternative spellings for -s like --quiet. It's always the s flag: $ make -s --jobs=4 s --jobserver-fds=3,4 -j $ make --jobs=4 --silent s --jobserver-fds=3,4 -j $ make --jobs=4 --quiet s --jobserver-fds=3,4 -j $ make --jobs=4 --quiet -n echo 'sn --jobserver-fds=3,4 -j' With just the -j flag $MAKEFLAGS starts with a space so the first word is empty: $ make -j4 --jobserver-fds=3,4 -j I don't know if other make implementations work similar but I think we require GNU Make, too. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15591 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15867] It's hard to decypher how to build off of the provided objects from the importlib docs
Eric Snow added the comment: As far as the import system goes, Barry Warsaw added a really nice page to the language reference[1]. However, it sounds like your concern is with taking advantage of the tools that importlib provides. First of all, a good thing to recognize is that importlib Python 3.3 exposes a much richer public API, including exposing the default import machinery. While importlib.abc is meaningful, importlib.machinery is more useful in your case. In versions prior to 3.3, things aren't as easy. In other Python 3 versions one approach you could take is to **carefully** use the private importlib APIs to get what you want. If you do that, I'd recommend that your code target the public 3.3 APIs and then write a wrapper around the earlier private APIs to get them to be compatible. There really shouldn't be a lot of difference. The key is to target Python 3.3's importlib. For Python 2, I'd still recommend targeting 3.3's importlib API and writing wrappers to make that work. This would likely involve more effort to backport whole chunks of the 3.3 importlib implementation. Better to simply port your code to Python 3. :) Secondly, the import system is a complex piece of machinery. The new reference that Barry did helps pull it all together, but there are simply a lot of moving parts in various layers. Adding examples for the importlib API may help for working with that API, but any activities in hooking into the import system should be done with a firm understanding of how it works since it's easy to break things. Currently there isn't any easy way around that and I doubt any of that will change for a long time (due to the effort required). Lastly, take a look at pylt[2]. It's a project I'm working on for source-to-source translation that hooks into the import system. Though it isn't finished yet, the import side of things is mostly done. Hopefully I'll have all the tests done in the next few days. For pylt I've made use of the 3.3 importlib API along with a couple of things that we should see in 3.4 that I've backported [3]. The code there should give you an idea of how I've done essentially what you are looking to do. Ultimately, any recommendations you can give on making the import system more approachable would be awesome. Though it will take a lot of thought, discussion, and effort to make the import system easy, there is still a lot of room for improvement in making it understandable. Your perspective would be meaningful in working toward a sensible improvement. [1] http://docs.python.org/dev/reference/import.html [2] https://bitbucket.org/ericsnowcurrently/pylt/ [3] http://bugs.python.org/issue15627 -- nosy: +eric.snow ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15867 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15868] leak in bytesio.c
Benjamin Peterson added the comment: LGTM -- nosy: +benjamin.peterson ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15868 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15870] PyType_FromSpec should take metaclass as an argument
New submission from Alexander Belopolsky: PyType_FromSpec() is a convenient function to create types dynamically in C extension modules, but its usefulness is limited by the fact that it creates new types using the default metaclass. I suggest adding a new C API function PyObject *PyType_FromSpecEx(PyObject *meta, PyType_Spec *spec) and redefine PyType_FromSpec() as PyType_FromSpecEx((PyObject *)PyType_Type, spec) This functionality cannot be implemented by user because PyType_FromSpec requires access to private slotoffsets table. A (trivial) patch attached. -- assignee: belopolsky components: Interpreter Core files: typeobject.diff keywords: needs review, patch messages: 169925 nosy: belopolsky, loewis priority: normal severity: normal stage: test needed status: open title: PyType_FromSpec should take metaclass as an argument type: enhancement versions: Python 3.4 Added file: http://bugs.python.org/file27137/typeobject.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15870 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15867] It's hard to decypher how to build off of the provided objects from the importlib docs
Brett Cannon added the comment: First off, what you want to do isn't easy to begin with. =) You are right that you want get_code() and that SourceLoader is what you want. The problem is that importlib inherited PEP 302s APIs, and there are so many that the docs don't repeat themselves in terms of what methods each ABC implements in order to keep the docs readable. That makes it a little difficult to realize what ABCs implement what without reading the class description and/or looking at the class hierarchy layout to realize that SourceLoader implements ResourceLoader which specifies get_code(). Second, import is just plain hard. It took me over 5 years to write importlib and get it to where it is now, and most of that work was just trying to keep it all straight in my head. This also makes writing an example or two difficult as it becomes a massive undertaking very quickly. And there is the simple issue that everyone wants something different, e.g. you want to transform source while others want an alternative back-end storage solution. That means coming up with the right examples is hard in and of itself. Third, in Python 3.4 your desire to transform source will be much easier to achieve thanks to http://bugs.python.org/issue15627 . IOW, I understand your pain but solving the problem is hard without writing a book on the subject (which who knows, maybe I'll do someday as a $1 ebook or something). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15867 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15591] when building the extensions, stdout is lost when stdout is redirected
Roundup Robot added the comment: New changeset 048e13546a7c by Christian Heimes in branch '3.2': Issue #15591: run ctypes' configure in quiet mode when setup.py runs silently http://hg.python.org/cpython/rev/048e13546a7c New changeset e5569b03a287 by Christian Heimes in branch 'default': Issue #15591: run ctypes' configure in quiet mode when setup.py runs silently http://hg.python.org/cpython/rev/e5569b03a287 New changeset 962e8b2a39f3 by Christian Heimes in branch '2.7': Issue #15591: run ctypes' configure in quiet mode when setup.py runs silently http://hg.python.org/cpython/rev/962e8b2a39f3 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15591 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15870] PyType_FromSpec should take metaclass as an argument
Amaury Forgeot d'Arc added the comment: The patch is a bit light: see how type_new also computes the metaclass from the base classes. -- nosy: +amaury.forgeotdarc ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15870 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15870] PyType_FromSpec should take metaclass as an argument
Alexander Belopolsky added the comment: On Thu, Sep 6, 2012 at 12:44 PM, Amaury Forgeot d'Arc rep...@bugs.python.org wrote: The patch is a bit light: see how type_new also computes the metaclass from the base classes. This was intentional. I was looking for a lightweight facility to create heap types. I know metaclass when I call PyType_FromSpec. If i wanted to invoke the metaclass from the base classes logic, I would just specify an appropriate base class in the spec. This would still leave an open problem of specifying the metatype for the most basic class. This is the problem I am trying to solve. -- nosy: +Alexander.Belopolsky ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15870 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15871] Online docs: make index search always available.
New submission from Terry J. Reedy: For the Windows Help version of the docs, the left side box has 4 tabs: Contents, Index, Search, Favorites. I now mostly use the Index tab. That means that I can enter an indexed keyword, topic, or object name and jump from place to place in the docs. The left margin of the online docs only has a text search box equivalent to the Windows search tab (which I essentially never use). The index is only available on the front page, possibly not even visible without scrolling. Consequently, people, especially beginners, tend to use the text search box when they should be using the index. The result is often useless. The issue came up on python-list about a beginner entering 'print' and getting nothing useful. With the Windows doc, 'print' in the index search immediately brings up print (builtin function) (twice, I did not look into why). The same thing in the search lists 153 pages, with the builtin functions page at 75. Not too surprising, as it is a long page with only 3 occurrences of 'print'. Also not useful. So I think the online docs should also have an always available index search box in addition to the text search box (which should be properly labeled as such). 'Enter a module, class, for function name.' should be applied to index search, not text search. An alternative is for the one box to give both index search results and text search results, but doing the latter when one only wants the former is a waste of both server and reader resources. -- assignee: docs@python components: Documentation messages: 169930 nosy: docs@python, eric.araujo, ezio.melotti, georg.brandl, terry.reedy priority: normal severity: normal status: open title: Online docs: make index search always available. type: enhancement versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15871 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15871] Online docs: make index search always available.
R. David Murray added the comment: The index is available on every page via the link in the upper right corner. An index-specific search might be interesting, though I usually just click the 'index on one page' link and do a text search. But that is a two step process and doesn't give a nice list of hits. I don't think I ever use the text search box, either. I just use google. -- nosy: +r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15871 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15871] Online docs: make index search always available.
Ezio Melotti added the comment: I find the current search quite useless. I think index search with a fallback on text search when there are no results would be better. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15871 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15642] Integrate pickle protocol version 4 GSoC work by Stefan Mihaila
Antoine Pitrou added the comment: Are there also some known techniques on tracking down memory leaks? Nothing more than the usual debugging techniques. It is more of a matter of taste whether you like to add print() (or printf ;-)) calls, or set breakpoints in an actual debugger. i.e. pickle.dumps(3.0+1j, 4) leaks but pickle.dumps(3.0+1j, 3) does not. Well it looks like you've narrowed things down a bit here. However, there appears to be no difference in the code that gets executed in v3 to the one executed in v4. Even the differences in memoization? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15642 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15871] Online docs: make index search always available.
Terry J. Reedy added the comment: I am not the only person who finds the 4 lines of Quick search [ ] [go] Enter search terms or a module, class or function name. more eye-catching than the more useful modules | index in the corner. It is not even obvious what those are about. They are in black 'I am not a link' text until the mouse goes over them. So lets make them more prominent. Second, no one finds the current, eye-catching Quick search very useful. For naive beginners, it seems to be off-putting. The python-list thread is python docs search for 'print'. So lets change it. Combining these ideas, my revised suggestion is: Move the upper right entries to the sidebar above Quick search and expand and capitalize them so the sidebar would then look like Module index General index Quick search [ ]... where the quick search is actually initially quick by first searching only the general index (Ezio's variation). (I am assuming that all modules are in the general index also). If something is found, it reports Index entries found: and only offers Click here to do a full text search. If nothing is in the index, report No index entries found, doing a full text search ... (This would still not be as good as the Windows doc, where the index tab starts with the entire index list and responds as each character is entered. That catches typos as mistyped. This would best be done by client-side javascript after loading the entire index list.) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15871 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15872] shutil.rmtree(..., ignore_errors=True) doesn't ignore all errors
New submission from Jakub Wilk:
This used to work correctly in Python 3.2:
Python 3.3.0rc1 (default, Aug 29 2012, 00:39:20)
[GCC 4.7.1] on linux
Type help, copyright, credits or license for more information.
import shutil
shutil.rmtree('/etc/fstab', ignore_errors=True)
Traceback (most recent call last):
File stdin, line 1, in module
File /usr/lib/python3.3/shutil.py, line 456, in rmtree
Not a directory: '{}'.format(path))
NotADirectoryError: [Errno 20] Not a directory: '/etc/fstab'
--
messages: 169936
nosy: jwilk
priority: normal
severity: normal
status: open
title: shutil.rmtree(..., ignore_errors=True) doesn't ignore all errors
type: behavior
versions: Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15872
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15871] Online docs: make index search always available.
Stefan Krah added the comment: I like the quick search: It works very well for function names. For the use cases mentioned here I use Google. I never use the index, so for me personally the positioning of the quick search box is perfect. -- nosy: +skrah ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15871 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15861] ttk.Treeview unmatched open brace in list
Bryan Oakley added the comment:
I gave myself an hour or so to play around with this, and the crux of the
matter seems to be in the function `_format_optdict()` which converts a
dictionary of options and values into something suitable to pass to
`tk.call()`. However, I think the same bug is in other `_format*` functions as
well, it's just that their nature is such that they have much less of a chance
to be passed weird data.
`_format_optdict` has some code that does a half-hearted attempt at handling
values that are tuples, such as the case with the values attribute of the
ttk.Treeview widget. However, all it does is protect values that have a space,
by surrounding the value with curly braces. Hence, when the value itself has a
curly brace, tcl throws the unmatched open brace error.
What is needed is to create a bona fide tcl list element according to the rules
of Tcl. I tried a hack where I simply escaped all problem characters, so
instead of returning `{foo bar}` the function returns `foo\ bar`. This seemed
to work, at least for the tiny bit of testing that I did. Another solution
might be to do something like tk.call(list,*the_tuple), though sadly,
`_format_optdict` is a function rather than a method so it doesn't have access
to the tcl interpreter.
What I think ttk needs (and may already exist somewhere in the Tkinter world; I
haven't looked...) is a function that takes a tuple and converts it to a
canonical list. Then, the places that do something ad hoc can all call this one
function.
For more information on the gory details of the string representation of a list
see http://www.tcl.tk/cgi-bin/tct/tip/407.html
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15861
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15870] PyType_FromSpec should take metaclass as an argument
Changes by Alexander Belopolsky alexander.belopol...@gmail.com: -- nosy: +Robin.Schreiber ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15870 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7682] Optimisation of if with constant expression
STINNER Victor added the comment: I'm working on a different approach: an AST optimizer. It is already able to replace if __debug__ and x: with if x: ... (pythonenv option must be enabled). https://bitbucket.org/haypo/astoptimizer/ -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7682 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15870] PyType_FromSpec should take metaclass as an argument
Alexander Belopolsky added the comment: see how type_new also computes the metaclass from the base classes. As you can see from my first message, I originally considered PyType_FromSpecEx(PyObject *meta, PyType_Spec *spec) without bases. (In fact I was unaware of the recent addition of PyType_FromSpecWithBases.) Maybe the original signature makes more sense than the one in the patch. Explicitly setting a metaclass is most useful for the most basic type. On the other hand, a fully general function may eventually replace both PyType_FromSpec and PyType_FromSpecWithBases for most uses. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15870 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15873] datetime cannot parse ISO 8601 dates and times
New submission from John Nagle: The datetime module has support for output to a string of dates and times in ISO 8601 format (2012-09-09T18:00:00-07:00), with the object method isoformat([sep]). But there's no support for parsing such strings. A string to datetime class method should be provided, one capable of parsing at least the RFC 3339 subset of ISO 8601. The problem is parsing time zone information correctly. The allowed formats for time zone are empty - no TZ, date/time is naive in the datetime sense Z - zero, or Zulu time, i.e. UTC. [+-]nn.nn - offset from UTC strptime does not understand timezone offsets. The datetime documentation suggests that the z format directive handles time zone info, but that's not actually implemented for input. Pypi has four modules for parsing ISO 8601 dates. Each has least one major problem in time zone handling: iso8601 0.1.4 Abandonware. Mishandles time zone when time zone is Z and the default time zone is specified. iso8601.py 0.1dev Always returns a naive datetime object, even if zone specified. iso8601plus 0.1.6 Fork of abandonware version above. Same bug. zc.iso8601 0.2.0 Zope version. Imports the pytz module with the full Olsen time zone database, but doesn't actually use that database. Thus, nothing in Pypi provides a good alternative. It would be appropriate to handle this in the datetime module. One small, correct, tested function would be better than the existing five bad alternatives. -- components: Library (Lib) messages: 169941 nosy: nagle priority: normal severity: normal status: open title: datetime cannot parse ISO 8601 dates and times type: enhancement versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15873 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15870] PyType_FromSpec should take metaclass as an argument
Martin v. Löwis added the comment: What is your use case for this API? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15870 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15873] datetime cannot parse ISO 8601 dates and times
Changes by STINNER Victor victor.stin...@gmail.com: -- nosy: +belopolsky ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15873 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15873] datetime cannot parse ISO 8601 dates and times
Changes by R. David Murray rdmur...@bitdance.com: -- versions: -Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15873 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15873] datetime cannot parse ISO 8601 dates and times
Changes by R. David Murray rdmur...@bitdance.com: -- nosy: +r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15873 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15870] PyType_FromSpec should take metaclass as an argument
Alexander Belopolsky added the comment: On Sep 6, 2012, at 5:10 PM, Martin v. Löwis rep...@bugs.python.org wrote: What is your use case for this API? I can describe my use case, but it is somewhat similar to ctypes. I searched the tracker for a PEP 3121 refactoring applied to ctypes and could not find any. I'll try to come up with a PEP 3121 patch for ctypes using the proposed API. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15870 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15870] PyType_FromSpec should take metaclass as an argument
Martin v. Löwis added the comment: If it's very special, I'm -0 on this addition. This sounds like this is something very few people would ever need, and they can learn to write more complicated code to achieve the same effect. Convenience API exists to make the common case convenient. I'm -1 on calling it PyType_FromSpecEx. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15870 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11715] Building Python on multiarch Debian and Ubuntu
Matthias Klose added the comment: I think that the ma.diff can safely go to the 2.7 and 3.2 branches. For the other extensions which are not built you are probably missing the build dependencies (try: apt-get build-dep python2.7 python3.2). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11715 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11715] Building Python on multiarch Debian and Ubuntu
Ezio Melotti added the comment: The other missing extensions are not a problem, as long as the one that I need and already have (e.g. readline, _ssl) are built correctly. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11715 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15298] _sysconfigdata is generated in srcdir, not builddir
Matthias Klose added the comment: looks fine. from my point of view this should go to the 3.3 branch after the 3.3.0 release, and to the trunk. -- keywords: -needs review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15298 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15872] shutil.rmtree(..., ignore_errors=True) doesn't ignore all errors
Alessandro Moura added the comment: Yes, confirmed. When checking whether the provided path is a directory, rmtree does not check whether ignore_errors is set. According to the docstring, If ignore_errors is set, errors are ignored. Presumably this means any error, in which case this is not the desired behaviour. The attached patch fixes this. -- keywords: +patch nosy: +eng793 Added file: http://bugs.python.org/file27138/shutil.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15872 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15830] make -s no longer silences output from setup.py
Matthias Klose added the comment: now fixed, see http://bugs.python.org/issue15591#msg169927 -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15830 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15830] make -s no longer silences output from setup.py
Christian Heimes added the comment: Matthias: Not yet, my checkin didn't fix the issue. I've just added a minor modification to setup.py that forwards the -q option to ctypes' configure script. -- nosy: +christian.heimes ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15830 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15870] PyType_FromSpec should take metaclass as an argument
Alexander Belopolsky added the comment: On Sep 6, 2012, at 6:25 PM, Martin v. Löwis rep...@bugs.python.org wrote: I'm -1 on calling it PyType_FromSpecEx. I find it encouraging that you commented on the choice of name. :-) I can live with PyType_FromMetatypeAndSpec and leave out bases. PyType_FromTypeAndSpec is fine too. On the substance, I don't think this API is just convenience. In my application I have to replace meta type after my type is created with PyType_FromSpec. This is fragile and works only for very simple metatypes. Let's get back to this discussion once I have a ctypes patch. I there will be a work-around for ctypes it will probably work for my case. (My case is a little bit more complicated because I extend the size of my type objects to store custom metadata. Ctypes fudge this issue by hiding extra data in a custom tp_dict. ) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15870 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15867] It's hard to decypher how to build off of the provided objects from the importlib docs
Changes by Chris Jerdonek chris.jerdo...@gmail.com: -- nosy: +cjerdonek ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15867 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15873] datetime cannot parse ISO 8601 dates and times
Alexander Belopolsky added the comment: %z format is supported, but it cannot accept colon in TZ offset. It can parse offsets like -0600 just fine. What OP is looking for is the GNU date %:z format which datetime does not support. For ISO 8601 compliance, however I think we need a way to specify a parser that will accept any valid 8601 format: with T or space separator and with or without : in time and timezone and with or without dashes in date. I would very much like such promiscuous parser to be implemented in datetime.__new__. So that we can create datetime objects from strings the way we do it with numbers. -- nosy: +Alexander.Belopolsky ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15873 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14468] Update cloning guidelines in devguide
Changes by Mike Hoy mho...@gmail.com: -- nosy: -mikehoy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14468 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15591] when building the extensions, stdout is lost when stdout is redirected
Roundup Robot added the comment: New changeset b9261dd34289 by Christian Heimes in branch '3.2': Issue #15591 and Issue #11715: silence output of setup.py when make is run with -s option. http://hg.python.org/cpython/rev/b9261dd34289 New changeset fcc629208842 by Christian Heimes in branch 'default': Issue #15591 and Issue #11715: silence output of setup.py when make is run with -s option. http://hg.python.org/cpython/rev/fcc629208842 New changeset 2587aeb616b6 by Christian Heimes in branch '2.7': Issue #15591 and Issue #11715: silence output of setup.py when make is run with -s option. http://hg.python.org/cpython/rev/2587aeb616b6 New changeset 4807ed8a627e by Christian Heimes in branch 'default': Issue #15591 and Issue #11715: silence output of setup.py when make is run with -s option. http://hg.python.org/cpython/rev/4807ed8a627e -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15591 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11715] Building Python on multiarch Debian and Ubuntu
Roundup Robot added the comment: New changeset b9261dd34289 by Christian Heimes in branch '3.2': Issue #15591 and Issue #11715: silence output of setup.py when make is run with -s option. http://hg.python.org/cpython/rev/b9261dd34289 New changeset fcc629208842 by Christian Heimes in branch 'default': Issue #15591 and Issue #11715: silence output of setup.py when make is run with -s option. http://hg.python.org/cpython/rev/fcc629208842 New changeset 2587aeb616b6 by Christian Heimes in branch '2.7': Issue #15591 and Issue #11715: silence output of setup.py when make is run with -s option. http://hg.python.org/cpython/rev/2587aeb616b6 New changeset 4807ed8a627e by Christian Heimes in branch 'default': Issue #15591 and Issue #11715: silence output of setup.py when make is run with -s option. http://hg.python.org/cpython/rev/4807ed8a627e -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11715 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15870] PyType_FromSpec should take metaclass as an argument
Antoine Pitrou added the comment: This API may make it easier to declare ABCs in C. -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15870 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15591] when building the extensions, stdout is lost when stdout is redirected
Changes by Christian Heimes li...@cheimes.de: -- nosy: +brett.cannon resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15591 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15872] shutil.rmtree(..., ignore_errors=True) doesn't ignore all errors
Chris Jerdonek added the comment: Can you also provide a test? -- nosy: +cjerdonek ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15872 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15870] PyType_FromSpec should take metaclass as an argument
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com: -- nosy: +Arfrever ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15870 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15873] datetime cannot parse ISO 8601 dates and times
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com: -- nosy: +Arfrever ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15873 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15872] shutil.rmtree(..., ignore_errors=True) doesn't ignore all errors
Alessandro Moura added the comment: Added test to patch. -- Added file: http://bugs.python.org/file27139/shutil.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15872 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15874] argparse cannot parse bash variable arguments in file-given arguments
New submission from Nat Hillard: When using the argparse argument fromfile_prefix_chars to obtain command line arguments from a file, it is not possible to make use of bash environment variables within this file. Ideally one would be able to `export BAR='/Users/x/Desktop/bar'`, and then give arguments such as: --foo $BAR and have this correctly expanded at read time to --foo '/Users/x/Desktop/bar'. To my knowledge, this is currently only possible if you give the arguments directly via the command line: python test.py --foo $BAR It would be great to be able to use environment variables within files as well! -- components: Library (Lib) messages: 169958 nosy: ZhuangZi, bethard priority: normal severity: normal status: open title: argparse cannot parse bash variable arguments in file-given arguments type: behavior versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15874 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15591] when building the extensions, stdout is lost when stdout is redirected
Roundup Robot added the comment: New changeset 8cd6acffbcb9 by Christian Heimes in branch '2.7': Issue #15591 and Issue #11715: silence output of setup.py when make is run with -s option. http://hg.python.org/cpython/rev/8cd6acffbcb9 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15591 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11715] Building Python on multiarch Debian and Ubuntu
Roundup Robot added the comment: New changeset 8cd6acffbcb9 by Christian Heimes in branch '2.7': Issue #15591 and Issue #11715: silence output of setup.py when make is run with -s option. http://hg.python.org/cpython/rev/8cd6acffbcb9 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11715 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11715] Building Python on multiarch Debian and Ubuntu
Christian Heimes added the comment: Sorry for the noise! I confused two tickets. The checkin should have referred to #15830 and #15591 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11715 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15871] Online docs: make index search always available.
Terry J. Reedy added the comment: 'print' *is* a function name ;-) which also happens to be a common word. If the current search box gives you the page where the function is defined, searching the index first should give you the same page. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15871 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15867] It's hard to decypher how to build off of the provided objects from the importlib docs
Nick Coghlan added the comment: One specific change we should make is that the see also at the start of the 3.3 importlib docs should link to the new section of the language reference, rather than Guido's packaging essay. We can probably also cull that long list of PEPs, moving it to the end of the language reference section. Other than that, yeah, we've been working away at this for years, trying to bring it down to a more manageable level of complexity. Brett's efforts in finally purging the last remnants of the old pre-PEP 302 import systems are what made it possible for Barry to finally create a coherent spec for the import system (previously, none of us really wanted to write such a thing, as there would have been *way* too many caveats needed in attempting to grandfather in the legacy import mechanics). Now that that is done, 3.4 will likely include a number of improvements to importlib to make it easier to use as a basis for custom import hooks (as Brett and Eric noted, better support for customisation of the source - bytecode compilation step will definitely be one of them. As far as books go, I think the evolution of Python's import system might make an interesting entry if they do a third edition of The Architecture of Open Source Applications [1] :) [1] http://www.aosabook.org/en/index.html -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15867 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15875] tarfile may not make @LongLink for non-ascii character
New submission from Manuke: When I will make a GNU tar-file with 'tarfile', @LongLink may not be made though the name of the archived-file is long, if the name uses non-ascii characters. In tarfile.py, the check code of the filename length is described as follows now: tarfile.py: 1032 if len(info[name]) LENGTH_NAME: But, the type of the value is 'str', it is not encoded. It must be described as follows: if len(info[name].encode(encoding, errors)) LENGTH_NAME: There seems to be the same problem in Line 1029(and the other functions for other formats), but I have not confirmed. -- components: Library (Lib) messages: 169962 nosy: Manuke priority: normal severity: normal status: open title: tarfile may not make @LongLink for non-ascii character type: behavior versions: Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15875 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15874] argparse cannot parse bash variable arguments in file-given arguments
R. David Murray added the comment: I'm not sure this is a good idea. $BAR is supported on the command line because your shell supports it. To support it in files, argparse would have to (re)implement shell parsing, and while we do have a parser in the stdlib that can do some of this (shlex), actually implementing environment variable substitution correctly would be a non-trivial undertaking. And what about the csh users? (Assuming there are any left :) -- nosy: +r.david.murray type: behavior - enhancement versions: +Python 3.4 -Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15874 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15873] datetime cannot parse ISO 8601 dates and times
John Nagle added the comment: Re: %z format is supported. That's platform-specific; the actual parsing is delegated to the C library. It's not in Python 2.7 / Win32: ValueError: 'z' is a bad directive in format '%Y-%m-%dT%H:%M:%S%z' It really shouldn't be platform-specific; the underlying platform is irrelevant to this task. That's more of a documentation error; the features not common to all supported Python platforms should not be mentioned in the documentation. Re: I would very much like such promiscuous parser to be implemented in datetime.__new__. For string input, it's probably better to do this conversion in a specific class-level function. Full ISO 8601 dates/times generally come from computer-generated data via a file or API. If invalid text shows up, it should be detected as an error, not be heuristically interpreted as a date. There's already fromtimestamp and fromordinal, and isoformat as an instance method, so fromisoformat seems reasonable. I'd also suggest providing a standard subclass of tzinfo in datetime for fixed offsets. That's needed to express the time zone information in an ISO 8601 date. The new fromisoformat would convert an ISO 8601 date/time would be convertible to a time-zone aware datetime object. If converted back to an ISO 8601 string with .isoformat(), the round trip should preserve the original data, including time zone offset. (Several more implementations of this conversion have turned up. In addition to the four already mentioned, there was one in xml.util, and one in feedparser. There are probably more yet to be found.) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15873 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15676] mmap: add empty file check prior to offset check
Steven Willis added the comment: Here's a patch for 2.7. I don't know if it cleanly applies to the rest. -- keywords: +patch Added file: http://bugs.python.org/file27140/issue15676.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15676 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15873] datetime cannot parse ISO 8601 dates and times
Alexander Belopolsky added the comment: On Thu, Sep 6, 2012 at 9:51 PM, John Nagle rep...@bugs.python.org wrote: It's not in Python 2.7 / Win32. Python 2.x series is closed and cannot accept new features. Both %z and fixed offset tzinfo subclass are implemented in 3.2. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15873 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15874] argparse cannot parse shell variable arguments in file-given arguments
Nat Hillard added the comment: Indeed these are all valid points, and as a zsh user myself I certainly considered the alternative shell issue. That said, if it were at all possible, through a combination of os.environ / shlex, subprocess, and even `source` if necessary, to offload this interpretation to the user's shell (pass the shell a given string, receive its interpretation first before further processing), I could see a lot of benefit from this. Relatedly, I have seem similar requests for environment variable support in configparser, here: http://grokbase.com/t/python/python-list/03ckhw75xr/parsing-environment-variables-in-configparser-files This particular proposal is interesting in that it creates an intermediary between the file's environment variable syntax and the shell's own. Presumably if you standardized the presentation of environment variables within this file you could use os.environ once you had recognized it. That said, I can understand, however, if this is prohibitively costly to implement, and it may well be that this option is ill suited to the task I am putting it to. -- title: argparse cannot parse bash variable arguments in file-given arguments - argparse cannot parse shell variable arguments in file-given arguments ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15874 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15873] datetime cannot parse ISO 8601 dates and times
Alexander Belopolsky added the comment: I am attaching a quick python only prototype for the proposed feature. My goal is to make date/time objects behave like numeric types for which constructors accept strings produced by str(). Since str() format is ISO 8601, it is natural to accept ISO 8601 formats in constructors. -- keywords: +patch Added file: http://bugs.python.org/file27141/issue15873-proto.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15873 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12014] str.format parses replacement field incorrectly
Changes by Alexander Belopolsky alexander.belopol...@gmail.com: -- nosy: +belopolsky ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12014 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15520] Document datetime.timestamp() in 3.3 What's New
Alexander Belopolsky added the comment: Added in 7ca6b3a16e15 -- nosy: +belopolsky resolution: - out of date status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15520 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5023] Segfault in datetime.time.strftime(%z)
Changes by Alexander Belopolsky alexander.belopol...@gmail.com: -- status: pending - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5023 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15870] PyType_FromSpec should take metaclass as an argument
Martin v. Löwis added the comment: As for declaring ABCs: I don't think the API is necessary, or even helps. An ABC is best created by *calling* ABCMeta, with the appropriate name, a possibly-empty bases tuple, and a dict. What FromSpec could do is to fill out slots with custom functions, which won't be necessary or desirable for ABCs. The really tedious part may be to put all the abstract methods into the ABC, for which having a TypeSpec doesn't help at all. (But I would certainly agree that simplifying creation of ABCs in extension modules is a worthwhile reason for an API addition) For the case that Alexander apparently envisions, i.e. metaclasses where the resulting type objects extend the layout of heap types: it should be possible for an extension module to fill out the entire type from scratch. This will require knowledge of the layout of heap types, so it can't use just the stable ABI - however, doing this through the stable ABI won't be possible, anyway, since the extended layout needs to know how large a HeapType structure is. If filling out a type with all slots one-by-one is considered too tedious, and patching ob_type too hacky - here is another approach: Use FromSpec to create a type with all slots filled out, then call the metatype to create a subtype of that. I.e. the type which is based on a metatype would actually be a derived class of the type which has the slots defined. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15870 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
