[issue13661] maniandram maniandram wants to chat

[maniram maniram]

maniram maniram  added the comment:

Sorry, accident.
Please delete.

--
nosy: +maniram.maniram

___
Python tracker 

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

[issue13660] maniandram maniandram wants to chat

[maniram maniram]

Changes by maniram maniram :


--
nosy: +maniram.maniram

___
Python tracker 

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

[issue13660] maniandram maniandram wants to chat

[maniram maniram]

maniram maniram  added the comment:

Sorry, accident.
Please delete.

--

___
Python tracker 

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

[issue13661] maniandram maniandram wants to chat

[maniram maniram]

maniram maniram  added the comment:

Please close this bug.

--

___
Python tracker 

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

[issue13660] maniandram maniandram wants to chat

[maniram maniram]

maniram maniram  added the comment:

Please close this bug as invalid.

--

___
Python tracker 

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

[issue13660] maniandram maniandram wants to chat

[maniram maniram]

maniram maniram  added the comment:

I can't edit this bug.

--

___
Python tracker 

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

[issue13644] Python 3 aborts with this code.

[Georg Brandl]

Georg Brandl  added the comment:

Why?

--

___
Python tracker 

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

[issue13644] Python 3 aborts with this code.

[Georg Brandl]

Changes by Georg Brandl :


--
Removed message: http://bugs.python.org/msg150226

___
Python tracker 

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

[issue13644] Python 3 aborts with this code.

[Georg Brandl]

Georg Brandl  added the comment:

> Nothing, but that would be pointless; the recursion would just start again.

Why?

--

___
Python tracker 

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

[issue13660] maniandram maniandram wants to chat

[Antoine Pitrou]

Changes by Antoine Pitrou :


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

[issue13661] maniandram maniandram wants to chat

[Antoine Pitrou]

Changes by Antoine Pitrou :


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

[issue13639] UnicodeDecodeError when creating tar.gz with unicode name

[Lars Gustäbel]

Lars Gustäbel  added the comment:

I thought about that myself, too. It is clearly no new feature, it is really 
more some kind of a fix.

Unicode pathnames given to tarfile.open() are just passed through to the open() 
function, which is why this always has been working, except for this particular 
case. There are 6 different possible write modes: "w:", "w:gz", "w:bz2", "w|", 
"w|gz" and "w|bz2". And the only one not working with a unicode pathname is 
"w|gz". Although admittedly tarfile.open() is not supposed to be used with a 
unicode path, people do it anyway, because they don't care, and because it 
works. The patch does not add a new broad functionality, it merely harmonises 
the way the six write modes work.

Neither can we retroactively enforce using string pathnames at this point, nor 
should we let a user run into this strange error. The patch is very small and 
minimally invasive. The error message you get without the patch is completely 
incomprehensible.

--

___
Python tracker 

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

[issue13644] Python 3 aborts with this code.

[Benjamin Peterson]

Benjamin Peterson  added the comment:

2011/12/24 Georg Brandl :
>
> Georg Brandl  added the comment:
>
>> Nothing, but that would be pointless; the recursion would just start again.

Because it would be caught in the function call above in the stack?

--

___
Python tracker 

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

[issue13644] Python 3 aborts with this code.

[Benjamin Peterson]

Benjamin Peterson  added the comment:

Basically forget my last 3 messages.

--

___
Python tracker 

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

[issue13644] Python 3 aborts with this code.

[Georg Brandl]

Georg Brandl  added the comment:

Would it?

--

___
Python tracker 

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

[issue13644] Python 3 aborts with this code.

[Benjamin Peterson]

Benjamin Peterson  added the comment:

2011/12/24 Georg Brandl :
>
> Georg Brandl  added the comment:
>
> Would it?

(,)

--

___
Python tracker 

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

[issue11105] Compiling evil ast crashes interpreter

[Ezio Melotti]

Changes by Ezio Melotti :


--
components: +None
stage:  -> test needed
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

[issue7338] recursive __attribute__ -> Fatal Python error: Cannot recover from stack overflow.

[Ezio Melotti]

Ezio Melotti  added the comment:

> This is normal.

Can this be closed then?

--
nosy: +ezio.melotti
versions: +Python 3.2, Python 3.3 -Python 3.1

___
Python tracker 

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

[issue1953] Compact int and float freelists

[Ezio Melotti]

Changes by Ezio Melotti :


--
nosy:  -BreamoreBoy
versions: +Python 3.3 -Python 3.2

___
Python tracker 

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

[issue13413] time.daylight incorrect behavior in linux glibc

[Ezio Melotti]

Changes by Ezio Melotti :


--
nosy: +amaury.forgeotdarc

___
Python tracker 

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

[issue11977] Document int.conjugate, .denominator, ...

[Ezio Melotti]

Ezio Melotti  added the comment:

Isn't there a way to specify multiple targets for the same entry?
The doc could say that int, float and complex all share some methods/attributes 
and then either list e.g. int.conjugate, float.conjugate, complex.conjugate 
with a single description or use just int (or even numbers.Number) and create 
targets for float and complex too in some other way, so that float.conjugate 
automatically links to the description of Number.conjugate.
I don't think it's necessary to document all methods/attributes in the same 
place.  These methods/attributes are not so common, so it's ok to have them 
documented in the numbers.Number page, for example.  A simple link to the page 
can then be added to the int/float/complex docs.
See also #4966 for a discussion about the reorganization of the stdtypes page.

--

___
Python tracker 

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

[issue7098] g formatting for decimal types should always strip trailing zeros.

[Ezio Melotti]

Changes by Ezio Melotti :


--
versions: +Python 3.3 -Python 2.6, Python 3.1

___
Python tracker 

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

[issue7098] g formatting for decimal types should always strip trailing zeros.

[Raymond Hettinger]

Raymond Hettinger  added the comment:

I would like to think about this one for a bit before it moves forward.

--
nosy: +rhettinger

___
Python tracker 

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

[issue7338] recursive __attribute__ -> Fatal Python error: Cannot recover from stack overflow.

[Roger Serwy]

Roger Serwy  added the comment:

This is related to #13644.

--
nosy: +serwy

___
Python tracker 

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

[issue13639] UnicodeDecodeError when creating tar.gz with unicode name

[Terry J. Reedy]

Terry J. Reedy  added the comment:

With that explanation, that it is one case out of six that fails, for whatever 
reason, I agree.

That leaves the issue of whether the fix is the right one. I currently agree 
with Victor that we should do what the rest of Python does and what is most 
universally useful. That fact that an old standard requires a *storage* 
encoding for a nearly unused field for .gz files that (I believe) only works 
for Western Europe, does not mean we should use it for *opening* .tar files. 
WestEuro-centrism is as bad as Anglo-centrism. If the unicode filename cannot 
be Latin-1 encoded, the filename field should be left blank. But it seems to me 
that the filename should be converted to the bytes that the user wants, 
expects, and can use.

--
type:  -> behavior

___
Python tracker 

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

[issue13644] Python 3 aborts with this code.

[Terry J. Reedy]

Terry J. Reedy  added the comment:

@maniram I know what IDLE does. For the tracker, a 'bug' is a discrepancy 
between doc and behavior. According to the doc, a recursion loop should 
continue forever, just like an iteration loop ;=).

Anyway, Roger is right, this is a duplicate of #6028, which has at least a 
preliminary patch.

--
resolution:  -> duplicate
status: open -> closed
superseder:  -> Interpreter crashes when chaining an infinite number of 
exceptions

___
Python tracker 

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

[issue7338] recursive __attribute__ -> Fatal Python error: Cannot recover from stack overflow.

[Terry J. Reedy]

Terry J. Reedy  added the comment:

This seems to be a duplicate of 3555 and 6028. I am redirecting to the latter 
because is has a proposed patch.

--
nosy: +terry.reedy
resolution:  -> duplicate
status: open -> closed
superseder:  -> Interpreter crashes when chaining an infinite number of 
exceptions
type: crash -> behavior

___
Python tracker 

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

[issue3555] Regression: nested exceptions crash (Cannot recover from stack overflow)

[Terry J. Reedy]

Terry J. Reedy  added the comment:

This is one of four essentially duplicate issues #6028, #7338, #13644.
#6028 has a proposed patch.

--
nosy: +terry.reedy
resolution:  -> duplicate
status: open -> closed
versions: +Python 3.3 -Python 3.0

___
Python tracker 

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

[issue6028] Interpreter aborts when chaining an infinite number of exceptions

[Terry J. Reedy]

Terry J. Reedy  added the comment:

I believe #3555, #7338, and *13644 are basically duplicates of this issue. I 
have left this one open because it has a try at a patch. I think any patch 
should be tested with the other examples.

I agree with Antoine that an intentional exit is not a crash.
I also agree that the current procedure is not really a bug either. According 
to the language spec, the interpreter should recurse forever;-), just like 
"while True: pass" iterates 'forever'. Given that it does not due to finite 
limitations, the exact alternate behavior is undefined.

Now, if someone can find a way to better handle infinite recursion mixed with 
exceptions, without re-introducing real crashes or eliminating the benefits of 
the 3.0 changes, great.

Yury, I think Antoine's point is that gracefully handling all the different 
kinds of programming mistakes in a finite system is a delicate and difficult 
balancing act.

--
nosy: +terry.reedy
stage:  -> patch review
title: Interpreter crashes when chaining an infinite number of exceptions -> 
Interpreter aborts when chaining an infinite number of exceptions
type: crash -> behavior
versions: +Python 3.2, Python 3.3 -Python 3.0

___
Python tracker 

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

[issue2134] Add new attribute to TokenInfo to report specific token IDs

[Meador Inge]

Meador Inge  added the comment:

> The cmdoption directive should be used with a program directive.

Ah, nice.  Thanks for the tip Éric.

Updated patch attached along with a patch for the 2.7/3.2 doc update attached.

--
Added file: http://bugs.python.org/file24088/tokenize-exact-type-v1.patch

___
Python tracker 

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

[issue2134] Add new attribute to TokenInfo to report specific token IDs

[Meador Inge]

Changes by Meador Inge :


Added file: http://bugs.python.org/file24089/tokenize-docs-2.7-3.2.patch

___
Python tracker 

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

[issue6028] Interpreter aborts when chaining an infinite number of exceptions

[Yury]

Yury  added the comment:

Rather than aborting with a stack overflow, I feel it is more natural to raise 
an exception. If it is not too difficult to implement, perhaps another type of 
exception should be raised. Since chained exceptions are new to 3.x, there 
should be a new exception to describe errors that happen in chaining. Perhaps 
stopping chaining at a certain depth and truncating all further exceptions with 
a blanket "ChainingException" exception. Or perhaps truncating the chain and 
wrapping it in another exception before returning it to user code.

While this is my proposed solution, I apologize I cannot volunteer to write the 
patch. The time investment on my part would involve learning most of the 
working of the interpreter. Perhaps someone who is already familiar with it 
would be interested.

--

___
Python tracker 

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

[issue13294] http.server: minor code style changes.

[Ezio Melotti]

Ezio Melotti  added the comment:

The first chunk of the patch (the use of strip) changes the behavior as 
discussed in the previous comments, so it should probably be reverted.  The 
rest of the changes are OK.

--
status: closed -> open

___
Python tracker 

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

[issue6028] Interpreter aborts when chaining an infinite number of exceptions

[Arfrever Frehtes Taifersar Arahesis]

Changes by Arfrever Frehtes Taifersar Arahesis :


--
nosy: +Arfrever

___
Python tracker 

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

[issue13642] urllib incorrectly quotes username and password in https basic auth

[Jesús Cea Avión]

Jesús Cea Avión  added the comment:

Joonas, this issue seems easy to solve. Do you want to try to post a patch?. 
Extra credits for patching testsuite too :).

If you work in 2.7, I promise to up-port the patch to 3.x.

--
nosy: +jcea

___
Python tracker 

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

[issue13294] http.server: minor code style changes.

[Senthil Kumaran]

Senthil Kumaran  added the comment:

The concern here is if the request line had something like this.

Method SP Request-URI SP HTTP-Version \r\n

The previous behavior would have resulted in 

Method SP Request-URI SP HTTP-Version 

That is removing only the final \r\n, whereas the current change would make it

Method SP Request-URI SP HTTP-Version 

That is removes all the trailing \r\n combination.

BTW, thing to note this, this is only for request line and not the header
lines.  And for request-line, both HTTP 1.0 and HTTP 1.1 spec has this in 
section
5.1

5.1  Request-Line

   The Request-Line begins with a method token, followed by the
   Request-URI and the protocol version, and ending with CRLF. The
   elements are separated by SP characters. No CR or LF are allowed
   except in the final CRLF sequence.

   Request-Line = Method SP Request-URI SP HTTP-Version CRLF

Which leads me to believe that, removing all the trailing \r\n is a fine thing
to do and should not be harmful.

Just to augment this with few other things I found while (re-)reading the spec.
This advise is different from Header's trailing whitespace, which is called
Linear White space (LWS).  If the Host Header looks like, e.g.  "Host:
www.foo.com \r\n" (notice the trailing white space), 

According to RFC 2616 (HTTP 1.1), section 4.2 Message Headers:

   The field-content does not include any leading or trailing LWS:
   linear white space occurring before the first non-whitespace
   character of the field-value or after the last non-whitespace
   character of the field-value. Such leading or trailing LWS MAY be
   removed without changing the semantics of the field value.

RFC 1945 (HTTP 1.0), section 4.2 Message Headers does not make such an explicit
statement.

My guess on the former behavior in http/server.py is that it was thought that
Request-Line was following something like section 4.2 on HTTP 1.0 spec and only
the last two characters were removed. But actually, the request-line as per
spec should have only one CRLF as end char. In the Docstring of the
BaseHTTPServer class, there is a mention about preserving the trailing
white-space, but it does not point to any authoritative reference, so I am sure
taking docstring as reference to preserve the behavior is a good idea.

Before dwelling to find the reason, I was thinking if reverting the patch in
2.7 and 3.1 would be a good idea.  But give that change has support from older
specs to new ones, I am inclined to think that leave the change as such
(without reverting) should be fine as well. 

Only if we find a stronger backwards compatibility argument for leaving
trailing \r\n in request-line, then we should remove it in 2.7 and 3.2,
otherwise we can leave it as such.

--

___
Python tracker 

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