[issue14868] Allow log calls to return True for code optimization.

[Lluís]

New submission from Lluís :

One of the problems with the logging library is that it can affect code 
performance when logging calls are over-utilized.

One possible solution would be to allow the compiler to remove logging calls 
when code is optimized with "python -O" by wrapping log calls with an assert:

   assert logging.debug("This is a test.")

Note that now debug(), info(), etc in the logging module always return "None" 
and this is not possible. An enhancement would be to make all logging calls to 
return True. In normal conditions messages would be logged without raising any 
error, but in optimized code they would never be called.

It is really easy to implement and I would be pleased to provide a patch for 
this, but I want to receive feedback from python core developers.

Thanks…

--
components: Library (Lib)
messages: 161251
nosy: Lluís
priority: normal
severity: normal
status: open
title: Allow log calls to return True for code optimization.
type: enhancement
versions: Python 3.4

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

[issue14868] Allow log calls to return True for code optimization.

[Lluís]

Lluís  added the comment:

storchaka, you're right, but since non of the debug(), info() etc. functions 
have a return value, it would cause no trouble and would be neater to add a 
"return True". I'm not sure, but probably also more efficient.

--

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

[issue14868] Allow log calls to return True for code optimization.

[Lluís]

Lluís  added the comment:

David, the problem is that if you have the logging inside a loop, the 
interpreter will have to evaluate the condition every time. With an assert you 
guarantee that *no code* is executed.

I know that we can find thousands of ways to do that, even writing a dynamic 
proxy for the Logger, and wrap the debug(), error() calls and return True, etc.

My is not telling developers to write "assert logger.debug('aa')" every time 
that they want to log something, but instead giving them the option to do that 
and be sure that *no code* is executed. Specially, because the return value of 
log functions is not used at all.

Thanks for the responses.

--

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

[issue14868] Allow log calls to return True for code optimization.

[Lluís]

Lluís  added the comment:

Thanks for the explanation, I didn't know of the exact behavior of __debug__.

I close ticket.

--
resolution:  -> works for me
status: open -> closed

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

[issue19686] possible unnecessary memoryview copies?

[Lluís]

New submission from Lluís:

The following code works without raising any AssertionError
 >>> n = "some small integer value"
 >>> m = "some larger integer value"
 >>> assert n>> data = bytearray(n)
 >>> mem = memoryview(data)
 >>> assert mem==mem[:]
 >>> assert mem==mem[0:]
 >>> assert mem==mem[:m]

However, the different slices have different IDs, failing on the following 
asserts:
 >>> assert id(mem)==id(mem[:])
 >>> assert id(mem)==id(mem[0:])
 >>> assert id(mem)==id(mem[:m])

Is the interpreter copying unnecessary data in these type of slices?

--
components: Library (Lib)
messages: 203700
nosy: Lluís
priority: normal
severity: normal
status: open
title: possible unnecessary memoryview copies?
type: enhancement

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

[issue28571] llist and scipy.stats conflicts, python segfault

[Lluís]

New submission from Lluís:

I'm running this small script that produces a segfault:

https://gist.github.com/anonymous/d24748d5b6de88b31f18965932744211

My python version is Python 3.5.2 (default, Jun 28 2016, 08:46:01) [GCC 6.1.1 
20160602] on linux. And running scipy version 0.18.1.

Can someone confirm if this segfaults with other systems ?

--
components: Interpreter Core
messages: 279828
nosy: Lluís
priority: normal
severity: normal
status: open
title: llist and scipy.stats conflicts, python segfault
type: crash
versions: Python 3.5

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

[issue28571] llist and scipy.stats conflicts, python segfault

[Lluís]

Lluís added the comment:

Confirmed with 2.7 as well.

--
versions: +Python 2.7

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