[Python-Dev] Windows installer - File associations in per user installs
On 9 March 2015 at 15:37, Steve Dower steve.do...@microsoft.com wrote: Maybe the answer is that we simply start recommending that everyone on Windows uses per-user installs. It makes little difference to me (beyond the fact that when I want to look at the source of something in the stdlib, the location of the file is a lot harder to remember than C:\Apps\Python34\Lib\whatever.py) but I doubt it's what most people will expect. I'm okay with this. Installing for all users is really something that could be considered an advanced option rather than the default, especially since the aim (AIUI) of the all-users install is to pretend that Python was shipped with the OS. (I'd kind of like to take that further by splitting things more sensibly between Program Files, Common Files and System32, but there's very little gain from that and much MUCH pain as long as people are still expecting C:\PythonXY installs...) I've just tried a per-user install of Python 3.5a2. The machine in question previously had (and still has) a system install of 3.4, with Make this Python the default selected (so the .py extension is associated with that version and specifically the 3.4 launcher). I didn't get the option to associate .py files with 3.5 (there's *no way* I'd consider that to be advanced usage - if I'm installing Python, why wouldn't I want to associate it with .py files [1]) and I still seem to have .py associated with the 3.4 launcher, not the 3.5 one that's in my %APPDATA% folder. cmd /c assoc .py .py=Python.File cmd /c ftype python.file python.file=C:\WINDOWS\py.exe %1 %* I'm happy if a per-user install of 3.5 makes a per-user filetype association (assuming such a thing is possible, I've never tried it before) but it's absolutely not OK if we're planning on recommending an install type that doesn't create the right association. Paul [1] Given that I have 3.4 and am installing an experimental 3.5 version, it's not actually at all clear cut which version I want as my default. In all honesty, I don't think this decision is actually something that should be defaulted. Maybe the don't make the user make any choices in the default selection approach has gone a little too far here? ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Windows installer - File associations in per user installs
It's a bug. File and assign to me please. Top-posted from my Windows Phone From: Paul Mooremailto:p.f.mo...@gmail.com Sent: 3/10/2015 3:35 To: Steve Dowermailto:steve.do...@microsoft.com Cc: Python Devmailto:python-dev@python.org Subject: Windows installer - File associations in per user installs On 9 March 2015 at 15:37, Steve Dower steve.do...@microsoft.com wrote: Maybe the answer is that we simply start recommending that everyone on Windows uses per-user installs. It makes little difference to me (beyond the fact that when I want to look at the source of something in the stdlib, the location of the file is a lot harder to remember than C:\Apps\Python34\Lib\whatever.py) but I doubt it's what most people will expect. I'm okay with this. Installing for all users is really something that could be considered an advanced option rather than the default, especially since the aim (AIUI) of the all-users install is to pretend that Python was shipped with the OS. (I'd kind of like to take that further by splitting things more sensibly between Program Files, Common Files and System32, but there's very little gain from that and much MUCH pain as long as people are still expecting C:\PythonXY installs...) I've just tried a per-user install of Python 3.5a2. The machine in question previously had (and still has) a system install of 3.4, with Make this Python the default selected (so the .py extension is associated with that version and specifically the 3.4 launcher). I didn't get the option to associate .py files with 3.5 (there's *no way* I'd consider that to be advanced usage - if I'm installing Python, why wouldn't I want to associate it with .py files [1]) and I still seem to have .py associated with the 3.4 launcher, not the 3.5 one that's in my %APPDATA% folder. cmd /c assoc .py .py=Python.File cmd /c ftype python.file python.file=C:\WINDOWS\py.exe %1 %* I'm happy if a per-user install of 3.5 makes a per-user filetype association (assuming such a thing is possible, I've never tried it before) but it's absolutely not OK if we're planning on recommending an install type that doesn't create the right association. Paul [1] Given that I have 3.4 and am installing an experimental 3.5 version, it's not actually at all clear cut which version I want as my default. In all honesty, I don't think this decision is actually something that should be defaulted. Maybe the don't make the user make any choices in the default selection approach has gone a little too far here? ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] str.lstrip bug?
On Tue, Mar 10, 2015 at 2:27 PM, lou xiao lox.x...@gmail.com wrote:
tiny➜ ~ python
Python 2.7.5+ (default, Feb 27 2014, 19:37:08)
[GCC 4.8.1] on linux2
Type help, copyright, credits or license for more information.
a='device_info'
a.lstrip('device')
'_info'
a.lstrip('device_')
'nfo'
On one hand, this is the development of python itself list; this
issue was more aimed to the general python list, of you was sure that
this is a real bug, to the issue tracker.
On the other hand, this is not a bug! If you pass a parameter to
lstrip it will (quoted from its help) remove characters in chars
instead., so the moment you pass device_, it removes all those
characers from the left... note that the 'i' is removed twice.
Regards,
--
.Facundo
Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/
Twitter: @facundobatista
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] str.lstrip bug?
On Wed, Mar 11, 2015 at 4:27 AM, lou xiao lox.x...@gmail.com wrote:
I find a bug in str.lstrip, when i call str.lstrip, i get this result.
tiny➜ ~ python
Python 2.7.5+ (default, Feb 27 2014, 19:37:08)
[GCC 4.8.1] on linux2
Type help, copyright, credits or license for more information.
a='device_info'
a.lstrip('device')
'_info'
a.lstrip('device_')
'nfo'
tiny➜ ~ uname -a
Linux tinymint 3.11.0-12-generic #19-Ubuntu SMP Wed Oct 9 16:20:46 UTC 2013
x86_64 x86_64 x86_64 GNU/Linux
tiny➜ ~
It's not a bug, because it isn't doing what you think it is. It strips
a *set of characters*, not a prefix string.
https://docs.python.org/2/library/stdtypes.html#str.lstrip
https://docs.python.org/3/library/stdtypes.html#str.lstrip
ChrisA
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] str.lstrip bug?
ths, i misunderstood the method
2015-03-11 1:33 GMT+08:00 Chris Angelico ros...@gmail.com:
On Wed, Mar 11, 2015 at 4:27 AM, lou xiao lox.x...@gmail.com wrote:
I find a bug in str.lstrip, when i call str.lstrip, i get this result.
tiny➜ ~ python
Python 2.7.5+ (default, Feb 27 2014, 19:37:08)
[GCC 4.8.1] on linux2
Type help, copyright, credits or license for more information.
a='device_info'
a.lstrip('device')
'_info'
a.lstrip('device_')
'nfo'
tiny➜ ~ uname -a
Linux tinymint 3.11.0-12-generic #19-Ubuntu SMP Wed Oct 9 16:20:46 UTC
2013
x86_64 x86_64 x86_64 GNU/Linux
tiny➜ ~
It's not a bug, because it isn't doing what you think it is. It strips
a *set of characters*, not a prefix string.
https://docs.python.org/2/library/stdtypes.html#str.lstrip
https://docs.python.org/3/library/stdtypes.html#str.lstrip
ChrisA
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] str.lstrip bug?
* lou xiao lox.x...@gmail.com [2015-03-11 01:27:21 +0800]:
I find a bug in str.lstrip, when i call str.lstrip, i get this result.
You're misunderstanding how str.strip works. It takes a set of
characters and removes them all from the beginning:
abababcd.lstrip('ab')
'cd'
Florian
--
http://www.the-compiler.org | m...@the-compiler.org (Mail/XMPP)
GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc
I love long mails! | http://email.is-not-s.ms/
pgpJPx9uFbx98.pgp
Description: PGP signature
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] str.lstrip bug?
I find a bug in str.lstrip, when i call str.lstrip, i get this result.
tiny➜ ~ python
Python 2.7.5+ (default, Feb 27 2014, 19:37:08)
[GCC 4.8.1] on linux2
Type help, copyright, credits or license for more information.
a='device_info'
a.lstrip('device')
'_info'
a.lstrip('device_')
'nfo'
tiny➜ ~ uname -a
Linux tinymint 3.11.0-12-generic #19-Ubuntu SMP Wed Oct 9 16:20:46 UTC 2013
x86_64 x86_64 x86_64 GNU/Linux
tiny➜ ~
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Thoughts on running Python 3.5 on Windows (path, pip install --user, etc)
On 10 March 2015 at slightly after midnight. Paul Moore wrote: Personally I doubt it would make much difference. If the docs say pygmentize I'm unlikely to dig around to find that the incantation python -m pygments.somemodule:main does the same thing using 3 times as many characters. I'd just add Python to my PATH and say stuff it. There is value in getting the incantation down to a single (preferably short) line, because then it can be used as a shortcut. That means it can be created as a shortcut at installation time, and that someone writing their own batch file can just cut and paste from the shortcut properties' target. Not as simple as just adding to the path, but simpler than adding several directories to the path, or modifying other environment variables, or fighting an existing but conflicting python installation already on the path. -jJ -- If there are still threading problems with my replies, please email me with details, so that I can try to resolve them. -jJ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] str.lstrip bug?
On 15-03-10, Ethan Furman wrote:
On 03/10/2015 10:57 AM, Isaac Schwabacher wrote:
On 15-03-10, Facundo Batista wrote:
On Tue, Mar 10, 2015 at 2:27 PM, lou xiao wrote:
tiny➜ ~ python
Python 2.7.5+ (default, Feb 27 2014, 19:37:08)
[GCC 4.8.1] on linux2
Type help, copyright, credits or license for more information.
a='device_info'
a.lstrip('device')
'_info'
a.lstrip('device_')
'nfo'
On one hand, this is the development of python itself list; this
issue was more aimed to the general python list, of you was sure that
this is a real bug, to the issue tracker.
On the other hand, this is not a bug! If you pass a parameter to
lstrip it will (quoted from its help) remove characters in chars
instead., so the moment you pass device_, it removes all those
characers from the left... note that the 'i' is removed twice.
That said, I bet this is the most common string-munging operations that
*isn't* available as a single function in the stdlib. I know my bash code
is full of ${filename%.suffix} and such, and the fact that in python I have
to either import re or resort to some combination of (starts|ends)with,
r?partition, slicing and an if-clause makes that sort of code much more
verbose and harder to read. Pathlib's Path.with_suffix helps in some but
not all of these cases. Maybe the stdlib should have a simple way to do
this? It could even be added as a kwarg (exact=False) to str.[lr]strip to
minimize the effect on the API; alternatively it could be
str.strip(prefix|suffix).
Nice way to bring it on-topic!
And yes, that would be nice.
Yes. When you are converting a code base from bash to python, you *really*
don't want python to push back.
--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] str.lstrip bug?
On 03/10/2015 10:57 AM, Isaac Schwabacher wrote:
On 15-03-10, Facundo Batista wrote:
On Tue, Mar 10, 2015 at 2:27 PM, lou xiao wrote:
tiny➜ ~ python
Python 2.7.5+ (default, Feb 27 2014, 19:37:08)
[GCC 4.8.1] on linux2
Type help, copyright, credits or license for more information.
a='device_info'
a.lstrip('device')
'_info'
a.lstrip('device_')
'nfo'
On one hand, this is the development of python itself list; this
issue was more aimed to the general python list, of you was sure that
this is a real bug, to the issue tracker.
On the other hand, this is not a bug! If you pass a parameter to
lstrip it will (quoted from its help) remove characters in chars
instead., so the moment you pass device_, it removes all those
characers from the left... note that the 'i' is removed twice.
That said, I bet this is the most common string-munging operations that
*isn't* available as a single function in the stdlib. I know my bash code is
full of ${filename%.suffix} and such, and the fact that in python I have to
either import re or resort to some combination of (starts|ends)with,
r?partition, slicing and an if-clause makes that sort of code much more
verbose and harder to read. Pathlib's Path.with_suffix helps in some but not
all of these cases. Maybe the stdlib should have a simple way to do this? It
could even be added as a kwarg (exact=False) to str.[lr]strip to minimize the
effect on the API; alternatively it could be str.strip(prefix|suffix).
Nice way to bring it on-topic!
And yes, that would be nice.
--
~Ethan~
signature.asc
Description: OpenPGP digital signature
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
