On 2016-12-02, Marko Rauhamaa wrote:
> Grant Edwards :
>> In general CISC processors like x86, AMD64, 68K have read-modify-write
>> instructions that allow you to increment a memory location or
>> set/clear a bit in memory with a single instruction:
>>
>> INC.W [R0]# increment memory word
Grant Edwards :
> In general CISC processors like x86, AMD64, 68K have read-modify-write
> instructions that allow you to increment a memory location or
> set/clear a bit in memory with a single instruction:
>
> INC.W [R0]# increment memory word whose addr is in register R0
The x86 instru
On 12/01/2016 08:39 PM, Ned Batchelder wrote:
> On Thursday, December 1, 2016 at 7:26:18 PM UTC-5, DFS wrote:
>> How is it possible that the 'if' portion runs, then 44/100,000ths of a
>> second later my process yields to another process which deletes the
>> file, then my process continues.
>
> A
On 2016-12-02, Steve D'Aprano wrote:
> I'm not an expert on the low-level hardware details, so I welcome
> correction, but I think that you can probably expect that the OS can
> interrupt code execution between any two CPU instructions.
Yep, mostly. Some CPUs have "lock" features that allow two
On Fri, 2 Dec 2016 11:26 am, DFS wrote:
>> For most programs, yes, it probably will never be a problem to check
>> for existence, and then assume that the file still exists. But put that
>> code on a server, and run it a couple of million times, with dozens of
>> other processes also manipulating
On Fri, 2 Dec 2016 11:26 am, DFS wrote:
> On 12/01/2016 06:48 PM, Ned Batchelder wrote:
>> On Thursday, December 1, 2016 at 2:31:11 PM UTC-5, DFS wrote:
>>> After a simple test below, I submit that the above scenario would never
>>> occur. Ever. The time gap between checking for the file's exist
On Thursday, December 1, 2016 at 7:26:18 PM UTC-5, DFS wrote:
> On 12/01/2016 06:48 PM, Ned Batchelder wrote:
> > On Thursday, December 1, 2016 at 2:31:11 PM UTC-5, DFS wrote:
> >> After a simple test below, I submit that the above scenario would never
> >> occur. Ever. The time gap between check
On Thursday, December 1, 2016 at 2:31:11 PM UTC-5, DFS wrote:
> After a simple test below, I submit that the above scenario would never
> occur. Ever. The time gap between checking for the file's existence
> and then trying to open it is far too short for another process to sneak
> in and dele
On Wed, 30 Nov 2016 05:35 pm, DFS wrote:
> On 11/29/2016 10:20 PM, Steven D'Aprano wrote:
>> On Wednesday 30 November 2016 10:59, woo...@gmail.com wrote:
>>
>>> If you want to do something only if the file exists (or does not), use
>>> os.path.isfile(filename)
>>
>> No, don't do that. Just because
;>>finally:
>>>f.close()
>>
>> What's the problem with spelling the above
>>
>> try:
>> f = open(...)
>> except FileNotFoundError:
>> ...
>> with f:
>> ...
>
> Nothing.
Well, in general, the
On Wednesday 30 November 2016 10:59, woo...@gmail.com wrote:
> If you want to do something only if the file exists (or does not), use
> os.path.isfile(filename)
No, don't do that. Just because the file exists, doesn't mean that you have
permission to read or write to it.
Worse, the code is vuln
On Tue, 29 Nov 2016 at 23:59 wrote:
> If you want to do something only if the file exists (or does not), use
> os.path.isfile(filename)
>
This opens you up to a potential race condition (and has potential security
implications, depending on the application), as you're using LBYL[0].
If you want
If you want to do something only if the file exists (or does not), use
os.path.isfile(filename)
--
https://mail.python.org/mailman/listinfo/python-list
Peter Otten <__pete...@web.de>:
> Marko Rauhamaa wrote:
>
>> However, I think the real answer is that you shouldn't mix the "with"
>> construct with exception handling. Instead you should write:
>>
>>try:
>>f = open("xyz")
>>except FileNotFoundError:
>>...[B]...
>>try:
Marko Rauhamaa wrote:
> However, I think the real answer is that you shouldn't mix the "with"
> construct with exception handling. Instead you should write:
>
>try:
>f = open("xyz")
>except FileNotFoundError:
>...[B]...
>try:
>...[A]...
>finally:
>f
Steven D'Aprano :
> There is no need to catch the exception if you're not going to do
> anything with it.
Correct. However, the question of the subject line is still a good one.
See:
try:
with open("xyz") as f:
...[A]...
except FileNotFoundError:
...[B]...
The
Thanks Steve I got what you were trying to explain , nice learning from
this conversation , what I was really doing wrong I had broken down my huge
code into a simple program and had missed out returning False.
On Tue, Nov 29, 2016 at 11:01 AM, Steven D'Aprano <
steve+comp.lang.pyt...@pearwood.
On Tuesday 29 November 2016 02:18, Ganesh Pal wrote:
> On Mon, Nov 28, 2016 at 1:16 PM, Steven D'Aprano <
> steve+comp.lang.pyt...@pearwood.info> wrote:
>
>>
>>
>> There is no need to return True. The function either succeeds, or it
>> raises an
>> exception, so there is no need to return any val
-
What will be the best way to catch the exception in the above program ?
Can we replace both the with statement in the above program with something
like below
try:
for i in range(1000):
with open(os.path.join(QA_TEST_DIR,"filena
Ganesh Pal wrote:
> I am using Python 2.7 and Linux
As a rule of thumb¹, use at least Python 3.3 for new programs.
> What will be the best way to catch the exception in the above program ?
> Can we replace both the with statement in the above program with
> something like be
On 11/28/2016 08:18 AM, Ganesh Pal wrote:
> On Mon, Nov 28, 2016 at 1:16 PM, Steven D'Aprano <
> steve+comp.lang.pyt...@pearwood.info> wrote:
>
>>
>>
>> There is no need to return True. The function either succeeds, or it
>> raises an
>> exception, so there is no need to return any value at all.
>
On Mon, Nov 28, 2016 at 1:16 PM, Steven D'Aprano <
steve+comp.lang.pyt...@pearwood.info> wrote:
>
>
> There is no need to return True. The function either succeeds, or it
> raises an
> exception, so there is no need to return any value at all.
>
>
I returned True here ,because based on the result
at can't be opened:
def create_files_append():
"""Docstring"""
os.makedirs(QA_TEST_DIR)
# Create few files and write something
for i in range(1000):
try:
with open(os.path.join(QA_TEST_DIR,"filename%d" %i),'w
-
---
What will be the best way to catch the exception in the above program ?
Can we replace both the with statement in the above program with something
like below
try:
for i in range(1000):
with open(os.path.join(QA_TEST_DIR,"filename%d
On Saturday, March 28, 2015 at 9:51:50 PM UTC+5:30, Rustom Mody wrote:
> So if the VB model is followed, it is purely a syntactic (ie not type-related)
> question whether an identifier is an adorned variable or an attribute of
> something else. The preceding dot is the disambiguator.
Uh... UN-ado
>
> > In VB one can do:
> >
> > with self
> > .attr1 = field1
> > .attr2 = field2
> >
> > (or something like that -- dont exactly remember the syntax)
>
>
> Pascal is another language with a construct like that, and there's a FAQ for
t-python-have-a-with-statement-for-attribute-assignments
>>> help('FAQ')
no Python documentation found for 'FAQ'
Less than useless, now what?
Did you try googling?
help("google")
Fails in just the same way. Do I raise a bug report on the issue trac
On Sat, 28 Mar 2015 11:26 pm, Mark Lawrence wrote:
> On 28/03/2015 06:26, Steven D'Aprano wrote:
>>Pascal is another language with a construct like that, and there's a FAQ
>>for it:
>>
>>
https://docs.python.org/2/faq/design.html#why-doesn-t-python-have-a-wit
that -- dont exactly remember the syntax)
Pascal is another language with a construct like that, and there's a FAQ for
it:
https://docs.python.org/2/faq/design.html#why-doesn-t-python-have-a-with-statement-for-attribute-assignments
c:\cpython\PCbuild>python
Python 3.4.3 (v3.4.3:9b73f1c
one can do:
>>
>> with self
>> .attr1 = field1
>> .attr2 = field2
>>
>> (or something like that -- dont exactly remember the syntax)
>
>
> Pascal is another language with a construct like that, and there's a FAQ for
> it:
>
> https://docs.pyth
g like that -- dont exactly remember the syntax)
Pascal is another language with a construct like that, and there's a FAQ for
it:
https://docs.python.org/2/faq/design.html#why-doesn-t-python-have-a-with-statement-for-attribute-assignments
--
Steven
--
https://mail.python.org/mailman/listinfo/python-list
Ian Kelly wrote:
On Thu, Apr 19, 2012 at 3:33 PM, Terry Reedy wrote:
On 4/19/2012 1:15 PM, Kiuhnm wrote:
A with statement is not at the module level only if it appears inside a
function definition or a class definition.
This is true, I believe, of all statements.
Am I forgetting something
On Thu, Apr 19, 2012 at 3:33 PM, Terry Reedy wrote:
> On 4/19/2012 1:15 PM, Kiuhnm wrote:
>>
>> A with statement is not at the module level only if it appears inside a
>> function definition or a class definition.
>
>
> This is true, I believe, of all statements.
On 4/19/2012 1:15 PM, Kiuhnm wrote:
A with statement is not at the module level only if it appears inside a
function definition or a class definition.
This is true, I believe, of all statements.
Am I forgetting something?
Comprehensions (in Py3) and lambda expressions also introduce new
On 4/19/2012 20:02, Jacob MacDonald wrote:
On Thursday, April 19, 2012 10:15:23 AM UTC-7, Kiuhnm wrote:
A with statement is not at the module level only if it appears inside a
function definition or a class definition.
Am I forgetting something?
Kiuhnm
That sounds about right to me. However
On Thursday, April 19, 2012 10:15:23 AM UTC-7, Kiuhnm wrote:
> A with statement is not at the module level only if it appears inside a
> function definition or a class definition.
> Am I forgetting something?
>
> Kiuhnm
That sounds about right to me. However, I haven't rea
streamlined 'with' syntax- abusing the for loop might just
>be confusing. The with statement is also a good fit because the caching
>strategy does have to atomically acquire, create and release the appropriate
>locks. With this statement the cached CLI wrappers can be called
abusing the for loop might just be
confusing. The with statement is also a good fit because the caching strategy
does have to atomically acquire, create and release the appropriate locks.
With this statement the cached CLI wrappers can be called from simultaneously
from different scripts and s
On 2/28/2012 5:12 PM, Prasad, Ramit wrote:
Craig Yoshioka wrote:
I see that there was previously a PEP to allow the with statement to skip the
enclosing block... this was shot down, and I'm trying to think of the most
elegant alternative. [..]
I would have really liked:
with cachingco
On Tue, Feb 28, 2012 at 1:04 PM, Craig Yoshioka wrote:
>
> I see that there was previously a PEP to allow the with statement to skip the
> enclosing block... this was shot down, and I'm trying to think of the most
> elegant alternative.
> The best I've found is
Craig Yoshioka wrote:
>I see that there was previously a PEP to allow the with statement to skip the
>enclosing block... this was shot down, and I'm trying to think of the most
>elegant alternative. [..]
>I would have really liked:
>with cachingcontext(x):
># creat
I see that there was previously a PEP to allow the with statement to skip the
enclosing block... this was shot down, and I'm trying to think of the most
elegant alternative.
The best I've found is to abuse the for notation:
for _ in cachingcontext(x):
# create cached resources her
On 12/16/2011 8:26 PM, Steven D'Aprano wrote:
On Fri, 16 Dec 2011 17:05:57 -0500, Terry Reedy wrote:
It is am important distinction [unbound versus bound]
It is not an important distinction, and I am not confusing the two.
So we agree on the distinction but disagree on its importance.
Let
On Fri, 16 Dec 2011 15:26:30 -0800, Ethan Furman wrote:
> Terry Reedy wrote:
>> On 12/16/2011 4:22 AM, Steven D'Aprano wrote:
[...]
> I think you two are in violent agreement as far as how Python is
> functioning, and the conflict is in the names given to the various
> pieces... I think a glossar
On Fri, 16 Dec 2011 17:05:57 -0500, Terry Reedy wrote:
> On 12/16/2011 4:22 AM, Steven D'Aprano wrote:
>> On Thu, 15 Dec 2011 19:39:17 -0500, Terry Reedy wrote: [...]
>>
>> After reading your post, I think I have worked out where our
>> disagreement lines: you think that bound methods and instance
Ethan Furman wrote:
Terry Reedy wrote:
On 12/16/2011 4:22 AM, Steven D'Aprano wrote:
On Thu, 15 Dec 2011 19:39:17 -0500, Terry Reedy wrote:
[...]
After reading your post, I think I have worked out where our
disagreement
lies: you think that bound methods and instance methods are not the same
Terry Reedy wrote:
On 12/16/2011 4:22 AM, Steven D'Aprano wrote:
On Thu, 15 Dec 2011 19:39:17 -0500, Terry Reedy wrote:
[...]
After reading your post, I think I have worked out where our disagreement
lies: you think that bound methods and instance methods are not the same
thing,
Do you agree
On 12/16/2011 4:22 AM, Steven D'Aprano wrote:
On Thu, 15 Dec 2011 19:39:17 -0500, Terry Reedy wrote:
[...]
After reading your post, I think I have worked out where our disagreement
lines: you think that bound methods and instance methods are not the same
thing,
Do you agree that an unbound met
On Thu, 15 Dec 2011 19:39:17 -0500, Terry Reedy wrote:
[...]
After reading your post, I think I have worked out where our disagreement
lines: you think that bound methods and instance methods are not the same
thing, and that a function defined inside a class is different from a
function outside
On Thu, 15 Dec 2011 05:35:55 -0800, Steve Howell wrote:
> For the special methods like __enter__ and __exit__, the tricky part
> isn't understanding what would happen once the methods were called; the
> tricky part is getting them to be called in the first place, if they
> were not declared inside
On 12/15/2011 12:01 AM, Steven D'Aprano wrote:
On Wed, 14 Dec 2011 18:13:36 -0500, Terry Reedy wrote:
On 12/14/2011 3:01 AM, Steven D'Aprano wrote:
On Wed, 14 Dec 2011 01:29:13 -0500, Terry Reedy wrote:
To complement what Eric says below: The with statement is looking for
a
MRAB wrote:
To give an analogy, it is like defining mammals as "hairy animals which
give birth to live young", which is correct for all mammals except for
monotremes, which are mammals which lay eggs.
Or the naked mole-rat. Or cetaceans (whales).
The way I understand it, the main characteris
On Dec 14, 9:01 pm, Steven D'Aprano wrote:
> [...]
> So what are methods? In Python, methods are wrappers around functions
> which automatically pass the instance to the inner function object. Under
> normal circumstances, you create methods by declaring functions inside a
> class, but that's not
On Thu, 15 Dec 2011 05:01:21 +, Steven D'Aprano wrote:
>> From the Python glossary:
>> "method: A function which is defined inside a class body."
>>
>> That is actually a bit too narrow, as a function can be added to the
>> class after it is defined. But the point then is that it is treated
ry Reedy wrote:
>>>>
>>>>> To complement what Eric says below: The with statement is looking
>>>>> for an instance *method*, which by definition, is a function
>>>>> attribute of a *class* (the class of the context manager) that
>>&
On 15/12/2011 05:01, Steven D'Aprano wrote:
On Wed, 14 Dec 2011 18:13:36 -0500, Terry Reedy wrote:
On 12/14/2011 3:01 AM, Steven D'Aprano wrote:
On Wed, 14 Dec 2011 01:29:13 -0500, Terry Reedy wrote:
To complement what Eric says below: The with statement is looking for
a
On Wed, 14 Dec 2011 18:13:36 -0500, Terry Reedy wrote:
> On 12/14/2011 3:01 AM, Steven D'Aprano wrote:
>> On Wed, 14 Dec 2011 01:29:13 -0500, Terry Reedy wrote:
>>
>>> To complement what Eric says below: The with statement is looking for
>>> an instan
On 12/14/2011 3:01 AM, Steven D'Aprano wrote:
On Wed, 14 Dec 2011 01:29:13 -0500, Terry Reedy wrote:
To complement what Eric says below: The with statement is looking for an
instance *method*, which by definition, is a function attribute of a
*class* (the class of the context manager)
On Wed, Dec 14, 2011 at 12:14 PM, Lie Ryan wrote:
> On 12/15/2011 03:56 AM, Eric Snow wrote:
>>
>> On Tue, Dec 13, 2011 at 11:05 PM, Eric Snow
>> wrote:
>>
>> If you want to be more dynamic about it you can do it, but it involves
>> black magic. Chances are really good that being explicit throug
On 12/15/2011 03:56 AM, Eric Snow wrote:
On Tue, Dec 13, 2011 at 11:05 PM, Eric Snow wrote:
If you want to be more dynamic about it you can do it, but it involves
black magic. Chances are really good that being explicit through your
class definition is the right approach.
Note that the black
On Dec 14, 12:01 am, Steven D'Aprano wrote:
> [...]
>
> So the normal lookup rules that apply to data attributes, namely
> instance, then class, then superclasses, also applies to methods in
> Python. In languages that don't allow that sort of thing, like Java, you
> need to use convoluted design
ve
>> foo.__exit__ = foo.goodbye
>> foo.__exit__() # outputs goodbye Steve
>>
>> with foo: # fails with AttributeError: __exit__
>> print("doing stuff")
>>
>> I am dynamically adding an attribute __exit__ to the variable foo,
>> which works fine
On Thursday, December 15, 2011 12:08:32 AM UTC+8, 8 Dihedral wrote:
> On Wednesday, December 14, 2011 4:01:24 PM UTC+8, Steven D'Aprano wrote:
> > On Wed, 14 Dec 2011 01:29:13 -0500, Terry Reedy wrote:
> >
> > > To complement what Eric says below: The wit
On Wednesday, December 14, 2011 4:01:24 PM UTC+8, Steven D'Aprano wrote:
> On Wed, 14 Dec 2011 01:29:13 -0500, Terry Reedy wrote:
>
> > To complement what Eric says below: The with statement is looking for an
> > instance *method*, which by definition, is a function at
quot;doing stuff")
>
> I am dynamically adding an attribute __exit__ to the variable foo,
> which works fine when I call it directly, but it fails when I try to
> use foo as the expression in the with statement. Here is the full
> output:
>
>> python3 with.coffee
&g
On Wed, 14 Dec 2011 01:29:13 -0500, Terry Reedy wrote:
> To complement what Eric says below: The with statement is looking for an
> instance *method*, which by definition, is a function attribute of a
> *class* (the class of the context manager) that takes an instance of the
> class
ce*.
with foo: # fails with AttributeError: __exit__
print("doing stuff")
I am dynamically adding an attribute __exit__ to the variable foo,
which works fine when I call it directly, but it fails when I try to
use foo as the expression in the with statement. Here is the full
outp
__exit__
> print("doing stuff")
>
> I am dynamically adding an attribute __exit__ to the variable foo,
> which works fine when I call it directly, but it fails when I try to
> use foo as the expression in the with statement. Here is the full
> output:
>
>&
ctly, but it fails when I try to
use foo as the expression in the with statement. Here is the full
output:
> python3 with.coffee
goodbye Steve
goodbye Steve
Traceback (most recent call last):
File "with.coffee", line 17, in
with foo: # fails with AttributeError:
Attr
Thomas Rachel wrote:
> Am 03.08.2011 04:15 schrieb Steven D'Aprano:
[...]
> > but to me that looks badly wrong. Surely the spam context manager
> > object will exit after the first iteration, and always raise an
> > exception on the second? But I don't quite understand context
> > managers eno
Am 03.08.2011 04:15 schrieb Steven D'Aprano:
> I'm not greatly experienced with context managers and the with
> statement, so I would like to check my logic.
>
> Somebody (doesn't matter who, or where) stated that they frequently
> use this idiom:
>
> spam =
On Wed, 03 Aug 2011 12:15:44 +1000, Steven D'Aprano wrote:
> I'm not greatly experienced with context managers and the with statement, so
> I would like to check my logic.
>
> Somebody (doesn't matter who, or where) stated that they frequently use this
> idiom:
>
On Tue, Aug 2, 2011 at 10:15 PM, Steven D'Aprano
wrote:
> I'm not greatly experienced with context managers and the with statement, so
> I would like to check my logic.
>
> Somebody (doesn't matter who, or where) stated that they frequently use this
> idiom:
>
I'm not greatly experienced with context managers and the with statement, so
I would like to check my logic.
Somebody (doesn't matter who, or where) stated that they frequently use this
idiom:
spam = MyContextManager(*args)
for ham in my_iter:
with spam:
# do stuff
but
On Saturday 11 September 2010, it occurred to Lawrence D'Oliveiro to exclaim:
> In message , MRAB
>
> wrote:
> > On 08/09/2010 19:07, Georg Brandl wrote:
> >> Thus spake the Lord: Thou shalt indent with four spaces. No more, no
> >> less. Four shall be the number of spaces thou shalt indent, and t
In message , MRAB
wrote:
> On 08/09/2010 19:07, Georg Brandl wrote:
>
>> Thus spake the Lord: Thou shalt indent with four spaces. No more, no
>> less. Four shall be the number of spaces thou shalt indent, and the
>> number of thy indenting shall be four. Eight shalt thou not indent,
>> nor either
On 09/09/2010 17:07, Mark Lawrence wrote:
On 08/09/2010 20:30, MRAB wrote:
On 08/09/2010 19:07, Georg Brandl wrote:
Thus spake the Lord: Thou shalt indent with four spaces. No more, no
less. Four shall be the number of spaces thou shalt indent, and the
number of thy indenting shall be four. Eig
On 08/09/2010 20:30, MRAB wrote:
On 08/09/2010 19:07, Georg Brandl wrote:
Thus spake the Lord: Thou shalt indent with four spaces. No more, no
less. Four shall be the number of spaces thou shalt indent, and the
number of thy indenting shall be four. Eight shalt thou not indent,
nor either indent
On Thu, Sep 9, 2010 at 11:20 AM, Fritz Loseries wrote:
> Hi,
>
> I do not know how to subject my problem in a better way.
>
> I have the following statement:
>
> return [ dict(x1 = elem.x1, x2 = elem.x2, x3 = elem.x3,)
> for elem in method(in_values)
> ]
>
> How can
Hi,
I do not know how to subject my problem in a better way.
I have the following statement:
return [ dict(x1 = elem.x1, x2 = elem.x2, x3 = elem.x3,)
for elem in method(in_values)
]
How can I transform it to an explicit description:
result = ...
return
On 08/09/2010 19:07, Georg Brandl wrote:
Thus spake the Lord: Thou shalt indent with four spaces. No more, no
less. Four shall be the number of spaces thou shalt indent, and the
number of thy indenting shall be four. Eight shalt thou not indent,
nor either indent thou two, excepting that thou the
On Sun, Feb 21, 2010 at 3:21 PM, John Nagle wrote:
> nobrowser wrote:
>>
>> Hi. The with statement is certainly nifty. The trouble is, the
>> *only* two documented examples how it can be used with the library
>> classes are file objects (which I use all the time)
nobrowser wrote:
Hi. The with statement is certainly nifty. The trouble is, the
*only* two documented examples how it can be used with the library
classes are file objects (which I use all the time) and thread locks
which I almost never use. Yet there are many, many classes in the
library
On 2/19/2010 2:18 AM, nobrowser wrote:
Hi. The with statement is certainly nifty. The trouble is, the
*only* two documented examples how it can be used with the library
classes are file objects (which I use all the time) and thread locks
which I almost never use. Yet there are many, many
On 2010-02-19 01:18 AM, nobrowser wrote:
Hi. The with statement is certainly nifty. The trouble is, the
*only* two documented examples how it can be used with the library
classes are file objects (which I use all the time) and thread locks
which I almost never use. Yet there are many, many
nobrowser wrote:
> Yet there are many, many classes in the
> library whose use would be more elegant and readable if the with
> statement could be employed. Start with the connection objects in
> httplib and you can probably come up with 10 others easily. Maybe it
> is the ca
Hi. The with statement is certainly nifty. The trouble is, the
*only* two documented examples how it can be used with the library
classes are file objects (which I use all the time) and thread locks
which I almost never use. Yet there are many, many classes in the
library whose use would be
I have just discovered that the syntax
with file(name, 'w') as f:
do_something(f)
does not close the file at the end of the with statement! On the
contrary
with open(name, 'w') as f:
do_something(f)
works fine. The docs say "When opening a file, it’s preferable
On Dec 10, 11:59 am, Christian Heimes wrote:
> In Python 2.5 you have to implement your own __enter__ and __exit__
> methods if you subclass from file. The file.__exit__ function doesn't
> call f.close().
Yes, that was my problem.
--
http://mail.python.org/mailman/listinfo/python-list
;)
>> test(outf)
>>
>> Which Python do you use?
>>
>> Diez
>
> Python 2.5, but it could be an artifact of the way I am looking if a
> file is closed.
> I have subclassed the file builtin, added a .close method and it was
> not called by the
> "with&qu
Michele Simionato wrote:
> Python 2.5, but it could be an artifact of the way I am looking if a
> file is closed.
> I have subclassed the file builtin, added a .close method and it was
> not called by the
> "with" statement. This during debugging, but now I have found an
;> test(outf)
>>
>> Which Python do you use?
>>
>> Diez
>
> Python 2.5, but it could be an artifact of the way I am looking if a
> file is closed.
The above ran on python2.5 for me, no hitch.
> I have subclassed the file builtin, added a .close method and
gt;
> Diez
Python 2.5, but it could be an artifact of the way I am looking if a
file is closed.
I have subclassed the file builtin, added a .close method and it was
not called by the
"with" statement. This during debugging, but now I have found another
reason to explain why I was
ru
Michele Simionato wrote:
> I have just discovered that the syntax
>
> with file(name, 'w') as f:
>do_something(f)
>
> does not close the file at the end of the with statement! On the
> contrary
>
> with open(name, 'w') as f:
>do_someth
Michele Simionato wrote:
> I have just discovered that the syntax
>
> with file(name, 'w') as f:
>do_something(f)
>
> does not close the file at the end of the with statement! On the
> contrary
>
> with open(name, 'w') as f:
>do_someth
On 2009-11-23, Terry Reedy wrote:
> Neil Cerutti wrote:
>> Unfortunately, the new "nested" with statement (which I also read
>> about today) forces me into this anti-idiom. When replacing an
>> appearance of contextlib.nested with the 3K with statement, I
>&g
cter labeled an
> anti-idiom. I already generally avoided it, so I just nodded.
>
> Unfortunately, the new "nested" with statement (which I also read
> about today) forces me into this anti-idiom. When replacing an
> appearance of contextlib.nested with the 3K with statement
lly avoided it, so I just nodded.
Unfortunately, the new "nested" with statement (which I also read
about today) forces me into this anti-idiom. When replacing an
appearance of contextlib.nested with the 3K with statement, I
ended up with an unexpected syntax error.
with (open(roster_pa
idiom. I already generally avoided it, so I just nodded.
>
> Unfortunately, the new "nested" with statement (which I also read
> about today) forces me into this anti-idiom. When replacing an
> appearance of contextlib.nested with the 3K with statement, I
> ended up
st nodded.
Unfortunately, the new "nested" with statement (which I also read
about today) forces me into this anti-idiom. When replacing an
appearance of contextlib.nested with the 3K with statement, I
ended up with an unexpected syntax error.
with (open(roster_path, 'r') as roster
1 - 100 of 124 matches
Mail list logo
