Re: Steve D'Aprano, you're the "master". What's wrong with this concatenation statement?

n" "line 2\n" "line 3") taking advantage of Python's compile-time implicit concatenation of string constants. or sSQL = "line 1\n" \ "line 2\n" \ "line 3" But no, "master", your answer

Re: String concatenation (was: Steve D'Aprano, you're the "master". What's wrong with this concatenation statement?)

You're saying that wasn't a coded message? On Sun, May 8, 2016, 10:44 PM srinivas devaki wrote: > I'm so sorry, forgot to lock my phone. > On May 9, 2016 9:01 AM, "srinivas devaki" > wrote: > > > f be gfdnbh be b GB GB BH GB vbjfhjb GB

Re: What's wrong with this concatenation statement?

On Monday 09 May 2016 09:10, DFS wrote: > sSQL = "line 1\n" > sSQL += "line 2\n" > sSQL += "line 3" Pointlessly provocative subject line edited. Since all three lines are constants know by the programmer at the time the source code is written, it should be written as: sSQL = """line 1 line

Re: String concatenation (was: Steve D'Aprano, you're the "master". What's wrong with this concatenation statement?)

f be gfdnbh be b GB GB BH GB vbjfhjb GB bffbbubbv GB hbu hbu fjbjfbbbufhbvh VB have fqbgvfb NB bb GB GB GB GB bbu GB vu GB vu GB GB b GB fbufjnb BH GB GB bvvfbubbjubuv GB b fbufbbby GB bfff GB f GB bbbu GB GB ffinj GB vh vh fjb GB fj GB h h GB gjfthey're the b GB gjf GBG GBG q GB

Re: String concatenation (was: Steve D'Aprano, you're the "master". What's wrong with this concatenation statement?)

I'm so sorry, forgot to lock my phone. On May 9, 2016 9:01 AM, "srinivas devaki" wrote: > f be gfdnbh be b GB GB BH GB vbjfhjb GB bffbbubbv GB hbu hbu > fjbjfbbbufhbvh VB have fqbgvfb NB bb GB GB GB GB bbu GB vu GB vu GB GB > b GB fbufjnb BH GB GB

Re: String concatenation (was: Steve D'Aprano, you're the "master". What's wrong with this concatenation statement?)

On Mon, May 9, 2016 at 10:44 AM, Thomas 'PointedEars' Lahn wrote: > With the “%” string operator (deprecated), str.format(), and str.Template, > you can use other values in string values even without concatenation. Not deprecated. Don't spread FUD. > Finally, with SQL you

String concatenation (was: Steve D'Aprano, you're the "master". What's wrong with this concatenation statement?)

DFS wrote: > sSQL = "line 1\n" > sSQL += "line 2\n" > sSQL += "line 3" What is wrong with it in Python is that it is unnecessarily inefficient. Python has implicit string concatenation if all operands are string literals:

Re: Steve D'Aprano, you're the "master". What's wrong with this concatenation statement?

On Sun, May 8, 2016 at 7:10 PM, DFS wrote: > sSQL = "line 1\n" > sSQL += "line 2\n" > sSQL += "line 3" > -- > https://mail.python.org/mailman/listinfo/python-list What is your point DFS? You found pylint, and you don't like what it tells you. Its a tool, and it can tell you

Re: Steve D'Aprano, you're the "master". What's wrong with this concatenation statement?

While I'm not Steven... On 2016-05-08 19:10, DFS wrote: > sSQL = "line 1\n" > sSQL += "line 2\n" > sSQL += "line 3" If you're only doing it once, it's adequate. If you're doing it within a loop for thing in some_iter(): s = "line1\n" s += "line2\n" s += "line3" use(s, thing)

Steve D'Aprano, you're the "master". What's wrong with this concatenation statement?

sSQL = "line 1\n" sSQL += "line 2\n" sSQL += "line 3" -- https://mail.python.org/mailman/listinfo/python-list

[issue26702] A better assert statement

Serhiy Storchaka added the comment: I'm -1 for changing syntax of assert. But I think that it may be useful to change semantic of assert so that all intermediate results of subexpressions are saved and included in the assert report (or at least their shortened reprs). I'm +0 for this.

Re: PEP proposal: sequence expansion support for yield statement: yield *

On Fri, Apr 22, 2016 at 1:19 AM, justin walters wrote: > I agree with the others that the new syntax is not needed. > > I would also like to point out that I believe any new added syntax or > functionality should avoid the use of '*' and '**' as both of these >

Re: PEP proposal: sequence expansion support for yield statement: yield *

I agree with the others that the new syntax is not needed. I would also like to point out that I believe any new added syntax or functionality should avoid the use of '*' and '**' as both of these characters are already used for many things such as optional arguments and mathematical operators.

Re: PEP proposal: sequence expansion support for yield statement: yield *

On Thu, 21 Apr 2016 05:34 am, Ken Seehart wrote: > Currently the common pattern for yielding the elements in a sequence is as > follows: > > for x in sequence: yield x > > I propose the following replacement (the result would be identical): > > yield *sequence Others have already pointed

Re: PEP proposal: sequence expansion support for yield statement: yield *

On Thu, Apr 21, 2016 at 8:26 AM, wrote: > Anyway, thanks for the link. And I suppose checking Python 3 for > implementation would be a good prior step as well! Sadly, "yield from" is not > in python 2.7, but it's presence in python 3.3 renders my proposal dead as a >

Re: PEP proposal: sequence expansion support for yield statement: yield *

On Wednesday, April 20, 2016 at 1:00:45 PM UTC-7, Ethan Furman wrote: > On 04/20/2016 12:34 PM, Ken Seehart wrote: > > New ideas for Python are typically vetted on Python Ideas. [1] > > > Currently the common pattern for yielding the elements in a sequence > > is as follows: > > > >for x in

Re: PEP proposal: sequence expansion support for yield statement: yield *

Currently the common pattern for yielding the elements in a sequence is as follows: for x in sequence: yield x I propose the following replacement (the result would be identical): yield *sequence imho the current syntax is much more intuitive, it is obvious to infer what it does by

Re: PEP proposal: sequence expansion support for yield statement: yield *

On 04/20/2016 12:34 PM, Ken Seehart wrote: New ideas for Python are typically vetted on Python Ideas. [1] Currently the common pattern for yielding the elements in a sequence > is as follows: for x in sequence: yield x I propose the following replacement (the result would be identical):

Re: PEP proposal: sequence expansion support for yield statement: yield *

On Wed, Apr 20, 2016, at 15:34, Ken Seehart wrote: > Currently the common pattern for yielding the elements in a sequence is > as follows: > > for x in sequence: yield x > > I propose the following replacement (the result would be identical): > > yield *sequence yield from sequence --

PEP proposal: sequence expansion support for yield statement: yield *

Currently the common pattern for yielding the elements in a sequence is as follows: for x in sequence: yield x I propose the following replacement (the result would be identical): yield *sequence The semantics are somewhat different from argument expansion (from which the syntax is

[issue26702] A better assert statement

Barry A. Warsaw added the comment: On Apr 06, 2016, at 03:07 PM, Serhiy Storchaka wrote: >I think in this particular case you are more interesting in the value of k >than k.replace('.', '').replace('-', '').replace('_', ''). Possibly so. -- ___

[issue26702] A better assert statement

Serhiy Storchaka added the comment: I think in this particular case you are more interesting in the value of k than k.replace('.', '').replace('-', '').replace('_', ''). -- nosy: +rhettinger, serhiy.storchaka ___ Python tracker

[issue26702] A better assert statement

assert statement versions: Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26702> ___ ___ Python-bugs-list mailing list Unsubsc

Re: module alias in import statement

On Tue, Apr 5, 2016 at 5:26 PM, Steven D'Aprano wrote: >>> sys.modules isn't really a cache in that sense, though. The "hard >>> problem" of cache invalidation comes from the fundamental assumption >>> that a cache hit should be semantically identical to a

Re: module alias in import statement

On Tuesday 05 April 2016 14:27, Rustom Mody wrote: > On Tuesday, April 5, 2016 at 9:53:30 AM UTC+5:30, Chris Angelico wrote: >> On Tue, Apr 5, 2016 at 2:08 PM, Rustom Mody wrote: >> >> 'import tk.ttk' looks for 'tk' in sys.modules, does not find it, looks >> >> for a module named 'tk' on disk,

Re: module alias in import statement

On Tuesday, April 5, 2016 at 9:53:30 AM UTC+5:30, Chris Angelico wrote: > On Tue, Apr 5, 2016 at 2:08 PM, Rustom Mody wrote: > >> 'import tk.ttk' looks for 'tk' in sys.modules, does not find it, looks > >> for a module named 'tk' on disk, does not find it, and says so. > > > > A well-known quote

Re: module alias in import statement

On Tue, Apr 5, 2016 at 2:08 PM, Rustom Mody wrote: >> 'import tk.ttk' looks for 'tk' in sys.modules, does not find it, looks >> for a module named 'tk' on disk, does not find it, and says so. > > A well-known quote comes to mind: > > | There are only two hard things in

Re: module alias in import statement

On Tuesday, April 5, 2016 at 2:17:24 AM UTC+5:30, Terry Reedy wrote: > On 4/4/2016 11:31 AM, ast wrote: > > hello > > > import tkinter as tk > import tk.ttk as ttk > > > > Traceback (most recent call last): > > File "", line 1, in > > import tk.ttk as ttk > >

Re: module alias in import statement

On 4/4/2016 11:31 AM, ast wrote: hello import tkinter as tk import tk.ttk as ttk Traceback (most recent call last): File "", line 1, in import tk.ttk as ttk ImportError: No module named 'tk' of course import tkinter.ttk as ttk works Strange, isn't it ? Nope. As

Re: module alias in import statement

amed 'tk' > > > of course > >>>> import tkinter.ttk as ttk > > works > > Strange, isn't it ? No. You have to understand what the import statement does. "import tkinter" does at least three steps: - locate a Python file called (for example) "tk

Re: module alias in import statement

On Monday, April 4, 2016 at 11:31:41 AM UTC-4, ast wrote: > hello > > >>> import tkinter as tk > >>> import tk.ttk as ttk > > Traceback (most recent call last): > File "", line 1, in > import tk.ttk as ttk > ImportError: No module named 'tk' > > > of course > > >>> import

module alias in import statement

hello import tkinter as tk import tk.ttk as ttk Traceback (most recent call last): File "", line 1, in import tk.ttk as ttk ImportError: No module named 'tk' of course import tkinter.ttk as ttk works Strange, isn't it ? --

Re: Readability counts, was Re: Use of Lists, Tupples, or Sets in IF statement.

On Tuesday, March 15, 2016 at 11:05:32 PM UTC+5:30, Peter Otten wrote: > Indeed. It's still better than > > "This is %s a fruit" % (x in x_list and "" or "not") > > The bug is intentional; the fix is of course > > "This is %s a fruit" % (x in x_list and "most likely" or "probably not") > > ;)

Re: Readability counts, was Re: Use of Lists, Tupples, or Sets in IF statement.

Rustom Mody wrote: > On Tuesday, March 15, 2016 at 2:00:25 PM UTC+5:30, Peter Otten wrote: >> Rustom Mody wrote: >> >> > Others have answered some parts >> if x in x_list: >> > ... print("That is a fruit.") >> > ... else: >> > ... print("That is not a fruit.") >> > ... >> > >> >

Re: Readability counts, was Re: Use of Lists, Tupples, or Sets in IF statement.

On Tuesday, March 15, 2016 at 2:00:25 PM UTC+5:30, Peter Otten wrote: > Rustom Mody wrote: > > > Others have answered some parts > if x in x_list: > > ... print("That is a fruit.") > > ... else: > > ... print("That is not a fruit.") > > ... > > > > However one can distribute the

Readability counts, was Re: Use of Lists, Tupples, or Sets in IF statement.

Rustom Mody wrote: > Others have answered some parts if x in x_list: > ... print("That is a fruit.") > ... else: > ... print("That is not a fruit.") > ... > > However one can distribute the print out of the if; Thus > "This is %s a fruit" % ("" if x in x_list else "not")

Re: Use of Lists, Tupples, or Sets in IF statement.

On Tuesday, March 15, 2016 at 5:56:54 AM UTC+5:30, jj0ge...@gmail.com wrote: > In Python is it possible to comparison-equate a variable to a List, Tupple, > or Set and have it return True if the contents of the variable matches an > element in the List, Tupple, or Set. > > E.g. > > x = "apple"

Re: Use of Lists, Tupples, or Sets in IF statement.

On Tue, 15 Mar 2016 11:26 am, jj0gen0i...@gmail.com wrote: > In Python is it possible to comparison-equate a variable to a List, > Tupple, or Set and have it return True if the contents of the variable > matches an element in the List, Tupple, or Set. > > E.g. > > x = "apple" > > x-list =

Re: Use of Lists, Tupples, or Sets in IF statement.

Thought "Tupple" looked wrong, too lazy to look in the book - lol. -- https://mail.python.org/mailman/listinfo/python-list

Re: Use of Lists, Tupples, or Sets in IF statement.

Thanks to all for the responses. Very new to Python, and thought there should be a way to do it. JJ -- https://mail.python.org/mailman/listinfo/python-list

Re: Use of Lists, Tupples, or Sets in IF statement.

On 15/03/2016 00:26, jj0gen0i...@gmail.com wrote: In Python is it possible to comparison-equate a variable to a List, Tupple, or Set and have it return True if the contents of the variable matches an element in the List, Tupple, or Set. It's actually "tuple", but what the heck :) E.g. x

Re: Use of Lists, Tupples, or Sets in IF statement.

On Tue, Mar 15, 2016 at 11:26 AM, wrote: > In Python is it possible to comparison-equate a variable to a List, Tupple, > or Set and have it return True if the contents of the variable matches an > element in the List, Tupple, or Set. > > E.g. > > x = "apple" > > x-list =

Re: Use of Lists, Tupples, or Sets in IF statement.

On Mon, Mar 14, 2016 at 8:26 PM, wrote: > In Python is it possible to comparison-equate a variable to a List, > Tupple, or Set and have it return True if the contents of the variable > matches an element in the List, Tupple, or Set. > > E.g. > > x = "apple" > > x-list =

Use of Lists, Tupples, or Sets in IF statement.

In Python is it possible to comparison-equate a variable to a List, Tupple, or Set and have it return True if the contents of the variable matches an element in the List, Tupple, or Set. E.g. x = "apple" x-list = ["apple", "banana", "peach"] If x == x-list: print('Comparison is True')

Re: a clarification on the "global" statement sought

On Fri, Mar 11, 2016 at 8:09 PM, Charles T. Smith wrote: > "Python deals with variables the other way around. >They are local, if not otherwise declared. >... > def f(): > print(s) > s = "I love Paris in the summer!" > f() > ... >

Re: a clarification on the "global" statement sought

Charles T. Smith wrote: > On Fri, 11 Mar 2016 19:29:20 +1100, Chris Angelico wrote: > >> Usefully? Never. >> >> Simple question - simple answer :) >> >> ChrisA > > > Right, that was the expected answer as well. I just ran into that in > legacy code, checked out the documentation and

Re: a clarification on the "global" statement sought

On Fri, Mar 11, 2016 at 2:13 AM, Charles T. Smith <cts.private.ya...@gmail.com> wrote: > When might a "global" statement be used in the outermost level of a module? You wouldn't need this in a normal module, because locals and globals are the same. It may be useful i

Re: a clarification on the "global" statement sought

On Fri, 11 Mar 2016 08:31:22 +, Mark Lawrence wrote: > Never. Hopefully this > http://www.python-course.eu/python3_global_vs_local_variables.php can > explain it better than I can :) The article is good, I'm glad to have confirmed what I have so empirical stumbled over. ... Irrespective of

Re: a clarification on the "global" statement sought

On Fri, 11 Mar 2016 19:29:20 +1100, Chris Angelico wrote: > Usefully? Never. > > Simple question - simple answer :) > > ChrisA Right, that was the expected answer as well. I just ran into that in legacy code, checked out the documentation and couldn't really make that out. So I figured I

Re: a clarification on the "global" statement sought

On 11/03/2016 08:13, Charles T. Smith wrote: When might a "global" statement be used in the outermost level of a module? Never. Hopefully this http://www.python-course.eu/python3_global_vs_local_variables.php can explain it better than I can :) (whereby, I assume a module is

Re: a clarification on the "global" statement sought

On Fri, Mar 11, 2016 at 7:13 PM, Charles T. Smith <cts.private.ya...@gmail.com> wrote: > When might a "global" statement be used in the outermost level of a module? > > (whereby, I assume a module is equivalent to a python file, correct?) > Usefully? Never. Sim

a clarification on the "global" statement sought

When might a "global" statement be used in the outermost level of a module? (whereby, I assume a module is equivalent to a python file, correct?) TIA for any thoughts. cts -- https://mail.python.org/mailman/listinfo/python-list

Re: Will file be closed automatically in a "for ... in open..." statement?

On Tuesday, February 16, 2016 at 3:39:34 AM UTC-5, jf...@ms4.hinet.net wrote: > I know > > with open('foo.txt') as f: > ...do something... > > will close the file automatically when the "with" block ends. > > I also saw codes in a book: > > for line in open('foo.txt'): >

Re: Will file be closed automatically in a "for ... in open..." statement?

On 2016-02-17 16:51, Steven D'Aprano wrote: > If you want the file to be closed immediately, you must: > > - use a with statement; > > - or explicitly call f.close() I have a lot of pre-"with" code (i.e., Py2.4) that looks like f = open(...) try: do_stuff

Re: Will file be closed automatically in a "for ... in open..." statement?

ly, as all ready explained, but how about this handle = open('foo.txt') for line in handle : ...do something... handle.close() Is that better? As already discussed in this thread, not in the face of an exception inside the loop or some other change of flow control (early "return" sta

Re: Will file be closed automatically in a "for ... in open..." statement?

On 18/02/2016 01:29, jf...@ms4.hinet.net wrote: The "for ... open ..." is definitely not a good design pattern. It opens a file at "for" block but leaves it closed somewhere in the sky. Hardly, as all ready explained, but how about this handle = open('foo.txt') for line in handle :

Re: Will file be closed automatically in a "for ... in open..." statement?

The "for ... open ..." is definitely not a good design pattern. It opens a file at "for" block but leaves it closed somewhere in the sky. > The garbage collector will: > - reclaim the memory used by the object; > - close the file. I suppose (IMO) that the primitive idea of garbage collection

Re: Will file be closed automatically in a "for ... in open..." statement?

claim the memory used by the object; - close the file. BUT there is no promise WHEN the file will be closed. It might be immediately, or it might be when the application shuts down. If you want the file to be closed immediately, you must: - use a with statement; - or explicitly call f.close() o

Re: Will file be closed automatically in a "for ... in open..." statement?

On 02/16/2016 11:04 PM, jf...@ms4.hinet.net wrote: > Thanks for these detailed explanation. Both statements will close file > automatically sooner or later and, when considering the exceptions, "with" is > better. Hope my understanding is right. > > But, just curious, how do you know the "for"

Re: Will file be closed automatically in a "for ... in open..." statement?

On Wed, Feb 17, 2016 at 3:04 PM, wrote: > Thanks for these detailed explanation. Both statements will close file > automatically sooner or later and, when considering the exceptions, "with" is > better. Hope my understanding is right. > > But, just curious, how do you know

Re: Will file be closed automatically in a "for ... in open..." statement?

Thanks for these detailed explanation. Both statements will close file automatically sooner or later and, when considering the exceptions, "with" is better. Hope my understanding is right. But, just curious, how do you know the "for" will do it? I can't find any document about it from every

Re: Will file be closed automatically in a "for ... in open..." statement?

On 2/16/2016 3:39 AM, jf...@ms4.hinet.net wrote: I know with open('foo.txt') as f: ...do something... will close the file automatically when the "with" block ends. I also saw codes in a book: for line in open('foo.txt'): ...do something... Some books were

Re: Will file be closed automatically in a "for ... in open..." statement?

up in the face of exceptions or "direct" departure from the block, such as a "return" statement. I also saw codes in a book: for line in open('foo.txt'): ...do something... but it didn't mention if the file will be closed automatically or not when the "for&q

Re: Will file be closed automatically in a "for ... in open..." statement?

On Tue, Feb 16, 2016 at 7:39 PM, wrote: > I know > > with open('foo.txt') as f: > ...do something... > > will close the file automatically when the "with" block ends. > > I also saw codes in a book: > > for line in open('foo.txt'): > ...do

Will file be closed automatically in a "for ... in open..." statement?

I know with open('foo.txt') as f: ...do something... will close the file automatically when the "with" block ends. I also saw codes in a book: for line in open('foo.txt'): ...do something... but it didn't mention if the file will be closed automatically or not when

Re: Is there a limit to the characters used in a print statement?

On 16/01/2016 13:49, Robert James Liguori wrote: I'm doing a data conversion and all is garbled when I add an extra hundred lines to the print in my for loop. Is there a limit? This will probably get answered under the thread with subject "print size limit" that arrived one minute before

Is there a limit to the characters used in a print statement?

I'm doing a data conversion and all is garbled when I add an extra hundred lines to the print in my for loop. Is there a limit? -- https://mail.python.org/mailman/listinfo/python-list

Re: Is there a limit to the characters used in a print statement?

On Sun, 17 Jan 2016 12:49 am, Robert James Liguori wrote: > I'm doing a data conversion and all is garbled when I add an extra hundred > lines to the print in my for loop. Is there a limit? Is this the same problem as the "print size limit" thread you started one minute earlier, or a different

[issue7944] Use the 'with' statement in conjunction with 'open' throughout test modules

Ezio Melotti added the comment: Thanks for the patch, however I got several errors while trying to apply it, so I ended up backporting d560eece0857 instead. This can be closed now. -- assignee: -> ezio.melotti resolution: -> fixed stage: patch review -> resolved status: open ->

[issue7944] Use the 'with' statement in conjunction with 'open' throughout test modules

Roundup Robot added the comment: New changeset e3763d98c46e by Ezio Melotti in branch '2.7': #7944: close files explicitly in test_tarfile (backport d560eece0857). https://hg.python.org/cpython/rev/e3763d98c46e -- nosy: +python-dev ___ Python tracker

Re: Sqlite pragma statement "locking_mode" set to "EXCLUSIVE" by default

t; >> I would like to have the Sqlite pragma statement "locking_mode" set to >> "EXCLUSIVE" by default (RO database). Does this need to be compiled in? How >> might this be achieved? >> > > You can issue any PRAGA statement you like using the

Re: Sqlite pragma statement "locking_mode" set to "EXCLUSIVE" by default

rogerbinns/apsw Cheers > > On Tue, Sep 22, 2015 at 2:04 PM, Ryan Stuart <ryan.stuart...@gmail.com> > wrote: > >> On Thu, Sep 17, 2015 at 2:24 PM, sol433tt <sol43...@gmail.com> wrote: >> >>> I would like to have the Sqlite pragma statement "locking_mode

Re: Sqlite pragma statement "locking_mode" set to "EXCLUSIVE" by default

On Thu, Sep 17, 2015 at 2:24 PM, sol433tt <sol43...@gmail.com> wrote: > I would like to have the Sqlite pragma statement "locking_mode" set to > "EXCLUSIVE" by default (RO database). Does this need to be compiled in? How > might this be achieved? > You

Re: Sqlite pragma statement "locking_mode" set to "EXCLUSIVE" by default

Is anyone aware of documentation that describes how to compile various sqlite options? On Thu, Sep 17, 2015 at 2:24 PM, sol433tt <sol43...@gmail.com> wrote: > hello > > I would like to have the Sqlite pragma statement "locking_mode" set to > "EXCLUSIVE" by

[issue25202] Windows: with-statement doesn't release file handle after exception on "No space left on device" error

Changes by STINNER Victor <victor.stin...@gmail.com>: -- title: with-statement doesn't release file handle after exception -> Windows: with-statement doesn't release file handle after exception on "No space left on device" error ___

[issue25202] Windows: with-statement doesn't release file handle after exception on "No space left on device" error

Changes by STINNER Victor : -- components: +Windows nosy: +paul.moore, steve.dower, tim.golden, zach.ware ___ Python tracker

[issue25202] with-statement doesn't release file handle after exception

New submission from Lauri Kajan: Hi all, I found out that handle to a file opened with with-statement is not released in all cases. I'm trying to delete a file when space on a disk is filled (0 bit left) by writing this file. I catch the IOError 28 to figure this out. I write the file within

[issue25202] Windows: with-statement doesn't release file handle after exception on "No space left on device" error

STINNER Victor added the comment: @Lauri: What is your Python version? Can you retry your test with Python 3.5? -- nosy: +haypo ___ Python tracker ___

[issue25202] Windows: with-statement doesn't release file handle after exception on "No space left on device" error

eryksun added the comment: Lauri changed the version from 3.4 to 3.2, and I was able to reproduce the problem in 3.2.5: C:\Temp>py -3.2 --version Python 3.2.5 C:\Temp>py -3.2 nospace.py removing fill.txt Traceback (most recent call last): File "nospace.py", line 8, in

[issue25202] Windows: with-statement doesn't release file handle after exception on "No space left on device" error

Changes by Zachary Ware : -- superseder: -> file descriptor not being closed with context manager on IOError when device is full ___ Python tracker

[issue25202] Windows: with-statement doesn't release file handle after exception on "No space left on device" error

Lauri Kajan added the comment: Thanks for these. I'll see what I could do to upgrade our python version. Sorry for not finding the old issue. Didn't find the right search terms. -- ___ Python tracker

[issue25202] Windows: with-statement doesn't release file handle after exception on "No space left on device" error

Changes by Lauri Kajan : -- versions: +Python 3.2 -Python 3.4 ___ Python tracker ___

[issue25202] Windows: with-statement doesn't release file handle after exception on "No space left on device" error

eryksun added the comment: See issue 16597. This wasn't fixed for 3.2, so it won't close the file if flush() fails. You'll either have to work around this or upgrade to 3.3+. -- nosy: +eryksun resolution: -> out of date stage: -> resolved status: open -> closed

[issue25175] Documentation-Tkinter wrong statement

Martin Panter added the comment: The problem here is you have quoted the Python 3 documentation (see in the title, or the version switcher at the top), when you are presumably using Python 2. The module changed name to lowercase in Python 3. -- nosy: +martin.panter

[issue25175] Documentation-Tkinter wrong statement

New submission from Rishit Bansal: The statement required to check whether Tkinter is installed on a system is mentioned in the documentation as python -m tkinter , whereas it is supposed to be python -m Tkinter (with a big 't'). Please correct this error on the documentation here:https

Sqlite pragma statement "locking_mode" set to "EXCLUSIVE" by default

hello I would like to have the Sqlite pragma statement "locking_mode" set to "EXCLUSIVE" by default (RO database). Does this need to be compiled in? How might this be achieved? There is some performance to be gained. I have a number of python scripts, and don't want to alter

[issue16864] sqlite3.Cursor.lastrowid isn't populated when executing a SQL REPLACE statement

Changes by Gerhard Häring g...@ghaering.de: -- assignee: - ghaering ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16864 ___ ___ Python-bugs-list

[issue21718] sqlite3 cursor.description seems to rely on incomplete statement parsing for detection

Changes by R. David Murray rdmur...@bitdance.com: -- stage: commit review - test needed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21718 ___

[issue21718] sqlite3 cursor.description seems to rely on incomplete statement parsing for detection

R. David Murray added the comment: Attached is the patch ported to python2.7. However, the test doesn't fail for me before I apply (compile) the fix. -- Added file: http://bugs.python.org/file40184/f67fa9c898a4713850e16934046f0fe2cba8c44c.patch

[issue24795] Make event loops with statement context managers

Guido van Rossum added the comment: My worry is that the context manager will make people believe it's a good pattern to create an event loop just to make one call. If tests violate this pattern, add a context manager helper function to test_utils.py. On Thu, Aug 6, 2015 at 2:57 AM, Martin

[issue24795] Make event loops with statement context managers

STINNER Victor added the comment: +1 for me. Asyncio examples already have this try/finally pattern. I already proposed to support context manager some months ago. Guido, I don't understand your point. Usually the main function id loop.run_until_complete/.run_forever. That's all. It doesn't

[issue24795] Make event loops with statement context managers

loops with statement context managers type: enhancement versions: Python 3.5 Added file: http://bugs.python.org/file40129/patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24795

[issue24795] Make event loops with statement context managers

Mathias Fröjdman added the comment: (Just noticed http://bugs.python.org/issue19860, which I originally failed to notice when just searching for asyncio loop and not context manager) Anyway, in recent Python/asyncio versions, failing to close the event loop before exiting whole the process

[issue24795] Make event loops with statement context managers

Guido van Rossum added the comment: This seems the wrong idea to me. Event loops should be long-lived, so the context manager would ideally see very little use. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24795

[issue24129] Incorrect (misleading) statement in the execution model documentation

Roundup Robot added the comment: New changeset 94e215a5e24b by Nick Coghlan in branch '3.4': Issue #24129: Clarify reference docs for name resolution. https://hg.python.org/cpython/rev/94e215a5e24b New changeset 5e4d21311772 by Nick Coghlan in branch '3.5': Merge issue #24129 from 3.4

[issue24129] Incorrect (misleading) statement in the execution model documentation

Nick Coghlan added the comment: I merged Ivan's latest patch to 3.4/3.5/default. We're unlikely to ever be able to make these docs completely intuitive (as name resolution is genuinely complex), but Ivan's revisions at least mean we're no longer assuming readers know how the name resolution

[issue24129] Incorrect (misleading) statement in the execution model documentation

Nick Coghlan added the comment: I merged Ivan's latest patch to 3.4/3.5/default. We're unlikely to ever be able to make these docs completely intuitive (as name resolution is genuinely complex), but Ivan's revisions at least mean we're no longer assuming readers know how the name resolution

[issue24129] Incorrect (misleading) statement in the execution model documentation

Changes by Nick Coghlan ncogh...@gmail.com: -- Removed message: http://bugs.python.org/msg248043 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24129 ___

[issue24129] Incorrect (misleading) statement in the execution model documentation

Nick Coghlan added the comment: The issue tracker was having issues and didn't automatically register the commits. Links: 3.4: https://hg.python.org/cpython/rev/94e215a5e24b 3.5: https://hg.python.org/cpython/rev/5e4d21311772 default: https://hg.python.org/cpython/rev/e75881393cf2 --

[issue21718] sqlite3 cursor.description seems to rely on incomplete statement parsing for detection

Robert Collins added the comment: @Gerhard would you like that ported to cPython for you? @Tom - I think that if the patch applies to 2.7.x we should apply it there since its very unlikely to break non-buggy code. -- nosy: +rbcollins versions: +Python 3.6

<    5   6   7   8   9   10   11   12   13   14   >