[issue45299] SMTP.send_message() does from mangling when it should not
Grant Edwards added the comment: Yes, passing the mangle_from value to BytesGenerator seems like the safest fix. It's unfortunate that BytesGenerator defaults to doing "the wrong thing" in the absence of a policy argument, but there might be code that depends on it. I've never done a PR before, but I could work on it next week. -- ___ Python tracker <https://bugs.python.org/issue45299> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45299] SMTP.send_message() does from mangling when it should not
New submission from Grant Edwards : SMTP.send_message() does from mangling even when the message's policy has that disabled. The problem is in the send_messsage() function shown below: 912 def send_message(self, msg, from_addr=None, to_addrs=None, 913 mail_options=(), rcpt_options=()): 914 """Converts message to a bytestring and passes it to sendmail. ... 963 # Make a local copy so we can delete the bcc headers. 964 msg_copy = copy.copy(msg) ... 977 with io.BytesIO() as bytesmsg: 978 if international: 979 g = email.generator.BytesGenerator( 980 bytesmsg, policy=msg.policy.clone(utf8=True)) 981 mail_options = (*mail_options, 'SMTPUTF8', 'BODY=8BITMIME') 982 else: 983 g = email.generator.BytesGenerator(bytesmsg) 984 g.flatten(msg_copy, linesep='\r\n') 985 flatmsg = bytesmsg.getvalue() If 'international' is True, then the BytesGenerator is passed msg.policy with utf8 added, and from mangling is only done if the message's policy has from mangling enabled. This is correct behavior. If 'international' is False, then the generator always does from mangling regardless of the message'spolicy. From mangling is only used when writing message to mbox format files. When sending a message via SMTP It is wrong to do it when the message's policy says not to. This needs to be fixed by passing the message's policy to BytesGenerator() in the 'else' clause also. I would suggest changing 983 g = email.generator.BytesGenerator(bytesmsg) to 983 g = email.generator.BytesGenerator(bytesmsg, policy=msg.policy) The problem is that if neither mangle_from_ nor policy arguments are passed to email.generator.BytesGenerator(), then mangle_from_ defaults to True, and the mangle_from_ setting in the message is ignored. This is not really documented: https://docs.python.org/3/library/email.generator.html#email.generator.BytesGenerator If optional mangle_from_ is True, put a > character in front of any line in the body that starts with the exact string "From ", that is From followed by a space at the beginning of a line. mangle_from_ defaults to the value of the mangle_from_ setting of the policy. Where "the policy" refers to the one passed to BytesGenerator(). Note that this section does _not_ state what happens if neither mangle_from_ nor policy are passed to BytesGenerator(). What actually happens is that in that case mangle_from_ defaults to True. (Not a good choice for default, since that's only useful for the one case where you're writing to an mbox file.) However, there is also a misleading sentence later in that same section: If policy is None (the default), use the policy associated with the Message or EmailMessage object passed to flatten to control the message generation. That's only partially true. If you don't pass a policy to BytesGenerator(), only _some_ of the settings from the message's policy will be used. Some policy settings (e.g. mangle_from_) are obeyed when passed to BytesGenerator(), but ignored in the message's policy even if there was no policy passed to BytesGenerator(). The documentation needs to be changed to state that mangle_from_ defaults to True if neitehr mangle_from_ nor policy are passed to BytesGenerator(), and that last sentence needs to be changed to state that when no policy is passed to BytesGenerator() only _some_ of the fields in the message's policy are used to control the message generation. (An actual list of policy fields are obeyed from the message's policy would be nice.) -- components: Library (Lib) messages: 402690 nosy: grant.b.edwards priority: normal severity: normal status: open title: SMTP.send_message() does from mangling when it should not versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue45299> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43584] Doc description of str.title() upper case vs. title case.
New submission from Grant Edwards : The documentation for str.title() states that the first character in each world is converted to upper case. That is not correct for recent versions of Python. The first character in each word is converted to title case. Title and upper may be the same for English/ASCII, but other languages have characters for which upper and title case are different. -- assignee: docs@python components: Documentation messages: 389242 nosy: docs@python, grant.b.edwards priority: normal severity: normal status: open title: Doc description of str.title() upper case vs. title case. versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue43584> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41118] datetime object does not preserve POSIX timestamp
New submission from Grant Petty : For complete context, see https://stackoverflow.com/questions/62582386/how-do-i-get-a-naive-datetime-object-that-correctly-uses-utc-inputs-and-preserve Short version: It does not seem correct that a datetime object produced *from* a POSIX timestamp using utcfromtimestamp should then return a different timestamp. As a user, I would like to be able to count on the POSIX timestamp as being the one conserved property of a datetime object, regardless of whether it is naive or time zone aware. > dt0 = dt.datetime(year=2020, month=1, day=1,hour=0,minute=0, tzinfo=pytz.utc) > print(dt0) 2020-01-01 00:00:00+00:00 > ts0 = dt0.timestamp() > print(ts0) 1577836800.0 > dt1 = dt.datetime.utcfromtimestamp(ts0) > print(dt1) 2020-01-01 00:00:00 > ts1 = dt1.timestamp() > print(ts1) 1577858400.0 -- messages: 372387 nosy: gpetty priority: normal severity: normal status: open title: datetime object does not preserve POSIX timestamp type: behavior versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue41118> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14465] xml.etree.ElementTree: add feature to prettify XML output
Change by Andrew Grant : -- nosy: +Andrew Grant ___ Python tracker <https://bugs.python.org/issue14465> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37134] Use PEP570 syntax in the documentation
Grant Jenks added the comment: Pablo, I never intended disrespect toward you personally. And I am sorry my words came across that way. I would rather the feature be one of Python's more esoteric qualities. I think Carol has described the most reasonable way forward. And in particular, I like this creative idea: > A Sphinx extension may also be made to show a simple user-friendly view and > with a click the fully accurate view. I agree too with Raymond in this point: > I don't think inclusion in 3.9 should be automatic. As anecdata: I showed the PEP and feature to an intermediate class of 15 professional software engineers today. The first question I got was, "when should I use that in my Python code?" And I think the answer is rarely. We reviewed the motivating cases in the PEP and those made sense to them. But I was left feeling concern that if it were prominent and frequent in the docs then people will be likely to imitate, not least of which through simple copy/paste, what they see there without understanding the C-API and why it is that way. -- ___ Python tracker <https://bugs.python.org/issue37134> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37134] [EASY] Use PEP570 syntax in the documentation
Grant Jenks added the comment: FWIW, I would rather not see the docs littered with "/". I've taught Python to hundreds of professional software engineers over the last five years and in all that time nobody has ever asked when the args need to be positional. It's easy to experiment to find out and it's historically been an implementation detail. I think the number of times people are surprised is far less than the number of times people never notice at all. As Raymond described, this change will elevate the feature to a day-1 topic and it's pretty useless to a day-1 user. This is another step toward making what I see as an unfortunate implementation detail into formal semantics. -- nosy: +grantjenks ___ Python tracker <https://bugs.python.org/issue37134> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37014] [First easy issue] fileinput module should document that openhook and mode are ignored when reading from stdin
Change by Grant Wu : -- nosy: +grantwu -Grant Wu2 ___ Python tracker <https://bugs.python.org/issue37014> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37014] fileinput module should document that openhook and mode are ignored when reading from stdin
New submission from Grant Wu : https://github.com/python/cpython/blob/master/Lib/fileinput.py#L326 shows that the openhook and mode are ignored when reading from stdin. Since part of fileinput's functionality is to abstract over whether one is reading from stdin or over a file, I think this abstraction leak should be documented. One common use case where this might break is when attempting to set the file encoding using the included fileinput.hook_encoded functionality. -- assignee: docs@python components: Documentation messages: 343221 nosy: Grant Wu2, docs@python priority: normal severity: normal status: open title: fileinput module should document that openhook and mode are ignored when reading from stdin versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue37014> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34055] IDLE: erroneous 'smart' indents in shell
Grant Jenks added the comment:
This issue was closed but I still see the problem in 3.7.2. Here's a snippet
with line numbers from IDLE:
01 Python 3.7.2 (default, Dec 30 2018, 08:59:00)
02 [Clang 9.1.0 (clang-902.0.39.2)] on darwin
03 Type "help", "copyright", "credits" or "license()" for more information.
04 >>> 1 + 2
05 3
06 >>> print('Hello')
07 Hello
08 >>> d = {1: 'uno', 2: 'dos', 3: 'tres}
09
10 SyntaxError: EOL while scanning string literal
11 >>> 1 + 2
12
13 3
14 >>>
Notice that IDLE is inserting an extra blank line at (12) above.
And here's a snippet with line numbers from the Python shell:
01 Python 3.7.2 (default, Dec 30 2018, 08:59:00)
02 [Clang 9.1.0 (clang-902.0.39.2)] on darwin
03 Type "help", "copyright", "credits" or "license" for more information.
04 >>> 1 + 2
05 3
06 >>> print('Hello')
07 Hello
08 >>> d = {1: 'uno', 2: 'dos', 3: 'tres}
09 File "", line 1
10 d = {1: 'uno', 2: 'dos', 3: 'tres}
11 ^
12 SyntaxError: EOL while scanning string literal
13 >>> 1 + 2
14 3
15 >>>
Between lines (13) and (14) there is no extra blank line.
I'm sorry if my initial post was unclear. But the extra blank line is the bug
I'm describing. I don't think there should be an extra blank line between (11)
and (13) in the IDLE shell. This blank line persists for every input, even
after restarts.
I'm on macOS.
I would be interested in debugging the issue locally but I ran into a couple
issues trying to do so. When I check out the CPython sources and build the
python.exe executable, I get this error when trying to execute IDLE:
$ ./python.exe -m pdb -m idlelib.idle
> /Users/grantj/repos/cpython/Lib/idlelib/idle.py(1)()
-> import os.path
(Pdb) c
Traceback (most recent call last):
File "/Users/grantj/repos/cpython/Lib/pdb.py", line 1695, in main
pdb._runmodule(mainpyfile)
File "/Users/grantj/repos/cpython/Lib/pdb.py", line 1540, in _runmodule
self.run(code)
File "/Users/grantj/repos/cpython/Lib/bdb.py", line 585, in run
exec(cmd, globals, locals)
File "/Users/grantj/repos/cpython/Lib/idlelib/idle.py", line 1, in
import os.path
File "/Users/grantj/repos/cpython/Lib/idlelib/pyshell.py", line 1507, in main
macosx.setupApp(root, flist)
File "/Users/grantj/repos/cpython/Lib/idlelib/macosx.py", line 280, in
setupApp
overrideRootMenu(root, flist)
File "/Users/grantj/repos/cpython/Lib/idlelib/macosx.py", line 181, in
overrideRootMenu
del mainmenu.menudefs[-2][1][0]
IndexError: list assignment index out of range
If I comment out line 181 in /Users/grantj/repos/cpython/Lib/idlelib/macosx.py
then I can get IDLE to start. But it will later crash trying to display the
first tooltip:
$ ./python.exe -m pdb -m idlelib.idle
> /Users/grantj/repos/cpython/Lib/idlelib/idle.py(1)()
-> import os.path
(Pdb) c
2019-01-02 15:52:57.582 python.exe[23803:6374992] *** Assertion failure in
-[_NSCGSWindow setFrame:],
/BuildRoot/Library/Caches/com.apple.xbs/Sources/AppKit/AppKit-1561.60.100/CGS.subproj/NSCGSWindow.m:1002
2019-01-02 15:52:57.588 python.exe[23803:6374992] *** Terminating app due to
uncaught exception 'NSInternalInconsistencyException', reason: 'Invalid
parameter not satisfying: CGRectContainsRect(CGRectMake((CGFloat)INT_MIN,
(CGFloat)INT_MIN, (CGFloat)INT_MAX - (CGFloat)INT_MIN, (CGFloat)INT_MAX -
(CGFloat)INT_MIN), frame)'
*** First throw call stack:
(
0 CoreFoundation 0x7fff48fa923b
__exceptionPreprocess + 171
1 libobjc.A.dylib 0x7fff7023ac76
objc_exception_throw + 48
2 CoreFoundation 0x7fff48faefd2
+[NSException raise:format:arguments:] + 98
3 Foundation 0x7fff4b0d9150
-[NSAssertionHandler handleFailureInMethod:object:file:lineNumber:description:]
+ 193
4 AppKit 0x7fff465d6f50
-[_NSCGSWindow setFrame:] + 475
5 AppKit 0x7fff4668eb07
_NSCreateWindowWithOpaqueShape2 + 248
6 AppKit 0x7fff4668d763 -[NSWindow
_commonAwake] + 1057
7 AppKit 0x7fff46d9bbe7
-[NSWindow(NSWindow_Carbon)
windowRefWithCompositedAttribute:andFrameworkScaledAttribute:] + 139
8 Tk 0x0001061f9ad5 XMapWindow +
239
9 Tk 0x000106166dbf Tk_MapWindow
+ 89
10 Tk 0x
[issue35196] IDLE text squeezer is too aggressive and is slow
Change by Grant Jenks : -- nosy: +grantjenks ___ Python tracker <https://bugs.python.org/issue35196> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34549] unittest docs could use another header
Change by Grant Jenks : -- nosy: +grantjenks ___ Python tracker <https://bugs.python.org/issue34549> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34445] asyncio support in doctests
Grant Jenks added the comment: This is not a bug in Python. The SyntaxError matches expected behavior. According to the Python grammar, you can't have "await" outside of a function. You have "await" at the globals scope which is not permitted. You may only "await" functions from within other functions. Doctest is designed to emulate what you would type into the Python shell. Your doctest snippet does not work there either: ``` $ python3 Python 3.7.0 (default, Jun 28 2018, 05:55:06) [Clang 9.1.0 (clang-902.0.39.2)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> async def hello_world(): ... return "Hello, world!" ... >>> await hello_world() File "", line 1 SyntaxError: 'await' outside function ``` To make your doctests work, use ``asyncio.run`` like so: ``` import asyncio async def hello_world(): """ Will greet the world with a friendly hello. >>> asyncio.run(hello_world()) 'hello world' """ return "hello world" if __name__ == "__main__": import doctest doctest.testmod() ``` Stefan, you may get a quicker answer next time from a forum like StackOverflow. Yury, it's probably a good idea to cover this case in your upcoming asyncio docs improvements. -- nosy: +grantjenks ___ Python tracker <https://bugs.python.org/issue34445> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14841] os.get_terminal_size() should check stdin as a fallback
Grant Jenks added the comment:
I asked on the ncurses maintainers email list about their logic and was pointed
to tty_settings.c which checks:
1. stderr
2. stdout
3. stdin
4. open('/dev/tty', 'r+')
I don't know a cross-platform way to check #4 but I think #1-3 are a reasonable
change to shutil.get_terminal_size().
The current logic checks only stdout. I'd like to amend that to try stderr,
stdout, and stdin after checking the COLUMNS and LINES env vars. So the new
logic would be:
1. Check COLUMNS and LINES env vars (for overrides)
2. Check os.get_terminal_size(stderr)
3. Check os.get_terminal_size(stdout)
4. Check os.get_terminal_size(stdin)
--
nosy: +grantjenks
versions: +Python 3.6, Python 3.7, Python 3.8
___
Python tracker
<https://bugs.python.org/issue14841>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34055] IDLE inserts extra blank line in prompt after SyntaxError
New submission from Grant Jenks :
IDLE inserts an extra blank line after the prompt after encountering a
SyntaxError:
```
>>> 1 + 2
3
>>> print('Hello')
Hello
v-- Missing single quote!
>>> d = {1: 'uno', 2: 'dos', 3: 'tres}
SyntaxError: EOL while scanning string literal
>>> print('Hello')
<-- Extra blank line and whitespace (tab and space).
Hello
>>> 1 + 2
<-- Extra blank line and whitespace (tab and space).
3
>>>
```
Notice the line starting with ">>> d =" above contains a missing single quote
which causes a "SyntaxError: EOL while scanning string literal". This causes
IDLE to insert extra blank lines with one tab and one space after every input.
The old behavior looked like:
```
>>> 1 + 2
3
>>> print('Hello')
Hello
>>> d = {1: 'uno', 2: 'dos', 3: 'tres}
SyntaxError: EOL while scanning string literal
>>> print('Hello')
Hello
>>> 1 + 2
3
```
--
assignee: terry.reedy
components: IDLE
messages: 321126
nosy: grantjenks, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE inserts extra blank line in prompt after SyntaxError
type: behavior
versions: Python 3.6
___
Python tracker
<https://bugs.python.org/issue34055>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23666] Add shell session logging option to IDLE
Grant Jenks added the comment: +1 from me. I'd like to see it ask me to save when I close the window if I've already saved once. -- nosy: +grantjenks ___ Python tracker <https://bugs.python.org/issue23666> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25115] SSL_set_verify_depth not exposed by the ssl module
Grant Bremer added the comment: The use case is for an internal PKI implementation where verification should be, needs to be limited to certificates signed by the PKI CA and no higher to, say, a larger realm which would not be appropriate. -- ___ Python tracker <https://bugs.python.org/issue25115> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27616] filedialog.askdirectory inconsistent on Windows between returning "C:/" and "C:/users" (no trailing slash)
New submission from Grant Hillebrand: When running the following code on Windows 7 (64bit os), and selecting a root drive letter, eg C:, it returns "C:/", with a slash appended. When selecting any other path below root level, eg "C:/users" it returns "C:/users" - no slash appended. This then introduces an odd edge case in processing the output if the path is to be prepended to directory walk data and other file names. Python 3.5.2 (v3.5.2:4def2a2901a5, Jun 25 2016, 22:18:55) [MSC v.1900 64 bit (AMD64)] on win32 >>> from tkinter import filedialog >>> SourcePath = filedialog.askdirectory() >>> print(SourcePath) C:/ >>> SourcePath = filedialog.askdirectory() >>> print(SourcePath) C:/NVIDIA >>> -- components: Tkinter, Windows messages: 271296 nosy: Grant Hillebrand, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: filedialog.askdirectory inconsistent on Windows between returning "C:/" and "C:/users" (no trailing slash) type: behavior versions: Python 3.3, Python 3.5 ___ Python tracker <http://bugs.python.org/issue27616> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27385] itertools.groupby has misleading doc string
New submission from Grant Mathews: The itertools.groupby function is generally well-documented, but the fact that it only groups consecutive occurrences of keys is not mentioned in the doc string, which is where that information is most needed. -- assignee: docs@python components: Documentation files: groupby_doc.patch keywords: patch messages: 269211 nosy: docs@python, gmathews priority: normal severity: normal status: open title: itertools.groupby has misleading doc string versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file43531/groupby_doc.patch ___ Python tracker <http://bugs.python.org/issue27385> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25115] SSL_set_verify_depth not exposed by the ssl module
Changes by Grant Bremer : -- hgrepos: -316 ___ Python tracker <http://bugs.python.org/issue25115> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25115] SSL_set_verify_depth not exposed by the ssl module
Grant Bremer added the comment: Attached is a patch for the 3.5 branch. The test is minimal -- we are relying on the underlying OpenSSL library and its context to manage the data. I have removed the data validation from the set function -- OpenSSL seems happy to accept negative numbers for depth, even if that is a non-sensical value. I have started on the documentation, and can do a more comprehensive job if the code section is good or mostly good. I'll do the same for the 2.7 patch. -- Added file: http://bugs.python.org/file40483/verify_depth-3.5.patch ___ Python tracker <http://bugs.python.org/issue25115> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25115] SSL_set_verify_depth not exposed by the ssl module
Grant Bremer added the comment: I had thought that I had found documentation that the max depth is 100 and anything higher is ignored -- and as I read that back to me, I believe I read an example passage and interpreted it incorrectly. I'll remove that. We primarily use Python 2.7, so I started there. I'll submit another patch with changes on the 3.5 branch and add tests. -- versions: +Python 2.7 ___ Python tracker <http://bugs.python.org/issue25115> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25115] SSL_set_verify_depth not exposed by the ssl module
Changes by Grant Bremer : -- hgrepos: +316 keywords: +patch Added file: http://bugs.python.org/file40471/verify_depth.patch ___ Python tracker <http://bugs.python.org/issue25115> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25115] SSL_set_verify_depth not exposed by the ssl module
New submission from Grant Bremer: The SSL_set_verify_depth OpenSSL method is not currently exposed by the ssl module. The context object would seem to be the proper place for it as an instance method. -- components: Library (Lib) messages: 250718 nosy: Grant Bremer priority: normal severity: normal status: open title: SSL_set_verify_depth not exposed by the ssl module type: enhancement versions: Python 2.7, Python 3.5 ___ Python tracker <http://bugs.python.org/issue25115> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17827] Document codecs.encode and codecs.decode
Grant added the comment: codecs module and 'whats new' doc patch for 3.4 -- keywords: +patch nosy: +Grant versions: -Python 2.7, Python 3.3 Added file: http://bugs.python.org/file30860/17827.diff ___ Python tracker <http://bugs.python.org/issue17827> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16973] Extending the datetime package by adding a workDayMath module
New submission from Grant: This module would allow programmers to perform high level workday addition and subtraction - a commonly needed function in the finance and accounting world not yet provided in a standard python module. -- components: Extension Modules files: workDayMath.py messages: 180029 nosy: belopolsky, grantf priority: normal severity: normal status: open title: Extending the datetime package by adding a workDayMath module type: enhancement versions: Python 2.7 Added file: http://bugs.python.org/file28741/workDayMath.py ___ Python tracker <http://bugs.python.org/issue16973> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10018] IDLE not loading in xp pro due to tcl issue
New submission from Grant Andrew :
I'm attempting to use Python for the first time and am running into issues
before I'm out the door. I started with 3.2 and have worked backward
installing older versions in hopes that IDLE would load on my xp pro laptop.
After reading several threads here, I ran C:\>C:\python27\python
C:\python27\Lib\idlelib\idle.py at a command prompt and received the following
output:
C:\>C:\python27\python C:\python27\Lib\idlelib\idle.py
Traceback (most recent call last):
File "C:\python27\Lib\idlelib\idle.py", line 11, in
idlelib.PyShell.main()
File "C:\python27\Lib\idlelib\PyShell.py", line 1389, in main
root = Tk(className="Idle")
File "C:\python27\lib\lib-tk\Tkinter.py", line 1685, in __init__
self.tk = _tkinter.create(screenName, baseName, className, interactive, want
objects, useTk, sync, use)
_tkinter.TclError: Can't find a usable init.tcl in the following directories:
{C:\IBMTOOLS\Python22\tcl\tcl8.4} C:/IBMTOOLS/Python22/tcl/tcl8.5 C:/python2
7/lib/tcl8.5 C:/lib/tcl8.5 C:/lib/tcl8.5 C:/library C:/library C:/tcl8.5.2/libra
ry C:/tcl8.5.2/library
C:/IBMTOOLS/Python22/tcl/tcl8.4/init.tcl: version conflict for package "Tcl": ha
ve 8.5.2, need exactly 8.4
version conflict for package "Tcl": have 8.5.2, need exactly 8.4
while executing
"package require -exact Tcl 8.4"
(file "C:/IBMTOOLS/Python22/tcl/tcl8.4/init.tcl" line 19)
invoked from within
"source C:/IBMTOOLS/Python22/tcl/tcl8.4/init.tcl"
("uplevel" body line 1)
invoked from within
"uplevel #0 [list source $tclfile]"
This probably means that Tcl wasn't installed properly.
After searching threads here and a general google search on TCL I couldn't turn
up a link that helped with this issue. The closest tcl version available is
8.4.19 which isn't exact, so I'm hesitant to install this and blow something
else up.
Help is appreciated!
Grant
--
components: IDLE
messages: 117907
nosy: Grant.Andrew
priority: normal
severity: normal
status: open
title: IDLE not loading in xp pro due to tcl issue
type: crash
versions: Python 2.5, Python 2.6, Python 2.7
___
Python tracker
<http://bugs.python.org/issue10018>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9294] Dead code in Objects/object.c
Changes by Grant Limberg : Removed file: http://bugs.python.org/file18198/internal_print_non_recursive.patch ___ Python tracker <http://bugs.python.org/issue9294> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9294] Dead code in Objects/object.c
Grant Limberg added the comment: On second thought, internal_print() doesn't look like it's needed anymore as it's only called by PyObject_Print() and is no longer recursive. This second patch moves internal_print()'s function body into PyObject_Print and removes the internal_print function. -- Added file: http://bugs.python.org/file18201/internal_print_remove.patch ___ Python tracker <http://bugs.python.org/issue9294> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9294] Dead code in Objects/object.c
Grant Limberg added the comment: It looks like at one point, internal_print was a recursive function, but this is no longer the case. I've updated the function parameters to no longer contain the "nesting" parameter and removed the if block shown in this case. -- keywords: +patch nosy: +Grant.Limberg Added file: http://bugs.python.org/file18198/internal_print_non_recursive.patch ___ Python tracker <http://bugs.python.org/issue9294> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7303] pkgutil lacks documentation for useful functions
Grant Limberg added the comment: I've taken the liberty of creating a patch for this issue. I've taken the docstrings fromt he pkgutil module and conveted them to reST. Please let me know if there are any changes necessary. -- keywords: +patch nosy: +Grant.Limberg Added file: http://bugs.python.org/file18193/pkgutil-docs-py3k-branch.patch ___ Python tracker <http://bugs.python.org/issue7303> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue762963] timemodule.c: Python loses current timezone
Grant Bowman added the comment: Is there anything others like me can do to help get this fixed? -- nosy: +grantbow ___ Python tracker <http://bugs.python.org/issue762963> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7180] "pydoc -k" can generate AttributeError on Mac OS X
New submission from Kevin Grant : Running "pydoc -k ..." with a query string will end with a Python AttributeError while looking for Carbon.File.FSSpecType. I was using /usr/bin/pydoc on Mac OS X Snow Leopard, which is from Python 2.6.1. It appears that any query will produce a similar error, but here is one case: % pydoc -k example xxsubtype - xxsubtype is an example module showing how to subtype builtin types from C. doctest - Module doctest -- a framework for running examples in docstrings. Traceback (most recent call last): File "/usr/bin/pydoc2.6", line 7, in pydoc.cli() File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/pydoc.py", line 2216, in cli apropos(val) File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/pydoc.py", line 1911, in apropos ModuleScanner().run(callback, key) File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/pydoc.py", line 1876, in run for importer, modname, ispkg in pkgutil.walk_packages(onerror=onerror): File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/pkgutil.py", line 110, in walk_packages __import__(name) File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/plat-mac/lib- scriptpackages/CodeWarrior/__init__.py", line 8, in import aetools File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/plat-mac/aetools.py", line 36, in from aepack import packkey, pack, unpack, coerce, AEDescType File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/plat-mac/aepack.py", line 61, in FSSType = Carbon.File.FSSpecType AttributeError: 'module' object has no attribute 'FSSpecType' A solution would appear to be as follows: Since Carbon.File no longer defines FSSpecType, perhaps aepack.py should no longer support it. This would require removing the definition from aepack.py:61, as well as the case in the pack() routine (at aepack.py:88-89) that uses FSSType. -- assignee: ronaldoussoren components: Macintosh messages: 94307 nosy: kmgrant, ronaldoussoren severity: normal status: open title: "pydoc -k" can generate AttributeError on Mac OS X type: behavior versions: Python 2.6 ___ Python tracker <http://bugs.python.org/issue7180> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3063] memory leak in random number generation
Grant Tang <[EMAIL PROTECTED]> added the comment: Facundo: I understand now. You mean every unique float number used will be an object in memory. And never been released until Python quit. Is there any way to reclaim these memory? We need 3G memory to create a list of 100million randum numbers. Thank you very much, Grant On Sun, Jun 8, 2008 at 11:59 AM, Facundo Batista <[EMAIL PROTECTED]> wrote: > > Facundo Batista <[EMAIL PROTECTED]> added the comment: > > So, 0.0 would be cached, and the 414m+384m would be from the list > itself, right? I tried, > > >>> data = [(1.0/i) for i in xrange(1,1)] > > And the memory consumption was the big one. > > Grant, the 800 MB is taken by ONE 0.0, and a list of zillion positions. > > Furthermore, I did: > > >>> for x in xrange(1): > ... i = random() > > And the memory didn't increase. > > Grant, take note that there's no gc issue, the numbers stay alive > because the list itself is pointing to them. > > Closing this as invalid. > > -- > resolution: -> invalid > status: open -> closed > > ___ > Python tracker <[EMAIL PROTECTED]> > <http://bugs.python.org/issue3063> > ___ > Added file: http://bugs.python.org/file10552/unnamed ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3063> ___Facundo: I understand now. You mean every unique float number used will be an object in memory. And never been released until Python quit. Is there any way to reclaim these memory? We need 3G memory to create a list of 100million randum numbers. Thank you very much, Grant On Sun, Jun 8, 2008 at 11:59 AM, Facundo Batista <mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]> wrote: Facundo Batista <mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]> added the comment:So, 0.0 would be cached, and the 414m+384m would be from the list itself, right? I tried,>>> data = [(1.0/i) for i in xrange(1,1)]And the memory consumption was the big one.Grant, the 800 MB is taken by ONE 0.0, and a list of zillion positions. Furthermore, I did:>>> for x in xrange(1):... i = random()And the memory didn't increase.Grant, take note that there's no gc issue, the numbers stay alivebecause the list itself is pointing to them. Closing this as invalid.--resolution: -> invalidstatus: open -> closed ___Python tracker <mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]><http://bugs.python.org/issue3063"; target="_blank">http://bugs.python.org/issue3063> ___-- Grant Tang ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3063] memory leak in random number generation
Grant Tang <[EMAIL PROTECTED]> added the comment: Here I am confused. 100million floats in a list takes about 800M byte memory. This is acceptable. for i in xrange(1): data[i] = random() so it should be 800M plus a float returned by random(). But the problem is after this loop, except 800M bytes list, another >2G memory is occupied. And delete data list and call gc.collect() does not release these memory. I think you mean there are lots of floats used in random () call, they should be released after random() returned. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3063> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3063] memory leak in random number generation
Grant Tang <[EMAIL PROTECTED]> added the comment: I agree with Tim's comment. The problem's why these floats keep alive even after random() call returns. Then this becomes a garbage collection issue? ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3063> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3063] memory leak in random number generation
New submission from Grant Tang <[EMAIL PROTECTED]>:
#the following code consume about 800M memory, which is normal
n = 1
data = [0.0 for i in xrange(n)]
#however, if I assign random number to data list, it will consume extra
2.5G memory.
from random import random
for s in xrange(n):
data[i] = random()
#even if I delete data, only 800M memory released
del data
#call gc.collect() does not help, the extra 2.5G memory not released
import gc
gc.collect()
only when I quit Python, the memory is released. Same effect if I use
random number generator from numpy.
Same effect even if I just say data[i] = atpof("1.26")
I tried it in both Python 2.4 and 2.5 on linux 64bit and 32bit.
--
components: None
messages: 67833
nosy: gtang
severity: normal
status: open
title: memory leak in random number generation
type: resource usage
versions: Python 2.4, Python 2.5
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3063>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1777] ElementTree/cElementTree findtext inconsistency
New submission from Grant Monroe: cElementTree findtext seems to return None when it should return a string. -- components: Library (Lib) files: etree_test.py messages: 59618 nosy: gmonroe severity: normal status: open title: ElementTree/cElementTree findtext inconsistency type: behavior versions: Python 2.5 Added file: http://bugs.python.org/file9115/etree_test.py __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1777> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1486] Idle tab command completion
Grant Delaney added the comment: You can remove this issue. It was a compile problem on my side, missing libs etc. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1486> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1486] Idle tab command completion
New submission from Grant Delaney: Running idle from a terminal window in desktop. Python 2.5.1 (r251:54863, Nov 22 2007, 13:55:16) [GCC 4.1.2] on linux2 Type "copyright", "credits" or "license()" for more information. Personal firewall software may warn about the connection IDLE makes to its subprocess using this computer's internal loopback interface. This connection is not visible on any external interface and no data is sent to or received from the Internet. IDLE 1.2.1 >>> import sys >>> test = sys.<--- pressing tab should give you the available options for that module/library. The error in the console is as follows: Exception in Tkinter callback Traceback (most recent call last): File "/usr/lib/python2.5/lib-tk/Tkinter.py", line 1403, in __call__ return self.func(*args) File "/usr/lib/python2.5/idlelib/AutoCompleteWindow.py", line 217, in winconfig_event x, y, cx, cy = self.widget.bbox(self.startindex) File "/usr/lib/python2.5/lib-tk/Tkinter.py", line 2833, in bbox self.tk.call((self._w, 'bbox') + args)) or None File "/usr/lib/python2.5/lib-tk/Tkinter.py", line 1030, in _getints return tuple(map(getint, self.tk.splitlist(string))) ValueError: invalid literal for int() with base 10: '(128,' Exception in Tkinter callback Traceback (most recent call last): File "/usr/lib/python2.5/lib-tk/Tkinter.py", line 1403, in __call__ return self.func(*args) File "/usr/lib/python2.5/idlelib/AutoCompleteWindow.py", line 217, in winconfig_event x, y, cx, cy = self.widget.bbox(self.startindex) File "/usr/lib/python2.5/lib-tk/Tkinter.py", line 2833, in bbox self.tk.call((self._w, 'bbox') + args)) or None File "/usr/lib/python2.5/lib-tk/Tkinter.py", line 1030, in _getints return tuple(map(getint, self.tk.splitlist(string))) ValueError: invalid literal for int() with base 10: '(128,' Exception in Tkinter callback Traceback (most recent call last): File "/usr/lib/python2.5/lib-tk/Tkinter.py", line 1403, in __call__ return self.func(*args) File "/usr/lib/python2.5/idlelib/AutoCompleteWindow.py", line 217, in winconfig_event x, y, cx, cy = self.widget.bbox(self.startindex) File "/usr/lib/python2.5/lib-tk/Tkinter.py", line 2833, in bbox self.tk.call((self._w, 'bbox') + args)) or None File "/usr/lib/python2.5/lib-tk/Tkinter.py", line 1030, in _getints return tuple(map(getint, self.tk.splitlist(string))) ValueError: invalid literal for int() with base 10: '(128,' -- components: IDLE messages: 57759 nosy: Mufasa severity: normal status: open title: Idle tab command completion type: behavior versions: Python 2.5 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1486> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1485] Idle tab command completion
New submission from Grant Delaney: Exception in Tkinter callback Traceback (most recent call last): File "/usr/lib/python2.5/lib-tk/Tkinter.py", line 1403, in __call__ return self.func(*args) File "/usr/lib/python2.5/idlelib/AutoCompleteWindow.py", line 217, in winconfig_event x, y, cx, cy = self.widget.bbox(self.startindex) File "/usr/lib/python2.5/lib-tk/Tkinter.py", line 2833, in bbox self.tk.call((self._w, 'bbox') + args)) or None File "/usr/lib/python2.5/lib-tk/Tkinter.py", line 1030, in _getints return tuple(map(getint, self.tk.splitlist(string))) ValueError: invalid literal for int() with base 10: '(72,' -- components: IDLE messages: 57757 nosy: Mufasa severity: normal status: open title: Idle tab command completion type: behavior versions: Python 2.5 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1485> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
