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

[Roundup Robot]

Roundup Robot added the comment:

New changeset 851adff2d434 by Ezio Melotti in branch 'default':
#15521: mention that test.regrtest is necessary to run tests on 2.7.  Patch by 
Chris Jerdonek.
http://hg.python.org/devguide/rev/851adff2d434

--
nosy: +python-dev

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

Fixed, thanks for the patch!

--
assignee: docs@python -> ezio.melotti
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

___
Python tracker 

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

[issue15496] harden directory removal for tests on Windows

[Tim Golden]

Tim Golden added the comment:

I'm +1 on the approach in principle. I'm tentative about using ctypes
for this just because I don't believe we use it anywhere else. But at
the least I suggest applying the patch to see how Jeremy's buildbot
behaves. If there are wider objections to ctypes we could always work up
a C patch. (In 3.3+ we could use the new _winapi module).

--

___
Python tracker 

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

[issue10731] UnicodeDecodeError in OS X tkinter when binding to

[Ned Deily]

Ned Deily added the comment:

Tcl/Tk 8.5.12 has now been released.  After installing ActiveTcl 8.5.12 for OS 
X, your 3.2 test case that previously readily failed for me no longer does.  So 
I hope you also find that the problem is now resolved.

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

___
Python tracker 

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

[issue15534] xmlrpc escaping breaks on unicode \u043c

[Dmitry Dvoinikov]

New submission from Dmitry Dvoinikov:

For the following script

import xmlrpc.client; from xmlrpc.client import escape
text = "...\u043c..<"
print(escape(text))

Python 3.3.0b1 produces
...ь..<...<
whereas Python 3.2
...ь..<

--
components: Library (Lib)
messages: 167199
nosy: ddvoinikov
priority: normal
severity: normal
status: open
title: xmlrpc escaping breaks on unicode \u043c
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

[issue15496] harden directory removal for tests on Windows

[Nick Coghlan]

Nick Coghlan added the comment:

My inclination is to say that using ctypes is a reasonable option for improving 
Windows buildbot stability in the near term, but we'd probably want to move 
this into _winapi long term.

Adding Antoine & MvL to get their opinion.

--
nosy: +loewis, 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]

Nick Coghlan added the comment:

We'll also want to add this to the inheritance tests in test_importlib.test_abc

--

___
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

[Martin v . Löwis]

Martin v. Löwis added the comment:

I wonder why it couldn't use os.listdir to find out whether the directory is 
empty, and os.stat to find out whether a specific file or directory still 
exists.

--

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

In reviewing Eric's changes, I found what I consider a good reason to keep 
Finder as the root of the hierarchy: *all* finders, both meta path and path 
entry, will continue to share the optional "invalidate_caches" API.

I'll commit a variant that has the inheritance that way around (still narrowing 
the "find_module" API for the new ABCs) and see how it looks to everyone.

--

___
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

[Roundup Robot]

Roundup Robot added the comment:

New changeset 184700df5b6a by Nick Coghlan in branch 'default':
Issue #15502: Bring the importlib ABCs into line with the current state of the 
import protocols given PEP 420. Original patch by Eric Snow.
http://hg.python.org/cpython/rev/184700df5b6a

--
nosy: +python-dev

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

Specifically, what I did was to drop "find_module" from the Finder ABC, but 
keep the ABC itself as a way to document the common "invalidate_caches" API. 
The ABC definition no longer cares whether you implement find_module() or not. 
MetaPathFinder then enforces find_module(), while PathEntryFinder enforces 
find_loader().

--

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

Nick Coghlan added the comment:

This didn't close automatically (I assume the open dependency upset matters, 
since it also prevented me from closing it manually the first time).

Applied to trunk in http://hg.python.org/cpython/rev/a1ac1e13c5a0

(including the rename from #15502)

--
dependencies:  -Meta path finders and path entry finders are different, but 
share an ABC
resolution:  -> fixed

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


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

___
Python tracker 

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

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

[Nick Coghlan]

Nick Coghlan added the comment:

I also dealt with #15519

--

___
Python tracker 

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

[issue15534] xmlrpc escaping breaks on unicode \u043c

[STINNER Victor]

STINNER Victor added the comment:

Hum, it's a regression introduced by the super-optimized fastsearch. It is just 
a typo: _s => s. I renamed _s to ptr to avoid future confusion ;-)

--

For your information, str.find(), str.rfind(), str.index(), str.rindex() and 
str.replace() are now using memchr() and memrchr() to find a substring, even if 
the substring contains characters outside the ASCII (U+-U+007F) and latin1 
ranges (U+-U+00FF). memchr() and memrchr() are much faster than a dummy C 
loop, even if there are false positive.

--
keywords: +patch
nosy: +flox, haypo, loewis, pitrou
Added file: http://bugs.python.org/file26661/fastsearch.patch

___
Python tracker 

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

[issue15534] xmlrpc escaping breaks on unicode \u043c

[STINNER Victor]

Changes by STINNER Victor :


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

[issue15534] xmlrpc escaping breaks on unicode \u043c

[Antoine Pitrou]

Antoine Pitrou added the comment:

Ow, nice find.

--

___
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

[Roundup Robot]

Roundup Robot added the comment:

New changeset 1f8351cf00f3 by Nick Coghlan in branch 'default':
Issue #15502: Bring the importlib.PathFinder docs and docstring more in line 
with the new import system documentation, and fix various parts of the new docs 
that weren't quite right given PEP 420 or were otherwise a bit misleading. Also 
note the key terminology problem still being discussed in the issue
http://hg.python.org/cpython/rev/1f8351cf00f3

--

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

Antoine Pitrou added the comment:

> On my machine I have programs that simply do not have an option to
> ignore any directories thus causing some grief during testing.

What are those programs exactly? A buildbot should ideally have a lean system 
install that does not interfere with the tests running.

--

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

OK, that last commit (along with one I did earlier for the import statement) 
brought over all the fixes I was previously overly hasty in committing to 
Barry's importdocs branch.

I've decided I can live with "regular packages" as the term for initialised 
packages (especially given the drawn out arguments on import-sig with the 
namespace package PEPs). If it becomes an anachronism by the time 4.0 rolls 
around, well, so be it.

The last big issue to be resolved is the terminology conflict between 
importlib.PathFinder, "path importer" and "importer. I think the first thing to 
try there is a rename to "importlib.PathImportFinder" and "path import finder" 
to see how well it reads.

My current feeling is that the result will have to be pretty horrible to make 
changing the long standing definition of "importer" to look like a superior 
option :)

I'm busy for the next couple of days though, so this may not make beta2

--

___
Python tracker 

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

[issue15535] Fix pickling of named tuples in 2.7.3

[Thomas Miedema]

New submission from Thomas Miedema:

Pickling a namedtuple Point(x=10, y=20, z=30) in Python 2.7.2 with protocol 
level 0 would result in something like the following output:

  ccopy_reg
  _reconstructor
  p0
  (c__main__
  Point
  p1
  c__builtin__
  tuple
  p2
  (I10
  I20
  I30
  tp3
  tp4
  Rp5
  .

In Python 2.7.3, the same namedtuple dumps to:

  ccopy_reg
  _reconstructor
  p0
  (c__main__
  Point
  p1
  c__builtin__
  tuple
  p2
  (I10
  I20
  I30
  tp3
  tp4
  Rp5
  ccollections
  OrderedDict
  p6
  ((lp7
  (lp8
  S'x'
  p9
  aI10
  aa(lp10
  S'y'
  p11
  aI20
  aa(lp12
  S'z'
  p13
  aI30
  aatp14
  Rp15
  b.

Note the OrderedDictionary at the end. All data, the field names and the 
values, are duplicated, which can result in very large pickled files when using 
nested namedtuples.

Loading both dumps with CPython 2.7.3 works. This is why this bug was not 
noticed any earlier. Loading the second dump with CPython or pypy 2.7.2 does 
not work however. CPython 2.7.3 broke forward compatibility.

Attached is a patch with a fix. The patch makes pickled namedtuples forward 
compatibile with 2.7.2. This patch does not break backward compability with 
2.7.3, since the extra OrderedDict data contained the same information as the 
tuple. 

Introduced:
http://hg.python.org/cpython/diff/26d5f022eb1a/Lib/collections.py

Also relevant:
http://bugs.python.org/issue3065

--
components: Library (Lib)
files: namedtuple_pickle_fix.patch
keywords: patch
messages: 167215
nosy: rhettinger, thomie
priority: normal
severity: normal
status: open
title: Fix pickling of named tuples in 2.7.3
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file26662/namedtuple_pickle_fix.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

[Barry A. Warsaw]

Barry A. Warsaw added the comment:

What about "Path Scanner"?  Came to me in a dream, so it has to be perfect,
right?  :)

--

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

> What are those programs exactly? A buildbot should ideally have a lean system 
> install that does not interfere with the tests running.

My development machine has add'l programs, not the buildbot machine.
Sorry is there was any confusion.  I get the same occasional access
denied errors when running the tests locally.

--

___
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 the ABCs, I'm okay with it as long as invalidate_caches() is meant to 
be a part of meta path finders.  I had considered this while writing the patch, 
so how I had it wasn't a fluke.  The fluke was that I didn't bring it up for 
discussion like I had meant to do.

 Anyway, my rationale was that importlib.invalidate_caches() is specific to 
path entry finders.  My patch reflected this.  If invalidates_caches() were 
meaningful for meta path finders then we could address that later without 
losing backward compatibility.

As to pulling find_module() off Finder, I felt that having a distinct 
signature, while semantically unimportant, made a clearer distinction between 
the old and the new.

--

___
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 02, 2012, at 11:33 AM, Nick Coghlan wrote:

>Specifically, what I did was to drop "find_module" from the Finder ABC, but
>keep the ABC itself as a way to document the common "invalidate_caches"
>API. The ABC definition no longer cares whether you implement find_module()
>or not. MetaPathFinder then enforces find_module(), while PathEntryFinder
>enforces find_loader().

One problem I have, which I'm not sure how to solve, is that the protocol
defines a couple of optional methods, specifically find_loader() on meta path
finders, and module_repr() on loaders.

You'd like for the ABC to be able to capture both the support of these methods
if they exist, and their optional nature, but I don't believe that's possible
with @abc.abstractmethod.  Correct me if I'm wrong, but by adding these
methods to the ABC, it requires subclasses to define them.  I noticed this
when I broke the test suite, and solved it by just adding the methods to the
mocks and other test classes.  But I think this is not the best solution.

Maybe we need an @abc.optionalabstractmethod decorator? ;)

--

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

> Tim Golden added the comment:
> I'm tentative about using ctypes this just because I don't believe we use it 
> anywhere else.

ctypes is already used later in test_support so I figured it was fine
to use for this as well.

--

___
Python tracker 

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

[issue15311] Dev Guide update hook broken

[Chris Jerdonek]

Chris Jerdonek added the comment:

Has this issue been resolved?  I saw that the following change is on the web 
site today:

http://hg.python.org/devguide/rev/851adff2d434

(though I didn't verify it immediately, just 6 hours after).

--

___
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 wonder why it couldn't use os.listdir to find out whether the directory is 
> empty, and os.stat to find out whether a specific file or directory still 
> exists.

It is possible to do the same thing with just os.listdir.  The use of
the Find*File functions was chosen to eliminate duplicating the wait
function for the two different cases.  Also,  it is just less resource
and time intensive to use the Find*File API directly (no need to build
an entire list when just testing if any entries exist).

--

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

Antoine Pitrou added the comment:

> > I wonder why it couldn't use os.listdir to find out whether the directory 
> > is empty, and os.stat to find out whether a specific file or directory 
> > still exists.
> 
> It is possible to do the same thing with just os.listdir.  The use of
> the Find*File functions was chosen to eliminate duplicating the wait
> function for the two different cases.  Also,  it is just less resource
> and time intensive to use the Find*File API directly (no need to build
> an entire list when just testing if any entries exist).

But it's certainly much easier to maintain using regular Python APIs. We
would use ctypes if the functionality wasn't accessible from pure
Python, but since it is, we don't want to reinvent the wheel.

--

___
Python tracker 

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

[issue15536] re.split doesn't respect MULTILINE

[Dave Abrahams]

New submission from Dave Abrahams:

This session demonstrates. See especially the very last expression evaluated

>>> s='''this is the end
s='''this is the end
... your only friend
your only friend
... the end'''
the end'''
>>> re.split('^', s, re.MULTILINE)
re.split('^', s, re.MULTILINE)
['this is the end\nyour only friend\nthe end']
>>> re.split('t', s, re.MULTILINE)
re.split('t', s, re.MULTILINE)
['', 'his is ', 'he end\nyour only friend\n', 'he end']
>>> re.split('\n', s, re.MULTILINE)
re.split('\n', s, re.MULTILINE)
['this is the end', 'your only friend', 'the end']
>>> re.split('(?<=\n)', s, re.MULTILINE)
re.split('(?<=\n)', s, re.MULTILINE)
['this is the end\nyour only friend\nthe end']
>>> re.split('^y', s, re.MULTILINE)
re.split('^y', s, re.MULTILINE)
['this is the end\nyour only friend\nthe end']
>>> re.split('$', s, re.MULTILINE)
re.split('$', s, re.MULTILINE)
['this is the end\nyour only friend\nthe end']
>>> re.split('$\n', s, re.MULTILINE)
re.split('$\n', s, re.MULTILINE)
['this is the end\nyour only friend\nthe end']
>>> re.split('\n', s, re.MULTILINE)
re.split('\n', s, re.MULTILINE)
['this is the end', 'your only friend', 'the end']
>>> re.split('^t', s, re.MULTILINE)
re.split('^t', s, re.MULTILINE)
['', 'his is the end\nyour only friend\nthe end']
>>> re.split('^t', s)
re.split('^t', s)
['', 'his is the end\nyour only friend\nthe end']
>>>

--
components: Regular Expressions
messages: 167224
nosy: dabrahams, ezio.melotti, mrabarnett
priority: normal
severity: normal
status: open
title: re.split doesn't respect MULTILINE
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

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

[Eric Snow]

Eric Snow added the comment:

I wish "path subsystem finder" weren't so long.  Then PathFinder would probably 
still be appropriate for the class name (as FileFinder is appropriate for 
FilePathEntryFinder :).

--

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

OK, here is another patch that uses just os.listdir

--
Added file: http://bugs.python.org/file26663/support.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:

> Maybe we need an @abc.optionalabstractmethod decorator?

Perhaps you are kidding, but I've had a similar thought on a number of 
occasions.  For kicks, I'll float this by python-ideas. :)

--

___
Python tracker 

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

[issue15537] MULTILINE confuses re.split

[Dave Abrahams]

New submission from Dave Abrahams:

compare the output of

$ python -c "open('/tmp/tst','w').write(100*'x\n');import re;print 
len(re.split('\n(?=x)', open('/tmp/tst').read()))"
100

with

$ python -c "open('/tmp/tst','w').write(100*'x\n');import re;print 
len(re.split('\n(?=x)', open('/tmp/tst').read(), re.MULTILINE))"
9

--
components: Regular Expressions
messages: 167228
nosy: dabrahams, ezio.melotti, mrabarnett
priority: normal
severity: normal
status: open
title: MULTILINE confuses re.split
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

[issue14873] Windows devguide: clarification for build errors due to missing optional dependencies

[Chris Jerdonek]

Chris Jerdonek added the comment:

I also think this would be worth a note.  May I propose a patch?

--
nosy: +cjerdonek

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

Well, really, the reason I'm deferring is to get the patch accepted, because it 
seems kind of unacceptable for standard library modules not to have full test 
coverage. So far, I don't see evidence that the issue has even been triaged. Of 
the three approaches, regex, cd, or decoration, which do you see as most likely 
to be accepted? I understand that cd might be common in some tests. But it also 
appears that, at least in test_filecmp, some pretty heinous practices are also 
common like piling a ridiculous number of asserts into one test method. (And 
I'll fix that, too.) I do really appreciate your advice, core developer or not. 
You are the only one providing advice here.

--

___
Python tracker 

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

[issue15311] Dev Guide update hook broken

[Ezio Melotti]

Ezio Melotti added the comment:

I think MvL fixed it.

--
nosy: +loewis

___
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

[Martin v . Löwis]

Martin v. Löwis added the comment:

I fail to see the point of not using os.stat. IIUC, Windows will delete the 
file once the last handle is been closed. Since stat will close any handle it 
temporarily gets, it will not prolong the live of the file; the file will still 
go away when the last process has closed it.

Performance is not an issue at all here, since we are waiting for the deletion 
of the file anyway. So checking whether the file is in the directory listing is 
fine with me as well. Unless someone can demonstrate how os.stat can prevent 
removal of the file, I'd like to see the comment corrected, though.

--

___
Python tracker 

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

[issue15538] Avoid nonstandard s6_addr8

[Philipp Hagemeister]

New submission from Philipp Hagemeister:

The s6_addr8 field of in6_addr structs is nonstandard, and therefore not 
supported on all platforms (android in my example). cpython's socket module 
should use the standard s6_addr field instead.

--
components: IO
hgrepos: 144
messages: 167233
nosy: phihag
priority: normal
severity: normal
status: open
title: Avoid nonstandard s6_addr8
type: compile error
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

___
Python tracker 

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

[issue15538] Avoid nonstandard s6_addr8

[Philipp Hagemeister]

Changes by Philipp Hagemeister :


--
keywords: +patch
Added file: http://bugs.python.org/file26664/issue15538.patch

___
Python tracker 

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

[issue15311] Dev Guide update hook broken

[Martin v . Löwis]

Martin v. Löwis added the comment:

I added an automated build process, yes. However, the current text is incorrect 
as it states that the build occurs immediately through a hook. 

This is not the case; instead, there is a cronjob that pulls changes. I refuse 
to report the frequency with which this happens, and advise against documenting 
the status quo, since that may again get outdated. It should be safe to say 
that changes should be published within a day.

--
priority: critical -> normal

___
Python tracker 

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

[issue15311] Dev Guide update procedure documentation in dev guide outdated

[Martin v . Löwis]

Changes by Martin v. Löwis :


--
title: Dev Guide update hook broken -> Dev Guide update procedure documentation 
in dev guide outdated

___
Python tracker 

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

[issue15538] Avoid nonstandard s6_addr8

[Martin v . Löwis]

Changes by Martin v. Löwis :


--
versions:  -Python 2.6, Python 3.1

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

In terms of invalidate_caches(), it could easily be changed to walk 
sys.meta_path and to call the method on the meta path finders. Not sure if that 
generalization is reasonable or not, though.

--

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

> Of the three approaches, regex, cd, or decoration, which do you see as most 
> likely to be accepted?

In my limited experience, I think the patch most likely to be accepted is the 
one that changes existing code the least. That would mean adding to the 
practices you're observing, unfortunately. Personally, I would go with trying 
to use test.support.temp_cwd() and doing an exact string match (since it 
provides a more precise test) -- taking appropriate cross-platform measures as 
necessary.

> I do really appreciate your advice, core developer or not. You are the only 
> one providing advice here.

You're welcome. I'm in the same boat as you, so I know how it feels.

--

___
Python tracker 

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

[issue15216] Support setting the encoding on a text stream after creation

[Atsuo Ishimoto]

Changes by Atsuo Ishimoto :


--
nosy: +ishimoto

___
Python tracker 

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

[issue15538] Avoid nonstandard s6_addr8

[Antoine Pitrou]

Antoine Pitrou added the comment:

Android doesn't have getaddrinfo()? getaddrinfo.c and getnameinfo.c only get 
compiled when the OS doesn't provide the same-named functions.

--
nosy: +pitrou
stage:  -> patch review

___
Python tracker 

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

[issue14905] zipimport.c needs to support namespace packages when no 'directory' entry exists

[Jonathan Paugh]

Changes by Jonathan Paugh :


--
nosy: +jpaugh

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

Not to detract from the fun  terminology discussion, but I have lingering 
concerns with the ABC inheritance model here.

Looking over changeset 184700df5b6a, I'm still fine with the change if 
invalidate_caches() is appropriate for both.  If not or if we don't know yet, I 
think we should hold off on moving invalidate_caches() up into Finder.  If it 
is okay then we should add meta path finder traversal to 
importlib.invalidate_caches().  Either way there's a (not substantial) loose 
end.

--

___
Python tracker 

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

[issue15539] Fixing Tools/scripts/pindent.py

[Serhiy Storchaka]

New submission from Serhiy Storchaka:

Here is a patch which fixes some bugs in Tools/scripts/pindent.py and 
modernizes it with regard to the new Python features abilities that have made 
since 1994.

1. Now pindent works with "with".
2. Now pindent does not produce improper indentation (tabs by default for 
space-indented file). It uses for the end-marks indentation the same sequence 
of whitespaces that for start operator indentation.
3. Now pindent works with escaped newline "\\\n" at start of line and after 
"class" and "def".
4. Now pindent does not produce indentation for empty line.
5. Fixed one type in help message.
6. Using io.StringIO.
7. Using booleans, augmented assignments, list.pop(), with operators, etc.

--
components: Demos and Tools
files: pindent.patch
keywords: patch
messages: 167239
nosy: storchaka
priority: normal
severity: normal
status: open
title: Fixing Tools/scripts/pindent.py
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file26665/pindent.patch

___
Python tracker 

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

[issue15537] MULTILINE confuses re.split

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

re.split = split(pattern, string, maxsplit=0, flags=0)
Split the source string by the occurrences of the pattern,
returning a list containing the resulting substrings.  If
capturing parentheses are used in pattern, then the text of all
groups in the pattern are also returned as part of the resulting
list.  If maxsplit is nonzero, at most maxsplit splits occur,
and the remainder of the string is returned as the final element
of the list.

maxsplit=0 in your fist example and maxsplit=8 (re.MULTILINE is 8) in your 
second example. This is not a bug, this is a wrong understanding.

--
nosy: +storchaka

___
Python tracker 

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

[issue15536] re.split doesn't respect MULTILINE

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Same as for issue 15537.

--
nosy: +storchaka

___
Python tracker 

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

[issue10731] UnicodeDecodeError in OS X tkinter when binding to

[Marc Culler]

Marc Culler added the comment:

Thanks, Ned!  It seems to be completely fixed by 8.5.12.

--
nosy: +Marc.Culler

___
Python tracker 

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

[issue15537] MULTILINE confuses re.split

[Matthew Barnett]

Matthew Barnett added the comment:

There are actually 2 issues here:

1. The third argument is 'maxsplit', the fourth is 'flags'.

2. It never splits on a zero-width match. See issue 3262.

--

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

I guess the question is how extensive do we want this cache validation to go? 
Do we think that only path entry finders stored in sys.path_importer_cache will 
have stuff to be cleared, or do we think stuff on sys.meta_path or 
sys.path_hooks will have things that need to get cleared as well? The more I 
think about it, the more I want to  generalize this to the point of 
sys.meta_path and then having PathFinder handle sys.path_hooks and 
sys.path_importer_cache. That stays in line with import not caring about 
sys.path, etc. and it really just being some cruft left over from Python 2.

Regardless, though, I would not define invalidate_caches() on Finder and 
instead define it separately on PathEntryFinder and MetaPathFinder. It's new in 
3.3 so it doesn't need to be on Finder for backwards-compatibility, and it 
isn't inherent to finders. Plus if Finder goes away we will have to push it up 
to the other ABCs anyway.

--

___
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 V. Smith]

Eric V. Smith added the comment:

I think the cache invalidation should be moved to the sys.meta_path level.

--

___
Python tracker 

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

[issue15538] Avoid nonstandard s6_addr8

[Roundup Robot]

Roundup Robot added the comment:

New changeset 86558ff7ce33 by Antoine Pitrou in branch '2.7':
Issue #15538: Fix compilation of the getnameinfo() / getaddrinfo() emulation 
code.
http://hg.python.org/cpython/rev/86558ff7ce33

New changeset 547f3a55a216 by Antoine Pitrou in branch '3.2':
Issue #15538: Fix compilation of the getnameinfo() / getaddrinfo() emulation 
code.
http://hg.python.org/cpython/rev/547f3a55a216

New changeset 61a56e982e98 by Antoine Pitrou in branch 'default':
Issue #15538: Fix compilation of the getnameinfo() / getaddrinfo() emulation 
code.
http://hg.python.org/cpython/rev/61a56e982e98

--
nosy: +python-dev

___
Python tracker 

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

[issue15538] Avoid nonstandard s6_addr8

[Antoine Pitrou]

Antoine Pitrou added the comment:

Ok, I couldn't test the patch as getipnodebyname / getipnodebyaddr don't exist 
here, but I committed it anyway. If it still doesn't work, please re-open the 
issue.

--
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
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

[issue14873] Windows devguide: clarification for build errors due to missing optional dependencies

[Chris Jerdonek]

Chris Jerdonek added the comment:

I am attaching a proposed patch for this issue.

I also did not know whether the errors were normal when building with Windows 
for the first time.

--
Added file: http://bugs.python.org/file2/issue-14873-1.patch

___
Python tracker 

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

[issue15311] Dev Guide update procedure documentation in dev guide outdated

[Chris Jerdonek]

Chris Jerdonek added the comment:

Attaching proposed wording along the lines Martin suggested.

--
keywords: +patch
Added file: http://bugs.python.org/file26667/issue-15311-2.patch

___
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

[STINNER Victor]

STINNER Victor added the comment:

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

I suppose that you mean "returns '1\n' instead of '1'". This is a
major change between Python 2 and Python 3. Use print(1, end=' ') if
you want the same behaviour. See:
http://docs.python.org/dev/whatsnew/3.0.html#print-is-a-function

You can also use the print() as a function in Python 2 using "from
__future__ import print_function":
http://docs.python.org/dev/whatsnew/2.6.html#pep-3105-print-as-a-function

I never liked "print expr," because it looks like a typo or an ugly
hack. It's easy to add a comma by mistake.

--

___
Python tracker 

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

[issue15295] Import machinery documentation

[Phillip J. Eby]

Phillip J. Eby added the comment:

Hope I'm not too late to the bikeshed painting party; just wanted to chip in 
with the suggestion of "self-contained package" for non-namespace packages.  
(i.e., a self-contained package is one that cannot be split across different 
sys.path entries due to its use of an __init__ module).

Also, technically, namespace portions do not only contribute subpackages; they 
can contribute modules as well.

Another point of possible confusion: meta finders and path finders are both 
described as "hooks", but this terminology seems in conflict with the use of 
"hook" as describing a callable on path_hooks.  Perhaps we could drop the term 
"hook" from this section, and retitle it "Import System Extensions" and say you 
can extend the system by writing meta finders and path entry finders.  This 
would let the term "hook" be the exclusive property of path_hooks, which is how 
you extend the import system to use your custom finders.

The statement about __path__ being a list is also out-of-date; as of PEP 420, 
it can be an immutable, iterable object.  Specification-wise, __path__ need 
only be a re-iterable object, and people reading its value must NOT assume that 
it's a list or even indexable.

The term "sys path finder" should also be replaced by "path entry finder".  The 
former term is both incorrect and misleading, as it both implies that such a 
finder actually searches sys.path, and that it is exclusive to sys.path.  Path 
entry finders are used to look for modules within a location specified by a 
"path entry" - a string found in sys.path or in a __path__ attribute.

The term "path importer" is also horribly confusing in context...  after some 
reflection, I suggest the following additional terminology changes:

1. Replace "meta path finder" with "import handler"
2. Replace "path importer" with "sys.path import handler"

Now we can say that you extend the import system by adding import handlers to 
sys.meta_path, and that one of the default handlers is the sys.path import 
handler, which processes imports using sys.path and module __path__ attributes.

The sys.path import handler can of course in turn be extended by adding path 
hooks to sys.path_hooks, which are used to create module finder objects for the 
path entry strings found in sys.path and module __path__ attributes.  A path 
hook must return a finder object, which implements similar methods to those of 
an import handler, but with some important differences.

Whew.  It's a bit of a mouthful, but I think that this set of terms would keep 
all the roles and functions clear, along with their relationships to one 
another.  In addition, I think it provides greater clarity as to which pieces 
you need to extend when, why, and how.

What do you think?

--
nosy: +pje

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

Good points, Brett.  While I still favor my posted patch, wouldn't Nick's 
commit still be okay (once invalidate_cache() is added appropriately)?  Or 
would it be confusing to people to have this "Finder" class that no one is 
actually supposed to use?

--

___
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 message: http://bugs.python.org/msg167252

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

Good points, Brett.  While I still favor my posted patch, wouldn't Nick's 
commit still be okay?  Or would it be confusing to people to have this "Finder" 
class that no one is actually supposed to use?

--

___
Python tracker 

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

[issue15534] xmlrpc escaping breaks on unicode \u043c

[Roundup Robot]

Roundup Robot added the comment:

New changeset 0e95b61af859 by Victor Stinner in branch 'default':
Close #15534: Fix a typo in the fast search function of the string library (_s 
=> s)
http://hg.python.org/cpython/rev/0e95b61af859

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

[issue15534] xmlrpc escaping breaks on unicode \u043c

[STINNER Victor]

STINNER Victor added the comment:

The issue should be fixed, thanks for the report!

--

___
Python tracker 

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

[issue15540] Python 3.3 and numpy

[Dave Malcolm]

New submission from Dave Malcolm:

I've been trying to get numpy working with Python 3.3, and to so I had to make 
some changes to CPython - hence I'm posting this to the Python bug tracker.

numpy pokes at the insides of PyUnicodeObject in a few places and is thus 
affected by the PEP 393 changes in Python 3.3

I'm attaching my latest work-in-progress patch for numpy, which mostly works 
(it has 3 remaining errors).

AIUI, the "numpy.str_" type subclasses PyUnicodeObject but with its own custom 
allocator, which takes a size (this is called in PyArray_Scalar when type_num 
== NPY_UNICODE).  unicode_new_subtype calls tp_alloc but passes in 0 for the 
size, so we can't use that.  So I had to reimplement parts of unicode creation 
in-place within numpy's PyArray_Scalar, copying macros from out of cpython's 
unicodeobject.c

The other wart is that, AIUI, numpy supports byte-swapping the values within an 
array, and when this is done for a unicode array, it byte-swaps the 4-byte UCS4 
values.  At that point, it's unlikely that the resulting 4-byte values are 
below 0x10, leading to various failures from inside CPython's unicode 
handling.

So I hacked those test from out of CPython :)   I'm attaching the diff I've got 
against cpython (clearly just a hack at this stage).

I may of course be misunderstanding the insides of numpy.

With these changes, the numpy test suite runs, with just these remaining errors:

==
ERROR: Ticket #16
--
Traceback (most recent call last):
  File 
"/home/david/coding/python3.3/local-install/lib/python3.3/site-packages/numpy/core/tests/test_regression.py",
 line 41, in test_pickle_transposed
b = pickle.load(f)
EOFError

==
ERROR: test_power_zero (test_umath.TestPower)
--
Traceback (most recent call last):
  File 
"/home/david/coding/python3.3/local-install/lib/python3.3/site-packages/numpy/core/tests/test_umath.py",
 line 139, in test_power_zero
assert_complex_equal(np.power(zero, 0+1j), cnan)
RuntimeWarning: invalid value encountered in power

==
ERROR: Failure: ValueError (can't handle version 187 of numpy.ndarray pickle)
--
Traceback (most recent call last):
  File 
"/home/david/coding/python3.3/local-install/lib/python3.3/site-packages/nose-1.1.2-py3.3.egg/nose/failure.py",
 line 37, in runTest
raise self.exc_class(self.exc_val).with_traceback(self.tb)
  File 
"/home/david/coding/python3.3/local-install/lib/python3.3/site-packages/nose-1.1.2-py3.3.egg/nose/loader.py",
 line 232, in generate
for test in g():
  File 
"/home/david/coding/python3.3/local-install/lib/python3.3/site-packages/numpy/lib/tests/test_format.py",
 line 429, in test_roundtrip
arr2 = roundtrip(arr)
  File 
"/home/david/coding/python3.3/local-install/lib/python3.3/site-packages/numpy/lib/tests/test_format.py",
 line 420, in roundtrip
arr2 = format.read_array(f2)
  File 
"/home/david/coding/python3.3/local-install/lib/python3.3/site-packages/numpy/lib/format.py",
 line 449, in read_array
array = pickle.load(fp)
ValueError: can't handle version 187 of numpy.ndarray pickle

--
Ran 4776 tests in 68.189s

FAILED (KNOWNFAIL=6, SKIP=1, errors=3)

--
components: Interpreter Core
files: get-numpy-working-with-python-3.3.patch
keywords: patch
messages: 167256
nosy: dmalcolm
priority: normal
severity: normal
status: open
title: Python 3.3 and numpy
versions: Python 3.3
Added file: 
http://bugs.python.org/file26668/get-numpy-working-with-python-3.3.patch

___
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

[STINNER Victor]

STINNER Victor added the comment:

> It would be nice to fix this before Python 3.3 final.

@Georg: So, what do you think?

--

___
Python tracker 

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

[issue15540] Python 3.3 and numpy

[Dave Malcolm]

Changes by Dave Malcolm :


Added file: 
http://bugs.python.org/file26669/hack-out-test-against-MAX_UNICODE-from-cpython-3.3.patch

___
Python tracker 

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

[issue15540] Python 3.3 and numpy

[Dave Malcolm]

Changes by Dave Malcolm :


--
nosy: +haypo, loewis

___
Python tracker 

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

[issue15540] Python 3.3 and numpy

[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

[issue15540] Python 3.3 and numpy

[Dave Malcolm]

Changes by Dave Malcolm :


--
nosy: +ncoghlan

___
Python tracker 

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

[issue15540] Python 3.3 and numpy

[Dave Malcolm]

Changes by Dave Malcolm :


--
nosy: +teoliphant

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

Nick's current patch is fine, although I would add back in invalidate_caches() 
into MetaPathFinder and PathEntryFinder where they do nothing but return 
NotImplemented as a form of no-op. I know you have a python-ideas discussion 
going about optional abstractmethod, but until that's settled I would rather 
have something there to document in code what is supported as part of the API.

--

___
Python tracker 

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

[issue15540] Python 3.3 and numpy

[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

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

[Brett Cannon]

Brett Cannon added the comment:

As for Finder containing nothing significant, that's a side-effect of the 
cleanup and why Finder should get deprecated, especially since the contract 
that a Finder implements find_module() is no longer being enforced. Tying 
MetaPathFinder and PathEntryFinder together because they are conceptually 
finders is just not useful from a programming perspective since their APIs have 
no overlap except for invalidate_caches(), which if generalized, is just 
happenstance and not by explicit design.

--

___
Python tracker 

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

[issue15541] logging.exception doesn't accept 'extra'

[Ned Batchelder]

New submission from Ned Batchelder:

The logging.exception method differs from .debug(), .info(), .warning(), 
.error() and .critical() in that it does not accept an `extra` keyword 
argument.  There seems to be no reason for this.

The docs are misleading about this. They say, "The arguments are interpreted as 
for debug()."

Changing exception() to this would take care of it::

def exception(self, msg, *args, **kwargs):
"""
Convenience method for logging an ERROR with exception information.
"""
kwargs['exc_info'] = 1
self.error(msg, *args, **kwargs)

--
components: Library (Lib)
messages: 167260
nosy: nedbat
priority: normal
severity: normal
status: open
title: logging.exception doesn't accept 'extra'
type: behavior
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

[issue15473] importlib no longer uses imp.NullImporter

[Brett Cannon]

Brett Cannon added the comment:

Did this get addressed in the final doc update?

--

___
Python tracker 

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

[issue15540] Python 3.3 and numpy

[Stefan Krah]

Stefan Krah added the comment:

A couple of days ago there was another effort by Ondřej Čertík to get
NumPy working with 3.3, see the thread starting here:

http://comments.gmane.org/gmane.comp.python.numeric.general/51087

I participated in that discussion and we hit the same problem with
the byte-swapped arrays: Since the generated Unicode strings are invalid,
the consistency checks fail in debug mode.

I wonder if taking out that assert is the right thing though: The
use case is pretty unique; could NumPy not convert these byte-swapped
arrays to uint32?

--
nosy: +skrah

___
Python tracker 

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

[issue15540] Python 3.3 and numpy

[Martin v . Löwis]

Martin v. Löwis added the comment:

The byte swapping in numpy is clearly a misfeature when applied to Unicode. I 
don't think Python should support that, and I can't imagine anybody is using 
this for a purpose that couldn't also be achieved in a better way. Not sure why 
you are submitting these patches here - consider this one rejected.

I'm also not sure why you posted the numpy patch here; we cannot process it in 
any meaningful way. If you just need to find a place in the web to post it, 
please use wiki.python.org.

In general, I'm (personally) quite opposed to using the tracker for 
work-in-progress. Tracker issues should be actionable by core committer 
(reject, commit, request further changes). If the author is aware that it is 
not ready for review yet, it shouldn't go into the tracker.

If you primarily wanted to report these incompatibilies: that's appreciated. I 
can add them to

http://www.python.org/dev/peps/pep-0393/#deprecations-removals-and-incompatibilities

I don't think anything can be done about this: any C extension type subclassing 
the Unicode type needs to be reviewed; I don't think any reasonable backwards 
compatibility can be applied. This is unfortunate, but without a good solution.

Likewise, code that mutates what is designed to be an immutable object is prone 
to break. I have no regrets about this breakage.

--

___
Python tracker 

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

[issue15295] Import machinery documentation

[Nick Coghlan]

Nick Coghlan added the comment:

We changed quite a bit already as we tried to make everything consistent,
including the importlib ABCs. Current version is on trunk, current
discussion is in #15502

--

___
Python tracker 

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

[issue15473] importlib no longer uses imp.NullImporter

[Nick Coghlan]

Nick Coghlan added the comment:

Barry covered it in a footnote

--

___
Python tracker 

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

[issue15403] Refactor package creation support code into a common location

[Chris Jerdonek]

Chris Jerdonek added the comment:

Attaching an updated patch.  Changes include:

1. Cleans up and expands support API to include creating nested directory 
structures (for use in the filecmp tests, for example).
2. Adds unit tests for the full API (similar to test_support.py).
3. Refactors test_filecmp and test_import to use the support code, in addition 
to test_runpy and test_cmd_line_script. We can remove some of these 
refactorings if you think it does not add much at this point.
4. Puts changes in package_helper.py for now (until issue 15494 is done). I 
didn't put them in script_helper.py to avoid creating a circular dependency.

--
Added file: http://bugs.python.org/file26670/issue-15403-2.patch

___
Python tracker 

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

[issue15542] Documentation incorrectly suggests __init__ called after direct __new__ call

[Aaron Staley]

New submission from Aaron Staley:

The documentation for __new__ at 
http://docs.python.org/reference/datamodel.html#object.__new__ is:
"""
object.__new__(cls[, ...])
Called to create a new instance of class cls. __new__() is a static method 
(special-cased so you need not declare it as such) that takes the class of 
which an instance was requested as its first argument. The remaining arguments 
are those passed to the object constructor expression (the call to the class). 
The return value of __new__() should be the new object instance (usually an 
instance of cls).

Typical implementations create a new instance of the class by invoking the 
superclass’s __new__() method using super(currentclass, cls).__new__(cls[, 
...]) with appropriate arguments and then modifying the newly-created instance 
as necessary before returning it.

If __new__() returns an instance of cls, then the new instance’s __init__() 
method will be invoked like __init__(self[, ...]), where self is the new 
instance and the remaining arguments are the same as were passed to __new__().

If __new__() does not return an instance of cls, then the new instance’s 
__init__() method will not be invoked.

__new__() is intended mainly to allow subclasses of immutable types (like int, 
str, or tuple) to customize instance creation. It is also commonly overridden 
in custom metaclasses in order to customize class creation.
"""


The problem is in this line: "If __new__() returns an instance of cls, then the 
new instance’s __init__() method will be invoked like __init__(self[, ...]), 
where self is the new instance and the remaining arguments are the same as were 
passed to __new__()."

This is only true in the context of a constructor. In particular, directly 
calling cls.__new__(cls) will NOT call __init__.

If I define a class:
  
class C(object):
  def __new__(*args, **kwargs):
print 'new', args, kwargs
return object.__new__(*args,**kwargs)
  def __init__(self):
print 'init'

C() will result in __new__ and __init__ being both executed, but C.__new__(C) 
will only create the instance of C; it will not call __init__!

The original documentation described in http://bugs.python.org/issue1123716 was 
more correct:

"__new__ must return an object... If you return an
existing object, the constructor call will still call
its __init__ method unless the object is an instance of
a different class..."

That is __init__ is only being called in the context of an external constructor 
call.  

Proposed phrasing:
"If __new__() is invoked during object construction (cls()) and it returns an 
instance of cls, then the new instance’s __init__() method will be invoked like 
__init__(self[, ...]), where self is the new instance and the remaining 
arguments are the same as were passed to the object constructor."

--
assignee: docs@python
components: Documentation
messages: 167267
nosy: Aaron.Staley, docs@python
priority: normal
severity: normal
status: open
title: Documentation incorrectly suggests __init__ called after direct  __new__ 
call
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

[issue15540] Python 3.3 and numpy

[Antoine Pitrou]

Antoine Pitrou added the comment:

Agreed with Martin. Byte-swapped unicode data in unicode objects doesn't make 
sense, since it will break the semantics of many operations. If numpy wants to 
support byte-swapped unicode data (what for?), they should store it in a 
different object type.

--
nosy: +pitrou

___
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

[Antoine Pitrou]

Antoine Pitrou added the comment:

About the patch: why wouldn't you use newline = NULL in both cases?

--

___
Python tracker 

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

[issue15542] Documentation incorrectly suggests __init__ called after direct __new__ call

[Chris Jerdonek]

Chris Jerdonek added the comment:

Whether or not the current language is technically correct, I would support 
improving its clarity.

Would you like to create a formal patch?  Also, note that the newest 
documentation is published here:

http://docs.python.org/dev/reference/datamodel.html#object.__new__

(Note that in the future, you do not need to post such full excerpts, just the 
key parts.)

--
nosy: +cjerdonek
stage:  -> needs patch
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

[issue15540] Python 3.3 and numpy

[Travis Oliphant]

Travis Oliphant added the comment:

On Aug 2, 2012, at 5:28 PM, Antoine Pitrou wrote:

> 
> Antoine Pitrou added the comment:
> 
> Agreed with Martin. Byte-swapped unicode data in unicode objects doesn't make 
> sense, since it will break the semantics of many operations. If numpy wants 
> to support byte-swapped unicode data (what for?), they should store it in a 
> different object type.

This is a mis-understanding of what NumPy does and why.There is a need to 
byte-swap only when the data is stored on disk in the reverse order from the 
native machine (i.e. NumPy is pointing to memory-mapped data).

The byte-swapping must be done prior to conversion to a Python Unicode-Object 
when selecting data out of the array.   

-Travis

--

___
Python tracker 

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

[issue7317] Display full tracebacks when an error occurs asynchronously

[Antoine Pitrou]

Antoine Pitrou added the comment:

Oops, sorry for the silence, I had forgotten about this issue. I'll take a look 
at the patch soon.

--

___
Python tracker 

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

[issue7317] Display full tracebacks when an error occurs asynchronously

[Antoine Pitrou]

Antoine Pitrou added the comment:

Oops, sorry for the silence, I had forgotten about this issue. I'll take a look 
at the patch soon.

--

___
Python tracker 

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

[issue7317] Display full tracebacks when an error occurs asynchronously

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
Removed message: http://bugs.python.org/msg167273

___
Python tracker 

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

[issue15540] Python 3.3 and numpy

[Antoine Pitrou]

Antoine Pitrou added the comment:

> The byte-swapping must be done prior to conversion to a Python
> Unicode-Object when selecting data out of the array.

But then it shouldn't affect the invariants which are commented out in
Dave's patch.

--

___
Python tracker 

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

[issue15540] Python 3.3 and numpy

[Stefan Krah]

Stefan Krah added the comment:

> There is a need to byte-swap only when the data is stored on disk in the 
> reverse order from the native machine (i.e. NumPy is pointing to 
> memory-mapped data).

In that case it should be a matter of disabling some NumPy unit tests.
It seems that currently generating a Unicode object with non-native
byte-order is being tested, hence the reported failures.

--

___
Python tracker 

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

[issue15540] Python 3.3 and numpy

[Stefan Krah]

Changes by Stefan Krah :


--
nosy: +certik

___
Python tracker 

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

[issue15540] Python 3.3 and numpy

[Travis Oliphant]

Travis Oliphant added the comment:

On Aug 2, 2012, at 6:09 PM, Antoine Pitrou wrote:

> 
> Antoine Pitrou added the comment:
> 
>> The byte-swapping must be done prior to conversion to a Python
>> Unicode-Object when selecting data out of the array.
> 
> But then it shouldn't affect the invariants which are commented out in
> Dave's patch.
> 

My impression is that Python should not have to change anything, but NumPy 
needs to adapt to the new Unicode concepts (which I think are great, by the way 
--- I'm a big supporter of getting rid of the wide/narrow build distinction). 

> --
> 
> ___
> Python tracker 
> 
> ___

--

___
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

[Phillip J. Eby]

Phillip J. Eby added the comment:

Per Nick's request that I redirect this here instead of #15295...  
(w/already-fixed things deleted):

Hope I'm not too late to the bikeshed painting party; just wanted to chip in 
with the suggestion of "self-contained package" for non-namespace packages.  
(i.e., a self-contained package is one that cannot be split across different 
sys.path entries due to its use of an __init__ module).

Also, technically, namespace portions do not only contribute subpackages; they 
can contribute modules as well.  (The trunk doc says they contribute 
subpackages ATM.)

Another point of possible confusion: meta finders and path finders are both 
described as "hooks", but this terminology seems in conflict with the use of 
"hook" as describing a callable on path_hooks.  Perhaps we could drop the term 
"hook" from this section, and retitle it "Import System Extensions" and say you 
can extend the system by writing meta finders and path entry finders.  This 
would let the term "hook" be the exclusive property of path_hooks, which is how 
you extend the import system to use your custom finders.

With respect to the current discussion about "importer", "handler", "finder", 
etc., I'd like to propose a slight tweak that I think can clear up the 
remaining confusing points:

1. Replace "meta path finder" with "import handler"
2. Replace "path finder" with "sys.path import handler"

Rationale:

Despite the similarity in interface between the two types of finders, they 
perform different sorts of functions.  A object in sys.meta_path can (and MUST) 
implement a broad module-finding policy, whereas a path entry finder is much 
more limited in scope - it only gets to override later path entry finders, and 
can't, for example, decide to use some other sort of __path__ attribute.  

(I'm not married to the term "handler" here, either - I just think "importer" 
is too generic, "finder" conflates with the more-commonly used kind of finder.  
"Policy" could be another possibility.  Both imply a broader scope of 
responsibility than "finder", and don't impinge on the special meaning of 
"importer".)

With a bigger distinction drawn between these two types of finders, we can say 
that you...

"""Extend the import system by adding "import handlers" to sys.meta_path, and 
that one of the default handlers is the "sys.path import handler", which 
processes imports using sys.path and module __path__ attributes.

The sys.path import handler can of course in turn be extended by adding "path 
hooks" to sys.path_hooks, which are then used to create "module finder" objects 
for the path entry strings found in sys.path and module __path__ attributes.  A 
path hook must return a finder object, which implements similar methods to 
those of an import handler, but with some important differences.
"""

Of course, if you make that "sys.path import policy" instead of "sys.path 
import handler", it still works.

Thoughts?

--
nosy: +pje

___
Python tracker 

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

[issue15540] Python 3.3 and numpy

[Nick Coghlan]

Nick Coghlan added the comment:

While I agree this is important (e.g. I know Dave started looking into this as 
getting NumPy working is currently a blocker for Fedora migrating their Python 
3 stack to 3.3), the burden is definitely on the NumPy side to get the code 
point values using the right byte order before handing them over to the CPython 
API. If the sanity checks in the Unicode implementation are firing, it means 
something is still wrong on the NumPy side (perhaps erroneous unit tests, as 
Stefan reports).

>From the point of view of CPython, an array of byte-swapped code points isn't 
>text, it's an array of 16 or 32 bit integers, and NumPy's text handling needs 
>to work within that constraint.

FWIW, with regard to Martin's tangential comment about appropriate use of the 
tracker, I'm personally fine with using the tracker for 'I found this problem, 
attempted to fix it (but failed), here's my attempt'. It's part of the wide 
spectrum of issue reporting that ranges from 'I found this problem, but have no 
idea what is causing it or where to even begin trying to fix it' through 'I 
found this problem, here's a fix that worked for me' all the way to 'I found 
this problem, here's a fix that works on multiple platforms with new tests, 
insightful doc adjustments and a pony' :)

--
resolution:  -> invalid
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

[issue15543] central documentation for 'universal newlines'

[Chris Jerdonek]

New submission from Chris Jerdonek:

"Universal newlines" of PEP 278 does not seem to have a central, linkable 
description within the documentation.  In particular, there does not seem to be 
a glossary entry or any index entries for it.

The main documentation seems to be in the middle of the documentation for the 
open() built-in function:

http://docs.python.org/dev/library/functions.html?highlight=open#open

But this does not feature prominently when searching for universal newlines in 
the "Quick Search".

This would allow us, for example, to reference and link to an explanation of 
universal newlines in the documentation for str.splitlines():

http://docs.python.org/dev/library/stdtypes.html#str.splitlines

I would be happy to provide a patch.

--
assignee: docs@python
components: Documentation
keywords: easy
messages: 167279
nosy: cjerdonek, docs@python
priority: normal
severity: normal
status: open
title: central documentation for 'universal newlines'
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

[issue15540] Python 3.3 and numpy

[Ondrej Certik]

Ondrej Certik added the comment:

I wrote this initial patch for the issue last week:

https://github.com/numpy/numpy/pull/366

with huge help from Stefan and others.

As far as the unicode issue goes, Travis and I just talked about this and I 
think I now understand what is going on  the unicode type itself (as 
returned by the PyArray_Scalar() function in NumPy) should *never* have the 
byte swapped internals.

In other words, the usage of the byte swapping is that if numpy happens to be 
pointing to a memory with byte swapped data (for example you save some data on 
big endian and you load it on little endian), let's say you have some strings 
(unicode). They will always be UCS4 inside numpy, possibly swapped. When the 
user actually calls things like my_array[1], then the PyArray_Scalar() looks at 
the memory, does any swapping (if necessary) and returns a valid unicode object 
on the current platform (with the correct endianness). The returned unicode can 
have any length (UCS1, UCS2 or UCS4 -- whatever Python likes), that doesn't 
really matter.

So no changes are necessary to Python itself. As far as NumPy goes -- the tests 
are obviously wrong, because they happen to create unicode that is invalid. So 
the NumPy tests need to be fixed.

Otherwise there is no problem. I am now working on a better version of my 
patch, that doesn't need to be forcing the unicode to be UCS4 so that it can 
swap its contents.

--

___
Python tracker 

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