[issue22491] Support Unicode line boundaries in regular expression

[Serhiy Storchaka]

New submission from Serhiy Storchaka:

Currently regular expressions support on '\n' as line boundary. To meet Unicode 
standard requirement RL1.6 [1] all Unicode line separators should be supported: 
'\n', '\r', '\v', '\f', '\x85', '\u2028', '\u2029' and two-character '\r\n'. 
Also it is recommended that '.' in "dotall" mode matches '\r\n'. Also strongly 
recommended to support the '\R' pattern which matches all line separators 
(equivalent to '(?:\\r\n|(?!\r\n)[\n\v\f\r\x85\u2028\u2029]').

>>> [m.start() for m in re.finditer('$', '\r\n\n\r', re.M)]
[1, 2, 4]  # should be [0, 2, 3, 4]
>>> [m.start() for m in re.finditer('^', '\r\n\n\r', re.M)]
[0, 2, 3]  # should be [0, 2, 3, 4]
>>> [m.group() for m in re.finditer('.', '\r\n\n\r', re.M|re.S)]
['\r', '\n', '\n', '\r']  # should be ['\r\n', '\n', '\r']
>>> [m.group() for m in re.finditer(r'\R', '\r\n\n\r')]
[]  # should be ['\r\n', '\n', '\r']

[1] http://www.unicode.org/reports/tr18/#RL1.6

--
components: Extension Modules, Regular Expressions
messages: 227508
nosy: ezio.melotti, mrabarnett, pitrou, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: Support Unicode line boundaries in regular expression
type: enhancement
versions: Python 3.5

___
Python tracker 

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

[issue22486] Speed up fractions.gcd()

[Mark Dickinson]

Mark Dickinson added the comment:

In case it's useful, see issue #1682 for my earlier Lehmer gcd implementation.  
 At the time, that approach was dropped as being premature optimisation.

--
nosy: +mark.dickinson

___
Python tracker 

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

[issue17319] http.server.BaseHTTPRequestHandler send_response_only doesn't check the type and value of the code.

[karl]

karl added the comment:

Where this is defined in the new RFC.

http://tools.ietf.org/html/rfc7230#section-3.1.2

 status-line = HTTP-version SP status-code SP reason-phrase CRLF

Things to enforce

 status-code= 3DIGIT

Response status code are now defined in 
http://tools.ietf.org/html/rfc7231#section-6
with something important.

   HTTP status codes are extensible.  HTTP clients are not required to
   understand the meaning of all registered status codes, though such
   understanding is obviously desirable.  However, a client MUST
   understand the class of any status code, as indicated by the first
   digit, and treat an unrecognized status code as being equivalent to
   the x00 status code of that class, with the exception that a
   recipient MUST NOT cache a response with an unrecognized status code.

   For example, if an unrecognized status code of 471 is received by a
   client, the client can assume that there was something wrong with its
   request and treat the response as if it had received a 400 (Bad
   Request) status code.  The response message will usually contain a
   representation that explains the status.

That should help.

The full registry of status code is defined here
http://www.iana.org/assignments/http-status-codes/http-status-codes.xhtml


@dmi.baranov 

In the patch
+def _is_valid_status_code(code):
+return isinstance(code, int) and 0 <= code <= 999

Maybe there is a missing check where the len(str(code)) == 3

--

___
Python tracker 

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

[issue22490] Using realpath for __PYVENV_LAUNCHER__ makes Homebrew installs fragile

[Tim Smith]

New submission from Tim Smith:

Homebrew, the OS X package manager, distributes python3 as a framework build. 
We like to be able to control the shebang that gets written to scripts 
installed with pip. [1]

The path we prefer for invoking the python3 interpreter is like 
/usr/local/opt/python3/bin/python3.4, which is symlinked to the framework stub 
launcher at 
/usr/local/Cellar/python3/3.4.1_1/Frameworks/Python.framework/Versions/3.4/bin/python3.4.
 For Python 2.x, we discovered that assigning 
"/usr/local/opt/python/bin/python2.7" to sys.executable in sitecustomize.py 
resulted in correct shebangs for scripts installed by pip. The same approach 
doesn't work with Python 3.

A very helpful conversation with Vinay Sajip [2] led us to consider how the 
python3 stub launcher sets __PYVENV_LAUNCHER__, which distlib uses in 
preference to sys.executable to discover the intended interpreter when pip 
writes shebangs.

Roughly, __PYVENV_LAUNCHER__ is set from argv[0], so it mimics the invocation 
of the stub, except that symlinks in the directory component of the path to the 
identified interpreter are resolved to a "real" path. For us, this means that 
__PYVENV_LAUNCHER__ (and therefore the shebangs of installed scripts) always 
points to the Cellar path, not the preferred opt path, even when python is 
invoked via the opt path.

Avoiding this symlink resolution would allow us to control pip's shebang (which 
sets the shebangs of all pip-installed scripts) by controlling the way we 
invoke python3 when we use ensurepip during installation.

Building python3 with the attached diff removes the symlink resolution.

[1]  This is important to Homebrew because packages are physically installed to 
versioned prefixes, like /usr/local/Cellar/python3/3.4.1_1/. References to 
these real paths are fragile and break when the version number changes or when 
the revision number ("_1") changes, when can happen when e.g. openssl is 
released and Python needs to be recompiled against the new library. To avoid 
this breakage, Homebrew maintains a version-independent symlink to each 
package, like /usr/local/opt/python3, which points to the 
.../Cellar/python3/3.4.1_1/ location.

[2] https://github.com/pypa/pip/issues/2031

--
assignee: ronaldoussoren
components: Macintosh
files: dont-realpath-venv-dirname.diff
keywords: patch
messages: 227505
nosy: ned.deily, ronaldoussoren, tdsmith, vinay.sajip
priority: normal
severity: normal
status: open
title: Using realpath for __PYVENV_LAUNCHER__ makes Homebrew installs fragile
type: behavior
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file36718/dont-realpath-venv-dirname.diff

___
Python tracker 

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

[issue15799] httplib client and statusline

[karl]

karl added the comment:

Let's close this.

>>> "HTTP/1.1301 ".split(None, 2)
['HTTP/1.1', '301']
>>> "HTTP/1.1301 ".split(' ', 2)
['HTTP/1.1', '', '  301 ']

I think it would be nice to have a way to warn without stopping, but the last 
comment from r.david.murray makes sense too. :)

--
resolution:  -> not a bug
status: open -> closed

___
Python tracker 

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

[issue22489] .gitignore file

[Ned Deily]

Changes by Ned Deily :


--
nosy: +zach.ware

___
Python tracker 

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

[issue21645] asyncio: Race condition in signal handling on FreeBSD

[Roundup Robot]

Roundup Robot added the comment:

New changeset fe456770b454 by Yury Selivanov in branch 'default':
asyncio: Reverting 69d474dab479 as issue #21645 is now closed and debug is no 
longer needed
https://hg.python.org/cpython/rev/fe456770b454

--

___
Python tracker 

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

[issue21566] make use of the new default socket.listen() backlog argument

[Yury Selivanov]

Yury Selivanov added the comment:

Guys, when you update asyncio code, please make sure you sync your changes with 
its upstream here: https://code.google.com/p/tulip/ to avoid commits like this 
5f001ad90373

The goal is to have single source base for 3.4 and 3.5 in cpython repo and for 
3.3 in tulip repo, to simplify syncing updates between them.

--
nosy: +yselivanov

___
Python tracker 

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

[issue5550] [urllib.request]: Comparison of HTTP headers should be insensitive to the case

[karl]

Changes by karl :


Removed file: http://bugs.python.org/file36698/issue-5550-4.patch

___
Python tracker 

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

[issue5550] [urllib.request]: Comparison of HTTP headers should be insensitive to the case

[karl]

karl added the comment:

OK after fixing my repo (Thanks orsenthil) I got the tests running properly. 
The inspection order of the two dictionary was not right, so I had to modify a 
bit the patch.

→ ./python.exe -m unittest -v 
Lib.test.test_urllib2net.OtherNetworkTests.test_headers_case_sensitivity
test_headers_case_sensitivity (Lib.test.test_urllib2net.OtherNetworkTests) ... 
ok

--
Ran 1 test in 0.286s

OK

→ ./python.exe -m unittest -v 
Lib.test.test_urllib2net.OtherNetworkTests.test_custom_headers
test_custom_headers (Lib.test.test_urllib2net.OtherNetworkTests) ... ok

--
Ran 1 test in 0.575s

OK


New patch issue5550-5.patch
unlinking issue5550-4.patch

--
Added file: http://bugs.python.org/file36717/issue5550-5.patch

___
Python tracker 

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

[issue19746] No introspective way to detect ModuleImportFailure in unittest

[Robert Collins]

Robert Collins added the comment:

Right: the existing code stringifies the original exception and creates an 
exception object and a closure
def test_thing(self):
raise exception_obj

but that has the stringified original exception.

--

___
Python tracker 

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

[issue22457] load_tests not invoked in root __init__.py when start=package root

[Robert Collins]

Robert Collins added the comment:

Updated patch - fixes windows tests for this patch.

--
Added file: http://bugs.python.org/file36716/issue22457.diff

___
Python tracker 

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

[issue22489] .gitignore file

[Robert Collins]

New submission from Robert Collins:

The .gitignore file was missing some build products on windows. The attached 
patch makes the tree be clean after doing a debug build.

--
files: windows-git-ignore.diff
keywords: patch
messages: 227498
nosy: rbcollins
priority: normal
severity: normal
status: open
title: .gitignore file
Added file: http://bugs.python.org/file36715/windows-git-ignore.diff

___
Python tracker 

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

[issue16662] load_tests not invoked in package/__init__.py

[Robert Collins]

Changes by Robert Collins :


Removed file: http://bugs.python.org/file36713/fix-windows-tests.patch

___
Python tracker 

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

[issue16662] load_tests not invoked in package/__init__.py

[Robert Collins]

Robert Collins added the comment:

bah, wrong extension to trigger review code :)

--
Added file: http://bugs.python.org/file36714/fix-windows-tests.diff

___
Python tracker 

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

[issue16662] load_tests not invoked in package/__init__.py

[Robert Collins]

Robert Collins added the comment:

Fix up the tests patch - tested on windows 7.

--
Added file: http://bugs.python.org/file36713/fix-windows-tests.patch

___
Python tracker 

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

[issue22484] Build doc archives for RC versions, docs download broken for 3.4.2rc1

[Roundup Robot]

Roundup Robot added the comment:

New changeset 8ce21ffc6df5 by Benjamin Peterson in branch '3.4':
allow archives for rc releases to be built (closes #22484)
https://hg.python.org/cpython/rev/8ce21ffc6df5

New changeset 7d6297450943 by Benjamin Peterson in branch 'default':
merge 3.4 (#22484)
https://hg.python.org/cpython/rev/7d6297450943

New changeset 22a46f05ce23 by Benjamin Peterson in branch '2.7':
allow archives for rc releases to be built (closes #22484)
https://hg.python.org/cpython/rev/22a46f05ce23

--
nosy: +python-dev
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

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

[issue22484] Build doc archives for RC versions, docs download broken for 3.4.2rc1

[Ned Deily]

Ned Deily added the comment:

This problem is currently resulting in 404's for 3.4.2rc1 documention 
downloads, e.g. the links on:

https://docs.python.org/3.4/download.html

--
nosy: +ned.deily
priority: high -> critical
title: Build doc archives for RC versions -> Build doc archives for RC 
versions, docs download broken for 3.4.2rc1

___
Python tracker 

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

[issue22488] 3.4 rc2 docs download link broken

[Ned Deily]

Changes by Ned Deily :


--
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Build doc archives for RC versions

___
Python tracker 

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

[issue22488] 3.4 rc2 docs download link broken

[Senthil Kumaran]

New submission from Senthil Kumaran:

Reported by John Jeffers on docs mailing list.

https://docs.python.org/3.4/download.html  (3.4.2rc1)
Return Error 404  (Your other pages are fine)!

--
messages: 227493
nosy: larry, orsenthil
priority: normal
severity: normal
status: open
title: 3.4 rc2 docs download link broken

___
Python tracker 

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

[issue21821] The function cygwinccompiler.is_cygwingcc leads to FileNotFoundError under Windows 7

[Aaron Meurer]

Aaron Meurer added the comment:

The issue is that that the Anaconda gcc on Windows is a bat file, so it can't 
find it. Another fix would be to use find_executable. This is because Anaconda 
has patched find_executalbe (which it also would be good to get backported)

diff --git Lib/distutils/spawn.py Lib/distutils/spawn.py
index b1c5a44..4703f00 100644
--- Lib/distutils/spawn.py
+++ Lib/distutils/spawn.py
@@ -156,17 +156,16 @@ def find_executable(executable, path=None):
 path = os.environ['PATH']

 paths = path.split(os.pathsep)
-base, ext = os.path.splitext(executable)
-
-if (sys.platform == 'win32') and (ext != '.exe'):
-executable = executable + '.exe'
-
-if not os.path.isfile(executable):
-for p in paths:
-f = os.path.join(p, executable)
-if os.path.isfile(f):
-# the file exists, we have a shot at spawn working
-return f
-return None
-else:
-return executable
+
+for ext in '.exe', '.bat', '':
+newexe = executable + ext
+
+if os.path.isfile(newexe):
+return newexe
+else:
+for p in paths:
+f = os.path.join(p, newexe)
+if os.path.isfile(f):
+# the file exists, we have a shot at spawn working
+return f
+return None

--

___
Python tracker 

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

[issue22487] ABC register doesn't check abstract methods

[R. David Murray]

R. David Murray added the comment:

Python is a consenting adults language.  If you call register, we assume you 
know what you are doing.  The isinstance check, on the other hand, does look in 
certain cases.  So if you define __iter__ you don't have to call register to 
make isinstance(o, Iterable) be True.

--
nosy: +r.david.murray
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 

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

[issue22487] ABC register doesn't check abstract methods

[Ryan McCampbell]

Ryan McCampbell added the comment:

Obviously, I meant isinstance(o, Collections.Iterable).

--

___
Python tracker 

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

[issue22487] ABC register doesn't check abstract methods

[Ryan McCampbell]

New submission from Ryan McCampbell:

Is there a reason register() doesn't check for abstract methods, like 
subclassing does? Would it fail for some builtin classes? It seems that this 
would be a better guarantee that, say, something really is iterable when you 
check isinstance(Collections.Iterable, o), since someone could have called 
Collections.Iterable.register(o.__class__) without adding an __iter__ method to 
their class.

--
messages: 227489
nosy: rmccampbell7
priority: normal
severity: normal
status: open
title: ABC register doesn't check abstract methods
type: enhancement

___
Python tracker 

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

[issue22464] Speed up fractions implementation

[Stefan Behnel]

Stefan Behnel added the comment:

I created issue 22486 about the gcd() performance. I think we can close this 
ticket - I don't see any more obvious low hanging fruit and future findings can 
have their own ticket.

Out of interest, I modified the fractions module to compile Fraction into an 
extension type with Cython. For the benchmark, it currently gives me a 10x 
speedup over the original fractions module in Py3.4. I uploaded my initial 
attempt to PyPI and it's on github:

https://pypi.python.org/pypi/quicktions

https://github.com/scoder/quicktions

That makes a C implementation of Fraction generally worth considering for 
CPython.

--
resolution:  -> fixed
status: open -> closed

___
Python tracker 

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

[issue22486] Speed up fractions.gcd()

[Stefan Behnel]

New submission from Stefan Behnel:

fractions.gcd() is required for normalising numerator and denominator of the 
Fraction data type. Some speed improvements were applied to Fraction in issue 
22464, now the gcd() function takes up about half of the instantiation time in 
the benchmark in issue 22458, which makes it quite a heavy part of the overall 
Fraction computation time.

The current implementation is

def gcd(a, b):
while b:
a, b = b, a%b
return a

Reimplementing it in C would provide for much faster calculations. Here is a 
Cython version that simply drops the calculation loop into C as soon as the 
numbers are small enough to fit into a C long long int:

def _gcd(a, b):
# Try doing all computation in C space.  If the numbers are too large
# at the beginning, retry until they are small enough.
cdef long long ai, bi
while b:
try:
ai, bi = a, b
except OverflowError:
pass
else:
# switch to C loop
while bi:
ai, bi = bi, ai%bi
return ai
a, b = b, a%b
return a

It's substantially faster already because the values will either be small 
enough right from the start or quickly become so after a few iterations with 
Python objects.

Further improvements should be possible with a dedicated PyLong implementation 
based on Lehmer's GCD algorithm:

https://en.wikipedia.org/wiki/Lehmer_GCD_algorithm

--
components: Library (Lib)
messages: 227487
nosy: scoder
priority: normal
severity: normal
status: open
title: Speed up fractions.gcd()
type: performance
versions: Python 3.5

___
Python tracker 

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

[issue22477] GCD in Fractions

[gladman]

gladman added the comment:

On 24/09/2014 17:24, Wolfgang Maier wrote:
> 
> Wolfgang Maier added the comment:
[snip]

> An aspect that hasn't really been discussed so far on the mailing list is 
> that this is *not* only about whether the gcd of negative integers should be 
> negative or positive, but also about the fact that in the current 
> implementation the result of gcd is dependent on the order of the arguments:
> 
 gcd(-3,6) == gcd(6,-3)
> False
> 
> which I think is clearly unexpected.

Yes, that's another interesting surprise.

> Ironically, though, the proposed new gcd would make this slower than it has 
> to be since it would do the abs() repeatedly, when
> 
> abs(reduce(_gcd, (3,6,9))) would suffice.
> 
> So, I guess that's the tradeoff coming with the proposed change:

I must admit to being more than a little hazy about what is fast and
what isn't in the Python interpreter but wouldn't the use of reduce to
repeatedly call _gcd be slower than an alternative that avoids this?

Taking on board one of Steven D'Aprano's thoughts about multiple inputs,
I had envisaged something like this:

def mgcd(a, *r):  # multiple gcd
  for b in r:
while b:
  a, b = b, a % b
  return abs(a)

which gives:

>>> mgcd(0)
0
>>> mgcd(7, 0)
7
>>> mgcd(0, 7)
7
>>> mgcd(-3, -7)
1
>>> mgcd(-3, 7)
1
>>> mgcd(7, -3)
1
mgcd(-21, -91, 707)
7

So it has the properties that I believe it should have (yes, I know we
don't agree on this). I am not sure I would extend it to rationals,
although I don't feel strongly about this.

This could be introduced elsewhere without changing what is done in
fractions.  Having two 'gcd's that return different results in some
circumstances might be a source of confusion for some - but not more
than already exists about what values the gcd should return :-)

PS I just know that I am going to regret posting code 'on the hoof' -
it's almost certain to be wrong :-)

--

___
Python tracker 

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

[issue17381] IGNORECASE breaks unicode literal range matching

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Here is other patch for 3.4. It is more than 10 times faster than initial patch 
in worst case.

--
Added file: http://bugs.python.org/file36712/re_ignore_case_range-3.4_2.patch

___
Python tracker 

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

[issue22484] Build doc archives for RC versions

[R. David Murray]

R. David Murray added the comment:

Why would this not also be an issue for alpha/beta?

--
nosy: +r.david.murray

___
Python tracker 

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

[issue22485] Documentation download links (3.4.2

[Carol Willing]

Carol Willing added the comment:

Thanks Berker. I'm glad it's being addressed and you have submitted a patch.

--

___
Python tracker 

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

[issue22485] Documentation download links (3.4.2

[Berker Peksag]

Berker Peksag added the comment:

Thanks for the report. This is a duplicate of issue 22484.

--
nosy: +berker.peksag
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Build doc archives for RC versions

___
Python tracker 

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

[issue22477] GCD in Fractions

[gladman]

gladman added the comment:

On 24/09/2014 19:01, Mark Dickinson wrote:
> 
> Mark Dickinson added the comment:
> 
>> The negative of the greatest common divisor is the least common divisor in 
>> an integer range.
> 
> That depends on your choice of definitions: it's perfectly reasonable to see 
> it as another greatest common divisor, if you interpret "greatest" as being 
> with respect to the divisibility lattice, not the total ordering of Z.  
> That's in some sense the correct interpretation, because it's the one that 
> generalises to other interesting rings: for example, the Gaussian integers 
> have a well-defined and useful notion of greatest common divisor, but aren't 
> ordered, and the ring Z[sqrt 3] similarly has well-defined greatest common 
> divisors (defined up to multiplication by a unit, as usual) *and* a total 
> ordering, but "greatest" *can't* be interpreted in the ordering sense in that 
> case (because there are infinitely many units).
> 
> Many textbooks will talk about "a greatest common divisor" rather than "the 
> greatest common divisor".  In that sense, -3 *is* a greatest common divisor 
> of 6 and -15.

Then the Python documentation should say 'a greatest ...', not 'the
greatest ...' since those who deny that the integer gcd is non-negative
can hardly deny that a positive alternative value exists :-)

--

___
Python tracker 

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

[issue22485] Documentation download links (3.4.2

[Ezio Melotti]

Changes by Ezio Melotti :


--
nosy: +larry, terry.reedy

___
Python tracker 

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

[issue22485] Documentation download links (3.4.2

[Carol Willing]

New submission from Carol Willing:

As reported by a couple of users on the python-docs mailing list:

Python 3.4.2rc1 docs are giving a 404 Not Found when clicking on the links to 
download (https://docs.python.org/3.4/download.html).

Python 3.5.0a0 links download docs correctly 
(https://docs.python.org/3.5/download.html).

If I option-click on a Mac, I can download Python 3.4.2rc1 docs; however, the 
direct links 404.

--
assignee: docs@python
components: Documentation
messages: 227480
nosy: docs@python, willingc
priority: normal
severity: normal
status: open
title: Documentation download links (3.4.2
type: behavior
versions: Python 3.4

___
Python tracker 

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

[issue22484] Build doc archives for RC versions

[Berker Peksag]

New submission from Berker Peksag:

The attached patch partly reverts 
https://hg.python.org/cpython/rev/48033d90c61d#l2.126 since it breaks building 
doc archives for RC versions:

- https://mail.python.org/pipermail/docs/2014-September/020211.html
- https://mail.python.org/pipermail/docs/2014-September/020214.html
- https://mail.python.org/pipermail/docs/2014-September/020215.html

See https://hg.python.org/cpython/rev/ecfb6f8a7bcf for the original changeset.

--
assignee: docs@python
components: Documentation
files: autobuild.diff
keywords: patch
messages: 227479
nosy: benjamin.peterson, berker.peksag, docs@python
priority: high
severity: normal
stage: patch review
status: open
title: Build doc archives for RC versions
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file36711/autobuild.diff

___
Python tracker 

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

[issue22477] GCD in Fractions

[Mark Dickinson]

Mark Dickinson added the comment:

> The negative of the greatest common divisor is the least common divisor in an 
> integer range.

That depends on your choice of definitions: it's perfectly reasonable to see it 
as another greatest common divisor, if you interpret "greatest" as being with 
respect to the divisibility lattice, not the total ordering of Z.  That's in 
some sense the correct interpretation, because it's the one that generalises to 
other interesting rings: for example, the Gaussian integers have a well-defined 
and useful notion of greatest common divisor, but aren't ordered, and the ring 
Z[sqrt 3] similarly has well-defined greatest common divisors (defined up to 
multiplication by a unit, as usual) *and* a total ordering, but "greatest" 
*can't* be interpreted in the ordering sense in that case (because there are 
infinitely many units).

Many textbooks will talk about "a greatest common divisor" rather than "the 
greatest common divisor".  In that sense, -3 *is* a greatest common divisor of 
6 and -15.

--

___
Python tracker 

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

[issue22482] logging: fileConfig doesn't support formatter styles

[Vinay Sajip]

Vinay Sajip added the comment:

While fileConfig() is not deprecated, I'm not planning to enhance it, as the 
newer dictConfig() API offers better functionality overall. With dictConfig(), 
you do have support for alternative formatting styles.

--

___
Python tracker 

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

[issue17835] test_io broken on PPC64 Linux

[Charles-François Natali]

Charles-François Natali added the comment:

> In this case, the issues are being caused by the following kernel parameters 
> that we have for our default build -
>
> #
> ## TIBCO network tuning #
> #
> net.core.rmem_default = 33554432
> net.core.wmem_default = 33554432
> net.core.rmem_max = 33554432
> net.core.wmem_max = 33554432
>
> Toggling the support.PIPE_MAX_SIZE to +32MB or temporarily removing these 
> parameters mitigates the issue.  Is there a better way of calculating 
> support.PIPE_MAX_SIZE so it is reflective of the actual OS value?

What does:

>>> import fcntl, os
>>> r, w = os.pipe()
>>> fcntl.fcntl(w, 1032)

return?

Note that the kernel buffer sizes above are, well, *really huge*.

--

___
Python tracker 

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

[issue22477] GCD in Fractions

[Terry J. Reedy]

Terry J. Reedy added the comment:

Or "Return a greatest magniture common divisor ...", there being two gmcds to 
choose from.

--

___
Python tracker 

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

[issue22477] GCD in Fractions

[Terry J. Reedy]

Terry J. Reedy added the comment:

If nothing else, the doc for fractions.gcd "Return the greatest common divisor" 
is wrong and should be changed. The negative of the greatest common divisor is 
the least common divisor in an integer range. The doc should say "Return the 
greatest common divisor or its negative".  Ditto for the docstring.

--
nosy: +terry.reedy

___
Python tracker 

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

[issue22483] Copyright infringement on PyPI

[Stefan Krah]

Stefan Krah added the comment:

Yeah right, obviously I don't *really* care about the issue (ethics
in open source software, in case you did not understand).

--

___
Python tracker 

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

[issue22483] Copyright infringement on PyPI

[Donald Stufft]

Donald Stufft added the comment:

Since I've been asked, just to clarify, my last post was a continuation of a 
sentence I mistakenly forgot to write out the whole thing.

It should read:

"If you actually care about fixing the issue report it through one of the 
venues that I've mentioned and Richard or myself (most likely Richard, I rarely 
deal with the actual administration of things and typically involve mostly with 
the technology side of things) will take a look and fix it."

And now I really am done :)

--

___
Python tracker 

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

[issue22483] Copyright infringement on PyPI

[Donald Stufft]

Donald Stufft added the comment:

This will be my last post on this issue.

I've given you the mechanisms for reporting problems with PyPI. PyPI is not run 
by python-dev nor is the python-dev bug tracker a mouth piece for your 
frustration with some part of the ecosystem around Python.

If you actually care about fixing the issue report it through one of the venues 
that I've mentioned and Richard or myself (most likely Richard, I rarely deal 
with the actual administration of things and typically involve mostly with the 
technology side of things).

I'm going to close this, please leave it closed as it has nothing do with 
CPython. If you want to speak out against something get a blog but a bugtracker 
is not that.

--
status: open -> closed

___
Python tracker 

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

[issue22483] Copyright infringement on PyPI

[Donald Stufft]

Donald Stufft added the comment:

Sorry, Richard or myself (...) will take a look and fix it.

--

___
Python tracker 

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

[issue22483] Copyright infringement on PyPI

[Stefan Krah]

Stefan Krah added the comment:

Sorry, Donald, the actions on PyPI deserve wider exposure.

--
status: closed -> open

___
Python tracker 

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

[issue22483] Copyright infringement on PyPI

[Alex Gaynor]

Alex Gaynor added the comment:

Stefan, this is not the right forum for this issue, please do not reopen it.

--
status: open -> closed

___
Python tracker 

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

[issue22483] Copyright infringement on PyPI

[Stefan Krah]

Stefan Krah added the comment:

I don't see a license on PKG-INFO itself.  Furthermore, even if
it is legal, it (again) shows an utter disregard for authors and
their stated preferences.

I'm not surprised though, given that even existing names are
reassigned in an autocratic fashion.

--
status: closed -> open

___
Python tracker 

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

[issue22477] GCD in Fractions

[Wolfgang Maier]

Wolfgang Maier added the comment:

Wouldn't it make more sense to change gcd() in the fractions module to return 
only positive integers?

The current gcd could become _gcd for private use by fractions, and the new 
wrapper gcd could just be implemented as:

def gcd(a,b):
return abs(_gcd(a, b))


An aspect that hasn't really been discussed so far on the mailing list is that 
this is *not* only about whether the gcd of negative integers should be 
negative or positive, but also about the fact that in the current 
implementation the result of gcd is dependent on the order of the arguments:

>>> gcd(-3,6) == gcd(6,-3)
False

which I think is clearly unexpected.


@Steven:
I share your fear of generating backwards incompatibility only partially. Of 
course, there may be code out there that is relying on the current documented 
behavior for negative integer input, but probably not in too many places since 
after all it's a pretty special need and it's easy enough to implement that 
most people will not even come across the stdlib function before writing their 
own. Even if your code's affected it is really easily fixed.

I do admit though that the proposed change of behavior *could* cause 
hard-to-track bugs in pieces of code that *do* use fractions.gcd right now. So 
I do favor your scheme of raising a warning with negative numbers in Python 
3.5, then changing the behavior in 3.6.

@Steven again:
I was playing around with the idea of having a gcd that accepts more than two 
arguments (and the same for a potential lcm function), then realized that its 
easily written right now as:

>>>reduce(gcd, (3,6,9))
3

Ironically, though, the proposed new gcd would make this slower than it has to 
be since it would do the abs() repeatedly, when

abs(reduce(_gcd, (3,6,9))) would suffice.

So, I guess that's the tradeoff coming with the proposed change:

- a more concise implementation of gcd

against

- broken backwards compatibility and
- reduced flexibility by calling abs implicitly instead of just when the user 
needs it

I guess with that I am 
+0.5 for the change though maybe an extra sentence in the docs about the 
consequences of the already documented behavior of gcd and that you really 
*should* call abs() on the result in most situations may be enough.

--
nosy: +wolma

___
Python tracker 

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

[issue22483] Copyright infringement on PyPI

[STINNER Victor]

STINNER Victor added the comment:

Oh, the issue was closed while I was writing my message.

I agree with Alex and Donald, it's not the right place to report such issue.

--

___
Python tracker 

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

[issue22483] Copyright infringement on PyPI

[STINNER Victor]

STINNER Victor added the comment:

I don't understand the issue.

I see two projects:
https://pypi.python.org/pypi/cdecimal
https://pypi.python.org/pypi/m3-cdecimal

The two projects have the same metadata except owner: cdecimal is owned by 
skrah, m3-cdecimal is owned by prefer.

The license and author (Stefan Krah) are not changed in m3-cdecimal. Where is 
the "copyright infringement"? Is it the description of the package? The 
description contains a few lines of text (Overview, Testing, Short benchmarks, 
Documentation and Linux Notes sections).

I'm unable to reach http://www.bytereef.org/. It looks like the domain is owned 
by Stefan Krah.

Is it illegal to clone a project on PyPI if the author and license is not 
changed?

--
nosy: +haypo

___
Python tracker 

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

[issue22483] Copyright infringement on PyPI

[Donald Stufft]

Donald Stufft added the comment:

There's a support link on the left hand side of the PyPI page, that'll take you 
to the support forum where you can issue a support request and it'll get dealt 
with. Alternatively you can email distutils-...@python.org, or Richard and 
Myself (first names @python.org).

--
resolution:  -> third party
status: open -> closed

___
Python tracker 

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

[issue22482] logging: fileConfig doesn't support formatter styles

[Berker Peksag]

Changes by Berker Peksag :


--
nosy: +vinay.sajip

___
Python tracker 

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

[issue22483] Copyright infringement on PyPI

[Alex Gaynor]

Alex Gaynor added the comment:

This bug tracker isn't really the right place to track this -- that said I 
don't know where is, so I've added Donald Stufft to the nosy list, hopefully he 
can help direct this appropriately.

What license is the bytereef text available under? The cdecimal source is BSD 
licensed, so it's perfectly legal to re-upload the package itself.

--
nosy: +alex, dstufft

___
Python tracker 

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

[issue22483] Copyright infringement on PyPI

[Stefan Krah]

New submission from Stefan Krah:

The following URL contains copyrighted verbatim text from bytereef.org:

  https://pypi.python.org/pypi/m3-cdecimal


I'm not surprised, since the ongoing Walmartization of Open Source
has little regard for authors.

--
messages: 227461
nosy: skrah
priority: normal
severity: normal
status: open
title: Copyright infringement on PyPI

___
Python tracker 

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

[issue22482] logging: fileConfig doesn't support formatter styles

[Dom Zippilli]

New submission from Dom Zippilli:

In the logging module's config.py, see the _create_formatters(cp) method used 
by the fileConfig() method. Note that it pulls "format" and "datefmt" and 
submits these in the formatter constructor:

f = c(fs, dfs)

However, the Formatter constructor has a third argument for formatting style:

def __init__(self, fmt=None, datefmt=None, style='%')

Since the argument is not passed, ConfigParser-format logging configs must use 
%-style logging format masks. We'd prefer to use curlies.

Note that the code for the dictionary configurator does this correctly:

fmt = config.get('format', None)
dfmt = config.get('datefmt', None)
style = config.get('style', '%')
result = logging.Formatter(fmt, dfmt, style)

--
messages: 227460
nosy: domzippilli
priority: normal
severity: normal
status: open
title: logging: fileConfig doesn't support formatter styles
type: enhancement
versions: Python 3.4

___
Python tracker 

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

[issue22466] problem with installing python 2.7.8

[Steve Dower]

Steve Dower added the comment:

Ah, okay, so this is due to the embedded DLL in the installer that we extract 
and use to validate the install path (if you select a path that already exists, 
you get a prompt warning you).

I don't know why your %TEMP% directory was not read/write/execute, but since it 
works fine for most people I suspect a configuration issue on your machine. I 
have seen in the past some "security" policies that will break installers, 
though typically launching the installer from an elevated command prompt (one 
that says "Administrator: Command Prompt" in the title) typically avoids these 
issues.

Glad you found a workaround at least.

--

___
Python tracker 

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

[issue21052] Consider dropping ImportWarning for empty sys.path_hooks and sys.meta_path

[Brett Cannon]

Changes by Brett Cannon :


--
assignee:  -> brett.cannon

___
Python tracker 

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

[issue22476] asyncio task chapter confusion about 'task', 'future', and 'schedule'

[STINNER Victor]

Changes by STINNER Victor :


--
components: +asyncio

___
Python tracker 

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

[issue22428] asyncio: KeyboardInterrupt inside a coroutine causes AttributeError

[STINNER Victor]

STINNER Victor added the comment:

The issue #22480 has been marked as a duplicate of this issue.

--

___
Python tracker 

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

[issue22480] SystemExit out of run_until_complete causes AttributeError when using python3 -m

[STINNER Victor]

STINNER Victor added the comment:

Running "python test.py" and "python -m test" changes how the code is loaded. 
With "python test.py", test.py becomes the "__main__" module, whereas "python 
-m test" uses the "test" module.

At Python exit, the __main__ module and other modules are destroyed differently.

Anyway, this issue is another example of the issue #22428 and so I close it as 
duplicate.

--
resolution:  -> duplicate
superseder:  -> asyncio: KeyboardInterrupt inside a coroutine causes 
AttributeError
versions: +Python 3.5

___
Python tracker 

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

[issue22427] TemporaryDirectory attempts to clean up twice

[STINNER Victor]

STINNER Victor added the comment:

Cool, the final code is simpler than before!

--

___
Python tracker 

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

[issue22473] The gloss on asyncio "future with run_forever" example is confusing

[STINNER Victor]

Changes by STINNER Victor :


--
components: +asyncio

___
Python tracker 

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

[issue22473] The gloss on asyncio "future with run_forever" example is confusing

[STINNER Victor]

STINNER Victor added the comment:

"But that isn't quite true.  It is the callback associated with the future that 
is displaying the result and stopping the loop."

I wrote this example to show that setting the result of a future can schedule a 
callback. I mean something like:

"In this example, the future is used to link slow_operation() to got_result(): 
when slow_operation() is done, got_result() is called with the result."

The main idea behind Future is to chain callbacks and the link is done 
externally. It's different from this design:

def slow_operation(done_callback):
...
done_callback()

--

___
Python tracker 

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

[issue22472] OSErrors should use str and not repr on paths

[Ezio Melotti]

Changes by Ezio Melotti :


--
nosy: +ezio.melotti
type:  -> behavior

___
Python tracker 

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

[issue22474] No explanation of how a task gets destroyed in asyncio 'task' documentation

[STINNER Victor]

STINNER Victor added the comment:

"destroyed" means "collected by the garbage collector", when the last reference 
the task objected was cleared. To be honest, I have no idea who keeps a 
reference to tasks nor how the "pending task destroyed" bug occurs.

"pending" means that the execution of the coroutine object didn't finish. In 
fact, it's related to Task.done(): a task is pending is task.done() is False.

There is a corner case: if task.cancel() was called but the coroutine object 
was not executed yet to handle the CancelledError, the task is still "pending".

Maybe "pending" is not the best word, and "not done" is better.

--

___
Python tracker 

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

[issue22475] asyncio task get_stack documentation seems to contradict itself

[STINNER Victor]

Changes by STINNER Victor :


--
components: +asyncio

___
Python tracker 

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

[issue22474] No explanation of how a task gets destroyed in asyncio 'task' documentation

[STINNER Victor]

Changes by STINNER Victor :


--
components: +asyncio

___
Python tracker 

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

[issue22476] asyncio task chapter confusion about 'task', 'future', and 'schedule'

[STINNER Victor]

STINNER Victor added the comment:

I know that the "18.5.3. Tasks and coroutines" section of the documentation is 
probably the worst section :-( Feel free to suggest changes with a patch!

I started to enhance the documentation of the Task class, but there is still a 
lot of work to enhance the whole section.


> "We then see an example that appears to include scheduling a future via 
> asyncio.async, because there is a specific mention of how we can attach a 
> callback after it is scheduled but before the event loop is started."

I guess that you are talking about this example?
https://docs.python.org/dev/library/asyncio-task.html#example-future-with-run-until-complete

You cannot "schedule" a Future object. A Future object doesn't contain code. It 
only schedules callbacks when set_result() or set_exception() is called.

In this example, a call to the slow_operation coroutine function is scheduled: 
"slow_operation(future)" creates a coroutine object which is wrapped into a 
Task object. A coroutine is disconnected from the event loop. The role of the 
task is to schedule the execution of a coroutine object.

It becomes more complex when you know that the Task class inherits from the 
Future class :-/


> "I see that a Future is scheduled by its creation"

Again, this is wrong. You cannot "schedule a future". You can schedule a 
coroutine object by creating a task wrapping it.


> As a followon point, the gloss on example of parallel execution of tasks says 
> "A task is automatically scheduled for execution when it is created.  The 
> event loop stops when all tasks are done."  This reads very strangely to me.  
> The first sentence seems to be pointing out the difference between this 
> example and the previous one with Future where we had to explicitly schedule 
> it (by calling async which creates a task...).  But it seems that that isn't 
> true...so why is that sentence there? The second sentence presumably refers 
> to the fact that run_until_complete runs the event loop until all scheduled 
> tasks are complete..because they are wrapped in 'wait'.  But wait is not 
> cross referenced or mentioned in the gloss, so I had to think about it 
> carefully and look up wait to conclude that that was what it meant.

Hum, I summarized too many information in "The event loop stops when all tasks 
are done." In fact, the example stops when run_until_complete() finished its 
job.

--

___
Python tracker 

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

[issue22481] Lists within tuples mutability issue

[Ezio Melotti]

Ezio Melotti added the comment:

See 
https://docs.python.org/3/faq/programming.html#why-does-a-tuple-i-item-raise-an-exception-when-the-addition-works

--
nosy: +ezio.melotti
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 

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

[issue22481] Lists within tuples mutability issue

[Владимир Тырин]

New submission from Владимир Тырин:

This behavior seems to be very strange. 

>>> l = [1, 2, 3]
>>> t = ('a', l)
>>> t
('a', [1, 2, 3])
>>> t[1] += [4]
Traceback (most recent call last):
  File "", line 1, in 
TypeError: 'tuple' object does not support item assignment
>>> t
('a', [1, 2, 3, 4])

--
messages: 227451
nosy: Владимир.Тырин
priority: normal
severity: normal
status: open
title: Lists within tuples mutability issue
type: behavior
versions: Python 2.7

___
Python tracker 

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

[issue1602] windows console doesn't print or input Unicode

[Nick Coghlan]

Nick Coghlan added the comment:

Aye, IPython has the advantage of running in a fully initialised browser, with 
the backend in a fully initialised Python environment.

CPython's setting up the standard streams for the default REPL at a much lower 
level, and there are quite a few problems with the way we're currently doing it.

I think Drekin's pointed the way towards substantially improving the situation 
for 3.5, though.

--

___
Python tracker 

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

[issue22479] strange behavior of importing random module

[Steven D'Aprano]

Steven D'Aprano added the comment:

For future reference, we *strongly* recommend that instead of taking a screen 
shot and posting it as an attachment, you copy and paste the text directly. 
Don't retype it, any decent terminal application will allow you to select and 
copy the text, then paste it elsewhere.

--
nosy: +steven.daprano

___
Python tracker 

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

[issue16056] shadowed test names in std lib regression tests

[Berker Peksag]

Berker Peksag added the comment:

- issue 16079 opened for "make patchcheck" integration
- issue 19119 opened for test_heapq
- issue 19113 opened for test_functions

And here's a patch for 2.7.

--
nosy: +berker.peksag
stage: needs patch -> patch review
versions: +Python 3.4, Python 3.5 -Python 3.2, Python 3.3
Added file: http://bugs.python.org/file36710/issue16056_27.diff

___
Python tracker 

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

[issue22477] GCD in Fractions

[Steven D'Aprano]

Steven D'Aprano added the comment:

If we are considering adding a new gcd elsewhere (say, in the math module), 
then it should accept any arbitrary number of arguments, not just two. (At 
least one argument though.)

Also, Mathematica supports the GCD of rational numbers, not just integers. 
Should we do the same?

Would it be too confusing to have fractions.gcd and fractions.Fraction.gcd both 
exist but behave differently? I fear so.

I wish we had a mathlib.py standard module for pure Python implementations...

--

___
Python tracker 

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

[issue22477] GCD in Fractions

[Steven D'Aprano]

Steven D'Aprano added the comment:

I would be a lot more cautious about changing the gcd function. As Mark says, 
there is *not* a single well-defined meaning of the gcd for negative arguments. 
Even Wolfram can't decide which to use: Mathworld gives one interpretation, 
Mathematica the opposite. See my comments here:

https://mail.python.org/pipermail/python-list/2014-September/678681.html
 
Given that there is no one definitive definition of gcd, this is not a bug fix, 
it is a backward-incompatible functional change. That means it ought to go 
through a deprecation period before changing it:

- deprecate negative arguments in 3.5;
- raise a warning in 3.6;
- change the behaviour in 3.7.

*Maybe* we could skip the silent deprecation period and jump straight to the 
warning. But I don't see any justification for fast-tracking this, and 
certainly not for jumping straight to the change of behaviour. Somebody is 
using this function and expects it to do what it currently does, and changing 
it will break their code for precious little benefit.

Another objection: this suggested change will add yet another backwards 
incompatibility between Python 2.7 and 3.x. There ought to be a good reason for 
that, not just to save a single call to abs() after gcd.

I am -1 on making this change.

--
nosy: +steven.daprano

___
Python tracker 

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

[issue16056] shadowed test names in std lib regression tests

[Roundup Robot]

Roundup Robot added the comment:

New changeset 6d44906344f4 by Berker Peksag in branch '3.4':
Issue #16056: Rename test method in test_statistics to avoid conflict.
https://hg.python.org/cpython/rev/6d44906344f4

New changeset c49d7f4d1c04 by Berker Peksag in branch 'default':
Issue #16056: Rename test method in test_statistics to avoid conflict.
https://hg.python.org/cpython/rev/c49d7f4d1c04

--

___
Python tracker 

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

[issue22466] problem with installing python 2.7.8

[Khalid]

Khalid added the comment:

I tried but I got this error "this installation package could not be
opened. verify that the package exists & that you can access it, or contact
the application vendor to verify that this is a valid windows installer
package" (screen shot in the attachment)

by the way I'm admin!

On Tue, Sep 23, 2014 at 9:26 PM, Steve Dower  wrote:

>
> Steve Dower added the comment:
>
> Can you try running this command and then post the log file after
> installation fails:
>
> > msiexec /l*vx log.txt /i ""
>
> --
>
> ___
> Python tracker 
> 
> ___
>

--
Added file: http://bugs.python.org/file36703/Capture2.JPG

___
Python tracker 

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

[issue22477] GCD in Fractions

[Akira Li]

Akira Li added the comment:

Whether or not gcd(a, b) == gcd(|a|, |b|) depends on the definition if
we believe to Stepanov of C++ STL fame who mentions in his lecture [1]

[1] http://www.stepanovpapers.com/gcd.pdf

that the current implementation that uses two operation __bool__ and 
__mod__:

  def gcd(a, b):
  while b:
  a, b = b, a%b
  return a

can be applied to Euclidean ring elements (not just positive or
negative integers). Despite Knuth’s objection to gcd(1, -1) = -1, 
adding `if a < 0: a = -a` at the end changes the requirements for the
type. Here's the definition from the lecture [1]:

  Greatest common divisor is a common divisor that is divisible by any 
  other common divisor.

I have no opinion on whether or not fractions.gcd() should be changed. 
I thought that I should mention that different definitions exist.

--
nosy: +akira

___
Python tracker 

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

[issue22477] GCD in Fractions

[Stefan Behnel]

Stefan Behnel added the comment:

I suggest adding a new implementation instead of replacing the current function 
in the fractions module. As Mark noted, the current gcd() is more of a 
sideeffect of the fractions module, but there's no real need to change that. It 
works perfectly ok for a) the Fraction type and b) positive input values.

Even if there's no other module namespace for this functionality that is more 
suitable than fractions, it could still be added under a different name, say, 
absgcd() or whatever. Something that makes it clear(er) how negative input is 
handled. The mere name "gcd" isn't very telling on that front.

--
nosy: +scoder

___
Python tracker 

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

[issue22477] GCD in Fractions

[gladman]

gladman added the comment:

On 24/09/2014 11:54, Mark Dickinson wrote:
> 
> Mark Dickinson added the comment:
> 
>> Well we will just have to agree to disagree on this :-)
> 
> Sure.  In the mean time, would you be interested in writing a patch targeting 
> Python 3.5?  (Irrespective of the arguments about the definition, I don't 
> think this is a change that could be applied in a 3.4 bugfix release.)

Yes, I am very willing to contribute. But I have never contributed to
Python before and I almost certainly have a lot to learn in any attempt
to do this.

In particular, I need advice on where any gcd should go (fractions or
math or ...).  And if it goes in math and/or we want to speed it up, I
would have to learn how to integrate Python and C code (I have done
almost none of this before).

So I would much appreciate further discusssion of this possible change
and how best to implement it (if there is a consensus to do so).

Of course, there is the very simple change of adding abs(x) to the
return value for the current gcd and adjusting its single use in
fractions accordingly.  But since there is already concern about the
impact of the gcd on the performance of fractions, it deserves more
careful consideration than this approach would involve.

--

___
Python tracker 

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

[issue1602] windows console doesn't print or input Unicode

[Stefan Champailler]

Stefan Champailler added the comment:

Thank you all for your quick and good answers. This level of responsiveness is 
truly amazing.

I've played a bit with IPython and it works just fine. I can type the eurosign 
drectly with "Alt Gr - E" (so I didn't enter a unicode code). So the bug is 
basically solved for me. But the python-repl behaviour still looks strange to 
me. So here's a successful IPython session :

C:\PORT-STCA2\pl-PRIVATE\horse>chcp 65001
Active code page: 65001

C:\PORT-STCA2\pl-PRIVATE\horse>ipython
Python 3.4.1 (v3.4.1:c0e311e010fc, May 18 2014, 10:38:22) [MSC v.1600 32 bit 
(Intel)]
Type "copyright", "credits" or "license" for more information.

IPython 2.2.0 -- An enhanced Interactive Python.
? -> Introduction and overview of IPython's features.
%quickref -> Quick reference.
help  -> Python's own help system.
object?   -> Details about 'object', use 'object??' for extra details.
   
In [1]: print('€') 
€   
   
In [2]:

--

___
Python tracker 

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

[issue22480] SystemExit out of run_until_complete causes AttributeError when using python3 -m

[chrysn]

Changes by chrysn :


Added file: http://bugs.python.org/file36709/destructortest.py

___
Python tracker 

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

[issue22480] SystemExit out of run_until_complete causes AttributeError when using python3 -m

[chrysn]

Changes by chrysn :


Added file: http://bugs.python.org/file36707/test.py

___
Python tracker 

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

[issue22480] SystemExit out of run_until_complete causes AttributeError when using python3 -m

[chrysn]

Changes by chrysn :


Added file: http://bugs.python.org/file36708/test.err

___
Python tracker 

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

[issue22480] SystemExit out of run_until_complete causes AttributeError when using python3 -m

[chrysn]

New submission from chrysn:

the attached test.py snipplet, which runs an asyncio main loop to the 
completion of a coroutine raising SystemExit, runs cleanly when invoked using 
`python3 test.py`, but shows a logging error from the Task.__del__ method when 
invoked using `python3 -m test`.

the error message (attached as test.err) indicates that the builtins module has 
already been emptied by the time the Task's destructor is run.

i could reproduce the problem with an easier test case without asyncio 
(destructoretest.py), but then again, there the issue is slightly more obvious 
(one could argue a "don't do that, then"), and it occurs no matter how the 
program is run. i'm leaving this initially assigned to asyncio, because (to the 
best of my knowledge) test.py does not do bad things by itself, and the 
behavior is inconsistent only there.

--
components: asyncio
messages: 227440
nosy: chrysn, gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: SystemExit out of run_until_complete causes AttributeError when using 
python3 -m
versions: Python 3.4

___
Python tracker 

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

[issue22477] GCD in Fractions

[Mark Dickinson]

Mark Dickinson added the comment:

> Well we will just have to agree to disagree on this :-)

Sure.  In the mean time, would you be interested in writing a patch targeting 
Python 3.5?  (Irrespective of the arguments about the definition, I don't think 
this is a change that could be applied in a 3.4 bugfix release.)

--
type: behavior -> enhancement
versions: +Python 3.5 -Python 3.4

___
Python tracker 

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

[issue22427] TemporaryDirectory attempts to clean up twice

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Committed without this test.

Thank you Victor and Yury for your comments.

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

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

[issue22219] python -mzipfile fails to add empty folders to created zip

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Hmm, looks as I forgot to attach a patch.

--
keywords: +patch
Added file: http://bugs.python.org/file36706/zipfile_add_dirs.patch

___
Python tracker 

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

[issue22477] GCD in Fractions

[gladman]

gladman added the comment:

On 24/09/2014 10:13, Mark Dickinson wrote:
> 
> Mark Dickinson added the comment:
> 
>> I will willingly supply more references if you need them.
> 
> I don't. :-) I've taught more elementary number classes and reviewed more 
> elementary number theory texts (including Rosen's) than I care to remember, 
> and I have plenty of my own references. I stand by my assertion that the 
> fractions module gcd is not wrong:  it returns 'a' greatest common divisor 
> for arbitrary integer inputs.

Well we will just have to agree to disagree on this :-)

--

___
Python tracker 

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

[issue22427] TemporaryDirectory attempts to clean up twice

[Roundup Robot]

Roundup Robot added the comment:

New changeset 7ea2153eae87 by Serhiy Storchaka in branch '3.4':
Issue #22427: TemporaryDirectory no longer attempts to clean up twice when
https://hg.python.org/cpython/rev/7ea2153eae87

New changeset e9d4288c32de by Serhiy Storchaka in branch 'default':
Issue #22427: TemporaryDirectory no longer attempts to clean up twice when
https://hg.python.org/cpython/rev/e9d4288c32de

--
nosy: +python-dev

___
Python tracker 

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

[issue21860] Correct FileIO docstrings

[Roundup Robot]

Roundup Robot added the comment:

New changeset be2746c565c2 by Berker Peksag in branch '2.7':
Issue #21860: Correct docstrings of FileIO.seek() and FileIO.truncate() methods.
https://hg.python.org/cpython/rev/be2746c565c2

--

___
Python tracker 

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

[issue21860] Correct FileIO docstrings

[Berker Peksag]

Berker Peksag added the comment:

Thanks for the patch, Terry.

--
assignee: haypo -> berker.peksag
nosy: +berker.peksag
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed
versions: +Python 3.5 -Python 3.3

___
Python tracker 

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

[issue21860] Correct FileIO docstrings

[Roundup Robot]

Roundup Robot added the comment:

New changeset 2058d94f32dd by Berker Peksag in branch '3.4':
Issue #21860: Correct docstrings of FileIO.seek() and FileIO.truncate() methods.
https://hg.python.org/cpython/rev/2058d94f32dd

New changeset de645efe6a9b by Berker Peksag in branch 'default':
Issue #21860: Correct docstrings of FileIO.seek() and FileIO.truncate() methods.
https://hg.python.org/cpython/rev/de645efe6a9b

--
nosy: +python-dev

___
Python tracker 

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

[issue22479] strange behavior of importing random module

[STINNER Victor]

STINNER Victor added the comment:

It's not a bug in Python. The problem is that your project contains a file 
called "random.py" which is used instead of the random from the standard 
library. Rename the file (and remove random.pyc).

--
nosy: +haypo
resolution:  -> not a bug
status: open -> closed

___
Python tracker 

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

[issue22478] tests for urllib2net are in bad shapes

[Senthil Kumaran]

Senthil Kumaran added the comment:

The buildbots are not showing this error too. I suggest you reset your local 
copy with the pristine one from remote, do a make distclean; ./configure; make 
and then run the tests.

--
assignee:  -> orsenthil
resolution:  -> works for me
stage:  -> resolved
status: open -> closed
type:  -> behavior

___
Python tracker 

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

[issue22478] tests for urllib2net are in bad shapes

[Senthil Kumaran]

Senthil Kumaran added the comment:

I suspect that you have your interpreters confused. (For e.g, I see 3.4 run 
against the trunk and the error messages are leading me to believe that 2.7 
version in run on 3 code).

Or your local copy is not in right shape.

I tested it on 3.4 and cpython default and everything was OK.

[localhost 3.4]$ ./python.exe -m unittest -v Lib/test/test_urllib2net.py
...
Ran 15 tests in 36.672s

OK
[localhost 3.4]$ hg log -r 3.4
changeset:   92551:bce1594023f9
branch:  3.4
parent:  92548:381d6362c7bc
parent:  92546:ff2cb4dc36e7
user:Serhiy Storchaka 
date:Tue Sep 23 23:23:41 2014 +0300
description:
Merge heads

[localhost cpython]$ ./python.exe -m unittest -v Lib/test/test_urllib2net.py
...
Ran 15 tests in 32.779s

OK
[localhost cpython]$ hg log -r tip
changeset:   92555:064f6baeb6bd
tag: tip
user:Georg Brandl 
date:Wed Sep 24 09:08:12 2014 +0200
files:   Python/importlib.h
description:
Update importlib.h frozen bytecode (changed due to commit c0ca9d32aed4).

--

___
Python tracker 

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

[issue22479] strange behavior of importing random module

[Bekket McClane]

New submission from Bekket McClane:

When I import the random module using "import random" in the command line, it 
worked fine. But if I import it in the file, the program will throw a strange 
error, but sometimes it just exit right away after the import statement with no 
error. Moreover, if I execute the python command line again and "import random" 
after that, the command line python exit right away too(with exit code 0). Only 
if I restarted the whole terminal program did the strange behavior gone

--
components: Library (Lib)
files: Screenshot from 2014-09-24 17:04:58.png
messages: 227428
nosy: Bekket.McClane
priority: normal
severity: normal
status: open
title: strange behavior of importing random module
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file36705/Screenshot from 2014-09-24 
17:04:58.png

___
Python tracker 

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

[issue22477] GCD in Fractions

[Mark Dickinson]

Mark Dickinson added the comment:

> I will willingly supply more references if you need them.

I don't. :-) I've taught more elementary number classes and reviewed more 
elementary number theory texts (including Rosen's) than I care to remember, and 
I have plenty of my own references. I stand by my assertion that the fractions 
module gcd is not wrong:  it returns 'a' greatest common divisor for arbitrary 
integer inputs.

A bit more: the concept of greatest common divisor is slightly ambiguous:  you 
can define the notion of "a greatest common divisor" for an arbitrary 
commutative ring-with-a-1 R:  c is a greatest common divisor of a and b if c is 
a common divisor (i.e. c divides a and c divides b, where "x divides y" is 
synonymous with "y is a multiple of x"), and any other common divisor divides 
c.  No ordering is necessary: "greatest" here is with respect to the 
divisibility lattice rather than with respect to any kind of total ordering.  
One advantage of this definition is that it makes it clear that 0 is a greatest 
common divisor of 0 and 0.

If further R is an integral domain, then it follows immediately from the 
definition that any two greatest common divisors of a and b (if they exist) are 
associates: a is a unit times b.  In the particular case where R is the usual 
ring of rational integers, that means that "the" greatest common divisor of two 
numbers a and b is only really defined up to +/-;  that is, the sign of the 
result is unimportant.  (An alternative viewpoint is to think of the gcd, when 
it exists, as a principal ideal rather than an element of the ring.)

See 
https://proofwiki.org/wiki/Definition:Greatest_Common_Divisor/Integral_Domain 
for more along these lines.

So you're using one definition, I'm using another.  Like I said, there's no 
universal agreement. ;-).

--

___
Python tracker 

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

[issue21049] Warning at interpreter exit triggers flood of “ImportWarning: sys.meta_path is empty”

[Quentin Pradet]

Quentin Pradet added the comment:

I've also been affected by this when testing integration with a third-party 
library (NLTK). NLTK does need to be fixed, but the ResourceWarning already say 
so.

The new one-liner doesn't seem contrived to me.

--
nosy: +Quentin.Pradet

___
Python tracker 

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

[issue18993] There is an overshadowed and invalid test in testmock.py

[Berker Peksag]

Berker Peksag added the comment:

This has been fixed in https://hg.python.org/cpython/rev/c8c11082bd0c.

--
nosy: +berker.peksag
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

___
Python tracker 

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