[issue14960] about the slowly HTTPServer

[Charles-François Natali]

Charles-François Natali  added the comment:

It's actually a duplicate of #6085 (already fixed).

Cheers!

--
nosy: +neologix
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> Logging in BaseHTTPServer.BaseHTTPRequestHandler causes lag

___
Python tracker 

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

[issue1470548] Bugfix for #1470540 (XMLGenerator cannot output UTF-16)

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
nosy: +loewis

___
Python tracker 

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

[issue1470548] Bugfix for #1470540 (XMLGenerator cannot output UTF-16)

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Oh, I see XMLGenerator completely outdated. It even has not been ported to 
Python 3. See function _write:

def _write(self, text):
if isinstance(text, str):
self._out.write(text)
else:
self._out.write(text.encode(self._encoding, _error_handling))

In Python 2 there was a choice between bytes and unicode strings. But in Python 
3 encoding never happens.

XMLGenerator does not distinguish between binary and text streams.

Here is a patch that fixes the work of XMLGenerator in Python 3. Unfortunately, 
it is impossible to avoid the loss of backward compatibility. I tried to keep 
the code to work for the most common cases, but some code which "worked" before 
may break (including I had to correct some tests).

--
Added file: http://bugs.python.org/file25760/XMLGenerator.patch

___
Python tracker 

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

[issue14796] Calendar module test coverage improved

[STINNER Victor]

STINNER Victor  added the comment:

> New changeset 98bc9e357f74 by R David Murray in branch 'default':
> #14796: improve calendar test coverage.
> http://hg.python.org/cpython/rev/98bc9e357f74

The following added test fails on Windows:

...
+def test_yeardatescalendar(self):
+def shrink(cal):
+return [[[' '.join((d.strftime('%D')
+for d in z)) for z in y] for y in x] for x in cal]
 self.assertEqual(
-cal.formatyearpage(2004, encoding=encoding).strip(b' \t\n'),
-result_2004_html.strip(' \t\n').encode(encoding)
+shrink(calendar.Calendar().yeardatescalendar(2004)),
+result_2004_dates
+)
...

The "%D" format is not supported by strftime(). Extract of timemodule.c:

#if defined(MS_WINDOWS) && !defined(HAVE_WCSFTIME)
/* check that the format string contains only valid directives */
for(outbuf = strchr(fmt, '%');
outbuf != NULL;
outbuf = strchr(outbuf+2, '%'))
{
if (outbuf[1]=='#')
++outbuf; /* not documented by python, */
if (outbuf[1]=='\0' ||
!strchr("aAbBcdHIjmMpSUwWxXyYzZ%", outbuf[1]))
{
PyErr_SetString(PyExc_ValueError, "Invalid format string");
Py_DECREF(format);
return NULL;
}
}
#endif

--
nosy: +haypo
resolution: fixed -> 
status: closed -> open

___
Python tracker 

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

[issue14961] map() and filter() methods for iterators

[Vladimir Berkutov]

New submission from Vladimir Berkutov :

It might be useful to introduce a new map() and filter() methods to iterators 
and iterables. Both methods should accept lambda/function which transforms a 
single argument into value. Both methods should return another iterator.

# proposed methods usage:
range(10).map(abs).filter(lambda x: x % 5 == 0)
# existing equivalent:
filter(lambda x: x % 5 == 0, map(abs, range(-10, 10)))
# result:
[10, 5, 0, 5]

Rough equivalent of implementation:
class iterator:
def map(self, fn):
for v in self:
yield fn(v)

def filter(self, fn):
for v in self:
if fn(v):
yield v
else:
continue

Introduction of such methods will allow to transform collections lazy without 
significant memory consumption (as was mentioned in 
http://bugs.python.org/issue912738).

--
components: Interpreter Core, Library (Lib)
messages: 161935
nosy: dair-targ
priority: normal
severity: normal
status: open
title: map() and filter() methods for iterators
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

[issue14962] When changing IDLE configuration all text in editor window loses highlighting

[Ramchandra Apte]

New submission from Ramchandra Apte :

When applying or okaying IDLE configuration (Options-> Configure IDLE) all text 
in the shell window loses highlighting.
Text in the shell window created after the configuration is applied is 
highlighted though.

--
components: IDLE
messages: 161936
nosy: ramchandra.apte
priority: normal
severity: normal
status: open
title: When changing IDLE configuration all text in editor window loses 
highlighting
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

[issue14962] When changing IDLE configuration all text in shell window loses highlighting

[Ramchandra Apte]

Changes by Ramchandra Apte :


--
title: When changing IDLE configuration all text in editor window loses 
highlighting -> When changing IDLE configuration all text in shell window loses 
highlighting

___
Python tracker 

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

[issue14961] map() and filter() methods for iterators

[Ramchandra Apte]

Ramchandra Apte  added the comment:

Sorry, small mistake.
Actually all the other Python 2.x releases are in security-fix mode.

--

___
Python tracker 

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

[issue14961] map() and filter() methods for iterators

[Ramchandra Apte]

Ramchandra Apte  added the comment:

I think this is quite a major change to Python and this needs a PEP BTW 
issue912738 and therefore this bug no longer applies to Python 3.
In Python 3 map returns an iterator.
Even if you wanted to implement this feature in Python 2, it is not possible 
because in Python 2.7 (the only Python 2 release which is not in bug-fix mode) 
only minor enhancements are allowed.
-1 for this proposal

--
nosy: +ramchandra.apte

___
Python tracker 

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

[issue14961] map() and filter() methods for iterators

[Ramchandra Apte]

Ramchandra Apte  added the comment:

Sorry,
To clarify:
Python 2.7 is in bug-fix mode which means only minor enhancements are allowed.

--

___
Python tracker 

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

[issue14961] map() and filter() methods for iterators

[Robert Lehmann]

Robert Lehmann  added the comment:

Your proposal seems two-fold: (a) make map/filter lazy and (b) have them as 
methods instead of functions.

It seems Tim borrowed Guido's time machine and already implemented (a) in 
Python 3.x, see http://docs.python.org/py3k/library/functions.html#map and 
http://docs.python.org/py3k/library/functions.html#filter.

Your second proposal-- which is better suited for python-ideas, really --is 
obstructed by iterators being merely a protocol (the next/__next__ method) 
which makes it hard to add those methods to one particular type. (This very 
discussion pops up every so often for str.join too.)

I'd recommend closing this issue.

--
nosy: +lehmannro

___
Python tracker 

___
___
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

[Ronald Oussoren]

Ronald Oussoren  added the comment:

s7v7nislands: you cannot use Xcode-select to fix this, xcode-select is used to 
switch between 2 or more installed versions of Xcode.

--
nosy: +ronaldoussoren

___
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

[Ronald Oussoren]

Ronald Oussoren  added the comment:

The issue is more annoying than the change of location of the SDK, the path to 
the compiler has also changed unless users manually install the Unix 
command-line tools, either using a button in the GUI or by installing a 
separate DMG.

There seem to be two options to thoroughly fixing this:

1) Tell users they must install the unix tools (cltools*.dmg)

   I'm not 100% sure at this time that this would work, from what I've
   learned from inspecting the installer packages this seems to imply
   "-isysroot /" (that is, no /Developer/SDKS/)

   A small change to distutils and packaging would switch distutils from
   using "-isysroot /Developer/SDKs/..." to "-isysroot /" when it 
   notices that the system root doesn't exist. This is similar to 
   existing hacks for changing a number of compiler flags on OSX 10.3
   when using the 32-bit universal build.

2) Tweak the configure script, distutils and packaging to look for the
   SDK and compiler in the new location if they cannot be found in the
   default location.

   This would be the most user-friendly as the build would "just work",
   but is more work on our end. I have a 10.8 VM with and Xcode install
   where I haven't installed the unix tools to experiment with this. 

   This is definitely more work than running configure with a
   different SDK and custom values for CC and CXX, we also have to 
   convince configure that it isn't performing a cross-build (it seems
   that some compile checks are performed before we add -isysroot to
   CFLAGS and because I don't have the unix tools installed this results
   in a compile failure early in configure)

   This option might be of limited use though: when you want to build
   an extension that uses a C library that isn't shipped with the OS
   (for example PIL with libjpeg) the build of the python extension
   would "just work", but you'd still have to manually specify the
   compiler and system root for the build of libjpeg.

--

___
Python tracker 

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

[issue14962] When changing IDLE configuration all text in shell window loses highlighting

[Ramchandra Apte]

Changes by Ramchandra Apte :


--
nosy: +kbk

___
Python tracker 

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

[issue14961] map() and filter() methods for iterators

[Nick Coghlan]

Nick Coghlan  added the comment:

As Robert noted, the map() and filter() builtins in Python 3 are already lazy 
and there's no reason to expand the iterator protocol for this functionality.

Map and filter also have dedicated syntax in the form of comprehensions and 
generator expressions:

itr = (x for x in map(abs, range(10)) if x % 5 == 0)

Furthermore, the standard library already provides an entire module of tools 
for creating and working with lazy iterators in both Python 2 and Python 3: 
http://docs.python.org/library/itertools

--
nosy: +ncoghlan
resolution:  -> 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

[issue14963] Use an iterative implementation for contextlib.ExitStack.__exit__

[Nick Coghlan]

New submission from Nick Coghlan :

The current implementation of contextlib.ExitStack [1] actually creates a 
nested series of frames when unwinding the callback stack in an effort to 
ensure exceptions are chained correctly, just as they would be if using nested 
with statements.

It would be nice to avoid this overhead by just using the one frame to iterate 
over the callbacks and handling correct exception chaining directly. This is 
likely to be a little tricky to get right, though, so the first step would be 
to set up a test that throws and suppresses a few exceptions and ensures the 
chaining when using ExitStack matches that when using nested with statements.

[1] http://hg.python.org/cpython/file/94a5bf416e50/Lib/contextlib.py#l227

--
components: Library (Lib)
messages: 161944
nosy: ncoghlan
priority: normal
severity: normal
stage: test needed
status: open
title: Use an iterative implementation for contextlib.ExitStack.__exit__
type: enhancement
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

[issue14690] Use monotonic time for sched, trace and subprocess modules

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 1345cf58738d by Victor Stinner in branch 'default':
Close #14690: Use monotonic clock instead of system clock in the sched,
http://hg.python.org/cpython/rev/1345cf58738d

--
nosy: +python-dev
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

[issue14428] Implementation of the PEP 418

[STINNER Victor]

STINNER Victor  added the comment:

> It really looks like seconds to me, definitely not jiffies ;-)

time.process_time() uses maybe "seconds" on Linux, but it doesn't include time 
elapsed during sleep. See the test:

def test_process_time(self):
start = time.process_time()
time.sleep(0.1)
stop = time.process_time()
self.assertLess(stop - start, 0.01)

According to Wikipedia: "Since 1967, the second has been defined to be: the 
duration of 9,192,631,770 periods of the radiation corresponding to the 
transition between the two hyperfine levels of the ground state of the caesium 
133 atom."

The caesium 133 atom is not sleeping while your process is sleeping, so you 
cannot say the time.process_time() uses second. Do you see what I mean?

--

___
Python tracker 

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

[issue1652] subprocess should have an option to restore SIGPIPE to default action

[Matt Joiner]

Changes by Matt Joiner :


--
nosy: +anacrolix

___
Python tracker 

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

[issue14796] Calendar module test coverage improved

[Roundup Robot]

Roundup Robot  added the comment:

New changeset d3321c010af5 by R David Murray in branch 'default':
#14796: fix failure of new calendar test on windows.
http://hg.python.org/cpython/rev/d3321c010af5

--

___
Python tracker 

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

[issue14947] Missing cross reference in types.new_class documentation

[Roundup Robot]

Roundup Robot  added the comment:

New changeset a5e621c8dd44 by Nick Coghlan in branch 'default':
Close #14947: add missing cross-reference to Language Definition from the new 
dynamic type creation functions. Also cleaned up the general wording of the docs
http://hg.python.org/cpython/rev/a5e621c8dd44

--
nosy: +python-dev
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

[issue14796] Calendar module test coverage improved

[R. David Murray]

R. David Murray  added the comment:

The buildbots seem happy.

--
status: open -> closed

___
Python tracker 

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

[issue14948] setup.cfg - rename home_page to homepage

[anatoly techtonik]

anatoly techtonik  added the comment:

1. Why not to add aliases?
2. Why not to postpone it to 3.4?
3. Why PEP change is a heavy process? Can we lighten it? (where is the 
description is PEP change process at all)

--
status: closed -> pending

___
Python tracker 

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

[issue14959] ttk.Scrollbar in Notebook widget freezes

[David Beck]

David Beck  added the comment:

After playing around with this a bit more, I've found that if the Scrollbars on 
the different tabs are not aligned (that is, they don't occupy the same EW 
position in the frame) the effect disappears. I thought that might mean that 
the last Scrollbar "persists" when you go back to earlier tabs, but the 
position of the slider in a frozen Scrollbar isn't necessarily the same as the 
position the last Scrollbar is left in (that is, after you manipulate the 
Scrollbar that causes the others to freeze, the frozen sliders are still in the 
configuration they were left in previously, so we're not just seeing a "ghost" 
of a scrollbar on another tabs).

I've posted this query to the other lists you mentioned as well.

--
status: pending -> open

___
Python tracker 

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

[issue14959] ttk.Scrollbar in Notebook widget freezes

[Ronald Oussoren]

Ronald Oussoren  added the comment:

I agree with Ned that this is a bug in Tk, especially because the problem goes 
away with small changes to the layout of the UI.

--
status: open -> pending

___
Python tracker 

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

[issue6721] Locks in python standard library should be sanitized on fork

[Richard Oudkerk]

Richard Oudkerk  added the comment:

> > Is there any particular reason not to merge Charles-François's 
> > reinit_locks.diff?
> > 
> > Reinitialising all locks to unlocked after a fork seems the only sane 
> > option.
>
> I agree with this. 
> I haven't looked at the patch very closely. I think perhaps each lock
> could have an optional callback for specific code to be run after
> forking, but that may come in another patch.
> (this would allow to make e.g. the C RLock fork-safe)

An alternative way of handling RLock.acquire() would be to always start by 
trying a non-blocking acquire while holding the GIL: if this succeeds and 
self->rlock_count != 0 then we can assume that the lock was cleared by 
PyThread_ReinitLocks().

--

___
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

[Ned Deily]

Ned Deily  added the comment:

I've been working on this and it does need to be thoroughly fixed.  There are 
two different aspects to it: (1) being able to build Python using any of the 
supported development environment options; and (2) support in Distutils and 
packaging to build extension modules for any of the supported development 
options.  With the release of the Command Line Tools for 10.7 and beyond (and 
with the dangling mess of 10.6 with both Xcode 3.2.6 and Xcode 4.2 
installations out there), we need to be able to support multiple options for 
users and builders of universal builds.  Apple does supply tools to deal with 
development environments installed in arbitrary locations (primarily, 
xcode-select and xcrun) but there are some gaps in them for supporting 
command-line-based builds, like a convenient way to find the absolute path to 
the SDK.  I'm working on patches for all of this right now.  I'm hopeful we 
will end up with a major increase in usability to users of universal builds.

--

___
Python tracker 

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

[issue14948] setup.cfg - rename home_page to homepage

[Éric Araujo]

Éric Araujo  added the comment:

I don’t believe aliases would help, on the contrary.  There already are a good 
number of fields to remember.  Anyway I expect people to use “pysetup create” 
or copy-pasting, so the spelling is not important: nobody will really have to 
remember it.  I have no personal opinion on “home page” vs. “homepage”, so I 
just accept what the PEP decided.

Postponing to 3.4 has no value.  The reasons for rejecting this will still 
apply.  Please keep this closed.

See PEP 1 for the PEP process.  See the month-long discussions on distutils-sig 
and python-dev two years ago on the packaging PEPs to see how long it can be.

--
status: pending -> closed

___
Python tracker 

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

[issue14956] custom PYTHONPATH may break apps embedding Python

[Éric Araujo]

Éric Araujo  added the comment:

> I fully agree with site.py/os.py/spam.py but I find it offtopic for this 
> Issue.

I don’t understand this message :)  There is nothing to agree with or judge on 
or off-topic; I was trying to understand the root of the bug and really asking 
you in good faith to try two things to see if my idea was right.

--

___
Python tracker 

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

[issue14956] custom PYTHONPATH may break apps embedding Python

[Jan Kratochvil]

Jan Kratochvil  added the comment:

While it should be documented this is not only a docs issue.  It should be 
solved in some way during runtime.

--

___
Python tracker 

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

[issue14938] 'import my_pkg.__init__' creates duplicate modules

[Brett Cannon]

Brett Cannon  added the comment:

If you directly import __init__ then it would just be a module within the 
package (the "magic" of packages should stay with the implicit interpretation 
of __init__).

--

___
Python tracker 

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

[issue14956] custom PYTHONPATH may break apps embedding Python

[R. David Murray]

R. David Murray  added the comment:

No it shouldn't.  As mentioned in the Fedora thread you linked, this is no 
different than the user setting LD_LIBRARY_PATH to something that screws up a 
system installed program.

--

___
Python tracker 

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

[issue14673] add sys.implementation

[Barry A. Warsaw]

Barry A. Warsaw  added the comment:

One small test that I think is missing is a test that 
sys.implementation.version and sys.implementation.hexversion are equal (modulo 
format differences).

--

___
Python tracker 

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

[issue14007] xml.etree.ElementTree - XMLParser and TreeBuilder's doctype() method missing

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 20b8f0ee3d64 by Eli Bendersky in branch 'default':
Issue #14007: implemented the 'element_factory' feature of TreeBuilder in
http://hg.python.org/cpython/rev/20b8f0ee3d64

--

___
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

[Ronald Oussoren]

Ronald Oussoren  added the comment:

What I'd prefer to look for the compiler:

* in distutils: if $CC is an absolute path and exists, use that

* look for clang on $PATH,  use it if found
   (default configure looks for GCC in preference of other compilers,
but with Apple's toolchain it is better to use clang)

* look for gcc on $PATH, use it if found
   (needed to use the Fink compiler when Fink is on $PATH, alternative
for 3.3 is to document that configure will try to pick and Apple
compiler)

* use $(xcodebuild -find clang)

To look for the SDK:

* in distutils: if -isysroot is set, is not '/' and exists, use that

* in distutils: extract SDK version from -isysroot string (if set),
  then use $(xcode-select) to find the root of the installation and
  construct a path relative to that. If the requested SDK version exists,
  use that

* if osx release < 10.5 and building universal: 

  - use /Developer/SDKs/MacOSX10.4u.sdk
(needed for universal builds on early releases of OSX 10.4)

* if /usr/include/stdint.h exists: use -isysroot /
  (older Xcode, or Xcode >=4.3 with Command Line Tools installed)

* use $(xcodebuild -showsdks) to find list of SDKs and use most recent
  one.


I haven't tried to capture this in code yet, and haven't tested the procedure 
on earlier releases (or even a 10.7 system with Xcode 4.3 without unix tools), 
but this should work.

--

___
Python tracker 

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

[issue14673] add sys.implementation

[Barry A. Warsaw]

Barry A. Warsaw  added the comment:

I'm not a fan of using a module, and less of a fan of structseq, so I think 
I'll discount those two.  I'll play with namespace and type next.

--

___
Python tracker 

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

[issue14962] When changing IDLE configuration all text in shell window loses highlighting

[Roger Serwy]

Changes by Roger Serwy :


--
nosy: +serwy

___
Python tracker 

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

[issue14938] 'import my_pkg.__init__' creates duplicate modules

[Ronan Lamy]

Ronan Lamy  added the comment:

Reverting to the previous behaviour, then? OK.

As I understand it, the issue comes from a DRY violation: both 
FileFinder.find_loader() and _LoaderBasics.is_package() have their own notion 
of what is a package and they disagree. Since the finder needs to know what is 
a package, I think that the loader should be told whether it's a package or not 
instead of trying to guess.

--

___
Python tracker 

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

[issue14673] add sys.implementation

[Barry A. Warsaw]

Barry A. Warsaw  added the comment:

I'm inclined to go with the as_simple_namespace patch.  As you say, the pro are 
that this is a much better fit for this use case, while the con is that this 
does kind of sneak in a new type.  Given that the type is not exposed in the 
API, that doesn't bother me.  One other possibility would be to move all that 
code to sysmodule.c as static functions, and then it definitely won't be 
available outside sys.  

OTOH, I do think this could eventually be a useful type to expose, however the 
current behavior of its repr filtering out _names would have to be removed in 
that case.  However, that's a useful filter for sys.implementation and it 
doesn't bother me, since you can always repr sys.implementation.__dict__ to get 
the whole thing.

On balance, my recommendation would be to keep it the way you have it, but 
perhaps mention this on python-dev, and watch the technicolor bikeshed go 
psychedelic.

A few other comments as we discussed in irc:

dir(sys.implementation) should return something useful, not traceback

There are a few PEP 7 violations, e.g. brace placements that should be fixed

I was looking at _namespace_init() and a few things bothered me.  I thought 
this might be superfluous and that you'd be able to just inline the 
PyDict_Update() calls, but now I'm not so sure.  AFAICT, Python's documentation 
is silent on whether *args and *kwds in a tp_init function can be NULL or not, 
and I definitely see cases where similar checks are made in other types.  So I 
think with that in mind, you must assume they *can* be NULL.  But then I'm not 
sure the assertions are useful or correct.  Take this scenario:

namespace_init() gets args==NULL.  Your assertion doesn't trigger, but 
PyObject_Size(NULL) sets an exception and returns -1.  Your conditional doesn't 
check for an error condition in PyObject_Size() so you'll incorrectly swallow 
(temporarily) that exception.  At the very least, you need to check for 
PyObject_Size() < 0.  Don't forget too that those assertions can get compiled 
away.

I think I'd rather see a PyTuple_Size(args) conditional here for the args 
parameter.  If it's not a tuple, you'll get an exception set, so check for size 
< 0.  If size > 0, then you can set the TypeError and return -1 explicitly.

Similarly, just call PyDict_Update(kwds) and return its value.  If kwds is 
neither a dict nor has a .keys() method (including if its NULL), an exception 
will be set so everything should work correctly (see _PyObject_CallMethodId() 
in abstract.c, which is what PyDict_Update() boils down to).

At least, I'm nearly certain that's safe :)

Moving on...

namespace_repr() also has some PEP 7 violations (brace position, extra blank 
lines).  Please fix these.

Is it ever possible to get into namespace_repr() with ns->ns_dict being NULL?  
I think it's impossible.  You might rewrite the if (d == NULL) check with an 
assertion.

I think you're leaking the PyList_New(0) that you put in `pairs` after you 
PyUnicode_Join() it.  PyUnicode_Join() doesn't decref its second argument and 
your losing the original referenced object when you assign `pairs` to its 
result.

I find the mix of inline error returns and `goto error` handling in 
namespace_repr() somewhat confusing.  I wonder if it would be more readable 
(and thus auditable) if there was consistent use of `goto error` with more 
XDECREFs?  If you feel like it, please try that out.

That's it for now.  Please submit another patch for the as_simple_namespace 
case and I'll take another look.  Also, if you send a message to python-dev 
about the introduction of the namespace object, I'll follow up with my support 
of that option.

Thanks, this is looking great!

--

___
Python tracker 

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

[issue10053] Don’t close fd when FileIO.__init__ fails

[STINNER Victor]

Changes by STINNER Victor :


--
nosy: +haypo

___
Python tracker 

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

[issue14955] hmac.secure_compare() is not time-independent for unicode strings

[STINNER Victor]

STINNER Victor  added the comment:

I'm not sure that encoding to UTF-8 is time indenpendant. You may try UTF-32-LE 
or unicode-internal?

--
nosy: +haypo

___
Python tracker 

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

[issue14952] Cannot run regrtest with amd64/debug on windows

[Georg Brandl]

Georg Brandl  added the comment:

This should block beta1.

--
nosy: +georg.brandl
priority: normal -> release blocker

___
Python tracker 

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

[issue14909] Fix incorrect use of *Realloc() and *Resize()

[STINNER Victor]

Changes by STINNER Victor :


--
nosy: +haypo

___
Python tracker 

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

[issue14810] tarfile does not support timestamp older 1970-01-01

[STINNER Victor]

Changes by STINNER Victor :


--
title: Bug in tarfile -> tarfile does not support timestamp older 1970-01-01

___
Python tracker 

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

[issue14909] Fix incorrect use of *Realloc() and *Resize()

[Kristján Valur Jónsson]

Kristján Valur Jónsson  added the comment:

Since this is a trivial patch I'm going to go ahead and apply it.  I was just 
waiting for the ability to run the full test suite in 64 bits, but that is 
currently broken due to some other issues.

--

___
Python tracker 

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

[issue14673] add sys.implementation

[Nick Coghlan]

Nick Coghlan  added the comment:

History with dictproxy means I'm also OK with "new type by stealth".
Perhaps add some tests to check "type(sys.implementation)()" does something
sane?

--

___
Python tracker 

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

[issue14956] custom PYTHONPATH may break apps embedding Python

[Nick Coghlan]

Nick Coghlan  added the comment:

If we don't expose the mechanism behind -E to embedding applications via
the C API, then a non-docs change may be needed. However, writing (or at
least trying to write) the relevant docs is a good way to check whether or
not that is the case.

--

___
Python tracker 

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

[issue14904] test_unicode_repr_oflw (in test_bigmem) crashes

[STINNER Victor]

Changes by STINNER Victor :


--
nosy: +haypo

___
Python tracker 

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

[issue14942] add PyType_New()

[Barry A. Warsaw]

Changes by Barry A. Warsaw :


--
nosy: +barry

___
Python tracker 

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

[issue3871] cross and native build of python for mingw32 with packaging

[Ray Donnelly]

Changes by Ray Donnelly :


Added file: 
http://bugs.python.org/file25761/python-py3k-20120318-MINGW-330a2.patch

___
Python tracker 

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

[issue3754] cross-compilation support for python build

[Ray Donnelly]

Changes by Ray Donnelly :


Added file: 
http://bugs.python.org/file25762/python-py3k-20120318-CROSS-330a2.patch

___
Python tracker 

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

[issue14963] Use an iterative implementation for contextlib.ExitStack.__exit__

[alon horev]

alon horev  added the comment:

The iterative approach turned out elegant and concise.
It actually now resembeles the implementation of nested's __exit__.

--
keywords: +patch
nosy: +alonho
Added file: http://bugs.python.org/file25763/14963.patch

___
Python tracker 

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

[issue3754] cross-compilation support for python build

[Ray Donnelly]

Ray Donnelly  added the comment:

Hi Roumen,

Many thanks for your patches, I've been using a 2.7.1 version of your patches 
for Python integration with GDB (pretty-printing) of my own version of the 
Android NDK for ages now (part of the Necessitas Qt project) and I really 
appreciate your efforts in this area. I've recently started looking into cross 
compilation of Python as I want to build everything on Linux and hopefully I 
can be useful in this effort.

What you said about wchar_t on Android is true on API level <= 8, but fixed for 
>8. See:

https://groups.google.com/group/android-ndk/browse_thread/thread/e40e3fd241e72d3f?pli=1

To test this:

test.c:
#include 
char bytes[(signed)sizeof(wchar_t)-4];

compile failure:
arm-linux-androideabi-gcc -I$NDK/platforms/android-8/arch-arm/usr/include/ -S 
test.c
test.c:2: error: size of array 'bytes' is negative

compile success:
arm-linux-androideabi-gcc -I$NDK/platforms/android-9/arch-arm/usr/include/ -S 
test.c

I've attached a version of your latest patch re-made against released 3.3.0a2. 
I've also done the same thing for your MinGW patch at 
http://bugs.python.org/issue3871

I'll follow up shortly with a patch that addresses some of the remaining issues 
with cross building for MinGW on Linux (and also the beginnings of Darwin on 
Linux). It'll be attached to http://bugs.python.org/issue3871 though as it's 
more specific to MinGW than general cross.

--
nosy: +Ray.Donnelly

___
Python tracker 

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

[issue3871] cross and native build of python for mingw32 with packaging

[Ray Donnelly]

Changes by Ray Donnelly :


Added file: 
http://bugs.python.org/file25764/python-py3k-20120318-MINGW-330a2.patch

___
Python tracker 

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

[issue3871] cross and native build of python for mingw32 with packaging

[Ray Donnelly]

Changes by Ray Donnelly :


Removed file: 
http://bugs.python.org/file25764/python-py3k-20120318-MINGW-330a2.patch

___
Python tracker 

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

[issue3871] cross and native build of python for mingw32 with packaging

[Ray Donnelly]

Ray Donnelly  added the comment:

Although mainly focussed on MinGW, I've begun adding Darwin cross support. I've 
also built Darwin cross compilers. The latest Linux version can be found at:

http://mingw-and-ndk.googlecode.com/files/multiarch-darwin11-cctools127.2-gcc42-5666.3-llvmgcc42-2336.1-Linux-120531.tar.xz

Here's a run-down of what's in the patch:

configure.ac:
 Set MACHDEP=darwin when using darwin-cross compilers.
 Set DELIM to ; for MACHDEP=win.
 Switch from PC/getpathp.c to Modules/getpath.c for MinGW build.
  This gives us a posix like layout as needed by autotools projects
  such as GDB.
 Add MSYSVPATH as an env. var to configure (used in getpath.c):
  MSYS make uses a 'virtual' VPATH, but getpath.c uses
  GetModuleFileNameW (replacing \ with /). This allows the user to
  define the 'actual 'real' value. Note, it should contain / not \,
  (i.e. use ecactly what is printed by "pwd -W")
 Fixes to build with MinGW64 for REPARSE_DATA_BUFFER (needs defining)

Include/fileutils.h:
 Define Py_wstat for MinGW/MinGW64.

Include/osdefs.h:
 Define SEP to / and ALTSEP to \ for MinGW.

cygwinccompiler.py:
 Fix RE_VERSION in for handling MinGW64 compiler versioning.
 Ask gcc where ld is instead of requiring it to be passed in os.environ
 
plat-generic/regen:
 Allow passing in the CC so sysroots can be determined from -print-search-dirs
 If this CC passing is detected, use $CCINSTALL/include/stddef.h as 
netinet/in.h doesn't come with MinGW.

Moules/faulthandler.c:
 Avoid _set_abort_behavior on MinGW64 as it's broken.

Modules/getpath.c:
 Add support for MinGW.

Modules/socketmodule.c:
 Change case (to lower) of #include  for MinGW/MinGW64 cross.

Parser/metagrammar.c:
 Rename _PyParser_Grammar to _PyParser_MetaGrammar to avoid multiply defined 
symbols.

Python/pythonrun.c:
 Translate ALTSEP (\) to SEP (/) in Py_SetProgramName

setup.py:
 Add 'msi','cabinet','rpcrt4' as libs to link against for _msi module.
 Fix an error with self.get_platform() no longer being defined (changed to 
host_platform)

Best regards,

Ray Donnelly.

--
nosy: +Ray.Donnelly
Added file: 
http://bugs.python.org/file25765/python-py3k-20120318-MINGW-FIXES-USE-POSIX-GETPATH-330a2.patch

___
Python tracker 

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

[issue14964] distutils2.utils.resolve_name cleanup

[Ronny Pfannschmidt]

New submission from Ronny Pfannschmidt :

this patch simplifies and cleans up the resolve_name function

--
assignee: eric.araujo
components: Distutils2
files: resolve_name.patch
keywords: patch
messages: 161974
nosy: Ronny.Pfannschmidt, alexis, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: distutils2.utils.resolve_name cleanup
type: enhancement
Added file: http://bugs.python.org/file25766/resolve_name.patch

___
Python tracker 

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

[issue14964] distutils2.utils.resolve_name cleanup

[Éric Araujo]

Éric Araujo  added the comment:

Thanks!  I would love to get your review on #12703 (not sure if this bug is a 
duplicate or an unrelated cleanup).

--
stage:  -> patch review
versions: +3rd party, Python 3.3

___
Python tracker 

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

[issue3871] cross and native build of python for mingw32 with packaging

[Éric Araujo]

Éric Araujo  added the comment:

Thanks for your work Ray, but as your patch adds a feature to distutils it 
cannot be accepted.

--

___
Python tracker 

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

[issue3871] cross and native build of python for mingw32 with packaging

[Ray Donnelly]

Ray Donnelly  added the comment:

Hi Éric,

Do you mean this bit?:

diff -urN a/Lib/distutils/cygwinccompiler.py b/Lib/distutils/cygwinccompiler.py
--- a/Lib/distutils/cygwinccompiler.py  2012-05-30 07:33:00.234438631 +0100
+++ b/Lib/distutils/cygwinccompiler.py  2012-05-30 07:33:03.320855811 +0100
@@ -392,7 +392,7 @@
 return (CONFIG_H_UNCERTAIN,
 "couldn't read '%s': %s" % (fn, exc.strerror))
 
-RE_VERSION = re.compile(b'(\d+\.\d+(\.\d+)*)')
+RE_VERSION = re.compile(b'[\D\s]*(\d+\.\d+(\.\d+)*)[\D\s]*$')

It's hardly touching distutils and only the cygwinccompiler.py part (which I 
doubt is used very much anyway). It there not some extensive testsuite we can 
run patches against that would allow distutils changes?

I guess the very limited amount of changes I've made to distutils is academic 
though as it depends on two patches from Roumen Petrov which touch distutils a 
lot more.

I thought that the distutils-is-frozen rule was only for Python 2.x and that 
they would be allowed for 3.x? Is this not true?

Obviously making Python cross compile properly is a very desired feature (in 
this day and age I'd say cross-compilation for any major software is expected 
to be honest with you). How can we progress this task in a way that is 
acceptable? Please advise.

Best regards,

Ray.

--

___
Python tracker 

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

[issue14963] Use an iterative implementation for contextlib.ExitStack.__exit__

[Nick Coghlan]

Nick Coghlan  added the comment:

Sorry, I wasn't clear on what I meant by "chained correctly", and that's the 
part that makes this trickier than the way contextlib.nested did it. I'm 
referring to the __context__ attribute on exceptions that is set automatically 
when an exception occurs in another exception handler, which makes error 
displays like the following possible:

>>> from contextlib import ExitStack
>>> with ExitStack() as stack:
... @stack.callback
... def f():
... 1/0
... @stack.callback
... def f():
... {}[1]
... 
Traceback (most recent call last):
  File "/home/ncoghlan/devel/py3k/Lib/contextlib.py", line 243, in 
_invoke_next_callback
suppress_exc = _invoke_next_callback(exc_details)
  File "/home/ncoghlan/devel/py3k/Lib/contextlib.py", line 240, in 
_invoke_next_callback
return cb(*exc_details)
  File "/home/ncoghlan/devel/py3k/Lib/contextlib.py", line 200, in _exit_wrapper
callback(*args, **kwds)
  File "", line 7, in f
KeyError: 1

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "", line 5, in 
  File "/home/ncoghlan/devel/py3k/Lib/contextlib.py", line 256, in __exit__
return _invoke_next_callback(exc_details)
  File "/home/ncoghlan/devel/py3k/Lib/contextlib.py", line 245, in 
_invoke_next_callback
suppress_exc = cb(*sys.exc_info())
  File "/home/ncoghlan/devel/py3k/Lib/contextlib.py", line 200, in _exit_wrapper
callback(*args, **kwds)
  File "", line 4, in f
ZeroDivisionError: division by zero


The recursive approach maintains that behaviour automatically because it really 
does create a nested set of exception handlers. With the iterative approach, we 
leave the exception handler before invoking the next callback, so we end up 
bypassing the native chaining machinery and will need to recreate it manually.

If you can make that work, then we'd end up with the best of both worlds: the 
individual exceptions would be clean (since they wouldn't be cluttered with the 
recursive call stack created by the unwinding process), but exception chaining 
would still keep track of things if multiple exceptions are encountered in 
cleanup operations.

--

___
Python tracker 

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

[issue7897] Support parametrized tests in unittest

[R. David Murray]

R. David Murray  added the comment:

People interested in this issue might be interested in changeset e6a33938b03f.  
I use parameterized unit tests in email a lot, and was annoyed by the fact that 
I couldn't run the tests individually using the unittest CLI.  The fix for that 
turned out to be trivial, but by the time I figured it out, I'd already written 
most of the metaclass.  So since the metaclass reduces the boilerplate (albeit 
at the cost of looking like black magic), I decided to go with it.  And the 
metaclass at least avoids the rather questionable use of the "modify locals()" 
hack I was using before.

--

___
Python tracker 

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

[issue14965] super() and property inheritance behavior

[猫 黒]

New submission from 猫 黒 :

super() objects allow access to inherited properties fget() but not fset() or 
fdel(), resulting in unexpected behavior.

Today on pydev thread 'Property inheritance in Python' GvR said "I
don't see the need for a Python-Ideas detour. It seems worth fixing"

>>> class BaseProp(object):
... @property
... def p(self):
... return self._p
... @p.setter
... def p(self, value):
... self._p = value
>>> class DerivedProp(BaseProp):
... @property
... def p(self):
... return super(DerivedProp, self).p * 2
... @p.setter
... def p(self, value):
... super(DerivedProp, self).p = value / 2
>>> d = DerivedProp()
>>> d._p = 21
>>> d.p
42
>>> d.p = 50
Traceback (most recent call last):
   ...
AttributeError: 'super' object has no attribute 'p'

--
components: Library (Lib)
messages: 161980
nosy: 猫.黒
priority: normal
severity: normal
status: open
title: super() and property inheritance behavior
type: behavior
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

[issue14965] super() and property inheritance behavior

[Alex Gaynor]

Changes by Alex Gaynor :


--
nosy: +alex

___
Python tracker 

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

[issue14673] add sys.implementation

[Eric Snow]

Eric Snow  added the comment:

Thanks for taking the time for the review, Barry.  Again, sorry I broke the 
review link.  It shouldn't be a problem any more.

> Barry A. Warsaw  added the comment:
>
> I'm inclined to go with the as_simple_namespace patch.  As you say,
> the pro are that this is a much better fit for this use case, while
> the con is that this does kind of sneak in a new type.  Given that
> the type is not exposed in the API, that doesn't bother me.  One
> other possibility would be to move all that code to sysmodule.c as
> static functions, and then it definitely won't be available outside
> sys.
>
> OTOH, I do think this could eventually be a useful type to expose,
> however the current behavior of its repr filtering out _names would
> have to be removed in that case.  However, that's a useful filter for
> sys.implementation and it doesn't bother me, since you can always
> repr sys.implementation.__dict__ to get the whole thing.
>
> On balance, my recommendation would be to keep it the way you have
> it, but perhaps mention this on python-dev, and watch the technicolor
> bikeshed go psychedelic.

:)  I'll bring it up on python-dev.

>
> A few other comments as we discussed in irc:
>
> dir(sys.implementation) should return something useful, not traceback

Not sure what I was doing to block the lookup from object, but it's working now.

So...Fixed.

>
> There are a few PEP 7 violations, e.g. brace placements that should
> be fixed

Done.

>
> I was looking at _namespace_init() and a few things bothered me.  I
> thought this might be superfluous and that you'd be able to just
> inline the PyDict_Update() calls, but now I'm not so sure.  AFAICT,
> Python's documentation is silent on whether *args and *kwds in a
> tp_init function can be NULL or not, and I definitely see cases where
> similar checks are made in other types.  So I think with that in
> mind, you must assume they *can* be NULL.  But then I'm not sure the
> assertions are useful or correct.

Yeah, they're mostly an artifact of copying code.  However, I'm glad they 
triggered your explanation. ;)

> Take this scenario:
>
> namespace_init() gets args==NULL.  Your assertion doesn't trigger,
> but PyObject_Size(NULL) sets an exception and returns -1.  Your
> conditional doesn't check for an error condition in PyObject_Size()
> so you'll incorrectly swallow (temporarily) that exception.  At the
> very least, you need to check for PyObject_Size() < 0.  Don't forget
> too that those assertions can get compiled away.
>
> I think I'd rather see a PyTuple_Size(args) conditional here for the
> args parameter.  If it's not a tuple, you'll get an exception set, so
> check for size < 0.  If size > 0, then you can set the TypeError and
> return -1 explicitly.

Pretty sure I understand.  Let me know if my new patch says otherwise.  

So...Done.

>
> Similarly, just call PyDict_Update(kwds) and return its value.  If
> kwds is neither a dict nor has a .keys() method (including if its
> NULL), an exception will be set so everything should work correctly
> (see _PyObject_CallMethodId() in abstract.c, which is what
> PyDict_Update() boils down to).

Done.  This was a case of prematurely optimizing.

>
> At least, I'm nearly certain that's safe :)
>
> Moving on...
>
> namespace_repr() also has some PEP 7 violations (brace position,
> extra blank lines).  Please fix these.

Done.

>
> Is it ever possible to get into namespace_repr() with ns->ns_dict
> being NULL?  I think it's impossible.  You might rewrite the if
> (d == NULL) check with an assertion.

Done.

>
> I think you're leaking the PyList_New(0) that you put in `pairs`
> after you PyUnicode_Join() it.  PyUnicode_Join() doesn't decref its
> second argument and your losing the original referenced object when
> you assign `pairs` to its result.

Good Catch.  Fixed.

>
> I find the mix of inline error returns and `goto error` handling in
> namespace_repr() somewhat confusing.  I wonder if it would be more
> readable (and thus auditable) if there was consistent use of `goto
> error` with more XDECREFs?  If you feel like it, please try that out.

I've given it a go.  :)

>
> That's it for now.  Please submit another patch for the
> as_simple_namespace case and I'll take another look.  Also, if you
> send a message to python-dev about the introduction of the namespace
> object, I'll follow up with my support of that option.
>
> Thanks, this is looking great!

Thanks again for all your support through this process!

--
Added file: 
http://bugs.python.org/file25767/issue14673_as_simple_namespace_2.diff

___
Python tracker 

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

[issue14673] add sys.implementation

[Eric Snow]

Changes by Eric Snow :


Added file: http://bugs.python.org/file25768/issue14673_docs_and_tests_2.diff

___
Python tracker 

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

[issue14673] add sys.implementation

[Eric Snow]

Eric Snow  added the comment:

> History with dictproxy means I'm also OK with "new type by stealth".
> Perhaps add some tests to check "type(sys.implementation)()" does
> something sane?

Test added.  Here's what happens:

  >>> cls = type(sys.implementation)
  >>> cls()
  namespace()
  >>> cls(x=1, y=2)
  namespace(x=1, y=2)

Though it's not immediately a problem, "vars(cls(x=1, y=2))" returns "{}", 
while "ns=cls(x=1, y=2); vars(ns)" returns "{'x': 1, 'y': 2}"!

Certainly it's a corner case, but it could indicate a more sinister problem.  
Regardless, I'll track down the root cause and fix it.  As far as I can tell, 
this odd behavior does not impact sys.implementation.

--

___
Python tracker 

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

[issue14673] add sys.implementation

[Eric Snow]

Eric Snow  added the comment:

@Barry: FWIW, the kwds passed to namespace_init was NULL when no keyword 
arguments were used.  Easy enough to handle though.

--

___
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

[Nick Coghlan]

New submission from Nick Coghlan :

CalledProcessError provides a nice encapsulation for a returncode, the original 
command and any partial output. The API should be officially documented so that 
third party subprocess.Popen convenience wrappers can use it easily.

--
assignee: docs@python
components: Documentation
keywords: easy
messages: 161984
nosy: docs@python, ncoghlan
priority: normal
severity: normal
status: open
title: Fully document subprocess.CalledProcessError
type: enhancement
versions: Python 2.7, 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