[issue29902] copy breaks staticmethod
New submission from Bruce Frederiksen: Doing a copy on a staticmethod breaks it: Python 3.5.2 (default, Nov 17 2016, 17:05:23) [GCC 5.4.0 20160609] on linux Type "help", "copyright", "credits" or "license" for more information. >>> from copy import copy >>> def foo(): pass ... >>> class bar: pass ... >>> bar.x = staticmethod(foo) >>> bar.x.__name__ 'foo' >>> bar.y = copy(staticmethod(foo)) >>> bar.y.__name__ Traceback (most recent call last): File "", line 1, in RuntimeError: uninitialized staticmethod object -- components: Library (Lib) messages: 290481 nosy: dangyogi priority: normal severity: normal status: open title: copy breaks staticmethod type: behavior versions: Python 3.5 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29902> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25991] readline example eventually consumes all memory
New submission from Bruce Frederiksen: The Example in the readline documentation (section 6.7 of the Library Reference) shows how to save your readline history in a file, and restore it each time you start Python. The problem with the Example is that it does not include a call to readline.set_history_length and the default is -1 (infinite). As a Python developer, I start Python quite a lot and had a .python_history file that was 850M bytes. Just starting Python was causing my system to thrash before the first prompt (>>>) even appeared. I suggest adding the following line to the example to avoid this: readline.set_history_length(1000) I'm not sure how far back this goes in terms of earlier versions of Python, but probably quite far. -- assignee: docs@python components: Documentation messages: 257325 nosy: dangyogi, docs@python priority: normal severity: normal status: open title: readline example eventually consumes all memory type: resource usage versions: Python 3.4 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25991> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17677] Invitation to connect on LinkedIn
New submission from Bruce Frederiksen: LinkedIn Python, I'd like to add you to my professional network on LinkedIn. - Bruce Bruce Frederiksen Information Technology and Services Professional Tampa/St. Petersburg, Florida Area Confirm that you know Bruce Frederiksen: https://www.linkedin.com/e/-3qcne3-hfb45911-6b/isd/12316860876/7QjJbS4a/?hs=falsetok=0GlQRpsV-Mh5I1 -- You are receiving Invitation to Connect emails. Click to unsubscribe: http://www.linkedin.com/e/-3qcne3-hfb45911-6b/z2oU7dKDzpt2G7xQz2FC2SclHmnUGzmsk0c/goo/report%40bugs%2Epython%2Eorg/20061/I4080988955_1/?hs=falsetok=3s-0HjjjGMh5I1 (c) 2012 LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, USA. -- messages: 186404 nosy: dangyogi priority: normal severity: normal status: open title: Invitation to connect on LinkedIn ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17677 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8515] idle Run Module (F5) does not set __file__ variable
Bruce Frederiksen dangy...@gmail.com added the comment: No, IDLE compiles the module (with the 'compile' built-in using the 'exec' option) and then does an 'exec' on the code (in PyShell.py). It has several lines of code that it runs before this exec to prepare the environment that the code is run in. It appears to be an oversight that the __file__ variable is not being set as a part of this preparation code to match the behavior of the python CLI. The patch that I included only changes one line of this preparation code to also set the __file__ variable and that fixes the problem. If you examine the IDLE code in the immediate vicinity of my patch you will see this. I have several use cases where I'm relying on the __file__ variable in my module so that it can find other non .py files that it needs in the same directory that it's in. This works under all combinations of uses from the CLI, but fails in IDLE using Run Module. The language reference manualhttp://docs.python.org/reference/datamodel.html?highlight=__file__states under Module: Predefined (writable) attributes: __name__ is the moduleâs name; __doc__ is the moduleâs documentation string, or None if unavailable; __file__ is the pathname of the file from which the module was loaded, if it was loaded from a file. The __file__ attribute is not present for C modules that are statically linked into the interpreter; for extension modules loaded dynamically from a shared library, it is the pathname of the shared library file. The python CLI honors this definition in all cases, but IDLE/Run Module does not. On Fri, Jun 11, 2010 at 11:11 AM, Tal Einat rep...@bugs.python.org wrote: Tal Einat talei...@users.sourceforge.net added the comment: I believe IDLE runs modules via execfile(), so I would expect the behavior to be similar, and execfile() does not set __file__. Doing Run Module is also IMO equivalent to doing execfile(), so this behavior retains consistency. However, I would expect __file__ to be set when running IDLE -r script, but I get name '__file__' is not defined (with Python 2.6.2). This is inconsistent and should be fixed. -- nosy: +taleinat ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8515 ___ -- Added file: http://bugs.python.org/file17632/unnamed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8515 ___No, IDLE compiles the module (with the #39;compile#39; built-in using the #39;exec#39; option) and then does an #39;exec#39; on the code (in PyShell.py). It has several lines of code that it runs before this exec to prepare the environment that the code is run in. It appears to be an oversight that the __file__ variable is not being set as a part of this preparation code to match the behavior of the python CLI. The patch that I included only changes one line of this preparation code to also set the __file__ variable and that fixes the problem. If you examine the IDLE code in the immediate vicinity of my patch you will see this.br brI have several use cases where I#39;m relying on the __file__ variable in my module so that it can find other non .py files that it needs in the same directory that it#39;s in. This works under all combinations of uses from the CLI, but fails in IDLE using Run Module.br brThe a href=http://docs.python.org/reference/datamodel.html?highlight=__file__;language reference manual/a states under quot;Modulequot;:brbrblockquote style=margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex; class=gmail_quote Predefined (writable) attributes: tt class=xref docutils literalspan class=pre__name__/span/tt is the moduleâs name; tt class=xref docutils literalspan class=pre__doc__/span/tt is the moduleâs documentation string, or tt class=xref docutils literalspan class=preNone/span/tt if unavailable; tt class=xref docutils literalspan class=prespan class=highlight__file__/span/span/tt is the pathname of the file from which the module was loaded, if it was loaded from a file. The tt class=xref docutils literalspan class=prespan class=highlight__file__/span/span/tt attribute is not present for C modules that are statically linked into the interpreter; for extension modules loaded dynamically from a shared library, it is the pathname of the shared library file.br/blockquotebrThe python CLI honors this definition in all cases, but IDLE/Run Module does not.brbrdiv class=gmail_quoteOn Fri, Jun 11, 2010 at 11:11 AM, Tal Einat span dir=ltrlt;a href=mailto:rep...@bugs.python.org;rep...@bugs.python.org/agt;/span wrote:br blockquote class=gmail_quote style=margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;br Tal Einat lt;a href=mailto:talei...@users.sourceforge.net;talei
[issue4806] Function calls taking a generator as star argument can mask TypeErrors in the generator
Bruce Frederiksen dangy...@gmail.com added the comment: I have also hit this error. I went to report it but found it already entered (good news), but not resolved from nearly a year ago (bad news). The error masked another bug that I had in my program and it took me quite awhile to figure out what the real problem was. I use *generator arguments quite a lot, so was surprised to see the error. So I, for one, can say that if you disable *generator arguments, you will break existing code. If anybody cares, I have verified that this error also appears in Python2.5 and Python2.4 and am attempting to add python2.5 to the Versions list. (And yes, *generators were allowed in Python2.4!) Is this headed for resolution? Progress on it seems to have stalled nearly a year ago. Can I vote to revive this? -- nosy: +dangyogi versions: +Python 2.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4806 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8515] idle Run Module (F5) does not set __file__ variable
New submission from Bruce Frederiksen dangy...@gmail.com: The python CLI always sets the __file__ variable, whether run as: $ python foobar.py or $ python -m foobar or $ python import foobar # __file__ set in foobar module The idle program sets the __file__ variable properly when you do the import from the idle shell, but __file__ is not set with the Run Module (F5) command from the editor. I've included a patch file to set __file__, but it doesn't del it after the module has run. But maybe this is OK, because the os.chdir is not undone either??? -- components: IDLE files: idle.patch keywords: patch messages: 104066 nosy: dangyogi severity: normal status: open title: idle Run Module (F5) does not set __file__ variable type: behavior versions: Python 2.6 Added file: http://bugs.python.org/file17062/idle.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8515 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8256] TypeError: bad argument type for built-in operation
New submission from Bruce Frederiksen dangy...@gmail.com: I'm getting a TypeError: bad argument type for built-in operation on a print() with no arguments. This seems to be a problem in both 3.1 and 3.1.2 (haven't tried 3.1.1). I've narrowed the problem down in a very small demo program that you can run to reproduce the bug. Just do python3.1 bug.py and hit ENTER at the prompt:. Removing the doctest call (and calling foo directly) doesn't get the error. Also removing the input call (and leaving the doctest call in) doesn't get the error. The startup banner on my python3.1 is: Python 3.1.2 (r312:79147, Mar 26 2010, 16:55:44) [GCC 4.3.3] on linux2 I compiled python 3.1.2 with ./configure, make, make altinstall without any options. I'm running ubuntu 9.04 with the 2.6.28-18-generic (32-bit) kernel. -- components: IO, Interpreter Core, Library (Lib) files: bug.py messages: 101874 nosy: dangyogi severity: normal status: open title: TypeError: bad argument type for built-in operation type: behavior versions: Python 3.1 Added file: http://bugs.python.org/file16681/bug.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8256 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3923] 'genexpr_for' in definition of 'call' in Language Reference.
New submission from Bruce Frederiksen [EMAIL PROTECTED]: The definition of 'call' in the Language Reference refers to 'genexpr_for' which doesn't exist. Either 'genexpr_for' should be changed to 'comp_for' or 'expression genexpr_for' should be changed to 'comprehension'. See the following: http://docs.python.org/dev/3.0/reference/expressions.html#grammar-token-call http://docs.python.org/dev/3.0/reference/expressions.html#grammar-token-comprehension I also did not see any description if what happens if you use the comprehension option (though I was scanning the text quickly and could have missed it). -- assignee: georg.brandl components: Documentation messages: 73513 nosy: dangyogi, georg.brandl severity: normal status: open title: 'genexpr_for' in definition of 'call' in Language Reference. versions: Python 3.0 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3923 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3917] set_display definition allows empty '{' '}' in Language Definition
New submission from Bruce Frederiksen [EMAIL PROTECTED]:
The definition for set_display in the Language Definition allows for
empty curly braces by enclosing expression_list | comprehension in
brackets ('[', ']'). These brackets should be removed, as empty curly
braces are a dict_display.
http://docs.python.org/dev/3.0/reference/expressions.html#grammar-token-set_display
--
assignee: georg.brandl
components: Documentation
messages: 73478
nosy: dangyogi, georg.brandl
severity: normal
status: open
title: set_display definition allows empty '{' '}' in Language Definition
versions: Python 3.0
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3917
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3914] augop definition does not include //=
New submission from Bruce Frederiksen [EMAIL PROTECTED]: The definition for 'augop' on the Simple Statements page of the Language Definition does not include //=. http://docs.python.org/dev/3.0/reference/simple_stmts.html#grammar-token-augop -- assignee: georg.brandl components: Documentation messages: 73449 nosy: dangyogi, georg.brandl severity: normal status: open title: augop definition does not include //= versions: Python 3.0 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3914 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3913] compound_stmt syntax includes 'decorated'
Bruce Frederiksen [EMAIL PROTECTED] added the comment: But the real Grammar doesn't include decorators on funcdef and classdef, while the Language Reference document does. So the 'decorated' option is not needed in the Language Reference (and, indeed, doesn't even seem to be defined there). Benjamin Peterson wrote: Benjamin Peterson [EMAIL PROTECTED] added the comment: If you look at the real Grammar (in Grammar/Grammar), you will see that this decorated is used in the grammar. -- nosy: +benjamin.peterson resolution: - invalid status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3913 ___ ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3913 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3913] compound_stmt syntax includes 'decorated'
Bruce Frederiksen [EMAIL PROTECTED] added the comment: The grammar definitions in the Language Reference are _not_ just a straight copy of the Grammar. They have been reworked. (I don't know why, perhaps to make it easier to understand)? So the Grammar defines funcdef and classdef _without_ decorators and then has a separate definition for decorated funcdefs and classdefs called 'decorated' that is another compound_stmt (along with funcdef and classdef). (For Grammar, I'm looking at: http://docs.python.org/dev/3.0/reference/grammar.html). The Language Reference defines both funcdef and classdef _with_ optional decorators, so the 'decorated' alternative for compound_stmt is no longer required and should be deleted. The following links should take you straight to the funcdef and classdef definitions in the Language Reference: http://docs.python.org/dev/3.0/reference/compound_stmts.html#grammar-token-funcdef http://docs.python.org/dev/3.0/reference/compound_stmts.html#grammar-token-classdef Now, I just also noticed that the Language Reference actually has two definitions of funcdef. The second definition is 3 lines below the first one and fails to include either the optional decorators or the new [- expression] option after the argument list. Should I report this as another bug, or does this comment count. This second definition should be deleted. Also, the first definition of funcdef in the Language Reference has an extraneous '?' character after the [- expression] which should also be deleted. Should I report this as a separate bug too, or leave it, as well, to this comment? (Sorry for asking whether to report these too, I don't know how strict you guys are about keeping a record of everything). There are many other places where the grammar defined in the Language Reference is not a mirror copy of the Grammar (but is still an equivalent grammar). In fact, this seems to be the rule, rather than the exception. If you are unaware of this, you should examine the grammar definitions in the Language Reference and compare them to the Grammar yourself; or ask whoever is in charge of the Language Reference document. I don't know why this was done, I'm just trying to point out that the Language Reference document has some (minor) bugs in it that are very easily fixed. Benjamin Peterson wrote: Benjamin Peterson [EMAIL PROTECTED] added the comment: The language reference is merely a explanation of the the Grammar, so I don't understand why you think it shouldn't be there. A 'decorated' node contains a 'classdef' or 'fundef'. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3913 ___ ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3913 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3842] can't run close through itertools.chain on inner generator
New submission from Bruce Frederiksen [EMAIL PROTECTED]: There is no way to get generators to clean up (run their 'finally' clause) when used as an inner iterable to chain: def gen(n): ... try: ... # do stuff yielding values ... finally: ... # clean up c = chain.from_iterable(map(gen, (1,2,3))) next(c) 0 # done with c, but can't clean up inner gen! Could you add a 'close' method to itertools.chain that would call close (if present) on both the inner and other iterable? Then clean up could be done as: with closing(chain.from_iterable(map(gen, (1,2,3 as c: ...next(c) # generator finalized by with closing! -- components: Extension Modules messages: 73052 nosy: dangyogi severity: normal status: open title: can't run close through itertools.chain on inner generator type: feature request versions: Python 3.0 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3842 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2598] { +(}.format(**{' +(': 44}) should produce ValueError: invalid identifier, ' +(' in format
Bruce Frederiksen [EMAIL PROTECTED] added the comment:
I was reading the 3.0 documentation:
http://docs.python.org/dev/3.0/library/string.html#formatstrings which
indicated that an identifier was required. I was unaware of the
implementation note in the PEP.
They only issue remaining is that for the example in the title of this
issue, { +(}.format(**{' +(': 44}), no error is generated. I agree
that this is a nit and presumably the will of the community reviewing
the PEP, so agree to having the issue rejected.
I would reject it myself, but am unable to do so...
Thank you for pointing out the PEP to me.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2598
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2597] python2.6 -3 should report list.sort(cmp) as DeprecationWarning
New submission from Bruce Frederiksen [EMAIL PROTECTED]: this is not reported in 2.6a1. -- components: Interpreter Core messages: 65207 nosy: dangyogi severity: normal status: open title: python2.6 -3 should report list.sort(cmp) as DeprecationWarning type: feature request versions: Python 2.6 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2597 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2598] { +(}.format(**{' +(': 44}) should produce ValueError: invalid identifier, ' +(' in format
New submission from Bruce Frederiksen [EMAIL PROTECTED]:
Format strings are documented to only allow identifiers or integers as
the field_name, but allow almost anything.
Python 3.0a3
--
components: Interpreter Core
messages: 65209
nosy: dangyogi
severity: normal
status: open
title: { +(}.format(**{' +(': 44}) should produce ValueError: invalid
identifier, ' +(' in format
type: behavior
versions: Python 3.0
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2598
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2599] allow field_name in format strings to default to next positional argument (e.g., {})
New submission from Bruce Frederiksen [EMAIL PROTECTED]:
Being forced to number the arguments when using positional arguments in
a format string is difficult to maintain. Adding an argument to the
format string either requires renumbering all subsequent arguments, or
using an out of sequence number such that the order of the format()
arguments no longer matches the order of the {...} arguments. Making
the integer optional would solve this. Thus, {} would be like the old
%s where it was far easier to add %s arguments in the middle of the
format string.
Python 3.0a3
--
components: Interpreter Core
messages: 65210
nosy: dangyogi
severity: normal
status: open
title: allow field_name in format strings to default to next positional
argument (e.g., {})
type: feature request
versions: Python 3.0
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2599
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2446] 2to3 translates import foobar to import .foobar rather than from . import foobar
New submission from Bruce Frederiksen [EMAIL PROTECTED]: 2to3 svn rev 61696 translates import local_module into import .local_module which isn't legal syntax. Should be from . import local_module. -- assignee: collinwinter components: 2to3 (2.x to 3.0 conversion tool) messages: 64247 nosy: collinwinter, dangyogi severity: normal status: open title: 2to3 translates import foobar to import .foobar rather than from . import foobar type: behavior versions: Python 2.6 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2446 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2427] 2to3 should translate itertools.imap into generator expression, not list comprehension
New submission from Bruce Frederiksen [EMAIL PROTECTED]: 2to3, svn rev 61623 translates itertools.imap(lambda x: ..., ...) into a list comprehension. This should be translated instead into a generator expression so that doing itertools.imap on infinite iterators still works. -- assignee: collinwinter components: 2to3 (2.x to 3.0 conversion tool) messages: 64092 nosy: collinwinter, dangyogi severity: normal status: open title: 2to3 should translate itertools.imap into generator expression, not list comprehension type: behavior versions: Python 2.6 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2427 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2428] 2to3 deletes # comments before from __future__ import with_statement
New submission from Bruce Frederiksen [EMAIL PROTECTED]: 2to3, svn rev 61623. To reproduce this error: $ cat ! foobar.py # line 1 # line 2 from __future__ import with_statement import sys ! $ 2to3 -w foobar.py RefactoringTool: Skipping implicit fixer: buffer RefactoringTool: Skipping implicit fixer: idioms RefactoringTool: Skipping implicit fixer: ws_comma --- foobar.py (original) +++ foobar.py (refactored) @@ -1,5 +1,2 @@ -# line 1 -# line 2 -from __future__ import with_statement import sys RefactoringTool: Files that were modified: RefactoringTool: foobar.py $ cat foobar.py import sys $ -- assignee: collinwinter components: 2to3 (2.x to 3.0 conversion tool) messages: 64098 nosy: collinwinter, dangyogi severity: normal status: open title: 2to3 deletes # comments before from __future__ import with_statement type: behavior versions: Python 2.6 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2428 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2410] absolute import doesn't work for standard python modules
New submission from Bruce Frederiksen [EMAIL PROTECTED]: Try this to reproduce error: $ mkdir -p test/email $ cd test $ touch __init__.py email/__init__.py $ cat ! foo.py from __future__ import absolute_import import smtplib ! $ python import foo ... File /usr/lib/python2.6/smtplib.py, line 46, in module import email.utils ImportError: No module named utils If you rename the email subdirectory, it will find email.utils where it should find it. Strangely, this doesn't happen if you have an 'os' subdirectory and try to import shlex, which does: import os.path ?? -- components: Interpreter Core messages: 63993 nosy: dangyogi severity: normal status: open title: absolute import doesn't work for standard python modules type: behavior versions: Python 2.5, Python 2.6, Python 3.0 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2410 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1174] new generator methods not documented in Library Reference
New submission from Bruce Frederiksen: The 2.5 library documentation mentions the new GeneratorExit exception, but does not show Generator Types with the new 'send', 'throw', 'close' and '__del__' methods. -- components: Documentation messages: 55981 nosy: dangyogi severity: minor status: open title: new generator methods not documented in Library Reference type: rfe versions: Python 2.5 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1174 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1173] yield expressions not documented in Language Reference
Changes by Bruce Frederiksen: -- components: Documentation severity: minor status: open title: yield expressions not documented in Language Reference type: rfe versions: Python 2.5 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1173 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
