[issue15533] subprocess.Popen(cwd) documentation

[Chris Jerdonek]

New submission from Chris Jerdonek:

The sentence describing Popen()'s cwd argument in the subprocess documentation 
seems reversed to me:

http://docs.python.org/dev/library/subprocess.html#subprocess.Popen

It says, "If cwd is not None, the child’s current directory will be changed to 
cwd before it is executed. Note that this directory is not considered when 
searching the executable, so you can’t specify the program’s path relative to 
cwd."

However, when cwd is not None, it seems like you *must* specify the program's 
path relative to cwd.  For example, when running a script containing the 
following using `./python.exe` from a source checkout--

p = Popen(['./python.exe', '-V'], stdout=PIPE, stderr=PIPE, cwd='temp')

you get an: "OSError: [Errno 2] No such file or directory."

In contrast, when you *do* specify the program's path relative to cwd, it 
works--

p = Popen(['../python.exe', '-V'], stdout=PIPE, stderr=PIPE, cwd='temp')

Issue 6374 seems to have made the same point in its second bullet, but the 
issue was closed without addressing that part of it.

--
assignee: docs@python
components: Documentation
keywords: easy
messages: 167194
nosy: cjerdonek, docs@python
priority: normal
severity: normal
status: open
title: subprocess.Popen(cwd) documentation
versions: Python 2.7, Python 3.3

___
Python tracker 

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

[issue13119] Newline for print() is \n on Windows, and not \r\n as expected

[Atsuo Ishimoto]

Atsuo Ishimoto added the comment:

Test for this issue. Tested on Windows7, Ubuntu linux 12.04.

I wonder why "print(1, file=sys.stderr)" returns '1' instead of '1\n'.

But in Python2.7, "print >>sys.stderr, 1" also returns '1', 
so this might not be a problem.

--
Added file: http://bugs.python.org/file26660/issue13119_test.patch

___
Python tracker 

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

[issue15502] Meta path finders and path entry finders are different, but share an ABC

[Eric Snow]

Eric Snow added the comment:

didn't mean to yank that one.

--
Added file: 
http://bugs.python.org/file26659/issue15502_windows_registry_finder.diff

___
Python tracker 

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

[issue15502] Meta path finders and path entry finders are different, but share an ABC

[Eric Snow]

Changes by Eric Snow :


Removed file: 
http://bugs.python.org/file26655/issue15502_windows_registry_finder.diff

___
Python tracker 

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

[issue7443] test.support.unlink issue on Windows platform

[Nick Coghlan]

Nick Coghlan added the comment:

See #15496 for an alternative approach to solving this problem, at least in the 
test suite - as noted in that issue, the rename dance isn't sufficient when the 
problem gets triggered by a different sequence like:

unlink(file_in_parent_dir)
unlink(parent_dir)  # This fails if file is still locked

--

___
Python tracker 

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

[issue15502] Meta path finders and path entry finders are different, but share an ABC

[Eric Snow]

Changes by Eric Snow :


Removed file: http://bugs.python.org/file26656/issue15502_new_abc.diff

___
Python tracker 

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

[issue15502] Meta path finders and path entry finders are different, but share an ABC

[Eric Snow]

Changes by Eric Snow :


Added file: http://bugs.python.org/file26658/issue15502_new_abc.diff

___
Python tracker 

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

[issue15502] Meta path finders and path entry finders are different, but share an ABC

[Eric Snow]

Eric Snow added the comment:

While ungainly a name change, this patch at least demonstrates the places that 
the name would have to change.

--
Added file: 
http://bugs.python.org/file26657/issue15502_file_path_entry_finder_of_doom.diff

___
Python tracker 

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

[issue15532] "for line in file" is *still* broken in Python 2.7 on pipes

[Ned Deily]

Ned Deily added the comment:

Notice in the reply to Issue3907, "with 2.6, you have to use io.open() 
explicitly".  This is still true in Python 2.7, i.e. the new 3.x-compatible io 
library is not used by default in Python 2.  If you want to use it with 
subprocess.Popen, one way is to supply a pipe with an io wrapper, perhaps 
something like:

import io, os
i, o = os.pipe()
piperead = io.open(i,'rb',buffering=0)
p = subprocess.Popen(..., stdout=o)

See Chapter 15 of the Python 2.7 Standard Library doc for more information on 
the io module: http://docs.python.org/library/io.html

--
nosy: +ned.deily
resolution:  -> works for me
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

[issue15496] harden directory removal for tests on Windows

[Nick Coghlan]

Changes by Nick Coghlan :


--
nosy: +ncoghlan

___
Python tracker 

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

[issue15502] Meta path finders and path entry finders are different, but share an ABC

[Eric Snow]

Changes by Eric Snow :


Added file: http://bugs.python.org/file26656/issue15502_new_abc.diff

___
Python tracker 

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

[issue15502] Meta path finders and path entry finders are different, but share an ABC

[Eric Snow]

Changes by Eric Snow :


Removed file: http://bugs.python.org/file26654/issue15502_new_abc.diff

___
Python tracker 

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

[issue15502] Meta path finders and path entry finders are different, but share an ABC

[Eric Snow]

Changes by Eric Snow :


Added file: 
http://bugs.python.org/file26655/issue15502_windows_registry_finder.diff

___
Python tracker 

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

[issue15502] Meta path finders and path entry finders are different, but share an ABC

[Eric Snow]

Changes by Eric Snow :


Removed file: http://bugs.python.org/file26653/issue15502_new_abc.diff

___
Python tracker 

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

[issue15502] Meta path finders and path entry finders are different, but share an ABC

[Eric Snow]

Eric Snow added the comment:

Okay, while the dust clears, I am going to separate the two parts into 
different patches.  :)

--
Added file: http://bugs.python.org/file26654/issue15502_new_abc.diff

___
Python tracker 

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

[issue15502] Meta path finders and path entry finders are different, but share an ABC

[Nick Coghlan]

Nick Coghlan added the comment:

As far as "path import finder" goes, it's no more wrong than "meta path finder" 
and "path entry finder". A "meta path finder" is a finder that gets installed 
on sys.meta_path, a "path entry finder" is one that finds loaders based on a 
specific path entry, and the "path import finders" finds loaders based on the 
full path import machinery (sys.path, __path__ attributes, sys.path_hooks, sys.
path_importer_cache").

As far as FileFinder goes, FilePathEntryFinder is an awful name. If we change 
the name at all (which I don't consider necessary, since FileFinder is just 
fine as a name for a finder that finds loaders for files), then more 
appropriate names would be FilesystemFinder or DirectoryFinder. I like the 
simplicity of FileFinder though and am -1 on changing it.

I'm far more comfortable with the idea of explaining that the qualifiers on the 
"finder" and "importer" terms may convey information regarding one or more of 
the kind of loaders being found (FileFinder, BuiltinImporter, FrozenImporter, 
zipimporter), the information sources that are being searched (BuiltinImporter, 
FrozenImporter, zipimporter, PathEntryFinder, PathImportFinder), or how the 
finders are themselves retrieved (PathEntryFinder, MetaPathFinder) than I am 
with trying to redefine the decade old unambiguous meaning of the "importer" 
term as something which is both a finder and a loader.

--

___
Python tracker 

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

[issue7443] test.support.unlink issue on Windows platform

[Chris Jerdonek]

Changes by Chris Jerdonek :


--
nosy: +cjerdonek

___
Python tracker 

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

[issue15496] harden directory removal for tests on Windows

[Chris Jerdonek]

Changes by Chris Jerdonek :


--
nosy: +cjerdonek

___
Python tracker 

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

[issue15526] regrtest crash on Windows 7 AMD64

[Chris Jerdonek]

Changes by Chris Jerdonek :


--
nosy: +cjerdonek

___
Python tracker 

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

[issue15502] Meta path finders and path entry finders are different, but share an ABC

[Eric Snow]

Eric Snow added the comment:

Regarding deprecating importlib.abc.Finder, I'll add a DeprecationWarning to 
the patch later.

--

___
Python tracker 

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

[issue15502] Meta path finders and path entry finders are different, but share an ABC

[Eric Snow]

Changes by Eric Snow :


Removed file: http://bugs.python.org/file26642/issue15502_new_abc.diff

___
Python tracker 

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

[issue15502] Meta path finders and path entry finders are different, but share an ABC

[Eric Snow]

Eric Snow added the comment:

> The patch will have Finder break all subclasses that don't define
> find_loader which is backwards-incompatible.

How so?  Finder is registered against PathEntryFinder.  It doesn't inherit, so 
it doesn't get the abc.ABCMeta as a metaclass and thereby there is no 
instantiation-time checks for find_loader().

Attached is a patch that makes the two names changes (FileFinder was all over 
the place).

--
Added file: http://bugs.python.org/file26653/issue15502_new_abc.diff

___
Python tracker 

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

[issue15526] regrtest crash on Windows 7 AMD64

[Jeremy Kloth]

Jeremy Kloth added the comment:

I have just completed an upgrade of the Win64 buildbot slave with a
faster hard drive and the issue is now much more pronounced.

--

___
Python tracker 

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

[issue15521] Dev Guide should say how to run tests in 2.7

[Chris Jerdonek]

Chris Jerdonek added the comment:

It is a relatively large section (nine paragraphs + six code snippets) and is 
primarily about the in-development branch, so I did not want to interrupt the 
flow with a remark specific to 2.7.  I also liked that the instructions in a 
subsection could be linked to.

But here is a new patch.

--
Added file: http://bugs.python.org/file26652/issue-15521-2.patch

___
Python tracker 

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

[issue15518] Provide test coverage for filecmp.dircmp.report methods.

[Chris Jerdonek]

Chris Jerdonek added the comment:

> However, I would like your blessing to continue with assertRegex in this case.

Sure, you can proceed that way. :)  My suggestions were just that -- 
suggestions for you to consider.  And I am not a core developer, so my approval 
won't necessarily get your patch committed more quickly. :)  Thanks for 
considering my suggestions.

--

___
Python tracker 

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

[issue15518] Provide test coverage for filecmp.dircmp.report methods.

[Chris Calloway]

Chris Calloway added the comment:

> There are at least two ways you could deal with this.  You could change the 
> working directory to the temp directory in setUp() and change it back in 
> tearDown().  This is a common pattern in the tests [...]

> Alternatively, you could save the temp directory path as an attribute of the 
> test class, and then include it in your string match prior to calling the 
> assert method.

Although I prefer explicitly testing that the subdirectory paths shows up in 
the reports and, in the case of the report_partial_closure test, the regex 
explicitly tests that the "only in" subdirectory is reported correctly, if I 
were to have to choose between the two options you propose, I would choose 
decorating the test instance with the strings as that would at least preserve 
the ability to perform the latter of the two explicit tests I mention and would 
not be subject to yet another file system point of failure while switching 
directories (even if that is a common pattern in the tests).

assertRegex is new from unittest2 and seems tailor-made for this use case to 
me. It gets the job done in explicitly correctly in the least amount of code. 
If you insist that I not use assertRegex for the report test, I will yield to 
your preferences. However, I would like your blessing to continue with 
assertRegex in this case.

In either event, I still will refactor the patch into separate test methods for 
the report methods as previously agreed after your continued feedback. And 
thank you again for your feedback above.

--

___
Python tracker 

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

[issue15231] update PyPI upload doc to say --no-raw passed to rst2html.py

[Eli Bendersky]

Eli Bendersky added the comment:

Backported in 014b36383a54 and 29bdbcadf299

--

___
Python tracker 

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

[issue15231] update PyPI upload doc to say --no-raw passed to rst2html.py

[Roundup Robot]

Roundup Robot added the comment:

New changeset 29bdbcadf299 by Eli Bendersky in branch '2.7':
Issue #15231: update PyPI upload doc to say --no-raw passed to rst2html.py
http://hg.python.org/cpython/rev/29bdbcadf299

--

___
Python tracker 

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

[issue15321] bdist_wininst installers may terminate with "close failed in file object destructor:\nsys.excepthook is missing\nlost sys.stderr"

[Roundup Robot]

Roundup Robot added the comment:

New changeset 014b36383a54 by Eli Bendersky in branch '3.2':
Issue #15321: update PyPI upload doc to say --no-raw passed to rst2html.py
http://hg.python.org/cpython/rev/014b36383a54

--

___
Python tracker 

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

[issue15502] Meta path finders and path entry finders are different, but share an ABC

[Barry A. Warsaw]

Barry A. Warsaw added the comment:

On Aug 01, 2012, at 10:44 PM, Nick Coghlan wrote:

>The problem with "path importer" is it's just plain *wrong*. That object is
>not an importer and thus calling it one makes it much harder to learn the
>finder/loader/importer distinctions correctly.

The term "importer" is sufficiently squishy though, and I think we could just
as easily adjust the term's definition in the glossary to match what this
thing is.

>"import finder" is only slightly longer than "importer" and has the huge
>advantage of *not being wrong*.

The problem is that "import finder" isn't correct either, because this thing
doesn't load modules, and it doesn't find imports.  It finds loaders through
different kinds of finders.

It is unquestionably a finder, so probably the most accurate term would be
"path finder" but that just didn't read well when I tried to use it.  Part of
the problem is that "path finder" isn't different enough from "path entry
finder" to avoid confusion, and I really like the latter to describe the
things that the sys.path_hooks callables return, and I'm sure none of us want
to call it the "path entry loader finder finder" :).

Keep trying, but so far "path importer" is the least crappy of the lot, IMHO.

--

___
Python tracker 

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

[issue15502] Meta path finders and path entry finders are different, but share an ABC

[Nick Coghlan]

Nick Coghlan added the comment:

The problem with "path importer" is it's just plain *wrong*. That object is
not an importer and thus calling it one makes it much harder to learn the
finder/loader/importer distinctions correctly. "import finder" is only
slightly longer than "importer" and has the huge advantage of *not being
wrong*.

--

___
Python tracker 

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

[issue15532] "for line in file" is *still* broken in Python 2.7 on pipes

[Andy Lutomirski]

Changes by Andy Lutomirski :


--
title: "for line in file" is *still* broken in Python 2.7 -> "for line in file" 
is *still* broken in Python 2.7 on pipes

___
Python tracker 

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

[issue15525] test_multiprocessing failure on Windows XP

[STINNER Victor]

STINNER Victor added the comment:

> Let's see if increasing the timeout fixes the failures.

At least, the 3 following builds succeed (let's see the next builds).

--
nosy: +haypo

___
Python tracker 

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

[issue15525] test_multiprocessing failure on Windows XP

[STINNER Victor]

Changes by STINNER Victor :


--
nosy: +pitrou

___
Python tracker 

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

[issue14713] PEP 414 installation hook fails with an AssertionError

[Vinay Sajip]

Changes by Vinay Sajip :


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

[issue1521950] shlex.split() does not tokenize like the shell

[Vinay Sajip]

Changes by Vinay Sajip :


--
versions: +Python 3.4 -Python 3.3

___
Python tracker 

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

[issue15502] Meta path finders and path entry finders are different, but share an ABC

[Barry A. Warsaw]

Barry A. Warsaw added the comment:

On Aug 01, 2012, at 10:03 PM, Nick Coghlan wrote:

>1. "path import subsystem" for that whole section of the import machinery;
>and
>2. "path import finder" specifically for the meta path finder that
>importlib calls "PathFinder" and the new docs currently call "path importer"

-0.  To me, this doesn't make things vastly more clear for the additional
awkwardness in readability.

>"path_importer_cache" would still be a bit of a misnomer, but that ship
>sailed a long time ago.

Yeah, we all agree that one's unfortunate! ;)

--

___
Python tracker 

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

[issue13072] Getting a buffer from a Unicode array uses invalid format

[STINNER Victor]

STINNER Victor added the comment:

@Georg: are you ok with this change? It reverts the behaviour of Python 3.2 and 
avoids to have to maintain an API that nobody wants to use ('u' format using 
Py_UCS4, 32 bits unsigned).

--
nosy: +georg.brandl

___
Python tracker 

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

[issue15530] Enhance Py_MIN and Py_MAX

[STINNER Victor]

STINNER Victor added the comment:

> I think that's too late for 3.3. It's not a bug fix.

Oops, I chose 3.3 instead of 3.4. Fixed.

> If we use this kind of feature, we either need to declare a minimum supported 
> GCC version

typeof() and __builtin_types_compatible_p() were introduced to gcc in version 
3.0 and 3.1.1. Do we plan to support GCC older than 3.1? :-)

> (any GCC older than 10 years can be dropped IMO)

GCC 3.1 was released 10 years ago. It's cheap to add a test on the GCC version 
to fallback on the simple "x Did you detect any errors in the Python code using this change?

Nope. But it avoids at least to evaluate an expression twice (if an argument is 
not a variable or a number, but a complex expression... like most new 
PyUnicode_*() macros). Even if I prefer to avoid expressions in macro 
arguments...

> Wouldn't the compiler refuse to perform the comparison
> if the types were not compatible?

I don't know exactly how __builtin_types_compatible_p() compare types. At 
least, I can say that int and unsigned int are considered as incompatible.

--

The Linux kernel uses "(void) (&_min1 == &_min2);" to check that types are 
compatible. I suppose that this expression is written for GCC. GCC only emits a 
warning, I chose Py_BUILD_ASSERT_EXPR() to emit an error instead.

--
versions: +Python 3.4 -Python 3.3

___
Python tracker 

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

[issue15502] Meta path finders and path entry finders are different, but share an ABC

[Nick Coghlan]

Nick Coghlan added the comment:

As a final attempt at giving the path import machinery the emphasis it
deserves without misusing the "importer" term, how about:
1. "path import subsystem" for that whole section of the import machinery;
and
2. "path import finder" specifically for the meta path finder that
importlib calls "PathFinder" and the new docs currently call "path importer"

"path_importer_cache" would still be a bit of a misnomer, but that ship
sailed a long time ago.

--

___
Python tracker 

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

[issue15532] "for line in file" is *still* broken in Python 2.7

[Andy Lutomirski]

New submission from Andy Lutomirski:

This program:

import subprocess, sys
p = subprocess.Popen(['bash', '-c', 'while true; do echo x; sleep 1; done'], 
bufsize=0, stdout=subprocess.PIPE)

for line in p.stdout:
sys.stdout.buffer.write(line)
sys.stdout.flush()

sits around and does nothing on Python 2.7.3.  It works (i.e. prints 'x' once 
per second) on Python 3.

This was http://bugs.python.org/issue3907 and is supposedly fixed, but it's not.

--
components: IO
messages: 167170
nosy: Andy.Lutomirski
priority: normal
severity: normal
status: open
title: "for line in file" is *still* broken in Python 2.7
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

[issue9635] Add Py_BREAKPOINT and sys._breakpoint hooks

[Dave Malcolm]

Dave Malcolm added the comment:

Note to self: a messy way of forcing gdb to do the equivalent of a breakpoint 
directly from Python is:
  os.kill(os.getpid(), signal.SIGTRAP)

--

___
Python tracker 

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

[issue15530] Enhance Py_MIN and Py_MAX

[Martin v . Löwis]

Martin v. Löwis added the comment:

I think that's too late for 3.3. It's not a bug fix.

If we use this kind of feature, we either need to declare a minimum supported 
GCC version (any GCC older than 10 years can be dropped IMO), or check for the 
specific version of GCC in which all the necessary features were present.

Did you detect any errors in the Python code using this change? Wouldn't the 
compiler refuse to perform the comparison if the types were not compatible?

--
nosy: +loewis

___
Python tracker 

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

[issue15510] textwrap.wrap('') returns empty list

[Chris Jerdonek]

Chris Jerdonek added the comment:

Here are additional test cases impacted by this issue:

>>> wrap("   ")
[]
>>> wrap("\n\n\n")
[]
>>> wrap("\n\n\n", replace_whitespace=False)
[]
>>> wrap("  \n\n", replace_whitespace=False)
[]

--

___
Python tracker 

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

[issue15468] Edit docs to hide hashlib.md5()

[Christian Heimes]

Changes by Christian Heimes :


--
nosy: +christian.heimes

___
Python tracker 

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

[issue15500] Python should support naming threads

[Christian Heimes]

Christian Heimes added the comment:

+1

win32 supports thread names, too. 
http://msdn.microsoft.com/en-us/library/xcb2z8hs.aspx

--
nosy: +christian.heimes

___
Python tracker 

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

[issue13072] Getting a buffer from a Unicode array uses invalid format

[Stefan Krah]

Stefan Krah added the comment:

array_revert_pep393-2.patch looks good (checked against 7042a83f37e
and all following commits that should be kept).

--

___
Python tracker 

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

[issue15529] PyIter_Check evaluates to 0 for Python list object

[Brett Cannon]

Brett Cannon added the comment:

I think Benjamin meant to say lists are iterables not iterators. =)

--
nosy: +brett.cannon

___
Python tracker 

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

[issue15531] os.path symlink docs missing

[Dave Abrahams]

New submission from Dave Abrahams:

the docs for os.path don't mention the following facts which I think are 
important (in fact I assumed the facts would be the reverse):

os.path.realpath(l) works when l is a broken symbolic link, returning the path 
to the (missing) target

os.path.readlink(l) causes an error when l is a broken symbolic link.

--
assignee: docs@python
components: Documentation
messages: 167163
nosy: dabrahams, docs@python
priority: normal
severity: normal
status: open
title: os.path symlink docs missing
type: enhancement
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

[issue15463] test_faulthandler can fail if install path is too long

[Chris Jerdonek]

Chris Jerdonek added the comment:

> Yes, I saw your patch, but I don't want to create very long filename.
Not all platforms support paths longer than 500 characters.

I think you may have a slight misunderstanding.  My patch was not meant to test 
paths over 500 characters.  It tests a path *under* 500 characters (but 
slightly over 100 characters).  And it has the same style and portability 
characteristics as the existing ".*threading.py" tests.

> My patch is different than yours: it checks that the string is
truncated, not that string shorter than the limit are not truncated.

Yes, your patch is different in two ways. :) It tests function names instead of 
paths, and length > 500 instead of 100 < length < 500.  I think there is value 
in adding a file path test because code changes over time, so it may not always 
be using the same code path as function names.

I agree that it is okay to leave out a file path test for longer than 500 
characters for the portability reasons you stated.

--

___
Python tracker 

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

[issue15530] Enhance Py_MIN and Py_MAX

[STINNER Victor]

New submission from STINNER Victor:

Attached patch enhances Py_MIN and Py_MAX to check that types of both arguments 
are compatible at compile time. Checks are only done if the compiler is GCC.

The patch uses also Py_MIN and Py_MAX in more places. (The commit may be done 
in two parts.)

--
components: Interpreter Core
files: py_min_max.patch
keywords: patch
messages: 167161
nosy: haypo
priority: normal
severity: normal
status: open
title: Enhance Py_MIN and Py_MAX
versions: Python 3.3
Added file: http://bugs.python.org/file26651/py_min_max.patch

___
Python tracker 

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

[issue15463] test_faulthandler can fail if install path is too long

[STINNER Victor]

STINNER Victor added the comment:

> Victor, did you see and review my patch? There is currently no test to check 
> that a long file path (longer than 100 characters) will render, which was the 
> original issue that was fixed.  The patch provides such a test.

Yes, I saw your patch, but I don't want to create very long filename.
Not all platforms support paths longer than 500 characters. It is
exactly the same code to display function name and file names. I
prefer to use a very long function name, it's simple and portable.

My patch is different than yours: it checks that the string is
truncated, not that string shorter than the limit are not truncated.

--

___
Python tracker 

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

[issue15463] test_faulthandler can fail if install path is too long

[Chris Jerdonek]

Chris Jerdonek added the comment:

> I didn't want to write such test, but I can review a patch adding such test.

Victor, did you see and review my patch?  There is currently no test to check 
that a long file path (longer than 100 characters) will render, which was the 
original issue that was fixed.  The patch provides such a test.

--

___
Python tracker 

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

[issue15441] test_posixpath fails on Japanese edition of Windows

[STINNER Victor]

STINNER Victor added the comment:

This issue (the test) should be fixed, see the issue #15478 for the real fix.

--
resolution:  -> fixed
status: open -> closed

___
Python tracker 

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

[issue15441] test_posixpath fails on Japanese edition of Windows

[Roundup Robot]

Roundup Robot added the comment:

New changeset 3edc71ed19e7 by Victor Stinner in branch 'default':
Issue #15441: Skip test_nonascii_abspath() of test_genericpath on Windows
http://hg.python.org/cpython/rev/3edc71ed19e7

--
nosy: +python-dev

___
Python tracker 

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

[issue15213] _PyOS_URandom documentation

[STINNER Victor]

STINNER Victor added the comment:

> The comment needs to be fixed before the issue is closed.

Ah yes, here is a patch updating the comment of _PyOS_URandom() and
the doc of the os module.

--
keywords: +patch
Added file: http://bugs.python.org/file26650/urandom_doc.patch

___
Python tracker 

___diff -r 2dd1b056d663 Doc/library/os.rst
--- a/Doc/library/os.rstWed Aug 01 14:53:22 2012 +0200
+++ b/Doc/library/os.rstWed Aug 01 15:34:07 2012 +0200
@@ -3331,5 +3331,5 @@ Miscellaneous Functions
This function returns random bytes from an OS-specific randomness source.  
The
returned data should be unpredictable enough for cryptographic applications,
though its exact quality depends on the OS implementation.  On a Unix-like
-   system this will query /dev/urandom, and on Windows it will use 
CryptGenRandom.
-   If a randomness source is not found, :exc:`NotImplementedError` will be 
raised.
+   system this will query ``/dev/urandom``, and on Windows it will use
+   :c:func:`CryptGenRandom`.
diff -r 2dd1b056d663 Python/random.c
--- a/Python/random.c   Wed Aug 01 14:53:22 2012 +0200
+++ b/Python/random.c   Wed Aug 01 15:34:07 2012 +0200
@@ -219,8 +219,9 @@ lcg_urandom(unsigned int x0, unsigned ch
 }
 }
 
-/* Fill buffer with size pseudo-random bytes, not suitable for cryptographic
-   use, from the operating random number generator (RNG).
+/* Fill buffer with size pseudo-random bytes from the operating random number
+   generator (RNG). It is suitable for for most cryptographic purposes except
+   long living private keys for asymmetric encryption.
 
Return 0 on success, raise an exception and return -1 on error. */
 int
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15479] Allow MAX_STRING_LENGTH limits to be changed at runtime

[STINNER Victor]

STINNER Victor added the comment:

> Sounds totally overkill to me.

I changed the maximum length of a string to 500 characters instead of
100. It should be enough for most cases.

--

___
Python tracker 

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

[issue14811] decoding_fgets() truncates long lines and fails with a SyntaxError("Non-UTF-8 code starting with...")

[STINNER Victor]

STINNER Victor added the comment:

> Are we going to fix this before 3.3? Any objections to Victor's patch?

detect_truncate.patch is now raising an error if a line is longer than BUFSIZ, 
whereas Python supports lines longer than BUFSIZ bytes (it's just that the 
encoding cookie is ignored if the line 1 or 2 is longer than BUFSIZ bytes). So 
my patch is not correct.

--

___
Python tracker 

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

[issue15463] test_faulthandler can fail if install path is too long

[STINNER Victor]

STINNER Victor added the comment:

I added a test checking that faulthandler truncates strings to 
MAX_STRING_LENGTH characters using a very long function name. I consider this 
issue as done.

--
resolution:  -> fixed
status: open -> closed

___
Python tracker 

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

[issue15463] test_faulthandler can fail if install path is too long

[Roundup Robot]

Roundup Robot added the comment:

New changeset 6e03f9b72c61 by Victor Stinner in branch 'default':
Issue #15463: Write a test for faulthandler truncating the name of functions
http://hg.python.org/cpython/rev/6e03f9b72c61

--

___
Python tracker 

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

[issue15502] Meta path finders and path entry finders are different, but share an ABC

[Brett Cannon]

Brett Cannon added the comment:

The patch will have Finder break all subclasses that don't define find_loader 
which is backwards-incompatible. And if you really want to deprecate Finder you 
should have a warning in an __init__ method (as one would hope people are 
calling super() as necessary). Otherwise the patch looks fine (from a cursory 
glance).

--

___
Python tracker 

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

[issue15519] finish exposing WindowsRegistryImporter in importlib

[Brett Cannon]

Brett Cannon added the comment:

It should be exposed (i.e. if SourcelessFileLoader is documented and exposed 
then so should WindowsRegistryFinder).

--

___
Python tracker 

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

[issue15519] finish exposing WindowsRegistryImporter in importlib

[Eric Snow]

Eric Snow added the comment:

I guess the real question here is if anyone has problems with adding 
WindowsRegistryFinder to importlib.machinery (and to the importlib docs).  If 
it should stay private than I'd like to throw a _ on the name of the class.  
The change to importlib.abc would likely stay either way.

--

___
Python tracker 

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

[issue15519] finish exposing WindowsRegistryImporter in importlib

[Eric Snow]

Eric Snow added the comment:

Also, WindowsRegistryImporter is misnamed.  It should be WindowsRegistryFinder 
(see issue15502).  Depending on the patch there, I'll update the one here.

--
dependencies: +Meta path finders and path entry finders are different, but 
share an ABC

___
Python tracker 

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

[issue15502] Meta path finders and path entry finders are different, but share an ABC

[Eric Snow]

Eric Snow added the comment:

@Barry: I'm fine with what you've said.  My big concern is that we be really 
consistent here because of the complexity of the import system.  Things are at 
a point that I think we're pretty close in the regard, so I'm mostly fine if we 
stay put.  My only real regret would likely be "path importer" vs. PathFinder, 
but I can live with it. :)

@Brett: I'll update my patch for WindowsRegistryImporter and FileFinder.

@anyone: do the doc-based deprecations in the patch look okay?  The inheritance 
model?

--

___
Python tracker 

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

[issue15525] test_multiprocessing failure on Windows XP

[Richard Oudkerk]

Richard Oudkerk added the comment:

I would guess that the process has already terminated (or is being torn down) 
but the timeout is not long enough to let the parent join child.

Let's see if increasing the timeout fixes the failures.

--

___
Python tracker 

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

[issue15525] test_multiprocessing failure on Windows XP

[Roundup Robot]

Roundup Robot added the comment:

New changeset b99a82bc2cde by Richard Oudkerk in branch 'default':
Issue #15525: Increase timeout when TerminateProcess() fails
http://hg.python.org/cpython/rev/b99a82bc2cde

--
nosy: +python-dev

___
Python tracker 

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

[issue15529] PyIter_Check evaluates to 0 for Python list object

[Benjamin Peterson]

Benjamin Peterson added the comment:

That's because lists are iterators not iterable.

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

___
Python tracker 

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

[issue15529] PyIter_Check evaluates to 0 for Python list object

[Tom Tromey]

New submission from Tom Tromey:

I was debugging this bug reported against gdb:

http://sourceware.org/bugzilla/show_bug.cgi?id=14386

It turns out that what went wrong in this code was that
PyIter_Check evaluates to 0 when its argument is a
Python list.

This happens because the PyIter_Check macro looks at the
tp_iternext field; but this field is 0 in PyList_Type.

I am not sure of the correct fix; but PyIter_Check is not
faithfully reflecting what PyObject_GetIter does.
Maybe it isn't intended to; but anyway it seems that
checking tp_iter would maybe be a better approximation.

Even if PyIter_Check remains as-is, I think it would be nice
if the documentation were more specific about what it
actually does.

FWIW I'm modifying gdb not to use this function.

--
components: None
messages: 167143
nosy: tromey
priority: normal
severity: normal
status: open
title: PyIter_Check evaluates to 0 for Python list object
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

[issue15528] Better support for finalization with weakrefs

[Richard Oudkerk]

New submission from Richard Oudkerk:

A patch with docs and tests for the idea I suggested on python-ideas:

http://comments.gmane.org/gmane.comp.python.ideas/15863

To repeat what I wrote there, the current issues with weakref callbacks include:

1. They are rather low level, and working out how to use them
   correctly requires a bit of head scratching.  One must find
   somewhere to store the weakref till after the referent is dead, and
   without accidentally keeping the referent alive.  Then one must
   ensure that the callback frees the weakref (without leaving any
   remnant ref-cycles).

   When it is an option, using a __del__ method is far less hassle.

2. Callbacks invoked during interpreter shutdown are troublesome.  For
   instance they can throw exceptions because module globals have been
   replaced by None.

3. Sometimes you want the callback to be called at program exit even
   if the referent is still alive.

4. Exceptions thrown in callbacks do not produce a traceback.  This
   can make debugging rather awkward.  (Maybe this is because printing
   tracebacks is problematic during interpreter shutdown?)

(Note that problems 2-4 also apply to using __del__ methods.)

Trivial usage of the class looks like

>>> class Kenny: pass
...
>>> kenny = Kenny()
>>> finalize(kenny, print, "you killed kenny!")

>>> del kenny
you killed kenny!

--
files: finalize.patch
keywords: patch
messages: 167142
nosy: sbt
priority: normal
severity: normal
stage: patch review
status: open
title: Better support for finalization with weakrefs
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file26649/finalize.patch

___
Python tracker 

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

[issue15468] Edit docs to hide hashlib.md5()

[Daniel Holth]

Daniel Holth added the comment:

re-tweak treatment of md5 in hashlib docs (the SHA-2 family is currently 
recommended by http://csrc.nist.gov/groups/ST/toolkit/secure_hashing.html)

--
Added file: http://bugs.python.org/file26648/hashlib.patch

___
Python tracker 

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

[issue15527] Double parens in functions references

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
title: Double parents in functions references -> Double parens in functions 
references

___
Python tracker 

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

[issue15521] Dev Guide should say how to run tests in 2.7

[Ezio Melotti]

Ezio Melotti added the comment:

Thanks for the patch.
I'm not sure it's necessary to add a new section though, unless you are 
planning to add more differences there.

+base command instead of the one described above: ::

You can just use "... above::" here.

--

___
Python tracker 

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

[issue6308] termios fix for QNX breaks HP-UX

[Dirkjan Ochtman]

Dirkjan Ochtman added the comment:

Can we have someone take a look at this? It seems fairly innocuous.

--
nosy: +djc

___
Python tracker 

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

[issue15502] Meta path finders and path entry finders are different, but share an ABC

[Brett Cannon]

Brett Cannon added the comment:

So just to weigh in on this, I think "meta path finder" and "path entry finder" 
(as Barry stated in the glossary already) clearly delineate what is from 
sys.meta_path and what is from some path entry hook by having a clarifying word 
to go with "finder" (either kind of finder is still trying to find a loader). 
Finder/loader/importer has history in terms of usage so we can't muck with 
these terms too much.

This does mean, though, that PathFinder and FileFinder are misnamed. 
Unfortunately PathFinder existed in previous versions of Python, so it will 
need an alias to its old name from a new name (PathImporter as Barry wants or 
MetaPathEntryFinder?). But FileFinder is new, so that can be renamed to 
FilePathEntryFinder (or FileEntryFinder). And of course WindowsRegistryImporter 
should be changed to *Finder.

I think if we harp on the "meta path" vs. "path entry" and use it consistently 
and extensively then the finder/loader/importer terminology does not need to 
change meaning and we don't have to misuse it for path importer to classify 
PathFinder while keeping the rest of Barry's terms intact which make it obvious 
when something is directly because of how import works vs. just a single meta 
path finder that happens to be what nearly everyone ends up using to handle 
their imports.

--

___
Python tracker 

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

[issue15527] Double parents in functions references

[Serhiy Storchaka]

New submission from Serhiy Storchaka:

:c:func:`PyMem_Malloc(n)` on Doc/c-api/memory.rst:109 rendered in HTML as PyMem_Malloc(1)() (note double parents). There are many 
other examples on this and other pages. The issue is actual for all modern 
versions of Python.

--
assignee: docs@python
components: Documentation
messages: 167137
nosy: docs@python, storchaka
priority: normal
severity: normal
status: open
title: Double parents in functions references
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

[issue15519] finish exposing WindowsRegistryImporter in importlib

[Antoine Pitrou]

Antoine Pitrou added the comment:

> The importers can both find and load modules (e.g. BuiltinImporter
> defines both find_module() and load_module()), while the finders only
> find modules (e.g. only define find_module()).

Ah, fair enough. I thought loader objects were always distinct from
finders.

--

___
Python tracker 

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

[issue15519] finish exposing WindowsRegistryImporter in importlib

[Brett Cannon]

Brett Cannon added the comment:

The importers can both find and load modules (e.g. BuiltinImporter defines both 
find_module() and load_module()), while the finders only find modules (e.g. 
only define find_module()). It's defined in the glossary, so maybe more links 
to that would help.

--

___
Python tracker 

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

[issue15496] harden directory removal for tests on Windows

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
nosy: +brian.curtin
stage:  -> patch review
versions: +Python 2.7, Python 3.2

___
Python tracker 

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

[issue15502] Meta path finders and path entry finders are different, but share an ABC

[Barry A. Warsaw]

Barry A. Warsaw added the comment:

I've mostly run out of time to work on the docs, but I do want to say that I
thought long and hard about all the terminology decisions.  Please don't
change them lightly, and definitely don't change them until you've tried to go
through the documentation and make all the updates and read through them to
see how well it flows and makes sense.  It is *not* easy.

On Aug 01, 2012, at 05:13 AM, Eric Snow wrote:

>("importer" == finder + loader) sounds fine with me.

That's how I tried to think about it.  In some sense, it's just an
implementation detail, but where it comes into the play for the documentation
is the "path importer", which is the thing on sys.meta_path that implements
all the sys.path/sys.path_hooks/sys.path_importer_cache semantics.

While technically a finder, calling it the "path finder" just does not work,
IMHO.  It's too confusing and causes the documentation to be less
comprehensible.  So the one compromise I made was to call this thing the "path
importer" because I think conceptually, if not strictly implementation-wise,
that term ties everything together.

A diagram would seal the deal I think.

>I'm find with changing "path importer" to "path finder".  If no one does a
>patch first, I'll put one up tomorrow.

Please don't, for reasons stated above!

>I actually prefer "path entry handler" for the distinctiveness, but I'm fine
>with leaving it be.  However, I get a sense that this is our one shot at this
>decision.

I don't think "handler" is a very good term.  These things *are* finders, even
if the API they support is richer and slightly different than meta path
finders.  Also, I think "path entry handler" could almost be just as useful
for the things on sys.path_hooks, although I do use "path entry hook" here.
But in a sense the callables on sys.path_hooks also "handle" path entries,
just in a different way.  I think "path entry finder" neatly describes both
its similarities and differences from other objects in the picture.

I'm going to leave all the abc names and implementations to you guys. :)

Thanks for all your excellent feedback and your own work on this nasty little
corner of Python. :)

--

___
Python tracker 

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

[issue15526] regrtest crash on Windows 7 AMD64

[Jeremy Kloth]

Jeremy Kloth added the comment:

> Well, test_startfile seems to be a common issue on that buildbot.

I wouldn't really call it common (twice in the last 30 runs).

However I would wager that the PermissionError is being caused by an
unknown (without having Process Monitor running when the error occurs)
process temporarily grabbing a handle to a file/directory within the
tests temporary directory.

This just reinforces the need for the solution in issue15496 to be applied.

--

___
Python tracker 

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

[issue15496] harden directory removal for tests on Windows

[Jeremy Kloth]

Jeremy Kloth added the comment:

I must also add that the proposed solution works well within the test suite as 
the access denied error can also occur when creating subsequent files, not just 
removing them.

This solution eliminates the need to wrap all creation calls with access denied 
handling, a huge plus IMHO.

--

___
Python tracker 

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

[issue15520] Document datetime.timestamp() in 3.3 What's New

[Antoine Pitrou]

Antoine Pitrou added the comment:

Yes, of course.

--
nosy: +pitrou

___
Python tracker 

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

[issue15510] textwrap.wrap('') returns empty list

[Antoine Pitrou]

Antoine Pitrou added the comment:

Uh, how is this a bug? An empty text doesn't contain lines at all, so returning 
an empty list of lines sounds right.

Furthermore, by "fixing" this, you may break existing software.

--
nosy: +pitrou

___
Python tracker 

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

[issue15519] finish exposing WindowsRegistryImporter in importlib

[Antoine Pitrou]

Antoine Pitrou added the comment:

I'm not sure why some finders are named "Finder" and others "Importer". It 
makes things confusing.

--
nosy: +pitrou

___
Python tracker 

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

[issue15522] impove 27 percent performance on stringpbject.c( by prefetch and loop optimization)

[Jesús Cea Avión]

Changes by Jesús Cea Avión :


--
nosy: +jcea

___
Python tracker 

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

[issue15526] regrtest crash on Windows 7 AMD64

[Antoine Pitrou]

Antoine Pitrou added the comment:

Well, test_startfile seems to be a common issue on that buildbot.

--
nosy: +jeremy.kloth, pitrou

___
Python tracker 

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

[issue15519] finish exposing WindowsRegistryImporter in importlib

[Nick Coghlan]

Changes by Nick Coghlan :


--
nosy: +ncoghlan

___
Python tracker 

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

[issue15526] regrtest crash on Windows 7 AMD64

[Nick Coghlan]

New submission from Nick Coghlan:

regrtest bailed out completely on one of the Windows 7 builders due to a 
problem with accessing the temporary working directory:

http://buildbot.python.org/all/builders/AMD64%20Windows7%20SP1%203.x/builds/410/steps/test/logs/stdio

It's seems a touch suspicious that test_fork1 just so happened to be the test 
executed right before test_startfile blew up.

Not marking as a blocker yet, since my initial assumption is that it's a race 
condition with a particular sequence of tests rather than a problem in Python 
itself. I'll change my mind if it happens again on the rebuild I just forced.

--
components: Tests
keywords: buildbot
messages: 167126
nosy: georg.brandl, ncoghlan
priority: normal
severity: normal
status: open
title: regrtest crash on Windows 7 AMD64
type: crash
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

[issue8847] crash appending list and namedtuple

[Martin v . Löwis]

Martin v. Löwis added the comment:

> Ah yes, you added new tests to Python 3.2 and 3.3, but no to Python
> 2.7. Why not adding these new tests to Python 2.7?

The tests don't crash Python 2.7. So they are not useful as a test whether
the bug has been worked-around. I actually don't know how to test this  
compiler
bug in Python 2.7 (except for writing specific C code that tries to trigger
the bug).

--

___
Python tracker 

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

[issue13072] Getting a buffer from a Unicode array uses invalid format

[Arfrever Frehtes Taifersar Arahesis]

Changes by Arfrever Frehtes Taifersar Arahesis :


--
nosy: +Arfrever

___
Python tracker 

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

[issue15525] test_multiprocessing failure on Windows XP

[Nick Coghlan]

New submission from Nick Coghlan:

test_multiprocessing failed on one of the XP buildbots with a permission error:

http://buildbot.python.org/all/builders/x86%20XP-4%203.x/builds/7223/steps/test/logs/stdio

The immediate rerun also failed, but the one at the end of the test run 
succeeded.

--
components: Library (Lib)
keywords: buildbot
messages: 167125
nosy: georg.brandl, ncoghlan, sbt
priority: release blocker
severity: normal
stage: needs patch
status: open
title: test_multiprocessing failure on Windows XP
type: behavior
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

[issue15425] Another strange Tracebacks with importlib

[Nick Coghlan]

Nick Coghlan added the comment:

Indeed, there are still a couple of Windows failures, but they aren't related 
to this.

--
status: pending -> closed

___
Python tracker 

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

[issue15522] impove 27 percent performance on stringpbject.c( by prefetch and loop optimization)

[Antoine Pitrou]

Antoine Pitrou added the comment:

Hi, several points:

- Python 2.7 is in bugfix mode; you need to work from the default Mercurial 
branch as explained in http://docs.python.org/devguide/ . In practice, this 
means your patch will target the future Python 3.4, and therefore either 
PyUnicode_Join or _PyBytes_Join.

- please provide an actual patch (a Mercurial diff, probably)

- please provide benchmarks (using e.g. timeit) which demonstrate the 
performance improvement you are proposing

--
nosy: +pitrou
versions: +Python 3.4 -Python 2.7

___
Python tracker 

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

[issue15524] Dict items() ordering varies across interpreter invocations

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
resolution:  -> invalid
status: open -> closed

___
Python tracker 

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

[issue13072] Getting a buffer from a Unicode array uses invalid format

[STINNER Victor]

STINNER Victor added the comment:

> The diff between b9558df8cc58 and default with array_revert_pep393.patch
> applied is small, but I noticed that in some places you switched back to
> Py_UNICODE typecode and in others not.

I just copied code from Python 3.2, I forgot to update typecode type
(Py_UNICODE => char). I attach a new patch which changes also the
documentation of the "u" format.

--
Added file: http://bugs.python.org/file26647/array_revert_pep393-2.patch

___
Python tracker 

___diff -r d3afe5d8a4da Doc/library/array.rst
--- a/Doc/library/array.rst Wed Aug 01 11:09:55 2012 +0200
+++ b/Doc/library/array.rst Wed Aug 01 14:43:35 2012 +0200
@@ -21,7 +21,7 @@ defined:
 
+---++---+---+---+
 | ``'B'``   | unsigned char  | int   | 1 | 
  |
 
+---++---+---+---+
-| ``'u'``   | Py_UCS4| Unicode character | 4 | 
  |
+| ``'u'``   | Py_UNICODE | Unicode character | 2 | 
\(1)  |
 
+---++---+---+---+
 | ``'h'``   | signed short   | int   | 2 | 
  |
 
+---++---+---+---+
@@ -35,9 +35,9 @@ defined:
 
+---++---+---+---+
 | ``'L'``   | unsigned long  | int   | 4 | 
  |
 
+---++---+---+---+
-| ``'q'``   | signed long long   | int   | 8 | 
\(1)  |
+| ``'q'``   | signed long long   | int   | 8 | 
\(2)  |
 
+---++---+---+---+
-| ``'Q'``   | unsigned long long | int   | 8 | 
\(1)  |
+| ``'Q'``   | unsigned long long | int   | 8 | 
\(2)  |
 
+---++---+---+---+
 | ``'f'``   | float  | float | 4 | 
  |
 
+---++---+---+---+
@@ -47,6 +47,11 @@ defined:
 Notes:
 
 (1)
+   The ``'u'`` type code corresponds to Python's unicode character
+   (:c:type:`Py_UNICODE` which is :c:type:`wchar_t`). Depending on the
+   platform, it can be 16 bits or 32 bits.
+
+(2)
The ``'q'`` and ``'Q'`` type codes are available only if
the platform C compiler used to build Python supports C :c:type:`long long`,
or, on Windows, :c:type:`__int64`.
diff -r d3afe5d8a4da Modules/arraymodule.c
--- a/Modules/arraymodule.c Wed Aug 01 11:09:55 2012 +0200
+++ b/Modules/arraymodule.c Wed Aug 01 14:43:35 2012 +0200
@@ -174,25 +174,24 @@ BB_setitem(arrayobject *ap, Py_ssize_t i
 static PyObject *
 u_getitem(arrayobject *ap, Py_ssize_t i)
 {
-return PyUnicode_FromOrdinal(((Py_UCS4 *) ap->ob_item)[i]);
+return PyUnicode_FromUnicode(&((Py_UNICODE *) ap->ob_item)[i], 1);
 }
 
 static int
 u_setitem(arrayobject *ap, Py_ssize_t i, PyObject *v)
 {
-PyObject *p;
+Py_UNICODE *p;
+Py_ssize_t len;
 
-if (!PyArg_Parse(v, "U;array item must be unicode character", &p))
+if (!PyArg_Parse(v, "u#;array item must be unicode character", &p, &len))
 return -1;
-if (PyUnicode_READY(p))
-return -1;
-if (PyUnicode_GET_LENGTH(p) != 1) {
+if (len != 1) {
 PyErr_SetString(PyExc_TypeError,
 "array item must be unicode character");
 return -1;
 }
 if (i >= 0)
-((Py_UCS4 *)ap->ob_item)[i] = PyUnicode_READ_CHAR(p, 0);
+((Py_UNICODE *)ap->ob_item)[i] = p[0];
 return 0;
 }
 
@@ -444,13 +443,6 @@ d_setitem(arrayobject *ap, Py_ssize_t i,
 return 0;
 }
 
-#if SIZEOF_INT == 4
-#  define STRUCT_LONG_FORMAT "I"
-#elif SIZEOF_LONG == 4
-#  define STRUCT_LONG_FORMAT "L"
-#else
-#  error "Unable to get struct format for Py_UCS4"
-#endif
 
 /* Description of types.
  *
@@ -460,7 +452,7 @@ d_setitem(arrayobject *ap, Py_ssize_t i,
 static struct arraydescr descriptors[] = {
 {'b', 1, b_getitem, b_setitem, "b", 1, 1},
 {'B', 1, BB_getitem, BB_setitem, "B", 1, 0},
-{'u', sizeof(Py_UCS4), u_getitem, u_setitem, STRUCT_LONG_FORMAT, 0, 0},
+{'u', sizeof(Py_UNICODE), u_getitem, u_setitem, "u", 0, 0},
 {'h', sizeof(short), h_getitem, h_setitem, "h", 1, 1},
 {'H', sizeof(short), HH_getitem, HH_setitem, "H", 1, 0},
 {'i', sizeof(int), i_getitem, i_setitem, "i", 1, 1},
@@ -1519,26 +1511,25 @@ This method is deprecated. Use tobytes i
 static PyObject *
 array_fromunicod

[issue15524] Dict items() ordering varies across interpreter invocations

[Antoine Pitrou]

Antoine Pitrou added the comment:

Yes, because hash randomization is now enabled by default:
http://docs.python.org/dev/reference/datamodel.html#object.__hash__

If you want deterministic behaviour, just set e.g. PYTHONHASHSEED=0.
(or any other fixed value)

--
nosy: +pitrou

___
Python tracker 

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

[issue8847] crash appending list and namedtuple

[STINNER Victor]

STINNER Victor added the comment:

> Please rephrase your question: what tests did I not add?
> I did add the tests that Stefan proposed.

Ah yes, you added new tests to Python 3.2 and 3.3, but no to Python
2.7. Why not adding these new tests to Python 2.7?

--

___
Python tracker 

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

[issue13072] Getting a buffer from a Unicode array uses invalid format

[Stefan Krah]

Stefan Krah added the comment:

The diff between b9558df8cc58 and default with array_revert_pep393.patch
applied is small, but I noticed that in some places you switched back to
Py_UNICODE typecode and in others not. For instance, in struct arraydescr
typecode is still char.

I'm not sure why typecode was originally Py_UNICODE though.

--

___
Python tracker 

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

[issue15213] _PyOS_URandom documentation

[Antoine Pitrou]

Antoine Pitrou added the comment:

The comment needs to be fixed before the issue is closed.

--

___
Python tracker 

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