[issue15040] stdlib compatability with pypy: mailbox.py

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  added the comment:

I'm not sure about the __del__: if pypy's deferred garbage collection is not 
enough to close self._file, how can a __del__ method help?

--
nosy: +amaury.forgeotdarc

___
Python tracker 

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

[issue13691] pydoc help (or help('help')) should show the doc for help

[Petr Kubat]

Petr Kubat  added the comment:

I see. So calling help('help') should produce the documentation on the help() 
function and typing help at the help> prompt should print the help for the 
prompt.
Tricky indeed. I think I'll look at it during the day after tomorrow and post 
some results (if any).

--

___
Python tracker 

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

[issue13857] Add textwrap.indent() as counterpart to textwrap.dedent()

[Nick Coghlan]

Changes by Nick Coghlan :


--
assignee:  -> ncoghlan
stage: needs patch -> patch review

___
Python tracker 

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

[issue7300] Unicode arguments in str.format()

[Gökçen Eraslan]

Changes by Gökçen Eraslan :


--
nosy: +Gökçen.Eraslan

___
Python tracker 

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

[issue4489] shutil.rmtree is vulnerable to a symlink attack

[Hynek Schlawack]

Hynek Schlawack  added the comment:

Fair enough, I'm not going to question your obviously superior judgement here. 
:)

However, your patch currently breaks the test suite on any platform that uses 
the fallback rmtree: You forgot the ignore_errors=False in the _rmtree_unsafe 
signature (and obviously also the argument when calling it as a fallback).

You also didn't seem to have touched the tests?

--

___
Python tracker 

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

[issue15043] test_gdb is disallowed by default security settings in Fedora 17

[Nick Coghlan]

New submission from Nick Coghlan :

Running test_gdb on Fedora 17 produces a litany of the following error:

- warning: File "/home/ncoghlan/devel/py3k/python-gdb.py" auto-loading has been 
declined by your `auto-load safe-path' set to 
"/usr/share/gdb/auto-load:/usr/lib/debug:/usr/bin/mono-gdb.py".

Presumably some security features in gdb have either been added, or enabled by 
default, with the F17 update.

The devguide needs to be updated with a reference to the relevant gdb security 
settings so contributors can get it running again.

--
components: Devguide
messages: 162610
nosy: dmalcolm, ezio.melotti, ncoghlan
priority: normal
severity: normal
status: open
title: test_gdb is disallowed by default security settings in Fedora 17
type: enhancement

___
Python tracker 

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

[issue15043] test_gdb is disallowed by default security settings in Fedora 17

[Nick Coghlan]

Nick Coghlan  added the comment:

In addition, we should probably report this as a test skip rather than as a 
litany of test failures.

--
components: +Tests

___
Python tracker 

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

[issue15044] _dbm not building on Fedora 17

[Nick Coghlan]

New submission from Nick Coghlan :

After upgrading from Fedora 16 -> 17, my previously working trunk build is 
getting the following error:

Building '_dbm' extension
gcc -pthread -fPIC -Wno-unused-result -g -O0 -Wall -Wstrict-prototypes 
-DHAVE_NDBM_H -IInclude -I. -I./Include -I/usr/local/include 
-I/home/ncoghlan/devel/py3k -c /home/ncoghlan/devel/py3k/Modules/_dbmmodule.c 
-o 
build/temp.linux-x86_64-3.3-pydebug/home/ncoghlan/devel/py3k/Modules/_dbmmodule.o
gcc -pthread -shared 
build/temp.linux-x86_64-3.3-pydebug/home/ncoghlan/devel/py3k/Modules/_dbmmodule.o
 -L/usr/local/lib -o build/lib.linux-x86_64-3.3-pydebug/_dbm.cpython-33dm.so
*** WARNING: renaming "_dbm" since importing it failed: 
build/lib.linux-x86_64-3.3-pydebug/_dbm.cpython-33dm.so: undefined symbol: 
dbm_nextkey

Failed to build these modules:
_dbm

--
components: Extension Modules
messages: 162612
nosy: dmalcolm, ncoghlan
priority: normal
severity: normal
status: open
title: _dbm not building on Fedora 17
type: compile error
versions: Python 3.3

___
Python tracker 

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

[issue13857] Add textwrap.indent() as counterpart to textwrap.dedent()

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 6f7afe25d681 by Nick Coghlan in branch 'default':
Close #13857: Added textwrap.indent() function (initial patch by Ezra
http://hg.python.org/cpython/rev/6f7afe25d681

--
nosy: +python-dev
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

___
Python tracker 

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

[issue10469] test_socket fails using Visual Studio 2010

[Kristján Valur Jónsson]

Kristján Valur Jónsson  added the comment:

This has been fixed with the proper 2010 support

--
resolution:  -> fixed
status: open -> closed
superseder:  -> Support Visual Studio 2010

___
Python tracker 

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

[issue13857] Add textwrap.indent() as counterpart to textwrap.dedent()

[Nick Coghlan]

Nick Coghlan  added the comment:

Ezra (and anyone interested) may want to take a look at the checked in version 
to see some of the changes I made while preparing the patch for commit.

- name changes and slight restructure as discussed on the review
- splitlines() invocation changed as discussed above
- doc examples changed to doctest style
- tests reworked to use a parameterised style (taking the easy way out of just 
failing on the first broken case, since there aren't that many cases and the 
test is quick to run)
- default predicate reworked to round trip with textwrap.dedent

--
resolution: fixed -> 
stage: committed/rejected -> patch review
status: closed -> open

___
Python tracker 

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

[issue10854] Output .pyd name in error message of ImportError when DLL load fails

[Kristján Valur Jónsson]

Kristján Valur Jónsson  added the comment:

Brian, reopening this since the original issue isn't addressed:  The "path" and 
"module" attributes aren't part of the error "repr"

--
status: closed -> open

___
Python tracker 

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

[issue15045] Make textwrap.dedent() consistent with str.splitlines(True) and str.strip()

[Nick Coghlan]

New submission from Nick Coghlan :

In working on #13857, I noticed that the current regex based implementation of 
textwrap.dedent() is limited specifically to ASCII whitespace (tabs and spaces) 
with Unix line endings (a line containing solely a Windows "\r\n" line ending 
will be deemed to contain a non-whitespace character, since "\r" isn't 
recognised by the regex)

The new textwrap.indent() function added in #13857 takes a much simpler 
approach to whitespace handling: its definition of a "line" is exactly that of 
"text.splitlines(True)", while its definition of a line that does not consist 
solely of whitespace is "bool(line.strip())"

As a simple example of how that can make a difference, consider:

>>> "\N{NO-BREAK SPACE}".strip()
''

One way to remedy this would be to replace the regex based implementation of 
textwrap.dedent with a simpler one written in terms of text.splitlines(True) 
and line.strip().

--
components: Library (Lib)
messages: 162617
nosy: ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Make textwrap.dedent() consistent with str.splitlines(True) and 
str.strip()
type: enhancement
versions: Python 3.4

___
Python tracker 

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

[issue13857] Add textwrap.indent() as counterpart to textwrap.dedent()

[Nick Coghlan]

Changes by Nick Coghlan :


--
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

___
Python tracker 

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

[issue11445] python.exe on OS X shared-llbrary build erroneously linked to MacPorts python library

[Samuel John]

Changes by Samuel John :


--
nosy: +samueljohn

___
Python tracker 

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

[issue10133] multiprocessing: conn_recv_string() broken error handling

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 60a7b704de5c by Richard Oudkerk in branch '2.7':
Issue #10133: Make multiprocessing deallocate buffer if socket read fails.
http://hg.python.org/cpython/rev/60a7b704de5c

New changeset 5643697070c0 by Richard Oudkerk in branch '3.2':
Issue #10133: Make multiprocessing deallocate buffer if socket read fails.
http://hg.python.org/cpython/rev/5643697070c0

--
nosy: +python-dev

___
Python tracker 

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

[issue13756] Python3.2.2 make fail on cygwin

[Jason Tishler]

Jason Tishler  added the comment:

I offer the attached patch for consideration. AFAICT, only the Makefile.pre.in 
and build_ext.py changes are required. I included the makesetup change for 
completeness and to be consistent with the other changes.

--
keywords: +patch
nosy: +jlt63, yselkowitz
Added file: http://bugs.python.org/file25936/3.2.3-libpython-abi.patch

___
Python tracker 

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

[issue15046] Missing cast to Py_ssize_t in socket_connection.c

[Marco den Otter]

New submission from Marco den Otter :

In the file socket_connection.c on line 139 a cast to Py_ssize_t is missing for 
the return value.

Is:
  return res < 0 ? res : ulength;
Should be
  return res < 0 ? (Py_ssize_t)res : (Py_ssize_t)ulength;

Now it can be possible that a close of the socket is not detected.

Found the bug by creating a server client that only sends the length of a data 
package and then closing the socket. 

Without the cast the calling function (connection_recvbytes in connection.h) 
will try to return an object because of not detecting the result was smaller 
then 0.

--
components: Library (Lib)
messages: 162620
nosy: MOtter
priority: normal
severity: normal
status: open
title: Missing cast to Py_ssize_t in socket_connection.c
type: behavior
versions: Python 2.7

___
Python tracker 

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

[issue14599] Windows test_import failure thanks to ImportError.path

[Brett Cannon]

Brett Cannon  added the comment:

If you look at line 127 in importlib/_bootstrap.py you will see that it is an 
os.open() call to open the bytecode file for exclusive writing. I'm willing to 
bet the buildbot didn't have the directory writable or something and that 
triggered the issue. Regardless, this has nothing to do with the finder's cache.

Antoine might have a little more insight since he wrote the atomic code 
initially. If not then this issue should be closed.

--

___
Python tracker 

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

[issue10133] multiprocessing: conn_recv_string() broken error handling

[Richard Oudkerk]

Richard Oudkerk  added the comment:

Thanks for the patch, I have applied it.  (I don't think there was a problem 
with the promotion rules because res was a never converted to UINT32.)

--
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

___
Python tracker 

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

[issue8028] self.terminate() from a multiprocessing.Process raises AttributeError exception

[Richard Oudkerk]

Richard Oudkerk  added the comment:

The docs were patched in changeset 9fa52478b32b, so I will close.

--
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

___
Python tracker 

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

[issue10037] multiprocessing.pool processes started by worker handler stops working

[Richard Oudkerk]

Changes by Richard Oudkerk :


--
resolution:  -> later
stage: patch review -> committed/rejected
status: open -> closed

___
Python tracker 

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

[issue8289] multiprocessing.Process.__init__ pickles all arguments

[Richard Oudkerk]

Richard Oudkerk  added the comment:

I don't think there is any problem here since you have control over which 
arguments you pass to __init__.

Without a reason why that is not a solution I will eventually close the issue 
as rejected.

--
resolution:  -> rejected
stage:  -> committed/rejected
status: open -> pending

___
Python tracker 

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

[issue12897] Support for iterators in multiprocessing map

[Richard Oudkerk]

Richard Oudkerk  added the comment:

Unless you have a reason why imap() does not solve the problem I will 
eventually close the issue as rejected.

--
resolution:  -> rejected
stage:  -> committed/rejected
status: open -> pending

___
Python tracker 

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

[issue14499] Extension module builds fail with Xcode 4.3 on OS X 10.7 due to SDK move

[Samuel John]

Changes by Samuel John :


--
nosy: +samueljohn

___
Python tracker 

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

[issue12897] Support for iterators in multiprocessing map

[andrew cooke]

andrew cooke  added the comment:

hi - i'm the original author (may be using a different account).  as far as i 
remember, i raised this because it seemed relevant given the link i gave.  if 
you've looked at the issue and think your approach would work, or that this 
should be closed, or whatever, that's fine by me.  i'm not going to check 
myself - i can't remember anything about this now (nearly a year later) and 
it's not my place to worry about your code (no offence - just trying to clarify 
that i have no skin in this game).

--
status: pending -> open

___
Python tracker 

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

[issue8289] multiprocessing.Process.__init__ pickles all arguments

[Ram Rachum]

Ram Rachum  added the comment:

I opened this issue 2 years ago, and I don't remember it being easily solvable 
back then. But I've long forgotten what the problems were, and I've lost 
personal interest in it, so I guess we'll just let it go.

--
status: pending -> open

___
Python tracker 

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

[issue3518] multiprocessing: BaseManager.from_address documented but doesn't exist

[Roundup Robot]

Roundup Robot  added the comment:

New changeset c2910971eb86 by Richard Oudkerk in branch 'default':
Issue #3518: Remove references to non-existent BaseManager.from_address()
http://hg.python.org/cpython/rev/c2910971eb86

--
nosy: +python-dev

___
Python tracker 

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

[issue8289] multiprocessing.Process.__init__ pickles all arguments

[Richard Oudkerk]

Richard Oudkerk  added the comment:

OK, I'll close.

--
status: open -> closed

___
Python tracker 

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

[issue12897] Support for iterators in multiprocessing map

[Richard Oudkerk]

Richard Oudkerk  added the comment:

I'll close then.

--
status: open -> closed

___
Python tracker 

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

[issue3518] multiprocessing: BaseManager.from_address documented but doesn't exist

[Richard Oudkerk]

Changes by Richard Oudkerk :


--
stage:  -> committed/rejected
status: open -> closed

___
Python tracker 

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

[issue9527] Add aware local time support to datetime module

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

This was originally posted on python-dev, but I hope reposting it here will 
make this issue easier to navigate.

"""
With addition of fixed offset timezone class and the timezone.utc
instance [0], it is easy to get UTC time as an aware datetime
instance:

>>> datetime.now(timezone.utc)
datetime.datetime(2010, 8, 3, 14, 16, 10, 670308, tzinfo=datetime.timezone.utc)

However, if you want to keep time in your local timezone, getting an
aware datetime is almost a catch 22.  If you know your timezone UTC
offset, you can do

>>> EDT = timezone(timedelta(hours=-4))
>>> datetime.now(EDT)
datetime.datetime(2010, 8, 3, 10, 20, 23, 769537,
tzinfo=datetime.timezone(datetime.timedelta(-1, 72000)))

but the problem is that there is no obvious or even correct way to
find local timezone UTC offset. [1]

In a comment on issue #5094 ("datetime lacks concrete tzinfo
implementation for UTC"), I proposed to address this problem in a
localtime([t]) function that would return current time (or time
corresponding to the optional datetime argument) as an aware datetime
object carrying local timezone information in a tzinfo set to an
appropriate timezone instance.   This solution is attractive by its
simplicity, but there are several problems:

1. An aware datetime cannot carry all information that system
localtime() supplies in a time tuple.  Specifically, the is_dst flag
is lost.  This is not a problem for most applications as long as
timezone UTC offset and timezone name are available, but may be an
issue when interoperability with the time module is required.

2.  Datetime's tzinfo interface was designed with the idea that
<2010-11-06 12:00 EDT> + <1 day> =  <2010-11-07 12:00 EST>, not
<2010-11-07 12:00 EDT>. It other words, if I have lunch with someone
at noon (12:00 EDT) on Saturday the day before first Sunday in
November, and want to meet again "at the same time tomorrow", I mean
12:00 EST, not 24 hours later.  With localtime() returning datetime
with tzinfo set to fixed offset timezone, however, localtime()  +
timedelta(1) will mean exactly 24 hours later and the result will be
expressed in an unusual for the given location timezone.

An alternative approach is the one recommended in the python manual.
[3]  One could implement a LocalTimezone class with utcoffset(),
tzname() and dst() extracting information from system mktime and
localtime calls.  This approach has its own shortcomings:

1. While adding integral number of days to datetimes in business
setting, it is natural to expect automatic timezone adjustments, it is
not as clearcut when adding hours or minutes.

2. The tzinfo.utcoffset() interface that expects *standard* local time
as an argument is confusing to many users.  Even the "official"
example in the python manual gets it wrong. [4]

3. datetime(..., tzinfo=LocalTimezone()) is ambiguous during the
"repeated hour" when local clock is set back in DST to standard time
transition.

As far as I can tell, the only way to resolve the last problem is to
add is_dst flag to the datetime object, which would also be the
only way to achieve full interoperability between datetime objects and
time tuples. [5]

The traditional answer to a call for improvement of timezone support in
datetime module has been: "this is up to 3rd parties to implement."
Unfortunately, stdlib is asking 3rd parties to implement an impossible
interface without giving access to the necessary data.   The
impossibility comes from the requirement that dst() method should find
out whether local time represents DST or standard time while there is
an hour each year when the same local time can be either.  The missing
data is the system UTC offset when it changes historically.  The time
module only gives access to the current UTC offset.

My preference is to implement the first alternative - localtime([t])
returning aware datetime with fixed offset timezone.  This will solve
the problem of python's lack of access to the universally available
system facilities that are necessary to implement any kind of aware
local time support.

[0] http://docs.python.org/dev/library/datetime.html#timezone-objects
[1] http://bugs.python.org/issue1647654
[2] http://bugs.python.org/issue5094#msg106997
[3] http://docs.python.org/library/datetime.html#tzinfo-objects
[4] http://bugs.python.org/issue9063
[5] http://bugs.python.org/issue9004
"""

-- http://mail.python.org/pipermail/python-dev/2010-August/102842.html

--

___
Python tracker 

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

[issue15046] Missing cast to Py_ssize_t in socket_connection.c

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  added the comment:

This was fixed 3 hours ago, with issue10133 :)

--
nosy: +amaury.forgeotdarc
resolution:  -> out of date
status: open -> closed
superseder:  -> multiprocessing: conn_recv_string() broken error handling

___
Python tracker 

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

[issue9004] datetime.utctimetuple() should not set tm_isdst flag to 0

[Éric Araujo]

Éric Araujo  added the comment:

> Just recommend the astimezone use in the docs
and recommend creating tz-aware instances in the first time (i.e. calling 
now(utc) instead of utcnow()), +1.

--
nosy: +eric.araujo

___
Python tracker 

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

[issue15047] Cygwin install (regen) problem

[Jason Tishler]

New submission from Jason Tishler :

The Cygwin build is failing during make install -- specifically, during the 
regen step:

[snip]
mkdir 
/home/jt/src/cygwin/cygwin-packages/1.7/python3-test/python-3.2.3-1/src/Python-3.2.3/Lib/plat-cygwin
cp 
/home/jt/src/cygwin/cygwin-packages/1.7/python3-test/python-3.2.3-1/src/Python-3.2.3/Lib/plat-generic/regen
 
/home/jt/src/cygwin/cygwin-packages/1.7/python3-test/python-3.2.3-1/src/Python-3.2.3/Lib/plat-cygwin/regen
export PATH; PATH="`pwd`:$PATH"; \
export PYTHONPATH; PYTHONPATH="`pwd`/Lib"; \
export DYLD_FRAMEWORK_PATH; DYLD_FRAMEWORK_PATH="`pwd`"; \
export EXE; EXE=".exe"; \
cd 
/home/jt/src/cygwin/cygwin-packages/1.7/python3-test/python-3.2.3-1/src/Python-3.2.3/Lib/plat-cygwin;
  ./regen
python$EXE ../../Tools/scripts/h2py.py -i '(u_long)' /usr/include/netinet/in.h
Could not find platform independent libraries 
Could not find platform dependent libraries 
Consider setting $PYTHONHOME to [:]
Fatal Python error: Py_Initialize: Unable to get the locale encoding
ImportError: No module named encodings
./regen: line 3:  2976 Aborted (core dumped) python$EXE 
../../Tools/scripts/h2py.py -i '(u_long)' /usr/include/netinet/in.h
[snip]

Note that I seem to be running into the same or similar problem as the 
following:

http://bugs.python.org/issue3626#msg72415

I was able to workaround the core dump problem with the following patch:

diff -u Python-2.6.5.orig/Makefile.pre.in Python-2.6.5/Makefile.pre.in
--- Python-2.6.5.orig/Makefile.pre.in   2009-12-24 09:19:38.0 -0500
+++ Python-2.6.5/Makefile.pre.in2010-04-13 17:05:04.368555900 -0400
@@ -910,7 +910,7 @@
mkdir $(srcdir)/Lib/$(PLATDIR)
cp $(srcdir)/Lib/plat-generic/regen $(srcdir)/Lib/$(PLATDIR)/regen
export PATH; PATH="`pwd`:$$PATH"; \
-   export PYTHONPATH; PYTHONPATH="`pwd`/Lib"; \
+   export PYTHONPATH; PYTHONPATH="$(srcdir)/Lib"; \
export DYLD_FRAMEWORK_PATH; DYLD_FRAMEWORK_PATH="`pwd`"; \
export EXE; EXE="$(BUILDEXE)"; \
cd $(srcdir)/Lib/$(PLATDIR); $(RUNSHARED) ./regen

Note that I'm building outside of the source tree, so when the original version 
sets PYTHONPATH to the following:

"`pwd`/Lib"

it was guaranteed to point to a nonexistent directory.

Unfortunately, now the build fails as follows:

[snip]
mkdir 
/home/jt/src/cygwin/cygwin-packages/1.7/python3-test/python-3.2.3-1/src/Python-3.2.3/Lib/plat-cygwin
cp 
/home/jt/src/cygwin/cygwin-packages/1.7/python3-test/python-3.2.3-1/src/Python-3.2.3/Lib/plat-generic/regen
 
/home/jt/src/cygwin/cygwin-packages/1.7/python3-test/python-3.2.3-1/src/Python-3.2.3/Lib/plat-cygwin/regen
export PATH; PATH="`pwd`:$PATH"; \
export PYTHONPATH; 
PYTHONPATH="/home/jt/src/cygwin/cygwin-packages/1.7/python3-test/python-3.2.3-1/src/Python-3.2.3/Lib";
 \
export DYLD_FRAMEWORK_PATH; DYLD_FRAMEWORK_PATH="`pwd`"; \
export EXE; EXE=".exe"; \
cd 
/home/jt/src/cygwin/cygwin-packages/1.7/python3-test/python-3.2.3-1/src/Python-3.2.3/Lib/plat-cygwin;
  ./regen
python$EXE ../../Tools/scripts/h2py.py -i '(u_long)' /usr/include/netinet/in.h
Could not find platform independent libraries 
Could not find platform dependent libraries 
Consider setting $PYTHONHOME to [:]
Traceback (most recent call last):
  File 
"/home/jt/src/cygwin/cygwin-packages/1.7/python3-test/python-3.2.3-1/src/Python-3.2.3/Lib/sysconfig.py",
 line 334, in _init_posix
_parse_makefile(makefile, vars)
  File 
"/home/jt/src/cygwin/cygwin-packages/1.7/python3-test/python-3.2.3-1/src/Python-3.2.3/Lib/sysconfig.py",
 line 220, in _parse_makefile
with open(filename, errors="surrogateescape") as f:
IOError: [Errno 2] No such file or directory: 
'/usr/lib/python3.2/config-3.2m/Makefile'
[snip]

AFAICT, the problem is when regen runs, python thinks it is running out of an 
installation directory and not a build directory.

Does anyone know how to convince python to think it is running out its build 
directory even though it is being found in the PATH.  If not, does anyone have 
any other suggestions on how to resolve this problem?

--
components: Build
messages: 162634
nosy: jlt63, yselkowitz
priority: normal
severity: normal
status: open
title: Cygwin install (regen) problem
versions: Python 3.2

___
Python tracker 

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

[issue15040] stdlib compatability with pypy: mailbox.py

[mattip]

mattip  added the comment:

Revised patch: changes to mailbox.py were not needed for pypy. Someone did a 
good job with mailbox.py in stdlib 2.7.3

Now the patch only changes tests. The tests in 3.3 are very different, it seems 
to me there is little that can be reused there.

--
Added file: http://bugs.python.org/file25937/mailbox.patch

___
Python tracker 

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

[issue15040] stdlib compatability with pypy: mailbox.py

[R. David Murray]

R. David Murray  added the comment:

Ah, good.  I thought we'd fixed the open/close issues, but I could easily 
believe we had missed something (especially in Python2).

Since the fp stuff is gone in 3, I'd be OK with just applying this.

--
versions:  -Python 3.2, Python 3.3

___
Python tracker 

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

[issue14446] Remove deprecated tkinter functions

[Michael Driscoll]

Michael Driscoll  added the comment:

Do I need to do anything else to those patches I submitted?

--

___
Python tracker 

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

[issue14927] add "Do not supply 'int' argument" to random.shuffle docstring

[Michael Driscoll]

Michael Driscoll  added the comment:

I added the extra information to the docstring for the shuffle method and 
attached a patch.

--
keywords: +patch
nosy: +michael.driscoll
Added file: http://bugs.python.org/file25938/shuffle.patch

___
Python tracker 

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

[issue14927] add "Do not supply 'int' argument" to random.shuffle docstring

[Christopher Smith]

Christopher Smith  added the comment:

On Tue, Jun 12, 2012 at 1:34 AM, Michael Driscoll
 wrote:
>
> Michael Driscoll  added the comment:
>
> I added the extra information to the docstring for the shuffle method and 
> attached a patch.

Thanks Michael (and Python team)!

Chris

--

___
Python tracker 

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

[issue14906] rotatingHandler WindowsError

[Vinay Sajip]

Vinay Sajip  added the comment:

It could be a number of things which are keeping the file open, e.g.

* Windows indexing the volume for search
* Child process keeping files open (e.g. while copying log files - I can't tell 
what you're actually copying)

You may need to use a tool like FileMon or PSMon to see what's happening, but I 
don't see any evidence that it's a logging bug.

Is there a specific logging statement which is being called which leads to the 
error? There are several in your snippet.

--
assignee:  -> vinay.sajip
nosy: +vinay.sajip

___
Python tracker 

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

[issue13756] Python3.2.2 make fail on cygwin

[Roumen Petrov]

Roumen Petrov  added the comment:

Hi Jason,
if you look in default rule you will see the same, so this relict specific 
"else case" could be removed. Also in Lib/packaging/command/build_ext.py.

--
nosy: +rpetrov

___
Python tracker 

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

[issue14599] Windows test_import failure thanks to ImportError.path

[Roumen Petrov]

Roumen Petrov  added the comment:

There is one long standing issue with length of the build path ...

--
nosy: +rpetrov

___
Python tracker 

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

[issue14966] Fully document subprocess.CalledProcessError

[Michael Driscoll]

Michael Driscoll  added the comment:

I don't see the error, TimeoutExpired, documented either. At least the doc page 
mentions CalledProcessError a couple times. Do we want to use the docstring for 
CalledProcessError for the documentation page? Where on the page would it go? I 
assume we'd want an example showing how to use it?

--
nosy: +michael.driscoll

___
Python tracker 

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

[issue15041] tkinter documentation: update "see also" list

[Michael Driscoll]

Michael Driscoll  added the comment:

I thought the ebook, "Modern Tkinter for Busy Python Developers" by Mark 
Roseman was pretty good too: 
http://www.amazon.com/Modern-Tkinter-Python-Developers-ebook/dp/B0071QDNLO/ref=sr_1_1?ie=UTF8&qid=1339446684&sr=8-1

--
nosy: +michael.driscoll

___
Python tracker 

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

[issue13532] In IDLE, sys.stdout.write and sys.stderr can write any pickleable object

[Roger Serwy]

Roger Serwy  added the comment:

@Ramchandra: "__name__" does not exist for many objects.

This issue with the sys.stdout.write encompasses a lot of other issues 
involving the shortcomings of the RPCProxy object. The following code prevents 
another prompt from appearing:

>>> class A:
pass

>>> import sys
>>> sys.stdout.write(A)

Even though "A" is pickleable, IDLE gets stuck trying to write to stdout. In 
run.py, Executive.runcode gets stuck on "exec(code, self.locals)", and is not 
interruptable. Restarting the shell makes the IDLE shell responsive again to 
commands.

--

___
Python tracker 

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

[issue14599] Windows test_import failure thanks to ImportError.path

[Brett Cannon]

Brett Cannon  added the comment:

Roumen, what issue is that? Do you have an issue # you can share?

--

___
Python tracker 

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

[issue14446] Remove deprecated tkinter functions

[Andrew Svetlov]

Andrew Svetlov  added the comment:

Michael Driscoll, thank you for patch.
Let's go on after Python 3.3 release — those patches should be applied for 3.4.
For now we need to wait.

--

___
Python tracker 

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

[issue15048] Manually Installed Python Includes System Wide Paths

[James Kyle]

New submission from James Kyle :

This behavior is present on OS X 10.7 and framework builds.

In this case, the /Library/Python/ paths are included in every 
install. 

I would consider this behavior non-standard as in most manual python installs 
only that installations library paths are included.

This can lead to surprising and inconsistent behavior if multiple installs are 
present (very common on osx, e.g. macports + system install).

This originated as a macports bug ticket: https://trac.macports.org/ticket/34763

--
assignee: ronaldoussoren
components: Macintosh
messages: 162648
nosy: James.Kyle, ronaldoussoren
priority: normal
severity: normal
status: open
title: Manually Installed Python Includes System Wide Paths
type: behavior
versions: Python 2.7

___
Python tracker 

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

[issue15048] Manually Installed Python Includes System Wide Paths

[Ronald Oussoren]

Ronald Oussoren  added the comment:

This is intentional behavior, you can install packages you want to share 
between python installations in /Library/Python instead of the regular 
site-packages directory.

Macports could always patch their site.py file to avoid this.

--

___
Python tracker 

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

[issue15048] Manually Installed Python Includes System Wide Paths

[Ronald Oussoren]

Ronald Oussoren  added the comment:

This was added in issue4865.

(The same behavior is present in 3.2 and 3.3)

--
resolution:  -> rejected
versions: +Python 3.2, Python 3.3

___
Python tracker 

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

[issue15048] Manually Installed Python Includes System Wide Paths

[Ronald Oussoren]

Changes by Ronald Oussoren :


--
status: open -> closed

___
Python tracker 

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

[issue15048] Manually Installed Python Includes System Wide Paths

[James Kyle]

James Kyle  added the comment:

Am I missing something or were the problems delineated in issue #4865 solvable 
by simply sys.path.append("/Library/Python/2.7/site-packages")?

What would the process be for reopening this issue for discussion? 

I'm not sure this is the right way to address this. For example, what if other 
*nix distros started adding their own custom "common" paths, would Python begin 
implemented these distro specific deviations from standard behavior?

In my honest opinion, there's an expectation of package isolation in 
independent python installs.

--

___
Python tracker 

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

[issue15048] Manually Installed Python Includes System Wide Paths

[Ronald Oussoren]

Ronald Oussoren  added the comment:

Python installation are already not isolated: there is a per-user site-packages 
directory on all platforms that is shared between all installations of a 
particular python release. This directory is located in a subdirectory of 
~/.local on POSIX systems (including OSX).

Anyway, this cannot be changed for a released version of python because that 
would break backward compatibility. At "best" this could be disabled in python 
3.3 and even there I'm far from convinced that disabling this feature would be 
worthwhile.

--
nosy: +ned.deily

___
Python tracker 

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

[issue15048] Manually Installed Python Includes System Wide Paths

[James Kyle]

James Kyle  added the comment:

Fair enough. Thanks!

--

___
Python tracker 

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

[issue14599] Windows test_import failure thanks to ImportError.path

[Stefan Krah]

Stefan Krah  added the comment:

Brett, I reopened this because you said earlier that the test_reprlib
failure is due to a race condition where an invalidate_caches()
call is needed.

You're quite right of course that the new occurrence could be caused
by something unrelated. I can't reproduce the failure on Windows 7,
so it might be limited to XP.

--

___
Python tracker 

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

[issue1667546] Time zone-capable variant of time.localtime

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

Reopening.  given the uncertainty with #9527, this issue may result in getting 
the TZ-aware local time support in stdlib sooner.

--
resolution: duplicate -> 
stage: committed/rejected -> patch review
status: closed -> open
versions: +Python 3.3 -Python 3.2

___
Python tracker 

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

[issue14927] add "Do not supply 'int' argument" to random.shuffle docstring

[Raymond Hettinger]

Changes by Raymond Hettinger :


--
assignee:  -> rhettinger

___
Python tracker 

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

[issue14927] add "Do not supply 'int' argument" to random.shuffle docstring

[Raymond Hettinger]

Changes by Raymond Hettinger :


--
priority: normal -> low

___
Python tracker 

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

[issue15049] line buffering isn't always

[R. David Murray]

New submission from R. David Murray :

rdmurray@hey:~/python/p32>cat bad.py

This line is just ascii
A second line for good measure.
This comment contains undecodable stuff: "�" or "\\xe9" in "pass�"" cannot 
be decoded.

The last line above is in latin-1, with an é inside those quotes.

rdmurray@hey:~/python/p32>cat bug.py  
import sys
with open('./bad.py', buffering=int(sys.argv[1])) as f:
for line in f:
print(line, end='')
rdmurray@hey:~/python/p32>python3 bug.py -1
Traceback (most recent call last):
  File "bug.py", line 3, in 
for line in f:
  File "/usr/lib/python3.2/codecs.py", line 300, in decode
(result, consumed) = self._buffer_decode(data, self.errors, final)
UnicodeDecodeError: 'utf8' codec can't decode byte 0xe9 in position 99: 
invalid continuation byte
rdmurray@hey:~/python/p32>python3 bug.py 1 
Traceback (most recent call last):
  File "bug.py", line 3, in 
for line in f:
  File "/usr/lib/python3.2/codecs.py", line 300, in decode
(result, consumed) = self._buffer_decode(data, self.errors, final)
UnicodeDecodeError: 'utf8' codec can't decode byte 0xe9 in position 99:
invalid continuation byte
rdmurray@hey:~/python/p32>python3 bug.py 2
This line is just ascii
A second line for good measure.
Traceback (most recent call last):
  File "bug.py", line 3, in 
for line in f:
  File "/usr/lib/python3.2/codecs.py", line 300, in decode
(result, consumed) = self._buffer_decode(data, self.errors, final)
UnicodeDecodeError: 'utf8' codec can't decode byte 0xe9 in position 0: 
invalid
continuation byte

So, line buffering does not appear to buffer line by line.

I ran into this problem because I had a much larger file that I thought
was in utf-8.  When I got the encoding error, I was annoyed that the
error message didn't really tell me which line the error was on, but I
figured, OK, I'll just set line buffering and then I'll be able to tell.
But that didn't work.  Fortunately using '2' did workbut at a minimum
the docs need to be updated to indicate when line buffering really is
line buffering and when it isn't.

--
messages: 162656
nosy: pitrou, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: line buffering isn't always
type: behavior
versions: Python 3.2, Python 3.3

___
Python tracker 

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

[issue15048] Manually Installed Python Includes System Wide Paths

[Ned Deily]

Ned Deily  added the comment:

I have to admit that I'm not keen on this feature for the reasons James cited.  
And I think the example of the shared user site directory is not a good 
analogy.  In that case, you, as a user, have more control over the presence and 
contents of the directory since it is located within your home directory.  You 
would normally need administrator privilege to manipulate /Library/Python.  
And, in any case, it would be better if there *were* separate user site 
directories per Python instance, IMO.  Yes, you can play with sys.path after 
the fact but that's not very friendly.  It certainly can lead to confusion.  An 
uncontrived example:

$ sudo easy_install-2.7 appscript
[...]
Installed 
/Library/Python/2.7/site-packages/appscript-1.0.0-py2.7-macosx-10.7-intel.egg
$ /usr/bin/python2.7 -c "import appscript"
$ /usr/local/bin/python2.7 -c "import appscript"
Traceback (most recent call last):
  File "", line 1, in 
  File "build/bdist.macosx-10.7-intel/egg/appscript/__init__.py", line 8, in 

  File "build/bdist.macosx-10.7-intel/egg/aem/__init__.py", line 5, in 
  File "build/bdist.macosx-10.7-intel/egg/aem/ae.py", line 7, in 
  File "build/bdist.macosx-10.7-intel/egg/aem/ae.py", line 3, in __bootstrap__
ImportError: No module named pkg_resources

... because the non-system Python did not have Distribute or setuptools 
installed, whereas Apple supplies it with the system Python.  It's not the only 
package to fail in a similar way. I expect there are other cases where 
differences in extension module builds could cause problems.  To me, the 
feature seems to go against "explicit is better than implicit".

As far as I know, the only place where this behavior is documented is in the 
What's New documents for 2.7.  I wouldn't object to removing it in 3.3.

--

___
Python tracker 

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

[issue9527] Add aware local time support to datetime module

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

Two objections have been raised to the proposed datetime.localtime() function:

1. It offers the third subtly different way to obtain current time in datetime 
module.  The first two being provided by datetime.now() and datetime.today().

2. C library localtime function takes POSIX timestamp as an argument, so 
datetime.localtime() should follow suit.

I attach a prototype patch for a different approach: make datetime.astimezone() 
method supply local timezone information if no argument is given.

This patch also demonstrates that extracting all TZ information that platform 
may have knowledge of is not trivial.

--
Added file: http://bugs.python.org/file25939/datetime-astimezone-proto.diff

___
Python tracker 

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

[issue9527] Add aware local time support to datetime module

[Alexander Belopolsky]

Changes by Alexander Belopolsky :


Added file: http://bugs.python.org/file25940/testtz.py

___
Python tracker 

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

[issue15048] Manually Installed Python Includes System Wide Paths

[Ned Deily]

Ned Deily  added the comment:

A few more thoughts.  The original impetus for this feature was Issue4865.  The 
use case there seem to be from users of Google App Engine back when it was 
released using Python 2.5. It seems to me that the use of dmg installers for 
Python packages has diminished; certainly the unofficial packages at 
pythonmac.org haven't been updated for more recent releases. The issues with 
installing some packages (like PIL) with 3rd-party C library dependencies 
notwithstanding, I wonder if part of the original call for this feature was the 
fact that Apple does provide setuptools easy_install's with system Pythons and 
there is confusion that a setuptools/Distribute instance, with its own 
easy_install command, is needed for each Python.  Some of that confusion should 
diminish over time with the availability of "pip -E" and, starting with 3.3, a 
batteries-included installer command, pysetup.

Also, with regard to backward compatibility, I speculate that there hasn't been 
much notice of this feature since it only affects users of Python 2.7 on OS X 
10.7+.  For Python 3, the presence or absence of the feature doesn't affect 
anyone because Apple has yet to ship a system Python 3 so removing it from 3.3 
would have no backward compatibility impacts, unless an administrator manually 
created a /Library/Python/3.x for some reason and manually installed things 
there.

--

___
Python tracker 

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

[issue9527] Add aware local time support to datetime module

[James Henstridge]

James Henstridge  added the comment:

One problem I can see with using a fixed offset tzinfo for localtime is that it 
might confuse people when doing date arithmetic.  For example:

>>> d = datetime.localtime() + timedelta(days=7)

While it will give a correct answer as a point in time it will have the wrong 
time zone offset if run just before a daylight saving transition, which could 
be just as confusing.

I'm not sure how you'd solve this without e.g. importing pytz into the standard 
library though.

--

___
Python tracker 

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

[issue15003] make PyNamespace_New() public

[Eric Snow]

Eric Snow  added the comment:

> Is this documented in whatsnew?

I'm not sure what has been (none of my patches have done so).

> Also, I remember a discussion about making it public or not, but
> don’t recall a decision.

Amaury brought it up in msg162127.  His point was that the type is public in 
Python, so why not the C API?  That's about the extent of the discussion.  :)  
Do you see any harm in making PyNamespace_New() public?

> I personally find it bad that we have structseqs for most things, dicts
> in PEP 418 get_clock_info return values, and now simplenamespace for
> sys.implementation.

The use cases are different for the different types.  StructSequence/namedtuple 
provides fixed data structures for structured records.  A dict is essentially 
the opposite: an un-fixed data structure for dynamic namespaces, making no firm 
promises as to what the future holds.

SimpleNamespace fills a similar role to dicts, but offers a higher appearance 
of stability by virtue of using attributes vs. keys.  The problem is that 
moving from item-access to attribute-access is not a backward-compatible 
change.  That's the big reason why PEP 421 specified the use of an attr-based 
object.

--

___
Python tracker 

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