[issue1128] msilib.Directory.make_short only handles file names with a single dot in them

[Christoph Gohlke]

Christoph Gohlke  added the comment:

A slightly different patch is attached to issue7639, which generates short 
names more similar to Windows/NTFS:
 
http://bugs.python.org/file15898/msilib_make_short.diff

Here are some short names created with the msilib_make_short patch, which are 
identical to the short names created by the Windows NTFS file system:

foo.txt ->  FOO.TXT
foo.2.txt   ->  FOO2~1.TXT
someLongName.txt->  SOMELO~1.TXT
someLongerName.txt  ->  SOMELO~2.TXT

For comparison, the msilib-2 patch generates these short names:

foo.txt ->  FOO.TXT
foo.2.txt   ->  FOO.2.TXT<- different from NTFS
someLongName.txt->  SOMELO~1.TXT
someLongerName.txt  ->  SOMELO~2.TXT

--
nosy: +cgohlke

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6470] Tkinter import fails when running Python.exe from a network share

[Christoph Gohlke]

Christoph Gohlke  added the comment:

This issue is also present in Python 2.7b2.

The svn trunk requires a slightly different patch (attached).

--
versions: +Python 2.7
Added file: http://bugs.python.org/file17304/Tkinter-import-UNCW-trunk.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8692] Use divide-and-conquer for faster factorials

[Mark Dickinson]

Mark Dickinson  added the comment:

Some quick comments:

(1) Agree about the extra bound checks:  let's treat those as a separate issue 
and just concentrate on performance here.

(2) log2 isn't portable:  it's not part of C89 (though it is in C99) and I 
don't think it exists on Windows.  Which is a shame, since it probably *does* 
reliably work well for boundary cases on most platforms.  I'm embarrassed to 
read that snippet that Alexander found, but it's true that an alternative like 
log(n)/log(2) has problems in boundary cases, thanks to the usual 
floating-point issues.  There's a bit-counting method in the int.bit_length() 
implementation (in Objects/longobject.c) that could possibly be re-used here.  
Alternatively, if a simple for-loop to count bits doesn't have any noticeable 
impact on speed, then we could use that.

(3) Is the 'count set bits' code a bottleneck?  If not, then it looks fine to 
me as it is.  Doesn't it just get called once per factorial computation?

(4) I wonder whether the recursion in factorial_part_product slows things down; 
 it might be interesting to compare with an iterative version (but still one 
that clumps together small pieces rather than doing lots of small*big 
multiplies).  It seems possible that the cost of the recursive calls is 
insignificant compared to the cost of the various Py* calls, though.

(5) Was there a reason for using long rather than unsigned long for the 
computations?  Using unsigned long would give you an easily computable 
multiply_cutoff, and save the need for that extra static variable (it could be 
a macro instead).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Py_Initialize: can't initialize sys standard streams

[M. Bashir Al-Noimi]

Hi All,

After installing python-3.1.2.msi I'm not able to run to python.exe at 
all because it gives me the following error message:



Fatal Python error: Py_Initialize: can't initialize sys standard streams
LookupError: unknown encoding: cp720

This application has requested the Runtime to terminate it in an 
unusual way.

Please contact the application's support team for more information.



*How I can fix this issue?*

*PS*

   * I'm using WinXp SP3 32Bit
   * I uninstalled python-2.6.3 before installing python-3.1.2.msi


--
Best Regards
Muhammad Bashir Al-Noimi
My Blog: http://mbnoimi.net

___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8695] Issue while installing Python 2.6.5 in IBM AIX 6.1

[Senthil]

New submission from Senthil :

Hi,
I am trying to install Python 2.6.5 in IBM AIX(6.1) machine. The make seems to 
failing with the following error.

Fatal Python error: Interpreter not initialized (version mismatch?)
make: *** [sharedmods] IOT/Abort trap (core dumped)

--
components: Build
files: logs.zip
messages: 105580
nosy: senthil_l
priority: normal
severity: normal
status: open
title: Issue while installing Python 2.6.5 in IBM AIX 6.1
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file17305/logs.zip

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8693] Py_Initialize: can't initialize sys standard streams

[Muhammad Bashir Al-Noimi]

Muhammad Bashir Al-Noimi  added the comment:

Lie Ryan gave me the solution,

copy 
http://svn.python.org/view/python/branches/py3k/Lib/encodings/cp720.py?view=markup
 to Python31\Lib\encodings

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8695] Issue while installing Python 2.6.5 in IBM AIX 6.1

[Martin v . Löwis]

Martin v. Löwis  added the comment:

Can you propose a patch?

--
nosy: +loewis

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2620] Multiple buffer overflows in unicode processing

[R. David Murray]

Changes by R. David Murray :


--
nosy: +haypo

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue1451466] reading very large files

[christen]

christen  added the comment:

I have no idea because
- I am using 2.5 (windows) or 2.6 (2.5 because of old stuff that I 
compiled compatible with 2.5 not 2.6)
- I am using open(file, 'U') that solved the problem under windows, and 
the pd does not exist in Linux
best
Richard

Terry J. Reedy a écrit :
> Terry J. Reedy  added the comment:
>
> Is this still an issue for 2.7?
>
> --
> nosy: +tjreedy
>
> ___
> Python tracker 
> 
> ___
>
>
>

--
nosy: +richard.chris...@unice.fr

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6610] Subprocess descriptor debacle

[Ezio Melotti]

Changes by Ezio Melotti :


--
nosy: +astrand, pitrou
stage: needs patch -> patch review
versions:  -Python 3.0

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8686] "This isn't defined beyond that" phrase is not friendly to non-native English speakers.

[A.M. Kuchling]

A.M. Kuchling  added the comment:

How about just dropping those words entirely, and writing "Return an 
approximate upper bound on ratio() very quickly.  This is not as accurate as 
ratio(), but is faster to compute."  (We'd make similar changes to 
real_quick_ratio()'s text.)

--
nosy: +akuchling

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8685] set(range(100000)).difference(set()) is slow

[Andrew Bennetts]

Changes by Andrew Bennetts :


Added file: http://bugs.python.org/file17306/set-mem.py

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8685] set(range(100000)).difference(set()) is slow

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> 1. In constrained memory environments, creating a temporary internal
> copy of a large set may cause the difference operation to fail that
> would otherwise succeed.

It's a space/time tradeoff. There's nothing wrong about that.
(do note that hash tables themselves take much more space than the "equivalent" 
list)

> 2. The break-even point between extra lookups and a copy is likely to
> be different on different systems or even on the same system under
> different loads.

So what? It's just a matter of choosing reasonable settings. There are other 
optimization heuristics in the interpreter.

The optimization here looks ok to me.

--
nosy: +pitrou

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8685] set(range(100000)).difference(set()) is slow

[Andrew Bennetts]

Andrew Bennetts  added the comment:

Regarding memory, good question... but this patch turns out to be an 
improvement there too.

This optimisation only applies when len(x) > len(y) * 4.  So the minimum size 
of the result is a set with 3/4 of the elems of x (and possibly would be a full 
copy of x anyway).

So if you like this optimisation is simply taking advantage of the fact we're 
going to be copying almost all of these elements anyway.  We could make it less 
aggressive, but large sets are tuned to be between 1/2 and 1/3 empty internally 
anyway, so 1/4 overhead seems reasonable.

Also, because this code immediately makes the result set be about the right 
size, rather than growing it one element at a time, the memory consumption is 
actually *better*.  I'll attach a script that demonstrates this; for me it 
shows that large_set.difference(small_set) [where large_set has 4M elems, 
small_set has 100] peaks at 50MB memory consumption without my patch, but only 
18MB with.  (after discounting the memory required for large_set itself, etc.)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6610] Subprocess descriptor debacle

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
nosy: +gregory.p.smith

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8697] PEP 391: Adding documentation of logging.config.dictConfig

[A.M. Kuchling]

New submission from A.M. Kuchling :

The attached patch adds a first cut at documenting the PEP 391 dictConfig() 
feature.  I've taken the PEP 391 text and rearranged it to fit into the 
existing logging module docs.  I haven't gone through every paragraph and 
adjusted the markup to use Sphinx roles.

Vinay: I don't think you need to proofread every single bit of text in this 
patch.  I suggest you look at the following things:

* The start of the 'Configuring Logging' section, which I rewrote.

* The description of dictConfig(), which is assembled from several bits of the 
PEP.

* The details of the dictionary schema are moved to be first instead of last.  
I therefore rewrote the paragraph in the PEP beginning "Before describing the 
schema in detail..." to one that begins "Describing a logging configuration 
requires listing..."  Is the new paragraph OK?

If you like the resulting ordering and the rewritten text, then I'll go through 
the rest of the text adding Sphinx markup, and commit the result.

Thanks!

--
assignee: vinay.sajip
components: Documentation
files: pep391-docs.txt
keywords: needs review, patch
messages: 105588
nosy: akuchling, vinay.sajip
priority: low
severity: normal
stage: patch review
status: open
title: PEP 391: Adding documentation of logging.config.dictConfig
versions: Python 2.7
Added file: http://bugs.python.org/file17307/pep391-docs.txt

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8696] PEP 391: Adding documentation of logging.config.dictConfig

[A.M. Kuchling]

New submission from A.M. Kuchling :

The attached patch adds a first cut at documenting the PEP 391 dictConfig() 
feature.  I've taken the PEP 391 text and rearranged it to fit into the 
existing logging module docs.  I haven't gone through every paragraph and 
adjusted the markup to use Sphinx roles.

Vinay: I don't think you need to proofread every single bit of text in this 
patch.  I suggest you look at the following things:

* The start of the 'Configuring Logging' section, which I rewrote.

* The description of dictConfig(), which is assembled from several bits of the 
PEP.

* The details of the dictionary schema are moved to be first instead of last.  
I therefore rewrote the paragraph in the PEP beginning "Before describing the 
schema in detail..." to one that begins "Describing a logging configuration 
requires listing..."  Is the new paragraph OK?

If you like the resulting ordering and the rewritten text, then I'll go through 
the rest of the text adding Sphinx markup, and commit the result.

Thanks!

--
assignee: vinay.sajip
components: Documentation
files: pep391-docs.txt
keywords: needs review, patch
messages: 105587
nosy: akuchling, vinay.sajip
priority: low
severity: normal
stage: patch review
status: open
title: PEP 391: Adding documentation of logging.config.dictConfig
versions: Python 2.7
Added file: http://bugs.python.org/file17308/pep391-docs.txt

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8698] PEP 391: Adding documentation of logging.config.dictConfig

[A.M. Kuchling]

New submission from A.M. Kuchling :

The attached patch adds a first cut at documenting the PEP 391 dictConfig() 
feature.  I've taken the PEP 391 text and rearranged it to fit into the 
existing logging module docs.  I haven't gone through every paragraph and 
adjusted the markup to use Sphinx roles.

Vinay: I don't think you need to proofread every single bit of text in this 
patch.  I suggest you look at the following things:

* The start of the 'Configuring Logging' section, which I rewrote.

* The description of dictConfig(), which is assembled from several bits of the 
PEP.

* The details of the dictionary schema are moved to be first instead of last.  
I therefore rewrote the paragraph in the PEP beginning "Before describing the 
schema in detail..." to one that begins "Describing a logging configuration 
requires listing..."  Is the new paragraph OK?

If you like the resulting ordering and the rewritten text, then I'll go through 
the rest of the text adding Sphinx markup, and commit the result.

Thanks!

--
assignee: vinay.sajip
components: Documentation
files: pep391-docs.txt
keywords: needs review, patch
messages: 105589
nosy: akuchling, vinay.sajip
priority: low
severity: normal
stage: patch review
status: open
title: PEP 391: Adding documentation of logging.config.dictConfig
versions: Python 2.7
Added file: http://bugs.python.org/file17309/pep391-docs.txt

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8697] PEP 391: Adding documentation of logging.config.dictConfig

[A.M. Kuchling]

Changes by A.M. Kuchling :


--
resolution:  -> duplicate
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8698] PEP 391: Adding documentation of logging.config.dictConfig

[A.M. Kuchling]

Changes by A.M. Kuchling :


--
resolution:  -> duplicate
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8692] Use divide-and-conquer for faster factorials

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

On Tue, May 11, 2010 at 5:58 PM, Mark Dickinson  wrote:
> Yes, I'm interested in seeing the pure Python version.

Here is my translation of the reference implementation.

> It could go into test_math, and would be a useful form of documentation.

Note that I copied the reference implementation recursive logic rather
than that in the proposed patch.  It may be better for documentation
this way.

If we end up using something like this in documentation, I would
rename nminusnumofbits() to something more readable.  Maybe "ntwos" or
"count_trailing_zeros" with an explanation why number of factors of 2
in factorial(n) is n - popcount(n).

--
Added file: http://bugs.python.org/file17310/factorial.py

___
Python tracker 

___import functools
import operator

product = functools.partial(functools.reduce, operator.mul)

def naive_factorial(n):
"""Naive implementation of factorial: product([1, ..., n])

>>> naive_factorial(4)
24
"""
return product(range(1, n+1), 1)

def factorial(n):
"""Implementation of Binary-Split Factorial algorithm

See http://www.luschny.de/math/factorial/binarysplitfact.html

>>> for n in range(20):
... assert(factorial(n) == naive_factorial(n))
"""
_, r = loop(n, 1, 1)
return r << nminusnumofbits(n)

def loop(n, p, r):
if n > 2:
p, r = loop(n // 2, p, r)
p *= partial_product(n // 2 + 1 + ((n // 2) & 1),  n - 1 + (n & 1))
r *= p
return p, r

def partial_product(n, m):
if m <= n + 1:
return n
if m == n + 2:
return n * m
k = (n + m) // 2
if k & 1 != 1:
k -= 1
return partial_product(n, k) * partial_product(k + 2, m)

def nminusnumofbits(n):
nb = 0
v = n
while v:
nb += v & 1
v >>= 1
return n - nb


if __name__ == '__main__':
import doctest
doctest.testmod()
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8699] Equality and hashing for functools.partial

[Daniel Urban]

New submission from Daniel Urban :

On python-dev came up an idea [1] to support equality (== and !=) and hashing 
by functools.partial instances.  Van Lindberg provided an implementation 
written in Python [2].  I've made a very similar implementation in C (in 
Modules/_functoolsmodule.c).  The Python equivalent of my code is in 
Lib/test/test_functools.py as the PythonPartialCls class.  The hashing differs 
a little from Van Lindberg's implementation: I'm computing the "normal form" of 
the dict as the sorted list of its items (not as the sorted list of the keys 
followed by the items).  (It was easier to implement this way.)

I haven't made a lot of Python programming in C, so I'm not sure I made 
everything in the right way (especially the reference counting).  Anyway, I'm 
attaching my patch.  I'd appreciate every suggestion, and will try to correct 
my mistakes.
Thanks!

[1] http://mail.python.org/pipermail/python-dev/2010-May/099981.html
[2] http://mail.python.org/pipermail/python-dev/2010-May/06.html

--
components: Extension Modules
files: partial_eq_hash.diff
keywords: patch
messages: 105591
nosy: durban
priority: normal
severity: normal
status: open
title: Equality and hashing for functools.partial
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file17311/partial_eq_hash.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8692] Use divide-and-conquer for faster factorials

[Raghuram Devarakonda]

Changes by Raghuram Devarakonda :


--
nosy: +draghuram

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8692] Use divide-and-conquer for faster factorials

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

On Tue, May 11, 2010 at 10:19 PM, Alexander Belopolsky
 wrote:
..
> Another readability nit:  for me k % 2 == 0 is a more readable check
> for even number than (k & 1) != 1.  Performance-wise the two choices
> are the same, and either can be improved by combining k = (n + m) / 2
> and k & 1 into one ldiv call.

Strike this comment.  For some reason I though GCC would optimize
division by 2 and inline ldiv, but apparently neither is true.

Still,

if ((k & 1) != 1)
  k = k - 1;

looks odd to me. Maybe k += (k & 1) - 1?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8692] Use divide-and-conquer for faster factorials

[Daniel Stutzbach]

Daniel Stutzbach  added the comment:

Thank you both for the valuable feedback.  I'm working on a revised patch that 
incorporates your many suggestions.

I decided to use an iterative version for two reasons:
- the reference has a note at the bottom in a tiny font suggesting it
- I found it counter-intuitive to implement product() as a recursive function.  
I had a much easier time matching the code up with the formula when it was 
implemented iteratively.

I agree that my use of log2() was an ugly hack. ;-)  I'll fix that.

Would it be worthwhile to create a pybits.h and .c that defines 
_Py_FindLastSetBit and _Py_CountSetBits? (with appropriate logic in the .h and 
configure.in to use system/compiler versions if available)

There are already two implementations of find-last-set-bit in Python: 
bits_in_digit() in Objects/longobject.c and hi0bits() in Python/dtoa.c.  It 
would be nice to consolidate them.

(hi0bits counts the leading 0 bits which is a trivial transformation of finding 
the highest set bit)

I don't know of anyplace else in Python that needs count-set-bits.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8692] Use divide-and-conquer for faster factorials

[Daniel Stutzbach]

Daniel Stutzbach  added the comment:

On Wed, May 12, 2010 at 10:31 AM, Alexander Belopolsky
 wrote:
> if ((k & 1) != 1)
>          k = k - 1;
>
> looks odd to me. Maybe k += (k & 1) - 1?

If we change the logic slightly to put the odd entry on the right
instead of the left, we can do:

k = (n + m) / 2;
k |= 1; /* Ensure that k is odd */
left = factorial_part_product(n, k-2);
if (left == NULL) goto done;
right = factorial_part_product(k, m);
if (right == NULL) goto done;

That will split 1*3*5*7*9*11 into (1*3*5) * (7*9*11), just like the
old code.  It will split 1*3*5*7*9 into (1*3) * (5*7*9) while the old
code did (1*3*5) * (7*9), which is fine.

It's easier to read and fewer operations. :-)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8696] PEP 391: Adding documentation of logging.config.dictConfig

[Vinay Sajip]

Vinay Sajip  added the comment:

Andrew - the patch looks good - thanks! A few places were "will be" could be 
replaced with "has been" or some such to indicate that the implementation now 
exists.

Please go ahead with the other changes.

--
keywords:  -needs review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8692] Use divide-and-conquer for faster factorials

[Mark Dickinson]

Mark Dickinson  added the comment:

Now that I've looked at the patch properly:

I'm +1 on including some version of this patch.  At the time that the original 
math.factorial went in (see issue 2138) we were hurrying a bit to get it in 
before the first 2.6 beta, so ended up with a simple implementation, with the 
understanding (I think) that it could be improved later.

It looks like you and Alexander are doing a great job of hammering out the fine 
detail;  I only have a few comments at this stage.  I predict that you're not 
going to like the first one ;-).  The others are just technical issues.

(1) In the interests of simplicity, please could we lose the 'long' 
optimization in factorial_part_product?  That is, get rid of the if (m == n+2) 
branch, and just let that case recurse normally---which means that we end up 
calling PyNumber_Multiply in some cases instead of doing a C long by C long 
multiplication.  Then we can get rid of multiply_cutoff entirely.  I'm +1 on 
the improved algorithm, and I realize that the optimization does have an effect 
(some unscientific tests showed me a 18% speed increase in typical cases) but 
for me this optimization goes past the simplicity/speed tradeoff.  There's 
always the option of adding something like this back in later, once the new 
algorithm's gone in.

(2) You're missing a Py_DECREF(part) in factorial_loop, so factorial(n) leaks 
references (for n > 12).

(3) The line "k = (n + m) / 2;" in factorial_part_product invokes undefined 
behaviour (from signed overflow) if n and m are large.  We're not going to get 
meaningful results in this case anyway, but UB should be avoided if at all 
possible.  Perhaps rewrite this as "k = n + (m - n) / 2;"?

(4) And please do restore the PyLong_FromDouble line in the main routine, 
rather than using a C double-to-long cast.  The direct conversion again leads 
to undefined behaviour for large doubles (cf. C99 6.3.1.4,p2).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8692] Use divide-and-conquer for faster factorials

[Mark Dickinson]

Mark Dickinson  added the comment:

> (cf. C99 6.3.1.4,p2).

Oops.  C99 6.3.1.4,p1.  That'll teach me not to cite chapter and verse.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8700] strip() is removing an extra character if the strip pattern contains "-"

[Balachander Ganesan]

New submission from Balachander Ganesan :

Version:

Python 2.4.3 (#1, Jan 14 2008, 18:31:21)
[GCC 4.1.2 20070626 (Red Hat 4.1.2-14)] on linux2

Description:

When the pattern used for strip contains "-" character then it removes one more 
characters next to it.

>>> a = 'image-abc-1.2.0-12_1234_123'
>>> b = a.strip('image-')
>>> print b
bc-1.2.0-12_1234_123


>From the above print statement we can see that instead of 
>'bc-1.2.0-12_1234_123', it prints only 'bc-1.2.0-12_1234_123'. 
The first character "a" next to "-" is missing.

--
components: Library (Lib)
messages: 105598
nosy: Balachander.Ganesan
priority: normal
severity: normal
status: open
title: strip() is removing an extra character if the strip pattern contains "-"
type: behavior
versions: 3rd party

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8700] strip() is removing an extra character if the strip pattern contains "-"

[R. David Murray]

R. David Murray  added the comment:

The argument to strip is a set of characters to remove, not a substring.

--
nosy: +r.david.murray
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8692] Use divide-and-conquer for faster factorials

[Daniel Stutzbach]

Daniel Stutzbach  added the comment:

On Wed, May 12, 2010 at 12:59 PM, Mark Dickinson  wrote:
> (4) And please do restore the PyLong_FromDouble line in the main routine, 
> rather than using a C double-to-long cast.  The direct conversion again leads 
> to undefined behaviour for large doubles (cf. C99 6.3.1.4,p2).

I was planning to add a "if (dx > (double) LONG_MAX)" check.  Would
that be sufficient?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8696] PEP 391: Adding documentation of logging.config.dictConfig

[A.M. Kuchling]

A.M. Kuchling  added the comment:

Thanks!  Committed to trunk in rev81125.

--
assignee: vinay.sajip -> akuchling
resolution:  -> accepted
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8692] Use divide-and-conquer for faster factorials

[Mark Dickinson]

Mark Dickinson  added the comment:

>I was planning to add a "if (dx > (double) LONG_MAX)" check.  Would
> that be sufficient?

Hmm.  It's subtle.  On an LP64 machine, LONG_MAX will be 2**63-1, which isn't 
exactly representable as a double.  So (double) LONG_MAX would likely be 
2.0**63 exactly (depending on rounding mode, but round-half-to-even is probably 
a safe assumption unless someone's deliberately messing around).  Then that 
check would fail for dx == 2.**63 exactly.

Turn it into '>=' rather than '>', and I *think* it's okay.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8046] mmap.mmap as a context manager

[Brian Curtin]

Changes by Brian Curtin :


--
versions:  -Python 2.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8692] Use divide-and-conquer for faster factorials

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

On Wed, May 12, 2010 at 4:50 AM, Mark Dickinson  wrote:
..
> (4) I wonder whether the recursion in factorial_part_product slows things 
> down;  it might be interesting to compare with an iterative version (but 
> still one that clumps together small pieces rather than doing lots of 
> small*big multiplies).  It seems possible that the cost of the recursive 
> calls is insignificant compared to the cost of the various Py* calls, though.

I am attaching a little study of three different part_product
implementations in python: the recursive one, straight product, and
not-recursive binary division:

$ ./python.exe -m timeit -s "import factorial3 as fm;
fm.partial_product = fm.partial_product; f = fm.factorial " "f(1)"
10 loops, best of 3: 66.1 msec per loop
$ ./python.exe -m timeit -s "import factorial3 as fm;
fm.partial_product = fm.partial_product1; f = fm.factorial "
"f(1)"
10 loops, best of 3: 67.6 msec per loop
$ ./python.exe -m timeit -s "import factorial3 as fm;
fm.partial_product = fm.partial_product2; f = fm.factorial "
"f(1)"
10 loops, best of 3: 43.4 msec per loop

The last one seems to b a clear winner, but I am not certain where the
gain comes from - no recursion or first by last instead of ith by
(i+1)st multiplication.   Also python recursion overhead is probably
different from C.

--
Added file: http://bugs.python.org/file17312/factorial3.py

___
Python tracker 

___import functools
import operator

product = functools.partial(functools.reduce, operator.mul)

def naive_factorial(n):
"""Naive implementation of factorial: product([1, ..., n])

>>> naive_factorial(4)
24
"""
return product(range(1, n+1), 1)

def factorial(n):
"""Implementation of Binary-Split Factorial algorithm

See http://www.luschny.de/math/factorial/binarysplitfact.html

>>> for n in range(20):
... assert(factorial(n) == naive_factorial(n))
>>> import math
>>> assert(factorial(100) == math.factorial(100))
"""
_, r = loop(n)
return r << (n - count_bits(n))

def loop(n):
p = r = 1
for i in range(n.bit_length() - 2, -1, -1):
m = n >> i
if m > 2:
p *= partial_product(((m >> 1) + 1) >> 1, (m - 1) >> 1)
r *= p
return p, r

def partial_product(j, i):
if i == j:
return j << 1 | 1
if i == j + 1:
return (j << 1 | 1) * (i << 1 | 1)
l = i + j >> 1
return partial_product(j, l) * partial_product(l + 1, i)

def partial_product1(j, i):
return product((l << 1 | 1 for l in range(j, i + 1)), 1)

def partial_product2(j, i):
a = [l << 1 | 1 for l in range(j, i + 1)]
n = i - j + 1
p = 1
while n:
n >>= 1
for k in range(n):
a[k] *= a[n-k]
return a[0]

def count_bits(n):
count = 0
while n:
n &= n - 1
count += 1
return count

if __name__ == '__main__':
import doctest
doctest.testmod()
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8692] Use divide-and-conquer for faster factorials

[Mark Dickinson]

Mark Dickinson  added the comment:

Interesting---thanks for the analysis!

Realistically though, I don't see an iterative version of 
factorial_part_product as an option for the C patch, without a significant 
increase in complexity.  Daniel's current patch is remarkably clean and simple, 
and I'd like to keep it that way.

I did think about various evil schemes for an iterative version, but didn't 
come up with anything I'd want to see in the Python codebase.  (The worst of 
these schemes involved using a union of long and PyObject * to try to increase 
the possibilities for doing simple C long multiplication, and using the fact 
that you can easily tell the difference between an odd long and a (4-byte 
aligned) PyObject * just by looking at the last bit.  But I'm fairly sure that 
comes under the 'evil' heading.  :) )

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2138] Add a factorial function

[Mark Dickinson]

Mark Dickinson  added the comment:

maix:  good point.  Fixed in revisions r81126 through r81129.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8694] python3 FAQ mentions unicode()

[Giampaolo Rodola']

Changes by Giampaolo Rodola' :


--
nosy: +ezio.melotti

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8686] "This isn't defined beyond that" phrase is not friendly to non-native English speakers.

[Martin v . Löwis]

Martin v. Löwis  added the comment:

I think it's important to note that this may err towards larger numbers (rather 
than being merely inaccurate).

I also find this "an upper bound on ratio()" difficult to understand. IIUC, it 
is the correct value being bounded, not the result of the function under 
discussion that is bounded (by the correct value).

--
nosy: +loewis

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8692] Use divide-and-conquer for faster factorials

[Alexander Belopolsky]

Alexander Belopolsky  added the comment:

Here is one more datapoint.

$ ./python.exe -m timeit -s "import factorial4 as fm;
fm.partial_product = fm.partial_product; f = fm.factorial " "f(1)"
10 loops, best of 3: 66.1 msec per loop
[32794 refs]
$ ./python.exe -m timeit -s "import factorial4 as fm;
fm.partial_product = fm.partial_product3; f = fm.factorial "
"f(1)"
10 loops, best of 3: 63 msec per loop
[32794 refs]
$ ./python.exe -m timeit -s "import factorial4 as fm;
fm.partial_product = fm.partial_product2; f = fm.factorial "
"f(1)"
10 loops, best of 3: 43.3 msec per loop

partial_product3 multiplies adjacent numbers instead of first by last.
 I am not sure it reproduces the order of multiplication in the
recursive version exactly, but it does show that the order of
multiplication matters a lot.

I wonder if one could write an elegant recursive version that would
multiply first by last in partial_product.

--
Added file: http://bugs.python.org/file17313/factorial4.py

___
Python tracker 

___import functools
import operator

product = functools.partial(functools.reduce, operator.mul)

def naive_factorial(n):
"""Naive implementation of factorial: product([1, ..., n])

>>> naive_factorial(4)
24
"""
return product(range(1, n+1), 1)

def factorial(n):
"""Implementation of Binary-Split Factorial algorithm

See http://www.luschny.de/math/factorial/binarysplitfact.html

>>> for n in range(20):
... assert(factorial(n) == naive_factorial(n))
>>> import math
>>> assert(factorial(100) == math.factorial(100))
"""
_, r = loop(n)
return r << (n - count_bits(n))

def loop(n):
p = r = 1
for i in range(n.bit_length() - 2, -1, -1):
m = n >> i
if m > 2:
p *= partial_product(((m >> 1) + 1) >> 1, (m - 1) >> 1)
r *= p
return p, r

def partial_product(j, i):
if i == j:
return j << 1 | 1
if i == j + 1:
return (j << 1 | 1) * (i << 1 | 1)
l = i + j >> 1
return partial_product(j, l) * partial_product(l + 1, i)

def partial_product1(j, i):
return product((l << 1 | 1 for l in range(j, i + 1)), 1)

def partial_product2(j, i):
a = [l << 1 | 1 for l in range(j, i + 1)]
n = i - j + 1
p = 1
while n:
n >>= 1
for k in range(n):
a[k] *= a[n-k]
return a[0]

def partial_product3(j, i):
a = [l << 1 | 1 for l in range(j, i + 1)]
while 1:
n = len(a)
if n == 1:
return a[0]
a = [a[k<<1] * a[k<<1|1] for k in range(n>>1)] + a[(n >> 1)<<1:]


def count_bits(n):
count = 0
while n:
n &= n - 1
count += 1
return count

if __name__ == '__main__':
#print(partial_product(10, 20))
import doctest
doctest.testmod()
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8686] "This isn't defined beyond that" phrase is not friendly to non-native English speakers.

[Tim Peters]

Tim Peters  added the comment:

I find this whole discussion to be hilarious ;-)

"Approximate upper bound" is gibberish - "upper bound" is a crisp concept that 
means what it says.  It's not necessarily true that an upper bound is 
inaccurate - it may be exactly right.  So "this is not as accurate as ratio()" 
overstates the case.

"quick_ratio() returns an upper bound on what ratio() returns" is the truth, 
and can't be improved by adding more words.   Appealing to a "correct" result 
would also be misleading (what ratio() returns is a more-or-less arbitrary 
computation whose only claim to "correctness" is that ratio() returns what it's 
documented to return).

If people find the gloss in the docs confusing, remove the gloss entirely, 
leaving just the correct:

"Return an upper bound on ratio() relatively quickly."

--
nosy: +tim_one

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8701] tarfile: first character of member names doubled

[Poor Yorick]

New submission from Poor Yorick :

In the following file, for python 2.6.4, tarfile.list doubles the first 
character of each member name:

http://watson.nci.nih.gov/cran_mirror/src/contrib/Archive/time/time_1.0.tar.gz

gnu tar handles the file correctly

--
components: Library (Lib)
messages: 105609
nosy: pooryorick
priority: normal
severity: normal
status: open
title: tarfile: first character of member names doubled
versions: Python 2.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8692] Use divide-and-conquer for faster factorials

[Daniel Stutzbach]

Daniel Stutzbach  added the comment:

On Wed, May 12, 2010 at 3:34 PM, Alexander Belopolsky
 wrote:
> I wonder if one could write an elegant recursive version that would
> multiply first by last in partial_product.

That could be done with a three-parameter partial_product, where the
third parameter designates how many numbers to multiply.  Something
like this:

part_product(9, 17, 5) -> 9*11*13*15*17
  part_product(9, 17, 2) -> 9*17
  part_product(11, 15, 3) -> 11*13*15

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3621] it would be nice if installers made by bdist_wininst stored an EstimatedSize property in the Windows registry

[Jason Spiro]

Jason Spiro  added the comment:

> Can you provide a patch?

Unfortunately not.  I still don't think it's worth fixing this bug.  :)  I 
think you should document it in the bdist_wininst documentation then close this 
bug as "won't fix due to lack of volunteer resources".  That way the problem 
will be documented both here and in that documentation, but nobody need spend 
the time to fix such a minor bug.

Or at least you should lower this bug's priority to the lowest setting.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3605] Py_FatalError causes infinite loop

[Jeffrey Yasskin]

Jeffrey Yasskin  added the comment:

I have a fix at http://codereview.appspot.com/1184043, which makes 
PyErr_Occurred() return NULL when there is no thread.  I'll commit it tomorrow 
unless there are comments.

--
assignee:  -> jyasskin
keywords: +needs review
nosy: +jyasskin
stage: unit test needed -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8016] Support for cp858

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
nosy: +haypo, lemburg
stage:  -> patch review
versions: +Python 3.2 -Python 2.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8687] sched.py module doesn't have a test suite

[Antoine Pitrou]

Antoine Pitrou  added the comment:

You know, one benefit of having user-settable sleep() and time() functions is 
that you can mock them easily, and therefore check that sched.py really 
schedules callables at the right intervals.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8687] sched.py module doesn't have a test suite

[Giampaolo Rodola']

Giampaolo Rodola'  added the comment:

I agree. Are you recommending to take advantage of this and change the tests in 
some way?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8687] sched.py module doesn't have a test suite

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> I agree. Are you recommending to take advantage of this and change the
> tests in some way?

Yes, it would allow you to check that if you have e.g. :
- A scheduled in 1 s
- B scheduled in 3 s

sched.py first sleeps for 1 s, then calls A, then sleeps for 2 s, then
calls B

Twisted has a full-blown utility class that they use in many tests,
allowing them to mock time.time():
http://twistedmatrix.com/documents/10.0.0/api/twisted.internet.task.Clock.html
You probably don't need something as sophisticated, the idea of a class
with advance() and time() methods is probably enough.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue3621] it would be nice if installers made by bdist_wininst stored an EstimatedSize property in the Windows registry

[Martin v . Löwis]

Changes by Martin v. Löwis :


--
priority: normal -> low

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8256] TypeError: bad argument type for built-in operation

[STINNER Victor]

STINNER Victor  added the comment:

This issue is directly related to issue #6697. The first problem is that the 
builtin input() function doesn't check that _PyUnicode_AsString() result is not 
NULL.

The second problem is that io.StringIO().encoding is None. I don't understand 
why it is None whereas it uses utf8 (it calls TextIOWrapper constructor with 
encodings="utf8" and errors="strict").

I will be difficult to write an unit test because the issue only occurs if 
stdin and stdout are TTY: input() calls PyOS_Readline(stdin, stdout, prompt). 

--

@gruszczy: You're patch is just a workaround, not the right fix. The problem 
should be fixed in input(), not in PyUnicode methods. _PyUnicode_AsString() 
expects an unicode argument, it should raise an error if the argument is None 
(and not return a magical value).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8256] input() doesn't catch _PyUnicode_AsString() exception; io.StringIO().encoding is None

[STINNER Victor]

Changes by STINNER Victor :


--
title: TypeError: bad argument type for built-in operation -> input() doesn't 
catch _PyUnicode_AsString() exception; io.StringIO().encoding is None

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7978] SocketServer doesn't handle syscall interruption

[Yaniv Aknin]

Changes by Yaniv Aknin :


Removed file: http://bugs.python.org/file16841/socketserver_eintr_py3k.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7978] SocketServer doesn't handle syscall interruption

[Yaniv Aknin]

Yaniv Aknin  added the comment:

While bda's usecase is indeed fixed is recent versions, I want to point out the 
issue still exists in a recent py3k checkout. I've updated my patch to apply 
cleanly against recent py3k (and made less structural changes to 
test_socketserver.py; I still think it has an archaic unittest structure but I 
want this patch to remain relevant a bit longer, maybe fix the structure at a 
later time).

Again, I argue that resolving the general case (a generic untilConcludes to be 
exposed in stdlib) is hard and that we have a patch review worthy (IMO) 
solution at hand. Let's apply it (and possibly open a separate ticket for the 
generic case, if that's deemed interesting).

--
Added file: 
http://bugs.python.org/file17314/socketserver_eintr_py3k_updated.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2716] Reimplement audioop because of copyright issues

[STINNER Victor]

STINNER Victor  added the comment:

I found severe bugs (which may lead to security vulnerabilities) in audioop: 
#7673. Nobody fixed these errors (but my issue contains a patch).

--
nosy: +haypo

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue4653] Patch to fix typos for Py3K

[STINNER Victor]

Changes by STINNER Victor :


--
nosy: +haypo

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8678] crashers in rgbimg

[STINNER Victor]

STINNER Victor  added the comment:

See also #7673 (other crashers).

--
nosy: +haypo

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8670] c_types.c_wchar should not assume that sizeof(wchar_t) == sizeof(Py_UNICODE)

[STINNER Victor]

Changes by STINNER Victor :


--
components: +Unicode

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8538] Add ConfigureAction to argparse

[Yaniv Aknin]

Yaniv Aknin  added the comment:

I'm looking into making a patch from this for py3k, and have the following 
observations:

1. I agree with merwok, at the moment the monolithic ConfigureAction is a bit 
excessive for most uses (other than maybe emulating ./Configure...). I vote we 
split it to FlagAction and ConfigureAction.
2. I don't think this should be added as an argparse builtin/registered action 
(like action='store' or action='count'), but rather as a ready-made user-action 
in a separate namespace (from argparse.actions import FlagAction)

Given feedback that these two decisions seem sane, I'd be happy to produce a 
patch against recent py3k.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8670] c_types.c_wchar should not assume that sizeof(wchar_t) == sizeof(Py_UNICODE)

[STINNER Victor]

Changes by STINNER Victor :


--
nosy: +haypo

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue7689] Pickling of classes with a metaclass and copy_reg

[Bryan Silverthorn]

Changes by Bryan Silverthorn :


--
nosy: +bsilverthorn

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8649] Py_UNICODE_* functions are undocumented

[STINNER Victor]

Changes by STINNER Victor :


--
nosy: +haypo

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8648] The UTF-7 codec functions are undocumented

[STINNER Victor]

Changes by STINNER Victor :


--
nosy: +haypo

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8647] PyUnicode_GetMax is undocumented

[STINNER Victor]

Changes by STINNER Victor :


--
nosy: +haypo

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8646] PyUnicode_EncodeDecimal is undocumented

[STINNER Victor]

Changes by STINNER Victor :


--
nosy: +haypo

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8645] PyUnicode_AsEncodedObject is undocumented

[STINNER Victor]

Changes by STINNER Victor :


--
nosy: +haypo

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8591] update mkpkg to latest coding standards

[Dan Buch]

Dan Buch  added the comment:

I've started work on cleanup of ``mkpkg.py`` per instruction from jafo, am 
pushing to a branch 'mbh/mkpkg-cleanup' of my distutils2 fork:

http://bitbucket.org/meatballhat/distutils2/changeset/be40174c59e2

I'll attach patch(es) when finished :)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8657] urlparse.urlunsplit should be smarter about +

[Senthil Kumaran]

Senthil Kumaran  added the comment:

I have added 'git' and 'git+ssh' under known schemes which will recognize 
authority/netloc and follow consistent round trip parsing behaviors.

For any unknown scheme(x or git+file), it might required to update the 
uses_netloc in the application.

git+ and svn+ might not be a good idea, as git+foobar like terms might cause 
ambiguity.

Fixed in r81130, r81131, r81132 and r81133.

--
resolution: accepted -> fixed
stage: patch review -> committed/rejected
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue6610] Subprocess descriptor debacle

[Gregory P. Smith]

Gregory P. Smith  added the comment:

Thanks for the test!  I'll take a look and likely commit this later.

--
assignee:  -> gregory.p.smith

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com