[issue16930] mention limitations and/or alternatives to hg graft

[Terry J. Reedy]

Terry J. Reedy added the comment:

16.6 is just what I was suggesting. I had not read that far in the revised 
version. But I am glad I did to find out about auto-commit. There have been 
issues where I would not want that. (I will check to see if commit is really 
'alwats' or if there is an option to not commit, as with import and merge.)

I think that the worry about people not having graft available is misplaced. 
New people should be downloading the latest version of hg. Experienced users 
will know about the alternatives before they read 'hg graft'. Also, it seems 
easy enough to update hg (I plan to do so again soon), I think the main dev doc 
should assume that people have a recent enough version and describe what is 
most favored by experienced devs. (On quasi-religious issues like editors and 
dev methods, consensus is unreachable.)

As for case conflicts, how about adding a phrase to produce
"On older versions of Mercurial where hg graft is not available, or when graft 
has problems with case conflicts, you can use:"
(note /version/versions/, so a patch is needed anyway ;-).

Other than that, I think this issue should be closed unless and until there is 
a actual problem encountered, say by someone like me or with even less 
experience. Let's move on to another dev guide issue.

--

___
Python tracker 

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

[issue17316] Add Django 1.5 to benchmarks

[Ramchandra Apte]

Changes by Ramchandra Apte :


--
components: +Benchmarks
versions: +Python 3.4

___
Python tracker 

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

[issue17170] string method lookup is too slow

[Mark Shannon]

Changes by Mark Shannon :


--
nosy: +Mark.Shannon

___
Python tracker 

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

[issue16954] Add docstrings for ElementTree module

[David Lam]

David Lam added the comment:

here's an updated patch incorporating the feedback from Ezio and Eric:

   - moved docstrings put in some __special__ method names
   - made the description of 'tag' consistent:  'tag' means the elements name 
(as opposed to 'tag' being a synonym for "element"!)
   - docstring args now *stared* as opposed to 'quoted'


I also gave a shot at copying the existing docstrings into their respective C 
counterparts.  But it *seems* like you can't do so
that easily for a C extension. Maybe I missed something though: 

>>> from _elementtree import Element as cElement
>>> cElement.__doc__ = 'foobarbaz'
Traceback (most recent call last):
  File "", line 1, in 
TypeError: can't set attributes of built-in/extension type 
'xml.etree.ElementTree.Element'

I see one example in Modules/_json.c where the docstrings were sorta copied and 
pasted over, so perhaps it's an ok thing to do.

--
Added file: http://bugs.python.org/file29278/issue16954-v2.patch

___
Python tracker 

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

[issue16465] dict creation performance regression

[Christian Heimes]

Christian Heimes added the comment:

The patch gives a measurable speedup (./python is a patched 3.3.0+). IMO we 
should apply it. It's small and I can see no harm, too.

$ for PY in python2.7 python3.2 python3.3 ./python; do cmd="$PY -R -m timeit -n 
1000 '{};{};{};{};{};{};{};{};{};{}'"; echo $cmd; eval $cmd; done
python2.7 -R -m timeit -n 1000 '{};{};{};{};{};{};{};{};{};{}'
1000 loops, best of 3: 0.162 usec per loop
python3.2 -R -m timeit -n 1000 '{};{};{};{};{};{};{};{};{};{}'
1000 loops, best of 3: 0.142 usec per loop
python3.3 -R -m timeit -n 1000 '{};{};{};{};{};{};{};{};{};{}'
1000 loops, best of 3: 0.669 usec per loop
./python -R -m timeit -n 1000 '{};{};{};{};{};{};{};{};{};{}'
1000 loops, best of 3: 0.381 usec per loop

$ for PY in python2.7 python3.2 python3.3 ./python; do cmd="$PY -R -m timeit -n 
1000 'int(\"1\", base=16)'"; echo $cmd; eval $cmd; done
python2.7 -R -m timeit -n 1000 'int("1", base=16)'
1000 loops, best of 3: 0.268 usec per loop
python3.2 -R -m timeit -n 1000 'int("1", base=16)'
1000 loops, best of 3: 0.302 usec per loop
python3.3 -R -m timeit -n 1000 'int("1", base=16)'
1000 loops, best of 3: 0.477 usec per loop
./python -R -m timeit -n 1000 'int("1", base=16)'
1000 loops, best of 3: 0.356 usec per loop

--
nosy: +christian.heimes

___
Python tracker 

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

[issue17320] os.path.abspath in window7, return error

[xiaowei]

New submission from xiaowei:

assert os.path.split( os.path.abspath('\xe7\x8e\xb0' ) )[-1] == '\xe7\x8e\xb0'

# it should be true(no error) but py2.7 in window it's false
# and when linux it's ok
# os.path.split( os.path.abspath('\xe7\x8e\xb0' ) )[-1] == '\xe7\x8e'
# i guess it's a real bug , hope some one can resolve it
# i donot try py3.* , i donot know if it exists in 3.*

--
components: Windows
messages: 183212
nosy: xiaowei.py
priority: normal
severity: normal
status: open
title: os.path.abspath in window7, return error
type: behavior
versions: Python 2.7

___
Python tracker 

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

[issue12641] Remove -mno-cygwin from distutils

[Dan]

Dan added the comment:

That's bull, Eric. This is not about a corner case in cygwin. This is about 
mingw, which is the **main free software that builds executables on Windows**. 
You know, for when you don't want to require your users to install Visual 
Studio.

Additionally, both you and Matthias imposed artificial conditions that made it 
unlikely for patches to be created (search for "will insist").

Now, I have to agree that the larger python community (and not an 
under-resourced team like your good selves) should be involved in distutils (or 
choose and **support** a different package manager). But I'm not sure where I 
could file a bug for that (again, blogging may be the best choice).

--

___
Python tracker 

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

[issue16930] mention limitations and/or alternatives to hg graft

[Ezio Melotti]

Ezio Melotti added the comment:

> (I will check to see if commit is really 'alwats' or if there is an 
> option to not commit, as with import and merge.)

There isn't AFAIK, but two "tricks" I use are:
 1) "hg diff -c tip" to check the diff of what I just grafted;
 2) "hg rollback" to rollback the commit in case something is wrong;

I'll see if/where they should be added.

> New people should be downloading the latest version of hg.

That works on Windows, but on Unix most people just use the version shipped 
with their distribution.  "hg graft" is not so bleeding-edge anymore though -- 
I had it for a while using the default "hg".

> As for case conflicts, how about adding a phrase to produce
> "On older versions of Mercurial where hg graft is not available, or 
> when graft has problems with case conflicts, you can use:"

This (or the wording I suggested in msg183024 if it's accurate) would be ok 
with me.  Terry, have you tried using "hg graft" yet?  Are there conflicts on 
Windows?  I'm not sure how common these conflicts are -- I've never seen them 
myself.

> (note /version/versions/, so a patch is needed anyway ;-).

Yep, I spotted that but was waiting for this issue :)

--

___
Python tracker 

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

[issue17063] assert_called_with could be more powerful if it allowed placeholders

[Antoine Pitrou]

Antoine Pitrou added the comment:

Just got bitten by this again. Context: I have a protocol which is sending JSON 
datagrams over the wire and I'm checking the sent data. I can't exactly check 
the JSON-encoded content since dict ordering is undefined. So right now I have 
to write:

self.assertEqual(q.transport.send.call_count, 1)
(dgram, target), _ = q.transport.send.call_args
self.assertEqual(target, (PEER, PORT))
self.assertEqual(json.loads(dgram), { ... })

Clumsy, clumsy (note that I am too lazy to add a check for the kwargs).

Would be much better if I could simply write:

dgram, = q.tranport.assert_called_once_with(mock.ANY, (PEER, PORT))
self.assertEqual(json.loads(dgram), { ... })

--

___
Python tracker 

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

[issue17063] assert_called_with could be more powerful if it allowed placeholders

[Michael Foord]

Michael Foord added the comment:

Note that there is nothing stopping you using the mock.ANY and 
assert_called_once_with style assert currently. You're making your assert more 
clumsy than it needs to be.

With my proposal you could write:

q.tranport.assert_called_once_with(mock.ANY, (PEER, PORT))
dgram = q.tranport.call_args.args[0]
self.assertEqual(json.loads(dgram),expected)

You could currently be doing:

q.tranport.assert_called_once_with(mock.ANY, (PEER, PORT))
dgram = q.tranport.call_args[0][0]
self.assertEqual(json.loads(dgram), expected)

--
assignee:  -> michael.foord

___
Python tracker 

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

[issue17063] assert_called_with could be more powerful if it allowed placeholders

[Antoine Pitrou]

Antoine Pitrou added the comment:

I still have to do some tuple unpacking myself while assert_* already did it 
first. It can be tedious and error-prone (especially if there are several 
arguments to get).

If the assert methods returning something bothers you, how about introducing a 
new method match_call_with(...)?

--

___
Python tracker 

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

[issue17063] assert_called_with could be more powerful if it allowed placeholders

[Michael Foord]

Michael Foord added the comment:

Or create a JsonMatcher class that does it for you.


class JsonMatcher(object):
   def __init__(self, expected):
   self.expected = expected

   def __eq__(self, other):
   return json.loads(other) == self.expected

q.tranport.assert_called_once_with(JsonMatcher(expected), (PEER, PORT))

--

___
Python tracker 

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

[issue11367] xml.etree.ElementTree.find(all): docs are wrong

[Henrik Heimbuerger]

Henrik Heimbuerger added the comment:

That sounds good, Eli! I'll check the implementations and then adapt the other 
ElementTree methods as well. Will take until next week, though.

--

___
Python tracker 

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

[issue17321] Better way to pass objects between imp.find_module() and imp.load_module()

[Joe Borg]

New submission from Joe Borg:

If I want to use imp to find some load modules, I have to do it in quite an 
"unpythonic" way:

>>> name = "os"
>>> file, pathname, description = imp.find_module(name)
>>> imp.load_module(name, file, pathname, description)

Can there not be a better way to pass the tuple (or other object) between 
find_module() and load_module()?

I'm happy to patch this myself and submit, if it's not already been thought 
about.

--
messages: 183220
nosy: Joe.Borg
priority: normal
severity: normal
status: open
title: Better way to pass objects between imp.find_module() and 
imp.load_module()
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

[issue17321] Better way to pass objects between imp.find_module() and imp.load_module()

[R. David Murray]

R. David Murray added the comment:

Does importlib in Python3 provide what you need?  (New features such as this 
cannot be added to Python2.)

--
nosy: +r.david.murray

___
Python tracker 

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

[issue17321] Better way to pass objects between imp.find_module() and imp.load_module()

[Ezio Melotti]

Ezio Melotti added the comment:

imp e imp.find/load_module() are also deprecated (or will be deprecated soon).

--
nosy: +brett.cannon, ezio.melotti
type:  -> behavior

___
Python tracker 

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

[issue17321] Better way to pass objects between imp.find_module() and imp.load_module()

[Joe Borg]

Joe Borg added the comment:

Thanks for the swift feedback guys, if this is deprecated (i.e. not being 
carried to Python 3) then close the bug; I'll look at `importlib` and see if it 
carries the same problem.

--
type: behavior -> 

___
Python tracker 

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

[issue12641] Remove -mno-cygwin from distutils

[Éric Araujo]

Éric Araujo added the comment:

[Martin]
Thanks for the message.  My previous message actually quoted Dan, not you, so 
no apology is necessary.


[Dan]
> That's bull, Eric.
Could you rephrase this?  English is not my native language.

> This is not about a corner case in cygwin.
Oops I confused cygwin and mingw, apologies.

> This is about mingw, which is the **main free software that builds
> executables on Windows**. You know, for when you don't want to require
> your users to install Visual Studio.
Let me state that I fully sympathize with people who use Windows and still want 
to use free software as much as possible, even though some version of Visual 
Studio is now available at no cost.  Again, the fact is that many core 
developers don’t use Windows, and the official CPython builds use MSVC, so from 
this viewpoint, MinGW is a niche platform for CPython.  It does not mean that 
patches are rejected, just that it’s harder for me to assess them.

> Additionally, both you and Matthias imposed artificial conditions that
> made it unlikely for patches to be created (search for "will insist").
Martin used that in a comment about backward compatibility, which we do take 
seriously.  Roumen’s patches don’t break backward compat if I read them 
correctly.

> Now, I have to agree that the larger python community (and not an
> under-resourced team like your good selves) should be involved in
> distutils
Yes, more feedback, bug reports, patches and reviews from the community would 
help.

> (or choose and **support** a different package manager). But I'm not
> sure where I could file a bug for that
An effort is ongoing to define the successors of distutils.  One problem is 
that it lacks features (like dependencies), and at the same time it tries to be 
too much (build, upload, install).  The community (Python core developers, 
packaging tools developers, users) is working on these things.

> (again, blogging may be the best choice).
If you want to get involved in the packaging discussions, you can join the 
distutils-sig mailing list.  If you want to push this specific issue forward, 
testing the patches on your system would help.  If you want to support Python 
on MinGW in general, you can contribute a buildbot to our continuous 
integration system, so that we can see when things break.

--

___
Python tracker 

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

[issue17321] Better way to pass objects between imp.find_module() and imp.load_module()

[Brett Cannon]

Brett Cannon added the comment:

Both imp.find_module() and load_module() have been documented as deprecated 
since Python 3.3. I have not added the warning as I have to work through the 
stdlib first to remove all current uses.

But for what you are after, Joe, just use importlib.import_module() (which is 
available in Python 2.7 in the stdlib and earlier on PyPI).

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

[issue17321] Better way to pass objects between imp.find_module() and imp.load_module()

[Joe Borg]

Joe Borg added the comment:

Hi Brett, I missed the fact that it's deprecated as it's not mentioned in the 
2.* docs http://docs.python.org/2/library/imp.html.

I can see it is in the 3.*.

Thanks for the feedback.

--

___
Python tracker 

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

[issue12641] Remove -mno-cygwin from distutils

[Jon]

Jon added the comment:

[Eric]
>> This is about mingw, which is the **main free software that builds
>> executables on Windows**. You know, for when you don't want to require
>> your users to install Visual Studio.
> Let me state that I fully sympathize with people who use Windows and
> still want to use free software as much as possible, even though some
> version of Visual Studio is now available at no cost.  Again, the
> fact is that many core developers don’t use Windows, and the official
> CPython builds use MSVC, so from this viewpoint, MinGW is a niche
> platform for CPython.  It does not mean that patches are rejected,
> just that it’s harder for me to assess them.

I'm going to advocate why mingw-based toolchains (mingw.org and mingw-w64) 
should be considered important platforms for CPython by giving some background 
info.

An important part of this issue has nothing to do with the politics of "free 
software" and everything to do with the technical benefits of using mingw-based 
toolchains on Windows. While you may be aware of the technical benefits, the 
following are important to me:

1a) MSVC forces you to link against a specific CRT version, and I don't get to 
decide which CRT version via a build setting. To the best of my knowledge the 
only way to link against another CRT version is to use another MSVC version. 
Many times it's important for all parts of a codebase to link against the same 
CRT version to prevent well-known cross-CRT object usage failures. While Mingw 
toolchains typically link to msvcrt.dll by default, they allow you to specify a 
CRT version via spec file tweaks.

1b) Often the most practical/stable way to build mixed codebases using CRT 
functionality is to link everything against msvcrt.dll. Using MSVC, the only 
way I'm aware of is to use old-and-slow VC6 which is not easily available. 
Updated and performant mingw toolchains enable one to link against msvcrt.dll 
and other CRT versions via spec file hackery.

2) While VC++ is a good IDE, many of us would like to simply use the command 
line compiler tools and not clutter our environment with a huge IDE we never 
use. MSFT has a poor record on this front, and after many fine years of making 
the command line tools available as part of the Windows SDK, they've regressed 
back to their lame ways in Windows 8 by removing the cmd line compiler tools 
from the SDK and embedding into the IDE similar to the old VC6 days. Enticing 
as it may be, I'll stop here rather than lurch into sailor-speak rage rant.

There are other benefits, but (1a) and (1b) are very important for many 
real-world usage scenarios on Windows. For example, easily building mercurial 
with mingw on Windows that work with the official MSVC-built Python. Extend 
this to other widely used Python and non-Python libraries. Extend this to those 
building binary libraries on Linux/OSX via mingw for their Windows users.

Also, there are other build automation awesomeness things you can do with mingw 
toolchains. For example, wouldn't it be great if you could download your source 
software, a complete mingw toolchain, and build the software on Windows in a 
sandbox using the mingw toolchain? You can with mingw and mingw-w64 toolchains. 
Nothing to pre-install and highly automated with minimal user intervention.

--

___
Python tracker 

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

[issue16930] mention limitations and/or alternatives to hg graft

[Chris Jerdonek]

Chris Jerdonek added the comment:

The first and/or main place that recommends "hg graft" should link to the 
section with more detail for cases where users experience problems with graft.  
I also agree that the section should mention the case-folding error.  I'm using 
a pretty new version of hg (version 2.2.1+20120504) and get the error.  
(Mercurial's web site is down right now so I can't tell if it's the newest 
released version still.)

--

___
Python tracker 

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

[issue10967] move regrtest over to using more unittest infrastructure

[Chris Jerdonek]

Chris Jerdonek added the comment:

> Extending regrtest to support unittest test discovery directly is also a 
> worthwhile specific proposal.

Updating the tests to support discovery in all cases is discussed in (meta) 
issue 16748.  There are also many individual issues in the tracker (one per 
test module).

--
dependencies: +Make CPython test package discoverable

___
Python tracker 

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

[issue17307] HTTP PUT request Example

[karl]

karl added the comment:

Sentil:

About the PUT/POST, I would say:

A POST and PUT methods differs only by the 
intent of the enclosed representation. In the 
case of a POST, the target resource (URI) on 
the server decides what is the meaning of the 
enclosed representation in the POST request.
In a PUT request, the enclosed representation 
is meant to replace the state of the target 
resource (URI) on the server.
It is why PUT is idempotent.

About the code:

* http.client
I would remove the following comment, because the term "file" is confusing in 
HTTP terms.

   # This will create a resource file with contents of BODY

or I would say more exactly


   # This creates an HTTP message 
   # with the content of BODY as the enclosed representation 
   # for the resource http://localhost:8080/foobar

   >>> import http.client
   >>> BODY = "Some data"
   >>> conn = http.client.HTTPConnection("localhost", 8080)
   >>> conn.request("PUT", "/foobar", BODY) # The actual PUT Request
   >>> response = conn.getresponse()
   >>> print(resp.status, response.reason)

Maybe it would be good to display the message which is sent so people can 
understand what goes on the wire.

* urllib
the client code for urllib doesn't create challenge, I would had a content-type 
but no hard feeling about it. On the other hand the server code makes me a bit 
uncomfortable. It sets people into believing that this is the way you should 
reply to a PUT which is not really the case.

1. If the resource was not existing and has been successfully created, the 
server MUST answer 204.
2. if the resource already exists and has been successfully replaced/modified, 
then the server SHOULD answer either 200 or 204 (depending on the design choice)

There are plenty of other cases depending on the constraints.  See for the 
details 
http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-22#section-4.3.4

If we keep the server code, I would be willing to have a note saying that it is 
not usable as-is in production code. 

Does that make sense? :)

--
nosy: +karlcow

___
Python tracker 

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

[issue17279] Document which named built-in classes can be subclassed

[Terry J. Reedy]

Terry J. Reedy added the comment:

>From the current python-ideas 'range' thread:
Me: Would it be correct to say (now) that all 4 are intentional omissions? and 
not merely oversights?
Nick: Yes, I think so. People will have to be *real* convincing to explain a 
case where composition isn't a more appropriate solution.

--

___
Python tracker 

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

[issue14468] Update cloning guidelines in devguide

[Chris Jerdonek]

Chris Jerdonek added the comment:

Ezio, did you delete the section on null-merging in your commits?  I don't see 
it in the devguide anymore.

--

___
Python tracker 

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

[issue12455] urllib2 forces title() on header names, breaking some requests

[karl]

karl added the comment:

Note that HTTP header fields are case-insensitive.
See http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging#section-3.2

   Each HTTP header field consists of a case-insensitive field name
   followed by a colon (":"), optional whitespace, and the field value.

Basically the author of a request can set them to whatever he/she wants. But we 
should, IMHO, respect the author intent. It might happen that someone will 
choose a specific combination of casing to deal with broken servers and/or 
proxies. So a cycle of set/get/send should not modify at all the headers.

--
nosy: +karlcow

___
Python tracker 

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

[issue17322] urllib.request add_header() currently allows trailing spaces

[karl]

New submission from karl:

For HTTP header field names parsing, see 
http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-22#section-3.2.4

   No whitespace is allowed between the header field-name and colon. In
   the past, differences in the handling of such whitespace have led to
   security vulnerabilities in request routing and response handling.  A
   server MUST reject any received request message that contains
   whitespace between a header field-name and colon with a response code
   of 400 (Bad Request). A proxy MUST remove any such whitespace from a
   response message before forwarding the message downstream.


In python3.3 currently
 
>>> import urllib.request
>>> req = urllib.request.Request('http://www.example.com/')
>>> req.add_header('FoO ', 'Yeah')
>>> req.header_items()
[('Foo ', 'Yeah'), ('User-agent', 'Python-urllib/3.3'), ('Host', 
'www.example.com')]

The space has not been removed. So we should fix that at least. This is a bug. 
I'm not familiar with the specific security issues mentioned in the spec.  

Note that many things can be done too: :/

>>> req.add_header('FoO \n blah', 'Yeah')
>>> req.add_header('Foo:Bar\nFoo2', 'Yeah')
>>> req.header_items()
[('Foo:bar\nfoo2', 'Yeah'), ('Foo \n blah', 'Yeah'), ('Foo ', 'Yeah'), 
('User-agent', 'Python-urllib/3.3'), ('Host', 'www.example.com')]


I will check for making a patch tomorrow.

--
components: Library (Lib)
messages: 183234
nosy: karlcow, orsenthil
priority: normal
severity: normal
status: open
title: urllib.request add_header() currently allows trailing spaces
versions: Python 3.3

___
Python tracker 

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

[issue17322] urllib.request add_header() currently allows trailing spaces (and other weird stuff)

[karl]

Changes by karl :


--
title: urllib.request add_header() currently allows trailing spaces -> 
urllib.request add_header() currently allows trailing spaces (and other weird 
stuff)

___
Python tracker 

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

[issue16901] In http.cookiejar.FileCookieJar() the .load() and .revert() methods don't work

[py.user]

py.user added the comment:

Demian Brecht:
>My proposal was made to python-ideas.

try this
http://mail.python.org/mailman/listinfo/python-dev

--

___
Python tracker 

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

[issue17322] urllib.request add_header() currently allows trailing spaces (and other weird stuff)

[karl]

karl added the comment:

Yet another one leading spaces :(

>>> req = urllib.request.Request('http://www.example.com/')
>>> req.header_items()
[]
>>> req.add_header(' Foo3', 'Ooops')
>>> req.header_items()
[(' foo3', 'Ooops')]
>>> req.headers
{' foo3': 'Ooops'}

--

___
Python tracker 

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

[issue12455] urllib2 forces title() on header names, breaking some requests

[karl]

karl added the comment:

So looking at the casing of headers, I discovered other issues. I opened 
another bug. http://bugs.python.org/issue17322

--

___
Python tracker 

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

[issue17299] Test cPickle with real files

[R. David Murray]

R. David Murray added the comment:

Aman: another nit: PEP8 calls for no unneeded parentheses around logical 
expressions, so things like:

   if(self.f):

should be written:

   if self.f:

in order to adhere to our coding style.

Also, it's not obvious to me that there is any reason to rename the base 
classes (PicklerTests->AbstractIOPicklerTests, and same for Persistent test).

Finally, rereading Serhiy's note, Python3 only has "general IO streams", both 
non-IO files and cStringIO.StringIO are gone.  So this really is a 2.7-only 
issue, and only worth doing because 2.7 is a long term maintenance release.

--

___
Python tracker 

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

[issue747320] rfc2822 formatdate functionality duplication

[R. David Murray]

R. David Murray added the comment:

Could you regenerate your patch using hg diff? (or at least diff -u)?

--

___
Python tracker 

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

[issue12641] Remove -mno-cygwin from distutils

[Dan]

Dan added the comment:

There's an additional aspect. Even though I don't use Windows as a development 
platform, I care about being able to propose Python to clients as a 
cross-platform technology (instead of, say, Java). Having an essential piece of 
Python infrastructure fail miserably on Windows impacts Python's appeal / 
credentials.

To clarify another point, I think that Python should pick and support an 
"official" package manager (be it distutils, pip or whatever) not eventually, 
but ASAP. For the time being it looks like distutils is a keystone, therefore 
it needs to work.

--

___
Python tracker 

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

[issue12641] Remove -mno-cygwin from distutils

[Jon]

Jon added the comment:

Eric, I'm assuming you are the key decision maker for any fix. As I want to see 
this issue stay razor focused, where specifically do you need community help?

Depending upon your needs, I can test on my win7 32bit notebook with official 
python 2.7.3. It also has arch 3.7.9 and ubuntu server 12.10 virtualbox vm's. I 
don't build python from source with mingw and my win8 64bit box isn't ready 
yet. The win7 box has mingw gcc 4.6.2 32bit and mingw-w64 32bit toolchains, 
both of which have msys and autohell goodies. I'm swamped these days but will 
carve out time from somewhere.

--

___
Python tracker 

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

[issue747320] rfc2822 formatdate functionality duplication

[karl]

karl added the comment:

R. David Murray:

Sure. Is it better? issue-747320-1.patch

It seems there are already tests for gmt date format in 
Lib/test/test_email/test_utils.py

--
Added file: http://bugs.python.org/file29279/issue-747320-1.patch

___
Python tracker 

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

[issue17299] Test cPickle with real files

[Aman Shah]

Aman Shah added the comment:

I had put in the renaming because "ioclass" is not defined in the class itself, 
only in the subclasses. So, instantiating it and using dumps/loads would be 
meaningless and would raise an error. Which is similar to the behavior of an 
abstract class.
Also, the "if(self.f):" part can be improved as you said and I looked at the 
patch for other similar mistakes. But, it's an isolated mistake (at lines 33 
and 74) and so maybe it can be fixed during the merge itself?

--

___
Python tracker 

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