[issue13876] Sporadic failure in test_socket

[Nadeem Vawda]

Nadeem Vawda  added the comment:

Merging nosy list from duplicate issue 15155.

--
nosy: +giampaolo.rodola, neologix, pitrou

___
Python tracker 

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

[issue15199] Default mimetype for javascript should be application/javascript

[Bohuslav "Slavek" Kabrda]

New submission from Bohuslav "Slavek" Kabrda :

Hi,
when using Python's Lib/mimetypes.py and none of the default files is present, 
there are some defaults used. For javascript, the default is 
application/x-javascript. However, according to IANA specification [1], this is 
not a registered type, and application/javascript should be used (see section 
7).
I'm attaching a simple patch that fixes this.


[1] http://www.rfc-editor.org/rfc/rfc4329.txt

--
components: Library (Lib)
files: python-correct-default-js-mimetype.patch
keywords: patch
messages: 164126
nosy: bkabrda
priority: normal
severity: normal
status: open
title: Default mimetype for javascript should be application/javascript
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3
Added file: 
http://bugs.python.org/file26174/python-correct-default-js-mimetype.patch

___
Python tracker 

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

[issue15200] Faster os.walk

[Serhiy Storchaka]

New submission from Serhiy Storchaka :

Using os.fwalk (if it is available) we can make os.walk more fast.

Microbenchmark:
./python -m timeit -s "from os import walk"  "for x in walk('Lib'): pass"

Results:
Vanilla: 112 msec
Patched: 90.5 msec

--
components: Library (Lib)
files: faster_walk.patch
keywords: patch
messages: 164127
nosy: storchaka
priority: normal
severity: normal
status: open
title: Faster os.walk
type: performance
versions: Python 3.4
Added file: http://bugs.python.org/file26175/faster_walk.patch

___
Python tracker 

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

[issue14899] Naming conventions and guidelines for packages and namespace packages

[Benoît Bryon]

Benoît Bryon  added the comment:

The proposal has been added to PEPs repository as PEP 423 :
http://hg.python.org/peps/rev/52767ab7e140

Review is about to be started at python-...@python.org.

To adapt the scope of this issue, in cpython documentation, I am to:

* remove the Doc/packaging/packagenames.rst document
* replace it by references to PEP 423

Obviously, this work requires that PEP 423 is accepted.

--

___
Python tracker 

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

[issue15201] C argument errors and Python arguments error are different

[Ramchandra Apte]

New submission from Ramchandra Apte :

C argument errors and Python arguments error are different.
For example:
all(4,4,4)
Traceback (most recent call last):
  File "", line 1, in 
TypeError: all() takes exactly one argument (3 given)
def func(a):pass
a(4,4)
Traceback (most recent call last):
  File "", line 1, in 
TypeError: func() takes exactly 1 positional argument (2 given)
I do not know which error message is better.
I think the second example's (func) error message is better.
Though feel free to vote by commenting on this bug.
Another example with not enough arguments given:
hasattr(4)
Traceback (most recent call last):
  File "", line 1, in 
TypeError: hasattr expected 2 arguments, got 1
func()
Traceback (most recent call last):
  File "", line 1, in 
TypeError: func() takes exactly 1 argument (0 given)
I don't know which of this error messages are better.
You can vote on this by commenting.

--
components: Interpreter Core
messages: 164129
nosy: ramchandra.apte
priority: normal
severity: normal
status: open
title: C argument errors and Python arguments error are different
type: behavior
versions: Python 3.2

___
Python tracker 

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

[issue15202] followlinks/follow_symlinks/symlinks flags unification.

[Serhiy Storchaka]

New submission from Serhiy Storchaka :

Now three different flag are used to denote the same behavior. followlinks is 
used in os.(f)walk, symlinks is used in shutil functions (with opposite 
meaning), and follow_symlinks is just added to many os functions. 
Unfortunately, symlinks, like followlinks, is used prior to 3.3. But 
follow_symlinks appeared only in 3.3 (besides, it's too long a name for this 
frequently used parameter) and it can be unified with one of the earlier 
spelling. Replacing follow_symlinks to followlinks is simpler than to symlinks.

--
components: Library (Lib)
files: followlinks.patch
keywords: patch
messages: 164130
nosy: storchaka
priority: normal
severity: normal
status: open
title: followlinks/follow_symlinks/symlinks flags unification.
Added file: http://bugs.python.org/file26176/followlinks.patch

___
Python tracker 

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

[issue15202] followlinks/follow_symlinks/symlinks flags unification

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
title: followlinks/follow_symlinks/symlinks flags unification. -> 
followlinks/follow_symlinks/symlinks flags unification

___
Python tracker 

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

[issue12971] os.isdir() should contain skiplinks=False in arguments

[Марк Коренберг]

Марк Коренберг  added the comment:

Отправлено с iPad

27.06.2012, в 6:03, Larry Hastings  написал(а):

No, follow symlinks is not the same. 

Skiplinks mean returning true or false depending on fact that last path element 
is symlink.
Checking If symlink appear in the middle of the path, this is not issue of this 
feature request. 

> 
> --
> nosy: +larry
> 
> ___
> Python tracker 
> 
> ___

--

___
Python tracker 

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

[issue15203] Accepting of os functions of (path, dir_fd) pair as argument

[Serhiy Storchaka]

New submission from Serhiy Storchaka :

Since many of os functions were polymorphic in its first argument (path or fd), 
the logical continuation is to add a (path, dir_fd) pair as yet one case of 
this argument. In any case dir_fd is incopatible with fd. This simplifies the 
code of certain functions which takes patch and dir_fd and pass them to lower 
level without changes, or that use same patch and dir_fd in calls of several 
functions. This freely adds support of dir_fd to many functions, such as 
os.path.isdir. This solves the problem of naming multiple dir_fd arguments 
(src_dir_fd/dst_dir_fd looks ugly). This saves a pre-3.3 signature of some 
functions, which will facilitate the use of decorators and improve 
compatibility with alternative implementations.

--
components: Library (Lib)
messages: 164132
nosy: storchaka
priority: normal
severity: normal
status: open
title: Accepting of os functions of (path, dir_fd) pair as argument
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

[issue1677] Ctrl-C will exit out of Python interpreter in Windows

[Tim Golden]

Tim Golden  added the comment:

Just to confirm: I can reproduce this more or less consistently on all versions 
of Python 2.2 -> 3.2 on Windows 7. Those are distribution builds -- ie not 
debug builds I've made myself. But it certainly does occur on a debug build of 
2.7.

I'm trying to narrow it down through some instrumentation (read: printf) on the 
2.7 branch. The MSDN page for signal warns that a separate thread will be 
created for the signal handler which will muddy the waters.

--
nosy: +tim.golden

___
Python tracker 

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

[issue15200] Faster os.walk

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
nosy: +larry

___
Python tracker 

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

[issue15202] followlinks/follow_symlinks/symlinks flags unification

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
nosy: +larry

___
Python tracker 

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

[issue15203] Accepting of os functions of (path, dir_fd) pair as argument

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
nosy: +larry

___
Python tracker 

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

[issue15202] followlinks/follow_symlinks/symlinks flags unification

[Hynek Schlawack]

Hynek Schlawack  added the comment:

Yeah, would be nice if that was consistent.

--
nosy: +hynek

___
Python tracker 

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

[issue15186] Support os.walk(dir_fd=)

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

> Your move, Serhiy ;-)

It seems that you play for both sides in the last days. ;-)  I surrender. 
Really, I'm not interested in this feature, but as of symmetry, and this is a 
very weak motive.

> p.s. Serhiy: yes, you can call os.fwalk() with dir_fd=None.  It would be 
> *awful* if you could not!  And actually, os.fwalk didn't even support dir_fd 
> until... 26 hours ago.

See issue15200.

--

___
Python tracker 

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

[issue15202] followlinks/follow_symlinks/symlinks flags unification

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


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

[issue15202] followlinks/follow_symlinks/symlinks flags unification

[Larry Hastings]

Larry Hastings  added the comment:

I assert that "followlinks" and "symlinks" are both bad names.  I dislike 
"followlinks" because "links" is ambiguous; both hard links and soft links are 
"links", but it's only modifying behavior regarding one of them.  Also, it's 
not PEP-8-compliant (which we can forgive because I'm pretty sure it predates 
PEP 8).  "symlinks" is far worse, because it's so ambiguous--quick, what does 
"symlinks=False" mean?  Examine symlinks, or follow them?

I agree that we can't rename "followlinks" and "symlinks" in 3.x.  All we can 
do for now is move forward.  At the same time I refused to be shackled by 
misguided old nomenclature.

So, certainly, I don't want to see "follow_symlinks" changed.  True story: the 
reason I started writing the patch for #14626 was so I could make sure it used 
the name "follow_symlinks".  I was dead certain Serhiy would use one of the 
existing names ;-)


If you really really want this to happen, you'll have to get Georg's 
permission--and the sooner the better.  Already I suspect it is too late.  If 
it ships in 3.3 it will absolutely be too late.


I suggest another approach: add a redundant "follow_symlinks" argument to 
os.walk, os.fwalk, and the shutil functions.  Prefer the new name in 
documentation but document the presence of the old one.  Throw an exception if 
both are specified in an invocation.  We could do that in 3.4.

--
nosy: +georg.brandl

___
Python tracker 

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

[issue15200] Faster os.walk

[Larry Hastings]

Larry Hastings  added the comment:

It's amusing that using fwalk and throwing away the last argument is faster 
than a handwritten implementation.  On the other hand, fwalk also uses a lot of 
file descriptors.  Users with processes which were already borderline on max 
file descriptors might not appreciate upgrading to find their os.walk calls 
suddenly failing.

Can you figure out why fwalk is faster, and apply that advantage to walk 
*without* consuming so many file descriptors?

No rush... :)

--

___
Python tracker 

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

[issue15203] Accepting of os functions of (path, dir_fd) pair as argument

[Larry Hastings]

Larry Hastings  added the comment:

I dislike this and always have.  I think it would look ugly and be obnoxious to 
use.

If you really think you can get this in for 3.3, you will have to bring it up 
with Georg.  I think your chances are about zero.

--

___
Python tracker 

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

[issue13876] Sporadic failure in test_socket

[Charles-François Natali]

Charles-François Natali  added the comment:

Looks like a kernel bug.
The only thing "non-standard" the test does is let the client call
close() before the server has called accept(), but this shouldn't
result in ENOTCONN - and doesn't for TCP sockets.

--

___
Python tracker 

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

[issue12971] os.isdir() should contain skiplinks=False in arguments

[Larry Hastings]

Larry Hastings  added the comment:

First: there's no chance this will go into 3.1, 3.2, or 3.3 at this point.

Second: I can assure you that switching to the l... version of a function and 
not following the last symlink is exactly what "follow_symlinks" is for.  
Please see the 3.3 documentation on follow_symlinks for more:

http://docs.python.org/3.3/library/os.html#follow-symlinks

Third: I think it's better to keep os.isdir() simple.  Users who want more 
sophisticated use cases (what to do about symlinks, using a dir_fd parameter) 
should use os.stat().  So I'm -1 on this.

TBH I'm not sure this even warrants a documentation change ("for more 
functionality, use os.stat()").

--
versions:  -Python 3.1, 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

[issue15200] Faster os.walk

[Charles-François Natali]

Charles-François Natali  added the comment:

> On the other hand, fwalk also uses a lot of file descriptors.  Users 
> with processes which were already borderline on max file descriptors 
> might not appreciate upgrading to find their os.walk calls suddenly 
> failing.

It doesn't have to.
Right now, it uses O(depth of the directory tree) FDs. It can be changed to 
only require O(1) FDs, see http://bugs.python.org/issue13734.
For example, GNU coreutils "rm -rf" uses *at() syscalls and only requires a 
constant number of FDs.

> Can you figure out why fwalk is faster, and apply that advantage to 
> walk *without* consuming so many file descriptors?

I didn't run any benchmark or test, but one reason why fwalk() is faster could 
be simply because it doesn't do as much path resolution - which is a somewhat 
expensive operation - thanks to the relative FD being passed.
I guess your mileage will vary with the FS in use, and the kernel version 
(there's been a lot of work to speed up path resolution by Nick Piggin during 
the last years or so).

Anyway, I think that such optimization is useless, because this micro-benchmark 
doesn't make much sense: when you walk a directory tree, it's usually to do 
something with the files/directories encountered, and as soon as you do 
something with them - stat(), unlink(), etc - the gain on the walking time will 
become negligible.

--
nosy: +neologix

___
Python tracker 

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

[issue15200] Faster os.walk

[Larry Hastings]

Larry Hastings  added the comment:

> It doesn't have to.
> Right now, it uses O(depth of the directory tree) FDs. 
> It can be changed to only require O(1) FDs

But closing and reopening those file descriptors seems like it might slow it 
down; would it still be a performance win?

Also, I'm not a security expert, but would the closing/reopening allow the 
possibility of timing attacks?  If so, that might still be okay for walk which 
makes no guarantees about safety.  (But obviously it would be unacceptable for 
fwalk.)


> Anyway, I think that such optimization is useless, because this
> micro-benchmark doesn't make much sense: when you walk a
> directory tree, it's usually to do something with the
> files/directories encountered, and as soon as you do something
> with them - stat(), unlink(), etc - the gain on the walking
> time will become negligible.

I'm not sure that "usually" is true here.  I suggest that "usually" people use 
os.walk to find *particular files* in a directory tree, generally by filename.  
So most of the time os.walk really is quickly iterating over directory trees 
doing very little.

I think 20% is a respectable gain, and it's hard for me to say "no" to 
functions that make Python faster for free.  (Well, for the possible cost of a 
slightly more expensive algorithm.)  So I'm +x for now.

--

___
Python tracker 

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

[issue15204] Deprecate the 'U' open mode

[Serhiy Storchaka]

New submission from Serhiy Storchaka :

Since Python 2.3 many open functions supports "Universal line mode" (PEP 278). 
Since 3.0 (and 2.6) PEP 3116 suggests better alternative -- io.TextWrapper.

Now support for the 'U' mode in the different open functions is heterogeneous. 
Some functions simply ignore the 'U' mode (but accept it), others perceive it 
as a synonym for text-mode, others just pass it on lower lever, other attempt 
to implement it, but the implementation is obtained imperfect and contradictory 
(as in ZipExtFile). The documentation for built-in open does not advise the use 
of the 'U' mode. The 'U' mode support cumbersome. I propose to deprecate the 
'U' mode. If someone wanted to work with the universal line support, he'll 
surely need to work with encodings too, and io.TextWrapper provides is better 
choise.

The deprecation plan for the 'U' mode of open functions might be as follow:

3.3.  Deprecating the 'U' mode in docs for all opens (building open, io.open, 
codecs.open, gzip.open, ZipFile.open, etc). Add suggestion about io.TextWrapper.
3.4.  Raise a warning on use of the 'U' mode.
3.5.  Raise an exception on use of the 'U' mode.
3.6 (or 4.0?).  Remove the 'U' mode processing code.

As the first stage involves only the changes to the documentation, I hope 
deprecation can starts in 3.3.

--
assignee: docs@python
components: Documentation, IO, Library (Lib)
messages: 164142
nosy: docs@python, storchaka
priority: normal
severity: normal
status: open
title: Deprecate the 'U' open mode
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

[issue15204] Deprecate the 'U' open mode

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
nosy: +gvanrossum, jackjansen, pitrou, stutzbach

___
Python tracker 

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

[issue15204] Deprecate the 'U' open mode

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

Related issues: #2091, #5148, #6759, #12900.

--

___
Python tracker 

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

[issue15204] Deprecate the 'U' open mode

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Starting to deprecate "U" in the 3.3 docs sounds reasonable to me.

--
nosy: +georg.brandl, nadeem.vawda

___
Python tracker 

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

[issue15202] followlinks/follow_symlinks/symlinks flags unification

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

> Also, it's not PEP-8-compliant (which we can forgive because I'm pretty sure 
> it predates PEP 8).

I don't see how this is contrary to PEP 8. PEP 8 says nothing about the
names of function arguments.

> Already I suspect it is too late.  If it ships in 3.3 it will
> absolutely be too late.

Unfortunately, too little time has passed between #14626 accepting and
shipping of 3.3b1. In any case, with accepted #14626 better than without
it.

> I suggest another approach: add a redundant "follow_symlinks" argument
> to os.walk, os.fwalk, and the shutil functions.

This is a bad solution, and I do not think that the benefits would
outweigh the disadvantages. I am -0.

--

___
Python tracker 

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

[issue15198] multiprocessing Pipe send of non-picklable objects doesn't raise error

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
nosy: +sbt

___
Python tracker 

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

[issue13241] llvm-gcc-4.2 miscompiles Python (XCode 4.1 on Mac OS 10.7)

[Anthony Kong]

Changes by Anthony Kong :


--
nosy: +Anthony.Kong

___
Python tracker 

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

[issue15202] followlinks/follow_symlinks/symlinks flags unification

[Larry Hastings]

Larry Hastings  added the comment:

> I don't see how this is contrary to PEP 8. PEP 8 says nothing about
> the names of function arguments.

Certainly it says *something*:

http://www.python.org/dev/peps/pep-0008/#function-and-method-arguments

But I grant you, it only specifically addresses "self", "cls", and function 
argument names that clash with keywords.

I therefore suggest that function arguments are most similar to "method names 
and instance variables"--after all, they *are* instance variables.  And "method 
names and instance variables" say "Use the function naming rules".  And 
function names "should be lowercase, with words separated by underscores as 
necessary to improve readability."

"followlinks" is comprised of two words but they are not separated by 
underscores.

(We can also reason by process of elimination: function arguments are wholly 
dissimilar to constants, package/module names, classes, and exception.  All the 
remaining types of identifiers in Python follow the above rule.)

It might actually be nice to clarify PEP 8 on this.


> Unfortunately, too little time has passed between #14626 accepting
> and shipping of 3.3b1.

I am genuinely sorry about that--but #14626 just wasn't ready earlier.  I'm 
glad you think it's an improvement--we can certainly agree on that!

--

___
Python tracker 

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

[issue1276] LookupError: unknown encoding: X-MAC-JAPANESE

[Olivier Berten]

Olivier Berten  added the comment:

Any idea why mac cjk encodings still aren't available in Python 2.7 and 3.2 ?

--
components:  -Build, Demos and Tools, Library (Lib), Macintosh
nosy: +ezio.melotti, olivier-berten
versions: +Python 2.7, Python 3.2 -Python 2.6, Python 3.0

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

New submission from Ollie Walsh :

Hi,

This is related to #12585.

Distutils sdist builds a package tree using hardlinks to the source if 
supported by the OS. This is then tarred/zipped/etc...

If the source contains symbolic links to external files:

On Linux (and apparently Solaris) they are not dereferenced and the resulting 
package is broken.

On OSX (and apparently all BSD kernels) a hardlink to a symlink will 
dereference the symlink first and the resulting tgz package is ok. However I 
would expect issue #8876 to be more likely as the symlink could references a 
different filesystem which would case hardlinking to fail.


In #12585 I assume that zip dereferences the symlinks which masks the issue.

distutils2 appears to always copy instead of hardlinking resolving all of these 
issues.

distutils can be monkey patched to do the same: 
http://article.gmane.org/gmane.comp.python.distutils.devel/2078

--
assignee: eric.araujo
components: Distutils
messages: 164149
nosy: eric.araujo, ollie.wa...@gmail.com, tarek
priority: normal
severity: normal
status: open
title: distutils dereferences symlinks on Mac OS X but not on Linux
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

[issue1677] Ctrl-C will exit out of Python interpreter in Windows

[Tim Golden]

Tim Golden  added the comment:

OK, I've run out of time to look, but the culprit looks like it's an odd 
interaction between my_fgets in myreadline.c and the interrupt handler in 
signal. There's a section of code which is conditional on 
ERROR_OPERATION_ABORTED being returned from fgets in the CRT. 

That then tries to play ball with a the interrupt handler having fired already 
(in a separate thread) by sleeping for one second and checking that the handler 
was tripped. If it has then the function returns one and stuff happens 
elsewhere; it it hasn't then the function behaves as if EOF (ie Ctrl-Z) was 
pressed and Python exits.

That's as far as I've got; it looks like a race condition of some sort but I 
can't see where. I'm not 100% sure that the SIGINT handler is tripping.

--

___
Python tracker 

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

[issue15199] Default mimetype for javascript should be application/javascript

[R. David Murray]

Changes by R. David Murray :


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

[issue15202] followlinks/follow_symlinks/symlinks flags unification

[R. David Murray]

R. David Murray  added the comment:

Although I do dislike how long it is, I think I agree with larry on this one 
that follow_symlinks is the cleanest choice.  And we are post feature-freeze, 
so I think changing it should be done only if there is a strong reason.

--
nosy: +r.david.murray

___
Python tracker 

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

[issue1677] Ctrl-C will exit out of Python interpreter in Windows

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  added the comment:

Great analysis!

> ... by sleeping for one second ...
Note that Sleep(1) only sleeps for 1 millisecond.
Does the issue go away if you replace with Sleep(10)?

--

___
Python tracker 

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

[issue15204] Deprecate the 'U' open mode

[R. David Murray]

R. David Murray  added the comment:

Unless there are places where it is actually broken, I don't think there is a 
good reason to have step 3.5, though.  Just add the deprecation warning and 
remove it in 4.0.

--
nosy: +r.david.murray

___
Python tracker 

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

[issue1677] Ctrl-C will exit out of Python interpreter in Windows

[Tim Golden]

Tim Golden  added the comment:

That'll be my next move when I get some more time.
I've got someone coming over to see me (about real work!)

--

___
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

[Eric V. Smith]

Changes by Eric V. Smith :


--
nosy: +eric.smith

___
Python tracker 

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

[issue10924] Adding salt and Modular Crypt Format to crypt library.

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 74a1110a3b50 by Christian Heimes in branch 'default':
Issue 10924: Fixed mksalt() to use a RNG that is suitable for cryptographic 
purpose
http://hg.python.org/cpython/rev/74a1110a3b50

--
nosy: +python-dev

___
Python tracker 

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

[issue15031] Split .pyc parsing from module loading

[Brett Cannon]

Brett Cannon  added the comment:

Why is distribute reading bytecode to begin with? What's the use case, 
especially considering that using bytecode screws over other Python VMs like 
Jython and IronPython.

--

___
Python tracker 

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

[issue15206] uuid module falls back to unsuitable RNG

[Christian Heimes]

New submission from Christian Heimes :

The uuid module uses Mersenne Twister from the random module as last fallback. 
However a MT isn't suitable for cryptographic purposes. The module should first 
try to use os.urandom() and then perhaps use its own instance of random.Random, 
similar to uuid_generate_* [1]

The problem doesn't apply to most modern platforms as the uuid module uses 
either libuuid or the Windows API with ctypes. Therefore I consider the real 
world severity as low. It may not require a backport to Python 2.x.

[1] http://linux.die.net/man/3/uuid_generate

--
components: Library (Lib)
messages: 164157
nosy: christian.heimes
priority: normal
severity: normal
status: open
title: uuid module falls back to unsuitable RNG
type: security
versions: Python 2.6, Python 2.7, Python 3.1, 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

[issue10924] Adding salt and Modular Crypt Format to crypt library.

[Christian Heimes]

Changes by Christian Heimes :


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

___
Python tracker 

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

[issue15031] Split .pyc parsing from module loading

[Marc Abramowitz]

Marc Abramowitz  added the comment:

Well, it may be a vestige from setuptools and I don't know if it's still 
needed/appropriate, but distribute scans the pyc modules to try to see whether 
stuff is zip_safe or not when you run `python setup.py bdist_egg`:

https://bitbucket.org/tarek/distribute/src/da2848d34282/setuptools/command/bdist_egg.py#cl-420

Personally, I always set zip_safe to True as I find zipped distributions to be 
a pain in the butt, but not all distributions out there always set it and 
currently `python setup.py bdist_egg` (and probably other commands?) bombs on 
such packages.

We should probably get Tarek to weigh in here.

--

___
Python tracker 

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

[issue15030] PyPycLoader can't read cached .pyc files

[Marc Abramowitz]

Marc Abramowitz  added the comment:

Updated patch based on feedback from Brett (thanks!)

--
Added file: http://bugs.python.org/file26177/cpython-issue-15030.patch

___
Python tracker 

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

[issue15030] PyPycLoader can't read cached .pyc files

[Marc Abramowitz]

Marc Abramowitz  added the comment:

Third revision of my patch based on additional feedback from Brett (thanks!)...

--
Added file: http://bugs.python.org/file26178/cpython-issue-15030.patch

___
Python tracker 

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

[issue15031] Split .pyc parsing from module loading

[Brett Cannon]

Brett Cannon  added the comment:

This all goes back to my original point: I don't want to promote people 
shipping around bytecode only as it hampers the use of other VMs.

Anyway, I'll continue to contemplate this. Any function would have to verify 
the magic number and flat-out fail otherwise to prevent parsing issues (e.g. 
Marc's patch works with or without the file size field to stay compatible with 
PyPycLoader.write_bytecode() implementations that might not set the file size 
field; a design flaw that I fixed in SourceLoader by taking away the ability to 
write bytecode). It would also have it return a dict much like path_stats() for 
easy comparison / verification.

But just to be very clear in case someone is hoping, I will NOT support an API 
to write bytecode as it make compatibility a nightmare and hampers changing the 
format as necessary.

--

___
Python tracker 

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

[issue15030] PyPycLoader can't read cached .pyc files

[Brett Cannon]

Brett Cannon  added the comment:

Patch looks good, Marc. Can you sign a PSF contributor agreement and send it in 
(http://www.python.org/psf/contrib/)?

--
assignee:  -> brett.cannon
stage:  -> commit review

___
Python tracker 

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

[issue11442] list_directory() in SimpleHTTPServer.py should add charset=... to Content-type header

[Guido van Rossum]

Guido van Rossum  added the comment:

For posterity, according to the red hat tracker at 
https://bugzilla.redhat.com/show_bug.cgi?id=803500 this issue has been assigned 
a CVE number: CVE-2011-4940

--

___
Python tracker 

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

[issue15030] PyPycLoader can't read cached .pyc files

[Marc Abramowitz]

Marc Abramowitz  added the comment:

Brett, I just emailed the contributor agreement.

--

___
Python tracker 

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

[issue14954] weakref doc clarification

[Ethan Furman]

Ethan Furman  added the comment:

Changed "... will return the object ..." to " ... may return the object ..."

For reference, here's the new text:

A weak reference to an object is not enough to keep the object alive: when the 
only remaining references to a referent are weak references,
:term:`garbage collection` is free to destroy the referent and reuse its memory 
for something else.  However, until the object is actually destroyed the weak 
reference may return the object even if there are no strong references to it.

--
Added file: http://bugs.python.org/file26179/weakref_doc_updates_v2.diff

___
Python tracker 

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

[issue15202] followlinks/follow_symlinks/symlinks flags unification

[Georg Brandl]

Georg Brandl  added the comment:

IMO adding follow_symlinks to the functions currently supporting 
symlinks/followlinks is a bugfix.  Such a patch would be ok to go into 3.3.

--

___
Python tracker 

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

[issue15200] Faster os.walk

[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

[issue15201] C argument errors and Python arguments error are different

[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

[issue15202] followlinks/follow_symlinks/symlinks flags unification

[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

[issue15203] Accepting of os functions of (path, dir_fd) pair as argument

[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

[issue15204] Deprecate the 'U' open mode

[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

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

[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

[issue15031] Split .pyc parsing from module loading

[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

[issue15206] uuid module falls back to unsuitable RNG

[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

[issue15030] PyPycLoader can't read cached .pyc files

[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

[issue15207] mimetypes.read_windows_registry() uses the wrong regkey, creates wrong mappings

[Dave Chambers]

New submission from Dave Chambers :

The current mimetypes.read_windows_registry() enums the values under 
HKCR\MIME\Database\Content Type
However, this is the key for mimetype to extension lookups, NOT for extension 
to mimetype lookups.
As a result, when >1 MIME types are mapped to a particular extension, the 
last-found entry is used.
For example, both "image/png" and "image/x-png" map to the ".png" file 
extension.
Unfortunately, what happens is this code finds "image/png", then later finds 
"image/x-png" and this steals the ".png" extension.


The solution is to use the correct regkey, which is the HKCR root.
This is the correct location for extension-to-mimetype lookups.
What we should do is enum the HKCR root, find all subkeys that start with a dot 
(i.e. file extensions), then inspect those for a 'Content Type' value.


The attached ZIP contains:
mimetype_flaw_demo.py  - this demonstrates the error (due to wrong regkey) and 
my fix (uses the correct regkey)
mimetypes_fixed.py   -   My suggested fix to the standard mimetypes.py module.

--
components: Windows
files: mimetype_flaw_demo.zip
messages: 164167
nosy: dlchambers
priority: normal
severity: normal
status: open
title: mimetypes.read_windows_registry() uses the wrong regkey, creates wrong 
mappings
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file26180/mimetype_flaw_demo.zip

___
Python tracker 

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

[issue12605] Enhancements to gdb 7 debugging hooks

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Got the following error on Mageia 1:

==
FAIL: test_threads (test.test_gdb.PyBtTests)
Verify that "py-bt" indicates threads that are waiting for the GIL
--
Traceback (most recent call last):
  File "/home/antoine/cpython/default/Lib/test/test_gdb.py", line 697, in 
test_threads
cmds_after_breakpoint=['thread apply all py-bt'])
  File "/home/antoine/cpython/default/Lib/test/test_gdb.py", line 153, in 
get_stack_trace
self.assertEqual(err, '')
AssertionError: "Error occurred in Python command: 'NoneType' object has no 
attribute 'startswit [truncated]... != ''
- Error occurred in Python command: 'NoneType' object has no attribute 
'startswith'

--

___
Python tracker 

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

[issue15030] PyPycLoader can't read cached .pyc files

[Martin v . Löwis]

Martin v. Löwis  added the comment:

I think the loader should just unconditionally assume 12 bytes header. This is 
meant to work only for the exact version it ships with, so it just has to match.

--
nosy: +loewis

___
Python tracker 

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

[issue15200] Faster os.walk

[Ross Lagerwall]

Ross Lagerwall  added the comment:

This looks like the kind of optimization that depends hugely on what kernel 
you're using. Maybe on FreeBSD/Solaris/whatever, standard os.walk() is faster?

If this micro-optimization were to be accepted, someone would have to be keen 
enough to test it is different ways on many different versions of every 
platform to conclusively prove that it is faster in general.

--
nosy: +rosslagerwall

___
Python tracker 

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

[issue15030] PyPycLoader can't read cached .pyc files

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> I think the loader should just unconditionally assume 12 bytes header. 
> This is meant to work only for the exact version it ships with, so it
> just has to match.

Agreed with Martin.

--

___
Python tracker 

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

[issue15200] Faster os.walk

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> This looks like the kind of optimization that depends hugely on what
> kernel you're using.

Agreed.
Also, I'm worried that there might be subtle differences between walk() and 
fwalk() which could come and bite users if we silently redirect the former to 
the latter.

(for the record, I get a 15% speedup on this Linux box)

--
nosy: +pitrou

___
Python tracker 

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

[issue15202] followlinks/follow_symlinks/symlinks flags unification

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

> I dislike "followlinks" because "links" is ambiguous; both hard links
> and soft links are "links", but it's only modifying behavior regarding
> one of them.

Technically, in Unix world any file is a hard link. It is impossible to
distinguish a hard link from the "original", they are completely equal.
So I don't think that there will be a ambiguity, what links are implied,
especially, if the documentation is clearly says "symbolic links".

> I therefore suggest that function arguments are most similar to "method names 
> and instance variables"--after all, they *are* instance variables.

Technically, they are local variables.

> "followlinks" is comprised of two words but they are not separated by 
> underscores.

As "getgrouplist" or "sendfile". What about such argument names as
"filename" and "newline"? If being a consistent in that, then it must be
"follow_symbolic_links". And "source_directory_file_descriptor" instead
"src_dir_fd".

> It might actually be nice to clarify PEP 8 on this.

I agree.

> I'm glad you think it's an improvement--we can certainly agree on that!

Of course. This is the issue, for the solution of which I registered
here. All other issues and patches were just distractions and
practice. ;-)  I am grateful to you.

--

___
Python tracker 

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

[issue14667] No IDLE

[Roger Serwy]

Roger Serwy  added the comment:

James, do you have IDLE working?

--
nosy: +serwy
status: open -> pending

___
Python tracker 

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

[issue15208] Uparrow doesn't show previously typed variable or character

[kracekumar ramaraju]

New submission from kracekumar ramaraju :

Below is the copy & paste from the Interpreter.

kracekumar@python-lover:~/codes/python/Python-3.3.0b1$ python3.3
Python 3.3.0b1 (default, Jun 27 2012, 22:27:38) 
[GCC 4.6.3] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> __builtins__

>>> ^[[A^[[A 

On pressing the up arrow inside 3.3 b1 interpreter doesn't show previously 
typed variable or statement.

This test was carried out in ubuntu 12.04.

--
components: Interpreter Core
messages: 164175
nosy: kracekumar
priority: normal
severity: normal
status: open
title: Uparrow doesn't show previously typed variable or character
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

[issue15207] mimetypes.read_windows_registry() uses the wrong regkey, creates wrong mappings

[R. David Murray]

R. David Murray  added the comment:

Thanks for working on this.  Could you please post the fix as a patch file?  If 
you don't have mercurial, you can generate the diff on windows using the python 
diff module (scripts/diff.py -u  ).  Actually, I'm not sure 
exactly where diff is in the windows install, but I know it is there.

Do you know if image/x-png and image/png are included in the registry on all 
windows versions?  If so we could use that key for a unit test.

--
components: +email
nosy: +barry, r.david.murray
stage:  -> needs patch
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

[issue15207] mimetypes.read_windows_registry() uses the wrong regkey, creates wrong mappings

[Dave Chambers]

Dave Chambers  added the comment:

My first diff file... I hope I did it right :)

--
keywords: +patch
Added file: http://bugs.python.org/file26181/mimetypes.py.diff

___
Python tracker 

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

[issue15208] Uparrow doesn't show previously typed variable or character

[Ned Deily]

Ned Deily  added the comment:

It looks like the Python you are using was built without GNU readline.  You 
probably need to install the libreadline-dev package from Ubuntu and rebuild 
Python.

--
nosy: +ned.deily
resolution:  -> invalid
status: open -> pending

___
Python tracker 

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

[issue15202] followlinks/follow_symlinks/symlinks flags unification

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

> IMO adding follow_symlinks to the functions currently supporting 
> symlinks/followlinks is a bugfix.  Such a patch would be ok to go into 3.3.

Here is an other patch, that implements Larry's suggestion about
renaming followlinks in (f)walk to follow_symlinks (with keeping old
name as alias). I hope native speakers corrected me in docs. However, I
don't think that this is the best solution (but it better than nothing).

--
Added file: 
http://bugs.python.org/file26182/followlinks-to-follow_symlinks.patch

___
Python tracker 

___diff -r b66e82c9f852 Doc/library/os.rst
--- a/Doc/library/os.rstTue Jun 26 23:05:27 2012 +0200
+++ b/Doc/library/os.rstWed Jun 27 20:49:59 2012 +0300
@@ -2128,7 +2128,7 @@
   and the *dir_fd*, *follow_symlinks*, and *ns* parameters.
 
 
-.. function:: walk(top, topdown=True, onerror=None, followlinks=False)
+.. function:: walk(top, topdown=True, onerror=None, follow_symlinks=False)
 
.. index::
   single: directory; walking
@@ -2168,12 +2168,12 @@
is available as the ``filename`` attribute of the exception object.
 
By default, :func:`walk` will not walk down into symbolic links that 
resolve to
-   directories. Set *followlinks* to ``True`` to visit directories pointed to 
by
+   directories. Set *follow_symlinks* to ``True`` to visit directories pointed 
to by
symlinks, on systems that support them.
 
.. note::
 
-  Be aware that setting *followlinks* to ``True`` can lead to infinite
+  Be aware that setting *follow_symlinks* to ``True`` can lead to infinite
   recursion if a link points to a parent directory of itself. :func:`walk`
   does not keep track of the directories it visited already.
 
@@ -2210,8 +2210,12 @@
   for name in dirs:
   os.rmdir(os.path.join(root, name))
 
-
-.. function:: fwalk(top='.', topdown=True, onerror=None, followlinks=False, *, 
dir_fd=None)
+   .. versionchanged:: 3.3
+  *followlinks* renamed to *follow_symlinks*. For backward compatibility
+  the old name accepted as alias to new one.
+
+
+.. function:: fwalk(top='.', topdown=True, onerror=None, 
follow_symlinks=False, *, dir_fd=None)
 
.. index::
   single: directory; walking
diff -r b66e82c9f852 Lib/os.py
--- a/Lib/os.py Tue Jun 26 23:05:27 2012 +0200
+++ b/Lib/os.py Wed Jun 27 20:49:59 2012 +0300
@@ -331,7 +331,9 @@
 
 __all__.extend(["makedirs", "removedirs", "renames"])
 
-def walk(top, topdown=True, onerror=None, followlinks=False):
+_sentry = object()
+
+def walk(top, topdown=True, onerror=None, follow_symlinks=_sentry, *, 
followlinks=_sentry):
 """Directory tree generator.
 
 For each directory in the directory tree rooted at top (including top
@@ -369,7 +371,7 @@
 
 By default, os.walk does not follow symbolic links to subdirectories on
 systems that support them.  In order to get this functionality, set the
-optional argument 'followlinks' to true.
+optional argument 'follow_symlinks' to true.
 
 Caution:  if you pass a relative pathname for top, don't change the
 current working directory between resumptions of walk.  walk never
@@ -387,7 +389,18 @@
 if 'CVS' in dirs:
 dirs.remove('CVS')  # don't visit CVS directories
 """
+if follow_symlinks is _sentry:
+if followlinks is _sentry:
+follow_symlinks = False
+else:
+follow_symlinks = followlinks
+elif followlinks is not _sentry:
+raise ValueError(
+"'follow_symlinks' and 'followlinks' arguments are 
incompatible")
 
+yield from _walk(top, topdown, onerror, follow_symlinks)
+
+def _walk(top, topdown, onerror, follow_symlinks):
 islink, join, isdir = path.islink, path.join, path.isdir
 
 # We may not have read permission for top, in which case we can't
@@ -415,8 +428,8 @@
 yield top, dirs, nondirs
 for name in dirs:
 new_path = join(top, name)
-if followlinks or not islink(new_path):
-yield from walk(new_path, topdown, onerror, followlinks)
+if follow_symlinks or not islink(new_path):
+yield from walk(new_path, topdown, onerror, follow_symlinks)
 if not topdown:
 yield top, dirs, nondirs
 
@@ -424,7 +437,7 @@
 
 if {open, stat} <= supports_dir_fd and {listdir, stat} <= supports_fd:
 
-def fwalk(top=".", topdown=True, onerror=None, followlinks=False, *, 
dir_fd=None):
+def fwalk(top=".", topdown=True, onerror=None, follow_symlinks=False, *, 
dir_fd=None):
 """Directory tree generator.
 
 This behaves exactly like walk(), except that it yields a 4-tuple
@@ -435,7 +448,7 @@
 and `dirfd` is a file descriptor referring to the directory `dirpath`.
 
 The advantage of fwalk() over walk() is that it's safe against symlink
-races (when followlin

[issue15207] mimetypes.read_windows_registry() uses the wrong regkey, creates wrong mappings

[Dave Chambers]

Dave Chambers  added the comment:

I added a diff file to the bug.
Dunno if that's the same as a patch file, or how to create a patchfile if it's 
not.

>Do you know if image/x-png and image/png are included in the registry on all 
> windows versions?

I think your question is reversed, in the same way that the code was reversed.
You're not looking for image/png and/or image/x-png. You're looking for .png in 
order to retrieve its mimetype (aka Content Type).
While nothing is 100% certain on Windows :), I'm quite confident that every 
copy will have an HKCR\.png regkey, and that regkey will have a Content Type 
value, and that value's setting will be the appropriate mometype, which I'd 
expect to be image/png.

I was kinda surprised to find this bug as it's so obvious
I started chasing it because Chrome kept complaining that pngs were being 
served as image/x-png (by CherryPy).
There are other bugs (eg: 15199, 10551) that my patch should fix.

-Dave

--

___
Python tracker 

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

[issue12605] Enhancements to gdb 7 debugging hooks

[Dave Malcolm]

Dave Malcolm  added the comment:

I believe this was due to this line:
  return self._gdbframe.name().startswith('pthread_cond_timedwait')
within is_waiting_for_gil(), and your gdb returned None for
self._gdbframe.name() for your build.

I've changed it to:
   name = self._gdbframe.name()
   if name:
   return name.startswith('pthread_cond_timedwait')
in my latest version.

I've also bulletproofed against the --without-threads case by simply
skipping the cases that fail (some tests run into this gdb error:
   Cannot find new threads: generic error
unless we add LD_PRELOAD=PATH-TO-libpthread.so.1 as a workaround, but it
seems that trying to add that workaround is more risky (what path?) than
simply skipping the tests under those circumstances.

Tested successfully on a Fedora 15 x86_64 box (gdb-7.3-43.fc15.x86_64)
with these configurations:
  * --with-pydebug
  * --with-pydebug --enable-shared
  * (no flags = optimized)
  * --enable-shared (optimized)
  * --with-pydebug --without-threads

(Note that because of issue #14774 I have to regenerate
_sysconfigdata.py between each configuration, otherwise it gets confused
about whether or not the build is optimized)

--

___
Python tracker 

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

[issue15206] uuid module falls back to unsuitable RNG

[Christian Heimes]

Christian Heimes  added the comment:

Further analysis:

* uuid1() uses random.randrange() if the system doesn't provide 
uuid_generate_time

* uuid1() also falls back to random.randrange() in getnode()'s 
_random_getnode() if no hardware address can be acquired.

* uuid4() is fine as it only falls back to random.randrange() when os.urandom() 
fails.

--

___
Python tracker 

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

[issue12605] Enhancements to gdb 7 debugging hooks

[Roundup Robot]

Roundup Robot  added the comment:

New changeset abcd29c9a791 by David Malcolm in branch 'default':
Issue #12605: Show information on more C frames within gdb backtraces
http://hg.python.org/cpython/rev/abcd29c9a791

--
nosy: +python-dev

___
Python tracker 

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

[issue15209] Re-raising exceptions from an expression

[Tyler Crompton]

New submission from Tyler Crompton :

As you know, a caught exception can be re-raised with a simple `raise` 
statement. Plain and simple. However, one cannot re-raise an error with this 
new `"from" expression` clause.

For example:

def getch(prompt=''):
'''Get and return a character (similar to `input()`).'''

print(prompt, end='')
try:
return windows_module.getch()
except NameError:
try:
fallback_module.getch()
except Exception:
raise from None

Output:

  File "getch.py", line 11
raise from None
 ^
SyntaxError: invalid syntax

A quick look at the documentation about 
[raise](http://docs.python.org/dev/reference/simple_stmts.html#the-raise-statement)
 confirms that this is the intended behavior. In my opinion, one should be able 
to still re-raise from an expression.

--
components: Interpreter Core
files: getch.py
messages: 164184
nosy: Tyler.Crompton
priority: normal
severity: normal
status: open
title: Re-raising exceptions from an expression
type: enhancement
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file26183/getch.py

___
Python tracker 

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

[issue15206] uuid module falls back to unsuitable RNG

[Martin v . Löwis]

Martin v. Löwis  added the comment:

Can you elaborate why it is unsuitable? None of the uuid functions claim any 
cryptographic properties, so even if MT was unsuitable for cryptographic 
purposes, this wouldn't rule it out for generating uuids.

--
nosy: +loewis

___
Python tracker 

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

[issue15202] followlinks/follow_symlinks/symlinks flags unification

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


Removed file: 
http://bugs.python.org/file26182/followlinks-to-follow_symlinks.patch

___
Python tracker 

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

[issue15202] followlinks/follow_symlinks/symlinks flags unification

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


Added file: 
http://bugs.python.org/file26184/followlinks-to-follow_symlinks.patch

___
Python tracker 

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

[issue15209] Re-raising exceptions from an expression

[Tyler Crompton]

Tyler Crompton  added the comment:

Relevent PEP: http://www.python.org/dev/peps/pep-0409/

--

___
Python tracker 

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

[issue1677] Ctrl-C will exit out of Python interpreter in Windows

[Tim Golden]

Tim Golden  added the comment:

OK, it is a race condition between the code in myreadline.c and the 
signal_handler in signalmodule.c. It can take between 0 and 3 sleeps for 
the myreadline code to see the signal tripped. Patch on its way for 2.7; 
VS 2010 downloading so that 3.x patch can be tested.

--

___
Python tracker 

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

[issue15209] Re-raising exceptions from an expression

[Tyler Crompton]

Changes by Tyler Crompton :


--
nosy: +ncoghlan, stoneleaf

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

New submission from Brett Cannon :

If you look at 
http://hg.python.org/cpython/file/abcd29c9a791/Lib/importlib/__init__.py you 
will notice that the try/except block for seeing if _frozen_importlib exists 
catches ImportError, not KeyError like it should since it is checking sys. 
modules and not performing an import.

--
components: Library (Lib)
messages: 164188
nosy: brett.cannon
priority: normal
severity: normal
stage: test needed
status: open
title: importlib.__init__ checks for the wrong exception when looking for 
_frozen_importlib
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

[issue15030] PyPycLoader can't read cached .pyc files

[Marc Abramowitz]

Marc Abramowitz  added the comment:

Hmmm if I simply do:

diff -r b66e82c9f852 Lib/importlib/abc.py
--- a/Lib/importlib/abc.py  Tue Jun 26 23:05:27 2012 +0200
+++ b/Lib/importlib/abc.py  Wed Jun 27 12:15:55 2012 -0700
@@ -282,7 +282,7 @@
 if len(raw_timestamp) < 4:
 raise EOFError("bad timestamp in {}".format(fullname))
 pyc_timestamp = _bootstrap._r_long(raw_timestamp)
-bytecode = data[8:]
+bytecode = data[12:]
 # Verify that the magic number is valid.
 if imp.get_magic() != magic:
 raise ImportError(

then I get two "ValueError: bad marshal data (unknown type code)" test errors 
in test_abc_loader.

I am unsure as to whether this is a bug in the test or the implementation.

The following quells the errors, but I am not all confident that it's correct:

@@ -302,7 +302,10 @@
 raise
 else:
 # Bytecode seems fine, so try to use it.
-return marshal.loads(bytecode)
+try:
+return marshal.loads(bytecode)
+except ValueError:
+return ''
 elif source_timestamp is None:
 raise ImportError("no source or bytecode available to create code "
   "object for {0!r}".format(fullname),

--

___
Python tracker 

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

[issue15211] Test

[j]

New submission from j :

asdf fsa sads f

--
assignee: collinwinter
components: Benchmarks
messages: 164190
nosy: collinwinter, jgbw
priority: normal
severity: normal
status: open
title: Test
type: crash
versions: Python 3.1

___
Python tracker 

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

[issue15207] mimetypes.read_windows_registry() uses the wrong regkey, creates wrong mappings

[R. David Murray]

R. David Murray  added the comment:

Well, I had no involvement in the windows registry reading stuff, and it is 
relatively new.  And, as issue 10551 indicates, a bit controversial.  (issue 
15199 is a different bug, in python's own internal table).

Can you run that diff again and use the '-u' flag?  The -u (universal) format 
is the one we are used to working with.  The one you posted still lets us read 
the changes, though, which is very helpful.

--
nosy: +brian.curtin, tim.golden

___
Python tracker 

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

[issue15211] Test

[R. David Murray]

Changes by R. David Murray :


--
assignee: collinwinter -> 
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed
type: crash -> 

___
Python tracker 

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

[issue15030] PyPycLoader can't read cached .pyc files

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> I am unsure as to whether this is a bug in the test or the implementation.

You should probably investigate a bit more. We don't want to silence exceptions 
if there's not a good reason to.

--

___
Python tracker 

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

[issue15208] Uparrow doesn't show previously typed variable or character

[Tyler Crompton]

Tyler Crompton  added the comment:

I recreated this issue on (mostly) fresh install of Ubuntu Server 12.04. I 
installed libreadline-dev and then removed and re-installed Python 3.3.0b1. 
This resolved the issue.

--
nosy: +Tyler.Crompton
status: pending -> open

___
Python tracker 

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

[issue15207] mimetypes.read_windows_registry() uses the wrong regkey, creates wrong mappings

[Dave Chambers]

Changes by Dave Chambers :


Added file: http://bugs.python.org/file26185/mimetypes.py.diff.u

___
Python tracker 

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

[issue15208] Uparrow doesn't show previously typed variable or character

[R. David Murray]

Changes by R. David Murray :


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

[issue15030] PyPycLoader can't read cached .pyc files

[Brett Cannon]

Brett Cannon  added the comment:

The patch could be updated to ignore the 12 bytes unconditionally when reading 
bytecode but still write out the accurate file size (when possible). That 
should be fully compatible within Python 3.3 no matter who generated the 
bytecode (PyPycLoader or import).

--

___
Python tracker 

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

[issue15202] followlinks/follow_symlinks/symlinks flags unification

[Larry Hastings]

Larry Hastings  added the comment:

> > after all, they *are* instance variables.
>  Technically, they are local variables.

Yeah, tbh I was thinking "instance of an invocation" here.  But PEP 8 probably 
means "instance of a class" here.

Still, there are three classes of naming things in Python: all uppercase 
(constants), CapCase (class and exception names), and everything else 
(lowercase with underscores).  I suggest that arguments and local variables 
belong in the latter camp.  At no point does PEP 8 suggest naming anything in 
lowercase without underscores.

> As "getgrouplist" or "sendfile". What about such argument names as
> "filename" and "newline"? If being a consistent in that, then it
> must be "follow_symbolic_links". And
> "source_directory_file_descriptor" instead "src_dir_fd".

You are muddling the issue--PEP 8 makes no ruling on abbreviations.

Personally, I prefer not to use abbreviations where possible.  I've found over 
the years that they are painfully ambiguous--I can never remember what 
abbreviation I used.  ("control" becomes... "ctl"? "cntl"?)  MvL also makes a 
good point that abbreviations are a hinderance to people who speak little or no 
English.

That said, naming things after their POSIX counterparts has to be okay, and 
abbreviations are occasionally called for when they are widely understood / 
have a precedent in the library.  So with every example you cite I prefer the 
extant name over any counterproposal you explicitly suggested.

--

___
Python tracker 

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

[issue15209] Re-raising exceptions from an expression

[Ethan Furman]

Ethan Furman  added the comment:

I agree that "raise from None" would be a nice enhancement.

I don't see it going into 3.3 since we've hit feature freeze.

Nick, do we need another PEP, or just consensus on pydev?  (If consensus, I can 
bring it up there after 3.3.0final is released.)

--

___
Python tracker 

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

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

[Arfrever Frehtes Taifersar Arahesis]

Arfrever Frehtes Taifersar Arahesis  added the comment:

The fix (c910af2e3c98 + 53fc7f59c7bb) for this issue broke deletion of 
directories, which contain symlinks to directories.
(Directories with symlinks to regular files or symlinks to nonexistent files 
are unaffected.)

$ mkdir -p /tmp/a/b
$ ln -s b /tmp/a/c
$ python3.2 -c 'import shutil; shutil.rmtree("/tmp/a")'
$ mkdir -p /tmp/a/b
$ ln -s b /tmp/a/c
$ python3.3 -c 'import shutil; shutil.rmtree("/tmp/a")'
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib64/python3.3/shutil.py", line 447, in rmtree
_rmtree_safe_fd(fd, path, onerror)
  File "/usr/lib64/python3.3/shutil.py", line 395, in _rmtree_safe_fd
_rmtree_safe_fd(dirfd, fullname, onerror)
  File "/usr/lib64/python3.3/shutil.py", line 406, in _rmtree_safe_fd
onerror(os.rmdir, path, sys.exc_info())
  File "/usr/lib64/python3.3/shutil.py", line 404, in _rmtree_safe_fd
os.rmdir(path)
NotADirectoryError: [Errno 20] Not a directory: '/tmp/a/c'
$

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

___
Python tracker 

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

[issue15030] PyPycLoader can't read cached .pyc files

[Marc Abramowitz]

Marc Abramowitz  added the comment:

Here's a patch that unconditionally switches over to the 12 byte format. I'm 
assuming the "size" in data[8:12] is the length of the bytecode?

--
Added file: http://bugs.python.org/file26186/cpython-issue-15030.patch

___
Python tracker 

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