[issue12275] urllib.request.HTTPRedirectHandler won't redirect to a URL with only path but not domain

[lilydjwg]

New submission from lilydjwg :

On redirecting to a url like '/login', at around line 556 of request.py it will 
raise an HTTPError. The sys.verrsion is

  Python 3.2 (r32:88445, Apr 15 2011, 11:20:08) 
  [GCC 4.5.2 20110127 (prerelease)] on linux2

--
components: Library (Lib)
messages: 137791
nosy: lilydjwg
priority: normal
severity: normal
status: open
title: urllib.request.HTTPRedirectHandler won't redirect to a URL with only 
path but not domain
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

[issue12276] 3.x ignores sys.tracebacklimit=0

[Gabriel Genellina]

New submission from Gabriel Genellina :

Python 3.x doesn't honor sys.tracebacklimit=0

According to 
http://docs.python.org/py3k/library/sys.html#sys.tracebacklimit
when set to 0, it should not print any stack trace, but it does.

Python 3.2 (r32:88445, Feb 20 2011, 21:29:02) [MSC v.1500 32 bit (Intel)] on win
32
Type "help", "copyright", "credits" or "license" for more information.
p3> import sys
p3> sys.tracebacklimit = 0
p3>
p3> def f(x):
...   return f(x-1) if x else 0/0
...
p3> f(5)
Traceback (most recent call last):
  File "", line 1, in 
  File "", line 2, in f
  File "", line 2, in f
  File "", line 2, in f
  File "", line 2, in f
  File "", line 2, in f
  File "", line 2, in f
ZeroDivisionError: division by zero
p3>

--
components: Interpreter Core
files: tracebacklimitbug.py
messages: 137792
nosy: gagenellina
priority: normal
severity: normal
status: open
title: 3.x ignores sys.tracebacklimit=0
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file22269/tracebacklimitbug.py

___
Python tracker 

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

[issue12276] 3.x ignores sys.tracebacklimit=0

[Gabriel Genellina]

Gabriel Genellina  added the comment:

Originally reported by Thorsten Kampe in comp.lang.python 2011-5-27


--

___
Python tracker 

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

[issue12276] 3.x ignores sys.tracebacklimit=0

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  added the comment:

This was changed a long time ago with 565012d1123d

--
nosy: +amaury.forgeotdarc

___
Python tracker 

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

[issue12276] 3.x ignores sys.tracebacklimit=0

[STINNER Victor]

Changes by STINNER Victor :


--
nosy: +haypo

___
Python tracker 

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

[issue12277] Missing comma in os.walk docs

[Boštjan Mejak]

New submission from Boštjan Mejak :

http://docs.python.org/release/2.6.6/library/os.html?highlight=os.walk#os.walk

Click the above link and note the 5th paragraph which goes "By default errors 
from the listdir() call are ignored."

Please fix it to "By default, errors from the listdir() call are ignored."

So add a comma after "By default," Thanks.

--
assignee: docs@python
components: Documentation
messages: 137795
nosy: Retro, docs@python
priority: normal
severity: normal
status: open
title: Missing comma in os.walk docs
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

___
Python tracker 

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

[issue12084] os.stat() on windows doesn't consider relative symlink

[Georg Brandl]

Georg Brandl  added the comment:

Any Windows person going to review this one?

--

___
Python tracker 

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

[issue9284] inspect.findsource() cannot find source for doctest code

[Dirkjan Ochtman]

Dirkjan Ochtman  added the comment:

Here's an attempted patch against 2.7. It seemed nice to put the test in 
test_doctest, but maybe it belongs in inspect...

--
keywords: +needs review, patch
Added file: http://bugs.python.org/file22270/issue9284.diff

___
Python tracker 

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

[issue12019] Dead or buggy code in importlib.test.__main__

[Georg Brandl]

Georg Brandl  added the comment:

If it's a minor cleanup and not a bugfix, why should it go into a branch that 
receives bugfixes only?

--
nosy: +georg.brandl

___
Python tracker 

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

[issue12268] file readline, readlines & readall methods can lose data on EINTR

[Antoine Pitrou]

Antoine Pitrou  added the comment:

I'm not sure why you're creating a separate test file. There are already 
signals-related tests in test_io. Also, perhaps you can reuse the idioms used 
there, rather than spawn subprocesses.

--
stage:  -> patch review

___
Python tracker 

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

[issue12084] os.stat() on windows doesn't consider relative symlink

[Tim Golden]

Tim Golden  added the comment:

I'm just patching a clone now.

--
nosy: +tim.golden

___
Python tracker 

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

[issue12084] os.stat() on windows doesn't consider relative symlink

[STINNER Victor]

STINNER Victor  added the comment:

issue12084.diff:
 - test_os pass with patched Python 3.3 on Windows 7 64 bits (and on Linux, 
Debian Sid)
 - in test_os: "finally: os.remove(file1)"  fails with file1 doesn't exist: a 
new try/finally should be used after "with open(file1, "w") as f:" block, or 
support.unlink() should be used instead
 - the patch doesn't apply cleany on the default Mercurial branch (fail on 
posixmodule.c), can you update your patch?
 - posixmodule.c still refer to win32_lstat() in a comment (a comment just 
before the removed win32_lstat() function)
 - win32_stat() must fail if the conversion to wide character failed. 
win32_stat() should use PyUnicode_DecodeFSDefault() instead of mbstowcs_s(). 
PyUnicode_DecodeFSDefault() allocates the memory and handles errors correctly: 
raise a nice Python error on decoding error (it uses the strict error handler 
for MBCS encoding, the ANSI code page).

win32_stat() decodes "manually" the filename from the ANSI code page and use 
the wide character API, instead of using the ANSI API. It is a little bit 
different than what is done for other functions of the posix module: other 
functions use the ANSI API, as specified by the PEP 277.
http://www.python.org/dev/peps/pep-0277/

Well, this PEP was written in 2002 when the default string type in Python (2) 
was the byte string. In 2011, with Python 3, the default string type is a 
character string and I can easily understand that you prefer to simplify the 
code by using a single string type. I also remember a discussion about 
deprecating byte filenames in Python 3.

I would prefer to discuss this point (decode byte string from the ANSI code 
page) on the mailing, and maybe also update the PEP 277.

The main question for me is how the ANSI API handles undecodable bytes: does it 
raise an error or ignore them? For stat(), ignoring undecodable bytes means 
that stat() will raise a "file not found error".

Most ANSI code pages never fail with a decoding error because they are 8 bits 
encoding and all bytes are mapped to characters. They are some multibyte code 
pages (like UTF-8), but I don't think that any Windows use such code page *by 
default*. I don't even know if it's possible to use a multibyte code page as 
the ANSI code page.

(I didn't check the symlink algorithm, I only cares about Unicode :-D)

--
nosy: +haypo

___
Python tracker 

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

[issue12275] urllib.request.HTTPRedirectHandler won't redirect to a URL with only path but not domain

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Well, the HTTP RFC does indicate that the redirection URI (in the Location 
header: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.30) must 
be an absolute URI, but I also agree that using a relative URI in that context 
is a common use-case supported by browsers, and it would be good to support it 
in the stdlib too.

--
nosy: +orsenthil, pitrou
stage:  -> needs patch
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

[issue12084] os.stat() on windows doesn't consider relative symlink

[STINNER Victor]

STINNER Victor  added the comment:

Win32SymlinkTests.test_rmdir_on_directory_link_to_missing_target() pass on my 
Windows 7 64 bits VM (with and without the patch), but is skipped:

@unittest.skip("currently fails; consider for improvement")
def test_rmdir_on_directory_link_to_missing_target(self):
self._create_missing_dir_link()
# consider allowing rmdir to remove directory links
os.rmdir(self.missing_link)

On which OS does it fail? The skip may be changed to only skipped some Windows 
versions?

--

___
Python tracker 

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

[issue12238] Readline module loading in interactive mode

[Antoine Pitrou]

Antoine Pitrou  added the comment:

I don't think readline is "special-cased":

$ echo "1/0" > logging.py
$ cpython/default/python
Python 3.3a0 (default:d8502fee4638+, Jun  6 2011, 19:13:58) 
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import logging
Traceback (most recent call last):
  File "", line 1, in 
  File "logging.py", line 1, in 
1/0
ZeroDivisionError: division by zero

--

___
Python tracker 

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

[issue12084] os.stat() on windows doesn't consider relative symlink

[Tim Golden]

Tim Golden  added the comment:

All expected tests pass on 3.2 branch (Win7 32-bit). The patch doesn't 
apply cleanly to trunk; not sure if it's expected to or not. The code
looks ok on paper. I'll leave Victor to quibble over the Unicode stuff...

--

___
Python tracker 

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

[issue12226] use secured channel for uploading packages to pypi

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> If you make an HTTPS connection without checking the certificate, what 
> security does it add?

Well, it does prevent the most trivial class of attacks (sniffing).
That said, Python has support for certificate checking, especially in 3.2+, so 
you should use that. You could e.g. bundle the CACert root certificate with the 
distribution.

--
nosy: +pitrou

___
Python tracker 

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

[issue12278] Core mentorship mention in the devguide

[Adam Woodbeck]

New submission from Adam Woodbeck :

Jesse requested the devguide be updated to include a mention of the Python 
Mentors site.  The attached patch is my rough draft.

--
components: Devguide
files: help.rst.patch
keywords: patch
messages: 137807
nosy: adam.woodbeck, ncoghlan
priority: normal
severity: normal
status: open
title: Core mentorship mention in the devguide
Added file: http://bugs.python.org/file22271/help.rst.patch

___
Python tracker 

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

[issue12188] PEP 7, C style: add ++ policy and explanation

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Indeed, I don't think that's appropriate. Also, it's not about ++ in general 
but a particular use of it.

--
nosy: +gvanrossum, pitrou
resolution:  -> rejected
status: open -> pending
type:  -> feature request

___
Python tracker 

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

[issue12188] PEP 7, C style: add ++ policy and explanation

[Eric V. Smith]

Eric V. Smith  added the comment:

But don't you think we should put information like this somewhere, even if it's 
not in PEP 7? We've had a discussion about this particular issue (idiomatic 
pointer increments when appending to a buffer) at least twice, and there's also 
the recent "if (const == variable)" issue that feels similar to me.

It seems to me that recording these decisions somewhere has value, just so we 
don't have to revisit them.

--
status: pending -> open

___
Python tracker 

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

[issue12197] non-blocking SSL write in Windows sends large data but raises exception

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Which version of Python are you testing on? It works fine using 3.2 and 3.3 
here, under Windows 7 64-bit.

Anyway, I would suggest to batch your write in smaller chunks (say, 2048 bytes 
each). Also, you may try sendall() instead.

--
nosy: +pitrou

___
Python tracker 

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

[issue11203] gzip doc is behind

[Antoine Pitrou]

Antoine Pitrou  added the comment:

The 3.x doc states that "GzipFile supports the io.BufferedIOBase interface, 
including iteration and the with statement. Only the truncate() method isn’t 
implemented". This implies that it also supports close().

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

[issue12198] zipfile.py:1047: DeprecationWarning: 'H' format requires 0 <= number <= 65535

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
nosy: +amaury.forgeotdarc

___
Python tracker 

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

[issue10115] Support accept4() for atomic setting of flags at socket creation

[Vetoshkin Nikita]

Vetoshkin Nikita  added the comment:

Yes, I can.
We decided to expose accept4() as another socket method, not accept() 
replacement?

--

___
Python tracker 

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

[issue12084] os.stat() on windows doesn't consider relative symlink

[STINNER Victor]

STINNER Victor  added the comment:

Oh oh. The situation is not a simple as expected. 3 functions only accept 
Unicode strings and 3 other functions decode "manually" byte strings from the 
ANSI code page.

--

chdir(), rmdir(), unlink(), access(), chmod(), link(), listdir(), 
_getfullpath(), mkdir(), utime(), open(), startfile(), unlink(), stat() and 
lstat() use the ANSI or the wide character API depending on the type of the 
input arguments.

rename(), symlink() and putenv() only use the wide character API. They use 
convert_to_unicode() to convert input arguments to Unicode. Byte strings are 
decoded from the file system encoding using the strict error error.

system(), readlink() and unsetenv() only accept Unicode strings.

--

Possible bugs.

unlink() uses DeleteFileA() for byte string and Py_DeleteFileW() for unicode. 
Py_DeleteFileW() has a special case for symbolic links:

/* override the default DeleteFileW behavior so that directory
symlinks can be removed with this function, the same as with
Unix symlinks */

unsetenv() encodes the variable name to UTF-8, which looks wrong to me.

startfile() encodes the second argument (operation) to UTF-8 and then decode it 
from ASCII to get a wchar_t* string. Why not using simply the "u" format to 
support more than ASCII characters?

It's surprising that unsetenv() only accept Unicode strings, because this 
Python function uses a C function with a bytes API (unsetenv).

--

___
Python tracker 

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

[issue12188] PEP 7, C style: add ++ policy and explanation

[Ezio Melotti]

Ezio Melotti  added the comment:

If there are a few of these idioms, I'm not against adding a new section  to 
PEP 7 (something like the "Programming Recommendations" section in the PEP 8).  
It's just not worth doing it for the "*p++ = x;" idiom alone IMHO.

--

___
Python tracker 

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

[issue12277] Missing comma in os.walk docs

[Petri Lehtinen]

Petri Lehtinen  added the comment:

Here's a patch.

--
keywords: +patch
nosy: +petri.lehtinen
Added file: http://bugs.python.org/file22272/docs_os_walk_add_comma.patch

___
Python tracker 

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

[issue12277] Missing comma in os.walk docs

[Petri Lehtinen]

Changes by Petri Lehtinen :


--
versions:  -Python 2.6, Python 3.4

___
Python tracker 

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

[issue12277] Missing comma in os.walk docs

[Petri Lehtinen]

Changes by Petri Lehtinen :


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

[issue11669] Clarify Lang Ref "Compound statements" footnote

[Petri Lehtinen]

Petri Lehtinen  added the comment:

Keywords suggest that there should to be a patch here. Where is it?

--
nosy: +petri.lehtinen

___
Python tracker 

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

[issue11277] Crash with mmap and sparse files on Mac OS X

[Steffen Daode Nurpmeso]

Steffen Daode Nurpmeso  added the comment:

Aehm, note that Apple has fixed the mmap(2) bug!!
I'm still surprised and can't really believe it, but it's true!
Just in case you're interested, i'll apply an updated patch.

Maybe Ned Deily should have a look at the version check, which
does not apply yet, but i don't know any other way to perform exact
version checking.  (Using 10.6.7 is not enough, it must be 10.7.0;
uname -a yet reports that all through, but no CPP symbol does!?)

--
Added file: http://bugs.python.org/file22273/11277.apple-fix.diff

___
Python tracker 

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

[issue12188] PEP 7, C style: add ++ policy and explanation

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> If there are a few of these idioms, I'm not against adding a new
> section  to PEP 7 (something like the "Programming Recommendations"
> section in the PEP 8).  It's just not worth doing it for the "*p++ =
> x;" idiom alone IMHO.

If these are recommandations, perhaps we should put them in the devguide
instead?

But I agree that it's not worth doing it only for "*p++" anyway.

--

___
Python tracker 

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

[issue11549] Build-out an AST optimizer, moving some functionality out of the peephole optimizer

[Eugene Toder]

Eugene Toder  added the comment:

Nick, if there's an interest in reviewing the patch I can update the it. I 
doubt it needs a lot of changes, given that visitor is auto-generated.

Raymond, the patch contains a rewrite of low-level optimizations to work before 
byte code generation, which simplifies them a great deal.

--

___
Python tracker 

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

[issue12274] "Print window" menu on IDLE aborts whole application

[R. David Murray]

Changes by R. David Murray :


--
nosy: +lukasz.langa

___
Python tracker 

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

[issue5906] Risk of confusion in multiprocessing module - daemonic processes

[Pascal Chambon]

Pascal Chambon  added the comment:

I've just crossed again the doc of the daemon flag 
(http://docs.python.org/library/multiprocessing.html), and it's still quite 
confusing to newcomers.

daemon
The process’s daemon flag, a Boolean value. This must be set before start() 
is called.
The initial value is inherited from the creating process. [1]
When a process exits, it attempts to terminate all of its daemonic child 
processes.

[1] this sentence is weird: since daemonic processes are not allowed to have 
children, isn't this flag always False in a new Process instance ?
[2] typo, it meant "all of its NON-daemonic child processes" instead, didn't it 
?

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

___
Python tracker 

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

[issue12238] Readline module loading in interactive mode

[R. David Murray]

R. David Murray  added the comment:

Python 3.3a0 (default:7323a865457a+, Jun  5 2011, 19:22:38) 
[GCC 4.5.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.modules['logging']
Traceback (most recent call last):
  File "", line 1, in 
KeyError: 'logging'
>>> sys.modules['os']


The difference is that logging is not imported at startup. So, however os (and 
friends, there are a lot of modules in sys.modules at startup) is imported, it 
is different from how readline.so is imported.

--

___
Python tracker 

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

[issue11784] multiprocessing.Process.join: timeout argument doesn't specify time unit.

[Petri Lehtinen]

Petri Lehtinen  added the comment:

The patch looks good to me and applies cleanly on top of 3.3 and 2.7.

--
nosy: +petri.lehtinen
versions: +Python 2.7, Python 3.3

___
Python tracker 

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

[issue12274] "Print window" menu on IDLE aborts whole application

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 0aa3064d1cef by Łukasz Langa in branch '3.2':
#12274: use proper escaping for % in IDLE config.
http://hg.python.org/cpython/rev/0aa3064d1cef

New changeset b410d013e7a8 by Łukasz Langa in branch 'default':
#12274: use proper escaping for % in IDLE config (merged from 3.2).
http://hg.python.org/cpython/rev/b410d013e7a8

--
nosy: +python-dev

___
Python tracker 

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

[issue12238] Readline module loading in interactive mode

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> The difference is that logging is not imported at startup. So, however
> os (and friends, there are a lot of modules in sys.modules at startup)
> is imported, it is different from how readline.so is imported.

For the record, os is imported by the _io module:

/* put os in the module state */
state->os_module = PyImport_ImportModule("os");
if (state->os_module == NULL)
goto fail;

(in Modules/_io/_iomodule.c)

This probably happens before sys.path is
adjusted/tweaked/fixed/garbled/whatever.

--

___
Python tracker 

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

[issue12274] "Print window" menu on IDLE aborts whole application

[Łukasz Langa]

Łukasz Langa  added the comment:

In 3.2 configparser started validating syntax in interpolation-aware parsers by 
default. I fixed the configuration.

It's unfortunate this configuration error hasn't been caught before in testing. 
We need a unit test for broken configuration and a change in IDLE so that it 
doesn't silently crash when configuration is invalid.

--
nosy: +kbk
stage:  -> test needed
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

[issue12084] os.stat() on windows doesn't consider relative symlink

[Brian Curtin]

Brian Curtin  added the comment:

I should have specified - the patch is for 3.2. 2.7 code in this area is 
different but I'll get to that, and default/3.3 will also get this patch but 
it'll probably require some tweaking.

I guess I went overboard on the refactoring which is why Victor is seeing 
errors and has the issues with Unicode related stuff. I'll have to put back in 
the narrow version of the win32_xstat_impl function for now. I'm not 
comfortable messing with something new and fancy this late in the cycle so I'll 
just go back to a structure that worked and figure out something better later 
on.


I'd rather figure out the test_rmdir_on_directory_link_to_missing_target stuff 
on another issue - this issue has already held up the release long enough.

--

___
Python tracker 

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

[issue12262] Not Inheriting File Descriptors on Windows?

[Jesse Litton]

Jesse Litton <3vi...@gmail.com> added the comment:

Yes, socat was compiled under cygwin.  I'll have to investigate whether I want 
to go the route of cygwin separately or just just leave the script as a pure 
stdin/out filter (since neither I nor the users have the cygwin environment 
installed).

After reading what you said, I re-read the MS notes 
(http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/redirection.mspx?mfr=true)
 and finally noticed the 'specific to each tool' text next to the description 
for handles 3-9.
 
Just to be sure, I came up with this simple test:

   echo test 1>&3 | set /P TEST= 0<&3

Which basically squashes my misconception, as it doesn't work.

So, I believe now that what I wanted is beyond the capabilities of the common 
Windows command shell, and this can be closed/invalid as not being a Python 
issue.  I also wish I was home using my Linux box about now.  :)

Thank you all very much for taking the time to help educate me on this!

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

___
Python tracker 

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

[issue12238] Readline module loading in interactive mode

[R. David Murray]

R. David Murray  added the comment:

Yeah, that would be my guess.  And readline.so is imported in main at a point 
where it has decided we are going into interactive mode, which is presumably 
after all other initialization has taken place, including the path munging.

Thus my suggestion that that particular import of readline.so should be special 
cased...

--

___
Python tracker 

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

[issue12242] distutils2 environment marker for current compiler

[Éric Araujo]

Éric Araujo  added the comment:

>> What would the value be for non-C Python implementations?

> I'm not really sure how this idea could have any value for those
> implementations, at least for the ones that can't make use of C
> extensions at all

The question was about the meaning of a new “compiler” environment marker.  
Would it be set to the empty string in Jython?  Not available?  Or do you think 
that there is no issue, since Jython would not try to compiler C files?

> I'm not entirely sure how common this is; even within those people
> who write C extensions, but I'm pretty sure some problems are
> unavoidable, such as compiler-specific options when linking to
> external libraries or compiler-specific ways of specifying
> compatibility options.

The SO page contains some pretty crude hacks.

Instead of putting more things into the PEP 345 environment markers, why not 
extend the extra_compile_args field to take a dictionary mapping regexes to 
match compiler names and versions to arguments?

In code:

Extension(..., extra_compile_args={'gcc': '-fo',
   'gcc .* 4.2': '-foo'})

In setup.cfg:

[build_ext] (or maybe extensions section)
extra_args =
  gcc = -fo
  gcc .* 4.2 = -foo

--

___
Python tracker 

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

[issue6056] socket.setdefaulttimeout affecting multiprocessing Manager

[Derek Wilson]

Derek Wilson  added the comment:

This should be higher priority as one of the major benefits of the 
multiprocessing module is remote process management in a completely transparent 
manner. socket timeouts are very important in this context as blocking forever 
waiting for a connection is not always an option. 

The problem of not being able to use a default socket timeout for other 
purposes in combination with multiprocessing managers is definitely an issue, 
but making multiprocessing actually use the timeout itself if set would be a 
huge advantage.

This might not be the place to ask for it, but it would make sense for manager 
objects to gain a timeout attribute to be used as a timeout for local or remote 
communications. At the very least, the manager.connect() method should accept a 
timeout argument.

--
nosy: +Derek.Wilson

___
Python tracker 

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

[issue12019] Dead or buggy code in importlib.test.__main__

[Éric Araujo]

Éric Araujo  added the comment:

Brett: Merging is hardly a hassle for me, nor would it take any time in this 
case (non-conflicting changes are applied by Mercurial itself).  I handle 
merges in projects that use multiple repositories, tons of clones, translation 
branches, so I’m a merge master :)

Georg: Thanks for confirming it’s not okay, I got confused for a bit about 
general Python policy vs. stricter distutils policy.  (I asked because I had 
set the 3.2 and 3.3 versions and Brett did not change them.)

--
status: open -> pending
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

[issue9302] distutils API Reference: setup() and Extension parameters' description not correct.

[Éric Araujo]

Éric Araujo  added the comment:

Sorry, I thought updating the status was enough to convey “I’m about to commit 
this”.

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

[issue12019] Dead or buggy code in importlib.test.__main__

[Georg Brandl]

Georg Brandl  added the comment:

I don't think our policy is that strict, i.e. I wouldn't revert the change if 
it was already committed.  But it's a bit slippery, and I'd rather have no 
behavior-changing "cleanups" end up in 3.2 originating in good intentions.

--
status: pending -> open

___
Python tracker 

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

[issue12019] Dead or buggy code in importlib.test.__main__

[Éric Araujo]

Éric Araujo  added the comment:

Agreed; I didn’t mean to imply that strict was restrictive, but that it was 
safe.

--

___
Python tracker 

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

[issue9302] distutils API Reference: setup() and Extension parameters' description not correct.

[R. David Murray]

R. David Murray  added the comment:

Um, no.

'pending' is 'pending close', specifically meaning, 'this issue is going to be 
closed (with a rejected status of some sort) unless someone objects or provides 
more information.'

Someday, pending issues will be autoclosed after N days.  Quite possibly this 
summer, since Ezio is working on roundup this summer.

--

___
Python tracker 

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

[issue11041] On the distutils2 documentation, 'requires-python' shouldn't be documented as *multi

[Roundup Robot]

Roundup Robot  added the comment:

New changeset d8d1bd2c4847 by Éric Araujo in branch 'default':
Fix documentation of requires-python field in setup.cfg (#11041)
http://hg.python.org/cpython/rev/d8d1bd2c4847

--
nosy: +python-dev

___
Python tracker 

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

[issue11092] Setup.cfg isn't packaged when running sdist

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 5940d2d82dee by Éric Araujo in branch 'default':
Fix sdist to always include setup.cfg (#11092), to comply with the spec
http://hg.python.org/cpython/rev/5940d2d82dee

--
nosy: +python-dev

___
Python tracker 

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

[issue9302] distutils API Reference: setup() and Extension parameters' description not correct.

[Éric Araujo]

Éric Araujo  added the comment:

Oh, thanks for clearing a misunderstanding I’ve had for a year!  I was using 
the pending status to prioritize issues (I have a personal “assigned to me + 
pending” query, now I’ll use priority instead.

--

___
Python tracker 

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

[issue9302] distutils API Reference: setup() and Extension parameters' description not correct.

[Éric Araujo]

Éric Araujo  added the comment:

This also explains why any new message cancels the pending status, BTW.

--

___
Python tracker 

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

[issue6884] Impossible to include file in sdist that starts with 'build' on Win32

[Éric Araujo]

Éric Araujo  added the comment:

I’m sorry I couldn’t fix this one in 3.1.  I didn’t take the time to download 
and install a Windows to test this year, and right now I don’t have the 
bandwidth.  I’ll get to it as soon as possible.

--
status: pending -> open
versions: +Python 3.3 -Python 3.1

___
Python tracker 

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

[issue12084] os.stat() on windows doesn't consider relative symlink

[Brian Curtin]

Brian Curtin  added the comment:

Victor - does the new patch pass all tests for you on 3.2?

--
Added file: http://bugs.python.org/file22274/issue12084_v2.diff

___
Python tracker 

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

[issue12279] Add build_distinfo command to packaging

[Éric Araujo]

New submission from Éric Araujo :

In the current packaging module, the PEP 376 .dist-info directory is generated 
at install time.  It should be split into two phases, build_distinfo and 
install_distinfo, to support at least two use cases:

- the develop command, which needs access to .dist-info
- the resources API (packaging.database.get_file), which is intended to work 
from an uninstalled codebase too.

The normal directory to put the generated files would be the build directory; 
however, setuptools’ egg_info command generates the file in the same directory 
as the setup.py file.  I’d prefer we avoid it in packaging, for consistency 
with other build_* commands, and to avoid that every project has to put 
“*.dist-info” in their VCS ignore file, but I don’t know if there is a 
technical reason that constrains setuptools to do so.

--
assignee: eric.araujo
components: Distutils2
keywords: gsoc
messages: 137842
nosy: alexis, eric.araujo, higery
priority: normal
severity: normal
stage: needs patch
status: open
title: Add build_distinfo command to packaging
type: feature request
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

[issue8668] Packaging: add a 'develop' command

[Éric Araujo]

Éric Araujo  added the comment:

FTR, Xu Dehai (higery) is working on this for GSoC.  We discussed the 
requirements on the mailing list: 
http://groups.google.com/group/the-fellowship-of-the-packaging/browse_thread/thread/ae196efc4956b9e2
This message in particular defines clearly the requirements: 
http://groups.google.com/group/the-fellowship-of-the-packaging/msg/9ef937cf2a90a882

--
dependencies: +Add build_distinfo command to packaging
nosy: +higery
stage:  -> needs patch

___
Python tracker 

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

[issue11041] On the distutils2 documentation, 'requires-python' shouldn't be documented as *multi

[Éric Araujo]

Changes by Éric Araujo :


--
assignee: tarek -> eric.araujo
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

[issue11092] setup.cfg isn't packaged when running sdist

[Éric Araujo]

Éric Araujo  added the comment:

This is now fixed.

--
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
title: Setup.cfg isn't packaged when running sdist -> setup.cfg isn't packaged 
when running sdist
type:  -> behavior
versions: +Python 3.3 -3rd party

___
Python tracker 

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

[issue7826] support caching for 2to3

[Éric Araujo]

Éric Araujo  added the comment:

FTR: https://github.com/pv/lib2to3cache

--
nosy: +eric.araujo

___
Python tracker 

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

[issue12019] Dead or buggy code in importlib.test.__main__

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 5392be94ea65 by Éric Araujo in branch 'default':
Kill dead code in importlib.test.__main__ (#12019, reviewed by Brett Cannon)
http://hg.python.org/cpython/rev/5392be94ea65

--
nosy: +python-dev

___
Python tracker 

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

[issue8927] Handle version incompatibilities in dependencies

[Éric Araujo]

Éric Araujo  added the comment:

As discussed on the Fellowship ML, ActiveState has implemented an algo for a 
smart dependency graph: https://github.com/ActiveState/depgraph

On the one hand, I think it’s not outside the scope of packaging.depgraph to be 
a bit smarter about dependencies.  On the other hand, this is still a deep 
research subject that’s by no means solved, so maybe keeping depgraph simple 
and dumb is more maintainable.

--
nosy: +srid
versions: +Python 3.3 -3rd party

___
Python tracker 

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

[issue12019] Dead or buggy code in importlib.test.__main__

[Éric Araujo]

Éric Araujo  added the comment:

I checked the patch again with ./python -m importlib.test and ./python 
Lib/importlib/test and committed.

--
resolution:  -> fixed
stage: commit 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

[issue8927] Handle version incompatibilities in dependencies

[Sridhar Ratnakumar]

Sridhar Ratnakumar  added the comment:

The only way to fix this is to /not/ install *any* packages prior to resolving 
*all* dependencies ... which means that there needs to be a way to resolve the 
entire dependency graph for any given package in PyPI.

If PyPI provided a mechanism to fetch the entire dependency graph[1], then 
https://github.com/ActiveState/depgraph can be used to implement comprehensive 
dependency resolution. PyPM can do this because the PyPM repository provides a 
sqlite db containing dependency information for all packages and their versions.

Let me know if you need any assistance regarding ActiveState's depgraph 
implementation (I may have pending commits to be merged to the GitHub repo)

[1] I posted a few suggestions in regards to facilitating such exposure of 
static metadata in PyPI to distutils-sig@ - but until this day they remain as 
merely ideas.

--

___
Python tracker 

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

[issue8927] Handle version incompatibilities in dependencies

[Éric Araujo]

Éric Araujo  added the comment:

> The only way to fix this is to /not/ install *any* packages prior to
> resolving *all* dependencies

packaging.install rolls back in case of error, so the system can’t be left in a 
half-installed state.  p7g.install is only as smart as p7g.depgraph, however.

> which means that there needs to be a way to resolve the entire
> dependency graph for any given package in PyPI.

PyPI exposes requires, obsoletes and provides for releases that upload PEP 345 
metadata; client code using p7g.pypi and p7g.depgraph can then build a 
dependency graph.

> the PyPM repository provides a sqlite db containing dependency
> information for all packages and their versions.

This experiment with a local copy of the full repo graph is interesting.  Do 
you have blog posts or something talking about synchronization issues, dealing 
with multiple repositories, using SQL vs. something less ugly , etc.?

> Let me know if you need any assistance regarding ActiveState's
> depgraph implementation

First, what we need here is a pronouncement from Tarek about smarter depgraph 
vs. simple stupid depgraph.  If we decide to improve depgraph, ideas from your 
code will have to be extracted and ported.  This will probably require a 
contributor agreement.

--

___
Python tracker 

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

[issue12273] Change ast.__version__ calculation to provide consistent ordering

[Éric Araujo]

Changes by Éric Araujo :


--
nosy: +eric.araujo

___
Python tracker 

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

[issue12278] Core mentorship mention in the devguide

[Éric Araujo]

Éric Araujo  added the comment:

Thanks for the patch.  I think it should be rewritten a bit:
> If you are interested in improving Python and contributing to its development,
> `Python Mentors`_ are here to help you.

python-ideas and python-dev are open to new people interested in contributing, 
not only python-mentors; the specificity of the latter is that it is intended 
as very user friendly.

--
nosy: +eric.araujo

___
Python tracker 

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

[issue11203] gzip doc is behind

[Éric Araujo]

Éric Araujo  added the comment:

> This implies that it also supports close().
One has to follow the link to BufferedIOBase and then to IOBase, but I think 
it’s okay.

Richard: Does that address your issue?

--

___
Python tracker 

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

[issue12277] Missing comma in os.walk docs

[Éric Araujo]

Éric Araujo  added the comment:

I have included this in a patch I’m preparing to fix several typos at once.

--
assignee: docs@python -> eric.araujo
nosy: +eric.araujo

___
Python tracker 

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

[issue12273] Change ast.__version__ calculation to provide consistent ordering

[Benjamin Peterson]

Benjamin Peterson  added the comment:

I propose we leave ast.__version__ alone. Using ast.__version__ at all should 
be a very advanced usecase. Generally, you should just be able to look at 
sys.version_info. We could document this rather than duplicating 
sys.version_info in ast.__version__. I think ast.__version__ is mostly useful 
for things like:

print("Running with Python {} and AST {}".format(sys.mercurial[2], 
ast.__version__)

--

___
Python tracker 

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

[issue9205] Parent process hanging in multiprocessing if children terminate unexpectedly

[Charles-François Natali]

Charles-François Natali  added the comment:

> Ok, the dependencies are now committed. Here is a new patch addressing 
> Charles-François' comments: select() is now called before each call to read() 
> when sentinels are given, to avoid race conditions.

The patch looks fine to me (but I didn't look at win32-specific code).

--

___
Python tracker 

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

[issue8927] Handle version incompatibilities in dependencies

[Sridhar Ratnakumar]

Sridhar Ratnakumar  added the comment:

On 2011-06-07, at 9:48 AM, Éric Araujo wrote:

> 
> Éric Araujo  added the comment:
> 
>> The only way to fix this is to /not/ install *any* packages prior to
>> resolving *all* dependencies
> 
> packaging.install rolls back in case of error, so the system can’t be left in 
> a half-installed state.  p7g.install is only as smart as p7g.depgraph, 
> however.

Well, if the same behavior is adopted for dependency conflicts (eg: see issue 
description) as well, it would necessitate rolling back by uninstalling the 
previous N packages, then installing these N packages (again) by traversing a 
different path (and repeat for other conflicts), would it not?

>> which means that there needs to be a way to resolve the entire
>> dependency graph for any given package in PyPI.
> 
> PyPI exposes requires, obsoletes and provides for releases that upload PEP 
> 345 metadata; client code using p7g.pypi and p7g.depgraph can then build a 
> dependency graph.

Not all packages upload their release sources (thus metadata) to PyPI, which is 
why - I believe - PIP is scraping the Simple Index and home_page urls to get 
the appropriate sdist for any package. I am not fully aware of what kind of 
packages p7g.install is supposed to support, though. I assume that 
setuptools-style projects (using install_requires) are not supported by 
p7g.install.

>> the PyPM repository provides a sqlite db containing dependency
>> information for all packages and their versions.
> 
> This experiment with a local copy of the full repo graph is interesting.  Do 
> you have blog posts or something talking about synchronization issues, 
> dealing with multiple repositories, using SQL vs. something less ugly , 
> etc.?

The local index cache is automatically updated not more than once a day. 
Multiple repositories are searched in the configured order (linearly). SQL is 
just a data format, the remote index can be of any format (xml, json, pickle, 
..) as long as the client can easily query the dependency chain.

But its probably much simpler to only expose per-package dependency (and other 
metadata) through REST urls (at the cost of network delays, however). No index 
is required. Eg:

http://pypi.python.org/metadata/scipy/0.9.0/DIST-INFO -> requires, 
obsoletes, etc...

(of course, this assumes that even packages that do not upload their sdists 
have the metadata available in PyPI somehow; perhaps the server caches them. we 
have our own pypi-like mirror that does this)

--

___
Python tracker 

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

[issue11203] gzip doc is behind

[K Richard Pixley]

K Richard Pixley  added the comment:

My point was for python-2.7.  I haven't stumbled into the buffer protocol yet.  
So no, it doesn't really.

I still think the documentation, especially the 2.7 doc, could be more explicit.

My concern here is with the use of close() becoming obscure, a second class 
citizen, or an afterthought.  While I greatly appreciate the context manager, 
there are times when I want an enduring open channel for which the context 
manager just isn't appropriate.  Even in a world with context manager, open and 
close need to be available and presented as a pair.

It isn't clear to me from reading the doc or looking at the examples that gzip 
is expected to support a close call.  Yes, I concur that there is an 
implication, but I would prefer to see it stated explicitly along with the 
explicit statement that it supports an open call.

--

___
Python tracker 

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

[issue8927] Handle version incompatibilities in dependencies

[Éric Araujo]

Éric Araujo  added the comment:

Tarek’s reply on IRC:

> I think we should make it dumb: in case of a conflict, it's always
> better/simpler to let the user deal with it.  A simple "could not
> install because you have package X version Y installed'.  Trying to do
> something smarter is very very hard and will probably fail.

About adding smarts to deal with simple cases like the one you mentioned in 
your email:
> If we provide automation for simple cases, people will want more.

So I think we’re leaning towards rejecting this.  pysetup is a simple installer 
for simple installs; pip and other installers will use the information returned 
by packaging.depgraph/install to be smart about conflicts.

--

___
Python tracker 

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

[issue6474] Inconsistent TypeError message on function calls with wrong number of arguments

[Benjamin Peterson]

Benjamin Peterson  added the comment:

Hopefully this situation was improved by #12265.

--

___
Python tracker 

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

[issue6056] socket.setdefaulttimeout affecting multiprocessing Manager

[Jesse Noller]

Jesse Noller  added the comment:

I agree derek, I think that would be a fine addition, however we lack a patch 
and I don't have the current bandwidth to add it.

--

___
Python tracker 

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

[issue11975] Fix referencing of built-in types (list, int, ...)

[Jonas H.]

Jonas H.  added the comment:

Having one page with two objects of the same name, e.g.

  .. function:: foo

  .. class:: foo

renders to two entries with the same anchor name (#foo). The first entry gets a 
link-to-this-paragraph marker, the second one doesn't.

Internal references (from within the same document) always link to the first 
entry because they use #foo anchor. (So if you put the class directive first, 
all links go to the class anchor.)

The first external reference (using intersphinx) always goes to the first 
target document element - no matter which type both have. The second reference 
isn't turned into a hyperlink.

This behaviour seems consistent with how HTML anchors work.

Having the two objects on two different pages however shows slightly odd 
results. Say we have this code on page 1:

  .. class:: foo

  :class:`foo`
  :func:`foo`

and

  .. function:: foo

on page 2, then both links in page 1 go to the page 1 'foo' (the class). 
However if you change order (putting the func role before the class role), 
those links go to the page 2 'foo' (the function).

All intersphinx-ed links go to the object on page 1, no matter the role order 
on page 1 or the external page.


I think we can conclude that using class and function directives at the same 
time doesn't help very much...

--

___
Python tracker 

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

[issue12278] Core mentorship mention in the devguide

[Adam Woodbeck]

Adam Woodbeck  added the comment:

Éric, good point.  I'll propose different wording when I have an opportunity 
later today.  In the mean time, I'm certainly open to suggestions, especially 
as I get my feet wet.

So you would also prefer a mention of the python-ideas and python-dev mailing 
lists, where the former is primarily for suggesting new development ideas, and 
the latter is for core language discussion.  Correct?

--

___
Python tracker 

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

[issue11203] gzip doc is behind

[Éric Araujo]

Éric Araujo  added the comment:

In 2.7, while there is no index-generating entry for the close method, it is 
mentioned: “Calling a GzipFile object’s close() method [...]”.

> Yes, I concur that there is an implication, but I would prefer to see
> it stated explicitly along with the explicit statement that it
> supports an open call.

I wouldn’t like to see the docs for int, float, complex, Decimal, Fraction, 
GzipFile, BZ2File, BytesIO, StringIO and all others having duplicated lists of 
methods and attributes that are already documented in the doc of the ABC.

--

___
Python tracker 

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

[issue6474] Inconsistent TypeError message on function calls with wrong number of arguments

[Oleg Oshmyan]

Oleg Oshmyan  added the comment:

Unfortunately it was not.

>>> Extension('myext', define_macros=[])
Traceback (most recent call last):
  File "", line 1, in 
TypeError: __init__() takes from 3 to 17 positional arguments but 3 were given

The issue is that the message tries to differentiate between positional and 
keyword arguments, while it really should differentiate between required and 
optional ones.

--

___
Python tracker 

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

[issue11203] gzip doc is behind

[K Richard Pixley]

K Richard Pixley  added the comment:

An interesting point, although I think that's only relevant if the 
documentation lists the ABC and a reference to it.  (python-3 doc essentially 
does this.)

I see no such reference in the 2.7 gzipfile doc, which leads me to believe, 
(from the doc alone), that it's an independent implementation of a "file like 
object".

This may not be important enough to even merit the time we've already put into 
it.  Please feel free to close this ticket without change if you prefer.

--

___
Python tracker 

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

[issue8927] Handle version incompatibilities in dependencies

[Éric Araujo]

Éric Araujo  added the comment:

> Not all packages upload their release sources (thus metadata) to PyPI
No, it’s register that uploads metadata.

> which is why - I believe - PIP is scraping the Simple Index and
> home_page urls to get the appropriate sdist for any package.
Yes, the screen scraping in setuptools comes from the fact that not all 
projects upload distributions on PyPI.  (Actually, setuptools did the screen 
scraping before PyPI supported distributions upload.)

> I am not fully aware of what kind of packages p7g.install is supposed
> to support, though. I assume that setuptools-style projects (using
> install_requires) are not supported by p7g.install.
I think they are, or if not it’s a missing feature we want to support.  Kelsey 
and Alexis know more about that topic.  See recent threads on Fellowship.

> But its probably much simpler to only expose per-package dependency
> (and other metadata) through REST urls
RESTful PyPI is Alexis’ pony :)  Right know, the XML-RPC exposes the metadata, 
including PEP 345 Requires-Dist if the release provided it.

--

___
Python tracker 

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

[issue11203] gzip doc is behind

[Éric Araujo]

Éric Araujo  added the comment:

> I see no such reference in the 2.7 gzipfile doc

Did you miss the first part of my previous message?  The 2.7 docs for GzipFile 
do not link to the ABC, but they mention the close method in plain text.

--

___
Python tracker 

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

[issue11277] Crash with mmap and sparse files on Mac OS X

[Ned Deily]

Ned Deily  added the comment:

Thanks for the update.  Since the fix will be in a future version of OS X 10.7 
Lion, and which has not been released yet, so it is not appropriate to change 
mmap until there has been an opportunity to test it.  But even then, we would 
need to be careful about adding a compile-time test as OS X binaries are often 
built to be compatible for a range of operating system version so avoid adding 
compilation conditionals unless really necessary.  If after 10.7 is released 
and someone is able to test that it works as expected, the standard way to 
support it would be to use the Apple-supplied availability macros to test for 
the minimum supported OS level of the build assuming it makes enough of a 
performance difference to bother to do so: 
http://developer.apple.com/library/mac/#technotes/tn2064/_index.html

(Modules/_ctypes/darwin/dlfcn_simple.c is one of the few that has this kind of 
test.)

--

___
Python tracker 

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

[issue11203] gzip doc is behind

[K Richard Pixley]

K Richard Pixley  added the comment:

I didn't miss it.

I think the close call needs equal treatment to the open call.  The mention is 
certainly present, but seems implicit to me.  I would prefer to see it listed 
explicitly.

But I also don't think it's important enough in the 2.7 docs to discuss it much 
further.  You've convinced me that it's not worth fixing.  Let's drop it.

--

___
Python tracker 

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

[issue11595] Miscellaneous bugs in cfg_to_args() utility function

[Éric Araujo]

Éric Araujo  added the comment:

Can you refresh your patch for packaging?

--
assignee: tarek -> eric.araujo
stage:  -> patch review
type:  -> behavior
versions: +Python 3.3 -3rd party

___
Python tracker 

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

[issue11200] Addition of abiflags breaks distutils

[Éric Araujo]

Éric Araujo  added the comment:

Now fixed in packaging too.

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

___
Python tracker 

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

[issue8927] Handle version incompatibilities in dependencies

[Dave Abrahams]

Dave Abrahams  added the comment:

I'm sorry, but it is simply not true that this is not a solved problem.  This 
is a well-understood problem that's solved --- at least as well as anyone could 
want it to be --- by aptitude (not apt-get) and by 
http://en.opensuse.org/openSUSE:Libzypp_satsolver

--

___
Python tracker 

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

[issue12021] mmap.read requires an argument

[Petri Lehtinen]

Petri Lehtinen  added the comment:

It seems I did. Attached now for real :)

--
Added file: http://bugs.python.org/file22275/mmap_read_all_4.patch

___
Python tracker 

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

[issue8927] Handle version incompatibilities in dependencies

[Sridhar Ratnakumar]

Sridhar Ratnakumar  added the comment:

On 2011-06-07, at 10:39 AM, Éric Araujo wrote:

> Éric Araujo  added the comment:
> 
>> Not all packages upload their release sources (thus metadata) to PyPI
> No, it’s register that uploads metadata.

(was not sent before?)

Ok, that's interesting. Does p7g.install support packages that do not register 
their new releases?

Setuptools/PIP does by scraping the project home pages.

Eg: http://pypi.python.org/pypi/PyChecker incorrectly (but expected) shows 
0.8.12 as latest, but http://pychecker.sourceforge.net/ shows 0.8.19 as the 
latest. Will p7g.install install 0.8.19?

--

___
Python tracker 

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

[issue8927] Handle version incompatibilities in dependencies

[Sridhar Ratnakumar]

Sridhar Ratnakumar  added the comment:

Dave, but aptitude contains a local index of all dependency information. 
Whereas, PyPI's infrastructure and pip/easy_install/p7g.install do not rely on 
one. Therefore, I think when Tarek said "Trying to do something smarter is very 
very hard and will probably fail." he is referring to doing such dependency 
resolution *with* the constraint of lack of such local metadata index.

--

___
Python tracker 

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

[issue12242] distutils2 environment marker for current compiler

[Eli Collins]

Eli Collins  added the comment:

> The question was about the meaning of a new “compiler” environment
> marker.  Would it be set to the empty string in Jython?  Not available?
>  Or do you think that there is no issue, since Jython would not try to
> compiler C files?

Ah, my bad. I _had_ misunderstood your question. Those cases would definitely 
need to have more properly defined behavior. As well, my attempt at my original 
idea convinced me that it may be difficult/impossible to implement an 
environment marker whose value may depend on per-command options. All told, I 
think your dict idea is probably a much better route to take (and more powerful 
to boot). 

I'll try to work up a patch implementing something along the lines you 
suggested. One issue is that multiple compiler patterns may match, so it might 
be better to use a list instead of a dict... and since extra_compile_args is 
already a list, it might be cleaner (and break less existing code) if I 
implemented a new argument entirely, eg "specific_compile_args" / 
"specific_link_args"; which took [ (pattern, option_str) ... ], and used the 
first pattern that matches (if any).

--

___
Python tracker 

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

[issue11457] Expose nanosecond precision from system calls

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

On Fri, Jun 3, 2011 at 6:52 PM, Martin v. Löwis  wrote:
..
>> One reason is the desire to avoid loading Python module from a
>> C-module.
>
> This desire is indeed no guidance for Python development; the opposite
> is the case.

Can you elaborate on this?  I did notice the current trend of mixing
software layers and welcoming circular dependencies in Python stdlib,
but I am not sure this is a good thing.  In the good old times imports
inside functions where frowned upon.  (And for many good reasons.)
Imports from inside C functions seem to be even worse.  Tricks like
this greatly reduce understandability of the code.  The import
statements at the top of the module tell a great deal about what the
module can and cannot do.  When modules can be imported at will as a
side-effect of innocuous looking functions (time.strptime is my
personal pet peeve), analysis of the programs becomes much more
difficult.

>  The only exception may be bootstrapping issues, which I
> claim are irrelevant in this case.

It is hard to tell without attempting an implementation, but my
intuition is exactly the opposite.  I believe parts of the import
mechanism have been implemented in Python and it seems to me that
os.stat() may need to be available before decimal can be imported.

--

___
Python tracker 

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

[issue8927] Handle version incompatibilities in dependencies

[Dave Abrahams]

Dave Abrahams  added the comment:

That's quite true.  However, I don't think a local index is needed if there's a 
remote index; you're already looking in a remote index, albeit a 
less-completeone.  And it could be maintained automatically from individual 
package metadata.  Maybe that's out of scope for this project, though.

--

___
Python tracker 

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

[issue11595] Miscellaneous bugs in cfg_to_args() utility function

[Erik Bray]

Erik Bray  added the comment:

Done.  Also added support for multi-valued description-file values.

--
Added file: http://bugs.python.org/file22276/issue11595-2.patch

___
Python tracker 

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

[issue12273] Change ast.__version__ calculation to provide consistent ordering

[R. David Murray]

R. David Murray  added the comment:

I think you should just kill ast.__version__ in that case.  There was a 
discussion on python-dev and packaging about __version__ and PEP 396 was the 
result.  If you want the VCS info put it somewhere else (like __vcs_version__?).

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

[issue7511] msvc9compiler.py: ValueError when trying to compile with VC Express

[Stefan Krah]

Stefan Krah  added the comment:

Marc-Andre Lemburg  wrote:
> >> >> Regarding the latest patch: This is not the right approach, since
> >> >> find_vcvarsall() is supposed to return the path to the vcvarsall.bat
> >> >> file and not an architecture specific setup file. It is later
> >> >> called with the arch identifier, which the arch specific setup files
> >> >> don't check or use.
> > > 
> > > The patch does not change anything for Visual Studio Pro. In Visual Studio
> > > Express (+SDK) vcvarsall.bat is broken, so the architecture specific setup
> > > files have to be used (they also work with a superfluous parameter).
> 
> I guess what I wanted to say is that find_vcvarsall() should
> return None for VC Express and code using it should then
> revert to using a new find_vcvars() function, which takes the
> architecture as parameter and returns the path to the correct
> architecture setup file.
> 
> Hacking the support into find_vcvarsall() is not the right
> approach. You have to add this support one level further up.

I agree that it is nicer if find_vcvarsall() actually returns vcvarsall.
The next level though is query_vcvarsall(), so it would still be wrong
to query vcvars64 in that function.

So unless query_vcvarsall() is renamed to something neutral like set_vcvars(),
I'm not sure where to add the support. But I imagine that renaming is out of
the question.

--

___
Python tracker 

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

[issue7511] msvc9compiler.py: ValueError when trying to compile with VC Express

[R. David Murray]

Changes by R. David Murray :


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

[issue12243] getpass.getuser works on OSX

[Bryce Verdier]

Bryce Verdier  added the comment:

I like the idea as well. But I'm not sure what is needed in order to help.

--

___
Python tracker 

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