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
Marko Rauhamaa :
> Peter Otten <__pete...@web.de>:
>
>> Marko Rauhamaa wrote:
>>>try:
>>>f = open("xyz")
>>>except FileNotFoundError:
>>>...[B]...
>>>try:
>>>...[A]...
>>>finally:
>>>f.close()
>>
>> What's the problem with spelling the above
>>
>> tr
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
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 below
>
> try:
>
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
On Monday 28 November 2016 17:09, Ganesh Pal wrote:
> Dear Python friends,
>
> Any suggestion on how to add exception and make the below program look
> better , I am using Python 2.7 and Linux
>
>
>
>
22 matches
Mail list logo
