Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #79125 > unrolled thread

Is there an easy way to control indents in Python

Back to article view | Back to comp.lang.python

Contents

  Is there an easy way to control indents in Python ryguy7272 <ryanshuell@gmail.com> - 2014-10-14 19:13 -0700
    Re: Is there an easy way to control indents in Python Juan Christian <juan0christian@gmail.com> - 2014-10-14 23:23 -0300
      Re: Is there an easy way to control indents in Python alex23 <wuwei23@gmail.com> - 2014-10-15 17:27 +1000
        Re: Is there an easy way to control indents in Python Chris “Kwpolska” Warrick <kwpolska@gmail.com> - 2014-10-15 16:32 +0200
          Re: Is there an easy way to control indents in Python alex23 <wuwei23@gmail.com> - 2014-10-16 09:51 +1000
            Re: Is there an easy way to control indents in Python Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-10-17 18:22 +1300
        Re: Is there an easy way to control indents in Python Terry Reedy <tjreedy@udel.edu> - 2014-10-15 13:12 -0400
        Re: Is there an easy way to control indents in Python Ian Kelly <ian.g.kelly@gmail.com> - 2014-10-15 13:30 -0600
          Re: Is there an easy way to control indents in Python Simon Kennedy <sffjunkie@gmail.com> - 2014-10-16 07:08 -0700
            Re: Is there an easy way to control indents in Python Chris Angelico <rosuav@gmail.com> - 2014-10-17 02:02 +1100
            Re: Is there an easy way to control indents in Python Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-10-18 21:53 +1100
              Re: Is there an easy way to control indents in Python Simon Kennedy <sffjunkie@gmail.com> - 2014-10-20 08:54 -0700
                Re: Is there an easy way to control indents in Python Ian Kelly <ian.g.kelly@gmail.com> - 2014-10-20 11:54 -0600
                  Re: Is there an easy way to control indents in Python Simon Kennedy <sffjunkie@gmail.com> - 2014-10-21 01:45 -0700
                    Re: Is there an easy way to control indents in Python Ian Kelly <ian.g.kelly@gmail.com> - 2014-10-21 11:09 -0600
                Re: Is there an easy way to control indents in Python Ian Kelly <ian.g.kelly@gmail.com> - 2014-10-20 11:57 -0600
                Re: Is there an easy way to control indents in Python Juan Christian <juan0christian@gmail.com> - 2014-10-20 17:04 -0200
                Re: Is there an easy way to control indents in Python Ian Kelly <ian.g.kelly@gmail.com> - 2014-10-20 13:40 -0600
                Re: Is there an easy way to control indents in Python MRAB <python@mrabarnett.plus.com> - 2014-10-20 20:43 +0100
                Re: Is there an easy way to control indents in Python Juan Christian <juan0christian@gmail.com> - 2014-10-20 20:30 -0200
                Re: Is there an easy way to control indents in Python Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-10-20 21:13 -0400
    Re: Is there an easy way to control indents in Python Chris Angelico <rosuav@gmail.com> - 2014-10-15 13:18 +1100
    Re: Is there an easy way to control indents in Python Dan Stromberg <drsalists@gmail.com> - 2014-10-14 19:38 -0700
    Re: Is there an easy way to control indents in Python Zachary Ware <zachary.ware+pylist@gmail.com> - 2014-10-14 21:35 -0500
    Re: Is there an easy way to control indents in Python Chris Angelico <rosuav@gmail.com> - 2014-10-15 13:47 +1100
    Re: Is there an easy way to control indents in Python jumppanen.jussi@gmail.com - 2014-10-21 06:51 -0700

Page 1 of 2  [1] 2  Next page →

#79125 — Is there an easy way to control indents in Python

I'm just learning Python.  It seems like indents are EXTREMELY important.  I guess, since there are no brackets, everything is controlled by indents.  Well, I'm reading a couple books on Python now, and in almost all of the examples they don't have proper indents, so when I copy/paste the code (from the PDF to the IDE) the indents are totally screwed up.  I'm thinking that there should be some control, or setting, for this.  I hope.  :)

I have PyCharm 3.4 and Python 3.4.

[toc] | [next] | [standalone]

#79126

[Multipart message — attachments visible in raw view] — view raw

Using PyCharm is easy:

File > Settings > (IDE Settings) Editor > Smart Keys > Reformat on paste >
choose "Reformat Block"

On Tue, Oct 14, 2014 at 11:13 PM, ryguy7272 <ryanshuell@gmail.com> wrote:

> I'm just learning Python.  It seems like indents are EXTREMELY important.
> I guess, since there are no brackets, everything is controlled by indents.
> Well, I'm reading a couple books on Python now, and in almost all of the
> examples they don't have proper indents, so when I copy/paste the code
> (from the PDF to the IDE) the indents are totally screwed up.  I'm thinking
> that there should be some control, or setting, for this.  I hope.  :)
>
> I have PyCharm 3.4 and Python 3.4.
> --
> https://mail.python.org/mailman/listinfo/python-list
>

[toc] | [prev] | [next] | [standalone]

#79139

On 15/10/2014 12:23 PM, Juan Christian wrote:
> Using PyCharm is easy:
>
> File > Settings > (IDE Settings) Editor > Smart Keys > Reformat on paste
>  > choose "Reformat Block"


This isn't as straight forward as you imply. Say I have misindented code 
like this:

     if True:
     print 'true'
     else:
     print 'false'
     print 'done'

If I select this block in PyCharm and reformat it, I get:

     if True:
         print 'true'
     else:
     print 'false'
     print 'done'

Which is still invalid. Even if it did work more fully, though, how 
would it determine the correct placement of the last line of code?

[toc] | [prev] | [next] | [standalone]

#79148

On Wed, Oct 15, 2014 at 9:27 AM, alex23 <wuwei23@gmail.com> wrote:
> On 15/10/2014 12:23 PM, Juan Christian wrote:
>>
>> Using PyCharm is easy:
>>
>> File > Settings > (IDE Settings) Editor > Smart Keys > Reformat on paste
>>  > choose "Reformat Block"
>
>
>
> This isn't as straight forward as you imply. Say I have misindented code
> like this:
>
>     if True:
>     print 'true'
>     else:
>     print 'false'
>     print 'done'
>
> If I select this block in PyCharm and reformat it, I get:
>
>     if True:
>         print 'true'
>     else:
>     print 'false'
>     print 'done'
>
> Which is still invalid. Even if it did work more fully, though, how would it
> determine the correct placement of the last line of code?
> --
> https://mail.python.org/mailman/listinfo/python-list

It should parse this as

else:
    print 'false'
    print 'done'

Why?  Because things like `print 'done'` usually have an empty line before it:

if True:
print 'true'
else:
print 'false'

print 'done'

That should be parsed the way you want it done.  Makes perfect sense
when you look at it.

-- 
Chris “Kwpolska” Warrick <http://chriswarrick.com/>
PGP: 5EAAEA16
stop html mail | always bottom-post | only UTF-8 makes sense

[toc] | [prev] | [next] | [standalone]

#79186

On 16/10/2014 12:32 AM, Chris “Kwpolska” Warrick wrote:
> It should parse this as
>
> else:
>      print 'false'
>      print 'done'
>
> Why?  Because things like `print 'done'` usually have an empty line before it:
>
> if True:
> print 'true'
> else:
> print 'false'
>
> print 'done'
>
> That should be parsed the way you want it done.  Makes perfect sense
> when you look at it.

I don't think it makes any sense at all, for two reasons:

1) Empty lines have no such semantic meaning in Python.
2) Anything that strips tabs is just as likely to strip EOLs.

[toc] | [prev] | [next] | [standalone]

#79233

> On 16/10/2014 12:32 AM, Chris “Kwpolska” Warrick wrote:

>> Why?  Because things like `print 'done'` usually have an empty line 
>> before it:

Not in my code, they don't. I never put blank lines
inside functions.

-- 
Greg

[toc] | [prev] | [next] | [standalone]

#79158

On 10/15/2014 10:32 AM, Chris “Kwpolska” Warrick wrote:
> On Wed, Oct 15, 2014 at 9:27 AM, alex23 <wuwei23@gmail.com> wrote:
>> On 15/10/2014 12:23 PM, Juan Christian wrote:
>>>
>>> Using PyCharm is easy:
>>>
>>> File > Settings > (IDE Settings) Editor > Smart Keys > Reformat on paste
>>>   > choose "Reformat Block"
>>
>>
>>
>> This isn't as straight forward as you imply. Say I have misindented code
>> like this:
>>
>>      if True:
>>      print 'true'
>>      else:
>>      print 'false'
>>      print 'done'
>>
>> If I select this block in PyCharm and reformat it, I get:
>>
>>      if True:
>>          print 'true'
>>      else:
>>      print 'false'
>>      print 'done'
>>
>> Which is still invalid. Even if it did work more fully, though, how would it
>> determine the correct placement of the last line of code?
>> --
>> https://mail.python.org/mailman/listinfo/python-list
>
> It should parse this as
>
> else:
>      print 'false'
>      print 'done'
>
> Why?  Because things like `print 'done'` usually have an empty line before it:

There is no such rule in Python so it hardly dependable for auto indenting.


> if True:
> print 'true'
> else:
> print 'false'
>
> print 'done'
>
> That should be parsed the way you want it done.  Makes perfect sense
> when you look at it.
>


-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#79174

On Wed, Oct 15, 2014 at 11:12 AM, Terry Reedy <tjreedy@udel.edu> wrote:
> On 10/15/2014 10:32 AM, Chris “Kwpolska” Warrick wrote:
>> It should parse this as
>>
>> else:
>>      print 'false'
>>      print 'done'
>>
>> Why?  Because things like `print 'done'` usually have an empty line before
>> it:
>
>
> There is no such rule in Python so it hardly dependable for auto indenting.

I agree. I very rarely use blank lines inside functions. As I see it,
if you feel you need a blank line for separation within a function,
that's an indication your function is overly complex and should be
broken up.

Keeping blank lines out of functions also makes it easy to copy/paste
those functions into the interactive interpreter, which can be handy
e.g. when sharing snippets of code by email.

[toc] | [prev] | [next] | [standalone]

#79213

On Wednesday, 15 October 2014 20:31:15 UTC+1, Ian  wrote:
> I agree. I very rarely use blank lines inside functions. As I see it,
> if you feel you need a blank line for separation within a function,
> that's an indication your function is overly complex and should be
> broken up.

Whereas I feel that if I wanted to write code which looked like that I'd have learnt/learned Perl ;-)

Each to their own.

[toc] | [prev] | [next] | [standalone]

#79216

On Fri, Oct 17, 2014 at 1:08 AM, Simon Kennedy <sffjunkie@gmail.com> wrote:
> On Wednesday, 15 October 2014 20:31:15 UTC+1, Ian  wrote:
>> I agree. I very rarely use blank lines inside functions. As I see it,
>> if you feel you need a blank line for separation within a function,
>> that's an indication your function is overly complex and should be
>> broken up.
>
> Whereas I feel that if I wanted to write code which looked like that I'd have learnt/learned Perl ;-)

I did learn Perl. That's why I now code in Python.

ChrisA

[toc] | [prev] | [next] | [standalone]

#79268

Simon Kennedy wrote:

> On Wednesday, 15 October 2014 20:31:15 UTC+1, Ian  wrote:
>> I agree. I very rarely use blank lines inside functions. As I see it,
>> if you feel you need a blank line for separation within a function,
>> that's an indication your function is overly complex and should be
>> broken up.
> 
> Whereas I feel that if I wanted to write code which looked like that I'd
> have learnt/learned Perl ;-)

I'm curious what aspect of idiomatic Perl code you are referring to. When
people talk about Perl code dismissively, I normally think of three things:

- excessively long one-liners;
- excessive use of symbols and sigils ("line noise");
- "More Than One [Thousand] Ways To Do It"

Are you suggesting that Perl functions tend to be too small? What do you
consider "too small"?


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#79317

On Saturday, 18 October 2014 11:53:16 UTC+1, Steven D'Aprano  wrote:
> I'm curious what aspect of idiomatic Perl code you are referring to. When
> people talk about Perl code dismissively, I normally think of three things:
> 
> - excessively long one-liners;
> - excessive use of symbols and sigils ("line noise");
> - "More Than One [Thousand] Ways To Do It"

I'll preface the following by stating that I program in Python as a hobby and that the only programming I've done professionally was a few years ago now and consisted of a Visual Basic style language (Wonderware Intouch) and a piece of software called ABB Sattline.

Not having ever attempted to go beyond even the basics of Perl, the aspect that causes me to refer to Perl 'dismissively' as well comment in this thread, is that I don't find Perl to be an aesthetically pleasing language and I consider Python functions which have no blank lines in them to be a small step towards Perl.

Some people do not like Python's indentation rules but for me it's a large part of what draws me to program in Python. Spaces for indentation and blank lines are both aspects of how I like to program. 

I write in Python because I like to, not because I have to.

I think the only reason I might code a function with no blank lines was if I was programming in a language that using blank lines caused it to run too slowly.
 
> Are you suggesting that Perl functions tend to be too small? What do you
> consider "too small"?

No function is "too small". A one line function if it helps to describe the higher level code where it is called is fine by me.

[toc] | [prev] | [next] | [standalone]

#79318

On Mon, Oct 20, 2014 at 9:54 AM, Simon Kennedy <sffjunkie@gmail.com> wrote:
> Not having ever attempted to go beyond even the basics of Perl, the aspect that causes me to refer to Perl 'dismissively' as well comment in this thread, is that I don't find Perl to be an aesthetically pleasing language and I consider Python functions which have no blank lines in them to be a small step towards Perl.
>
> Some people do not like Python's indentation rules but for me it's a large part of what draws me to program in Python. Spaces for indentation and blank lines are both aspects of how I like to program.
>
> I write in Python because I like to, not because I have to.
>
> I think the only reason I might code a function with no blank lines was if I was programming in a language that using blank lines caused it to run too slowly.

So to be clear, I'm not talking about taking a function like this
(contrived) example and just removing the blank line:

def find_path(graphdata, start, end):
    edges = map(str.split, lines)
    graph = collections.defaultdict(list)
    for node1, node2, weight in edges:
        graph[node1].append((node[2], int(weight)))
        graph[node2].append((node[1], int(weight)))

    open_heap = [(0, (start,))]
    closed_set = set()
    while open_heap:
        cost, path = heapq.heappop(open_heap)
        current_node = path[-1]
        if current_node == end:
            return path
        if current_node in closed_set:
            continue
        for next_node, weight in graph[current_node]:
            heapq.heappush((cost + weight, path + (next_node,)))
        closed_set.add(current_node)
    else:
        raise ValueError("No path from start to end")

Rather, I'm saying that where the blank line is should be the start of
a new function. There would still be a blank line, just no longer
inside the function.

Now, maybe you think there should be more blank lines in the above, in
which case we'll just have to disagree on that point.

[toc] | [prev] | [next] | [standalone]

#79374

On Monday, 20 October 2014 18:56:05 UTC+1, Ian  wrote:
> Rather, I'm saying that where the blank line is should be the start of
> a new function. There would still be a blank line, just no longer
> inside the function.
> 
> Now, maybe you think there should be more blank lines in the above, in
> which case we'll just have to disagree on that point.

Why did you separate the above 2 sequences of thoughts by a blank line? Is the inherent pause in the communication of your thoughts not also applicable to your code?

Where we see the pause between thoughts appears to be in a different place. I see them both within the function and between the functions and I assume you see them between the functions only.

BTW I'm more than happy to disagree. There is no right or wrong answer unless Guido wants to pronounce on the issue :-J

[toc] | [prev] | [next] | [standalone]

#79389

On Tue, Oct 21, 2014 at 2:45 AM, Simon Kennedy <sffjunkie@gmail.com> wrote:
> On Monday, 20 October 2014 18:56:05 UTC+1, Ian  wrote:
>> Rather, I'm saying that where the blank line is should be the start of
>> a new function. There would still be a blank line, just no longer
>> inside the function.
>>
>> Now, maybe you think there should be more blank lines in the above, in
>> which case we'll just have to disagree on that point.
>
> Why did you separate the above 2 sequences of thoughts by a blank line? Is the inherent pause in the communication of your thoughts not also applicable to your code?
>
> Where we see the pause between thoughts appears to be in a different place. I see them both within the function and between the functions and I assume you see them between the functions only.

That makes sense. I see two distinct thoughts in the function that I
posted: "build the graph" and "search the graph". The blank line
separates them. By my view, a function should represent a single,
complete thought. Thus, the function should be broken up at the blank
line.

[toc] | [prev] | [next] | [standalone]

#79319

On Mon, Oct 20, 2014 at 11:54 AM, Ian Kelly <ian.g.kelly@gmail.com> wrote:
> On Mon, Oct 20, 2014 at 9:54 AM, Simon Kennedy <sffjunkie@gmail.com> wrote:
>> Not having ever attempted to go beyond even the basics of Perl, the aspect that causes me to refer to Perl 'dismissively' as well comment in this thread, is that I don't find Perl to be an aesthetically pleasing language and I consider Python functions which have no blank lines in them to be a small step towards Perl.
>>
>> Some people do not like Python's indentation rules but for me it's a large part of what draws me to program in Python. Spaces for indentation and blank lines are both aspects of how I like to program.
>>
>> I write in Python because I like to, not because I have to.
>>
>> I think the only reason I might code a function with no blank lines was if I was programming in a language that using blank lines caused it to run too slowly.
>
> So to be clear, I'm not talking about taking a function like this
> (contrived) example and just removing the blank line:
>
> def find_path(graphdata, start, end):
>     edges = map(str.split, lines)
>     graph = collections.defaultdict(list)
>     for node1, node2, weight in edges:
>         graph[node1].append((node[2], int(weight)))
>         graph[node2].append((node[1], int(weight)))
>
>     open_heap = [(0, (start,))]
>     closed_set = set()
>     while open_heap:
>         cost, path = heapq.heappop(open_heap)
>         current_node = path[-1]
>         if current_node == end:
>             return path
>         if current_node in closed_set:
>             continue
>         for next_node, weight in graph[current_node]:
>             heapq.heappush((cost + weight, path + (next_node,)))
>         closed_set.add(current_node)
>     else:
>         raise ValueError("No path from start to end")
>
> Rather, I'm saying that where the blank line is should be the start of
> a new function. There would still be a blank line, just no longer
> inside the function.
>
> Now, maybe you think there should be more blank lines in the above, in
> which case we'll just have to disagree on that point.

By the way, I didn't test that at all, which is why I've spotted at
least two bugs in it since sending the message.

[toc] | [prev] | [next] | [standalone]

#79324

[Multipart message — attachments visible in raw view] — view raw

Ok, new code using ?:

import sqlite3

db = sqlite3.connect('db.sqlite')


def create_db():
    db.execute('''
    CREATE TABLE TOPICS(
    ID INT PRIMARY KEY NOT NULL,
    URL VARCHAR NOT NULL,
    AUTHOR VARCHAR NOT NULL,
    MESSAGE VARCHAR NOT NULL
    );
    ''')


def insert_db(_id, url, author, message):
    db.execute("INSERT INTO TOPICS (ID, URL, AUTHOR, MESSAGE) VALUES (?, ?,
?, ?)", (_id, url, author, message))
    db.commit()


def get_db(_id):
cursor = db.execute("SELECT ID, URL, AUTHOR, MESSAGE FROM TOPICS WHERE ID =
?", (_id))
return cursor.fetchone()


if __name__ == '__main__':
create_db()
insert_db(12, 'abc.com', 'a', 'b')
print(get_db(12))
db.close()

-------------

But now when I execute I get

Traceback (most recent call last):
  File ".\sql.py", line 30, in <module>
    print(get_db(12))
  File ".\sql.py", line 23, in get_db
    cursor = db.execute("SELECT ID, URL, AUTHOR, MESSAGE FROM TOPICS WHERE
ID = ?", (_id))
ValueError: parameters are of unsupported type

-------------

And the second time, again, I get

Traceback (most recent call last):
  File ".\sql.py", line 28, in <module>
    create_db()
  File ".\sql.py", line 14, in create_db
    ''')
sqlite3.OperationalError: table TOPICS already exists

On Mon, Oct 20, 2014 at 3:57 PM, Ian Kelly <ian.g.kelly@gmail.com> wrote:

> On Mon, Oct 20, 2014 at 11:54 AM, Ian Kelly <ian.g.kelly@gmail.com> wrote:
> > On Mon, Oct 20, 2014 at 9:54 AM, Simon Kennedy <sffjunkie@gmail.com>
> wrote:
> >> Not having ever attempted to go beyond even the basics of Perl, the
> aspect that causes me to refer to Perl 'dismissively' as well comment in
> this thread, is that I don't find Perl to be an aesthetically pleasing
> language and I consider Python functions which have no blank lines in them
> to be a small step towards Perl.
> >>
> >> Some people do not like Python's indentation rules but for me it's a
> large part of what draws me to program in Python. Spaces for indentation
> and blank lines are both aspects of how I like to program.
> >>
> >> I write in Python because I like to, not because I have to.
> >>
> >> I think the only reason I might code a function with no blank lines was
> if I was programming in a language that using blank lines caused it to run
> too slowly.
> >
> > So to be clear, I'm not talking about taking a function like this
> > (contrived) example and just removing the blank line:
> >
> > def find_path(graphdata, start, end):
> >     edges = map(str.split, lines)
> >     graph = collections.defaultdict(list)
> >     for node1, node2, weight in edges:
> >         graph[node1].append((node[2], int(weight)))
> >         graph[node2].append((node[1], int(weight)))
> >
> >     open_heap = [(0, (start,))]
> >     closed_set = set()
> >     while open_heap:
> >         cost, path = heapq.heappop(open_heap)
> >         current_node = path[-1]
> >         if current_node == end:
> >             return path
> >         if current_node in closed_set:
> >             continue
> >         for next_node, weight in graph[current_node]:
> >             heapq.heappush((cost + weight, path + (next_node,)))
> >         closed_set.add(current_node)
> >     else:
> >         raise ValueError("No path from start to end")
> >
> > Rather, I'm saying that where the blank line is should be the start of
> > a new function. There would still be a blank line, just no longer
> > inside the function.
> >
> > Now, maybe you think there should be more blank lines in the above, in
> > which case we'll just have to disagree on that point.
>
> By the way, I didn't test that at all, which is why I've spotted at
> least two bugs in it since sending the message.
> --
> https://mail.python.org/mailman/listinfo/python-list
>

[toc] | [prev] | [next] | [standalone]

#79326

On Mon, Oct 20, 2014 at 1:04 PM, Juan Christian
<juan0christian@gmail.com> wrote:
> Ok, new code using ?:

I suspect you meant to post this to some other thread.

> def get_db(_id):
> cursor = db.execute("SELECT ID, URL, AUTHOR, MESSAGE FROM TOPICS WHERE ID =
> ?", (_id))
> return cursor.fetchone()

(_id) is not a tuple; it's just a parenthesized variable name. To
create a one-element tuple you need a trailing comma: (_id,)

Remember that with the exception of the empty tuple (), tuples are
created by commas, not parentheses.

[toc] | [prev] | [next] | [standalone]

#79327

On 2014-10-20 20:04, Juan Christian wrote:
> Ok, new code using ?:
>
> import sqlite3
>
> db = sqlite3.connect('db.sqlite')
>
>
> def create_db():
>      db.execute('''
> CREATE TABLE TOPICS(
> ID INT PRIMARY KEY NOT NULL,
> URL VARCHAR NOT NULL,
> AUTHOR VARCHAR NOT NULL,
> MESSAGE VARCHAR NOT NULL
> );
> ''')
>
>
> def insert_db(_id, url, author, message):
>      db.execute("INSERT INTO TOPICS (ID, URL, AUTHOR, MESSAGE) VALUES
> (?, ?, ?, ?)", (_id, url, author, message))
>      db.commit()
>
>
> def get_db(_id):
> cursor = db.execute("SELECT ID, URL, AUTHOR, MESSAGE FROM TOPICS WHERE
> ID = ?", (_id))
> return cursor.fetchone()
>
>
> if __name__ == '__main__':
> create_db()
> insert_db(12, 'abc.com <http://abc.com>', 'a', 'b')
> print(get_db(12))
> db.close()
>
> -------------
>
> But now when I execute I get
>
> Traceback (most recent call last):
>    File ".\sql.py", line 30, in <module>
>      print(get_db(12))
>    File ".\sql.py", line 23, in get_db
>      cursor = db.execute("SELECT ID, URL, AUTHOR, MESSAGE FROM TOPICS
> WHERE ID = ?", (_id))
> ValueError: parameters are of unsupported type
>
> -------------
>
I'm not certain, but I think that the SQL type is called "INTEGER", not
"INT".

> And the second time, again, I get
>
> Traceback (most recent call last):
>    File ".\sql.py", line 28, in <module>
>      create_db()
>    File ".\sql.py", line 14, in create_db
>      ''')
> sqlite3.OperationalError: table TOPICS already exists
>
That's because you created the table the last time you ran it.

[toc] | [prev] | [next] | [standalone]

#79345

[Multipart message — attachments visible in raw view] — view raw

Sorry guys, my post about SQL was not meant to be here!!!

On Mon, Oct 20, 2014 at 5:43 PM, MRAB <python@mrabarnett.plus.com> wrote:

> On 2014-10-20 20:04, Juan Christian wrote:
>
>> Ok, new code using ?:
>>
>> import sqlite3
>>
>> db = sqlite3.connect('db.sqlite')
>>
>>
>> def create_db():
>>      db.execute('''
>> CREATE TABLE TOPICS(
>> ID INT PRIMARY KEY NOT NULL,
>> URL VARCHAR NOT NULL,
>> AUTHOR VARCHAR NOT NULL,
>> MESSAGE VARCHAR NOT NULL
>> );
>> ''')
>>
>>
>> def insert_db(_id, url, author, message):
>>      db.execute("INSERT INTO TOPICS (ID, URL, AUTHOR, MESSAGE) VALUES
>> (?, ?, ?, ?)", (_id, url, author, message))
>>      db.commit()
>>
>>
>> def get_db(_id):
>> cursor = db.execute("SELECT ID, URL, AUTHOR, MESSAGE FROM TOPICS WHERE
>> ID = ?", (_id))
>> return cursor.fetchone()
>>
>>
>> if __name__ == '__main__':
>> create_db()
>> insert_db(12, 'abc.com <http://abc.com>', 'a', 'b')
>> print(get_db(12))
>> db.close()
>>
>> -------------
>>
>> But now when I execute I get
>>
>> Traceback (most recent call last):
>>    File ".\sql.py", line 30, in <module>
>>      print(get_db(12))
>>    File ".\sql.py", line 23, in get_db
>>      cursor = db.execute("SELECT ID, URL, AUTHOR, MESSAGE FROM TOPICS
>> WHERE ID = ?", (_id))
>> ValueError: parameters are of unsupported type
>>
>> -------------
>>
>>  I'm not certain, but I think that the SQL type is called "INTEGER", not
> "INT".
>
>  And the second time, again, I get
>>
>> Traceback (most recent call last):
>>    File ".\sql.py", line 28, in <module>
>>      create_db()
>>    File ".\sql.py", line 14, in create_db
>>      ''')
>> sqlite3.OperationalError: table TOPICS already exists
>>
>>  That's because you created the table the last time you ran it.
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.python

csiph-web