[issue6278] http.server, BaseHTTPRequestHandler write string error

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  added the comment:

the HTTP response should be a bytes string:
self.wfile.write(b'test')

--
nosy: +amaury.forgeotdarc
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

[issue6250] Python compiles dead code

[Raymond Hettinger]

Raymond Hettinger  added the comment:

I'm curious to whether this needs to be embedded in the compiler or
whether a standalone tool can be offered.  See
http://code.activestate.com/recipes/277940/ for an example of processing
the bytecodes directly.  FWIW, deadcode can already be detected by some
of the existing code quality tools: 
http://www.doughellmann.com/articles/CompletelyDifferent-2008-03-linters/index.html
.  What does this patch offer beyond what we already have with those tools?

--

___
Python tracker 

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

[issue6282] In tarfile, compression level cannot be specified

[Omri Shaked]

Omri Shaked  added the comment:

Silly me...  Thanks!

--
status: open -> closed

___
Python tracker 

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

[issue6286] distutils upload command doesn't work with http proxy

[Tarek Ziadé]

New submission from Tarek Ziadé :

upload is base on httplib and doesn't use the http_proxy envrionment
variable. So it's impossible to upload a file behind a firewall.

Let's change the command so it uses a proxy if set

--
assignee: tarek
components: Distutils
messages: 89398
nosy: tarek
severity: normal
status: open
title: distutils upload command doesn't work with http proxy
versions: Python 2.7, Python 3.2

___
Python tracker 

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

[issue5811] io.BufferedReader.peek(): Documentation differs from Implementation

[Antoine Pitrou]

Antoine Pitrou  added the comment:

I haven't read the patch in detail but I don't think you should have
changed read1(). read1() is there for optimization purposes and its
current behaviour makes sense IMO.

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

[issue5811] io.BufferedReader.peek(): Documentation differs from Implementation

[Nick Coghlan]

Nick Coghlan  added the comment:

The doc revision definitely does a better job of characterising the
current underspecified behaviour :)

I agree with Antoine that "at most a single read" would be better wording.

--

___
Python tracker 

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

[issue5811] io.BufferedReader.peek(): Documentation differs from Implementation

[Lucas Prado Melo]

Lucas Prado Melo  added the comment:

Ok
A new patch without read1() changes.
Only one test fails, a read1() test:

==
FAIL: test_read1 (test.test_io.PyBufferedRWPairTest)
--
Traceback (most recent call last):
  File "/home/lucas/Codes/python-stuff/py3k/Lib/test/test_io.py", line
1139, in test_read1
self.assertEqual(pair.read1(3), b"abc")
AssertionError: b'a' != b'abc'


Since I've changed peek_unlocked() (which is used once by read1()), I
guess there's a problem with read1() expectations about it.

--
Added file: http://bugs.python.org/file14305/peek4.diff

___
Python tracker 

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

[issue6205] sdist doesn't include data_files

[James]

James  added the comment:

great, thanks for the info.

--

___
Python tracker 

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

[issue6208] path separator output ignores shell's path separator: / instead of \

[Eric Smith]

Eric Smith  added the comment:

> So is this a cosmetic issue or a functional issue? 

It's a cosmetic issue.

> Also, even if it could figure that out, how would it know whether
> a particular filename "stringification" with os.path.join() was 
> intended for display to the user or to be passed to a Windows API?

The Windows API's (at least every one I've ever called) take either
slashes or backslashes, so it wouldn't matter.

I'm +0 on this request, if we could reliably figure out which separator
we wanted to use based on the shell (or maybe an environment variable).
It would be one more way to let me forget I'm using Windows instead of Unix.

My use case is mostly copying path's that have been print()'d from
within Python, then pasting them into a cygwin bash shell. All of the
backslashes need to be manually escaped (or the whole string quoted). Of
course this doesn't help with other characters that also need escaping
(like spaces). That and the fragile nature of the "which shell am I
running" check are why I'm +0.

--
nosy: +eric.smith

___
Python tracker 

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

[issue6208] path separator output ignores shell's path separator: / instead of \

[Tim Golden]

Tim Golden  added the comment:

Eric Smith wrote:
> Eric Smith  added the comment:
> 
>> So is this a cosmetic issue or a functional issue? 
> 
> It's a cosmetic issue.
> 
>> Also, even if it could figure that out, how would it know whether
>> a particular filename "stringification" with os.path.join() was 
>> intended for display to the user or to be passed to a Windows API?
> 
> The Windows API's (at least every one I've ever called) take either
> slashes or backslashes, so it wouldn't matter.

Just for information's sake, the shell APIs usually only accept backslashes.

TJG

--
nosy: +tim.golden
title: path separator output ignores shell's path separator: / instead of \ -> 
path separator output ignores shell's path separator: /  instead of \

___
Python tracker 

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

[issue6208] path separator output ignores shell's path separator: / instead of \

[Eric Smith]

Eric Smith  added the comment:

Tim Golden wrote:
> Just for information's sake, the shell APIs usually only accept backslashes.

That's good to know. Do you have any specific examples?

CreateFile and the like, which is where my experience is, take either. 
90% of my Windows Python programs use slashes exclusively. About the 
only time I get a backslash is when using os.path.join(), and then I end 
up with mixed slashes and backslashes. Windows handles these mixed paths 
correctly, as far as I can tell.

--

___
Python tracker 

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

[issue6250] Python compiles dead code

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Are you looking for dead code detection (like a lint utility) or
automatic dead code removal (modified code)?

--

___
Python tracker 

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

[issue6250] Python compiles dead code

[Collin Winter]

Collin Winter  added the comment:

Standalone bytecode-modifying tools almost never check that they're
outputting correct bytecode. http://code.activestate.com/recipes/277940/
makes no attempt to check what version of Python it's running under;
running it under Unladen Swallow 2009Q1 would have produced completely
incorrect code because we had modified how opcode arguments were stored.

I don't want to encourage people to write tools that operate over
CPython bytecode. As such code proliferates, the alternate
implementations have to chase it down and ask that it be removed. It
complicates the process of verifying that other implementations are
compatible with CPython.

Like I said earlier in this issue, for me this is more a compiler
cleanliness issue rather than a performance issue.

--

___
Python tracker 

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

[issue6250] Python compiles dead code

[James Abbatiello]

James Abbatiello  added the comment:

I should add that the patch doesn't only address dead user-code.  It
also eliminates code that the compiler generates itself but that would
be unreachable at runtime.  Consider the following function:

def foo(x):
  if x:
raise Something
  else:
raise SomethingElse


Without the patch this would compile to:
  2   0 LOAD_FAST0 (x)
  3 POP_JUMP_IF_FALSE   15

  3   6 LOAD_GLOBAL  0 (Something)
  9 RAISE_VARARGS1
 12 JUMP_FORWARD 6 (to 21)

  5 >>   15 LOAD_GLOBAL  1 (SomethingElse)
 18 RAISE_VARARGS1
>>   21 LOAD_CONST   0 (None)
 24 RETURN_VALUE


With the patch this slims down to:

  2   0 LOAD_FAST0 (x)
  3 POP_JUMP_IF_FALSE   12

  3   6 LOAD_GLOBAL  0 (Something)
  9 RAISE_VARARGS1

  5 >>   12 LOAD_GLOBAL  1 (SomethingElse)
 15 RAISE_VARARGS1


So there are benefits even for normal code.

Also the END_FINALLY handling would be really hard to do in a pure
bytecode walker since context from the AST is needed (am I in a
try-finally or try-except or with statement?)

--

___
Python tracker 

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

[issue6250] Python compiles dead code

[Raymond Hettinger]

Raymond Hettinger  added the comment:

James, the peepholer currently assumes that codestrings terminate with
RETURN_VALUE.  Is this assumption invalidated by your code?

--

___
Python tracker 

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

[issue6287] distutils.core.setup does not document the 'license' meta-data

[Matthew Smart]

New submission from Matthew Smart :

The 'license' meta-data option is not listed under:

http://docs.python.org/distutils/setupscript.html#meta-data

There are others, too, from:

$ python setup.py --help
.. snip ..
Information display options (just display information, ignore any commands)
 --help-commands     list all available commands
 --name              print package name
 --version (-V)      print package version
 --fullname          print -
 --author            print the author's name
 --author-email      print the author's email address
 --maintainer        print the maintainer's name
 --maintainer-email  print the maintainer's email address
 --contact           print the maintainer's name if known, else the author's
 --contact-email     print the maintainer's email address if known, else the
                     author's
 --url               print the URL for this package
 --license           print the license of the package
 --licence           alias for --license
 --description       print the package description
 --long-description  print the long package description
 --platforms         print the list of platforms
 --classifiers       print the list of classifiers
 --keywords          print the list of keywords
 --provides          print the list of packages/modules provided
 --requires          print the list of packages/modules required
 --obsoletes         print the list of packages/modules made obsolete

--
assignee: tarek
components: Distutils
messages: 89410
nosy: mattsmart, tarek
severity: normal
status: open
title: distutils.core.setup does not document the 'license' meta-data
versions: Python 2.5

___
Python tracker 

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

[issue6192] add disable_nagle_algorithm to SocketServer.TCPServer

[Kristján Valur Jónsson]

Kristján Valur Jónsson  added the comment:

On consideration, it is more appropariate to have the 
disable_nagle_algorithm as part of StreamRequestHandler rather than in the 
TCPSockerServer.  It then sits right next to the rfile and wfile that 
affect it.
The RequestHandlers aren't documented as extensively as the socket 
servers, though, so the documentation will have to go.
Attached is a patch.

--
Added file: http://bugs.python.org/file14306/socketserver2.patch

___
Python tracker 

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

[issue6250] Python compiles dead code

[James Abbatiello]

James Abbatiello  added the comment:

Raymond, I've updated peephole.c to allow code to terminate with any of
RETURN_VALUE, END_FINALLY or RAISE_VARARGS [0-3].  I also added tests to
test_peepholer.py to make sure the peepholer still works in these cases.

--

___
Python tracker 

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

[issue6250] Python compiles dead code

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Martin, am transferring this to you for adjudication.  I'm -0 on the patch.

On the plus side, the code is well thought-out and reasonably well
tested.  On the minus side, it complexifies the compiler in a way that
may make it more difficult to maintain.

The benefits to the end-user are almost invisible.  

Developers may possibly benefit from the -r command-line argument as a
way of detecting errors in their own code, but this functionality may be
better suited to lint utilities such as pylint which already supports
detection of unreachable code).

We've rejected previous, less sophisticated patches for dead code
elimination on the theory that there was too little pay-off. And at one
point, Guido expressed a disinclination to any efforts to neaten-up the
generated bytecode (he compared it to rearranging assembly language and
thought there was little point to it).

--
assignee: rhettinger -> loewis
nosy: +loewis

___
Python tracker 

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

[issue6234] cgi.FieldStorage is broken when given POST data

[Miles Kaufmann]

Changes by Miles Kaufmann :


--
nosy: +milesck

___
Python tracker 

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

[issue6250] Python compiles dead code

[Martin v . Löwis]

Martin v. Löwis  added the comment:

I'm also happy with rejecting the patch, and agree with everything that
has been brought up against it: from an end-user point of view, there is
a negligible-if-any benefit (e.g. if you want to speed up importing, try
to reduce the number of stat() calls instead). For a developer, this
analysis is much better added to pylint.

Thanks for the contribution, anyway - don't get discouraged by this
rejection.

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

[issue6288] Update contextlib.nested docs in light of deprecation

[Nick Coghlan]

New submission from Nick Coghlan :

Just a placeholder to remind me to implement the suggestion from
python-dev of updating the contextlib.nested docs to show:

1. The one remaining valid use case (variable number of context managers)
2. The warnings module incantation needed to suppress the deprecation
warning

--
assignee: ncoghlan
components: Documentation
messages: 89415
nosy: benjamin.peterson, ncoghlan
priority: release blocker
severity: normal
status: open
title: Update contextlib.nested docs in light of deprecation
type: behavior
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

[issue5468] urlencode does not handle "bytes", and could easily handle alternate encodings

[Miles Kaufmann]

Miles Kaufmann  added the comment:

parse_qs and parse_qsl should also grow encoding and errors parameters to 
pass to the underlying unquote().

--
nosy: +milesck

___
Python tracker 

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

[issue6289] compile() raises SyntaxError with confusing message for some decoding problems

[Jean-Paul Calderone]

New submission from Jean-Paul Calderone :

Consider this source file:

  # coding: ascii
  ☃

It is not a valid Python program (for several reasons).  The first
problem encountered is that bytes representing SNOWMAN do not fit into
ASCII, so the file cannot be decoded using the declared encoding.

If one tries to import this file, a reasonable thing happens:

Traceback (most recent call last):
  File "", line 1, in 
  File "encodingfoo.py", line 2
SyntaxError: 'ascii' codec can't decode byte 0xe2 in position 0: ordinal
not in range(128)

If the builtin compile() is used instead, though, something different
happens:

Traceback (most recent call last):
  File "", line 1, in 
  File "", line 0
SyntaxError: unknown encoding: ascii

--
components: Library (Lib)
messages: 89417
nosy: exarkun
severity: normal
status: open
title: compile() raises SyntaxError with confusing message for some decoding 
problems
type: behavior
versions: Python 2.5

___
Python tracker 

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

[issue6289] compile() raises SyntaxError with confusing message for some decoding problems

[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

[issue6290] cPickle can misread data type

[Alex James]

New submission from Alex James :

When using cPickle to pickle / unpickle an object instance whose
__dict__ contains a dictionary of NumPy Arrays (on a windows32 system),
some of the array elements have the wrong type raising a ValueError:
could not convert string to float.  

On UNIX platform this error does not occur, and the data is read out in
the correct type every time.  
Forcing the caller to use pickle.py module instead removed the issue.

Statements about the imprecision of cPickle (such as issue1536, 655802),
or its deprecaition (now I can't find where that was mentioned), would
assist.  By contrast the current state of the documentation implies that
cPickle is better overall, and thus should be used preferentially.

--
assignee: georg.brandl
components: Documentation, Extension Modules, Windows
messages: 89418
nosy: ac.james, georg.brandl
severity: normal
status: open
title: cPickle can misread data type
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

[issue6286] distutils upload command doesn't work with http proxy

[Tarek Ziadé]

Changes by Tarek Ziadé :


--
type:  -> feature request

___
Python tracker 

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

[issue6286] distutils upload command doesn't work with http proxy

[Tarek Ziadé]

Tarek Ziadé  added the comment:

done in r73436. Will merge it into 3.2 after 3.1 is tagged.

I am leaving this issue open until the merge in 3.2 is done.

--

___
Python tracker 

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

[issue6289] compile() raises SyntaxError with confusing message for some decoding problems

[Benjamin Peterson]

Benjamin Peterson  added the comment:

Fixed in r73439.

--
nosy: +benjamin.peterson
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

[issue6290] cPickle can misread data type

[Alexandre Vassalotti]

Alexandre Vassalotti  added the comment:

Could you provide a test case? The behaviour you are describing sounds
like a bug in cPickle.

--
nosy: +alexandre.vassalotti

___
Python tracker 

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

[issue3672] Ill-formed surrogates not treated as errors during encoding/decoding

[hippietrail]

Changes by hippietrail :


--
nosy: +hippietrail

___
Python tracker 

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

[issue3407] test_urllib2_localnet fails on MacOS X 10.4.11 (Intel)

[Senthil]

Senthil  added the comment:

Closing it based on the (test pass) comments.
Fix was applied in r67779, r6.

--
status: open -> closed

___
Python tracker 

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

[issue6277] Add description of new syntax of with to 2.7 whatsnew document.

[Vikram U Shenoy]

Vikram U Shenoy  added the comment:

I see. OK, so you want me to close this bug ?

--

___
Python tracker 

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

[issue6277] Add description of new syntax of with to 2.7 whatsnew document.

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Thanks.  BTW, other doc patches are always welcome.

--
resolution:  -> wont fix
status: open -> closed

___
Python tracker 

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