Modify the PATHEXT environment variable to include .py;
For example the default one on Windows XP is:
PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;
Modify it so it says:
PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.py
Now you can run python programs from your c
> But that perspective is not directly relevant to *your* topic line. When
> you make a claim that os.stat is 'broken' and bugged, you are making a
> claim about the *programmer* experience -- in particular, experiencing a
> discrepancy between performance and reasonable expectation based on the
>
I have tried (unsuccessfully) to get you to view things from the end user
perspective.
I wish that you would consider looking at what the end user sees because
that is what really matters.
Without end users we would not need to develop software would we?
This entire conversation was VERY nicel
Perspective is often the source of problems with communication.
You view timezones and DST as offsets from GMT. I understand and respect
that perspective.
When I think of timezones and DST I think of the timezone setting and the
DST setting in Windows.
These settings are two separate settings
There is a conflict with the answers that you and Terry have given.
The original issue I raised was that I Python 2.5.1 and Windows did not have
the same textual represenation for a localize date.
You have stood true to the statements that Python 2.5.1 is correct and that
previous versions were
""Martin v. Löwis"" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>> It appears that you may have missed part of my tests. Sorry it was such
>> a
>> long reply but I was trying to provide a lot of detail so that others had
>> a
>> clear understanding of what was going on.
>
> Ple
> Please understand that it is *extremely* tedious to follow your
> messages. It would have been much better if they had been short and
> to the point.
Sometimes it seems that it is impossible to please people.
When messages are short then people complain that they did not get
sufficient details
> | > You are misinterpreting what you are seeing. Windows is not claiming
> | > that the modification time changes when DST starts. Instead, it is
> | > claiming that the *same* time now has a *different* textual
> | > representation, because the computer now has moved to a different
> | > time z
""Martin v. Löwis"" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>> The short explaination of this issue is that the timestamp shown when
>> you do a dir on a file that is on an NTFS volume changes by an hour
>> when DST starts and also when DST ends, even though the file has NOT
>>
> It's not clear whether it's an error, however, localtime() does
> something different from what dir does.
Hi Martin,
First off thank you for spending your time to investigate this bug with me.
Thanks for pointing out the issue with Windows XP caching the access
timestamps,
I was not aware of
>"Neil Hodgson" <[EMAIL PROTECTED]> wrote in message
>news:[EMAIL PROTECTED]
>
>One problem I have seen is that Windows Explorer and its File
> Properties sheet sometimes cache time values. Even closing and reopening
> the properties can show the old value. dir should always read the times
Hi Terry,
> If, when discussion is concluded here, you still think there is a bug,
> file
> a report on SF. Make a concise summary in the comments section and attach
> a file with the output from your experiments. You may have to submit the
> attachment separately after first submitting the rep
""Martin v. Löwis"" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>> I created a file and specifically set the created date, last accessed
>> date
>> and last write date to
>>
>> 01/02/2003 12:34:56
>
> How did you do that?
I used a "touch" utility to set the dates but let's tr
Hi Martin,
Please see my response to Tony Meyer titled "Python 2.5.1 broke os.stat
module"
I provide a sample program that demonstrates that the results that are
produced by the Python 2.4.2 os.stat module ALWAYS match the results that
Windows Explorer displays as well as the results of the di
ccess_match_count)
print 'Did NOT Match Access Date: %s' % (access_no_match_count)
print
print 'Matched Write Date : %s' % (write_match_count)
print 'Did NOT Match Write Date : %s' % (write_no_match_count)
print
"Tony Meyer" <[EMAIL
I just upgraded from Python 2.4.2 to Python 2.5.1 and have found some
unexpected behavior that appears to be a bug in the os.stat module.
My OS is Windows XP SP2 + all updates.
I have several programs that have worked flawlessly on all previous Python
versions for years and they are now produc
ata, followed by 4868 bytes of nulls.
I did a second test where the actual data size was 11,109 bytes. In that
case pyodbc returned a value that was 22,218 bytes long. The first 11,109
bytes are the real data, followed by 11,109 null bytes.
This seems to confirm the bug.
"Joe Salmeri&
Thanks, I reported them there first and then posted here in case they
monitor the forum more frequently and so others would be aware of the
problems found.
Joe
"Gabriel Genellina" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> En Fri, 18 May 2007 20:48:49
Thank you for your response but this is not an Access problem.
The exact same code using mx.ODBC or using the old odbc.py that comes with
the win32 files works fine.
It only fails with pyodbc.
<[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> On May 18, 6:46 pm, &qu
I submitted a patch quite a while back for a bug in cgi.py (see source forge
1159139)
Martin, I posted this here, hoping you would see the message.
Back in March 2007 you were looking at this bug and updated the item on
source forge looking for more details.
I have documented the bug further f
I believe this bug is also related to the other problem I just reported.
OS = Windows XP SP2
DB = Microsoft Access XP
PROBLEM:
When you use + (or &) to concatenation columns together and the columns are
of type text and the combined length exceed 255 this causes pyodbc to fail
and python to cras
I have found a data corruption problem with pyodbc.
OS = Windows XP SP2
DB = Microsoft Access XP
PROBLEM:
When selecting columns from a table that are of type Memo the value
returned is padded with a bunch of null characters at the end.
The problems does not seem to occur until the length of th
22 matches
Mail list logo
