[issue15246] Line coverage for collectionts.abc.Set

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
nosy: +rhettinger, stutzbach
stage:  -> patch review

___
Python tracker 

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

[issue10574] email.header.decode_header fails if the string contains multiple directives

[Roy Hyunjin Han]

Roy Hyunjin Han  added the comment:

> This is fixed by the fix to issue 1079, but we have decided that fix can't be 
> backported because it is a behavior change that might break existing working 
> programs.

Thanks for this update.

--

___
Python tracker 

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

[issue15249] email.generator.BytesGenerator doesn't mangle "From " lines when non-ASCII bytes are present

[Petri Lehtinen]

New submission from Petri Lehtinen :

The _handle_text function of BytesGenerator writes the payload straight through 
if there surrogateescape sequences are present, and skips the "From " mangling.

--
components: email
messages: 164641
nosy: barry, petri.lehtinen, r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: email.generator.BytesGenerator doesn't mangle "From " lines when 
non-ASCII bytes are present
versions: Python 3.2, Python 3.3

___
Python tracker 

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

[issue15246] Line coverage for collectionts.abc.Set

[Mark Dickinson]

Mark Dickinson  added the comment:

Can you attach the failing tests for __and__?

--
nosy: +mark.dickinson

___
Python tracker 

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

[issue15205] distutils dereferences symlinks on Mac OS X but not on Linux

[Ollie Walsh]

Ollie Walsh  added the comment:

Hi,

> As I said in the other bug, symlinks handling in not fully specified

Yes. I've mostly submitted a bug report in case anybody else encounters the 
problem.

> At present I am not sure if having symlinks in a distribution makes sense

I agree.
In my case symlinks are being used to restructure a large legacy module into 
smaller packages. When creating sdists the symlinks are dereferenced on another 
developer's host (OSX) and all is well but they on my host (Linux) I get 
packages with broken symlinks.

> BTW the example you link to is not at all monkey-patching

My mistake. When I worked around this issue I did monkey-patch sdist. I also 
just wrapped the source path is os.path.readlink() before hardlinking. I think 
the approach in that link is a much better solution so I have referred to it 
instead.

-Ollie

--

___
Python tracker 

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

[issue15205] distutils dereferences symlinks on Mac OS X but not on Linux

[Ollie Walsh]

Ollie Walsh  added the comment:

PS that should be os.readlink()

--

___
Python tracker 

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

[issue15210] importlib.__init__ checks for the wrong exception when looking for _frozen_importlib

[Brett Cannon]

Brett Cannon  added the comment:

Thanks for the diagnosis, Stefan. Unfortunately that line is the crux of the 
test. =) I will see if I can steal some time to look at the failure to see if 
there is anything obvious going on.

--

___
Python tracker 

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

[issue15250] document that filecmp.dircmp comparisons are "shallow"

[Chris Jerdonek]

New submission from Chris Jerdonek :

The documentation for the dircmp class doesn't say that the same_files and 
diff_files attributes are determined using the "shallow=True" rules described 
in the filecmp.cmp() and filecmp.cmpfiles().  It should say this.

For example, the documentation describes diff_files as, "Files which are in 
both a and b, whose contents differ."  But this isn't true since files whose 
contents differ aren't included if their os.stat() signatures are equal.

See also issue 12932 to allow dircmp to perform non-shallow comparisons.

--
assignee: docs@python
components: Documentation
keywords: easy
messages: 164646
nosy: cjerdonek, docs@python
priority: normal
severity: normal
status: open
title: document that filecmp.dircmp comparisons are "shallow"
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

[issue15139] Speed up threading.Condition wakeup

[Matt Joiner]

Matt Joiner  added the comment:

Did this make it into 3.3?

--
nosy: +anacrolix

___
Python tracker 

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

[issue12932] filecmp.dircmp does not allow non-shallow comparisons

[Chris Jerdonek]

Chris Jerdonek  added the comment:

+1 for this.

Whether or not this feature is implemented, I think the documentation should 
state that directory comparisons are done using "shallow=True".  I created 
issue 15250 for this.

--
nosy: +cjerdonek

___
Python tracker 

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

[issue15245] ast.literal_eval fails on some literals

[Mark Dickinson]

Changes by Mark Dickinson :


--
nosy: +mark.dickinson

___
Python tracker 

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

[issue15210] importlib.__init__ checks for the wrong exception when looking for _frozen_importlib

[Chris Jerdonek]

Chris Jerdonek  added the comment:

I could be way off (just passing through), but the test flakiness described 
here seems reminiscent of a discussion we had for issue 7559.  There the 
solution to order-dependent tests with importlib involved calling 
importlib.invalidate_caches() at the appropriate time.

--
nosy: +cjerdonek

___
Python tracker 

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

[issue15139] Speed up threading.Condition wakeup

[Gregory P. Smith]

Gregory P. Smith  added the comment:

Nope.

--

___
Python tracker 

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

[issue15245] ast.literal_eval fails on some literals

[Daniel Urban]

Daniel Urban  added the comment:

eval(repr(float('nan'))) doesn't work either, so I'm not sure ast.literal_eval 
should. The same with float('inf').

--
nosy: +daniel.urban

___
Python tracker 

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

[issue15251] new.code and new.function crashes Python iterpretter

[Jeffrey Harper]

New submission from Jeffrey Harper :

I've attached a script that crashes the Python interpreter.  

I can get the crash to occur under Windows Vista with this version of Python:

C:\tmp\remote>c:\Python27\python.exe
Python 2.7.1 Stackless 3.1b3 060516 (release27-maint, Jan  1 2011, 13:04:37) 
[MSC v.1500 32 bit (Intel)] on win32

Also, I got it to segfault under Ubuntu Linux:

jharper@ubuntu:~$ uname -a
Linux ubuntu 2.6.35-27-generic #48-Ubuntu SMP Tue Feb 22 20:25:29 UTC 2011 i686 
GNU/Linux
jharper@ubuntu:~$ python
Python 2.6.6 (r266:84292, Sep 15 2010, 15:52:39) 
[GCC 4.4.5] on linux2

Note, when I commented out the line, "pprint(code_args)", the script generated 
a SystemError exception instead of crashing.

--
components: Library (Lib)
files: bug3.py
messages: 164652
nosy: jeffdharper
priority: normal
severity: normal
status: open
title: new.code and new.function crashes Python iterpretter
type: crash
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file26257/bug3.py

___
Python tracker 

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

[issue15251] new.code and new.function crashes Python iterpretter

[Jeffrey Harper]

Jeffrey Harper  added the comment:

The marshal loads and dumps don't seem to be necessary to reproduce the crash.  
On both the Windows Vista and Ubuntu Linux systems, the crash still occurred 
when I replaced:

mcopy_code = loads(dumps(code))

with:

mcopy_code = code #loads(dumps(code))

--

___
Python tracker 

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

[issue15251] new.code and new.function crashes Python iterpretter

[Martin v . Löwis]

Martin v. Löwis  added the comment:

You need to pass co_freevars and co_cellvars as well for your example to work. 
It shouldn't crash, but I don't consider this particular crash as a bug, as it 
is a known limitation that new.code doesn't perform all consistency checks that 
are necessary to guarantee that the function execution doesn't crash the 
interpreter.

It certainly can't be fixed in 2.6.

--
nosy: +loewis
versions:  -Python 2.6

___
Python tracker 

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

[issue15247] io.open() is inconsistent re os.open()

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Good catch indeed.

--
components: +IO
nosy: +pitrou
stage:  -> needs patch
versions: +Python 3.2

___
Python tracker 

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

[issue15210] importlib.__init__ checks for the wrong exception when looking for _frozen_importlib

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 906c69928049 by Brett Cannon in branch 'default':
Issue #15210: Greatly simplify the test for supporting importlib
http://hg.python.org/cpython/rev/906c69928049

--

___
Python tracker 

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

[issue15210] importlib.__init__ checks for the wrong exception when looking for _frozen_importlib

[Brett Cannon]

Brett Cannon  added the comment:

I realized the problem was that _frozen_importlib was getting set to None, 
which won't trigger an exception since the code was just directly accessing 
sys.modules. I switched to an ``import ... as ...`` clause and moved to using 
test.support.import_fresh_module() and that seemed to fix the problem.

--
status: open -> closed

___
Python tracker 

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

[issue15245] ast.literal_eval fails on some literals

[João Bernardo]

João Bernardo  added the comment:

That's what I said by `nan` and `inf` are not literals, but their 
representations look like they should be.

One solution could be to add another argument to allow some extra names. Maybe 
a mapping, as `eval`.

--

___
Python tracker 

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

[issue15210] importlib.__init__ checks for the wrong exception when looking for _frozen_importlib

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Thanks Brett!

--

___
Python tracker 

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

[issue3561] Windows installer should add Python and Scripts directories to the PATH environment variable

[Jason Spiro]

Jason Spiro  added the comment:

I'm glad you're willing to consider using a checkbox.  It seems to fit
better with the wizard paradigm, where there are always [ < Back ], [
Next > ], and [ Cancel ] buttons onscreen.

OK, I acknowledge that a lot of third-party software still depends on
Python 2.  Fine.  Why not modify the Python 3 installer to add Python
3 to the *end* of the PATH variable, not the beginning?  Then I think
you could safely modify the PATH variable by default.

--

___
Python tracker 

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

[issue3561] Windows installer should add Python and Scripts directories to the PATH environment variable

[Brian Curtin]

Brian Curtin  added the comment:

We don't need to stay with some paradigm if it's not the best way. If I can get 
any of these ways to work, I may post some type of survey on python-dev.

Adding to the end wouldn't make this much of a feature. Most users have already 
put another Python into their path, so if they decide they want to add 3.3 to 
it, this option barely helps them.

Anyway, just about everything relating to this feature has been discussed on 
the above mentioned lists over a long period of time. The feature is 
implemented as is, it has already been released, and it's staying that way for 
3.3. All we can do is tweak the GUI.

--

___
Python tracker 

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

[issue3561] Windows installer should add Python and Scripts directories to the PATH environment variable

[Jason Spiro]

Jason Spiro  added the comment:

Adding Python to the end of the PATH would very much help Windows
non-experts who don't even know what a PATH is.

IMO, when Python 3.4 comes out, it'd make sense add Python to the end
of the PATH by default.  This'd help those non-experts a lot.

On 7/4/12, Brian Curtin  wrote:
>
> Brian Curtin  added the comment:
>
> We don't need to stay with some paradigm if it's not the best way. If I can
> get any of these ways to work, I may post some type of survey on
> python-dev.
>
> Adding to the end wouldn't make this much of a feature. Most users have
> already put another Python into their path, so if they decide they want to
> add 3.3 to it, this option barely helps them.
>
> Anyway, just about everything relating to this feature has been discussed on
> the above mentioned lists over a long period of time. The feature is
> implemented as is, it has already been released, and it's staying that way
> for 3.3. All we can do is tweak the GUI.
>
> --
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

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

[issue15251] new.code and new.function crashes Python iterpretter

[Jeffrey Harper]

Jeffrey Harper  added the comment:

Martin,

Thanks for your response.  I didn't know it was possible to pass freevars and 
cellvars to new.code.  I think the documentation needs to be updated.  The 
documentation for 2.7.3 located at 
http://docs.python.org/library/new.html?highlight=new#new.code is as follows:

new.code(argcount, nlocals, stacksize, flags, codestring, constants, names, 
varnames, filename, name, firstlineno, lnotab)

After I got your reply to this bug report I did help(new.code) and I see that 
it includes freevars and cellvars as optional arguments.

--
assignee:  -> docs@python
components: +Documentation -Library (Lib)
nosy: +docs@python

___
Python tracker 

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

[issue15247] io.open() is inconsistent re os.open()

[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

[issue15247] io.open() is inconsistent re os.open()

[Juancarlo Añez]

Juancarlo Añez  added the comment:

Note that attempting subsequent operations on the returned object do raise 
IsADirectoryError.


>>> import io
>>> import os
>>> d = io.open(os.open('.',0))
>>> d.read()
Traceback (most recent call last):
  File "", line 1, in 
IsADirectoryError: [Errno 21] Is a directory
>>>

--

___
Python tracker 

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

[issue15033] Different exit status when using -m

[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

[issue15020] default value for progname in pythonrun.c should be python3 for Python 3

[Arfrever Frehtes Taifersar Arahesis]

Arfrever Frehtes Taifersar Arahesis  added the comment:

Maybe it would be better to use L"python3.2" for Python 3.2 and L"python3.3" 
for Python 3.3.

--
nosy: +Arfrever

___
Python tracker 

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

[issue15242] PyImport_GetMagicTag() should use the same const char * as sys.implementation.cache_tag

[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

[issue15245] ast.literal_eval fails on some literals

[Benjamin Peterson]

Benjamin Peterson  added the comment:

I don't think literal_eval should handle anything which is not syntax.

--

___
Python tracker 

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

[issue15033] Different exit status when using -m

[Roundup Robot]

Roundup Robot  added the comment:

New changeset fcbd3bda7c0f by Senthil Kumaran in branch '3.2':
Fix issue # 15033 - Return the proper exitcode for failure when modules are 
invoked using -m switch. Patch contributed by Jeff Knupp
http://hg.python.org/cpython/rev/fcbd3bda7c0f

New changeset 1186d68715cc by Senthil Kumaran in branch 'default':
Fix issue # 15033 - Return the proper exitcode for failure when modules are 
invoked using -m switch. Patch contributed by Jeff Knupp
http://hg.python.org/cpython/rev/1186d68715cc

--
nosy: +python-dev

___
Python tracker 

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

[issue15033] Different exit status when using -m

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 55b3de6d701e by Senthil Kumaran in branch '2.7':
Fix closes issue # 15033 - Return the proper exitcode for failure when modules 
are invoked using -m switch. Patch contributed by Jeff Knupp
http://hg.python.org/cpython/rev/55b3de6d701e

--

___
Python tracker 

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

[issue15033] Different exit status when using -m

[Senthil Kumaran]

Senthil Kumaran  added the comment:

Thanks for the patch Jeff and thanks for the guidance, Nick. 
Committed this in all branches.

--
nosy: +orsenthil
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

[issue15250] document that filecmp.dircmp comparisons are "shallow"

[Éric Araujo]

Changes by Éric Araujo :


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

[issue12535] Chained tracebacks are confusing because the first traceback is minimal

[Nick Coghlan]

Nick Coghlan  added the comment:

I've thought of a different approach to this which should be less hazardous to 
doctests: include the truncation warning in the *traceback* section, rather 
than in the header. doctests already ignore the details of that section because 
checking it is too fragile.

cc'ing Georg because I think this a potentially big win for the usability of 
chained tracebacks, but also think it is dubious from a feature vs fix point of 
view.

With the change I'm considering, truncated tracebacks would look something like:

Traceback (most recent call last):
  
  File "/home/rdmurray/python/email6/Lib/email/message.py", line 466, in 
__getattr__
return getattr(self._headers, key)
AttributeError: '_Header_List' object has no attribute 'header_factory'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "", line 1, in 
  File "/home/rdmurray/python/email6/Lib/mailbox.py", line 1631, in set_flags
self.replace_header('Status', status_flags)
  File "/home/rdmurray/python/email6/Lib/email/message.py", line 495, in 
replace_header
print('rep', self.header_factory)
  File "/home/rdmurray/python/email6/Lib/email/message.py", line 469, in 
__getattr__
self.__class__.__name__, key))
AttributeError: 'mboxMessage' object has no attribute 'header_factory'

--
nosy: +georg.brandl

___
Python tracker 

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

[issue15249] email.generator.BytesGenerator doesn't mangle "From " lines when non-ASCII bytes are present

[Petri Lehtinen]

Petri Lehtinen  added the comment:

Attached a test case that fails.

--
keywords: +patch
Added file: http://bugs.python.org/file26258/issue115249_test.patch

___
Python tracker 

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

[issue15222] mailbox.mbox writes without empty line after each message

[Petri Lehtinen]

Petri Lehtinen  added the comment:

Well, by appending newmail to the mailbox, you effectively break the 
next-to-last message by not inserting a newline after it. This can also be 
achieved by adding a message that doesn't end in a newline to the mbox (using 
the mailbox module).

The real bug is that mailbox doesn't insert an empty line after each message, 
which it should do even if the message doesn't end in a newline. This breaks 
appending new messages (either by cat message >> mbox or by mailbox.py itself), 
and it might also break mbox parsing in other programs that search for starts 
of messages using "\n\nFrom ".

--
components: +email
nosy: +barry, r.david.murray

___
Python tracker 

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