On 7/23/2011 5:34 AM, Vinay Sajip wrote:
Glenn Linderman g.nevcal.com> writes:
I aim to update the launcher downloads Real Soon Now.
Has fixed my problem with not having a local py.ini file, and now is
picking up python=3 from the py.ini coresident to the py.exe. Thanks,
Mark & Vinay.
___
Glenn Linderman g.nevcal.com> writes:
I aim to update the launcher downloads Real Soon Now.
> What (free?) toolset is needed for building the launcher? I don't
> even have a C compiler installed on this computer yet.
>
The tools I use for building the launcher are:
Windows SDK (for t
On 7/21/2011 5:44 PM, Mark Hammond wrote:
On 22/07/2011 9:02 AM, Glenn Linderman wrote:
Bad logic is get_configured_value! get_configured_value only looks in
the global configuration file if there is a local configuration file
that doesn't have the setting. It should look in the global
configu
On 22/07/2011 9:02 AM, Glenn Linderman wrote:
Bad logic is get_configured_value! get_configured_value only looks in
the global configuration file if there is a local configuration file
that doesn't have the setting. It should look in the global
configuration file if there is no local configurat
On 7/20/2011 5:11 PM, Mark Hammond wrote:
It may be that your copy of the launcher is a little old - some
changes were pushed just yesterday (but I'm not sure if Vinay made a
new installer yet). It has slightly better debug output (although
generally not what you are asking for yet) and better
On Fri, Jul 22, 2011 at 6:05 AM, Glenn Linderman wrote:
> On 7/21/2011 8:20 AM, Michael Foord wrote:
>> py launcher and python binaries behaving differently in this regard would be
>> a recipe for confusion and hard to debug problems.
>
> I see the point. Although the incremental benefit is highe
On 7/21/2011 8:20 AM, Michael Foord wrote:
On 21/07/2011 15:43, Paul Moore wrote:
On 21 July 2011 09:13, Glenn Linderman wrote:
Certainly when the launcher is invoked via an association, this would
be the case. However, when the launcher is invoked via the command
line, then the unqualified n
On 21/07/2011 15:43, Paul Moore wrote:
On 21 July 2011 09:13, Glenn Linderman wrote:
Certainly when the launcher is invoked via an association, this would
be the case. However, when the launcher is invoked via the command
line, then the unqualified name is passed through. To be useful from
th
On 21 July 2011 09:13, Glenn Linderman wrote:
> Certainly when the launcher is invoked via an association, this would
> be the case. However, when the launcher is invoked via the command
> line, then the unqualified name is passed through. To be useful from
> the command line, the launcher shoul
On Thu, 21 Jul 2011 01:06:57 -0700, Glenn Linderman
wrote:
> Interesting, David, that you feel it that Python usability on Windows
> should be limited to its usability on Unix, rather than to exceed it. I
> don't see that as a necessary or appropriate limit. Windows and Unix
That wasn't how
On Thu, Jul 21, 2011 at 6:06 PM, Glenn Linderman wrote:
> Interesting, David, that you feel it that Python usability on Windows should
> be limited to its usability on Unix, rather than to exceed it. I don't see
> that as a necessary or appropriate limit. Windows and Unix are different.
> Unix pe
On 7/20/2011 5:34 PM, Mark Hammond wrote:
On 21/07/2011 10:13 AM, Glenn Linderman wrote:
On 7/20/2011 2:43 PM, Glenn Linderman wrote:
It's not py's job to walk the path: the shell does that when you
just type
"foo". It locates foo.py, and then invokes py because of file
association - py
then c
On 7/20/2011 8:22 PM, Nick Coghlan wrote:
On Thu, Jul 21, 2011 at 12:52 PM, R. David Murray wrote:
Indeed. If I want to run a script with a different python version
on a unix-like system, I need to know the path to said script.
We're trying to make python as easy to use on Windows as it is on
On Thu, Jul 21, 2011 at 12:52 PM, R. David Murray wrote:
> Indeed. If I want to run a script with a different python version
> on a unix-like system, I need to know the path to said script.
> We're trying to make python as easy to use on Windows as it is on Unix.
> If find-script-on-path is consi
On Thu, 21 Jul 2011 10:27:31 +1000, Mark Hammond
wrote:
> On 21/07/2011 10:18 AM, Glenn Linderman wrote:
> > On 7/20/2011 5:07 PM, Nick Coghlan wrote:
> >> On Thu, Jul 21, 2011 at 8:51 AM, Ethan Furman wrote:
> >>> I would say that would be a cool enhancement, as it could save a bit of
> >>> typ
On 21/07/2011 10:18 AM, Glenn Linderman wrote:
On 7/20/2011 5:07 PM, Nick Coghlan wrote:
On Thu, Jul 21, 2011 at 8:51 AM, Ethan Furman wrote:
I would say that would be a cool enhancement, as it could save a bit of
typing, but I think the launcher is quite useful even without path
traversal.
T
On 21/07/2011 10:13 AM, Glenn Linderman wrote:
On 7/20/2011 2:43 PM, Glenn Linderman wrote:
It's not py's job to walk the path: the shell does that when you just type
"foo". It locates foo.py, and then invokes py because of file association - py
then checks the file for a shebang to decide which
On 7/20/2011 5:11 PM, Mark Hammond wrote:
On 21/07/2011 10:02 AM, Glenn Linderman wrote:
So this tells me that it didn't find a local py.ini (no surprise, I
don't have one) but doesn't tell me that it did find or read
c:\Windows\system32\py.ini much less whether I have the syntax correct
for my
On 7/20/2011 5:07 PM, Nick Coghlan wrote:
On Thu, Jul 21, 2011 at 8:51 AM, Ethan Furman wrote:
I would say that would be a cool enhancement, as it could save a bit of
typing, but I think the launcher is quite useful even without path
traversal.
Two related points:
1. Walking PATH isn't necess
On 7/20/2011 2:43 PM, Glenn Linderman wrote:
It's not py's job to walk the path: the shell does that when you just type
"foo". It locates foo.py, and then invokes py because of file association - py
then checks the file for a shebang to decide which Python to dispatch it to.
Certainly when the
On 21/07/2011 10:02 AM, Glenn Linderman wrote:
So this tells me that it didn't find a local py.ini (no surprise, I
don't have one) but doesn't tell me that it did find or read
c:\Windows\system32\py.ini much less whether I have the syntax correct
for my [defaults] section. It doesn't tell me tha
On Thu, Jul 21, 2011 at 8:51 AM, Ethan Furman wrote:
> I would say that would be a cool enhancement, as it could save a bit of
> typing, but I think the launcher is quite useful even without path
> traversal.
Two related points:
1. Walking PATH isn't necessary, but the cwd of the py process shou
On 7/20/2011 4:41 PM, Mark Hammond wrote:
On 21/07/2011 7:43 AM, Glenn Linderman wrote:
...
I still get the same behavior. Is there any debugging output produced
by py.exe that would tell what py.ini it looks in, and what the content
is? What diagnostic steps might I take to produce additiona
On 21/07/2011 7:43 AM, Glenn Linderman wrote:
...
I still get the same behavior. Is there any debugging output produced
by py.exe that would tell what py.ini it looks in, and what the content
is? What diagnostic steps might I take to produce additional
information that would help you (or me, a
Glenn Linderman wrote:
On 7/20/2011 7:19 AM, Vinay Sajip wrote:
It's not py's job to walk the path: the shell does that when you just type
"foo". It locates foo.py, and then invokes py because of file association - py
then checks the file for a shebang to decide which Python to dispatch it to.
On 7/20/2011 7:19 AM, Vinay Sajip wrote:
Glenn Linderman g.nevcal.com> writes:
Since I don't yet have associations set up that point at the
launcher, I thought I'd play with saying "py" in front of the
command.
Why don't you have any associations pointing to the launcher? Did
Glenn Linderman g.nevcal.com> writes:
> Since I don't yet have associations set up that point at the
> launcher, I thought I'd play with saying "py" in front of the
> command.
Why don't you have any associations pointing to the launcher? Did you delete
them? If you uninstall and ins
On 20 July 2011 10:17, Glenn Linderman wrote:
> However, the following fails: py foo.py
> It fails, because foo.py is not found. Instead, I have to specify: py
> d:\path\to\foo.py
> This is annoying, py should walk the PATH for unqualified files (the Windows
> PATH implicitly includes the curren
On 7/18/2011 6:41 PM, Vinay Sajip wrote:
> So I can fix my machine, now that I understand what went wrong
> (delete py.exe entries from HCU, and put them in HLM instead).
> Then the other problem I have, is why py.exe launched py 2.6.4
> instead of py 3.2.1 when 3.2.1 is ne
On 7/18/2011 7:03 PM, Glenn Linderman wrote:
Wonder if there is a third party command line tool which augments them
for reading/setting HCU Classes? Will search. I know there is a
command line registry tool somewhere, but specifying the paths
correctly would be onerous.
XP+ has REG and REGI
On 7/18/2011 6:41 PM, Vinay Sajip wrote:
Yes, but the launcher installer is beta software, and it's not yet clear
exactly how the launcher will be packaged with Python 3.3. Clearly if
packaged as an automatic installation with Python, it will use Python
defaults.
Sure, and that's why I'm trying
Glenn Linderman g.nevcal.com> writes:
> So, then, there must be 2 problems... one in the launcher installer,
> and the other being whatever happened to my machine.
I think so. I know that Windows sometimes adds file type associations under
HKCU which shadow the ones set up in HKLM, but I
On 7/18/2011 4:55 PM, Vinay Sajip wrote:
Glenn Linderman g.nevcal.com> writes:
Here is a list of py.exe references in my registry:
HCR\Python.CompiledFile
HCR\Python.File
HCR\Python.NoConFile
[snip]
There shouldn't be so many references, so I suggest you may wan
Glenn Linderman g.nevcal.com> writes:
> Here is a list of py.exe references in my registry:
> HCR\Python.CompiledFile
> HCR\Python.File
> HCR\Python.NoConFile
[snip]
There shouldn't be so many references, so I suggest you may want to try the
following (after backing up yo
On 7/18/2011 2:13 PM, Vinay Sajip wrote:
The reason I thought it did nothing, is that I checked assoc (
=Python.File ) and ftype ( =c:\python32\python.exe "%1" %* ) both of
which look familiar, and neither of which mention py.exe which is
what I think the launcher is suppo
On 7/18/2011 2:13 PM, Vinay Sajip wrote:
Remember that there are two sets of locations - HKCU and HKLM - where the type
associations are potentially held. Please do a registry search (with
Administrator rights so you can search the whole registry) for "py.exe" or
"pyw.exe" and see if they show up
> The reason I thought it did nothing, is that I checked assoc (
> =Python.File ) and ftype ( =c:\python32\python.exe "%1" %* ) both of
> which look familiar, and neither of which mention py.exe which is
> what I think the launcher is supposed to have been named; and
> runni
On 7/18/2011 1:01 PM, Paul Moore wrote:
2011/7/18 Glenn Linderman:
Attached reduced test case works fine with Python 3.1, fails with Python3.2:
PS D:\Data> py -3 .\t32enc.py
PS D:\Data> py -2 .\t32enc.py
File ".\t32enc.py", line 1
SyntaxError: Non-ASCII character '\xc3' in file .\t32enc.py
Similar outcome as Paul's.
$ python3 t32enc.py
$ python t32enc.py
File "t32enc.py", line 1
SyntaxError: Non-ASCII character '\xc3' in file t32enc.py on line 1, but no
encoding declared; see http://www.python.org/peps/pep-0263.html for details
$ python3 -V
Python 3.2.1a0
$ python -V
Python 2.6.1
2011/7/18 Glenn Linderman :
> Attached reduced test case works fine with Python 3.1, fails with Python3.2:
PS D:\Data> py -3 .\t32enc.py
PS D:\Data> py -2 .\t32enc.py
File ".\t32enc.py", line 1
SyntaxError: Non-ASCII character '\xc3' in file .\t32enc.py on line 1,
but no encoding declared; see h
On 7/18/2011 3:10 PM, Glenn Linderman wrote:
Attached reduced test case works fine with Python 3.1, fails with Python3.2:
SyntaxError: Non-ASCII character '\xc3' in file D:\my\py\t32enc.py on
line 1, but no encoding declared; see
http://www.python.org/peps/pep-0263.html for details
It runs fin
41 matches
Mail list logo
