[issue13405] Add DTrace probes

[anatoly techtonik]

anatoly techtonik  added the comment:

I am an almost complete 0 in C system programming and in DTrace matters,
but I feel like DTrace has a potential to help me understand internal
CPython processes better. If maintenance of the code with DTrace is hard,
there are several ways to make it easier:

1. PyCon talk and a reference to video (why DTrace is cool for Python and
how to use it)
2. Chapter in Development guide explaining DTrace magic, how it works
3. Annotated example (like in "dive into" series)

--

___
Python tracker 

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

[issue13703] Hash collision security issue

[Charles-François Natali]

Charles-François Natali  added the comment:

> A dict can contain non-orderable keys, I don't know how an AVL tree
> can fit into that.

They may be non-orderable, but since they are required to be hashable,
I guess one can build an comparison function with the following:

def cmp(x, y):
if x == y:
return 0
 elif hash(x) <= hash(y):
 return -1
 else:
 return 1

It doesn't yield a mathematical order because it lacks the
anti-symmetry property, but it should be enough for a binary search
tree.

--

___
Python tracker 

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

[issue13703] Hash collision security issue

[Frank Sievertsen]

Frank Sievertsen  added the comment:

> They may be non-orderable, but since they are required to be hashable,
> I guess one can build an comparison function with the following:

Since we are are trying to fix a problem where hash(X) == hash(Y), you
can't make them orderable by using the hash-values and build a binary
out of the (equal) hash-values.

--

___
Python tracker 

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

[issue13736] urllib.request.urlopen leaks exceptions from socket and httplib.client

[Senthil Kumaran]

Changes by Senthil Kumaran :


--
assignee:  -> orsenthil

___
Python tracker 

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

[issue13703] Hash collision security issue

[Charles-François Natali]

Charles-François Natali  added the comment:

> Since we are are trying to fix a problem where hash(X) == hash(Y), you
> can't make them orderable by using the hash-values and build a binary
> out of the (equal) hash-values.

That's not what I suggested.
Keys would be considered equal if they are indeed equal (__eq__). The
hash value is just used to know if the key belongs to the left or the
right child tree. With a self-balanced binary search tree, you'd still
get O(log(N)) complexity.

Anyway, I still think that the hash randomization is the right way to
go, simply because it does solve the problem, whereas the collision
counting doesn't: Martin made a very good point on python-dev with his
database example.

--

___
Python tracker 

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

[issue13703] Hash collision security issue

[Frank Sievertsen]

Frank Sievertsen  added the comment:

> The hash value is just used to know if the key belongs to the left
> or the right child tree.

Yes, that's what I don't understand: How can you do this, when ALL
hash-values are equal.

--

___
Python tracker 

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

[issue13817] deadlock in subprocess while running several threads using Popen

[Martijn van Oosterhout]

Martijn van Oosterhout  added the comment:

What a concidence, we had this problem as well and just today tracked it down, 
and turns out someone filed this bug yesterday.

I note the referenced bug (#13156) says that it's been fixed in the release 
branch but not yet released. I don't suppose there will be a release of 2.7 in 
the near future?

--
nosy: +Martijn.van.Oosterhout

___
Python tracker 

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

[issue13703] Hash collision security issue

[Charles-François Natali]

Charles-François Natali  added the comment:

> Yes, that's what I don't understand: How can you do this, when ALL
> hash-values are equal.

You're right, that's stupid.
Short night...

--

___
Python tracker 

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

[issue13703] Hash collision security issue

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

Charles-François Natali wrote:
> 
> Anyway, I still think that the hash randomization is the right way to
> go, simply because it does solve the problem, whereas the collision
> counting doesn't: Martin made a very good point on python-dev with his
> database example.

For completeness, I quote Martin here:

"""
The main issue with that approach is that it allows a new kind of attack.

An attacker now needs to find 1000 colliding keys, and submit them
one-by-one into a database. The limit will not trigger, as those are
just database insertions.

Now, if the applications also as a need to read the entire database
table into a dictionary, that will suddenly break, and not for the
attacker (which would be ok), but for the regular user of the
application or the site administrator.

So it may be that this approach actually simplifies the attack, making
the cure worse than the disease.
"""

Martin is correct in that it is possible to trick an application
into building some data pool which can then be used as indirect
input for an attack.

What I don't see is what's wrong with the application raising
an exception in case it finds such data in an untrusted source
(reading arbitrary amounts of user data from a database is just
as dangerous as reading such data from any other source).

The exception will tell the programmer to be more careful and
patch the application not to read untrusted data without
additional precautions.

It will also tell the maintainer of the application that there
was indeed an attack on the system which may need to be
tracked down.

Note that the collision counting demo patch is trivial - I just
wanted to demonstrate how it works. As already mentioned, there's
room for improvement:

If Python objects were to provide an additional
method for calculating a universal hash value (based on an
integer input parameter), the dictionary in question could
use this to rehash itself and avoid the attack. Think of this
as "randomization when needed". (*)

Since the dict would still detect the problem, it could also
raise a warning to inform the maintainer of the application.

So you get the best of both worlds and randomization would only
kick in when it's really needed to keep the application running.

--

___
Python tracker 

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

[issue13807] logging.Handler.handlerError() may raise AttributeError in traceback.print_exception()

[Roundup Robot]

Roundup Robot  added the comment:

New changeset b60c789c4ccd by Vinay Sajip in branch '2.7':
Closes #13807: Now checks for sys.stderr being there before writing to it.
http://hg.python.org/cpython/rev/b60c789c4ccd

New changeset 73dad4940b88 by Vinay Sajip in branch '3.1':
Closes #13807: Now checks for sys.stderr being there before writing to it.
http://hg.python.org/cpython/rev/73dad4940b88

New changeset 6a1a33a1fe93 by Vinay Sajip in branch '3.2':
Closes #13807: Merged fix from 3.1.
http://hg.python.org/cpython/rev/6a1a33a1fe93

New changeset de85a9c7fe94 by Vinay Sajip in branch 'default':
Closes #13807: Merged fix from 3.2.
http://hg.python.org/cpython/rev/de85a9c7fe94

--
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

___
Python tracker 

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

[issue13516] Gzip old log files in rotating handlers

[Vinay Sajip]

Vinay Sajip  added the comment:

Refactoring in 57295c4d81ac supports this use case.

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

___
Python tracker 

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

[issue8108] test_ftplib fails with OpenSSL 0.9.8m

[Maxim Yegorushkin]

Maxim Yegorushkin  added the comment:

I am still having this issue with Python-2.7.2 (which includes the patch) and 
openssl-devel-1.0.0e-1.fc14.x86_64:

  File "./download.py", line 195, in download_file
ftp.retrbinary("retr " + filename, lambda data: file.write(data))
  File "/usr/local/ots/python/lib/python2.7/ftplib.py", line 691, in retrbinary
conn.unwrap()
  File "/usr/local/ots/python/lib/python2.7/ssl.py", line 275, in unwrap
s = self._sslobj.shutdown()
socket.error: [Errno 0] Error

--
nosy: +max0x7ba

___
Python tracker 

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

[issue13703] Hash collision security issue

[STINNER Victor]

STINNER Victor  added the comment:

> Note that the collision counting demo patch is trivial - I just
> wanted to demonstrate how it works. As already mentioned, there's
> room for improvement:
>
> If Python objects were to provide an additional
> method for calculating a universal hash value (based on an
> integer input parameter), the dictionary in question could
> use this to rehash itself and avoid the attack. Think of this
> as "randomization when needed".

Yes, the solution can be improved, but maybe not in stable versions
(the patch for stable versions should be short and simple).

If the hash output depends on an argument, the result cannot be
cached. So I suppose that dictionary lookups become slower than the
dictionary switches to the randomized mode. It would require to add an
optional argument to hash functions, or add a new function to some (or
all?) builtin types.

--

___
Python tracker 

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

[issue13736] urllib.request.urlopen leaks exceptions from socket and httplib.client

[Antoine Pitrou]

Antoine Pitrou  added the comment:

I think the general pattern of wrapping exceptions in other exceptions is 
rather unfortunate. It makes it harder to examine the original problem (for 
example the ``errno`` attribute) for no actual gain.

--
nosy: +pitrou

___
Python tracker 

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

[issue13703] Hash collision security issue

[Charles-François Natali]

Charles-François Natali  added the comment:

> So you get the best of both worlds and randomization would only
> kick in when it's really needed to keep the application running.

Of course, but then the collision counting approach loses its main
advantage over randomized hashing: smaller patch, easier to backport.
If you need to handle a potential abnormal number of collisions
anyway, why not account for it upfront, instead of drastically
complexifying the algorithm? While larger, the randomization is
conceptually simpler.

The only argument in favor the collision counting is that it will not
break applications relying on dict order: it has been argued several
times that such applications are already broken, but that's of course
not an easy decision to make, especially for stable versions...

--

___
Python tracker 

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

[issue13760] ConfigParser exceptions are not pickleable

[Roundup Robot]

Roundup Robot  added the comment:

New changeset e63e2471f46f by Łukasz Langa in branch 'default':
#13760: picklability tests for configparser exceptions
http://hg.python.org/cpython/rev/e63e2471f46f

New changeset 76077971ee1f by Łukasz Langa in branch '3.2':
#13760: picklability tests for configparser exceptions
http://hg.python.org/cpython/rev/76077971ee1f

--
nosy: +python-dev

___
Python tracker 

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

[issue13822] is(upper/lower/title) are not exactly correct

[Ezio Melotti]

Changes by Ezio Melotti :


--
stage:  -> needs patch
type:  -> enhancement

___
Python tracker 

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

[issue13814] Generators as context managers.

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
nosy: +ncoghlan
versions: +Python 3.3 -Python 2.7, Python 3.4

___
Python tracker 

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

[issue13832] tokenization assuming ASCII whitespace; missing multiline case

[Jim Jewett]

Jim Jewett  added the comment:

Ignoring non-ascii whitespace is defensible, and I agree that it should match 
the rest of the parser.  Ignoring 2nd lines is still a problem, and supposedly 
part of what got fixed.  Test case:

s="""x=5  # comment
x=6
"""
compile(s, "", 'single')

--

___
Python tracker 

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

[issue13832] tokenization assuming ASCII whitespace; missing multiline case

[Benjamin Peterson]

Benjamin Peterson  added the comment:

$ ./python 
Python 3.3.0a0 (default:50a4af2ca654+, Jan 20 2012, 10:59:48) 
[GCC 4.5.3] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> s="""x=5  # comment
... x=6
... """
>>> compile(s, "", "single")
Traceback (most recent call last):
  File "", line 1, in 
  File "", line 1
x=5  # comment
 ^
SyntaxError: multiple statements found while compiling a single statement

--

___
Python tracker 

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

[issue13760] ConfigParser exceptions are not pickleable

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 5ecf650ede7c by Łukasz Langa in branch '2.7':
Fixes #13760: picklability of ConfigParser exceptions
http://hg.python.org/cpython/rev/5ecf650ede7c

--

___
Python tracker 

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

[issue13760] ConfigParser exceptions are not pickleable

[Łukasz Langa]

Łukasz Langa  added the comment:

3.2 and 3.3 already worked as expected. For 2.7 I did the __reduce__ workaround 
that's also used by SQLAlchemy.

--
resolution:  -> fixed
stage: test needed -> committed/rejected
status: open -> closed
type:  -> behavior

___
Python tracker 

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

[issue13736] urllib.request.urlopen leaks exceptions from socket and httplib.client

[Jyotirmoy Bhattacharya]

Jyotirmoy Bhattacharya  added the comment:

Antoine, could "raise ... from" be used here? Perhaps also using new subclasses 
of URLError to allow the exceptions to be caught with finer granularity. That 
way no information would be lost while at the same time not surprising clients 
who only catch URLError based on the documentation.

At least one exception which I feel must be wrapped is socket.timeout. Since we 
allow a timeout argument to urlopen, it doesn't make sense for the fact of the 
timeout to be announced by an exception from another library.

--

___
Python tracker 

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

[issue13822] is(upper/lower/title) are not exactly correct

[Giampaolo Rodola']

Changes by Giampaolo Rodola' :


--
nosy: +giampaolo.rodola

___
Python tracker 

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

[issue13736] urllib.request.urlopen leaks exceptions from socket and httplib.client

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> Antoine, could "raise ... from" be used here?

That's a possible compromise indeed. It's up to Senthil to decide
anyway.

>  Perhaps also using new subclasses of URLError to allow the exceptions
> to be caught with finer granularity. That way no information would be
> lost while at the same time not surprising clients who only catch
> URLError based on the documentation.

I agree there is a problem with the documentation announcing that all
exceptions will be wrapped. Honestly I would like it better if that
guarantee were dropped. In the meantime I'm not sure what the best
course of action is.

> At least one exception which I feel must be wrapped is socket.timeout.
> Since we allow a timeout argument to urlopen, it doesn't make sense
> for the fact of the timeout to be announced by an exception from
> another library.

You still may be interested to know that the request failed because of a
timeout rather than (say) an authentication failure, no?

--

___
Python tracker 

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

[issue13703] Hash collision security issue

[Jim Jewett]

Jim Jewett  added the comment:

Marc-Andre Lemburg:
>> So you get the best of both worlds and randomization would only
>> kick in when it's really needed to keep the application running.

Charles-François Natali
> The only argument in favor the collision counting is that it will not
> break applications relying on dict order:

There is also the "taxes suck" argument; if hashing is made complex,
then every object (or at least almost every string) pays a price, even
if it will never be stuck in a dict big enough to matter.

With collision counting, there are no additional operations unless and
until there is at least one collision -- in other words, after the
base hash algorithm has already started to fail for that particular
piece of data.

In fact, the base algorithm can be safely simplified further,
precisely because it does not need to be quite as adequate for
reprobes on data that does have at least one collision.

--

___
Python tracker 

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

[issue13703] Hash collision security issue

[Guido van Rossum]

Guido van Rossum  added the comment:

On Thu, Jan 19, 2012 at 8:58 PM, Frank Sievertsen wrote:

>
> Frank Sievertsen  added the comment:
>
> >> That's true. But without the suffix, I can pretty easy and efficient
> >> guess the prefix by just seeing the result of a few well-chosen and
> >> short repr(dict(X)). I suppose that's harder with the suffix.
>
> > Since the hash function is known, it doesn't make things much
> > harder. Without suffix you just need hash('') to find out what
> > the prefix is. With suffix, two values are enough
>
> This is obvious and absolutely correct!
>
> But it's not what I talked about. I didn't talk about the result of
> hash(X), but about the result of repr(dict([(str: val), (str:
> val)])), which is more likely to happen and not so trivial
> (if you want to know more than the last 8 bits)
>
> IMHO this problem shows that we can't advice dict() or set() for
> (potential dangerous) user-supplied keys at the moment.
>
> I prefer randomization because it fixes this problem. The
> collision-counting->exception prevents a software from becoming slow,
> but it doesn't make it work as expected.
>

That depends. If collision counting prevents the DoS attack that may be
"work as expected", assuming you believe (as I do) that "real life" data
won't ever have that many collisions.

Note that every web service is vulnerable to some form of DoS where a
sufficient number of malicious requests will keep all available servers
occupied so legitimate requests suffer delays and timeouts. The defense is
to have sufficient capacity so that a potential attacker would need a large
amount of resources to do any real damage. The hash collision attack vastly
reduces the amount of resources needed to bring down a service; crashing
early moves the balance of power significantly back, and that's all we can
ask for.

Sure, you can catch the exception. But when you get the exception,
> probably you wanted to add the items for a reason: Because you want
> them to be in the dict and that's how your software works.
>

No, real data would never make this happen, so it's a "don't care" case (at
least for the vast majority of services). An attacker could also send you
such a large amount of data that your server runs out of memory, or starts
swapping (which is almost worse). But that requires for the attacker to
have enough bandwidth to send you that data. Or they could send you very
many requests. Same requirement.

All we need to guard for here is the unfortunate multiplication of the
attacker's effort due to the behavior of the collision-resolution code in
the dict implementation. Beyond that it's every app for itself.

> Imagine an irc-server using a dict to store the connected users, using
> the nicknames as keys. Even if the irc-server catches the unexpected
> exception while connecting a new user (when adding his/her name to the
> dict), an attacker could connect 999 special-named users to prevent a
> specific user from connecting in future.
>

Or they could use many other tactics. At this point the attack is specific
to this IRC implementation and it's no longer Python's responsibility.

> Collision-counting->exception can make it possible to inhibit a
> specific future add to the dict. The outcome is highly application
> dependent.
>
> I think it fixes 95% of the attack-vectors, but not all and it adds a
> few new risks. However, of course it's much better then doing nothing
> to fix the problem.
>

Right -- it vastly increases the effort needed to attack any particular
service, and does not affect any behavior of existing Python apps.

--

___
Python tracker 

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

[issue13703] Hash collision security issue

[Jim Jewett]

Jim Jewett  added the comment:

On Fri, Jan 20, 2012 at 7:58 AM, STINNER Victor
> If the hash output depends on an argument, the result cannot be
> cached.

They can still be cached in a separate dict based on id, rather than
string contents.

It may also be possible to cache them in the dict itself; for a
string-only dict, the hash of each entry is already cached on the
object, and the cache member of the entry is technically redundant.
Entering a key with the alternative hash can also switch the lookup
function to one that handles that possibility, just as entering a
non-string key currently does.

> It would require to add an
> optional argument to hash functions, or add a new function to some
> (or all?) builtin types.

For backports, the alternative hashing could be done privately within
dict and set, and would not require new slots on other types.

--

___
Python tracker 

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

[issue13806] Audioop decompression frames size check fix

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Do you think it would be possible to add a test for valid compressed data that 
used to trigger the check?

--

___
Python tracker 

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

[issue13703] Hash collision security issue

[STINNER Victor]

STINNER Victor  added the comment:

I ran the test suite of Twisted 11.1 using a limit of 20 collisions:
there is no test failing because of hash collisions.

--

___
Python tracker 

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

[issue13760] ConfigParser exceptions are not pickleable

[Faheem Mitha]

Faheem Mitha  added the comment:

Thanks for the quick attention to this, Lukasz. I'm just curious. Why do 3.2 
and 3.3 already work? My understanding was that the basic exception issue in 
http://bugs.python.org/issue1692335 was still open.

--

___
Python tracker 

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

[issue11076] Iterable argparse Namespace

[Jean-Lou Dupont]

Changes by Jean-Lou Dupont :


--
nosy: +Jean-Lou.Dupont

___
Python tracker 

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

[issue13829] exception error

[Brett Cannon]

Brett Cannon  added the comment:

Can you isolate the cause? There is way too much in that core dump to try to 
debug the problem. Without knowing what code in this Moviegrabber app caused 
the bug we can't do anything to debug the issue.

--
nosy: +brett.cannon
status: open -> pending

___
Python tracker 

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

[issue13405] Add DTrace probes

[Jesús Cea Avión]

Changes by Jesús Cea Avión :


--
stage:  -> patch review

___
Python tracker 

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

[issue13829] exception error

[Dan kamp]

Dan kamp  added the comment:

On Jan 20, 2012, at 4:20 PM, Brett Cannon wrote:

> Can you isolate the cause? There is way too much in that core dump to try to 
> debug the problem. Without knowing what code in this Moviegrabber app caused 
> the bug we can't do anything to debug the issue.

All I know is that this happens with Moviegrabber and no other app that I am 
running (5 of them). Attached is the code I am using. This is WAY above what I 
know how to do but I can tell you that I am running it on a mac with 2.7.1 
installed and OSX lion. Attached is the source. Thanks

--
status: pending -> open

___
Python tracker 

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

[issue13703] Hash collision security issue

[Dave Malcolm]

Dave Malcolm  added the comment:

On Fri, 2012-01-06 at 12:52 +, Marc-Andre Lemburg wrote:
> Marc-Andre Lemburg  added the comment:
> 
> Demo patch implementing the collision limit idea for Python 2.7.
> 
> --
> Added file: http://bugs.python.org/file24151/hash-attack.patch
> 

Marc: is this the latest version of your patch?

Whether or not we go with collision counting and/or adding a random salt
to hashes and/or something else, I've had a go at updating your patch

Although debate on python-dev seems to have turned against the
collision-counting idea, based on flaws reported by Frank Sievertsen
http://mail.python.org/pipermail/python-dev/2012-January/115726.html
it seemed to me to be worth at least adding some test cases to flesh out
the approach.  Note that the test cases deliberately avoid containing
"hostile" data.

Am attaching an updated version which:
  * adds various FIXMEs (my patch isn't ready yet, but I wanted to get
more eyes on this)

  * introduces a new TooManyHashCollisions exception, and uses that
rather than KeyError (currently it extends BaseException; am not sure
where it should sit in the exception hierarchy).

  * adds debug text to the above exception, including the repr() and
hash of the key for which the issue was triggered:
  TooManyHashCollisions: 1001 hash collisions within dict at key
ChosenHash(999, 42) with hash 42

  * moves exception-setting to a helper function, to avoid duplicated
code

  * adds a sys.max_dict_collisions, though currently with just a
copy-and-paste of the 1000 value from dictobject.c

  * starts adding a test suite to test_dict.py, using a ChosenHash
helper class (to avoid having to publish hostile data), and a context
manager for ensuring the timings of various operations fall within sane
bounds, so I can do things like this:
with self.assertFasterThan(seconds=TIME_LIMIT) as cm:
for i in range(sys.max_dict_collisions -1 ):
key = ChosenHash(i, 42)
d[key] = 0

The test suite reproduces the TooManyHashCollisions response to a basic
DoS, and also "successfully" fails due to scenario 2 in Frank's email
above (assuming I understood his email correctly).

Presumably this could also incorporate a reproducer for scenario 1 in
this email, though I don't have one yet (but I don't want to make
hostile data public).

The patch doesn't yet do anything for sets.

Hope this is helpful
Dave

--
Added file: 
http://bugs.python.org/file24286/hash-collision-counting-dmalcolm-2012-01-20-001.patch

___
Python tracker 

___diff -r 3be60a4c8c63 Include/pyerrors.h
--- a/Include/pyerrors.hFri Jan 20 11:01:06 2012 -0500
+++ b/Include/pyerrors.hFri Jan 20 17:51:33 2012 -0500
@@ -207,6 +207,8 @@
 PyAPI_DATA(PyObject *) PyExc_BytesWarning;
 PyAPI_DATA(PyObject *) PyExc_ResourceWarning;
 
+PyAPI_DATA(PyObject *) PyExc_TooManyHashCollisions;
+
 
 /* Convenience functions */
 
diff -r 3be60a4c8c63 Lib/test/test_dict.py
--- a/Lib/test/test_dict.py Fri Jan 20 11:01:06 2012 -0500
+++ b/Lib/test/test_dict.py Fri Jan 20 17:51:33 2012 -0500
@@ -3,6 +3,8 @@
 
 import collections, random, string
 import gc, weakref
+import sys
+import time
 
 
 class DictTest(unittest.TestCase):
@@ -757,6 +759,192 @@
 self._tracked(MyDict())
 
 
+# Support classes for HashCollisionTests:
+class ChosenHash:
+"""
+Use this to create arbitrary collections of keys that are non-equal
+but have equal hashes, without needing to include hostile data
+within the test suite.
+"""
+def __init__(self, variability, hash):
+self.variability = variability
+self.hash = hash
+
+def __eq__(self, other):
+# The variability field is used to handle non-equalness:
+return self.variability == other.variability
+
+def __hash__(self):
+return self.hash
+
+def __repr__(self):
+return 'ChosenHash(%r, %r)' % (self.variability,
+   self.hash)
+
+class Timer:
+"""
+Simple way to measure time elapsed during a test case
+"""
+def __init__(self):
+self.starttime = time.time()
+
+def get_elapsed_time(self):
+"""Get elapsed time in seconds as a float"""
+curtime = time.time()
+return curtime - self.starttime
+
+def elapsed_time_as_str(self):
+"""Get elapsed time as a string (with units)"""
+return '%0.3f seconds' % self.get_elapsed_time()
+
+class TookTooLong(RuntimeError):
+def __init__(self, timelimit, elapsed, itercount=None):
+self.timelimit = timelimit
+self.elapsed = elapsed
+self.itercount = itercount
+
+def __str__(self):
+result = 'took >= %s seconds' % self.timelimit
+if self.itercount is not None:
+result += (' (%0.3f seconds elapsed after %i iterations)'
+  

[issue13782] xml.etree.ElementTree: Element.append doesn't type-check its argument

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Confirmed with on 3.2.2 Win7 for all three methods.
Docs say .append should raise AssertionError (see below).
However, that is unusual and TypeError is normal practice.
I am not sure what to do.

Our docs say: '''
append(subelement) 
Adds the element subelement to the end of this elements internal list of 
subelements.

extend(subelements) 
Appends subelements from a sequence object with zero or more elements. Raises 
AssertionError if a subelement is not a valid object.

insert(index, element) 
Inserts a subelement at the given position in this element.
'''

This implies to me that append and insert should do the same.
In fact, the current code has the assertion checks but they are commented out 
in all methods.

 From
http://effbot.org/zone/pythondoc-elementtree-ElementTree.htm
"append ... Raises AssertionError:
If a sequence member is not a valid object."
Ditto for .insert

Florent: why are all the assertion checks commented out in
Changeset: 59511 (831e30c0fd73) Issue #6472:
The xml.etree package is updated to ElementTree 1.3.
(March 2010)

Is the change in Fredrik's code, in spite of his docs?

--
nosy: +effbot, flox, terry.reedy
stage:  -> test needed

___
Python tracker 

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

[issue13790] In str.format an incorrect error message for list, tuple, dict, set

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Doc patch attached to make sure correct. Should {} be quoted?

Eric, do you want to close off the idea of changing :d errors, or switch back 
after the doc fix?

--
keywords: +patch
nosy: +terry.reedy
stage:  -> test needed
Added file: http://bugs.python.org/file24287/i13790.diff

___
Python tracker 

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

[issue13405] Add DTrace probes

[Jesús Cea Avión]

Jesús Cea Avión  added the comment:

My point about DTrace probes is not performance per-se but observability.

An OS with DTrace support can be completely inspected and shows you ALL the 
inner working. You can see a particular pattern in the operating system and 
locate the syscalls and the process involved. If it is a compiled program, you 
can actually look inside it and locate the particular function responsible and, 
even, its arguments.

You can not do that easily with an interpreted program, because when you 
inspect the stacktrace, you see the C interpreter functions, not the actual 
interpreted functions running. So, to be appropriately integrated with the 
impressive observability of the entire system, the interpreter must cooperate. 
That is the role of this patch. And that role is crucial.

Just an example I was checking today, just for fun: an email server written in 
Python.

I am interested in knowing which function is involved in database "misses", and 
so real READ harddisk activity. Since Berkeley DB is used as the backend, and 
Oracle has included dtrace probes on the library 
(http://docs.oracle.com/cd/E17076_02/html/programmer_reference/program_perfmon.html),
 we can do something like this:

"""
dtrace -n "bdb1066:::mpool-miss {@misses[jstack(20)]=count();}"
"""

This on-liner will trace process "1066" and with plug into the Berkeley DB 
cache miss event, recording the python stack (up to 20 levels) at each event 
fire. We let the monitor script go for a few seconds and ^c it, showing 
something like:

"""
dtrace: description 'bdb1066:::mpool-miss ' matched 1 probe
^C


  libdb-5.3.so`__memp_fget+0x22cb
  libdb-5.3.so`__ham_get_cpage+0x140
  libdb-5.3.so`__ham_lookup+0x8b
  libdb-5.3.so`__hamc_get+0x3d5
  libdb-5.3.so`__dbc_iget+0x40d
  libdb-5.3.so`__dbc_get+0x9d
  libdb-5.3.so`__db_get+0xb8
  libdb-5.3.so`__db_get_pp+0x2db
  _pybsddb.so`DB_get+0x1f5
  libpython2.7.so.1.0`PyCFunction_Call+0x148
  libpython2.7.so.1.0`PyEval_EvalFrameEx+0x55f2
[ 
/export/home/correo/durus-berkeleydbstorage/berkeleydb_storage.py:317 
(_prefetch_thread) ]
  libpython2.7.so.1.0`PyEval_EvalCodeEx+0x7a4
  libpython2.7.so.1.0`function_call+0x18f
  libpython2.7.so.1.0`PyObject_Call+0x5c
  libpython2.7.so.1.0`PyEval_EvalFrameEx+0x1d8e
[ /usr/local/lib/python2.7/threading.py:505 (run) ]
  libpython2.7.so.1.0`PyEval_EvalFrameEx+0x63ed
[ /usr/local/lib/python2.7/threading.py:552 (__bootstrap_inner) 
]
  libpython2.7.so.1.0`PyEval_EvalFrameEx+0x63ed
[ /usr/local/lib/python2.7/threading.py:525 (__bootstrap) ]
  libpython2.7.so.1.0`PyEval_EvalCodeEx+0x7a4
  libpython2.7.so.1.0`function_call+0x9a
  libpython2.7.so.1.0`PyObject_Call+0x5c
1

  libdb-5.3.so`__memp_fget+0x22cb
  libdb-5.3.so`__ham_get_cpage+0x140
  libdb-5.3.so`__ham_lookup+0x8b
  libdb-5.3.so`__hamc_get+0x3d5
  libdb-5.3.so`__dbc_iget+0x40d
  libdb-5.3.so`__dbc_get+0x9d
  libdb-5.3.so`__db_get+0xb8
  libdb-5.3.so`__db_get_pp+0x2db
  _pybsddb.so`DB_get+0x1f5
  libpython2.7.so.1.0`PyCFunction_Call+0x148
  libpython2.7.so.1.0`PyEval_EvalFrameEx+0x55f2
[ 
/export/home/correo/durus-berkeleydbstorage/berkeleydb_storage.py:725 (load) ]
  libpython2.7.so.1.0`PyEval_EvalCodeEx+0x7a4
  libpython2.7.so.1.0`function_call+0x18f
  libpython2.7.so.1.0`PyObject_Call+0x5c
  libpython2.7.so.1.0`PyEval_EvalFrameEx+0x1d8e
[ 
/export/home/correo/durus-berkeleydbstorage/berkeleydb_storage.py:430 (f) ]
  libpython2.7.so.1.0`PyEval_EvalCodeEx+0x7a4
  libpython2.7.so.1.0`PyEval_EvalFrameEx+0x4f89
[ 
build/bdist.solaris-2.10-i86pc/egg/durus/storage_server.py:302 
(_send_load_response) ]
  libpython2.7.so.1.0`PyEval_EvalFrameEx+0x63ed
[ 
build/bdist.solaris-2.10-i86pc/egg/durus/storage_server.py:295 (handle_L) ]
  libpython2.7.so.1.0`PyEval_EvalFrameEx+0x63ed
[ 
build/bdist.solaris-2.10-i86pc/egg/durus/storage_server.py:261 (handle) ]
  libpython2.7.so.1.0`PyEval_EvalFrameEx+0x63ed
[ 
build/bdist.solaris-2.10-i86pc/egg/durus/storage_server.py:227 (serve) ]
2

  libdb-5.3.so`__memp_fget+0x22cb
  libdb-5.3.so`__ham_get_cpage+0x140
  libdb-5.3.so`__ham_lookup+0x8b
  libdb-5.3.so`__hamc_get+0x3d5
  libdb-5.3.so`__dbc_iget+0x40d
  libdb-5.3.so`__dbc_get+0x9d
  libdb-5.3.so`__db_get+0xb8
  libdb-5.3.so`__db_get_pp+0x2db
   

[issue13790] In str.format an incorrect error message for list, tuple, dict, set

[Eric V. Smith]

Eric V. Smith  added the comment:

I don't think "{}" is the correct way to document this. These all have an empty 
format specifier:

"{}".format(foo)
"{:}".format(foo)
"{0}".format(foo)
"{0:}".format(foo)
"{name}".format(name=foo)
format(foo, "")
format(foo)

That is, they all call foo.__format__(""). If foo.__format__ (well, really 
type(foo).__format__) doesn't exist, then object.__format__(foo, "") gets 
called. It's object.__format__ that's checking for the empty format string, and 
if so it returns str(foo).

What would you suggest changing the ':d' error message to, for objects that 
don't support a format type of 'd'? This makes sense to me:

>>> format('', 'd')
Traceback (most recent call last):
  File "", line 1, in 
ValueError: Unknown format code 'd' for object of type 'str'

The problem, if there is one, is:
>>> format([], 'd')
Traceback (most recent call last):
  File "", line 1, in 
ValueError: Unknown format code 'd' for object of type 'str'

The problem is that the str that's producing this error doesn't know that it 
exists because object.__format__ returned str([]).

--

___
Python tracker 

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

[issue13796] use 'text=...' to define the text attribute of and xml.etree.ElementTree.Element

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Pedro and Patrick: if you are going to respond by email rather than by typing 
in the browser box, PLEASE delete the quoted text. Or on occasion, quote a line 
or two if really necessary, as when responding to a previous message other than 
the last one. Each message is assumed to be a response to the one immediately 
preceding, and that message is visible just above yours. This is not like a 
mail list where previous messages may have come and gone.

In any case, etree.ElementTree is documented as being a stable version F. 
Lundh's package and I am pretty sure that we are not going to change that by 
adding things on our own. So continue using your customized subclass.

"See http://effbot.org/zone/element-index.htm for tutorials and links to other 
docs. Fredrik Lundh’s page is also the location of the development version of 
the xml.etree.ElementTree.

Changed in version 3.2: The ElementTree API is updated to 1.3. For more 
information, see Introducing ElementTree 1.3."

--
nosy: +terry.reedy
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

[issue13798] Pasting and then running code doesn't work in the IDLE Shell

[Terry J. Reedy]

Changes by Terry J. Reedy :


--
resolution:  -> duplicate
status: open -> closed
superseder:  -> Pasted \n not same as typed \n

___
Python tracker 

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

[issue13799] Base 16 should be hexadecimal in Unicode HOWTO

[Terry J. Reedy]

Changes by Terry J. Reedy :


--
nosy: +terry.reedy

___
Python tracker 

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

[issue13804] Python library structure creates hard to read code when using higher order functions

[Terry J. Reedy]

Terry J. Reedy  added the comment:

I am closing this because map has even less chance of being made a collection 
method than join. Unlike join, map takes any positive number of iterables as 
args, not just one. 'Iterables' includes iterators, which intentionally need 
have no methods other than __iter__ and __next__.

If map were an attribute, it should be an attribute of 'function' (except that 
there is no one function class).

To abstract attributes, use get/setattr. Untested example: 

def atcat(self, src,  src_at, dst):
  res = []
  for col in getattr(self, src):
res += getattr(col, src_at)
  setattr(self, dst, res)

--
nosy: +terry.reedy
resolution:  -> rejected
status: open -> closed
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

[issue13812] multiprocessing package doesn't flush stderr on child exception

[Terry J. Reedy]

Changes by Terry J. Reedy :


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

[issue13703] Hash collision security issue

[Dave Malcolm]

Dave Malcolm  added the comment:

On Fri, 2012-01-20 at 22:55 +, Dave Malcolm wrote:
> Dave Malcolm  added the comment:
> 
> On Fri, 2012-01-06 at 12:52 +, Marc-Andre Lemburg wrote:
> > Marc-Andre Lemburg  added the comment:
> > 
> > Demo patch implementing the collision limit idea for Python 2.7.
> > 
> > --
> > Added file: http://bugs.python.org/file24151/hash-attack.patch
> > 
> 
> Marc: is this the latest version of your patch?
> 
> Whether or not we go with collision counting and/or adding a random salt
> to hashes and/or something else, I've had a go at updating your patch
> 
> Although debate on python-dev seems to have turned against the
> collision-counting idea, based on flaws reported by Frank Sievertsen
> http://mail.python.org/pipermail/python-dev/2012-January/115726.html
> it seemed to me to be worth at least adding some test cases to flesh out
> the approach.  Note that the test cases deliberately avoid containing
> "hostile" data.

I had a brainstorm, and I don't yet know if the following makes sense,
but here's a crude patch with another approach, which might get around
the issues Frank raises.

Rather than count the number of equal-hash collisions within each call
to lookdict, instead keep a per-dict count of the total number of
iterations through the probe sequence (regardless of the hashing),
amortized across all calls to lookdict, and if it looks like we're going
O(n^2) rather than O(n), raise an exception.  Actually, that's not quite
it, but see below...

We potentially have 24 words of per-dictionary storage hiding in the
ma_smalltable area within PyDictObject, which we can use when ma_mask >=
PyDict_MINSIZE (when mp->ma_table != mp->ma_smalltable), without
changing sizeof(PyDictObject) and thus breaking ABI.  I hope there isn't
any code out there that uses this space.  (Anyone know of any?)

This very crude patch uses that area to add per-dict tracking of the
total number of iterations spent probing for a free PyDictEntry whilst
constructing the dictionary.  It rules that if we've gone more than (32
* ma_used) iterations whilst constructing the dictionary (counted across
all ma_lookup calls), then we're degenerating into O(n^2) behavior, and
this triggers an exception.  Any other usage of ma_lookup resets the
count (e.g. when reading values back).  I picked the scaling factor of
32 from out of the air; I hope there's a smarter threshold.  

I'm assuming that an attack scenario tends to involve a dictionary that
goes through a construction phase (which the attacker is aiming to
change from O(N) to O(N^2)), and then a usage phase, whereas there are
other patterns of dictionary usage in which insertion and lookup are
intermingled for which this approach wouldn't raise an exception.

This leads to exceptions like this:

AlgorithmicComplexityError: dict construction used 4951 probes for 99
entries at key 99 with hash 42

(i.e. the act of constructing a dict with 99 entries required traversing
4951 PyDictEntry slots, suggesting someone is sending deliberately
awkward data).

Seems to successfully handle both the original DoS and the second
scenario in Frank's email.  I don't have a reproducer for the first of
Frank's scenarios, but in theory it ought to handle it.  (I hope!)

Have seen two failures within python test suite from this, which I hope
can be fixed by tuning the thresholds and the reset events (they seem to
happen when a large dict is emptied).

May have a performance impact, but I didn't make any attempt to optimize
it (beyond picking a power of two for the scaling factor).

(There may be random bits of the old patch thrown in; sorry)

Thoughts? (apart from "ugh! it's ugly!" yes I know - it's late here)
Dave

--
Added file: 
http://bugs.python.org/file24288/amortized-probe-counting-dmalcolm-2012-01-20-002.patch

___
Python tracker 

___diff -r 3be60a4c8c63 Include/pyerrors.h
--- a/Include/pyerrors.hFri Jan 20 11:01:06 2012 -0500
+++ b/Include/pyerrors.hFri Jan 20 22:11:43 2012 -0500
@@ -207,6 +207,8 @@
 PyAPI_DATA(PyObject *) PyExc_BytesWarning;
 PyAPI_DATA(PyObject *) PyExc_ResourceWarning;
 
+PyAPI_DATA(PyObject *) PyExc_AlgorithmicComplexityError;
+
 
 /* Convenience functions */
 
diff -r 3be60a4c8c63 Lib/test/test_dict.py
--- a/Lib/test/test_dict.py Fri Jan 20 11:01:06 2012 -0500
+++ b/Lib/test/test_dict.py Fri Jan 20 22:11:43 2012 -0500
@@ -3,6 +3,8 @@
 
 import collections, random, string
 import gc, weakref
+import sys
+import time
 
 
 class DictTest(unittest.TestCase):
@@ -757,6 +759,196 @@
 self._tracked(MyDict())
 
 
+# Support classes for HashCollisionTests:
+class ChosenHash:
+"""
+Use this to create arbitrary collections of keys that are non-equal
+but have equal hashes, without needing to include hostile data
+within the test suite.
+"""
+def __init__(self, variability, hash):

[issue6631] Disallow relative files paths in urllib*.open()

[Senthil Kumaran]

Changes by Senthil Kumaran :


--
title: urlparse.urlunsplit() can't handle relative files (for urllib*.open() -> 
Disallow relative files paths in urllib*.open()

___
Python tracker 

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

[issue6631] Disallow relative files paths in urllib*.open()

[Roundup Robot]

Roundup Robot  added the comment:

New changeset f6008e936fbc by Senthil Kumaran in branch '2.7':
Fix Issue6631 - Disallow relative files paths in urllib*.open()
http://hg.python.org/cpython/rev/f6008e936fbc

--
nosy: +python-dev

___
Python tracker 

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

[issue6631] Disallow relative files paths in urllib*.open()

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 4366c0df2c73 by Senthil Kumaran in branch '2.7':
NEWS entry for Issue6631
http://hg.python.org/cpython/rev/4366c0df2c73

New changeset 514994d7a9f2 by Senthil Kumaran in branch '3.2':
Fix  Issue6631 - Disallow relative file paths in urllib urlopen
http://hg.python.org/cpython/rev/514994d7a9f2

--

___
Python tracker 

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

[issue6631] Disallow relative files paths in urllib*.open()

[Senthil Kumaran]

Changes by Senthil Kumaran :


--
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type: performance -> behavior
versions: +Python 2.7, 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

[issue13814] Generators as context managers.

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Calling g.close() is pointless for a generator used in normal pull mode and run 
to completion, as in the example. The generator is already 'closed', so 
g.close() does not do anything useful. See
http://docs.python.org/py3k/reference/expressions.html#yield-expressions

The method was added to be used with .send() so that generators used in push 
mode could be told to finish up when there is nothing more to send. For such 
rare uses, contextlib.closing should usually be sufficient, I think.

So I think this issue should be closed.

--
nosy: +terry.reedy
stage:  -> test needed
status: open -> pending

___
Python tracker 

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

[issue13834] In help(bytes.strip) there is no info about leading ASCII whitespace

[py.user]

New submission from py.user :

help(bytes.strip):

strip(...)
B.strip([bytes]) -> bytes

Strip leading and trailing bytes contained in the argument.
If the argument is omitted, strip trailing ASCII whitespace.

--
assignee: docs@python
components: Documentation
messages: 151718
nosy: docs@python, py.user
priority: normal
severity: normal
status: open
title: In help(bytes.strip) there is no info about leading ASCII whitespace
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

[issue13815] tarfile.ExFileObject can't be wrapped using io.TextIOWrapper

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Based on other examples in the doc, I think the note
"... and also supports iteration over its lines."
should be extended with 
" It also has a dummy `flush` method, so that it can be wrapped using 
:class:`io.TextIOWrapper`."

Then just add
".. versionchanged:: 3.3
  Added the `flush` method."

I leave the test to Lars.

--
nosy: +terry.reedy
stage:  -> patch review
type:  -> enhancement

___
Python tracker 

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

[issue13790] In str.format an incorrect error message for list, tuple, dict, set

[R. David Murray]

R. David Murray  added the comment:

Oh, I see.  Yes, that is a problem.

object.__format__ knows the type of the object it was called on, right?  
Couldn't it catch the error and re-raise it with the correct type?  (If the 
type isn't str, of course, we don't want to get into an infinite recursion.)

--

___
Python tracker 

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

[issue13816] Two typos in the docs

[Terry J. Reedy]

Terry J. Reedy  added the comment:

The Chicago Manual of Style. which is perhaps the mostly widely used general 
style manual in the US, uses 'th' as a suffix without ' or -.
ie, 28th, etc except for 22d ('preferred' to 22nd) and 23d ('preferred' to 
23rd).

https://en.wiktionary.org/wiki/nth
gives nth, which I use, with *n*th (italic n) as alternate form (when italic is 
available) and n'th and n-th as 'sometimes used'. I think both of the last two 
are ugly and that we should use either nth or, since we can, *n*th.  I see that 
we already have *i*.

--
nosy: +terry.reedy

___
Python tracker 

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

[issue13790] In str.format an incorrect error message for list, tuple, dict, set

[R. David Murray]

R. David Murray  added the comment:

Oh, never mind that comment about recursion, I wasn't thinking it through.

--

___
Python tracker 

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

[issue13818] argparse: -h listening required options under optional arguments

[Terry J. Reedy]

Changes by Terry J. Reedy :


--
nosy: +bethard
stage:  -> test needed

___
Python tracker 

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

[issue13820] 2.6 is no longer in the future

[Roundup Robot]

Roundup Robot  added the comment:

New changeset c84b39c18963 by Terry Jan Reedy in branch '2.7':
Issue13820 as and with really became keywords in 2.6.
http://hg.python.org/cpython/rev/c84b39c18963

--
nosy: +python-dev

___
Python tracker 

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

[issue13820] 2.6 is no longer in the future

[Terry J. Reedy]

Terry J. Reedy  added the comment:

I verified that 'as' and 'with' are in the 2.6 keyword.kwlist.
http://svn.python.org/projects/python/branches/release26-maint/Lib/keyword.py. 
I verified that they work as keywords in 2.7.
http://svn.python.org/projects/python/branches/release26-maint/Doc/reference/compound_stmts.rst
says with is always enabled in 2.6.

I fixed whitespace error in 74551 (117d58fc6e8d)

--
assignee: docs@python -> terry.reedy
nosy: +terry.reedy
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

___
Python tracker 

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

[issue13790] In str.format an incorrect error message for list, tuple, dict, set

[Terry J. Reedy]

Terry J. Reedy  added the comment:

OK, the example of an empty format spec should be dropped. Let people figure it 
out ;-).

>>> format([], 'd')
Traceback (most recent call last):
  File "", line 1, in 
ValueError: Unknown format code 'd' for object of type 'str'

One possibility is to give (str of) the object instead of the type:

ValueError: Unknown format code 'd' for object '[]'

The downside is a long message for long strings. It would need to be limited 
(as is done in test error reports).

--

___
Python tracker 

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

[issue1602] windows console doesn't print or input Unicode

[akira]

Changes by akira <4kir4...@gmail.com>:


--
nosy: +akira

___
Python tracker 

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