[issue36245] PCBuild/build.bat errors, probably from space characters in paths
Jess added the comment: How long should I be waiting on review? -- ___ Python tracker <https://bugs.python.org/issue36245> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36245] PCBuild/build.bat errors, probably from space characters in paths
Jess added the comment: Nevermind, the hold over issue was from another bit. Updated the change request. -- versions: +Python 2.7, Python 3.4, Python 3.5, Python 3.6 ___ Python tracker <https://bugs.python.org/issue36245> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36245] PCBuild/build.bat errors, probably from space characters in paths
Jess added the comment: Looks like the brackets are fine even in the bracket case Steve mentioned. @echo off if NOT DEFINED ABCDEF ( echo "all good" ) if NOT DEFINED ABCDE ( echo "all good2" ) set ABCDE= if NOT DEFINED ABCDE ( echo "sadness" ) if [%ABCDE%]==[] ( echo "all good3" ) set ABCDE=] if [%ABCDE%] NEQ [] ( echo "all good4" ) set ABCDE="]" if [%ABCDE%] NEQ [] ( echo "all good5" ) >demo.bat "all good" "sadness" "all good3" "all good4" "all good5" -- ___ Python tracker <https://bugs.python.org/issue36245> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36245] PCBuild/build.bat errors, probably from space characters in paths
Jess added the comment: Alas, "IF NOT DEFINED PYTHON" isn't working - as it's even more possible to get into a state where PYTHON="" than it is for a bracket to be in the python name. Thus, the system would think it declared where we would have created it into an actual path otherwise. -- ___ Python tracker <https://bugs.python.org/issue36245> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36230] Please sort assertSetEqual's output
Jess added the comment: Good call on the repr(), hadn't noted the "3+4j" issue - __gt__ and __lt__ do work for compare there, but not sorted(). *shrug* Will make sure the solution takes that into account in some fashion. Bit slower as I expected as setting up the windows env has some bits that are not entirely happy. -- ___ Python tracker <https://bugs.python.org/issue36230> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36245] PCBuild/build.bat errors, probably from space characters in paths
Change by Jess : -- keywords: +patch pull_requests: +12229 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue36245> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36245] PCBuild/build.bat errors, probably from space characters in paths
Jess added the comment: Note: the error is actually in get_externals.bat, which is called by build.bat. -- ___ Python tracker <https://bugs.python.org/issue36245> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36245] PCBuild/build.bat errors, probably from space characters in paths
New submission from Jess : Have a fix for this that I'll send off shortly. What I see with the current head (my username was replaced with "Foo Bar" in this example: > Using "C:\Users\Foo > Bar\cpython\PCbuild\\..\externals\pythonx86\tools\python.exe" (found in > externals directory) > Bar\cpython\PCbuild\\..\externals\pythonx86\tools\python.exe""=="" was > unexpected at this time. My theory, window's turning: > C:\Users\Foo Bar into > "C:\Users\Foo Bar" and this is colliding with our use of "%PYTHON%", creating double quotes, or: > ""C:\Users\Foo Bar"" which, of course: > if ""C:\Users\Foo Bar""=="" does not make sense as a statement. -- components: Windows messages: 337530 nosy: Jess, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: PCBuild/build.bat errors, probably from space characters in paths type: compile error ___ Python tracker <https://bugs.python.org/issue36245> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36230] Please sort assertSetEqual's output
Jess added the comment: Wow! Thank you, very fast and the precise snippet of info I needed. Will try to send something off today. Very exciting. -- ___ Python tracker <https://bugs.python.org/issue36230> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36230] Please sort assertSetEqual's output
New submission from Jess : Currently https://docs.python.org/2/library/unittest.html#unittest.TestCase.assertSetEqual returns a random list, but I'd like to see it sorted for ease of reading which running tests. Should be small, but useful. Happy to make the edit myself, but have no clue how to send you changes. -- components: Tests messages: 337443 nosy: Jess priority: normal severity: normal status: open title: Please sort assertSetEqual's output type: enhancement ___ Python tracker <https://bugs.python.org/issue36230> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35502] Memory leak in xml.etree.ElementTree.iterparse
Change by Jess Johnson : -- versions: +Python 3.6 ___ Python tracker <https://bugs.python.org/issue35502> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35502] Memory leak in xml.etree.ElementTree.iterparse
New submission from Jess Johnson :
When given xml that that would raise a ParseError, but parsing is stopped
before the ParseError is raised, xml.etree.ElementTree.iterparse leaks memory.
Example:
import gc
from io import StringIO
import xml.etree.ElementTree as etree
import objgraph
def parse_xml():
xml = """
"""
parser = etree.iterparse(StringIO(initial_value=xml))
for _, elem in parser:
if elem.tag == 'LEVEL1':
break
def run():
parse_xml()
gc.collect()
uncollected_elems = objgraph.by_type('Element')
print(uncollected_elems)
objgraph.show_backrefs(uncollected_elems, max_depth=15)
if __name__ == "__main__":
run()
Output:
[]
Also see this gist which has an image showing the objects that are retained in
memory: https://gist.github.com/grokcode/f89d5c5f1831c6bc373be6494f843de3
--
components: XML
messages: 331861
nosy: jess.j
priority: normal
severity: normal
status: open
title: Memory leak in xml.etree.ElementTree.iterparse
type: resource usage
versions: Python 3.7
___
Python tracker
<https://bugs.python.org/issue35502>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24564] shutil.copytree fails when copying NFS to NFS
New submission from Jess Hamrick:
shutil.copytree seems to fail when copying files across NFS filesystems. In
this example (see bug_demo.py), /tmp is a normal ext4 filesystem and the
current working directory is NFS (version 4). Interestingly, it works fine to
to copy between ext4 and NFS, just not NFS and NFS (even if it's the same NFS
mount).
Depending on the specific version of 3.4, there are slightly different errors.
For 3.4.0:
$ uname -a
Linux compmodels-node 3.13.0-55-generic #94-Ubuntu SMP Thu Jun 18 00:27:10 UTC
2015 x86_64 x86_64 x86_64 GNU/Linux
$ python3 bug_demo.py
--
Python version info:
3.4.0 (default, Jun 19 2015, 14:20:21)
[GCC 4.8.2]
--
Copying NFS -- /tmp
Copying /tmp -- NFS
Copying NFS -- NFS
Traceback (most recent call last):
File /usr/lib/python3.4/shutil.py, line 336, in copytree
copystat(src, dst)
File /usr/lib/python3.4/shutil.py, line 212, in copystat
_copyxattr(src, dst, follow_symlinks=follow)
File /usr/lib/python3.4/shutil.py, line 152, in _copyxattr
os.setxattr(dst, name, value, follow_symlinks=follow_symlinks)
OSError: [Errno 22] Invalid argument: 'demo_files3'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File bug_demo.py, line 27, in module
shutil.copytree('demo_files', 'demo_files3')
File /usr/lib/python3.4/shutil.py, line 339, in copytree
if why.winerror is None:
AttributeError: 'OSError' object has no attribute 'winerror'
And for 3.4.3:
$ uname -a
Linux compmodels-node-02 3.19.0-21-generic #21-Ubuntu SMP Sun Jun 14 18:31:11
UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
$ python3 bug_demo.py
--
Python version info:
3.4.3 (default, Mar 26 2015, 22:03:40)
[GCC 4.9.2]
--
Copying NFS -- /tmp
Copying /tmp -- NFS
Copying NFS -- NFS
Traceback (most recent call last):
File bug_demo.py, line 27, in module
shutil.copytree('demo_files', 'demo_files3')
File /usr/lib/python3.4/shutil.py, line 343, in copytree
raise Error(errors)
shutil.Error: [('demo_files', 'demo_files3', [Errno 22] Invalid argument:
'demo_files3')]
This is probably related to https://bugs.python.org/issue17076 and my guess is
that's also why there is a difference in the error messages between 3.4.0 and
3.4.3.
--
files: bug_demo.py
messages: 246272
nosy: jhamrick
priority: normal
severity: normal
status: open
title: shutil.copytree fails when copying NFS to NFS
type: crash
versions: Python 3.4
Added file: http://bugs.python.org/file39864/bug_demo.py
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24564
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24564] shutil.copytree fails when copying NFS to NFS
Jess Hamrick added the comment:
Some further information: if I run copystat directly on 3.4.3, I get
essentially the same error as on 3.4.0. So really it only looks like the
difference is just in how the error is reported:
Traceback (most recent call last):
File bug_demo.py, line 31, in module
shutil.copystat('demo_files', 'demo_files3')
File /usr/lib/python3.4/shutil.py, line 213, in copystat
_copyxattr(src, dst, follow_symlinks=follow)
File /usr/lib/python3.4/shutil.py, line 153, in _copyxattr
os.setxattr(dst, name, value, follow_symlinks=follow_symlinks)
OSError: [Errno 22] Invalid argument: 'demo_files3'
Also, I should mention that I did test this on 2.7 as well, and it is not an
issue there.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24564
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5434] datetime.monthdelta
Jess Austin jess.aus...@gmail.com added the comment: Yeah, the masses have spoken, and their silence is deafening. I was going to downplay the health of the package based on the number of downloads, but then I looked at the futures page. b^) Seriously, getting this in would require a core developer wanting it in, and at this point it seems none do. On the subject of float operations, while there may be some question about the integerness or floatness of timedelta, monthdelta is definitely an integer. As monthdelta already supports multiplication by integers and floor division by integers or monthdeltas, I don't see anything missing. To use monthdeltas with floats is to miss the point entirely. -- status: pending - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5434 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5434] datetime.monthdelta
Changes by Jess Austin jess.aus...@gmail.com: -- status: open - pending ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5434 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5516] equality not symmetric for subclasses of datetime.date and datetime.datetime
Jess Austin jess.aus...@gmail.com added the comment: Could you provide some reasoning for such a resolution? I had thought that won't fix indicated that the issue wasn't actually an error in behavior. I grant that most people will never see this particular error, but it is an error. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5516 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5516] equality not symmetric for subclasses of datetime.date and datetime.datetime
Jess Austin jess.aus...@gmail.com added the comment: To be systematic, without the patch: D(1900, 1, 1) DT(1900, 1, 1) False D(1900, 1, 1) DT(1900, 1, 1) False DT(1900, 1, 1) D(1900, 1, 1) Traceback (most recent call last): File stdin, line 1, in module TypeError: can't compare DT to D DT(1900, 1, 1) D(1900, 1, 1) Traceback (most recent call last): File stdin, line 1, in module TypeError: can't compare DT to D with the patch: D(1900, 1, 1) DT(1900, 1, 1) True D(1900, 1, 1) DT(1900, 1, 1) False DT(1900, 1, 1) D(1900, 1, 1) Traceback (most recent call last): File stdin, line 1, in module TypeError: can't compare DT to D DT(1900, 1, 1) D(1900, 1, 1) Traceback (most recent call last): File stdin, line 1, in module TypeError: can't compare DT to D It might seem like the latter behavior is marginally better, but really this is just a mess, since a date-datetime comparison TypeErrors in all directions. I appreciate Alexander's more experienced perspective, but it's not obvious to me that this problem is insoluble simply due to OOP algebra. I'm going to keep tinkering with this to see if there isn't a way to satisfy his concerns AND fix these bugs WITHOUT breaking the established (and admittedly anti-OOP) behavior that dates are not equal to datetimes. (Incidentally, the test I removed still seems to be an arbitrary ad-hoc requirement that subclasses of date behave differently than date itself. I don't see how one could rely on this given the other inconsistencies with date subclasses, and so violating this in order to fix more serious problems seems acceptable.) I'm reminded of the set and frozenset situation, which seems almost dual to this one. set and frozenset don't inherit from each other, but they do compare. This seems to bite you only when you try to redefine comparison in subclasses. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5516 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7116] str.join() should be documented as taking an iterable
New submission from Jess Austin jess.aus...@gmail.com: In its __doc__ string and in the documentation, str.join() is described as taking a sequence. This is not general enough; it actually takes any iterable of strings: ','.join(str(x) for x in range(5)) '0,1,2,3,4' Maybe this is a small nit to pick, but it slowed me down for a few minutes, and I already vaguely remembered that str.join() could handle iterables. -- assignee: georg.brandl components: Documentation, Interpreter Core messages: 93909 nosy: georg.brandl, jess.austin severity: normal status: open title: str.join() should be documented as taking an iterable type: behavior versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7116 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7116] str.join() should be documented as taking an iterable
Changes by Jess Austin jess.aus...@gmail.com: -- keywords: +patch Added file: http://bugs.python.org/file15111/jointakesiterables.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7116 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5434] datetime.monthdelta
Jess Austin jess.aus...@gmail.com added the comment: The backport through python 2.3 is up at PyPI: http://pypi.python.org/pypi?name=MonthDelta:action=display Download source and install, or just easy_install. Documentation is also linked at PyPI. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5434 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5434] datetime.monthdelta
Changes by Jess Austin jess.aus...@gmail.com: Added file: http://bugs.python.org/file13743/monthdelta3.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5434 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5434] datetime.monthdelta
Changes by Jess Austin jess.aus...@gmail.com: Removed file: http://bugs.python.org/file13696/monthdelta2.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5434 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5434] datetime.monthdelta
Changes by Jess Austin jess.aus...@gmail.com: Added file: http://bugs.python.org/file13696/monthdelta2.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5434 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5520] refactor test_datetime.py
Jess Austin jess.aus...@gmail.com added the comment: I don't see a point to this one since Issue 5530 was rejected. If someone else wants this they can reopen it. -- status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5520 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5434] datetime.monthdelta
Jess Austin jess.aus...@gmail.com added the comment: With the rejection of Issue 5530, it seems best for the name of this class to remain lowercase. Mixing casing schemes within the same module would be perverse. -- title: datetime.MonthDelta - datetime.monthdelta ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5434 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2706] datetime: define division timedelta/timedelta
Jess Austin jess.aus...@gmail.com added the comment: A comment on the two most recent patches... For both of these, we can do the following: from datetime import timedelta td = timedelta(12) td datetime.timedelta(12) td //= 3 td datetime.timedelta(4) td //= timedelta(2) td 2 # CHANGED VARIABLE TYPE! I think the last operation will trap unsuspecting programmers, and provide no benefit for the savvy. There really is no reason to allow an in-place operation like this to change the type of the variable so drastically. (That is, I realize a similar thing could happen with ints and floats, but it seems worse with timedeltas and ints.) I feel the last operation should raise a TypeError, even though it would be quite valid for a non-in-place operation. -- nosy: +jess.austin ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2706 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5516] equality not symmetric for subclasses of datetime.date and datetime.datetime
Jess Austin jess.aus...@gmail.com added the comment: The attached patch fixes this issue, and updates the tests. Contrary to my initial impression, it seems that a previous developer knew of this behavior and thought it correct; see the comment of the test I deleted. I left memcmp() in. -- keywords: +patch Added file: http://bugs.python.org/file13403/issue5516.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5516 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5520] refactor test_datetime.py
Changes by Jess Austin jess.aus...@gmail.com: Added file: http://bugs.python.org/file13385/test_datetime.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5520 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5520] refactor test_datetime.py
Changes by Jess Austin jess.aus...@gmail.com: Removed file: http://bugs.python.org/file13376/test_datetime.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5520 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5530] datetime class names should obey PEP 8 CapWords convention
New submission from Jess Austin jess.aus...@gmail.com: Class names that comply with the CapWords naming convention described in PEP 8 (http://www.python.org/dev/peps/pep-0008/) are preferred. See the recent discussion that included the BDFL's recommendations at http://mail.python.org/pipermail/python-dev/2009-March/086684.html. Per those recommendations, the attached patch updates every class to expose a CapWords name to python: datetime.timedelta -- datetime.TimeDelta datetime.date -- datetime.Date datetime.tzinfo -- datetime.TZInfo datetime.time -- datetime.Time datetime.datetime -- datetime.DateTime In addition, the old lowercase names are reproduced as derived classes, the methods of which throw PendingDeprecationWarning, and the docstrings of which advise using the new CapWords class names. The test_datetime.py unit test is updated to check for proper functionality and for the presence of the pending deprecation warnings. (This patch relies on the previously-submitted refactoring patch attached to Issue 5520, http://bugs.python.org/issue5520.) Various other tests and support files are updated to use the new CapWords class names. The current patch still fails one test in test_datetime.py, due to previously-existing Issue 5516, http://bugs.python.org/issue5516. This patch includes no documentation updates. -- components: Library (Lib) files: pending_dep.diff keywords: patch messages: 83921 nosy: jess.austin severity: normal status: open title: datetime class names should obey PEP 8 CapWords convention type: behavior versions: Python 3.1 Added file: http://bugs.python.org/file13386/pending_dep.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5530 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5520] refactor test_datetime.py
New submission from Jess Austin jess.aus...@gmail.com: I've broken out this refactoring from some of the other datetime stuff I'm doing. The patch needn't be applied until the other issues that depend on it are. -- components: Library (Lib) files: test_datetime.diff keywords: patch messages: 83822 nosy: jess.austin severity: normal status: open title: refactor test_datetime.py versions: Python 3.1 Added file: http://bugs.python.org/file13376/test_datetime.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5520 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5516] equality not reflixive for subclasses of datetime.date and datetime.datetime
New submission from Jess Austin jess.aus...@gmail.com: While the datetime.date and datetime.datetime classes consistently handle mixed-type comparison, their subclasses do not: from datetime import date, datetime, time d = date.today() dt = datetime.combine(d, time()) d == dt False dt == d False class D(date): ... pass ... class DT(datetime): ... pass ... d = D.today() dt = DT.combine(d, time()) d == dt True dt == d False I think this is due to the premature optimization of using memcmp() in date_richcompare(). -- components: Library (Lib) messages: 83798 nosy: jess.austin severity: normal status: open title: equality not reflixive for subclasses of datetime.date and datetime.datetime type: behavior versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5516 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5516] equality not reflexive for subclasses of datetime.date and datetime.datetime
Changes by Jess Austin jess.aus...@gmail.com: -- title: equality not reflixive for subclasses of datetime.date and datetime.datetime - equality not reflexive for subclasses of datetime.date and datetime.datetime ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5516 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5516] equality not symmetric for subclasses of datetime.date and datetime.datetime
Changes by Jess Austin jess.aus...@gmail.com: -- title: equality not reflexive for subclasses of datetime.date and datetime.datetime - equality not symmetric for subclasses of datetime.date and datetime.datetime ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5516 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5434] datetime.MonthDelta
Changes by Jess Austin jess.aus...@gmail.com: Added file: http://bugs.python.org/file13309/monthdelta.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5434 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5434] datetime.MonthDelta
Changes by Jess Austin jess.aus...@gmail.com: Removed file: http://bugs.python.org/file13258/datetimemodule.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5434 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5434] datetime.MonthDelta
Jess Austin jess.aus...@gmail.com added the comment: This prototype python implementation passes the same tests that the C implementation in the patch does (modulo import differences). I'll probably backport this for 2.x versions. -- Added file: http://bugs.python.org/file13307/monthdelta.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5434 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5434] datetime.MonthDelta
Jess Austin jess.aus...@gmail.com added the comment: This is my first try at a patch. All functionality, tests, and documentation are included, but I won't be surprised if I need to make some changes! Please let me know. -- keywords: +patch Added file: http://bugs.python.org/file13258/datetimemodule.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5434 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5434] datetime.MonthDelta
Jess Austin jess.aus...@gmail.com added the comment: Rietveld link: http://codereview.appspot.com/25079 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5434 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3107] memory leak in make test (in test list), 2.5.2 not 2.5.1, Linux 64bit
jess [EMAIL PROTECTED] added the comment: This appears to be the same issue as in: 30552 months ago test_list on 64-bit platforms The failing test appears to be test_bigrepeat: def test_bigrepeat(self): x = self.type2test([0]) x *= 2**16 self.assertRaises(MemoryError, x.__mul__, 2**16) if hasattr(x, '__imul__'): self.assertRaises(MemoryError, x.__imul__, 2**16) I am experiencing the same symptoms with 64-bit builds on Solaris10 on an 8gb sparc machine with lots of virtual memory. The test is attempting to allocate a list with 4gb elements. This requires more space than there is physical memory so the machine starts swapping like crazy but does not throw an error in 64 bit mode. In 32 bit, it would presumabley throw the error because the test has requested more than 4gb of memory. In other words Python appears to be working as it should. In my case I am not sure that Solaris10 is scanning for virtual memory properly but that is an entirely different problem. -- nosy: +jess ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3107 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
