[issue4176] segfault with pickle if 4th or 5th item of tuple returned by __reduce__ is not an iterator

[Hirokazu Yamamoto]

Changes by Hirokazu Yamamoto <[EMAIL PROTECTED]>:


Added file: 
http://bugs.python.org/file11917/fix_pickle_consistency_on_trunk.patch

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1673409] datetime module missing some important methods

[Steve Roberts]

Steve Roberts <[EMAIL PROTECTED]> added the comment:

I would like to add a use case, generating random dates. Especially
generating random dates/times according to different probability
distributions and within ranges. It would be nicest if operations could
be done directly with datetime, date, time and timedelta objects, but
easy conversion to and from timestamps as requested here would also make
for reasonably convenient code (i.e. get timestamp conversions from
objects to represent ranges, generate random numbers and convert back)

--
nosy: +steve.roberts

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4236] Crash when importing builtin module during interpreter shutdown

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:

Setting builtins._=None is not enough.

My example is very simple, but the crash I had initially was during the
deletion of sys.last_tb: the C() object may be stored anywhere.

I agree that the test in PyModule_Create2 is too strong: the import
machinery is still functional at this point. It could be replaced by
something that becomes true on _PyImport_Init(), and false on
_PyImport_Fini().

--
nosy: +loewis

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1673409] datetime module missing some important methods

[Marc-Andre Lemburg]

Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:

You can have all this by using the time module's functions.

It is true that these don't work for all dates, but they are still
useful to have.

FWIW: mxDateTime has always had methods to convert the date/time values
to ticks and back again:

http://www.egenix.com/products/python/mxBase/mxDateTime/

Since most of the datetime module was inspired by mxDateTime, I wonder
why these were left out.

--
nosy: +lemburg

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4176] segfault with pickle if 4th or 5th item of tuple returned by __reduce__ is not an iterator

[Alexandre Vassalotti]

Alexandre Vassalotti <[EMAIL PROTECTED]> added the comment:

Iterators only need to provide a __next__() method. So, you don't have
to check __iter__.

Other than that, the patch looks good.

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1673409] datetime module missing some important methods

[Skip Montanaro]

Skip Montanaro <[EMAIL PROTECTED]> added the comment:

Unassigning.  Haven't heard from Tim in quite awhile and he's made no 
input on this issue.  Also bump to 2.7.

--
assignee: tim_one -> 
versions: +Python 2.7 -Python 2.6

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4176] segfault with pickle if 4th or 5th item of tuple returned by __reduce__ is not an iterator

[Hirokazu Yamamoto]

Hirokazu Yamamoto <[EMAIL PROTECTED]> added the comment:

Thank you for review.

>Iterators only need to provide a __next__() method. So, you don't have
>to check __iter__.

Hmm, but python document says,
(http://docs.python.org/library/stdtypes.html#typeiter)

>The iterator objects themselves are required to support the
>following two methods, which together form the iterator protocol:

Is this false information?

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4244] ihooks incompatible with absolute_import feature

[Jean-Paul Calderone]

New submission from Jean-Paul Calderone <[EMAIL PROTECTED]>:

The __import__ function ihooks installs has a signature which is
incompatible with the real __import__ function, breaking some things
when ihooks is in use:

[EMAIL PROTECTED]:~$ python2.5
Python 2.5.2 (r252:60911, Jul 31 2008, 17:28:52)
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import ihooks
>>> ihooks.install()
>>> from __future__ import absolute_import
Traceback (most recent call last):
  File "", line 1, in 
TypeError: import_module() takes at most 5 arguments (6 given)
>>>

--
components: Interpreter Core, Library (Lib)
messages: 75414
nosy: exarkun
severity: normal
status: open
title: ihooks incompatible with absolute_import feature
type: behavior
versions: Python 2.5, Python 2.5.3, Python 2.6

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4242] Classify language vs. impl-detail tests, step 1

[Armin Rigo]

Armin Rigo <[EMAIL PROTECTED]> added the comment:

Brett: in my experience the granularity is usually fine, and not coarse.
 A class decorator doesn't look too useful.  A function decorator is
useful, but not enough.  We also need a flag that can be checked in the
middle of a larger test.  (See the patch for test_descr for many
examples of this use case.)

Nick: your impl_detail() decorator looks fine to me (except that I think
it should also accept an optional reason=... keyword argument).  Based
on it, the way to skip only a few lines in a larger test should be with
a similar helper check_impl_detail(*vm_names) which returns True or False.

I agree that "impl_detail()" wasn't the best name originally, but in
Nick's proposed approach, "impl_detail()" sounds like exactly the right
name.

I also like Nick's approach because it means that in the various little
cases where, for some elegance argument, CPython is really wrong, then
it can be "officialized" by writing a test that is skipped on CPython :-)

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4243] has_key doc could be clearer

[David W. Lambert]

David W. Lambert <[EMAIL PROTECTED]> added the comment:

The D'Arcy J.M. Cain wording is clearer.

"dict.has_key(key) is deprecated.  Use "key in dict" instead." would
improve python.

--
nosy: +LambertDW

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4243] has_key doc could be clearer

[D'Arcy J.M. Cain]

D'Arcy J.M. Cain <[EMAIL PROTECTED]> added the comment:

The original is not technically ambiguous modulo the dict/d issue.  The
suggested text just makes it more obvious.

We just don't want to reduce the possibility of no confusion.  :-)

--
nosy: [EMAIL PROTECTED]

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4216] subprocess.Popen hangs at communicate() when child exits

[Amy]

Amy <[EMAIL PROTECTED]> added the comment:

Yes, I can only replicate this issue with command to start firewall.
Stopping firewall or other service commands don't have the problem.
Check Point firewall is a kernel application. 

Somehow select system call is interrupted and can't terminate the PIPE.
I don't know what interrupt it is, though.

I'll collect the full log and attach it here.

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4216] subprocess.Popen hangs at communicate() when child exits

[STINNER Victor]

STINNER Victor <[EMAIL PROTECTED]> added the comment:

The bug should be fixed in Python 2.5 since it uses:

while read_set or write_set:
try:
rlist, wlist, xlist = select.select(read_set, write_set, 
[])
except select.error, e:
if e[0] == errno.EINTR:
continue
else:
raise

EINTR is supported in subprocess for select(), read(), write() and 
waitpid()

Can't you migrate to Python 2.5 or 2.6? You can try to copy 
subprocess.py from Python 2.5 to Python 2.4.

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3022] mailbox module, two small fixes

[STINNER Victor]

STINNER Victor <[EMAIL PROTECTED]> added the comment:

@gpolo: your patch is correct, but I prefer line.rstrip() to 
line.strip(). My new patch combines your two patches + replace strip 
by rstrip + use itervalues() instead of items() in MH.pack().

--
nosy: +haypo
Added file: http://bugs.python.org/file11918/mailbox.patch

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4204] Cannot build _multiprocessing, math, mmap and readline of Python 2.6 on FreeBSD 4.11 w/ gcc 2.95.4

[Akira Kitada]

Akira Kitada <[EMAIL PROTECTED]> added the comment:

Christian,
Thank you for the review.
Let me know if there is anything I could help with this.

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4245] threading documentation: reorder sections

[Michael Hoffman]

New submission from Michael Hoffman <[EMAIL PROTECTED]>:

It is somewhat confusing that the meat of the threading module, the
Thread object itself, is so far down in the documentation. It should be
the first  section after the module functions and objects.

http://docs.python.org/library/threading.html

--
assignee: georg.brandl
components: Documentation
messages: 75422
nosy: georg.brandl, hoffman
severity: normal
status: open
title: threading documentation: reorder sections

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1673409] datetime module missing some important methods

[STINNER Victor]

STINNER Victor <[EMAIL PROTECTED]> added the comment:

I wrote this function is my program:

def timedelta2seconds(delta):
"""
Convert a datetime.timedelta() objet to a number of second
(floatting point number).

>>> timedelta2seconds(timedelta(seconds=2, microseconds=4))
2.04
>>> timedelta2seconds(timedelta(minutes=1, milliseconds=250))
60.25
"""
return delta.microseconds / 100.0 \
+ delta.seconds + delta.days * 60*60*24

About the use cases: I use it to compute the compression rate of an 
audio song (bytes / seconds), to compute the bit rate of a video 
(bytes / seconds). I'm using datetime.timedelta() to store the 
audio/video duration.

It's not related to time_t: see issue #2736 for 
datetime.datetime.totimestamp(). And about time_t: I don't about 31 
bits signed integer. It's not beacuse other programs have arbitrary 
limits than Python should also be limited.

About the patch: I don't like the name "tosecs", it's not consistent 
with the constructor: timedelta(seconds=...).tosec[ond]s(). And why 
dropping the microseconds? For short duration, microseconds are 
useful.

--
nosy: +haypo

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4243] has_key doc could be clearer

[Terry J. Reedy]

Terry J. Reedy <[EMAIL PROTECTED]> added the comment:

I believe "deprecated" at the end is the sort of dangling modifier
deprecated by English style books I have read. I felt it to be
sufficiently awkward and potentially confusing, at least for a moment,
to be worth a few minutes to report and change.  Another suggestion for
improvement:

"dict.has_key(key), now deprecated, is equivalent to key in dict, the
recommended replacement."

With or without the (optional) final phrase, this is smoother and
impossible to misread.

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4176] segfault with pickle if 4th or 5th item of tuple returned by __reduce__ is not an iterator

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc <[EMAIL PROTECTED]> added the comment:

I corrected the test in the py3k branch.
I don't know why I did not make it similar to the one in trunk; I guess 
I ran the test suite on the wrong directory... Sorry for the 
inconvenience.

Regarding the consistency between python and C, I don't think it is 
necessary to be so strict. If the python version can allow a weaker 
version of the "iterator" concept, let be it.
OTOH, in 3.0 the C version was rewritten to be quasi identical to the 
Python one, so I do understand your desire to have similar code.

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1673409] datetime module missing some important methods

[STINNER Victor]

STINNER Victor <[EMAIL PROTECTED]> added the comment:

New patch based on catlee's patch: add toseconds() method to timedelta 
but use the float type to keep the microseconds. The error between the 
exact value and IEEE754 value is small: the error is smaller than one 
second even with 9 days:

 - with less than 16 days, the microsecond error is smaller than 
0,01%.
 - with less than 1000 days, the microsecond error is smaller than 1%
 - with 99500 days or more, the microsecond error is bigger than 90%

To compute the error in microseconds:
>>> d=100; m=1
>>> e=abs((timedelta(days=d, microseconds=m).toseconds() - 
d*86400)*1e6 - m)
>>> e*100/m
0.024044513702392578

For the seconds, this is no error even with 9 days. Error in 
seconds:

>>> d=9; s=1; timedelta(days=d, seconds=m).toseconds() - 
d*86400, s
(1.0, 1)

(no error, both values are the same)

--
keywords: +patch
Added file: http://bugs.python.org/file11919/timedelta_toseconds_float.patch

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1544339] _ctypes fails to build on Solaris x86 32-bit (Sun compiler)

[Ed Summers]

Changes by Ed Summers <[EMAIL PROTECTED]>:


--
nosy: +edsu

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4243] has_key doc could be clearer

[Benjamin Peterson]

Benjamin Peterson <[EMAIL PROTECTED]> added the comment:

After consulting with an English teacher who agreed that the phrasing
was awkward, I fix it up in r67070.

--
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4176] segfault with pickle if 4th or 5th item of tuple returned by __reduce__ is not an iterator

[Alexandre Vassalotti]

Alexandre Vassalotti <[EMAIL PROTECTED]> added the comment:

Hirokazu Yamamoto wrote
> Hmm, but python document says,
> (http://docs.python.org/library/stdtypes.html#typeiter)
>
> >The iterator objects themselves are required to support the
> >following two methods, which together form the iterator protocol:
>
> Is this false information?

Oh, you are right. I got confused by looking at the implementation of
PyIter_Check(), which only verifies that tp_next is not NULL. Anyway, 
_batch_appends() and _batch_setitems() in pickle.py calls iter() on the
iterators; so, the iterators must provide __iter__ too.

Personally, I wouldn't bother about checking for __iter__ to avoid
adding a new method to Pickler and also to save a few hasattr() calls. 
But I have to admit, it is really just nitpicking at this point.

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4225] unicode_literals doesn't work in exec

[Benjamin Peterson]

Benjamin Peterson <[EMAIL PROTECTED]> added the comment:

This problem will still persist for anybody who uses PyParser_* APIs and
then PyNode_Compile, but we can probably only document that.

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4176] segfault with pickle if 4th or 5th item of tuple returned by __reduce__ is not an iterator

[Alexandre Vassalotti]

Alexandre Vassalotti <[EMAIL PROTECTED]> added the comment:

Amaury Forgeot d'Arc wrote:
> Regarding the consistency between python and C, I don't think it is 
> necessary to be so strict. If the python version can allow a weaker 
> version of the "iterator" concept, let be it.

I guess you're right. However, my only fear is that people will write
code for pickle.py and then, when they run it on _pickle, their code
will fail due to the stricter requirements. In addition, I think having
the same requirements make it easier to write tests for both
implementations.

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4233] open(0, closefd=False) prints 3 warnings

[Christian Heimes]

Christian Heimes <[EMAIL PROTECTED]> added the comment:

I don't see a good 'n easy way to fix the issue. close() is called in
too many places and I don't wanna add more checks in Python code. 

This patch reduces the mass of warnings to one, but it also changes the
semantic of close() a bit. However it seems logical to set the fd
attribute of the file object to -1 (meaning closed).

Index: Modules/_fileio.c
===
--- Modules/_fileio.c   (Revision 67068)
+++ Modules/_fileio.c   (Arbeitskopie)
@@ -60,7 +60,8 @@
 static PyObject *
 fileio_close(PyFileIOObject *self)
 {
-   if (!self->closefd) {
+   if (!self->closefd && self->fd >= 0) {
+   self->fd = -1;
if (PyErr_WarnEx(PyExc_RuntimeWarning,
 "Trying to close unclosable fd!", 3) < 0) {
return NULL;

--
nosy: +christian.heimes
priority: critical -> release blocker

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4211] frozen packages set an improper __path__ value

[Brett Cannon]

Brett Cannon <[EMAIL PROTECTED]> added the comment:

I have an attached patch that fixes the reported problem.

First, it adds a sanity check that no empty module name is checked for
(crashes the interpreter otherwise).

Second, the __path__ attribute is now a list. This does break
backwards-compatibility and thus cannot be backported to 2.6.

Third, I removed the special-casing of frozen packages and just made
frozen module checks a universal thing. This did change the module
resolution order such that frozen modules are checked before built-in
modules and registered modules under Windows (whatever those are).
Moving frozen modules after those two cases are possible if it's really
desired.

At this point I need a review to get this into 3.0 and a decision on
whether to backport to 2.7 (I say don't bother, out of
backward-compatibility, but it probably wouldn't really hurt anything
either).

--
assignee: brett.cannon -> 
keywords: +needs review, patch
Added file: http://bugs.python.org/file11920/issue4211.diff

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4243] has_key doc could be clearer

[Martin v. Löwis]

Martin v. Löwis <[EMAIL PROTECTED]> added the comment:

Benjamin: Thanks for asking your teacher! It's curious that all the
foreigners have no problems with the formulation, and all the native
speakers do... There is clearly something to the English language that
we haven't mastered yet.

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4242] Classify language vs. impl-detail tests, step 1

[Nick Coghlan]

Nick Coghlan <[EMAIL PROTECTED]> added the comment:

My idea above won't really support Armin's idea of being able to exclude
certain known-broken implementations. The check function would need to
be handled differently to support that use case:

# In test_support.py
vm = platform.python_implementation().lower()
reference_vm = "cpython"

def check_impl_detail(implemented=(reference_vm,), broken=()):
  # Skip known broken implementations
  if broken:
broken = [vm.lower() for vm in broken]
if vm in broken:
  return False
  # Only check named implementations
  if implemented:
implemented = [vm.lower() for vm in implemented]
return vm in implemented
  # No specific implementations named, so expect it to
  # work on implementations that are not known to be broken
  return True
  
def impl_detail(implemented=(reference_vm,), broken=(), msg=''):
  if check_impl_detail(implemented, broken):
# Test the implementation detail
  else:
# Skip this test (incude 'msg' in the skip message)

It would be pretty easy to build cpython_only, jython_only, pypy_only
etc checks and decorators on top of that kind of infrastructure.

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4233] open(0, closefd=False) prints 3 warnings

[STINNER Victor]

STINNER Victor <[EMAIL PROTECTED]> added the comment:

@christian: Your patch doesn't work: if close() if called twice, the 
file is really closed :-/

Here is a new patch:
 - _FileIO.close() sets self->fd to -1 but don't show a warning anymore 
because the operation is valid: it does really close the _FileIO object
 - add two tests for two problems: read is now blocked if the file is 
closed, and the warning displayed by FileIO.__del__

--
keywords: +patch
nosy: +haypo
Added file: http://bugs.python.org/file11921/fileio_closefd.patch

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4233] open(0, closefd=False) prints 3 warnings

[STINNER Victor]

STINNER Victor <[EMAIL PROTECTED]> added the comment:

christian just told me that my svn repos was old. Here is an updated 
version of my patch. I now use io.open() instead of io.BufferedReader() 
in the tests.

Added file: http://bugs.python.org/file11922/fileio_closefd-2.patch

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4233] open(0, closefd=False) prints 3 warnings

[STINNER Victor]

Changes by STINNER Victor <[EMAIL PROTECTED]>:


Removed file: http://bugs.python.org/file11921/fileio_closefd.patch

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4233] open(0, closefd=False) prints 3 warnings

[Christian Heimes]

Christian Heimes <[EMAIL PROTECTED]> added the comment:

Another patch based on Victor's patch. It adds some additional tests and
exposes the internal attribute closefd.

Added file: http://bugs.python.org/file11923/fileio_closefd3.patch

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4220] Builtins treated as free variables?

[Terry J. Reedy]

Terry J. Reedy <[EMAIL PROTECTED]> added the comment:

The request as stated is invalid.
'Int' and 'long' are built-in names, not keywords.

The context of the cited sentence is
"If a name is bound in a block, it is a local variable of that block,
unless declared as nonlocal. If a name is bound at the module level, it
is a global variable. (The variables of the module code block are local
and global.) If a variable is used in a code block but not defined
there, it is a free variable."

Built-in names are not defined in the code block.  Therefore, they are
free names (variables).  However, there is NO mention of builtins in
this chapter up to this point*, so I can see how one could miss that.  
* The previous 'identifiers' chapter has only this:
"The special identifier _ is used in the interactive interpreter to
store the result of the last evaluation; it is stored in the builtins
module."

So something like the following could be added:
"Free variables include the names of built-in objects."

where *built-in objects* is linked to that section near the top of the
Library manual.  (The references later in the chapter are to the Lib
manual entry on the builtins module, which pretty much repeats what is
said later in the chapter.)

--
nosy: +tjreedy
priority:  -> low

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4220] Builtins treated as free variables?

[Terry J. Reedy]

Changes by Terry J. Reedy <[EMAIL PROTECTED]>:


--
versions: +Python 3.0

___
Python tracker <[EMAIL PROTECTED]>

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com