[issue39496] Inelegant loops in Modules/_sqlite/cursor.c

[Berker Peksag]

Berker Peksag  added the comment:


New changeset 78c7183f470b60a39ac2dd0ad1a94d49d1e0b062 by Alex Henrie in branch 
'master':
bpo-39496: Remove redundant checks from _sqlite/cursor.c (GH-18270)
https://github.com/python/cpython/commit/78c7183f470b60a39ac2dd0ad1a94d49d1e0b062


--
nosy: +berker.peksag

___
Python tracker 

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

[issue39496] Inelegant loops in Modules/_sqlite/cursor.c

[Berker Peksag]

Change by Berker Peksag :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

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

[issue39496] Inelegant loops in Modules/_sqlite/cursor.c

[Alex Henrie]

Alex Henrie  added the comment:

Sorry about that, I didn't notice that GCC's -Wall option emits a warning about 
this. I just added the extra sets of parentheses.

--

___
Python tracker 

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

[issue39496] Inelegant loops in Modules/_sqlite/cursor.c

[Vedran Čačić]

Vedran Čačić  added the comment:

It seems you haven't read carefully what I've written. This way some compilers 
might emit warnings. Please read 
https://stackoverflow.com/questions/5476759/compiler-warning-suggest-parentheses-around-assignment-used-as-truth-value

--

___
Python tracker 

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

[issue39496] Inelegant loops in Modules/_sqlite/cursor.c

[Alex Henrie]

Alex Henrie  added the comment:

You're right, that's even better. I forgot that the equals operator also 
returns the variable's new value. I just updated my pull request :-)

--

___
Python tracker 

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

[issue39496] Inelegant loops in Modules/_sqlite/cursor.c

[Vedran Čačić]

Vedran Čačić  added the comment:

You mean, something like

while ((row = pysqlite_cursor_iternext(self))) {
PyList_Append(list, row);
Py_DECREF(row);
}

? It's interesting that now we have walrus in Python, we see the opportunities 
for it in other languages. (In C, it's spelled (=).:)

--
nosy: +veky

___
Python tracker 

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

[issue39496] Inelegant loops in Modules/_sqlite/cursor.c

[Alex Henrie]

Change by Alex Henrie :


--
keywords: +patch
pull_requests: +17645
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/18270

___
Python tracker 

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

[issue39496] Inelegant loops in Modules/_sqlite/cursor.c

[Alex Henrie]

New submission from Alex Henrie :

pysqlite_cursor_fetchall currently has the following bit of code:

/* just make sure we enter the loop */
row = (PyObject*)Py_None;

while (row) {
row = pysqlite_cursor_iternext(self);
if (row) {
PyList_Append(list, row);
Py_DECREF(row);
}
}

This can and should be rewritten as a for loop to avoid the unnecessary 
initialization to Py_None and the redundant if statement inside the loop.

pysqlite_cursor_fetchmany has the same problem.

--
components: Library (Lib)
messages: 361006
nosy: alex.henrie
priority: normal
severity: normal
status: open
title: Inelegant loops in Modules/_sqlite/cursor.c
type: performance
versions: Python 3.9

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

Re: Inelegant

[Greg Ewing]

Bengt Richter wrote:
I never liked any of the solutions that demand bracketing the string with 
expression brackets,
but I just had an idea ;-)
Or for an even more twisted idea:
  from textwrap import dedent
  class _Dedent(type):
def __new__(cls, name, bases, dict):
  if name  == *: # for bootstrapping
return type.__new__(cls, name, bases, dict)
  return dedent(dict['__doc__'])
  DedentedString = _Dedent(*, (), {})
  #
  #   Usage example
  #
  class foo(DedentedString):

This is a dedented (or perhaps demented?) string.
It spans multiple lines.

  print type(foo)
  print foo
The output is:
  type 'str'
  This is a dedented (or perhaps demented?) string.
  It spans multiple lines.
--
Greg Ewing, Computer Science Dept,
University of Canterbury,   
Christchurch, New Zealand
http://www.cosc.canterbury.ac.nz/~greg
--
http://mail.python.org/mailman/listinfo/python-list

Inelegant

[Dan]

I've just begun playing with Python, and so far I like what I see.
It's a very elegant language.  But I've found something that's, well,
a bit ugly.  Maybe someone can point out to me where I'm wrong.

If you use triple quotes to define a string, then the newlines are
implicitly included.  This is a very nice feature.  But if you're
inside a function or statement, then you'll want the string to be
positioned along that indentation.  And the consequences of this is
that the string will include those indentations.

For example:

def SomeFunction()
   if SomeCondition:
  MyString = 
  
  The quick brown fox
  
  print MyString

The output will be:

  The quick brown fox

But what you really want is:

The quick brown fox

The way around it is to write the function thus:

def SomeFunction()
   if SomeCondition:
  MyString = 

The quick brown fox

  print MyString

But that's just ugly.  It seems to me that the string should be
interpreted with the edge along the indentation line, not from the
start of the line.  But that would probably create other problems.

Dan
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Inelegant

[Terry Hancock]

On Thursday 14 April 2005 02:03 am, Dan wrote:
 If you use triple quotes to define a string, then the newlines are
 implicitly included.  This is a very nice feature.  But if you're
 inside a function or statement, then you'll want the string to be
 positioned along that indentation.  And the consequences of this is
 that the string will include those indentations.
  [...]
 But that's just ugly. 

Yeah, it's definitely a wart.  So much so that recent Python
distributions include a function to fix it:

 from textwrap import dedent
 string_block = dedent(
...   This string will have the leading
...   spaces removed so that it doesn't
...   have to break up the indenting.
...   )
 string_block
\nThis string will have the leading\nspaces removed so that it doesn't\nhave 
to break up the indenting.\n
 print string_block
 
This string will have the leading
spaces removed so that it doesn't
have to break up the indenting.
 



--
Terry Hancock ( hancock at anansispaceworks.com )
Anansi Spaceworks  http://www.anansispaceworks.com

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Inelegant

[Bengt Richter]

On Thu, 14 Apr 2005 02:43:40 -0500, Terry Hancock [EMAIL PROTECTED] wrote:

On Thursday 14 April 2005 02:03 am, Dan wrote:
 If you use triple quotes to define a string, then the newlines are
 implicitly included.  This is a very nice feature.  But if you're
 inside a function or statement, then you'll want the string to be
 positioned along that indentation.  And the consequences of this is
 that the string will include those indentations.
  [...]
 But that's just ugly. 

Yeah, it's definitely a wart.  So much so that recent Python
distributions include a function to fix it:

 from textwrap import dedent
 string_block = dedent(
...   This string will have the leading
...   spaces removed so that it doesn't
...   have to break up the indenting.
...   )
 string_block
\nThis string will have the leading\nspaces removed so that it doesn't\nhave 
to break up the indenting.\n
 print string_block
 
This string will have the leading
spaces removed so that it doesn't
have to break up the indenting.
 

I never liked any of the solutions that demand bracketing the string with 
expression brackets,
but I just had an idea ;-)

  class Dedent(object):
 ... def __init__(self, **kw): self.kw = kw
 ... def __add__(self, s):
 ... lines = s.splitlines()[1:]
 ... margin = self.kw.get('margin', 0)*' '
 ... mnow = min(len(L)-len(L.lstrip()) for L in lines)
 ... return '\n'.join([line[mnow:] and margin+line[mnow:] or '' for 
line in lines])
 ...
 ...

Normally you wouldn't pass **kw in like this,
you'd just write
 mystring = Dedent()+\

or

 mystring = Dedent(margin=3)+\

but  I wanted to control the print. Note the the first line, unless you escape 
it (ugly there)
is zero length and therefore has zero margin, which subverts the other 
shifting, so I just drop that line.
You have to live with the backslash after the + as payment for preferring not 
to have parentheses ;-)

  def foo(**kw):
 ... mystring = Dedent(**kw)+\
 ... 
 ... This makes
 ...for a cleaner isolation
 ... of the string IMO.
 ... 
 ... return mystring
 ...
  print '\n%s'%foo()
 
 This makes
for a cleaner isolation
 of the string IMO.
 
  print '\n%s'%foo(margin=3)
 
This makes
   for a cleaner isolation
of the string IMO.
 

Regards,
Bengt Richter
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Inelegant

[gry]

I sometimes use the implicit literal string concatenation:

def SomeFunction():
   if SomeCondition:
  MyString = 'The quick brown fox ' \
 'jumped over the ' \
 'lazy dog'
  print MyString

SomeFunction()
The quick brown fox jumped over the lazy dog


It looks pretty good, I think.  One could use triple quotes too, if the
string
contains quotes.

-- George

-- 
http://mail.python.org/mailman/listinfo/python-list