Re: [Python-Dev] [PEPs] Rebooting PEP 394 (aka Support the /usr/bin/python2 symlink upstream)

[Ned Deily]

In article 
,
 Kerrick Staley  wrote:
> Here are my thoughts:
> * For Ned's comments, I agree. Although the issue isn't as large with
> these programs, there's no reason we can't handle them in the same
> way. I updated the PEP.

Thanks.

> Also, I updated the PEP with the clarification that commands like
> python3 should be hard links (because they'll be invoked from code and
> are more efficient; also, hard links are just as flexible as symlinks
> here), while commands like python should be soft links (because this
> makes it clear to sysadmins that they can be "switched", and it's
> needed for flexibility if python3 changes). This really doesn't
> matter, but can we keep it this way unless there are serious
> objections?

I think adding the requirement to mandate hard link vs soft link usage 
is an unnecessary and unwarranted attempt at optimization.  For 
instance, IIRC, the OS X installers don't use any hard links: that may 
complicate the install, plus hard links on OS X HFS* file systems are a 
bit of a kludge and not necessarily more efficient than symlinks.   It's 
not a big deal but perhaps the wording should be changed to make a 
suggestion about hard links vs syminks rather than mandate which should 
be used.

-- 
 Ned Deily,
 n...@acm.org

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Python web adv. ?

[Durga D]

Hi All,

My desktop application opens web page from tomcat/apache server in
button click event (MySQL database by using JSP/Servlets on internet from
user machine). Here, I found some delay in opening web pages.  Is there any
advantages with Python over JSP/Servlets?

I am new to web programming. Please provide any inputs on Python over
jsp/servlets.

Thanks in advance.

Regards,
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python web adv. ?

[Laurens Van Houtven]

Hi!

This list is for developing Python itself, not about developing *in* Python.
For more support try the comp.lang.python newsgroup or the equivalent
http://mail.python.org/mailman/listinfo/python-list mailing list, or the
#python IRC channel on Freenode.

cheers
lvh

On Mon, Jul 18, 2011 at 5:32 PM, Durga D  wrote:

> Hi All,
>
> My desktop application opens web page from tomcat/apache server in
> button click event (MySQL database by using JSP/Servlets on internet from
> user machine). Here, I found some delay in opening web pages.  Is there any
> advantages with Python over JSP/Servlets?
>
> I am new to web programming. Please provide any inputs on Python over
> jsp/servlets.
>
> Thanks in advance.
>
> Regards,
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/_%40lvh.cc
>
>


-- 
cheers
lvh
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] 3.2.1 encoding surprise

[Glenn Linderman]

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


I'm familiar with the PEP, but thought 3.x cured that.  Python 3.1 
produces no error; I'm not sure that 3.2 did or didn't report such 
problems, or if the programs I ran with 3.2 simply didn't contain 
non-ASCII characters.


The file is UTF-8 encoded with no pseudo-BOM.

Is this intentional, or a regression (in which case I will open a ticket)?

If a regression, does that mean we have no tests for it, possibly 
because most of the tests contain the PEP 263 encoding directive, 
because most people using 3.x are still also using 2.x (I am not)?
"L × W"
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 3.2.1 encoding surprise

[Terry Reedy]

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 fine for me on winxp, 3.2.1, both command prompt and idle.
When cut/paste worked, I downloaded file and ran that.


I'm familiar with the PEP, but thought 3.x cured that.  Python 3.1
produces no error; I'm not sure that 3.2 did or didn't report such
problems, or if the programs I ran with 3.2 simply didn't contain
non-ASCII characters.

The file is UTF-8 encoded with no pseudo-BOM.

Is this intentional, or a regression (in which case I will open a ticket)?

If a regression, does that mean we have no tests for it, possibly
because most of the tests contain the PEP 263 encoding directive,
because most people using 3.x are still also using 2.x (I am not)?


Or there could be a test (have not checked) which usually passes.


--
Terry Jan Reedy

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 3.2.1 encoding surprise

[Paul Moore]

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 http://www.python.o
rg/peps/pep-0263.html for details
PS D:\Data> py -3 --version
Python 3.2.1
PS D:\Data> py -2 --version
Python 2.7

Windows 7 32-bit, py is Vinay's implementation of the PEP 397 launcher
for Windows.

This looks like correct output to me.

Could it be your environment somehow?
Paul.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 3.2.1 encoding surprise

[Anthony Kong]

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

Running the script on OSX 10.6.8

(And I just realised I am running 3.2.1a0...)

Cheers

On Tue, Jul 19, 2011 at 6:01 AM, 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 on line 1,
> but no encoding declared; see http://www.python.o
> rg/peps/pep-0263.html for details
> PS D:\Data> py -3 --version
> Python 3.2.1
> PS D:\Data> py -2 --version
> Python 2.7
>
> Windows 7 32-bit, py is Vinay's implementation of the PEP 397 launcher
> for Windows.
>
> This looks like correct output to me.
>
> Could it be your environment somehow?
> Paul.
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/anthony.hw.kong%40gmail.com
>



-- 

Tony Kong
*blog:* www.ahwkong.com

Don’t EVER make the mistake that you can design something better than what
you get from ruthless massively parallel trial-and-error with a feedback
cycle. That’s giving your intelligence *much* too much credit.


- Linus Torvalds
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 3.2.1 encoding surprise

[Glenn Linderman]

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 on line 1,
but no encoding declared; see http://www.python.o
rg/peps/pep-0263.html for details
PS D:\Data>  py -3 --version
Python 3.2.1
PS D:\Data>  py -2 --version
Python 2.7

Windows 7 32-bit, py is Vinay's implementation of the PEP 397 launcher
for Windows.

This looks like correct output to me.

Could it be your environment somehow?
Paul.


Yes, a surprise.  But it is my environment I'm not sure exactly how 
or why yet.  I've continued investigating since posting that... but 
thanks for the confirmation that it isn't 3.2.1 !


Tweaked the program to show the version and it showed 2.6.4!  Which is 
the only version of Python 2.x installed here.


So my suspicion is that   launchsys.adm64.msi, installed just after 
3.2.1 (but which appeared to do nothing) has taken over ... something.  
Not sure what yet.


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 running  
c:\python32\python.exe from the command line produces a Python that 
looks like 3.2.1 .


But somehow, runningt32enc.py  from the command line fails, and 
loads 2.6.4 !


From what I've read about the launcher, I thought it was supposed to 
take over the assoc and ftype and point Python.File to  
c:\windows\system32\py.exe  -- but that hasn't happened (and yes, I've 
rebooted since doing the installs, so it is not just a leftover CMD that 
didn't pick up new values).


So my question now is: how does the launcher really get activated when 
invoking .py files from the command line, if the assoc and ftype 
indicate that it should run c:\python32\python.exe (which when I run by 
hand, seems to be what the name claims it to be)?


We don't need to create mysteries!

Glenn
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 3.2.1 encoding surprise

[Vinay Sajip]

> 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
> running  c:\python32\python.exe from the command line produces a
> Python that looks like 3.2.1 .
> But somehow, running    t32enc.py  from the command line fails, and
> loads 2.6.4 !
> From what I've read about the launcher, I thought it was supposed to
> take over the assoc and ftype and point Python.File to 
> c:\windows\system32\py.exe  -- but that hasn't happened (and yes,
> I've rebooted since doing the installs, so it is not just a leftover
> CMD that didn't pick up new values).
> So my question now is: how does the launcher really get activated
> when invoking .py files from the command line, if the assoc and
> ftype indicate that it should run c:\python32\python.exe (which when
> I run by hand, seems to be what the name claims it to be)?
> We don't need to create mysteries!
> Glenn

The launcher's activation is done by the shell you're using, which does the
lookups in the registry.

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 anywhere at all. The launcher code tries to
add these keys in HKEY_CLASSES_ROOT, but I believe Windows can map this to HKCU
rather than HKLM if you don't have administrator access, at least on XP.

Regards,

Vinay Sajip

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 3.2.1 encoding surprise

[Glenn Linderman]

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 anywhere at all. The launcher code tries to
add these keys in HKEY_CLASSES_ROOT, but I believe Windows can map this to HKCU
rather than HKLM if you don't have administrator access, at least on XP.


Oh, and I'm running Windows 7 64-bit, but most of my registry knowledge 
was learned on Win2K and XP, and I have no knowledge of what they did in 
Vista or 7, and haven't yet attempted to research such.


I am running as an administrator, but a much more ignorant one on 7 than 
I was on XP.


I have no idea why CMD would show an ftype Python.File as one thing, but 
then the execution would use something from the registry that is different.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 3.2.1 encoding surprise

[Glenn Linderman]

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 supposed to have been named; and
 running  c:\python32\python.exe from the command line produces a
 Python that looks like 3.2.1 .
 But somehow, runningt32enc.py  from the command line fails, and
 loads 2.6.4 !
 From what I've read about the launcher, I thought it was supposed to
 take over the assoc and ftype and point Python.File to 
 c:\windows\system32\py.exe  -- but that hasn't happened (and yes,

 I've rebooted since doing the installs, so it is not just a leftover
 CMD that didn't pick up new values).
 So my question now is: how does the launcher really get activated
 when invoking .py files from the command line, if the assoc and
 ftype indicate that it should run c:\python32\python.exe (which when
 I run by hand, seems to be what the name claims it to be)?
 We don't need to create mysteries!
 Glenn

The launcher's activation is done by the shell you're using, which does the
lookups in the registry.

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 anywhere at all. The launcher code tries to
add these keys in HKEY_CLASSES_ROOT, but I believe Windows can map this to HKCU
rather than HKLM if you don't have administrator access, at least on XP.


Thanks for the response, Vinay... you are the one that would know, now 
that I've figured out it is a launcher issue rather than a Python issue.


Here is a list of py.exe references in my registry:

HCR\Python.CompiledFile
HCR\Python.File
HCR\Python.NoConFile
HCU\Software\Classes\Python.CompiledFile
HCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.py\OpenWithListk
HLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-21.\Componer
HLM\SOFTWARE\Wow6432Note\Microsoft\Windows\CurrentVersion\SharedDLLs
HKU\S-1-5-21-.\Software\Classes\Python.CompiledFile (and similar 
corresponding to the above HCR ones)


My (perhaps dated) understanding of the CMD commands attrib and ftype is 
that they reflect the contents of HCR.  But here HCR\Python.File is 
different than the value displayed by the CMD ftype Python.File.  Why?  
What am I missing?


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 3.2.1 encoding surprise

[Vinay Sajip]

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 your registry first):

1. Uninstall all instances of the launcher.
2. Remove all registry keys for .py, .pyc, .pyo, .pyw, Python.File,
Python.NoConFile, and Python.CompiledFile.
3. Re-install the launcher (64-bit) using "msiexec /i launchsys.amd64.msi
ALLUSERS=1" (or launcher.amd64.msi if you prefer - the only difference is the
installation directory).
4. Check that the removed associations have appeared under HKEY_LOCAL_MACHINE,
and that they all point to the launcher installed in the previous step. These
may also appear in HKEY_CLASSES_ROOT if it is aliased to the
HKEY_LOCAL_MACHINE\Software\Classes tree.

Regards,

Vinay Sajip

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 3.2.1 encoding surprise

[Glenn Linderman]

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 want to try the
following (after backing up your registry first):


So, then, there must be 2 problems... one in the launcher installer, and 
the other being whatever happened to my machine.


Can you list the ones there should be?


1. Uninstall all instances of the launcher.


Well, there is only one.  But I can certainly remove it, and see what 
happens.



2. Remove all registry keys for .py, .pyc, .pyo, .pyw, Python.File,
Python.NoConFile, and Python.CompiledFile.

Yes, I can do this.


3. Re-install the launcher (64-bit) using "msiexec /i launchsys.amd64.msi
ALLUSERS=1" (or launcher.amd64.msi if you prefer - the only difference is the
installation directory).
So what I had done was just double click launchsys.msi.  Why should 
there be command line parameters, rather than question/answer dialogs?  
This is Windows after all.  What does the parameter do, that would be 
different than what double click did?

4. Check that the removed associations have appeared under HKEY_LOCAL_MACHINE,
and that they all point to the launcher installed in the previous step. These
may also appear in HKEY_CLASSES_ROOT if it is aliased to the
HKEY_LOCAL_MACHINE\Software\Classes tree.


I also still don't understand why CMD reports a different command line 
via its assoc/ftype commands for the Python.File than actually gets used 
by CMD to launch the .py file.


Found the following at http://zetconsultants.com/blog/?p=36:
Second issue (not really an issue, however something that makes our 
situation more complicated) is the fact that HKCR is in fact registry 
symlink and this registry key doesn’t really exists on system. It is 
merge of two different keys – HKLM\Software\Classes and 
HKCU\Software\Classes. You probably already guessed (correctly) that 
this is the way how you can overwrite some settings on per-user basis 
– HKCU key always wins.


which is useful, but still doesn't explain the variant results from 
ftype and launching behavior.}


They further say:


You need to create file type using FTYPE first and then associate this 
TFYPE with executable using ASSOC command. Even though this process is 
not very simple, you can use it. There is one HUGE disadvantage though 
and I still don’t understand how is it possible – both FTYPE and ASSOC 
works only on per-machine level! Therefore you cannot configure 
per-user associations using these tools!


Currently, there is no way through the UI to change or edit the
user-specific file type associations stored in the
HKEY_CURRENT_USER\SOFTWARE\Classes registry key. If you want to do
this, you have to directly edit the registry or develop your own
UI to gain access to this information.

Above you can see official Microsoft statement 
 about this issue.




So maybe the problem is that ftype and assoc report the HLM values, but 
CMD actually uses the HCU values.  This actually would explain what I am 
seeing, and this is the piece of information I didn't understand that 
caused my confusion.


So as long as everything is installed for "all users", then there is no 
confusion!  I see I have less than 3 dozen extensions installed in HCU, 
and over 800 in HLM, so clearly I choose "all users" most of the time.  
It would be painstaking to see if the 3 dozen were all consistent or 
not, without writing a program to help.


Clearly the launcher installer should offer the same choices as Python 
itself for installing for one or all users, rather than defaulting 
silently to one user.  Better, the default should be inherited from the 
Python installation... if they are all consistent, and if permissions 
allow the modification of HLM settings.



Regards,

Vinay Sajip


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 newer, and I don't have a #! line.  That is 
probably the defined behavior of the launcher, to prefer 2.x if 3 isn't 
specified.  I'll have to reread the launcher PEP.  In my environment, I 
would much prefer to use 3.x if 2.x isn't specified... so hopefully when 
I reread the launcher PEP, I'll discover a way to do that.  (I recall 
one can put -3 on the command line, so I could do that in the py.exe 
ftype commands, but hopefully there is a way to tweak the py.ini to do 
that.)


Thanks for your response, and help in creating the launcher.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/pyt

Re: [Python-Dev] 3.2.1 encoding surprise

[Vinay Sajip]

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'm not sure why or how it
happens.

> Well, there is only one.  But I can certainly remove it, and see
> what happens.

Okay, just making sure.

> So what I had done was just double click launchsys.msi.  Why should
> there be command line parameters, rather than question/answer
> dialogs?  This is Windows after all.  What does the parameter do,
> that would be different than what double click did?

Windows is unfortunately not consistent in its behaviour across different
versions - if you Google for ALLUSERS you'll probably find the information
that makes some people tear their hair out. So the ALLUSERS=1 forces Windows
to install under HKLM ("for all users" as opposed to "just for me") and to
fail if you don't have admin rights. Note that the ALLUSERS= is something
introduced by Microsoft, not something launcher-specific.

> I also still don't understand why CMD reports a different command
> line via its assoc/ftype commands for the Python.File than actually
> gets used by CMD to launch the .py file.

I believe it's to do with multiple versions in the registry.

>   something that makes our situation more complicated) is the fact
>   that HKCR is in fact registry symlink and this registry key
>   doesn’t really exists on system. It is merge of two different keys
>   – HKLM\Software\Classes and HKCU\Software\Classes. You probably
>   already guessed (correctly) that this is the way how you can
>   overwrite some settings on per-user basis – HKCU key always wins.
> 
> which is useful, but still doesn't explain the variant results from
> ftype and launching behavior.}
> They further say:
>   You need to create file type using FTYPE first and then
> associate this TFYPE with executable using ASSOC command. Even
> though this process is not very simple, you can use it. There is
> one HUGE disadvantage though and I still don’t understand how is
> it possible – both FTYPE and ASSOC works only on per-machine
> level! Therefore you cannot configure per-user associations
> using these tools!

I have certainly seen file type associations for .py in HKCU, whose presence
there I can't explain, but it's probably wrongly created by some Windows
software common in the ecosystem (if not Windows itself), which manifests in
odd ways - search deadlybloodyserious.com for problems where command line
arguments aren't passed to scripts because of bad ftype/assoc registry
entries. I would advise not using ftype/assoc commands, as you certainly
shouldn't need them for Python files if you install the launcher.

> Currently, there is no way through the UI to change or edit
>   the user-specific file type associations stored in the
>   HKEY_CURRENT_USER\SOFTWARE\Classes registry key. If you want
>   to do this, you have to directly edit the registry or develop
>   your own UI to gain access to this information. 
>   
>   Above you can see official Microsoft
>   statement about this issue.

Yes, but some software in Windows (perhaps "select program from a list" or
similar) definitely does set values in HKCU as a side-effect of doing
something else, which comes back to bite you later. I have personally
experienced the same problem as the blogger on deadlybloodyserious.com (which
is how I came across the solution on that site - by Googling to see if anyone
else had encountered it).


> Clearly the launcher installer should offer the same choices as
> Python itself for installing for one or all users, rather than
> defaulting silently to one user.  Better, the default should be
> inherited from the Python installation... if they are all
> consistent, and if permissions allow the modification of HLM
> settings.

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.

Note that ALLUSERS was introduced precisely because Microsoft didn't think
things through initially with sufficient care, and there's no way to get
consistent behaviour across XP and Vista/Windows 7. It's possible to force
ALLUSERS=1 in the .msi, but this means that non-admin users can't try the
launcher. Unfortunately AFAICT, there's no obvious solution which "just
works", though if someone were to point out a solution it could certainly be
tried.

> 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 

Re: [Python-Dev] 3.2.1 encoding surprise

[Glenn Linderman]

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 it out now, to provide feedback.  But 
because I couldn't tell from assoc and ftype commands that it had done 
anything, I was a bit surprised by the behaviors I did encounter when I 
encountered them.  So now I've learned about the limits of ftype and 
assoc, sadly.  And they only work for setting things in HLM if you "Run 
as administrator", by the way.


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.


Would be nice if the default of Py 2.x or 3.x were an install question, 
perhaps.  I know that only affects scripts without #! lines, but it 
would be nice to limit the required creation of those to the smaller 
class of preexisting scripts on a particular installation.



Note that ALLUSERS was introduced precisely because Microsoft didn't think
things through initially with sufficient care, and there's no way to get
consistent behaviour across XP and Vista/Windows 7. It's possible to force
ALLUSERS=1 in the .msi, but this means that non-admin users can't try the
launcher. Unfortunately AFAICT, there's no obvious solution which "just
works", though if someone were to point out a solution it could certainly be
tried.


Could be, with .msi and/or .cab installers.  I have no knowledge of 
them, except that when I first needed to use an installer to package 
things, I read a bit about them, and determined that they are too 
complex for my brain.  I found NSIS, still complex, but it is much 
friendlier to my brain, but it seems to handle this case correctly, 
giving the installer creator the option of asking for or demanding 
elevation, and exposing the answer to the rest of the logic of the 
installer, so it can do different things for those cases if it desires.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] 3.2.1 encoding surprise

[Glenn Linderman]

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 REGINI commands which can manipulate the registry from 
the command line, without resorting to third party applications.  So a 
batch file could wrap them, to avoid mistyping keys, and one could make 
an FTYPE.CMD and ASSOC.CMD (I haven't, at least not yet).


Also  although 
specific to Vim, is addressing the general problem, and comments by 
readers on that page seem relevant:


The following is a "for reader's information" comment; not a 
suggestion that the tip be changed. In classic Microsoft style, using 
HKEY_CLASSES_ROOT is ambiguous. I do not know the details, but on at 
least some systems (after Windows 9x), I think the following is correct:


HKEY_LOCAL_MACHINE\Software\Classes : for all users 
HKEY_CURRENT_USER\Software\Classes : for interactive user 
HKEY_CLASSES_ROOT : merged view of above (and is used by Win9x
apps ) 

I don't know what happens if you write to HKEY_CLASSES_ROOT (which 
does not exist). Perhaps (like installing some apps), if you are in 
the Administrators group, you will write to HKLM, otherwise you will 
write to HKCU. JohnBeckett 
 08:24, 2 July 2009 (UTC)




This is correct as far as I know. I wanted to include some information 
about how HKCR is a merged view of HKLM/Software/Classes and 
HKCU/Software/Classes, but doing so would beg information such as 
"what happens when I edit an entry that actually exists in HKCU?" etc. 
From experimentation, it seems that creating /new/ keys in this area 
will always create it in HKLM (system-wide), and ftype and assoc 
certainly do that, but I don't really have any documentation of that 
fact, and I don't know what it will do for limited-privilege accounts. 
I also don't know what happens when you edit an existing key, but I 
imagine it will "do the right thing" and keep the original where it 
was. I don't know this for a fact though. For these reasons, I left 
out that tidbit. But if we can answer some of these questions, it 
would be a good thing to include.




So attempts by applications to use the HKEY_CLASSES_ROOT directly may 
result in variant behavior depending on the privilege of the 
application.  My overall opinion? It is sad that M$ even invented the 
registry.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com