[issue1758] Wrong link in documentation
Robert Lehmann added the comment: This problem has been removed in the current version of the documentation (http://docs.python.org/dev/install/index.html) -- old docs aren't updated. It has an own section now (http://docs.python.org/dev/bugs.html). Issue can be closed. -- nosy: +lehmannro __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1758> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2120] broken links in advocacy HOWTO
Robert Lehmann added the comment: Aye, this patch removes the spaces and re-aligns the paragraph of the latter link. -- nosy: +lehmannro Added file: http://bugs.python.org/file9434/spaces.patch __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2120> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2120] broken links in advocacy HOWTO
Robert Lehmann added the comment: Right, the second link requires a tilde -- I just tried the first one (which works without). You should change all lines to be 80 characters wide maximum, though (can quickly be done by any commiter, not worth a new patch IMO). The dash thing looks okay, "---" is used a couple of times throughout the docs. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2120> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2201] Documentation Section 4.4
Robert Lehmann added the comment: In the example code from the tutorial you gave, there was still a comma separator between the string 'equals' and the reference `x`. This is missing when you entered the code, that's why Python is throwing an exception there. -- nosy: +lehmannro __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2201> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2529] list/generator comprehension parser doesn't match spec
Robert Lehmann <[EMAIL PROTECTED]> added the comment: Your example is parsed as [e for i in (j in ['a','b','c'])] and since `j` is not defined, you get a NameError. If it was defined, you would still be iterating a boolean (which is not defined). Grammatically, this is the following (just the important parts, again): list_comprehension ::= expression list_for list_for ::= "for" target_list "in" old_expression_list old_expression_list ::= old_expression old_expression ::= comparison comparison ::= or_expr ( comp_operator or_expr )* comp_operator ::= "in" So your basic misconception is that both `in` keywords are belonging to the list comprehension syntax -- the former does while the latter is simply an operator. -- nosy: +lehmannro __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2529> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9042] Gettext cache and classes
Robert Lehmann added the comment: Wouldn't constructing the key as a tuple of (class_, mofile) be much cleaner than making up an artificial key? -- nosy: +lehmannro ___ Python tracker <http://bugs.python.org/issue9042> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12325] regex matches incorrectly on literal dot (99.9% confirmed)
Robert Lehmann added the comment:
I can not reproduce either of your findings. Could you provide us with your
version information? re version 2.2.1, _sre 2.2.2, Python 2.6.6, Debian sid
here. Also tested with Python 2.7.2rc1 (same RE).
>>> import re
>>> re.compile(r"\.co\.uk", re.DEBUG)
literal 46
literal 99
literal 111
literal 46
literal 117
literal 107
<_sre.SRE_Pattern object at 0xb73b0860>
>>> re.compile(r"(^|
>>> )((?:[\w\-]{2,}?\.|)(?:[\w\-]{2,}?)(?:\.com|\.net|\.org|\.co\.uk|\.tv|\.ly))",
>>> flags = re.IGNORECASE | re.MULTILINE | re.DEBUG).sub("\\1http://\\2";,
>>> """me and a buddy and his girlfriend were watching tv once and this
>>> blabbering idiot starts talking about this scientific study she heard about
>>> where they built a fake city and only one guy didn't know that it was a
>>> fake. we all paused for a second and i said "the truman show?" and she says
>>> "yeah! that was the name of it!" me my buddy and his girlfriend all catch
>>> eyes and are baffled at how stupid she was""")
subpattern 1
...
'me and a buddy and his girlfriend were watching tv once...'
--
nosy: +lehmannro
___
Python tracker
<http://bugs.python.org/issue12325>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10598] curses fails to import on Solaris
Robert Lehmann added the comment: I have attached a fix and a regression test. -- keywords: +patch nosy: +lehmannro Added file: http://bugs.python.org/file19903/issue10598.patch ___ Python tracker <http://bugs.python.org/issue10598> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10562] Change 'j' for imaginary unit into an 'i'
Robert Lehmann added the comment: > I wonder whether there are many examples where scientific data is written in > a form that Python's complex() constructor couldn't currently read, but would > be able to read if it accepted 'i' in place of 'j'. I could not reproduce widespread real world issues with the syntax as it stands using Google Code Search (a mere 4 unique hits). http://goo.gl/sqMhY -- nosy: +lehmannro ___ Python tracker <http://bugs.python.org/issue10562> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10576] Add a progress callback to gcmodule
Robert Lehmann added the comment: A few issues I'd like to raise: (1) Multiple callback chains. Is there any code in your existing use case of GC callbacks where you don't check for the phase argument and follow different code paths depending on it? If not, having two callback chains should be fine and takes the burden from the programmer to the implementors. (This is feasible if we *only ever* have two values for the phase.) (2) Single collections. Currently, neither PyGC_Collect nor gc.collect() invoke the callbacks (since they do not call collect_generations). Is this an oversight or intentional? (3) Error checking. What about callbacks which are bound to fail on each and every invocation, ie. because of wrong signatures. Should these be flat-out rejected in some way *on registration*, automagically removed when first encountered, or are we okay with errors slammed into the user's face every so often because he should REALLY fix them? (4) Interop. Can this be supported as easily on other VMs? (That's perhaps a good reason for the statistics to be a dict, for GCs providing vastly different amounts of information.) -- nosy: +lehmannro ___ Python tracker <http://bugs.python.org/issue10576> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14961] map() and filter() methods for iterators
Robert Lehmann added the comment: Your proposal seems two-fold: (a) make map/filter lazy and (b) have them as methods instead of functions. It seems Tim borrowed Guido's time machine and already implemented (a) in Python 3.x, see http://docs.python.org/py3k/library/functions.html#map and http://docs.python.org/py3k/library/functions.html#filter. Your second proposal-- which is better suited for python-ideas, really --is obstructed by iterators being merely a protocol (the next/__next__ method) which makes it hard to add those methods to one particular type. (This very discussion pops up every so often for str.join too.) I'd recommend closing this issue. -- nosy: +lehmannro ___ Python tracker <http://bugs.python.org/issue14961> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13435] Copybutton does not hide tracebacks
New submission from Robert Lehmann : The recently added copybutton.js (r18bbfed9aafa) does not work with the 2.7 docs since they are deployed with JQuery 1.2 (which is shipped with Sphinx 0.6). Copybutton is an unobtrusive Javascript feature which adds a little button to all doctests that removes the interactive prompts in order to copy the code as-is into Python scripts. I think that feature could well be ported to Sphinx itself. In line 44 and 51 of Doc/tools/sphinxext/static/copybutton.js the code uses jQuery.nextUntil(), which is new in JQuery 1.4. That results in tracebacks being only partially hidden. Reproduce the error at http://docs.python.org/tutorial/errors.html#exceptions for example. The Python 3.2+ documentation is not affected as it is built with Sphinx 1.0, which ships with JQuery 1.4. JQuery Untils are available as a separate plugin (http://benalman.com/projects/jquery-untils-plugin/). -- assignee: docs@python components: Documentation messages: 147962 nosy: docs@python, ezio.melotti, lehmannro priority: normal severity: normal status: open title: Copybutton does not hide tracebacks type: behavior versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue13435> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6105] json.dumps doesn't respect OrderedDict's iteration order
Robert Lehmann added the comment:
This only seems to be the case with the C implementation of json (_json).
>>> json.encoder.c_make_encoder = None
>>> json.dumps(OrderedDict(items))
'{"one": 1, "two": 2, "three": 3, "four": 4, "five": 5}'
I think the culprit is encoder_listencode_dict (Modules/_json.c:2049).
It uses PyDict_Next to fetch all items from the dictionary and thereby
loses order. A special code branch for dict subclasses
(!PyDict_CheckExact) which uses PyIter* instead should solve the
problem. (PyDict_Next should not honor order no matter what IMO.)
If nobody beats me to it I can try to come up with a patch.
--
nosy: +lehmannro
___
Python tracker
<http://bugs.python.org/issue6105>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6574] List the __future__ features in a table
Robert Lehmann added the comment: I composed a list of __future__ features and linked the respective PEPs. Even though the language reference would be a better place to store such general information (being PEP'd and all) I found the library reference's __future__.py documentation to be a cleaner host for that table. Python 3 docs would need to add the barry_as_FLUFL feature to that table. -- keywords: +patch nosy: +lehmannro Added file: http://bugs.python.org/file14569/future.patch ___ Python tracker <http://bugs.python.org/issue6574> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6574] List the __future__ features in a table
Robert Lehmann added the comment: Implemented proposed changes. Additionally, I'd change line 13 to state either "future statements" or "`future`:ref:" instead of "future_statements", which does not make sense in normal, unmarked text. -- Added file: http://bugs.python.org/file14885/future.patch ___ Python tracker <http://bugs.python.org/issue6574> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6574] List the __future__ features in a table
Changes by Robert Lehmann : Added file: http://bugs.python.org/file14886/future.patch ___ Python tracker <http://bugs.python.org/issue6574> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6908] Minor markup error in hashlib docs
New submission from Robert Lehmann : The documentation for hashlib.hash.digest_size/block_size (notice the hash) renders as documentation for hashlib.*_size, which does not exist. Fixed by explicitly declaring membership; patch attached. -- assignee: georg.brandl components: Documentation files: hashlib-docs.patch keywords: patch messages: 92611 nosy: georg.brandl, lehmannro severity: normal status: open title: Minor markup error in hashlib docs versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2 Added file: http://bugs.python.org/file14887/hashlib-docs.patch ___ Python tracker <http://bugs.python.org/issue6908> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6911] Document changes in asynchat
New submission from Robert Lehmann : asynchat.async_chat grew a _collect_incoming and a _get_data method in 2.6. The constructor has been extended to conform to asyncore.dispatcher's. This should be documented. Apart from that, fifo and simple_producer have been deprecated, and async_chat.ac_out_buffer was replaced by async_chat.incoming. These are internals and were never documented. A patch is attached. -- assignee: georg.brandl components: Documentation files: asynchat-docs.patch keywords: patch messages: 92616 nosy: georg.brandl, lehmannro severity: normal status: open title: Document changes in asynchat versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2 Added file: http://bugs.python.org/file14888/asynchat-docs.patch ___ Python tracker <http://bugs.python.org/issue6911> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6911] Document changes in asynchat
Robert Lehmann added the comment: Excuse me -- fifo and simple_producer are indeed documented and need a deprecation notice. New patch attached (plus reworded paragraph about async_chat.__init__). -- Added file: http://bugs.python.org/file14889/asynchat-docs.patch ___ Python tracker <http://bugs.python.org/issue6911> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6911] Document changes in asynchat
Robert Lehmann added the comment: I found another bug: async_chat.push still talks about automatically creating a simple_producer, which is no longer true. I added a fix to the patch. -- Added file: http://bugs.python.org/file14893/asynchat-docs.patch ___ Python tracker <http://bugs.python.org/issue6911> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6916] Remove deprecated items from asynchat
New submission from Robert Lehmann : The patches in issue1736190 deprecated fifo and simple_producers. These are safe for removal in Python 3.0. I attached a patch purging fifo and simple_producers from py3k code and tests. The docs are mostly trivial as well but also touched by my other issue issue6911 so I'd like that to settle first, otherwise this might result in a merge conflict. -- assignee: georg.brandl components: Documentation, Library (Lib), Tests files: asynchat.patch keywords: patch messages: 92645 nosy: georg.brandl, lehmannro severity: normal status: open title: Remove deprecated items from asynchat versions: Python 3.0, Python 3.1, Python 3.2 Added file: http://bugs.python.org/file14894/asynchat.patch ___ Python tracker <http://bugs.python.org/issue6916> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5483] [PATCH]Add FastDbfilenameShelf: shelf nerver sync cache even when writeback=True
Robert Lehmann added the comment: If I understand you correctly, your proposal is the following: use Shelf.cache to cache *all* objects instead of only keeping live references. Your patch retains the cache forever instead of purging it on sync. (All these changes only apply with writeback=True, which you enabled by default; nothing changes with writeback=False.) This speeds up *repeated* reads/writes as they are kept in-memory instead of querying the-- probably slow --database every time. I do not think this is a feasible solution for two reasons: (1) writeback was never intended to do such thing. It was introduced as a solution to "make shelve less surprising." If you remove its sync-on-close characteristics, shelve is as surprising as before. See issue553171. (2) If you intend to implement caching on *any* database I'd suggest not using shelve for that matter. Using it for serialization is all okay but I'd rather add an additional layer of indirection to implement caching strategies if you want to do that The Right Way. (Shelf.cache is really only a map of objects that were touched during runtime.) I'm -1 on this patch but generally +1 on a generic caching wrapper. The error you describe later on appears because Python is already tearing down when gc'ing the Shelf (calling __del__ -> close -> sync). With writeback=True this currently tries to pickle the cache again which emits the error you observed. This should be handled in a separate issue. -- nosy: +lehmannro ___ Python tracker <http://bugs.python.org/issue5483> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5754] Shelve module writeback parameter does not act as advertised
Robert Lehmann added the comment: I think you're misquoting Python's shelve module documentation in your first sentence. The documentation says: "By default modified objects are written only when assigned to the shelf [...]. If the optional writeback parameter is set to True, all entries accessed are cached in memory, and written back at close time [...]." The emphasis should be on the word "only:" it does *always* write to the database when assigned to the shelf but, iff writeback=True, *also* to the cache. Also consider the consequences of *only* caching keys: (a) __contains__ and has_key have to consult the dict and the cache for membership tests. (b) keys and __len__ need to compute a union of both sources. (c) __delitem__ is no longer guaranteed to fail on the cache if it failed for the database. I admit the docs could spell this out more clearly. I attached a patch ensuring the behaviour I described in a test and updating the docs. (Note: shelve is no extension module -- it's part of the stdlib. Patch applies to 3.x as well.) -- components: +Library (Lib) -Extension Modules keywords: +patch nosy: +lehmannro Added file: http://bugs.python.org/file14909/issue5754.patch ___ Python tracker <http://bugs.python.org/issue5754> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6932] Open shelves fail when Python exits
New submission from Robert Lehmann : I'm reopening issue5483 by Zhigang Wang (zhigang) as a separate bug. Shelves that are still open when Python terminates will try to sync. If writeback=True, this pickles cached items. In this example, serialization of Test() re-imports __main__, which is already gc'd, and raises: Exception cPickle.PicklingError: Can't pickle : it's not the same object as __main__.Test" in }> The error is ignored (due to Python already tearing down) but all cached modifications are lost. The promise "[t]he __del__() method of the Shelf class calls the close() method, so the programmer generally need not do this explicitly" is not true with writeback enabled. I'm unsure if this error can be fixed (probably with atexit/weakref, but that's more trouble than gain). I attached a patch to the docs simply warning the user of this issue (+ documenting Shelf.close, + removing above quote). -- assignee: georg.brandl components: Documentation, Extension Modules, Library (Lib) files: example.py messages: 92773 nosy: georg.brandl, lehmannro severity: normal status: open title: Open shelves fail when Python exits type: behavior versions: Python 2.7, Python 3.1 Added file: http://bugs.python.org/file14912/example.py ___ Python tracker <http://bugs.python.org/issue6932> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6932] Open shelves fail when Python exits
Changes by Robert Lehmann : -- keywords: +patch Added file: http://bugs.python.org/file14913/shelve-warning.patch ___ Python tracker <http://bugs.python.org/issue6932> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5483] [PATCH]Add FastDbfilenameShelf: shelf nerver sync cache even when writeback=True
Robert Lehmann added the comment: I addressed the other bug you were experiencing in issue6932. -- ___ Python tracker <http://bugs.python.org/issue5483> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1766304] improve xrange.__contains__
Robert Lehmann added the comment: I revised the patch for Python 3.1 and added notices to Misc/NEWS and the range documentation. (Changing Type to resource usage.) -- nosy: +lehmannro type: feature request -> resource usage Added file: http://bugs.python.org/file14939/range.patch ___ Python tracker <http://bugs.python.org/issue1766304> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1766304] improve xrange.__contains__
Robert Lehmann added the comment: Thanks for your feedback. I added a few tests and changed the bits you criticized. -- Added file: http://bugs.python.org/file14945/range.patch ___ Python tracker <http://bugs.python.org/issue1766304> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2816] Quote-type recognition bug
Robert Lehmann <[EMAIL PROTECTED]> added the comment: It seems "single-quoted" doesn't mean the actual quotation sign used but rather how many you used. Compare the multiline triple quote syntax: $ cat foo.py """bar $ python foo.py File "foo.py", line 3 ^ SyntaxError: EOF while scanning triple-quoted string This shouldn't read sextuple-quoted string, should it? -- nosy: +lehmannro __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2816> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3669] sqlite3.Connection.iterdump docs pythonicity
New submission from Robert Lehmann <[EMAIL PROTECTED]>: The `sqlite3` docs are a little unpythonic. When using `str.join` on `Connection.iterdump`, the example in the docs manually unpacks the generator using a LC. I propose this'd be improved. Patch attached. Same applies to the py3k docs, it's just a few lines above there. -- assignee: georg.brandl components: Documentation files: connection-iterdump.patch keywords: patch messages: 71875 nosy: georg.brandl, lehmannro severity: normal status: open title: sqlite3.Connection.iterdump docs pythonicity type: feature request versions: Python 2.6, Python 3.0 Added file: http://bugs.python.org/file11237/connection-iterdump.patch ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3669> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4058] markup in What's New in 2.6
New submission from Robert Lehmann <[EMAIL PROTECTED]>:
The markup in the Doc/whatsnew/2.6.rst document is somewhat messy in
some places. I fixed indentation (spaces to tabs -- made some things
readable in the docutils output but not in the source), code samples
("->" notation to Python prompt) and some minor things (which are too
small for issues on their own).
--
assignee: georg.brandl
components: Documentation
files: whatsnew.2.6.patch
keywords: patch
messages: 74389
nosy: georg.brandl, lehmannro
severity: normal
status: open
title: markup in What's New in 2.6
type: feature request
versions: Python 2.6
Added file: http://bugs.python.org/file11713/whatsnew.2.6.patch
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue4058>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4059] sqlite3 docs incomplete
New submission from Robert Lehmann <[EMAIL PROTECTED]>: The sqlite3 documentation misses Row and Cursor.description. Additionally it does not use the best markup in all places (missing links, basically, and forgotten .. class:: statements). A patch is attached. -- assignee: georg.brandl components: Documentation files: sqlite3.patch keywords: patch messages: 74392 nosy: georg.brandl, lehmannro severity: normal status: open title: sqlite3 docs incomplete versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1 Added file: http://bugs.python.org/file11714/sqlite3.patch ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4059> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5034] itertools.fixlen
New submission from Robert Lehmann : As raised recently on python-ideas [1]_, an itertools method fixing iterators to a certain length might be handy (where fixing is either cutting elements off or appending values). I appended a patch implementing this feature in Python/C, unit tests and documentation included. .. [1] http://thread.gmane.org/gmane.comp.python.ideas/2472/focus=2479 -- components: Library (Lib) files: fixlen.patch keywords: patch messages: 80372 nosy: lehmannro severity: normal status: open title: itertools.fixlen type: feature request versions: Python 2.7 Added file: http://bugs.python.org/file12833/fixlen.patch ___ Python tracker <http://bugs.python.org/issue5034> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5034] itertools.fixlen
Robert Lehmann added the comment: When I started writing this patch this was actually what I intended. But having ``fixlen(range(3), 2)`` return 0 1 2 struck me as odd. Renaming the function to `pad` would help there indeed. It depends on which use case is more common: either fixing an iterator to a certain length (slicing/padding applied as required) or obtaining an iterator of *at least* some number of elements (padded as required)? The thread on python-ideas suggests the latter while the example Python code brought up there implements the former. OTOH the latter cannot be composed *that easily* of other itertools but the former is more useful for unpacking. On a related note: what should happen if `length` is negative? `itertools.repeat` just defaults to 0 in such cases but I am unsure how applicable that is in this case. ___ Python tracker <http://bugs.python.org/issue5034> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6019] Minor typos in ctypes docs
New submission from Robert Lehmann :
There are a few errors in the ctypes documentation covering function
calls using the example of `libc.printf`. It's basically just typos but
they are really confusing when trying to understand the examples.
Patch to trunk is attached. Corrections should apply to 3.x as well but
I'm unsure whether they apply cleanly to those branches, see issue4309
for details.
Unicode coercion as in printf("%S", u"abc") keeps segfaulting for me
with 2.5 so I'm unsure about the example's validity there; corrections
could be backported to 2.5-maint as well though. 2.4 and below are not
affected: ctypes was not present in these versions.
--
assignee: georg.brandl
components: Documentation
files: ctypes-docs.patch
keywords: patch
messages: 87733
nosy: georg.brandl, lehmannro
severity: normal
status: open
title: Minor typos in ctypes docs
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file13981/ctypes-docs.patch
___
Python tracker
<http://bugs.python.org/issue6019>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
