[Python-Dev] Windows installer - File associations in "per user" installs

2015-03-10 Thread Paul Moore 
On 9 March 2015 at 15:37, Steve Dower  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

2015-03-10 Thread Steve Dower 
It's a bug. File and assign to me please.

Top-posted from my Windows Phone

From: Paul Moore
Sent: ‎3/‎10/‎2015 3:35
To: Steve Dower
Cc: Python Dev
Subject: Windows installer - File associations in "per user" installs

On 9 March 2015 at 15:37, Steve Dower  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] Thoughts on running Python 3.5 on Windows (path, pip install --user, etc)

2015-03-10 Thread Jim J. Jewett 


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] Tunning binary insertion sort algorithm in Timsort.

2015-03-10 Thread Tim Peters 
OK - here's what the current binsort does, ignoring that it skips an
already-sorted prefix (if any), and creating a new list instead of
modifying in-place:

def oldsort(a):
from bisect import bisect_right as br
assert a
result = [a[0]]
for i in range(1, len(a)):
x = a[i]
index = br(result, x)
result.insert(index, x)
return result

And here's my best guess as to what you _intend_ the new version to
do.  Please confirm that, or, if I'm guessing wrong, please give a
Python function that _does_ implement your intent:

def newsort(a):
from bisect import bisect_right as br
assert a
oldx = a[0]
result = [oldx]
index = 0
for i in range(1, len(a)):
x = a[i]
if x < oldx:
index = br(result, x, 0, index)
else:
index = br(result, x, index + 1)
result.insert(index, x)
oldx = x
return result

Now assuming that's right, I don't care about timing it ;-)  The only
basic question to me is whether it in fact reduces the number of
comparisons.  So here's an integer wrapper that bumps a global counter
whenever it's asked to compare:

class IntWrap(object):
def __init__(self, i):
self.i = i

def __cmp__(a, b):
global gncmp
gncmp += 1
return cmp(a.i, b.i)

def __repr__(self):
return repr(self.i)

Now we can build lists containing that, and get exact comparison
counts.  To start, for a given length `n`, this counts the total
number of comparisons needed to sort all possible permutations of a
list of length n, under both the old and new ways:

def drive(n):
import itertools
global gncmp
base = [IntWrap(i) for i in range(n)]
oldcount = newcount = 0
numperms = 0
for p in itertools.permutations(base):
numperms += 1

gncmp = 0
oldresult = oldsort(p)
oldcount += gncmp

gncmp = 0
newresult = newsort(p)
newcount += gncmp

assert oldresult == newresult == base
print 'n', n, 'perms', numperms
print 'old compares', oldcount
print 'new compares', newcount
print 'diff %', (newcount - oldcount) * 100.0 / max(oldcount, 1)

And, finally, a tiny loop to drive it:

for n in range(1, 13):
print
drive(n)

It's still running as I type this, but the results aren't promising so
far - as soon as the list length gets non-trivial, the new way
requires more comparisons than the old way so far:

n 1 perms 1
old compares 0
new compares 0
diff % 0.0

n 2 perms 2
old compares 2
new compares 2
diff % 0.0

n 3 perms 6
old compares 16
new compares 16
diff % 0.0

n 4 perms 24
old compares 112
new compares 116
diff % 3.57142857143

n 5 perms 120
old compares 848
new compares 880
diff % 3.77358490566

n 6 perms 720
old compares 7008
new compares 7296
diff % 4.1095890411

n 7 perms 5040
old compares 63456
new compares 66432
diff % 4.68986384266

n 8 perms 40320
old compares 628608
new compares 662496
diff % 5.39095907147

n 9 perms 362880
old compares 6826752
new compares 7202304
diff % 5.50118123523

n 10 perms 3628800
old compares 80605440
new compares 85006080
diff % 5.45948263542

I believe it would be very difficult to analyze this rigorously - and
even if I saw an analysis it would be hard to trust it.  Raw counts
from simple code are hard to argue with ;-)

FYI, here are two ideas I had way back when, but didn't pursue:

1. Merge "2 at a time" instead of just 1.  That is, first "sort" the
next 2 elements to be merged (1 compare and a possible swap).  Then
binary search to find where the smaller belongs, and a shorter binary
search to find where the larger belongs.  Then shift both into place.
This can win on two counts:

A. Less data movement, since the already-sorted values after the
larger element get moved only once instead of twice.

B. A possible cut in number of compares.  Merging a sorted list of N
elements with a sorted list of 2 elements has been studied a lot
(e.g., search for "optimal merging of 2 elements" and find the paper
by Hwang and Lin).  The minimum average theoretical number of compares
needed is
ceiling(log2((N+2)*(N+1)/2)).

2. Instead of binary insertion sort, do an ordinary (but optimized)
bottom-up merge sort.  That may not cut the number of compares, but
would slash worst-case data movement cost from O(n**2) to O(n*log(n)).

As to why your code is sometimes faster, for the Python code in your
timing harness, well, that didn't actually sort anything, so wasn't
measuring anything interesting (or even explainable ;-) ).  For the
Java code, I have no guess - I don't know enough about Java internals.
Maybe "lucky" data, maybe cache effects, maybe a mistake - don't know,
and can't guess.  Or maybe my guess (above) at the intent of

[Python-Dev] str.lstrip bug?

2015-03-10 Thread lou xiao 
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] str.lstrip bug?

2015-03-10 Thread Facundo Batista 
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.

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?

2015-03-10 Thread Chris Angelico 
On Wed, Mar 11, 2015 at 4:27 AM, lou xiao  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?

2015-03-10 Thread lou xiao 
ths, i misunderstood the method

2015-03-11 1:33 GMT+08:00 Chris Angelico :

> On Wed, Mar 11, 2015 at 4:27 AM, lou xiao  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?

2015-03-10 Thread Florian Bruhin 
* lou xiao  [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

Re: [Python-Dev] str.lstrip bug?

2015-03-10 Thread Ethan Furman 
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

Re: [Python-Dev] str.lstrip bug?

2015-03-10 Thread Isaac Schwabacher 
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