[issue3982] support .format for bytes

[Guido van Rossum]

Guido van Rossum added the comment:

I don't believe it either. I find join consistently faster than format:

python2.7 -m timeit -s 'x = [b"x"*1000']*10 'b"".join(x)'
100 loops, best of 3: 0.686 usec per loop

python2.7 -m timeit -s 'x = b"x"*1000'
'(b"{}{}{}{}{}{}{}{}{}{}").format(x, x, x, x, x, x, x, x, x, x)'
10 loops, best of 3: 2.37 usec per loop

Try longer strings, same results (though less pronounced):

python2.7 -m timeit -s 'x = [b"x"*1']*10 'b"".join(x)'
10 loops, best of 3: 3.54 usec per loop

python2.7 -m timeit -s 'x = b"x"*1'
'(b"{}{}{}{}{}{}{}{}{}{}").format(x, x, x, x, x, x, x, x, x, x)'
10 loops, best of 3: 7.35 usec per loop

I'm guessing the advantage of format() is that it allows the
occasional formatting of a float or int.

And % is not significantly faster:

python2.7 -m timeit -s 'x = b"x"*1000' '(b"%s%s%s%s%s%s%s%s%s%s") %
(x, x, x, x, x, x, x, x, x, x)'
10 loops, best of 3: 2.31 usec per loop

python2.7 -m timeit -s 'x = b"x"*1' '(b"%s%s%s%s%s%s%s%s%s%s") %
(x, x, x, x, x, x, x, x, x, x)'
10 loops, best of 3: 6.81 usec per loop

python2.7 -m timeit -s 'x = b"x"*10' '(b"%s%s%s%s%s%s%s%s%s%s") %
(x, x, x, x, x, x, x, x, x, x)'
1000 loops, best of 3: 565 usec per loop

--

___
Python tracker 

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

[issue16957] shutil.which() shouldn't look in working directory on unix-y systems

[Roundup Robot]

Roundup Robot added the comment:

New changeset f18d11ab53a0 by Serhiy Storchaka in branch '3.3':
Issue #16957: shutil.which() no longer searches a bare file name in the
http://hg.python.org/cpython/rev/f18d11ab53a0

New changeset 7b51568cfbae by Serhiy Storchaka in branch 'default':
Issue #16957: shutil.which() no longer searches a bare file name in the
http://hg.python.org/cpython/rev/7b51568cfbae

--
nosy: +python-dev

___
Python tracker 

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

[issue16957] shutil.which() shouldn't look in working directory on unix-y systems

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Committed. Thank you for for the patch.

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

___
Python tracker 

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

[issue14771] Occasional failure in test_ioctl

[Ezio Melotti]

Changes by Ezio Melotti :


--
status: open -> pending

___
Python tracker 

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

[issue11201] Python installation error 2203

[Ezio Melotti]

Changes by Ezio Melotti :


--
resolution:  -> out of date
stage:  -> committed/rejected
status: pending -> closed

___
Python tracker 

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

[issue3982] support .format for bytes

[Eric V. Smith]

Eric V. Smith added the comment:

I think ''.join() will always be faster than ''.format(), for a number of 
reasons (some already stated):
- it doesn't have to pass the format string
- it doesn't have to do the __format__ lookup and call the resulting function 
(although I believe there's an optimization for str)
- it doesn't have to consider the conversion and formatting steps

Whether b''.format() would have to lookup and call __format__ remains to be 
seen. From what I've read, maybe baking in knowledge of bytes, float, and int 
would be good enough. I suspect there might be some need for datetimes, but I 
could be wrong.

The above said, code using b''.format() would definitely be easier to write and 
understand that a lot of individual field formatting followed by a .join().

--

___
Python tracker 

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

[issue3982] support .format for bytes

[Antoine Pitrou]

Antoine Pitrou added the comment:

> Whether b''.format() would have to lookup and call __format__ remains
> to be seen. From what I've read, maybe baking in knowledge of bytes,
> float, and int would be good enough. I suspect there might be some
> need for datetimes, but I could be wrong.

The __bytes__ method (and/or tp_buffer) may be a better discriminator than
__format__. It would also allow combining arbitrary buffer objects without
making tons of copies.
What it also means is that "format()" may not be the best method name for
this. It is less about formatting than about combining.

Also, it's not obvious what "formatting" a number as bytes should do.
Should it mimick the bytes constructor:

>>> bytes(5)
b'\x00\x00\x00\x00\x00'

Should it mimick the int to_bytes() method:

>>> (5).to_bytes(4, 'little')
b'\x05\x00\x00\x00'

Numbers currently don't have a __bytes__ method:

>>> (5).__bytes__()
Traceback (most recent call last):
  File "", line 1, in 
AttributeError: 'int' object has no attribute '__bytes__'

--

___
Python tracker 

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

[issue3982] support .format for bytes

[Eric V. Smith]

Eric V. Smith added the comment:

I retract the datetime comment. Given what we're trying to accomplish, I think 
we only need to support types that are supported by 2.7's %-formatting.

--

___
Python tracker 

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

[issue14208] No way to recover original argv with python -m

[Tim Golden]

Tim Golden added the comment:

My use case is the reloader or restarter. I've initially fallen foul of this 
when using the cherrypy reloader (which does an execv by building from 
sys.executable + sys.argv) but I also have web services running which I'd like 
to restart remotely by forcing them to execv themselves.

It's trivial to retrieve the original command line from the Windows API, 
shlex.split it and pass it along to execv so this is hardly a showstopper. But 
it would be useful to have something equivalent built-in.

--
nosy: +tim.golden

___
Python tracker 

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

[issue12411] cgi.parse_multipart is broken on 3.x

[Roundup Robot]

Roundup Robot added the comment:

New changeset a46a0dafcb7a by Senthil Kumaran in branch '3.2':
Issue #12411: Fix to cgi.parse_multipart to correctly use bytes boundaries and
http://hg.python.org/cpython/rev/a46a0dafcb7a

New changeset 59ea872d8b6b by Senthil Kumaran in branch '3.3':
merge from 3.2
http://hg.python.org/cpython/rev/59ea872d8b6b

New changeset 3d7000549eb1 by Senthil Kumaran in branch 'default':
merge from 3.3
http://hg.python.org/cpython/rev/3d7000549eb1

--
nosy: +python-dev

___
Python tracker 

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

[issue12411] cgi.parse_multipart is broken on 3.x

[Senthil Kumaran]

Senthil Kumaran added the comment:

I updated the patch addressing Ezio's comments in the review system and also 
condensed the tests. This fixes the parse_multipart's byte handling at "some" 
level. 

The docstring of parse_multipart say that, this should be deprecated in favor 
of FieldStorage completely. I will have to trace through the argument and see 
what should be done here and then I shall close this bug.

--
assignee:  -> orsenthil
resolution:  -> fixed

___
Python tracker 

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

[issue17017] email.utils.getaddresses fails for certain addresses

[R. David Murray]

R. David Murray added the comment:

It's sort-of a bug, and sort-of not.  getaddresses is expecting to parse an 
already unfolded header, but the pre-3.3 email package does not unfold headers 
automatically.  See issue 11050 for more information.

--
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> email.utils.getaddresses behavior contradicts RFC2822

___
Python tracker 

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

[issue16672] improve tracing performances when f_trace is NULL

[Xavier de Gaye]

Xavier de Gaye added the comment:

The patch applied to the default branch should be reverted.

The 2.7 _hotshot extension module follows the specifications of PyEval_SetTrace:

  """Set the tracing function to func. This is similar to PyEval_SetProfile(),
  except the tracing function does receive line-number events."""
  

The 2.7 patch breaks test_hotshot because PyTrace_LINE events are not sent
anymore when f_trace is NULL.

The first patch (already applied to the default branch), breaks also existing
applications that expect to receive line events when they don't care to
implement the following semantics defined by sys.settrace:

  """The trace function is invoked (with event set to 'call') whenever a new
 local scope is entered; it should return a reference to a local trace
 function to be used that scope, or None if the scope shouldn’t be
 traced."""

Those applications want to receive unconditionally line debug events.

Attached is a patch that reverts the patch on the default branch.

--
Added file: http://bugs.python.org/file28806/revert_f_trace_perfs.patch

___
Python tracker 

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

[issue16672] improve tracing performances when f_trace is NULL

[Jesús Cea Avión]

Jesús Cea Avión added the comment:

So, Xavier, are you saying that you are reverting the patch?.

Could be possible to provide a "good" patch, with a correct test of the 
situation you describe?

Or are you suggesting just revert this and close this bugentry for good?.

--
resolution: fixed -> 
status: closed -> open

___
Python tracker 

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

[issue16672] improve tracing performances when f_trace is NULL

[Roundup Robot]

Roundup Robot added the comment:

New changeset cd87afe18ff8 by Benjamin Peterson in branch 'default':
revert #16672 for incorrect semantics
http://hg.python.org/cpython/rev/cd87afe18ff8

--

___
Python tracker 

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

[issue16672] improve tracing performances when f_trace is NULL

[Xavier de Gaye]

Xavier de Gaye added the comment:

It is not possible to improve the performances of the trace function set with
sys.settrace without breaking backward compatibility for PyEval_SetTrace or
without introducing a new PyEval_xxx of some sort.

Yes, I suggest to revert this patch.

--

___
Python tracker 

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

[issue16672] improve tracing performances when f_trace is NULL

[Xavier de Gaye]

Xavier de Gaye added the comment:

status should be close, I guess.

--

___
Python tracker 

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

[issue17012] Differences between /usr/bin/which and shutil.which()

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Thank you, Ned, for information.

Here is a patch which remove the first difference (processing an empty path).

The second difference is not semantically significant and I'm not sure whether 
we need to get rid of it.

--
keywords: +patch
Added file: http://bugs.python.org/file28807/shutil_which_empty_path.patch

___
Python tracker 

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

[issue17012] Differences between /usr/bin/which and shutil.which()

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
stage:  -> patch review

___
Python tracker 

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

[issue5430] imaplib: must not replace LF or CR by CRLF in literals

[R. David Murray]

Changes by R. David Murray :


--
components: +email
nosy: +barry, r.david.murray

___
Python tracker 

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

[issue3461] smtplib does not fully support IPv6 in EHLO

[R. David Murray]

Changes by R. David Murray :


--
components: +email
nosy: +barry

___
Python tracker 

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

[issue16672] improve tracing performances when f_trace is NULL

[Benjamin Peterson]

Changes by Benjamin Peterson :


--
resolution:  -> rejected
status: open -> closed

___
Python tracker 

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

[issue17018] Inconsistent behaviour of methods waiting for child process

[Marcin Szewczyk]

New submission from Marcin Szewczyk:

I've done some experiments with:
1) multiprocessing.Process.join()
2) os.waitpid()
3) subprocess.Popen.wait()

These three methods behave completely different when interrupted with a signal 
which I find disturbing.

Reactions are:
1) exit with no exception or special return code
2) OSError exception
3) quiet retry (no exit)

The 1) case is very impractical.

Is there any movement towards standardization of those 3?

Now I know I can loop around Process.join() and check exitcode or is_alive, but 
it requires more code.

It has been pointed out that it changed between 2.6 and 2.7.

Associated bug: http://bugs.python.org/issue1731717

Relevant sources:
http://svn.python.org/view/python/branches/release26-maint/Lib/multiprocessing/forking.py?revision=84031&view=markup
http://hg.python.org/releasing/2.7.3/file/7bb96963d067/Lib/multiprocessing/forking.py
http://hg.python.org/cpython/rev/41aef062d529/

I think the behaviour of those three should be at least documented, especially 
if every one of them behaves differently and it changes between versions.

My environment is:
$ python --version
Python 2.7.3rc2

$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:Debian GNU/Linux 7.0 (wheezy)
Release:7.0
Codename:   wheezy

$ uname -a
Linux magazyn-ziarno 3.2.0-4-686-pae #1 SMP Debian 3.2.35-2 i686 GNU/Linux

Filing a bug as advised on python-dev mailing list 
().

--
messages: 180465
nosy: wodny
priority: normal
severity: normal
status: open
title: Inconsistent behaviour of methods waiting for child process
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

[issue17018] Inconsistent behaviour of methods waiting for child process

[Jakub Wilk]

Changes by Jakub Wilk :


--
nosy: +jwilk

___
Python tracker 

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

[issue3982] support .format for bytes

[Guido van Rossum]

Guido van Rossum added the comment:

Remember, the only reason to add this would be to enable writing code
that works in both 2.7 and 3.4. So it has to be called .format() and
it has to format numbers as decimal strings by default.

--

___
Python tracker 

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

[issue17018] Inconsistent behaviour of methods waiting for child process

[Richard Oudkerk]

Changes by Richard Oudkerk :


--
nosy: +sbt

___
Python tracker 

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

[issue14771] Occasional failure in test_ioctl

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Third argument of ioctl should be not "", but a bytes object with platform 
dependent length sizeof(pid_t).

Beside this, the code at the top of the module checks the same condition and 
skip the tests if it is wrong. Race condition happened -- the process has been 
put into the background between executing these two codes. What command line 
you run the test?

--
nosy: +serhiy.storchaka
status: pending -> open

___
Python tracker 

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

[issue3982] support .format for bytes

[Florent Xicluna]

Changes by Florent Xicluna :


--
nosy: +flox

___
Python tracker 

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

[issue14771] Occasional failure in test_ioctl

[Antoine Pitrou]

Antoine Pitrou added the comment:

> Beside this, the code at the top of the module checks the same
> condition and skip the tests if it is wrong. Race condition happened
> -- the process has been put into the background between executing
> these two codes. What command line you run the test?

It happens (or happened) quite often when using the -j option to regrtest.

--

___
Python tracker 

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

[issue17019] Invitation to connect on LinkedIn

[mtb]

New submission from mtb:

LinkedIn


I'd like to add you to my professional network on LinkedIn.

- Matthew

Matthew Burns
unemployed at n/a
Greater Los Angeles Area

Confirm that you know Matthew Burns:
https://www.linkedin.com/e/-3qcne3-hcapdpuw-2h/isd/10664060930/HGLNsmfN/?hs=false&tok=3M68u6D1DIClA1

--
You are receiving Invitation to Connect emails. Click to unsubscribe:
http://www.linkedin.com/e/-3qcne3-hcapdpuw-2h/z2oU7dKDzpt2G7xQz2FC2SclHmnUGzmsk0c/goo/report%40bugs%2Epython%2Eorg/20061/I3541514734_1/?hs=false&tok=1flNx1ai_IClA1

(c) 2012 LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, USA.

--
messages: 180469
nosy: zubah
priority: normal
severity: normal
status: open
title: Invitation to connect on LinkedIn

___
Python tracker 

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

[issue14771] Occasional failure in test_ioctl

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Do you use -r option?

--

___
Python tracker 

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

[issue17019] Invitation to connect on LinkedIn

[Christian Heimes]

Christian Heimes added the comment:

Please don't spam the bug tracker!

--
nosy: +christian.heimes
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

[issue14771] Occasional failure in test_ioctl

[Antoine Pitrou]

Antoine Pitrou added the comment:

> Serhiy Storchaka added the comment:
> 
> Do you use -r option?

No. Usually just -j

--

___
Python tracker 

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

[issue17016] _sre: avoid relying on pointer overflow

[Nickolai Zeldovich]

Nickolai Zeldovich added the comment:

Lines 2777 and 3111 do indeed look suspect, because gcc can compile (ptr + 
offset < ptr) into (offset < 0):

nickolai@sahara:/tmp$ cat x.c 
void bar();

void
foo(char* ptr, int offset)
{
  if (ptr + offset < ptr)
bar();
}
nickolai@sahara:/tmp$ gcc x.c -S -o - -O2
...
foo:
.LFB0:
.cfi_startproc
testl   %esi, %esi
js  .L4
rep
ret
.p2align 4,,10
.p2align 3
.L4:
xorl%eax, %eax
jmp bar
.cfi_endproc
...
nickolai@sahara:/tmp$ 

Lines 658, 678, 1000, 1084 are potentially problematic -- I don't know of 
current compilers that will do something unexpected, but it might be worth 
rewriting the code to avoid undefined behavior anyway.

--

___
Python tracker 

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

[issue4934] tp_del and tp_version_tag undocumented

[Antoine Pitrou]

Antoine Pitrou added the comment:

> tp_cache and tp_weaklist are also for internal use only, but are
> documented.

Ok, so I guess tp_version_tag and tp_del should also be documented as "for 
internal use only".

--

___
Python tracker 

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

[issue14771] Occasional failure in test_ioctl

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

What is ? Can you please expose several lines of regrtest output 
before and after this error? When "/1" appeared?

I suspect test_gdb:

$ ./python -m test.regrtest -j 2 test_gdb test_gdb

[1]+  Stopped ./python -m test.regrtest -j 2 test_gdb test_gdb

--

___
Python tracker 

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

[issue14771] Occasional failure in test_ioctl

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

$ ./python -m test.regrtest -j 2 test_gdb test_ioctl test_ioctl test_ioctl 
test_ioctl test_ioctl test_ioctl test_ioctl test_ioctl test_ioctl
[ 1/10] test_ioctl
[ 2/10] test_ioctl
[ 3/10] test_ioctl
[ 4/10] test_ioctl
[ 5/10] test_ioctl
[ 6/10] test_ioctl
[ 7/10] test_ioctl
[ 8/10] test_ioctl
test_ioctl skipped -- Neither the process group nor the session are attached to 
/dev/tty
[ 9/10] test_ioctl
test_ioctl skipped -- Neither the process group nor the session are attached to 
/dev/tty
[10/10] test_gdb
8 tests OK.
2 tests skipped:
test_ioctl test_ioctl

--

___
Python tracker 

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

[issue14771] Occasional failure in test_ioctl

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

$ ./python -m test.regrtest -j 4 test_gdb test_ioctl test_ioctl test_ioctl 
test_ioctl test_ioctl test_ioctl test_ioctl test_ioctl test_ioctl test_ioctl 
test_ioctl test_ioctl test_ioctl test_ioctl test_ioctl test_ioctl test_ioctl 
test_ioctl test_ioctl
[ 1/20] test_ioctl
[ 2/20] test_ioctl
[ 3/20] test_ioctl
[ 4/20] test_ioctl
[ 5/20] test_ioctl
[ 6/20] test_ioctl
[ 7/20] test_ioctl
[ 8/20] test_ioctl
[ 9/20] test_ioctl
[10/20] test_ioctl
[11/20] test_ioctl
[12/20] test_ioctl
[13/20] test_ioctl
[14/20] test_ioctl
[15/20] test_ioctl
[16/20] test_ioctl
[17/20] test_ioctl
[18/20] test_ioctl
test_ioctl skipped -- Neither the process group nor the session are attached to 
/dev/tty
[19/20] test_ioctl
[20/20/1] test_gdb
test test_gdb failed -- Traceback (most recent call last):
  File "/home/serhiy/py/cpython/Lib/test/test_gdb.py", line 716, in test_threads
cmds_after_breakpoint=['thread apply all py-bt'])
  File "/home/serhiy/py/cpython/Lib/test/test_gdb.py", line 170, in 
get_stack_trace
self.assertEqual(err, '')
AssertionError: 'Error occurred in Python command.\n' != ''
- Error occurred in Python command.
18 tests OK.
1 test failed:
test_gdb
1 test skipped:
test_ioctl

--

___
Python tracker 

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

[issue14771] Occasional failure in test_ioctl

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Bingo!

$ ./python -m test.regrtest -j 4 test_gdb test_ioctl test_ioctl test_ioctl 
test_ioctl test_ioctl test_ioctl test_ioctl test_ioctl test_ioctl test_ioctl 
test_ioctl test_ioctl test_ioctl test_ioctl test_ioctl test_ioctl test_ioctl 
test_ioctl test_ioctl
[ 1/20] test_ioctl
[ 2/20] test_ioctl
[ 3/20] test_ioctl
[ 4/20] test_ioctl
[ 5/20] test_ioctl
[ 6/20] test_ioctl
[ 7/20] test_ioctl
[ 8/20] test_ioctl
[ 9/20] test_ioctl
test_ioctl skipped -- Neither the process group nor the session are attached to 
/dev/tty
[10/20] test_ioctl
[11/20/1] test_ioctl
test test_ioctl failed -- Traceback (most recent call last):
  File "/home/serhiy/py/cpython/Lib/test/test_ioctl.py", line 66, in 
test_ioctl_mutate_2048
self._check_ioctl_mutate_len(2048)
  File "/home/serhiy/py/cpython/Lib/test/test_ioctl.py", line 54, in 
_check_ioctl_mutate_len
self.assertIn(rpgrp, ids)
AssertionError: 14270 not found in (14225, 4030)
[12/20/1] test_ioctl
test_ioctl skipped -- Neither the process group nor the session are attached to 
/dev/tty
[13/20/1] test_ioctl
[14/20/1] test_ioctl
[15/20/1] test_ioctl
[16/20/1] test_ioctl
[17/20/1] test_ioctl
test_ioctl skipped -- Neither the process group nor the session are attached to 
/dev/tty
[18/20/1] test_ioctl
[19/20/1] test_ioctl
[20/20/1] test_gdb
16 tests OK.
1 test failed:
test_ioctl
3 tests skipped:
test_ioctl test_ioctl test_ioctl

--

___
Python tracker 

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

[issue14771] Occasional failure in test_ioctl

[Antoine Pitrou]

Antoine Pitrou added the comment:

Nice catch, Serhiy. I wouldn't have suspected test_gdb.

--

___
Python tracker 

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

[issue14771] Occasional failure in test_ioctl when run parallel with test_gdb

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
stage:  -> needs patch
title: Occasional failure in test_ioctl -> Occasional failure in test_ioctl 
when run parallel with test_gdb
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

[issue17020] random.random() generating values >= 1.0

[Floris van Manen]

New submission from Floris van Manen:

I recently noticed that the standard random() function generates values >= 1.0

As processes are called from an event scheduler, each process has its own 
Random() instance.

self.random = random.Random(seed)
self.randomState = self.random.getstate()



keeping track of multiple objects:

self.random.setstate(self.randomState)
self.random.jumpahead(1)
self.randomState = self.random.getstate()


Also gammavariate() generates errors as it too makes use of the _random() call

A workaround is to check each response of random() for values >= 1.0

--
assignee: ronaldoussoren
components: Macintosh
messages: 180480
nosy: klankschap, ronaldoussoren
priority: normal
severity: normal
status: open
title: random.random() generating values >= 1.0
type: compile error
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

[issue14771] Occasional failure in test_ioctl when run parallel with test_gdb

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Perhaps we need a possibility to mark a test that it can't run in parallel. 
I suspect some multiprocess tests fail for same reason.

--

___
Python tracker 

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

[issue17020] random.random() generating values >= 1.0

[R. David Murray]

R. David Murray added the comment:

Can you post a small program that demonstrates the problem?  I'm certainly not 
seeing a problem just calling random.random() (and would be very surprised if I 
did).

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

[issue17020] random.random() generating values >= 1.0

[Peter Otten]

Peter Otten added the comment:

This could be a duplicate of issue14591.

--
nosy: +peter.otten

___
Python tracker 

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

[issue17016] _sre: avoid relying on pointer overflow

[Matthew Barnett]

Matthew Barnett added the comment:

You're checking "int offset", but what happens with "unsigned int offset"?

--

___
Python tracker 

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

[issue17016] _sre: avoid relying on pointer overflow

[Nickolai Zeldovich]

Nickolai Zeldovich added the comment:

For an unsigned int offset, see my original bug report: gcc eliminates the 
check altogether, since offset >= 0 by definition.

--

___
Python tracker 

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

[issue17020] random.random() generating values >= 1.0

[R. David Murray]

R. David Murray added the comment:

That indeed looks likely.  Fortunately there will be a new release of 2.7 
including that fix soon.

Floris, do you have any way to test against 2.7 tip?

--

___
Python tracker 

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

[issue17020] random.random() generating values >= 1.0

[Floris van Manen]

Floris van Manen added the comment:

On 23 Jan 2013, at 19:18, R. David Murray wrote:

> 
> R. David Murray added the comment:
> 
> That indeed looks likely.  Fortunately there will be a new release of 2.7 
> including that fix soon.
> 
> Floris, do you have any way to test against 2.7 tip?

using 2.7.3 as well as pypy (based on 2.7.3) via macport.
pypy version suffers from the same issue.

i'm not (yet) familiar how to get the tip from 2.7.3
hint?

.F

--

___
Python tracker 

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

[issue17020] random.random() generating values >= 1.0

[Floris van Manen]

Floris van Manen added the comment:

indeed, looks like the same.
.F

On 23 Jan 2013, at 19:09, Peter Otten wrote:

> 
> Peter Otten added the comment:
> 
> This could be a duplicate of issue14591.
> 
> --
> nosy: +peter.otten
> 
> ___
> Python tracker 
> 
> ___

--

___
Python tracker 

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

[issue3982] support .format for bytes

[Glyph Lefkowitz]

Glyph Lefkowitz added the comment:

On Jan 22, 2013, at 11:27 PM, Antoine Pitrou  wrote:

> Antoine Pitrou added the comment:
> 
> The "ASCII superset commands" part is clearly separated from the "binary
> data" part. Your own LineReceiver is able to switch between "raw mode"
> and "line mode"; one is text and the other is binary.

This is incorrect.  "Lines" are just CRLF (0x0D0A) separated chunks of data.  
For example, SMTP is always in line-mode, but messages ("data lines") may 
contain arbitrary 8-bit data.

> This is a non-sequitur. You can fully well (...)
> So, yes, it is reasonably possible, and it even makes sense.

I concede it is possible to implement what you're talking about, but it still 
requires encoding things which are potentially 8-bit data.  Yes, there are many 
corners of protocols where said data looks like text, but it is an optical 
illusion.

>> even disregarding compatibility with a 2.x codebase, b''.join() and
>> b'' + b'' and (''.format()).encode('charmap') are all slower _and_
>> more awkward than simply b''.format() or b''%.
> 
> How can existing constructions be slower than non-existing constructions
> that don't have performance numbers at all?

Sorry, "in 2.x" :).

> Besides, if b''.join() is too slow, it deserves to be improved. Or
> perhaps you should try bytearray instead, or even io.BytesIO.

As others have noted, b''.join is *not* slower than b''.format for simply 
assembling strings; b''.join is indeed faster at that and I didn't mean to say 
it wasn't.  The performance improvement shows up when you are assembling 
complex messages that contain a smattering of ints, floats, and other chunks of 
bytes; mostly in that you can avoid a bunch of python code execution and python 
function calls when formatting those values.  The trouble with cooking up an 
example of this is that it starts to involve a bunch of additional code 
complexity and it requires careful framing to make sure the other complexity 
isn't what's getting in the way.  I will try to come up with one, maybe doing 
so will prove even this contention wrong.

But, the main issue here is expressiveness, not performance.

--

___
Python tracker 

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

[issue3982] support .format for bytes

[Glyph Lefkowitz]

Glyph Lefkowitz added the comment:

On Jan 22, 2013, at 11:31 PM, Martin v. Löwis  wrote:

> I admit that it is puzzling that string interpolation is apparently the 
> fastest way to assemble byte strings. It involves parsing the format string, 
> so it ought to be slower than anything that merely concatenates (such as 
> cStringIO). (I do understand why + is inefficient, as it creates temporary 
> objects)

You're correct about this; see my previous comment.

--

___
Python tracker 

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

[issue3982] support .format for bytes

[Glyph Lefkowitz]

Glyph Lefkowitz added the comment:

On Jan 23, 2013, at 1:58 AM, Antoine Pitrou  wrote:

> Numbers currently don't have a __bytes__ method:
> 
 (5).__bytes__()
> Traceback (most recent call last):
>  File "", line 1, in 
> AttributeError: 'int' object has no attribute '__bytes__'

They do have some rather odd behavior when passed to the builtin though:

>>> bytes(10)
b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'

It would be much more convenient for me if bytes(int) returned the 
ASCIIfication of that int; but honestly, even an error would be better than 
this behavior.  (If I wanted this behavior - which I never have - I'd rather it 
be a classmethod, invoked like "bytes.zeroes(n)".)

--

___
Python tracker 

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

[issue3982] support .format for bytes

[Antoine Pitrou]

Antoine Pitrou added the comment:

> They do have some rather odd behavior when passed to the builtin
> though:
> 
> >>> bytes(10)
> b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'
> 
> It would be much more convenient for me if bytes(int) returned the
> ASCIIfication of that int; but honestly, even an error would be better
> than this behavior.  (If I wanted this behavior - which I never have -
> I'd rather it be a classmethod, invoked like "bytes.zeroes(n)".)

I would agree with you, but it's probably too late to change...

--

___
Python tracker 

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

[issue3982] support .format for bytes

[Glyph Lefkowitz]

Glyph Lefkowitz added the comment:

On Jan 23, 2013, at 11:02 AM, Antoine Pitrou  wrote:

> I would agree with you, but it's probably too late to change...

Understandable, and, in any case, out of scope for this ticket.

--

___
Python tracker 

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

[issue14771] Occasional failure in test_ioctl when run parallel with test_gdb

[Antoine Pitrou]

Antoine Pitrou added the comment:

> Perhaps we need a possibility to mark a test that it can't run in parallel. 
> I suspect some multiprocess tests fail for same reason.

Well, first I would like to know what the underlying problem is.
-j doesn't use multiprocessing, it spawns standalone processes using the 
subprocess module.

--

___
Python tracker 

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

[issue17020] random.random() generating values >= 1.0

[R. David Murray]

R. David Murray added the comment:

hg pull http://hg.python.org/cpython
hg up 2.7

There are also git and bzr mirrors, but I don't know their urls or how up to 
date they are.

We could also just close this as a dup if you are pretty sure its the same 
problem (which it certainly sounds like it is) and you could post to that issue 
if your problem isn't solved by the RC for 2.7.4.

--

___
Python tracker 

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

[issue14771] Occasional failure in test_ioctl when run parallel with test_gdb

[Antoine Pitrou]

Antoine Pitrou added the comment:

Ah, I see, that's because of the "Skip if another process is in foreground" 
thing?

--

___
Python tracker 

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

[issue14771] Occasional failure in test_ioctl when run parallel with test_gdb

[Antoine Pitrou]

Antoine Pitrou added the comment:

Given what _check_ioctl_mutate_len() seems to be designed to check, perhaps we 
should relax:

self.assertIn(rpgrp, ids)

into:

self.assertNotEqual(rpgrp, fill)

or perhaps simply:

self.assertGreater(rpgrp, 0)

--

___
Python tracker 

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

[issue14771] Occasional failure in test_ioctl when run parallel with test_gdb

[Antoine Pitrou]

Antoine Pitrou added the comment:

Ah, and the test_ioctl() method needs to be fixed too.

--

___
Python tracker 

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

[issue13169] Regular expressions with 0 to 65536 repetitions raises OverflowError

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Now RuntimeError is raised in this case.

Here is a patch, which:

1) Increases the limit of repeat numbers to 4G (now SRE_CODE at least 32-bit).
2) Raises re.error exception if this limit is exceeded.
3) Fixes some minor related things.

--
components: +Extension Modules, Regular Expressions
keywords: +patch
nosy: +serhiy.storchaka
stage:  -> patch review
versions: +Python 3.3, Python 3.4
Added file: http://bugs.python.org/file28808/re_maxrepeat.patch

___
Python tracker 

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

[issue3982] support .format for bytes

[Eric V. Smith]

Eric V. Smith added the comment:

So it sounds like the use case is (as Glyph said in msg180432):

- Provide a transition for users of 2.7's of str %-formatting into a style 
that's compatible with both str in 2.7 and bytes in 3.4.

In that case the only options I see are to implement __mod__ or .format for 
bytes in 3.4. I'd of course prefer to use .format, although __mod__ would 
probably make the transition easier (no need to move to .format first). It 
would probably also make the implementation easier, since there's so much less 
code in str.__mod__. But let's assume we're using .format [1].

Given the restricted use case, and assuming we using .format, the 
implementation would not need to support:
- Types other than bytes, int, float.
- Subclasses of these types with custom formatting.
- !s, !r, or !a (none of the ! conversions). [2]

But it would support all of the specifiers for formatting strs (except now for 
bytes), floats, and ints.

I haven't looked through the str.format or {str,int,float}.__format__ code 
since the PEP 393 work, so I'm not really sure if we could stringlib-ify the 
code again, or if it would just be easier to reimplement it as separate 
bytes-only code.

[1] It's open for debate whether .format or .__mod__ is preferable.
[2] Since %-formatting supports %r and %s, this point is arguable.

--

___
Python tracker 

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

[issue8478] tokenize.untokenize first token missing failure case

[Thomas Kluyver]

Changes by Thomas Kluyver :


--
nosy: +takluyver

___
Python tracker 

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

[issue16701] Docs missing the behavior of += (in-place add) for lists.

[benrg]

benrg added the comment:

This is bizarre:

Python 3.3.0 (v3.3.0:bd8afb90ebf2, Sep 29 2012, 10:55:48) [MSC v.1600 32 bit 
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> x = y = [1, 2]
>>> x += [3]
>>> y
[1, 2, 3]
>>> x = y = {1, 2}
>>> x -= {2}
>>> y
{1}
>>>

Since when has this been standard behavior? The documentation says:

"An augmented assignment expression like x += 1 can be rewritten as x = x + 1 
to achieve a similar, but not exactly equal effect. In the augmented version, x 
is only evaluated once. Also, when possible, the actual operation is performed 
in-place, meaning that rather than creating a new object and assigning that to 
the target, the old object is modified instead."

What is "when possible" supposed to mean here? I always thought it meant "when 
there are known to be no other references to the object". If op= is always 
destructive on lists and sets, then "where possible" needs to be changed to 
"always" and a prominent warning added, like "WARNING: X OP= EXPR DOES NOT 
BEHAVE EVEN REMOTELY LIKE X = X OP EXPR IN PYTHON WHEN X IS A MUTABLE OBJECT, 
IN STARK CONTRAST TO EVERY OTHER LANGUAGE WITH A SIMILAR SYNTAX."

--
nosy: +benrg

___
Python tracker 

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

[issue17021] Invitation to connect on LinkedIn

[Hank Christian]

New submission from Hank Christian:

LinkedIn


Python,

I'd like to add you to my professional network on LinkedIn.

- Henry

Henry Christian
ADJUNCT PROFESSOR at Central Texas College
Greater Los Angeles Area

Confirm that you know Henry Christian:
https://www.linkedin.com/e/-3qcne3-hcbawhei-t/isd/10674146693/f8KKDSuG/?hs=false&tok=1CeofNO2B6D5A1

--
You are receiving Invitation to Connect emails. Click to unsubscribe:
http://www.linkedin.com/e/-3qcne3-hcbawhei-t/z2oU7dKDzpt2G7xQz2FC2SclHmnUGzmsk0c/goo/report%40bugs%2Epython%2Eorg/20061/I3544543039_1/?hs=false&tok=2VYf22chR6D5A1

(c) 2012 LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, USA.

--
messages: 180502
nosy: hankchristian
priority: normal
severity: normal
status: open
title: Invitation to connect on LinkedIn

___
Python tracker 

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

[issue17021] Invitation to connect on LinkedIn

[Ezio Melotti]

Changes by Ezio Melotti :


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

[issue17021] Invitation to connect on LinkedIn

[Ezio Melotti]

Changes by Ezio Melotti :


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

___
Python tracker 

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

[issue15919] hg.python.org: log page entries don't always link to revision

[Ezio Melotti]

Ezio Melotti added the comment:

This should now be fixed 
(http://mail.python.org/pipermail/python-dev/2013-January/123680.html).

> This seems to happen whenever the revision description begins with
> text that results in a link to something else (e.g. an issue number).

To elaborate a bit on what I wrote in the email, I'll provide a few examples.  
Here  is a link to the revision page,  to the bug 
tracker, and the 4 steps shows the original message, the resulting link in the 
"shortlog" page, the link added by interhg and how the browser interprets the 
invalid HTML:
1) issue at the beginning:
#12345: fix foo  <- commit message
#12345: fix foo  <- normal link
#12345 fix foo  <- interhg (invalid html)
#12345 fix foo <- resulting html

2) issue in the middle:
Issue #12345: fix foo  <- commit message
Issue #12345: fix foo  <- normal link
Issue #12345 fix foo  <- interhg (invalid html)
Issue #12345 fix foo  <- resulting html

In case 1) the revision link ends up being empty, and there's no way to get to 
the revision page.  In case 2) everything before the issue number links to the 
revision page, the #12345 links to the bug tracker, and everything after that 
is not a link.

> In contrast, the "graph" page seems always to link to the revision

This seems to be because that page is not affected by the interhg extension.

> the UI doesn't make a distinction between the portion of the 
> description that links to the revision and the portion that links
> to the something else.

That's because the link to the revision page ends right where the one for the 
issue begins.

> For example, with description text "Fix for fcc629208842",

FWIW all that I said about issues is true for changeset ids.  However the fix I 
added for issue has not been applied for csids (they are not really common in 
commit messages, and usually they are not at the beginning).

> It might be better if the revision link was separate from the
> description text.

I did the opposite -- I left the revision link there and created a separated 
link to the issue at the end of the description. 

I think this issue can be closed now, even if there still some room for 
improvement.

--
assignee:  -> ezio.melotti
resolution:  -> fixed
stage:  -> 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

[issue16701] Docs missing the behavior of += (in-place add) for lists.

[Ezio Melotti]

Ezio Melotti added the comment:

> What is "when possible" supposed to mean here?

Generally it means "when the object is mutable":
>>> l = [1,2,3]
>>> id(l)
3074713484
>>> l += [4]
>>> id(l)
3074713484
>>> t = (1,2,3)
>>> id(t)
3074704004
>>> t += (4,)
>>> id(t)
3075304860

Tuples are not mutable, so it's not possible to modify them in place, and a new 
tuple needs to be created.
Note that while most mutable objects in the stdlib that support += do indeed 
modify the object rather than creating a new one, I don't think this is 
strictly required.
IOW that paragraph is already warning you that (with mutable objects) the 
object might be reused, depending on the implementation.  Maybe this should be 
clarified?
(IIRC in CPython it could be possible that in some situations an immutable 
object still has the same id after an augmented assignment, but, if it really 
happens, it is an implementation detail and shouldn't affect semantics.)

--

___
Python tracker 

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

[issue13169] Regular expressions with 0 to 65536 repetitions raises OverflowError

[Matthew Barnett]

Matthew Barnett added the comment:

IMHO, I don't think that MAXREPEAT should be defined in sre_constants.py _and_ 
SRE_MAXREPEAT defined in sre_constants.h. (In the latter case, why is it in 
decimal?)

I think that it should be defined in one place, namely sre_constants.h, perhaps 
as:

#define SRE_MAXREPEAT ~(SRE_CODE)0

and then imported into sre_constants.py.

That'll reduce the chance of an inadvertent mismatch, and it's the C code 
that's imposing the limit to the number of repeats, not the Python code.

--

___
Python tracker 

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

[issue15919] hg.python.org: log page entries don't always link to revision

[Chris Jerdonek]

Chris Jerdonek added the comment:

>> It might be better if the revision link was separate from the
>> description text.
> I did the opposite -- I left the revision link there and created a separated 
> link to the issue at the end of the description. 

Some downsides of the selected approach are that it doesn't work for 
descriptions referencing more than one issue and/or containing a changeset 
reference.  It also adds clutter by repeating the issue number.

I may create a new issue for improving this.

--

___
Python tracker 

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

[issue16701] Docs missing the behavior of += (in-place add) for lists.

[R. David Murray]

R. David Murray added the comment:

If you really want to freak out, try this:

>>> x = ([],)
>>> x[0] += [1]
Traceback (most recent call last):
  File "", line 1, in 
TypeError: 'tuple' object does not support item assignment
>>> x
([1],)

but to answer your question, it has *always* worked that way, from the time 
augmented assignment was introduced (see, eg, issue 1306777, which was reported 
against python 2.4).  

Remember, Python names refer to pointers to objects, they are not variables in 
the sense that other languages have variables.

Guido resisted augmented assignment for a long time.  These confusions speak to 
why.

As far as I know Ezio is correct, "when possible" means "when the target is 
mutable".  The documentation should probably be clarified on that point.  I'm 
not sure it is practical to let whether or not the target is mutated be an 
implementation detail. IMO the behavior must be clearly defined for each type 
that is built in to Python.

--

___
Python tracker 

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

[issue16701] Docs missing the behavior of += (in-place add) for lists.

[Ezio Melotti]

Ezio Melotti added the comment:

To clarify, with "depends on the implementation" I meant the way a particular 
class is implemented (i.e. a class might decide to return a new object even if 
it's mutable).
The behavior of built-in types is well defined and should be the same across 
all the Python implementations.
Regarding the comment about immutable types, it's something specific to CPython 
(I don't remember the specific details though, so I might be wrong), and 
somewhat similar to:
>>> 'a'*20 is 'a'*20
True
>>> 'a'*25 is 'a'*25
False
This shouldn't be a problem though, so if you e.g. do "x = y = immutableobj;  y 
+= 1", 'x' should never be affected.

--

___
Python tracker 

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

[issue15919] hg.python.org: log page entries don't always link to revision

[Ezio Melotti]

Ezio Melotti added the comment:

True.

The fix is far from being ideal, but it's a good compromise given the 
limitations of interhg IMHO.

An RFE for interhg should be created, to allow to specify the pages affected by 
each regex and/or use different regexs on different pages.

--

___
Python tracker 

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

[issue16701] Docs missing the behavior of += (in-place add) for lists.

[benrg]

benrg added the comment:

> As far as I know Ezio is correct, "when possible" means "when the target is 
> mutable".  The documentation should probably be clarified on that point.

Yes, it needs to be made very, very clear in the documentation. As I said, I'm 
not aware of any other language in which var op= expr does not mean the same 
thing as var = var op expr. I'm actually amazed that neither of you recognize 
the weirdness of this behavior (and even more amazed that GvR apparently 
didn't). I'm an experienced professional programmer, and I dutifully read the 
official documentation cover to cover when I started programming in Python, and 
I interpreted this paragraph wrongly, because I interpreted it in the only way 
that made sense given the meaning of these operators in every other language 
that has them. Python is designed to be unsurprising; constructs generally mean 
what it looks like they mean. You need to explain this unique feature of Python 
in terms so clear that it can't possibly be mistaken for the behavior of all of 
the other languages.

> Remember, Python names refer to pointers to objects, they are not variables 
> in the sense that other languages have variables.

That has nothing to do with this. Yes, in Python (and Java and Javascript and 
many other languages) all objects live on the heap, local variables are not 
first-class objects, and var = expr is a special form. That doesn't change the 
fact that in all of those other languages, var += expr means var = var + expr. 
In C++ local variables are first-class objects and var += expr means 
var.operator+=(expr) or operator+=(var, expr), and this normally modifies the 
thing on the left in a way that's visible through references. But in C++, var = 
var + expr also modifies the thing on the left, in the same way.

In Python and Java and Javascript and ..., var = value never visibly mutates 
any heap object, and neither does var = var + value (in any library that 
defines a sane + operator), and therefore neither should var += value (again, 
in any sanely designed library). And it doesn't. Except in Python.

--

___
Python tracker 

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

[issue16701] Docs missing the behavior of += (in-place add) for lists.

[Ezio Melotti]

Ezio Melotti added the comment:

> Python is designed to be unsurprising; constructs generally mean
> what it looks like they mean.

AFAIK in C "x += 1" is equivalent to "x++", and both are semantically more 
about incrementing (mutating) the value of x than about creating a new value 
that gets assigned to x.
Likewise it seems to me more natural to interpret "x += y" as "add the value of 
y to the object x" than "add x and y together and save the result in x".
Clearly if you are used to other languages with different semantics you might 
expect a different behavior, but you could say the same about the fact that 
int/int gives float on Python 3: it's surprising if you are used to other 
languages like C, but otherwise it's more natural.

> I interpreted this paragraph wrongly, because I interpreted it in the
> only way that made sense given the meaning of these operators in 
> every other language that has them.

It seems to me that the documentation doesn't leave much room for 
interpretation regarding the fact that the object is mutated in place; the only 
problem is that it doesn't specify clearly what are the objects that do this.

--

___
Python tracker 

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

[issue12782] Multiple context expressions do not support parentheses for continuation across lines

[Atsuo Ishimoto]

Atsuo Ishimoto added the comment:

In Python 3.3, we have contextlib.ExitStack() for multiple contexts. 
So, perhaps we can close this issue?

--

___
Python tracker 

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

[issue16803] Make test_importlib run tests under both _frozen_importlib and importlib._bootstrap

[Eric Snow]

Changes by Eric Snow :


--
nosy: +eric.snow

___
Python tracker 

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

[issue1159051] Handle corrupted gzip files with unexpected EOF

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Actually previous patch doesn't fix original problem, it only ensure that 
GzipFile consistent with BZ2File and LZMAFile.

To fix original problem we need other patch, and this patch looks as new 
feature for 3.4. Here is a sample patch for LZMAFile. BZ2File patch will be 
similar, and GzipFile patch will be more different and complex.

Now error doesn't raised immediately when read the file unexpectedly ended if 
some data can be read. Instead maximal possible part of read data returned and 
exception raising deferred to next read (see tests).

Perhaps we need a new flag for constructor or for read() which enables a new 
behavior (what will be a good name for this?). Or we can use a special value 
for size argument which means "read to the end as much as possible" (we can 
differentiate the behavior for size<0 and size=None). Unconditional enabling a 
new behavior for size >=0 is safe.

--
type: behavior -> enhancement
versions:  -Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file28809/lzma_deferred_error.patch

___
Python tracker 

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

[issue12782] Multiple context expressions do not support parentheses for continuation across lines

[Ezio Melotti]

Ezio Melotti added the comment:

If this can't be fixed I think it should be at least documented in the FAQs.

--

___
Python tracker 

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