Sean Ochoa added the comment:
After discussing with folks on the #python-dev tonight, I learned that I was
testing with a list and I should've been using a set. I'm working on a patch
now, and I'm almost ready to have it reviewed.
--
___
Python
Fergus Noble added the comment:
GPS time doesn't include leap seconds so I think datetime is a good
representation. If datetime doesn't know about leap seconds then there would
still be some issues with finding the timedelta between a GPS time and a UTC
time straddling a leap second but I
Mark Dickinson added the comment:
Agreed. Closing.
--
resolution: - invalid
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11842
___
Changes by Yongzhi Pan fossi...@users.sourceforge.net:
--
nosy: +fossilet
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12634
___
___
Nick Coghlan added the comment:
I've started looking into what would be needed to fix this. The basic problem
is that the compilation process involves many recursive operations, but doesn't
contain *any* calls to the recursion control functions
Nick Coghlan added the comment:
One caveat on this idea: it may not be possible to use the standard recursion
limiting functions here, since the Python level recursion limit is generally
set quite low (1000 by default on my Fedora system).
While this crash *is* a design flaw in our compiler
Stefan Behnel added the comment:
The problem is a) that the module does not necessarily know to which place it
eventually gets installed (Cython relies on the distutils Extension not lying
to it, for example, which people do from time to time), and b) that the call to
Py_InitModule() only
Serhiy Storchaka added the comment:
Isn't it a duplicate of issue5765?
--
nosy: +serhiy.storchaka
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11383
___
Changes by Serhiy Storchaka storch...@gmail.com:
--
resolution: - duplicate
superseder: - stack overflow evaluating eval(() * 3)
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11383
___
Nick Coghlan added the comment:
We want to minimise the risk of breaking working code. Making it easy to adjust
this recursion limit separately from the main recursion limit by using a
scaling factor is a good way to do that. It shouldn't increase the maintenance
burden in any significant
Daniel Urban added the comment:
I've attached a patch addressing the comments on Rietveld. I've added another
modification: inspect.signature uses inspect.unwrap. (It already tried to
unwrap the function, but it wasn't protected from infinite recursion. I don't
know if this worth fixing in
Serhiy Storchaka added the comment:
I don't understand what you mean---can you elaborate?
The Python implementation of this method only 40 lines length, including blank
lines, docstring and comments. The C implementation requires over 160 lines
and less clear. Are there ways to use in
New submission from Chris Jerdonek:
There is a mismatch between what PyPI and the docs say regarding listing
versions of packages on PyPI.
The current docs say, By default PyPI will list all versions of a given
package.
(from http://docs.python.org/3.4/distutils/packageindex.html )
However,
Serhiy Storchaka added the comment:
The patch looks good to me. Now benchmarks and special casing for Py_ssize_t
values needed.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14794
___
Mark Dickinson added the comment:
Now benchmarks and special casing for Py_ssize_t values needed.
I thought about that, but I don't think it's worth it. I did some quick
timings, and as expected the new version of slice.indices is somewhat slower
than the original. But I think adding a
Serhiy Storchaka added the comment:
Here is a patch which reverts 3.1 implementation (and adds some optimization).
Microbenchmark:
$ ./python -m timeit -s import re re._compile('', 0)
Results:
3.1: 1.45 usec per loop
3.2: 4.45 usec per loop
3.3: 9.91 usec per loop
3.4patched: 0.89 usec per
New submission from Chris Jerdonek:
Currently, the documentation makes no mention of the PKG-INFO file.
It would be useful if the documentation mentioned what this file is and how it
is created (e.g. via the sdist command), and also linked to PEP 314. This can
be covered somewhere in the
Serhiy Storchaka added the comment:
Look at compute_slice_indices() in Objects/rangeobject.c.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14794
___
Chris Jerdonek added the comment:
PEP 345 can also be linked to (Metadata version 1.2).
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16401
___
Mark Dickinson added the comment:
Hmm: one more thing that needs to be fixed before this can be committed---the
error messages for maltyped start, stop and step are less informative than they
used to be.
Before the patch:
slice(0, 2.3, 4).indices(5)
Traceback (most recent call
Antoine Pitrou added the comment:
Autogenerated code could easily hit the 1000 term limit - if anything,
I'd be inclined to set it *higher* than 4 rather than lower, as
breaking previously working code in a maintenance release is a bad
thing, regardless of our opinion of the sanity of that
Mark Dickinson added the comment:
New patch that fixes the error message for badly typed slice arguments.
Also tweaks a couple of other details:
- replace Py_GE with Py_GT, Py_LE with Py_LT in the out-of-range comparisons,
as suggested by Serhiy; this also makes it more closely match the
Serhiy Storchaka added the comment:
Isn't it be clearer?
import os
dir_fd = os.open('somedir', os.O_RDONLY)
def opener(path, flags):
... return os.open(path, flags, dir_fd=dir_fd)
...
with open('spamspam.txt', 'w', opener=opener) as f:
...
Changes by Serhiy Storchaka storch...@gmail.com:
--
components: -Windows
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16183
___
___
Serhiy Storchaka added the comment:
compute_slice_indices() and slice_indices() looks as partially duplicates. I
think the similar code should be merged and reused.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14794
Chris Jerdonek added the comment:
Previous issues like this include issue 962772 (from 5/2004) and issue 3686
(from 8/2008). Copying the nosy lists from those issues.
This issue affects me also because I maintain a project that I did not author.
However, PyPI lists me as the author because
New submission from Mark Dickinson:
class A(object):
... def __index__(self): raise ZeroDivisionError
...
[66062 refs]
a = A()
[66065 refs]
range(10)[0:a]
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: slice indices must be integers or None or have an
Mark Dickinson added the comment:
Here's a patch.
--
keywords: +patch
stage: - patch review
type: - behavior
versions: +Python 3.2, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file27879/issue16402.patch
___
Python tracker
Mark Dickinson added the comment:
Agreed.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14794
___
___
Python-bugs-list mailing list
New submission from Chris Jerdonek:
As discussed in issue 16108 and other issues referenced there, distutils lists
the maintainer as the author in PKG-INFO when the maintainer is provided.
However, the documentation does not state this.
This issue is to update the distutils documentation to
Chris Jerdonek added the comment:
I also created issue 16403 to update the distutils docs to say that distutils
lists the maintainer as the author in PKG-INFO when maintainer is provided.
--
___
Python tracker rep...@bugs.python.org
Changes by Mark Dickinson dicki...@gmail.com:
--
components: +Interpreter Core
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16402
___
___
Roundup Robot added the comment:
New changeset 94d15358ad6e by Mark Dickinson in branch '3.2':
Issue #16402: In range slicing, fix shadowing of exceptions from __index__
method.
http://hg.python.org/cpython/rev/94d15358ad6e
New changeset 2b656a2cf7ef by Mark Dickinson in branch '3.3':
Issue
Changes by Mark Dickinson dicki...@gmail.com:
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16402
___
Ray Donnelly added the comment:
I agree in principle about not having to maintain two implementations but I
would worry about breaking external packages that depend on the python
implementation.
In the meantime, please find an updated version of this patch that adds support
for --configdir
Serhiy Storchaka added the comment:
I quote from Gregory P. Smith (msg91897):
The decryption provided by the zipfile module is for the worthless
32-bit crc based encryption of zipfiles. I think promoting the use of
that is a bad idea.
zipfile can be used by people to get their data out of
Ray Donnelly added the comment:
I also checked the Windows releases and python-config isn't included. However,
I don't think there's a good reason for that. python-config would in theory
work fine if people wanted to link their programs to Python on Windows, as
would python-config.sh given a
Serhiy Storchaka added the comment:
See also criticism in the original discussion:
http://mail.python.org/pipermail/python-dev/2009-August/091450.html .
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10030
Stefan Krah added the comment:
Would that result in displaying both author and maintainer info on the PyPI
page? For what cases is it useful?
It gives due credit to the original author if another person maintains
the package. I think it's a matter of common courtesy not to suppress
author
Robert de Vries added the comment:
My use case is decrypting files of 100's of megabytes. This is so slow that it
is quite useless. About an hour or so.
I do agree that the encryption is worthless, but that is not important for my
use case where I want to discourage people from reverse
R. David Murray added the comment:
We aren't particularly interested in helping people make their files slightly
harder to reverse engineer, either, so I don't think that is a good enough
reason for accepting this. There might be other reasons that are good enough,
but I don't think that is
Christian Heimes added the comment:
From the zlib FAQ:
38. How can I encrypt/decrypt zip files with zlib?
zlib doesn't support encryption. The original PKZIP encryption is very weak
and can be broken with freely available programs. To get strong encryption,
use GnuPG,
Roundup Robot added the comment:
New changeset ab02cd145f56 by Nick Coghlan in branch '3.3':
Issue #5765: Apply a hard recursion limit in the compiler
http://hg.python.org/cpython/rev/ab02cd145f56
New changeset bd1db93d76e1 by Nick Coghlan in branch 'default':
Issue #5765: Merge from 3.3
Nick Coghlan added the comment:
You can take the scaling factor out if you really want, but it adds no real
maintenance overhead, and better reflects the real stack usage.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5765
Nick Coghlan added the comment:
However, agreed on the won't fix for 3.2 and 2.7, although I'd consider it at
least for 2.7 if someone went through and worked out a patch that applies
cleanly.
For 3.2, this really isn't the kind of thing we'd want to do in the final
regular maintenance
Antoine Pitrou added the comment:
You can take the scaling factor out if you really want, but it adds no
real maintenance overhead, and better reflects the real stack usage.
Can you also add a related snippet in
Tools/scripts/find_recursionlimit.py ?
--
Nick Coghlan added the comment:
Note: if you do take the scaling factor out, don't forget to track down the
reasons behind the original commit that added the test that broke *without* the
scaling factor.
For me, the test suite fails without it is reason enough for me to say its
needed -
Roundup Robot added the comment:
New changeset cf2515d0328b by Nick Coghlan in branch '3.3':
Issue #5765: Also check the compiler when finding the recursion limit
http://hg.python.org/cpython/rev/cf2515d0328b
New changeset 3712028a0c34 by Nick Coghlan in branch 'default':
Issue #5765: Merge
Nick Coghlan added the comment:
The sanity check in the recursion limit finding script is definitely a good
idea, so I added that (as the commits show).
For the record, running that script on the 3.3 branch with my 4 GB RAM Fedora
17 ASUS Zenbook finds a maximum recursion limit around 16800,
Robert de Vries added the comment:
If the encryption is so horrible why is there any support (with bad
performance) at all in Python?
It would be better to remove it altogether.
This prevents users from building software using this feature only to find out
later how bad the performance is.
Mark Shannon added the comment:
I don't think there is any need for a scaling factor.
Expressions in auto-generated trees will tend to be trees of binary operator
rather lists of purely unary operators. A tree of a billion items only has a
depth of ~30.
There is no way an expression tree 1000
Antoine Pitrou added the comment:
The sanity check in the recursion limit finding script is definitely a
good idea, so I added that (as the commits show).
Didn't you make a mistake in the recursion factor there? Or is it really
10 rather than 3?
--
Antoine Pitrou added the comment:
If the encryption is so horrible why is there any support (with bad
performance) at all in Python?
It would be better to remove it altogether.
We don't remove it as it would break existing programs which rely on
this feature. However adding a bunch of C code
Antoine Pitrou added the comment:
The patch is probably trivial - however I would still like some
verification.
Would it be correct to call self.close() when fp.read returns ''? In
case self.length is not present, I don't see a way around this anyway.
When it is present, and fp.read returns
Nick Coghlan added the comment:
Antoine: The scaling is deliberate higher in the recursion limit finder because
we just want to ensure it hits the recursion limit (or blows the stack, if the
scaling is wrong). In the tests, I cut it finer because I wanted to ensure we
were straddling the
New submission from Ned Batchelder:
Examining the CPython sources, there are a number of places where
PyLong_FromLong is used without checking its return value. In places where it
is done correctly, PyErr_Occurred is often used to avoid having to check every
call.
Here are places where it
New submission from Nick Coghlan:
Setting up the same commit checks locally that the main repo enforces for
incoming patch sets can save a great deal of frustration with the server
rejecting hg push for changes (this can be especially frustrating if you have
already merged changes across
Brett Cannon added the comment:
It sounds like Cython has its fix and CPython knows what should eventually be
changed in Python 4 to bring extension module initialization closer to how
Python module code is initialized.
Maybe we should add a warning in some documentation somewhere about this
Ezio Melotti added the comment:
Configuring the editor to remove trailing whitespace, and using make patchcheck
are other valid solutions to this problem.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16405
Christian Heimes added the comment:
I'm all with Antoine's suggestion. readprofile() should not be executed when
sys.flags.ignore_environment is set.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16248
Nick Coghlan added the comment:
Sure, but both of those can fail (forgetting to run make patchcheck, using a
different editor from your normal one for some reason)
Once the commit hook is set up properly, you get alerted to the problem as soon
as you try to commit, rather than having to
Ezio Melotti added the comment:
I'm not against your proposal. If the goal is to explain how to get rid of
trailing whitespace then the other solutions should be mentioned too (I think
made patchcheck already is). If the goal is to show how to set up local hooks
and where to get them, then
Serhiy Storchaka added the comment:
Here is a patch which optimize (speed up 2x) Python implementation of ZIP
decryptor. It is almost the maximum of what can be achieved without
significant degradation of maintainability.
Of course, 2x is less then 100x, but it more portable and costs almost
Rafik Draoui added the comment:
Here is a patch with an implementation of os.path.commonpath, along with tests
and documentation. At the moment, this is only implemented for POSIX, as I
don't feel like I know enough about Windows to tackle drive letters and UNC in
paths without spending some
Serhiy Storchaka added the comment:
See also issue15989.
--
assignee: - docs@python
components: +Documentation, Extension Modules, Interpreter Core
nosy: +docs@python, mark.dickinson, serhiy.storchaka
stage: - needs patch
type: - behavior
versions: +Python 3.2, Python 3.3
Changes by Serhiy Storchaka storch...@gmail.com:
--
stage: needs patch - patch review
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10395
___
___
Serhiy Storchaka added the comment:
At the moment, this is only implemented for POSIX, as I don't feel like I
know enough about Windows to tackle drive letters and UNC in paths without
spending some more time on it.
Just use splitdrive() and first ensure that all drivespecs are same, then
Changes by Serhiy Storchaka storch...@gmail.com:
--
stage: - needs patch
versions: +Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14811
___
Changes by Serhiy Storchaka storch...@gmail.com:
--
stage: patch review - needs patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14377
___
___
Sean Ochoa added the comment:
Ready for review.
--
keywords: +patch
Added file: http://bugs.python.org/file27884/issue-13349.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13349
___
Changes by Serhiy Storchaka storch...@gmail.com:
--
stage: patch review - needs patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13968
___
___
Ezio Melotti added the comment:
You should use assertRaises/assertRaisesRegex to check the error message and
add more tests to cover all the changes. I also noticed an inconsistence
between 'element not in container' and 'element is not in container' (note the
extra 'is'). FWIW I prefer the
Berker Peksag added the comment:
I don't think it's necessary to check for UnboundLocalError/NameError
in the tests.
Thanks for the review.
Attached a new patch.
--
Added file: http://bugs.python.org/file27885/pkgutil-name-with-test_v3.diff
___
Changes by Berker Peksag berker.pek...@gmail.com:
--
nosy: -berker.peksag
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15276
___
___
R. David Murray added the comment:
If the encryption is so horrible why is there any support (with bad
performance) at all in Python?
I would say it there so that people can use python to decrypt an encrypted
zip archive they have been sent that was generated by some other tool. I would
Berker Peksag added the comment:
Alexander: Did you have a chance to review the test?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue6478
___
New submission from Chris Jerdonek:
I think the Package Index (PyPI) documentation would be clearer if the section
called Uploading Packages to the Package Index:
http://docs.python.org/3.4/distutils/uploading.html
were made a part of the previous section about PyPI (now called Registering
Alexander Belopolsky added the comment:
issue6478_v2.patch looks good to me. There is a long line in _strptime.py
which I will fix before committing.
--
stage: test needed - commit review
versions: -Python 3.2
___
Python tracker
New submission from yrammos:
I am building Python 2.7.3 using Homebrew as follows:
brew install --with-dtrace --quicktest python
The failing tests are:
test_ctypes
test_sys
Omitting --with-dtrace reduces the failures to one test:
test_ctypes
@samueljohn from github
Changes by Serhiy Storchaka storch...@gmail.com:
Removed file: http://bugs.python.org/file25709/issue8271-3.3.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8271
___
Changes by Serhiy Storchaka storch...@gmail.com:
Removed file: http://bugs.python.org/file26116/issue8271-3.3-fast-2.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8271
___
Changes by Serhiy Storchaka storch...@gmail.com:
--
versions: +Python 3.4 -Python 2.7, Python 3.1, Python 3.2, Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8271
___
Serhiy Storchaka added the comment:
What about commit? All Ezio's tests passsed, microbenchmark shows less than
10% differences:
vanilla patched
MB/s MB/s
2076 (-3%) 2007 decode utf-8 'A'*1
414 (-0%)413decode utf-8 '\x80'*1
1283 (-1%) 1275 decode
New submission from Eric Busboom:
The zipfile.testzip() method will open each of the files in a zip archive, but
does not close the files, resulting in a file descriptor leak.
--
components: Library (Lib)
messages: 174829
nosy: Eric.Busboom
priority: normal
severity: normal
status:
Robert de Vries added the comment:
The current situation is now that the decryption is part of Python. It is well
known to be computationally intensive and should therefore be implemented in C.
This patch provides that support.
The discussion if Python should support the decryption is behind
Changes by Serhiy Storchaka storch...@gmail.com:
--
stage: test needed - patch review
versions: +Python 3.4 -Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12892
___
Roundup Robot added the comment:
New changeset 5962f192a483 by Ezio Melotti in branch '3.3':
#8271: the utf-8 decoder now outputs the correct number of U+FFFD characters
when used with the replace error handler on invalid utf-8 sequences. Patch
by Serhiy Storchaka, tests by Ezio Melotti.
Ezio Melotti added the comment:
Fixed, thanks for updating the patch!
I committed it on 3.3 too, and while this could have gone on 2.7/3.2 too IMHO,
it's to much work to port it there and not worth it.
--
status: open - closed
versions: +Python 3.3
Serhiy Storchaka added the comment:
issue5057-3.diff LGTM.
I added debug output in peepholer, ran tests and found that this optimization
happened for unicode strings only in test_multibytecodec (where it used
deliberately) and test_peepholer. Seems as this is very rare case.
--
Serhiy Storchaka added the comment:
Agree. In 2.7 UTF-8 codec still broken in corner cases (it accepts
surrogates) and 3.2 is coming to an end of maintaining. In any case it is
only recomendation, not demands.
--
___
Python tracker
Changes by Serhiy Storchaka storch...@gmail.com:
--
keywords: +easy
stage: - needs patch
type: behavior - resource usage
versions: +Python 3.2, Python 3.3, Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16408
Roundup Robot added the comment:
New changeset 9481e062fe26 by Ezio Melotti in branch '2.7':
#5057: the peepholer no longer optimizes subscription on unicode literals (e.g.
ufoo[0]) in order to produce compatible pyc files between narrow and wide
builds.
Changes by Ezio Melotti ezio.melo...@gmail.com:
--
resolution: - fixed
stage: commit review - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5057
___
New submission from anatoly techtonik:
Renamed urllib.urlretrieve changed behaviour in Py3k, which leads to
ZeroDivisionErrors in applications that use block_size parameter for
calculations. Previously, block size was constant. Now it varies making it
impossible to exactly calculate value
Eric Busboom added the comment:
I've tried just closing the ZipExtFile created in testzip, but that didn't
actually close the file. It looks like ZipExtClose.close() also doesn't close
the file descriptor, at least when the ZipFile is constructed on a filename.
This code worked (Addition of
New submission from anatoly techtonik:
http://hg.python.org/cpython/file/tip/PC/winsound.c
No need to maintain this in C. It doesn't seem like a critical part of code.
Will there be significant performance penalty?
--
components: Library (Lib), ctypes
messages: 174838
nosy: techtonik
Changes by anatoly techtonik techto...@gmail.com:
--
assignee: - docs@python
components: +Documentation
nosy: +docs@python
versions: +Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4
___
Python tracker rep...@bugs.python.org
Roundup Robot added the comment:
New changeset 96f4cee8ea5e by Victor Stinner in branch '3.3':
Issue #8271: Fix compilation on Windows
http://hg.python.org/cpython/rev/96f4cee8ea5e
New changeset 6f44f33460cd by Victor Stinner in branch 'default':
(Merge 3.3) Issue #8271: Fix compilation on
Martin v. Löwis added the comment:
ctypes is not an acceptable implementation strategy for modules in the standard
library. No need to reimplement it.
--
nosy: +loewis
resolution: - wont fix
status: open - closed
___
Python tracker
STINNER Victor added the comment:
test_cmd_line_script.test_non_utf8() is failing on Mac OS X since the changeset
95d1adf144ee.
==
FAIL: test_non_utf8 (test.test_cmd_line_script.CmdLineTest)
1 - 100 of 138 matches
Mail list logo
