[issue10483] http.server - what is executable on Windows

[Martin v . Löwis]

Martin v. Löwis  added the comment:

> Martin, that is an interesting viewpoint, and one I considered, but
> didn't state, because it seems much too restrictive.  Most CGI
> programs are written in scripting languages, not compiled to .exe.
> So it seems the solution should allow for launching at least Perl and
> Python scripts, as well as .exe.

Notice that it does support launching Python scripts. I disagree that
Perl scripts need to be supported. The idea of CGI is really that
"programs" get run by the web server, with the notion of "programs"
clearly deviating from system to system. Window really doesn't support
"scripts" (in the hash-bang sense), and it isn't the function of
http.server to extend Windows here. At best, support for .bat files
might be negotiable, using cmd.exe to launch them (but I personally
would not).

Anybody who wants support for other kinds of scripts on Windows will
have to subclass CGIHTTPRequestHandler (and it might be useful to
simplify subclassing that class).

In any case, the bug as stated ("def executable is simply wrong")
has a clear resolution - make it match what the rest of the code
supports. Anything beyond that is a feature request.

--

___
Python tracker 

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

[issue1284316] Win32: Security problem with default installation directory

[Gynvael Coldwind]

Gynvael Coldwind  added the comment:

(since Issue 10491 is superseded by this one, I'll reply here)

As I've said in issue 10491, in my opinion this is not a case of frustrating 
users because they have to elevate the console (I think they have to do that in 
case of UAC anyway), but a case of privilege escalation vulnerability on 
mutli-user Windows systems with Python installed globally (i.e. in the default 
installation directory).

Though I am aware there are not many such systems to begin with, I am pretty 
certain they do exist (think: servers at an University giving Python access to 
students, and not using *nix for some reason).
There are also non-multi-user systems with multiple accounts (think: production 
systems running stuff on different accounts), and this issue can be abused as 
one of many steps during an attack, after gaining shell access, but before 
gaining administrative rights.

I acknowledge your right to choose not to fix this issue due to usability 
issues, but in such case imo there should be an explicit message during the 
installation making the user aware of this insecurity.
The last months revealed issues like this in many applications and tools, and 
they have (mostly) been patched, so administrators might assume this was also 
fixed in Python (especially since this is known from 2005).

--
nosy: +Gynvael.Coldwind

___
Python tracker 

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

[issue10459] missing character names in unicodedata (CJK...)

[Martin v . Löwis]

Martin v. Löwis  added the comment:

For 3.2, this now fixed in r86681.

--

___
Python tracker 

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

[issue10500] Palevo.DZ worm msix86 installer 3.x installer

[Vil]

New submission from Vil :

scan on msi installer x86 win 3.x python gives Win32/Palevo.DZ worm and erases.

--
messages: 122101
nosy: VilIgnoble
priority: normal
severity: normal
status: open
title: Palevo.DZ worm msix86 installer 3.x installer
type: security
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

[issue10483] http.server - what is executable on Windows

[Glenn Linderman]

Glenn Linderman  added the comment:

The rest of the code has clearly never had its deficiencies exposed on Windows, 
simply because executable() has prevented that.  So what the rest of the code 
"already supports" is basically nothing.  Reasonable Windows support is 
appropriate to implement as part of the bugfix.

You state that it isn't the function of http.server to extend Windows, however, 
even MS IIS has extended Windows to provide reasonable web scripting 
functionality, albeit it its own way, thus convicting the Windows facilities of 
being insufficient.  Attempting to use http.server to get a web testing 
environment running so that Python scripts can be tested locally requires some 
way of using an existing environment (except, of course, for "all new" web 
sites).  I suppose you would claim that using http.server for a web testing 
environment is an inappropriate use of http.server, also.  

Yet http.server on Unix appears to provide an adequate web testing environment: 
yes, some of that is because of Unix's #! feature.  This would certainly not be 
the first case where more code is required on Windows than Unix to implement 
reasonable functionality.

My desire for support for Perl is not an attempt to convince Python developers 
to use Perl instead of Python, but simply a reflection of the practicality of 
life: There are a lot of Perl CGI scripts used for pieces of Web servers.  
Reinventing them in Python may be fun, but can be more time consuming than 
projects may have the luxury to do.

Your claim that it already supports Python CGI scripts must be tempered by the 
documentation claim that it provides "altered semantics".  "altered semantics", 
as best as I can read in the code, is that the query string is passed to the 
Python script as a command line if it doesn't happen to contain an "=" sign.  
This is weird, unlikely to be found in a real web server, and hence somewhat 
useless for use as a test server also.

http.server has chosen to use subprocess which has chosen to use CreateProcess 
as its way of executing CGI.  There are other Windows facilities for executing 
programs, such as ShellExecute, but of course it takes the opposite tack: it 
can "execute" nearly any file, via registry-based associations.  Neither of 
these seem to be directly appropriate for use by http.server, the former being 
too restrictive without enhancements, the latter being too liberal in executing 
too many file types, although the requirement that CGI scripts live in specific 
directories may sufficiently rein in that liberality.

However, you have made me think through the process: it seems that an 
appropriate technique for Windows is to allow for a specific set of file 
extensions, and permit them to be executed using the registry-based association 
to do so.  However, for .cgi files, which depend heavily on the Unix #!, 
emulation of #! seems appropriate (and Windows doesn't seem to have an 
association for .cgi files either).

Your suggestion of making CGIHTTPRequestHandler easier to subclass is certainly 
a good one, and is almost imperative to implement to fix this bug in a useful 
manner without implementing an insufficient set of Windows extensions (for 
someone's definition of wrong).  There should be a way to sidestep the "altered 
semantics" for Python scripts (and Python scripts shouldn't have to be a 
special case, they should work with the general case), without replacing the 
whole run_cgi() function.  There should be a hook to define the list of 
executable extensions, and how to run them, and/or a hook to alter the command 
line passed to subprocess.Popen to achieve same.

So is_executable and is_python both seem to currently be replacable.  What is 
missing is a hook to implement cmdline creation before calling 
subprocess.Popen()  (besides the other reported bugs, of course)

--

___
Python tracker 

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

[issue10231] SimpleHTTPRequestHandler directory bugs

[Hallvard B Furuseth]

Hallvard B Furuseth  added the comment:

Senthil Kumaran writes:
> I have doubts on the validity of this bug itself.
> 
> - First is, query and fragment are usually for the file being served
> from the webserver, not on the directories. If there are characters such
> as '?' and '#' in the directory names, which may get featured in the
> path, then those should be quoted in the request. So foo/dir?baz is
> wrong where as foo/dir%3Fbaz it the correct request.

That's backwards.  Start with the URL spec (RFC 3986), not with
thinking of filesystem paths.  If '?' or '#' do occur in the URL, they
are not part of the path.  That is the case this bug report is about.

That's because it reserves these characters for query and fragment.
So yes, the if filesystem path contains '?' or '#', these must be
escaped in the URL.

--

___
Python tracker 

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

[issue10501] make_buildinfo regression with unquoted path

[Martin]

New submission from Martin :

My build got broken by the change for issue 9981 in revision 86137. The problem 
is it adds $(IntDir) to various places in the vcproj file, including the 
command line arguments to make_buildinfo, and my svn checkout is under a dir 
with a space in.

Ideally it could just use a relative path, but just making sure it's quoted 
works too.

--
components: Build
files: issue9981_regression.patch
keywords: patch
messages: 122104
nosy: gz, krisvale
priority: normal
severity: normal
status: open
title: make_buildinfo regression with unquoted path
versions: Python 3.2
Added file: http://bugs.python.org/file19769/issue9981_regression.patch

___
Python tracker 

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

[issue10470] python -m unittest ought to default to discovery

[Michael Foord]

Michael Foord  added the comment:

Eli - I quite agree. TestProgram is a *particularly* obscure part of unittest. 
A much better solution (well - both would be ideal) would be to refactor the 
code so that it isn't so obscure.

TestProgram is an artefact of unittest's history and should be a series of 
functions rather than a class.

--

___
Python tracker 

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

[issue9771] add an optional "default" argument to tokenize.detect_encoding

[STINNER Victor]

STINNER Victor  added the comment:

> no cookie found, returns ('utf-8', [line1, line2])

I never understood the usage of the second item. IMO it should be None if no 
cookie found.

--

___
Python tracker 

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

[issue10459] missing character names in unicodedata (CJK...)

[Martin v . Löwis]

Martin v. Löwis  added the comment:

The patch for 3.1 is r86685. The patch for 2.7 is r86686.

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

[issue10483] http.server - what is executable on Windows

[Martin v . Löwis]

Martin v. Löwis  added the comment:

> Your suggestion of making CGIHTTPRequestHandler easier to subclass is
> certainly a good one, and is almost imperative to implement to fix
> this bug in a useful manner without implementing an insufficient set
> of Windows extensions (for someone's definition of wrong).

It's indeed the approach I would prefer over the alternatives you
suggested - I particularly dislike Python implementing a strategy
where #! files become considered on Windows (you then immediately
run into subsequent problems, such as /usr/bin/perl being no valid
filename on most Windows installations).

So I maintain that technically, in order to resolve the *reported*
issue (msg121875), it is sufficient to define that executables
on Windows are the files ending with .exe. To recall, the reported
issue is "is simply wrong ... is not clear what to use instead"
(to you as the reporter). My job as a maintainer is to resolve this,
and I will decide to resolve this as suggested. Even the refactoring
to allow substitution of process creation is an independent feature,
but I'm willing to accept patches.

--

___
Python tracker 

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

[issue10501] make_buildinfo regression with unquoted path

[Martin v . Löwis]

Martin v. Löwis  added the comment:

Kristjan, can you take a look?

--
assignee:  -> krisvale
nosy: +loewis

___
Python tracker 

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

[issue1675455] Use getaddrinfo() in urllib2.py for IPv6 support

[Senthil Kumaran]

Changes by Senthil Kumaran :


--
assignee: facundobatista -> orsenthil
nosy:  -BreamoreBoy

___
Python tracker 

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

[issue10483] http.server - what is executable on Windows

[Senthil Kumaran]

Changes by Senthil Kumaran :


--
nosy: +orsenthil

___
Python tracker 

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

[issue10502] Add unittestguirunner to Tools/

[Michael Foord]

New submission from Michael Foord :

Add the unittestgui test runner, built with Tk, to the Tools directory.

It would be good to have this script included in the bin/ directory of the Mac 
installer as well.

The unittestgui runner can be found at:

https://bitbucket.org/markroddy/unittestgui

The code is a modification of the original unittestgui by Steve Purcell and 
updated for test discovery by Mark Roddy. I have asked Mark if he is willing to 
help maintain the code and asked him to complete a contributor agreement.

--
assignee: michael.foord
components: Library (Lib)
messages: 122110
nosy: michael.foord, ronaldoussoren
priority: low
severity: normal
stage: needs patch
status: open
title: Add unittestguirunner to Tools/
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

[issue10502] Add unittestguirunner to Tools/

[Michael Foord]

Michael Foord  added the comment:

It will need documenting, or at least pointing to in the documentation, 
probably with a note recommending Hudson for production use - unittestgui is a 
tool for beginners / convenience.

Note also that Brian Curtin has contributed a patch to make unittestgui Python 
3 compatible. This has not yet been 'merged upstream':

http://lists.idyll.org/pipermail/testing-in-python/2010-November/003604.html

--
nosy: +brian.curtin

___
Python tracker 

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

[issue7257] Improve documentation of list.sort and sorted()

[Ole Laursen]

Ole Laursen  added the comment:

Okay. I can only say that while the current docstrings are likely good 
reminders for you, knowing Python in and out, they were pretty useless to me as 
documentation, which I believe docstrings should be, they're called docstrings, 
after all, not reminderstrings. :) I fail to see how including more info can 
hurt in any way, you're not forced to read it if you don't need it, so I hope 
you (or somebody else) will reconsider at some point.

--

___
Python tracker 

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

[issue10501] make_buildinfo regression with unquoted path

[Kristján Valur Jónsson]

Kristján Valur Jónsson  added the comment:

Ah yes, spaces in filenames.  One always forgets.
Fixed the make_buildinfo.c (quote whole string, not just part of it) and 
committed in revision 86689

--
resolution:  -> accepted
status: open -> closed

___
Python tracker 

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

[issue8890] Use tempfile instead of /tmp in examples

[Vinay Sajip]

Vinay Sajip  added the comment:

Actually, I don't think it's a great idea in general to use temporary files for 
logging, though of course there are specific cases where one might do this. So 
for the logging examples in the docs (which used '/tmp/XXX') I just removed the 
'/tmp/' part.

--

___
Python tracker 

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

[issue8525] Small enhancement to help()

[Rob Cliffe]

Rob Cliffe  added the comment:

Thanks for your work.  Glad if I have made a contribution to Python, 
however small.
Rob Cliffe

On 22/11/2010 00:26, Éric Araujo wrote:
> Éric Araujo  added the comment:
>
> Thank you.  I uploaded your patch to Rietveld and reviewed it: 
> http://codereview.appspot.com/3169042/
>
> --
>
> ___
> Python tracker
> 
> ___
>

--

___
Python tracker 

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

[issue8525] Small enhancement to help()

[Rob Cliffe]

Rob Cliffe  added the comment:

I would not be at all surprised if my patch could be simplified (in fact 
I'd be surprised if it couldn't).
However, I did try out your version on Python 2.5 specifically, and it 
did not work for me.
Trying it out on help(Exception), the relevant members of 
object.__subclasses__() viz.
,   etc.
had a __module__attribute which equalled 'exceptions', not 'builtins'.
Best wishes
Rob Cliffe

On 22/11/2010 01:33, Alexander Belopolsky wrote:
> Alexander Belopolsky  added the comment:
>
> The following passes tests in elp_8525.patch, but is much simpler:
>
> ===
> --- Lib/pydoc.py  (revision 86600)
> +++ Lib/pydoc.py  (working copy)
> @@ -1139,6 +1139,15 @@
>   push('' + makename(base))
>   push('')
>
> +# List the built-in subclasses, if any:
> +subclasses = [cls.__name__ for cls in object.__subclasses__()
> +  if cls.__module__ == 'builtins']
> +if subclasses:
> +push("Built-in subclasses:")
> +for subclassname in sorted(subclasses):
> +push('' + subclassname)
> +push('')
> +
>   # Cute little class to pump out a horizontal rule between sections.
>   class HorizontalRule:
>   def __init__(self):
>
> --
> nosy: +belopolsky
>
> ___
> Python tracker
> 
> ___
>

--

___
Python tracker 

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

[issue10503] os.getuid() documentation should be clear on what kind of uid it is referring

[Giampaolo Rodola']

New submission from Giampaolo Rodola' :

http://docs.python.org/library/os.html#os.getuid
os.getuid() documentation just states:

> Return the current process’s user id.

It is not clear, however, whether "user id" refers to real, effective or saved 
user id.

As per:
http://linux.about.com/library/cmd/blcmdl2_getuid.htm
...it should refer to _real_ user id.

--
assignee: d...@python
components: Documentation
messages: 122117
nosy: d...@python, giampaolo.rodola
priority: normal
severity: normal
status: open
title: os.getuid() documentation should be clear on what kind of uid it is 
referring
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

___
Python tracker 

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

[issue8525] Small enhancement to help()

[Éric Araujo]

Éric Araujo  added the comment:

New features can only go into 3.2, so you have to test with an updated checkout 
of the Subversion branch named py3k.  See the link I have in a previous message.

(P.S. Would you be so kind as to edit quoted text out of your replies?  It’s 
unnecessary noise.  Thanks in advance.)

--

___
Python tracker 

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

[issue10466] locale.py resetlocale throws exception on Windows (getdefaultlocale returns value not usable in setlocale)

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

I think that's a bug in the resetlocale() API.

The correct way to reset the locale setting to defaults, it to use

setlocale(category, "")

The other issues here is that getlocale() appears to return non-ISO language 
codes on Windows. If that's indeed the case, then we would need to add mappings 
of the Windows codes to the ISO ones and use a reverse mappings to make 
setlocale() work with the ISO codes.

Perhaps it's easier to just update the mapping used by getdefaultencoding() to 
return the non-ISO codes used by Windows and then update the documentation to 
say that on Windows, non-ISO codes are returned.

BTW: I wonder why this hasn't popped up earlier.

--

___
Python tracker 

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

[issue9424] Disable unittest.TestCase.assertEquals and assert_ during a regrtest run

[Ezio Melotti]

Ezio Melotti  added the comment:

Committed in r86690 on py3k, blocked in r86691 and r88692 on 3.1/2.7.

--

___
Python tracker 

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

[issue4493] urllib2 doesn't always supply / where URI path component is empty

[Wes Chow]

Wes Chow  added the comment:

This same bug also exists in HTTPClient, and my patch addresses that. 
Addressing it in HTTPClient has a side effect of taking care of it for urllib2 
as well (and all future libraries that use HTTPClient).

Even if the urllib2 patch is preferable, shouldn't we fix the problem in 
HTTPClient as well?

--

___
Python tracker 

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

[issue10504] Trivial mingw compile fixes

[Johann Hanne]

New submission from Johann Hanne :

There are a number of mingw compile issues which are easily fixed
* some "_MSC_VER" #if's should be "MS_WINDOWS" instead
* for cross-compiling, windows.h should be all-lowercase
* mingw has a strcasecmp, so private implementations must not use that name

--
components: Build
files: Python-2.7.diff
keywords: patch
messages: 122122
nosy: jonny
priority: normal
severity: normal
status: open
title: Trivial mingw compile fixes
versions: Python 2.7
Added file: http://bugs.python.org/file19770/Python-2.7.diff

___
Python tracker 

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

[issue940286] pydoc.Helper.help() ignores input/output init parameters

[Éric Araujo]

Changes by Éric Araujo :


--
stage: unit test needed -> patch review
versions: +Python 2.7, Python 3.1

___
Python tracker 

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

[issue10503] os.getuid() documentation should be clear on what kind of uid it is referring

[Giampaolo Rodola']

Giampaolo Rodola'  added the comment:

Update: I think also os.getlogin() doc is wrong.
This is what it states (2.7 doc):


> Return the name of the user logged in on the controlling terminal of 
> the process. For most purposes, it is more useful to use the 
> environment variable LOGNAME to find out who the user is, or 
> pwd.getpwuid(os.getuid())[0] to get the login name of the currently 
> effective user id.

Since os.getuid() refers to _real_ uid the last sentence should be changed as 
such:

- ... to get the login name of the currently effective user id.
+ ... to get the login name of the currently real user id.

--

___
Python tracker 

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

[issue8890] Use tempfile instead of /tmp in examples

[Éric Araujo]

Éric Araujo  added the comment:

Whatsnew documents are not edited after the corresponding release is done.

Using either /home/user or tempfile depending on the example seems good to me.

--
stage: needs patch -> patch review

___
Python tracker 

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

[issue10490] mimetypes read_windows_registry fails for non-ASCII keys

[And Clover]

Changes by And Clover :


--
type:  -> behavior

___
Python tracker 

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

[issue10351] Add autocompletion for keys in dictionaries

[Éric Araujo]

Éric Araujo  added the comment:

Review time!

+elif "[" in text:
+self.matches = self.dict_key_matches(text)
Does this complete only dicts?  What about other mappings?  What about other 
sequences implementing __getitem__?  One of the function name and the function 
docstring (“Compute matches when text contains a [”) is wrong.

I’m not familiar with rlcompleter’s internals, so I’d like a few comments 
sprinkled in the code.

Please wrap your lines at 79 columns, and follow other advice given at 
http://www.python.org/dev/patches/ for the next version of your patch.

+The evaluation of the part before the '[' could be enhanced.
This belongs in a comment or a test, not the docstring.

+  'DictCompleteMe[\'öh, вау!\']',
I find it more readable to avoid escaped quotes whenever possible.  Here I 
would use "DictCompleteMe['öh, вау!']".

--
assignee: d...@python -> 
components:  -Documentation
nosy:  -d...@python

___
Python tracker 

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

[issue9095] patchcheck should handle extraneous whitespace in .rst files

[Éric Araujo]

Éric Araujo  added the comment:

I tried to use “make patchcheck” after edits to reST files and it hung.  Do you 
have the same behavior?  I suspect reindent-rst is the culprit.

I’m wondering about the reindenting; other checks in patchcheck don’t edit 
files, they just print warnings.  On the other hand, removing trailing 
whitespace and reindenting is not a very good use of people’s time, so having a 
tool do them is good.

--

___
Python tracker 

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

[issue10466] locale.py resetlocale throws exception on Windows (getdefaultlocale returns value not usable in setlocale)

[R. David Murray]

R. David Murray  added the comment:

I had a report from a user on IRC during the bug weekend that they could not 
reproduce the failure on windows.  So it may be dependent on the windows 
version.  That doesn't answer your question of why it hasn't come up before, 
though, since my tests were done on XP.

--

___
Python tracker 

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

[issue8890] Use tempfile instead of /tmp in examples

[anatoly techtonik]

anatoly techtonik  added the comment:

On Mon, Nov 22, 2010 at 3:59 PM, Éric Araujo  wrote:
>
> Using either /home/user or tempfile depending on the example seems good to me.

There is no /home/user on Windows.

--

___
Python tracker 

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

[issue10505] test_compileall: failure on Windows

[Stefan Krah]

New submission from Stefan Krah :

On Windows, test_compileall fails due to #10197:

==
FAIL: test_quiet (test.test_compileall.CommandLineTests)
--
Traceback (most recent call last):
  File 
"D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_compileall.py",
 line 227, in test_quiet
self.assertGreater(len(noise), len(quiet))
AssertionError: 89 not greater than 89


The patch uses subprocess.check_output() instead. Technically, now
byte strings are compared instead of strings, but that should not matter
for the outcome.

Does the patch look ok?

--
components: Tests
files: test_compileall.patch
keywords: buildbot, patch
messages: 122129
nosy: brian.curtin, r.david.murray, skrah
priority: normal
severity: normal
stage: patch review
status: open
title: test_compileall: failure on Windows
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file19771/test_compileall.patch

___
Python tracker 

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

[issue10505] test_compileall: failure on Windows

[Éric Araujo]

Éric Araujo  added the comment:

Can you post on #10453?  Thanks in advance.

--
nosy: +eric.araujo
resolution:  -> duplicate
stage: patch review -> committed/rejected
status: open -> closed
superseder:  -> Add -h/--help option to compileall

___
Python tracker 

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

[issue10087] HTML calendar is broken

[Chris Lambacher]

Chris Lambacher  added the comment:

I don't understand what you mean by "elides the line breaks in output". They 
are still there, you just don't see them as \n because print() is no longer 
implicitly converting the bytes to a string (which appears to actually result 
in a repr).

--

___
Python tracker 

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

[issue10087] HTML calendar is broken

[Ezio Melotti]

Changes by Ezio Melotti :


--
nosy: +ezio.melotti

___
Python tracker 

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

[issue10453] Add -h/--help option to compileall

[Stefan Krah]

Stefan Krah  added the comment:

On Windows, test_compileall fails due to #10197. The patch uses
subprocess.check_output() instead. Technically, now byte strings
are compared instead of strings, but that should not matter for
the outcome.

--
nosy: +skrah
Added file: http://bugs.python.org/file19772/test_compileall.patch

___
Python tracker 

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

[issue7995] On Mac / BSD sockets returned by accept inherit the parent's FD flags

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> > Well, unless someone explains convincingly how the current behaviour is
> > desireable (rather than misleading and useless), I really think this is
> > a bug that should be fix (then we can also discuss what the fix should
> > exactly be).
> 
> So please propose a fix.

Well, in case you didn't notice, a fix was already proposed :)
(not in proper form, granted, and lacking a test)

At least now you won't argue that this is normal behaviour, so we are
progressing.

--

___
Python tracker 

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

[issue10506] argparse execute system exit in python prompt

[Tarsis Azevedo]

New submission from Tarsis Azevedo :

Hi all, when I use argparse in python prompt, and raise a exception, as the 
code below:

>>> import argparse
>>> parser = argparse.ArgumentParser()
>>> parser.add_argument('-i' type=int)
>>> parser.parse_args(['-i', 'a'])

the prompt is closed.

This behavior this in error function (Lib/argparse.py:2325)
I think in python prompt this behavior it's wrong.

it's right?!

--
components: Library (Lib)
messages: 122134
nosy: Tarsis.Azevedo
priority: normal
severity: normal
status: open
title: argparse execute system exit in python prompt
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

[issue9742] Python 2.7: math module fails to build on Solaris 9

[Doug Shea]

Doug Shea  added the comment:

I have some knowledge of these things, so I'll try to find out what's going on, 
but I could also upload output and/or debug files here for you to examine, if 
that helps. If you give me the files you'd like to see from my build, or the 
commands you'd like the output of, I'd be happy to oblige. Thanks!

--

___
Python tracker 

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

[issue10087] HTML calendar is broken

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

On Mon, Nov 22, 2010 at 9:48 AM, Chris Lambacher  wrote:
..
> I don't understand what you mean by "elides the line breaks in output".

It is actually not that bad:

$ ./python.exe -m calendar -t html| wc -l
 121
$ python2.7 -m calendar -t html| wc -l
 122

At first, I thought that html was printed one line at a time, but now
I realize that it is prepared in-memory and printed in one shot.  The
extra '\n' in python2.7 is probably a bug in 2.7.

I think this is a reasonable approach.Just a few comments on the patch:

1. Unit tests needed.
2. It may be appropriate to add a warning to the documentation stating
that using -e option may mess up the terminal.
3.   In the following snippet, p is an unconditional shortcut to
sys.stdout.buffer.write.  I would just call it "write"

 optdict = dict(encoding=encoding, css=options.css)
+p = sys.stdout.buffer.write

4.  While white space consistency with 2.7 is not very important, the
following should be fixed, IMO:

$ ./python.exe -m calendar -e ascii| wc -l
  35
$ ./python.exe -m calendar| wc -l
  36

5. I wonder how ./python.exe -m calendar -e ascii will look on
Windows.  I don't think cmd window is smart about displaying unix line
endings.

--

___
Python tracker 

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

[issue1975] signals not always delivered to main thread, since other threads have the signal unmasked

[nh2]

nh2  added the comment:

My problem was actually related to the subprocess.Popen I use inside my threads 
in combination with signals. As Popen does not spawn a new thread, but a new 
process, it completely ignores my locks.

However, it seems impossible to safely unregister signals for subprocesses. I 
tried using SIG_IGN in preexec_fn for Popen as well as a ignore/Popen/unignore 
wrapper, but both result in race conditions (for the first: if the signal 
arrives between fork and exec and for the second if it arrives within the 
wrapper).

I think ignoring signals by default for everything but the main thread or 
process would solve this problem and make parallel programming with events in 
Python a lot easier.

Explicit is better than implicit.

--

___
Python tracker 

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

[issue10220] Make generator state easier to introspect

[Nick Coghlan]

Nick Coghlan  added the comment:

Temporarily reopening to remind me to switch from using integer constants to 
strings (which are much friendlier for debugging purposes).

--
status: closed -> open

___
Python tracker 

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

[issue9742] Python 2.7: math module fails to build on Solaris 9

[Mark Dickinson]

Mark Dickinson  added the comment:

Doug:  thanks.  I think I may just be being stupid here. One thing you might 
try is replacing the line

  extern double round(double);

in Include/pymath.h, with:

  PyAPI_FUNC(double) round(double);

and see if that helps.

--

___
Python tracker 

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

[issue9742] Python 2.7: math module fails to build on Solaris 9

[Doug Shea]

Doug Shea  added the comment:

I unpacked a fresh tarball, made this change, then did a ./configure and make 
as normal. Exact same error as originally reported. :(

--

___
Python tracker 

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

[issue10504] Trivial mingw compile fixes

[Martin v . Löwis]

Martin v. Löwis  added the comment:

What's the objective of this patch? I.e. what precisely is it supposed to 
achieve?

--
nosy: +loewis

___
Python tracker 

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

[issue9742] Python 2.7: math module fails to build on Solaris 9

[Mark Dickinson]

Mark Dickinson  added the comment:

Hmm.  That's puzzling indeed.

I made a claim earlier that 'round' is already used in Objects/floatobject.c, 
but it occurs to me now that that's not true if PY_NO_SHORT_FLOAT_REPR is 
#defined.

Could you attach the pyconfig.h file produced by configure?

--

___
Python tracker 

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

[issue10507] Check well-formedness of reST markup within "make patchcheck"

[Dave Malcolm]

New submission from Dave Malcolm :

Misc/NEWS needs to be valid reST.

Issue 10450 identified an issue where it wasn't.

"make patchcheck" potentially could check the markup of that file, and, 
potentially all the other places in the source tree that are supposed to be 
valid reST (all of the .rst files in the source tree, especially those below 
Doc).

I don't know what the best way of doing this is, without pulling in a lot of 
dependencies.  (Perhaps we could look for rst2html on $PATH, and use it if it's 
present?).

--
components: Demos and Tools
messages: 122142
nosy: dmalcolm
priority: normal
severity: normal
stage: needs patch
status: open
title: Check well-formedness of reST markup within "make patchcheck"
type: feature request
versions: 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

[issue10450] Fix markup in Misc/NEWS

[Dave Malcolm]

Dave Malcolm  added the comment:

Opened as issue 10507

--

___
Python tracker 

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

[issue9742] Python 2.7: math module fails to build on Solaris 9

[Doug Shea]

Doug Shea  added the comment:

Certainly!

--
Added file: http://bugs.python.org/file19773/pyconfig.h

___
Python tracker 

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

[issue10220] Make generator state easier to introspect

[Guido van Rossum]

Guido van Rossum  added the comment:

Yes please.

On Mon, Nov 22, 2010 at 7:44 AM, Nick Coghlan  wrote:
>
> Nick Coghlan  added the comment:
>
> Temporarily reopening to remind me to switch from using integer constants to 
> strings (which are much friendlier for debugging purposes).
>
> --
> status: closed -> open
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

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

[issue10087] HTML calendar is broken

[Chris Lambacher]

Chris Lambacher  added the comment:

I am attaching a new patch which fixes the majority of the comments raised.

1. Any suggestions about how to test the output of the console program (the 
case that this bug affects) would be appreciated.

2. Agreed, included in the output for --help

3. Agreed, included in new patch

4. Okay. That is because of using write vs print. Changed to always use write

5. Doesn't seem to cause any issues on windows terminal.

--
Added file: http://bugs.python.org/file19774/calendar_bytes_output_v2.patch

___
Python tracker 

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

[issue10087] HTML calendar is broken

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

On Mon, Nov 22, 2010 at 11:55 AM, Chris Lambacher
 wrote:
..
> 1. Any suggestions about how to test the output of the console program (the 
> case that this bug affects)
> would be appreciated.

For month displays, a doctest may be most appropriate. See
Lib/test/test_syntax.py for one example of using doctests in regrtest
suite.  Note that sys.stdout being StringIO may present a challenge to
your approach.  You can also take a look at test_pydoc which also
tests console-oriented text and html output.

--

___
Python tracker 

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

[issue10087] HTML calendar is broken

[Chris Lambacher]

Chris Lambacher  added the comment:

The test_pydoc method looks workable, but I'll need to come back to it later 
because I don't have any more time to work on it today.

--

___
Python tracker 

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

[issue10504] Trivial mingw compile fixes

[Johann Hanne]

Johann Hanne  added the comment:

Python 2.7 will currently not compile with MinGW for the outlined reasons.

* There are several "#if defined(_MSC_VER)" macros which surround Windows 
specific code/preprocessor fragments. But _MSC_VER is only defined with the 
Visual Studio compiler, not with gcc/MinGW. So the MS_WINDOWS define needs to 
be used for Windows specific code (and _MSC_VER only for compiler specific 
code).

* When cross-compiling on Unix with gcc/MinGW, the windows.h header is only 
found if it's written all lowercase due to Unix filesystems being 
case-sensitive.

* strcasecmp is a already defined by gcc/MinGW, so it must not be used for 
defining another function. The patch thus renames a function currently named 
strcasecmp to my_strcasecmp.

--

___
Python tracker 

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

[issue10504] Trivial mingw compile fixes

[Johann Hanne]

Johann Hanne  added the comment:

> What's the objective of this patch? I.e. what precisely is it supposed to 
> achieve?

So the answer is: It will fix compiling with gcc/MinGW by fixing the 3 issues 
described.

--

___
Python tracker 

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

[issue10508] compiler warnings about formatting pid_t as an int

[Jesús Cea Avión]

New submission from Jesús Cea Avión :

In r85679 Greorg committed a trivial patch to avoid a compiler warning.

I request this (single line fix) to be backported to 2.7.

My argument is that 2.7 is going to be live for quite long, the fix is trivial, 
it is already in use in Py3k branch, and we would have a perfect clean buildbot 
report.

For instance: 
http://www.python.org/dev/buildbot/all/builders/x86%20OpenIndiana%202.7/builds/17/steps/compile/logs/warnings%20%281%29

I mark this as a release blocker to raise attention of the maintainer, since we 
are in release candidate already.

--
assignee: georg.brandl
components: Extension Modules
keywords: easy
messages: 122152
nosy: georg.brandl, jcea
priority: release blocker
severity: normal
stage: commit review
status: open
title: compiler warnings about formatting pid_t as an int
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

[issue10509] PyTokenizer_FindEncoding can lead to a segfault if bad characters are found

[Andreas Stührk]

New submission from Andreas Stührk :

If a non-ascii character is found and there isn't an encoding cookie, a 
SyntaxError is raised (in `decoding_fgets`) that includes the path of the file 
(using ``tok->filename``), but that path is never set. You can easily reproduce 
the crash by calling `imp.find_module("badsyntax")`, where "badsyntax" is a 
Python file containing a non-ascii character (see e.g. the attached unit test), 
as `find_module` uses `PyTokenizer_FindEncoding`. Note that Python 3.1 uses 
`snprintf()` for formatting the error message and some implementations of 
`snprintf()` explicitly check for null pointers, hence it might not crash.

One possible fix is to set ``tok->filename`` to something like "". 
Attached is a patch which does that and adds an unit test for imp.

--
components: Interpreter Core
messages: 122153
nosy: Trundle
priority: normal
severity: normal
status: open
title: PyTokenizer_FindEncoding can lead to a segfault if bad characters are 
found
type: crash
versions: Python 3.1, Python 3.2

___
Python tracker 

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

[issue10509] PyTokenizer_FindEncoding can lead to a segfault if bad characters are found

[Andreas Stührk]

Changes by Andreas Stührk :


--
keywords: +patch
Added file: http://bugs.python.org/file19775/PyTokenizer_FindEncoding_fix.patch

___
Python tracker 

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

[issue10509] PyTokenizer_FindEncoding can lead to a segfault if bad characters are found

[Ezio Melotti]

Changes by Ezio Melotti :


--
nosy: +ezio.melotti
stage:  -> patch review

___
Python tracker 

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

[issue10506] argparse execute system exit in python prompt

[Santoso Wijaya]

Changes by Santoso Wijaya :


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

[issue9742] Python 2.7: math module fails to build on Solaris 9

[Mark Dickinson]

Mark Dickinson  added the comment:

Thanks.  I'm still stuck, though.  Since I'm pretty much at the wild guesses 
stage, here's one:

 Perhaps the pymath.o object file isn't being included in the Python 
executable at all, because none of its functions are needed.  Now that doesn't 
seem to make sense, since the round function is needed, and used, in 
Objects/floatobject.c (that is, if PY_NO_SHORT_FLOAT_REPR is *not* defined;  
I'm still not clear on whether that's the case or not---if you can get as far 
as launching an interpreter, then the result of sys.float_repr_style would be 
'short' in that case).  But gcc (depending on the version, I guess) has builtin 
versions of some standard C library functions, including 'round'.  So if it 
were using the builtin then there would be no need to link to the pymath.o 
file, so it might be left out of the python executable.  But I'm not sure why 
the same doesn't happen when compiling the math module.

Neither am I sure how one might go about testing the above hypothesis.

--

___
Python tracker 

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

[issue10435] Document unicode C-API in reST

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

On Wed, Nov 17, 2010 at 5:20 PM, Marc-Andre Lemburg
 wrote:
..
> -/* Encodes a Unicode object and returns the result as Python string
> +/* Encodes a Unicode object and returns the result as Python bytes
>    object. */
>
>
> PyUnicode_AsEncodedObject() encodes the Unicode object to
> whatever the codec returns, so the "bytes" is wrong in the
> above line.
>

The above line describes PyUnicode_AsEncodedString(), not
PyUnicode_AsEncodedObject().  The former has PyBytes_Check(v) after
calling  v = PyCodec_Encode(..).  As far as I can tell this is the
only difference that makes PyUnicode_AsEncodedObject() not redundant.

..
> +.. c:function:: PyObject* PyUnicode_AsDecodedObject(PyObject *unicode, const 
> char *encoding, const char *errors)
>
> +   Create a Unicode object by decoding the encoded Unicode object
> +   *unicode*.
>
> The function does not guarantee that a Unicode object will be
> returned. It merely passes a Unicode object to a codec's
> decode function and returns whatever the codec returns.
>

Good point.  I am changing "Unicode object" to "Python object".

..
> +   Note that Python codecs do not accept Unicode objects for decoding,
> +   so this method is only useful with user or 3rd party codecs.
>
> Please strike the last sentence. The codecs that were wrongly removed
> from Python3 will get added back and provide such functionality.
>

Would it be acceptable to keep this note, but add "as of version 3.2"
or something like that?   I don't think there is a chance that these
codecs will be added in 3.2 given the current schedule.

..
> This should read:
>
>   Decodes a Unicode object by passing the given Unicode object
>   *unicode* to the codec for *encoding*.
>   *encoding* and *errors* have the same meaning as the
>   parameters of the same name in the :func:`unicode` built-in
>   function.  The codec to be used is looked up using the Python codec
>   registry.  Return *NULL* if an exception was raised by the codec.
>

Is the following better?

"""
Decodes a Unicode object by passing the given Unicode object
*unicode* to the codec for *encoding*.  *encoding* and *errors*
have the same meaning as the parameters of the same name in the
:func:`unicode` built-in  function. The codec to be used is
looked up using the Python codec registry. Return *NULL* if an
exception was raised by the codec.

As of Python 3.2, this method is only useful with user or 3rd
party codec that encodes string into something other than bytes.
For encoding to bytes, use c:func:`PyUnicode_AsEncodedString`
instead.
"""
..
>
> +.. c:function:: void PyUnicode_Append(PyObject **pleft, PyObject *right)
..
> +
> +.. c:function:: void PyUnicode_AppendAndDel(PyObject **pleft, PyObject 
> *right)
..
>
> Please don't document these two obscure APIs. Instead we should
> make them private functions by prepending them with an underscore.
> If you look at the implementations of those two APIs, they
> are little more than a macros around PyUnicode_Concat().
>

I don't agree that they are obscure.  Python uses them in multiple
places and developers seem to know about them.  See patches submitted
to issue4113 and issue7584.

> 3rd party extensions should use PyUnicode_Concat() to achieve
> the same effect.
>

Hmm.  I would not be surprised if current 3rd party extensions used
PyUnicode_AppendAndDel() more often than PyUnicode_Concat().  (I know
that I learned about PyUnicode_AppendAndDel()  before
PyUnicode_Concat().)

Is there anything that makes PyUnicode_AppendAndDel() undesirable?   I
don't mind adding a recommendation to use PyUnicode_Concat() if there
is a practical reason for it or even a warning that
PyUnicode_AppendAndDel() may be deprecated in the future, but renaming
it to _PyUnicode_AppendAndDel() seems premature.

..
>
> I don't think it's a good idea to make this a public API.
> 3rd party extensions should not need to make use of such
> APIs.
>
> Instead, we should make this a private API.

I agree, but isn't it prudent to document it as deprecated for 3rd
party use first?

--

___
Python tracker 

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

[issue9095] patchcheck should handle extraneous whitespace in .rst files

[Brett Cannon]

Brett Cannon  added the comment:

Just ran it without issue after doing an `svn up`.

As for fix vs. not, while fixing indentations and removing trailing whitespace 
is nice, it isn't necessary. Both instances should be a rarity (most IDEs will 
make sure the situation doesn't occur), so the most important thing is 
detecting there is an issue for people to fix them (along with providing as 
much info as possible to make it easy to fix) rather than fixing it for them 
(if that turns out to be somewhat complicated to do).

--

___
Python tracker 

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

[issue9807] deriving configuration information for different builds with the same prefix

[Barry A. Warsaw]

Changes by Barry A. Warsaw :


Removed file: http://bugs.python.org/file19564/9807.txt

___
Python tracker 

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

[issue9807] deriving configuration information for different builds with the same prefix

[Barry A. Warsaw]

Barry A. Warsaw  added the comment:

Here's an updated patch which address's Matthias's last concerns.

--
Added file: http://bugs.python.org/file19776/9807.txt

___
Python tracker 

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

[issue6878] changed return type from tkinter.Canvas.coords

[SilentGhost]

SilentGhost  added the comment:

In my original post, I mentioned that it might be just a documentation issue. 
Could someone confirm that having map object returned is actually causing any 
problems?

--

___
Python tracker 

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

[issue9742] Python 2.7: math module fails to build on Solaris 9

[Doug Shea]

Doug Shea  added the comment:

> ./python
Python 2.7 (r27:82500, Nov 22 2010, 10:06:14)
[GCC 3.3.2] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> print sys.float_repr_style
short

So it appears, if I follow you, that PY_NO_SHORT_FLOAT_REPR is not defined.

Glancing through the Makefile, pymath.o is included in the PYTHON_OBJS 
variable, which is in turn included in the LIBRARY_OBJS variable, which is used 
in all the libpython* targets.

I'm going to try to turn on some debugging on the commands that build those 
targets, and see if anything jumps out at me. Maybe it'll be obvious that 
pymath.o is being left out for one reason or another that'll sync up with your 
"wild guess". :/

--

___
Python tracker 

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

[issue6878] changed return type from tkinter.Canvas.coords

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

Committed in r86697 (3.2) and r86698 (3.1).

@Éric: I tried to minimize whitespace changes in the commit, but if you see 
indentation that can be improved, let me know and I'll fix it separately.

@SilentGhost: Yes, the problem is real.  For example, turtle module had to be 
fixed to work around the API change.  I now reverted that.  Note that 2to3 (I 
believe) fixes direct invocations of map, but cannot look inside the functions.

--

___
Python tracker 

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

[issue6878] changed return type from tkinter.Canvas.coords

[Alexander Belopolsky]

Changes by Alexander Belopolsky :


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

[issue10503] os.getuid() documentation should be clear on what kind of uid it is referring

[R. David Murray]

R. David Murray  added the comment:

These are wrappers around the posix functions.  As such the unix man pages are 
a better authority than the Python docs :)  Still, we could certainly improve 
the docs.

The getlogin error is probably a miscopy from the man page: the man page on my 
system shows the example as  getpwuid(geteuid()), but it is actually showing a 
replacement for 'cuserid', not 'getlogin'.

--
nosy: +r.david.murray
stage:  -> needs patch
type:  -> behavior
versions:  -Python 2.6

___
Python tracker 

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

[issue10506] argparse execute system exit in python prompt

[R. David Murray]

R. David Murray  added the comment:

This is working as designed.  Whether or not the design is correct has been 
debated in the past.  If you want to re-debate it the appropriate place is 
probably python-ideas.

--
nosy: +bethard, r.david.murray
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

[issue10490] mimetypes read_windows_registry fails for non-ASCII keys

[R. David Murray]

R. David Murray  added the comment:

This is a duplicate if issue 9291.

--
nosy: +r.david.murray
stage:  -> committed/rejected
status: open -> closed
superseder:  -> mimetypes initialization fails on Windows because of non-Latin 
characters in registry

___
Python tracker 

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

[issue9291] mimetypes initialization fails on Windows because of non-Latin characters in registry

[R. David Murray]

Changes by R. David Murray :


--
nosy: +aclover

___
Python tracker 

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

[issue9162] License for multiprocessing files

[Daniel Tavares]

Daniel Tavares  added the comment:

Hi Jesse,

Any word from PSF board regarding this issue? I was hoping to fix it and have 
it be my 1st contribution to Python.

Thanks

--
nosy: +dBugSlayer

___
Python tracker 

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

[issue10503] os.getuid() documentation should be clear on what kind of uid it is referring

[Giampaolo Rodola']

Giampaolo Rodola'  added the comment:

Indeed, now that I google for "getlogin", it's not easy to figure out what kind 
of user it is supposed to return exactly.

For getuid() it seems pretty clear that we're talking about _real_ uid, though.
http://www.manpagez.com/man/2/getuid/
http://linux.die.net/man/2/getuid

--

___
Python tracker 

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

[issue1647654] No obvious and correct way to get the time zone offset

[Max Arnold]

Max Arnold  added the comment:

Our region recently switched to another timezone and I've noticed similar issue 
while using Mercurial. There is some (hopefully) useful details: 
http://mercurial.selenic.com/bts/issue2511

--
nosy: +LwarX

___
Python tracker 

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

[issue9162] License for multiprocessing files

[Jesse Noller]

Jesse Noller  added the comment:

We have to add the BSD header and maintain the copyright clause on all of the 
multiprocessing files. Apologies for the delay

--

___
Python tracker 

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

[issue9095] patchcheck should handle extraneous whitespace in .rst files

[Georg Brandl]

Georg Brandl  added the comment:

patchcheck.py is not so complicated; why don't you debug that hangup yourself?

--

___
Python tracker 

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

[issue9742] Python 2.7: math module fails to build on Solaris 9

[Doug Shea]

Doug Shea  added the comment:

I don't think there's anything wrong with the setup we've been looking at so 
far, per se. The libpython2.7.a file produced has the 'round' function like it 
should:

> nm libpython2.7.a | grep round
[116] |  1360| 696|FUNC |GLOB |0|2  |_Py_double_round
[218] | 0|   0|NOTY |GLOB |0|UNDEF  |_Py_double_round
[10] | 15268| 236|FUNC |LOCL |0|2  |builtin_round
[48] |  9912| 198|OBJT |LOCL |0|4  |round_doc
[8] | 0|  96|FUNC |GLOB |0|2  |round

However, the python executable itself, compiled against that archive, does 
*not* have it:

> nm python | grep round
[4805] |244408| 696|FUNC |GLOB |0|9  |_Py_double_round
[1735] |640836| 236|FUNC |LOCL |0|9  |builtin_round
[1770] |   1533576| 198|OBJT |LOCL |0|16 |round_doc

So, for some reason, the gcc command that builds that python executable is 
leaving it out:

gcc -o python \
   Modules/python.o \
   libpython2.7.a -lresolv -lsocket -lnsl -lrt -ldl -lpthread -lm

Just an update. Going to try to debug that command and see if I can find out 
why.

--

___
Python tracker 

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

[issue9263] Try to print repr() when an C-level assert fails (in the garbage collector, beyond?)

[Dave Malcolm]

Changes by Dave Malcolm :


--
nosy: +pitrou

___
Python tracker 

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

[issue9263] Try to print repr() when an C-level assert fails (in the garbage collector, beyond?)

[Dave Malcolm]

Dave Malcolm  added the comment:

Attaching a simplified version of the patch; I got rid of the callbacks.

Still doesn't have test cases.

I suspect that the use of __STRING and __PRETTY_FUNCTION__ may be compatibility 
issues.  I believe that __FILE__ and __LINE__ and standard C though.

--
Added file: 
http://bugs.python.org/file19777/py3k-objdump-on-gcmodule-assertions-2010-11-22-001.patch

___
Python tracker 

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

[issue10504] Trivial mingw compile fixes

[Roumen Petrov]

Changes by Roumen Petrov :


--
nosy: +rpetrov

___
Python tracker 

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

[issue6166] encoding error for 'setup.py --author' when read via subprocess pipe

[Sridhar Ratnakumar]

Sridhar Ratnakumar  added the comment:

"PYTHONIOENCODING=UTF-8 python test2.py" does work.

--

___
Python tracker 

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

[issue10501] make_buildinfo regression with unquoted path

[Martin]

Martin  added the comment:

Thanks. Don't actually need to quote the whole path, but what you've landed 
works for me.

--

___
Python tracker 

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

[issue10437] ThreadPoolExecutor should accept max_workers=None

[Daniel Stutzbach]

Daniel Stutzbach  added the comment:

Amaury Forgeot d'Arc said:
> pypy does have a GIL!

D'oh.  That shows you how much I know about PyPy.  Make that "keep in mind that 
IronPython doesn't have a GIL". ;)

Brian Quinlan said:
> I think that using the number of CPUs for max_workers makes sense
> for you but won't for most users. So I wouldn't make it a default.

Fair enough.  Marking as invalid.

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

[issue10504] Trivial mingw compile fixes

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  added the comment:

I doubt this fix will be enough to fix compilation with mingw32.
But IMO it goes in the right direction.

With this patch, "#ifdef MS_WINDOWS" has the meaning of "linked with some 
version of MSVCRT".  Do we agree on this, or is another symbol necessary?

--
nosy: +amaury.forgeotdarc

___
Python tracker 

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

[issue10504] Trivial mingw compile fixes

[Martin v . Löwis]

Martin v. Löwis  added the comment:

> I doubt this fix will be enough to fix compilation with mingw32.

So somebody will have to verify independently. If it fails to fix
the bug completely, it's out of scope for 2.7 (it's out of scope for
2.7.1 IMO either way).

> With this patch, "#ifdef MS_WINDOWS" has the meaning of "linked with
> some version of MSVCRT". Do we agree on this, or is another symbol
> necessary?

MS_WINDOWS is defined as

MS_WINDOWS - Code specific to Windows, but all versions.

So it does *not* imply "MSVCRT". Introducing a new preprocessor symbol
is also out of scope for 2.7, so if we mean "MSC or mingw", we need
to spell that out (i.e. defined(_MSC_VER) || defined(__MINGW32__)).

--

___
Python tracker 

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

[issue9846] ZipExtFile provides no mechanism for closing the underlying file object

[Łukasz Langa]

Łukasz Langa  added the comment:

Adding a patch implementing the discussed functionality, removing almost all of 
the ResourceWarnings raised by zipfile.

--
keywords: +patch
nosy: +lukasz.langa
stage: needs patch -> patch review
Added file: http://bugs.python.org/file19778/issue9846.diff

___
Python tracker 

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

[issue9846] ZipExtFile provides no mechanism for closing the underlying file object

[Łukasz Langa]

Łukasz Langa  added the comment:

Committed in rev 86699.

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

[issue9915] speeding up sorting with a key

[Daniel Stutzbach]

Daniel Stutzbach  added the comment:

I'm starting to get settled in here at Google and finding time to follow up on 
everything that got put on hold while moving.

Based on the feedback everyone gave me (thanks!), I greatly revised my script 
for comparing the speed of sort().  It's now compares speeds more quickly and 
more accurately.  I discovered a few things along the way:

1) Don't try to run timings on a virtual server with crummy clock resolution.

2) Make sure that CPU frequency scaling is turned off.  It increases the 
standard deviation of timings by an order of magnitude or two.

On Linux systems, the new version of my script will check to see if CPU 
frequency scaling is turned on and provide suggestions on how to turn it off.  
On other operating systems, you are on your own. ;)

Usage:
filfre:~/py3k-patched$ ./python Tools/sort_speed/sort_speed.py -r 3 --maxn 
10 ../py3k-pristine . sort_random

Using my new-and-improved timing script and running on real hardware with CPU 
frequency scaling turned off, I was able to detect a slight slowdown on sorting 
random integers.  Here's a summary for sorting random integers:

Original patch (increasing execution time is bad):
n in [700 .. 100,000]: 1% to 2% increase in execution time
n in [70 to 700]: 2% to 3% increase
n in [10 to 70]: 3% to 4% increase
n in [5 to 7]: 7% to 9% decrease
n in [0 to 3]: 18+% decrease

I went back to the code and managed to squeeze out a bit more performance.  
Here's a summary of the new patch:

New patch (increasing execution time is bad):
n in [30,000 .. 100,000]: < 1% increase in execution time
n in [35 .. 30,000]: 1% to 2% increase
n in [20 .. 35]: about the same
n in [10 .. 20]: 1 to 2% decrease
n in [4 .. 7]: 15+% decrease
n in [0 .. 3]: 22+% decrease

All of the above results are for sorting without a key.  For sorting *with* a 
key, there's a big performance boost across the board (15% to 45% decrease in 
execution time, when the key function is simply "int").

Overall, the patch shrinks Objects/listobject.c by 10 lines.

Executive Summary
-

Good:
- Dramatically cuts execution time of sorting with a key (15% to 45%)
- Significantly cuts execution time of sorting small lists without a key (15+%)

Bad:
- Very slightly increases execution of sorting large lists without a key (1% to 
2%; less than 1% for very large lists)

Worthwhile trade?

--
Added file: http://bugs.python.org/file19779/sort-speed-test.patch

___
Python tracker 

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

[issue9915] speeding up sorting with a key

[Daniel Stutzbach]

Changes by Daniel Stutzbach :


Added file: http://bugs.python.org/file19780/sort-faster.patch

___
Python tracker 

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

[issue9915] speeding up sorting with a key

[Daniel Stutzbach]

Changes by Daniel Stutzbach :


Added file: http://bugs.python.org/file19781/detailed-speed-results.txt

___
Python tracker 

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

[issue9915] speeding up sorting with a key

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> Worthwhile trade?

+1 obviously.

Why don't you contribute a list sorting benchmark to the suite in 
http://hg.python.org/benchmarks/?

--

___
Python tracker 

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

[issue1676121] Problem linking to readline lib on x86(64) Solaris

[Éric Araujo]

Changes by Éric Araujo :


--
superseder: documentation for new SSL module -> readline configuration for 
shared libs w/o curses dependencies

___
Python tracker 

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

[issue9915] speeding up sorting with a key

[Daniel Stutzbach]

Daniel Stutzbach  added the comment:

Antoine Pitrou  wrote:
> Why don't you contribute a list sorting benchmark to the suite in 
> http://hg.python.org/benchmarks/?

I considered that, but I want to separately benchmark sorting different kinds 
and quantities of data.  AFAIK, there isn't an easy way to do that with perf.py.

--

___
Python tracker 

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

[issue9915] speeding up sorting with a key

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Le mardi 23 novembre 2010 à 00:10 +, Daniel Stutzbach a écrit :
> Daniel Stutzbach  added the comment:
> 
> Antoine Pitrou  wrote:
> > Why don't you contribute a list sorting benchmark to the suite in 
> > http://hg.python.org/benchmarks/?
> 
> I considered that, but I want to separately benchmark sorting
> different kinds and quantities of data.  AFAIK, there isn't an easy
> way to do that with perf.py.

Right, that wouldn't suit your present purposes. But apparently you are
proposing to add a list sorting benchmark to the Tools directory, with
lots of duplicated code from that repo...

--

___
Python tracker 

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