[ python-Bugs-1704156 ] TarFile.addfile() throws a struct.error
Bugs item #1704156, was opened at 2007-04-20 10:21
Message generated for change (Settings changed) made by gustaebel
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1704156&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
>Status: Closed
Resolution: None
Priority: 5
Private: No
Submitted By: K. C. Wong (dvusboy)
Assigned to: Lars Gustäbel (gustaebel)
Summary: TarFile.addfile() throws a struct.error
Initial Comment:
When adding a file to a TarFile instance using addfile(), if the file paths
(name and arcname) are unicode strings, then a struct.error will the raised.
Python versions prior to 2.5 do not show this behaviour.
Assuming the current directory has a file name 'mac.txt', here is an
interactive session that shows the problem:
Python 2.5 (r25:51908, Apr 18 2007, 19:06:57)
[GCC 3.4.6 20060404 (Red Hat 3.4.6-3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import tarfile
>>> t=tarfile.open('test.tar', 'w')
>>> i=t.gettarinfo(u'mac.txt', u'mac.txt')
>>> t.addfile(i, file(u'mac.txt', 'r'))
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python2.5/tarfile.py", line 1422, in addfile
self.fileobj.write(tarinfo.tobuf(self.posix))
File "/usr/lib/python2.5/tarfile.py", line 871, in tobuf
buf = struct.pack("%ds" % BLOCKSIZE, "".join(parts))
File "/usr/lib/python2.5/struct.py", line 63, in pack
return o.pack(*args)
struct.error: argument for 's' must be a string
--
Comment By: K. C. Wong (dvusboy)
Date: 2007-04-22 06:13
Message:
Logged In: YES
user_id=414175
Originator: YES
Much thanks for your effort.
--
Comment By: Lars Gustäbel (gustaebel)
Date: 2007-04-21 14:25
Message:
Logged In: YES
user_id=642936
Originator: NO
I checked in a simple fix to the release25-maint branch (rev. 54908). I
will come up with a more solid approach for 2.6.
--
Comment By: K. C. Wong (dvusboy)
Date: 2007-04-21 06:54
Message:
Logged In: YES
user_id=414175
Originator: YES
I see the work around, and I have already implemented similar workarounds
in my code. However, I have 2 problem with this response:
1. The behaviour changed. As the documentation did not explicitly say
tarfile does not support unicode file paths, and it worked prior to 2.5,
then I would say breaking that behaviour at the least calls for a
documentation update.
2. The error message stamps from struct failing to pack a unicode string.
First of all, I did not grasp the subtle message of it being a unicode
string as opposed to a non-unicode string. You see, I actually did not
expect unicode string in the first place, it was a by-product of TEXT_DATA
from a DOM tree. I can understand why struct.pack() throws (because no
explicit encoding scheme was specified) but it was so cryptic with regard
to tarfile itself, that I had to modify tarfile to track down the reason
for the exception.
In short, I would prefer the owner of tarfile to make an explicit support
or not-supported call on unicode file path, document said decision and make
more reasonable attempt in presenting releavant exceptions.
Thank you for looking into this.
--
Comment By: Lars Gustäbel (gustaebel)
Date: 2007-04-20 21:25
Message:
Logged In: YES
user_id=642936
Originator: NO
tarfile.py was never guaranteed to work correctly with unicode filenames.
The fact that this works with Python < 2.5 is purely accidental.
You can work around this (sticking to your example):
i = t.gettarinfo(u'mac.txt', 'mac.txt')
or:
i = t.gettarinfo('mac.txt')
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1704156&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1704156 ] TarFile.addfile() throws a struct.error
Bugs item #1704156, was opened at 2007-04-20 10:21
Message generated for change (Settings changed) made by gustaebel
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1704156&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: K. C. Wong (dvusboy)
Assigned to: Lars Gustäbel (gustaebel)
Summary: TarFile.addfile() throws a struct.error
Initial Comment:
When adding a file to a TarFile instance using addfile(), if the file paths
(name and arcname) are unicode strings, then a struct.error will the raised.
Python versions prior to 2.5 do not show this behaviour.
Assuming the current directory has a file name 'mac.txt', here is an
interactive session that shows the problem:
Python 2.5 (r25:51908, Apr 18 2007, 19:06:57)
[GCC 3.4.6 20060404 (Red Hat 3.4.6-3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import tarfile
>>> t=tarfile.open('test.tar', 'w')
>>> i=t.gettarinfo(u'mac.txt', u'mac.txt')
>>> t.addfile(i, file(u'mac.txt', 'r'))
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python2.5/tarfile.py", line 1422, in addfile
self.fileobj.write(tarinfo.tobuf(self.posix))
File "/usr/lib/python2.5/tarfile.py", line 871, in tobuf
buf = struct.pack("%ds" % BLOCKSIZE, "".join(parts))
File "/usr/lib/python2.5/struct.py", line 63, in pack
return o.pack(*args)
struct.error: argument for 's' must be a string
--
Comment By: K. C. Wong (dvusboy)
Date: 2007-04-22 06:13
Message:
Logged In: YES
user_id=414175
Originator: YES
Much thanks for your effort.
--
Comment By: Lars Gustäbel (gustaebel)
Date: 2007-04-21 14:25
Message:
Logged In: YES
user_id=642936
Originator: NO
I checked in a simple fix to the release25-maint branch (rev. 54908). I
will come up with a more solid approach for 2.6.
--
Comment By: K. C. Wong (dvusboy)
Date: 2007-04-21 06:54
Message:
Logged In: YES
user_id=414175
Originator: YES
I see the work around, and I have already implemented similar workarounds
in my code. However, I have 2 problem with this response:
1. The behaviour changed. As the documentation did not explicitly say
tarfile does not support unicode file paths, and it worked prior to 2.5,
then I would say breaking that behaviour at the least calls for a
documentation update.
2. The error message stamps from struct failing to pack a unicode string.
First of all, I did not grasp the subtle message of it being a unicode
string as opposed to a non-unicode string. You see, I actually did not
expect unicode string in the first place, it was a by-product of TEXT_DATA
from a DOM tree. I can understand why struct.pack() throws (because no
explicit encoding scheme was specified) but it was so cryptic with regard
to tarfile itself, that I had to modify tarfile to track down the reason
for the exception.
In short, I would prefer the owner of tarfile to make an explicit support
or not-supported call on unicode file path, document said decision and make
more reasonable attempt in presenting releavant exceptions.
Thank you for looking into this.
--
Comment By: Lars Gustäbel (gustaebel)
Date: 2007-04-20 21:25
Message:
Logged In: YES
user_id=642936
Originator: NO
tarfile.py was never guaranteed to work correctly with unicode filenames.
The fact that this works with Python < 2.5 is purely accidental.
You can work around this (sticking to your example):
i = t.gettarinfo(u'mac.txt', 'mac.txt')
or:
i = t.gettarinfo('mac.txt')
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1704156&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1707255 ] lost global variables in main memory intensive execution
Bugs item #1707255, was opened at 2007-04-25 11:45 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1707255&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Parser/Compiler Group: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jordi Pujol Ahulló (jpahullo) Assigned to: Nobody/Anonymous (nobody) Summary: lost global variables in main memory intensive execution Initial Comment: Hello, I was running a very main memory intensive program in my computer. I looked for similar bugs or troubles in the site and I didn't found any similar to this. I know that the use of global variables is not recommended by software engineering, but for special cases it is very fast to develop/test some ideas. My problem statement is the following (very simplified and also attached): ## BEGINNING OF CODE #test for globals counter_1 = 0 def modifierfunction(): global counter_1 #some code counter_1 += 1 #some other code def test(): for i in range(2): global counter_1 counter_1 = 0 for j in range(10): modifierfunction() print "COUNTER_1:", counter_1 def test2(): global counter_1 for i in range(2): counter_1 = 0 for j in range(10): modifierfunction() print "COUNTER_1:", counter_1 if __name__ == "__main__": test() test2() ## END OF CODE Globally speaking, it is a global variable, defined at the begining of the python file (counter_1), and it is modified in some functions within it (in this example, modifierfunction). At the end, it appear some tests that make what I need. If you try to run this code, it will always show the expected values in the standard out. But, let me to show you my problem. In the beginning, I have the global statement as in test2. But I found that it only take a corrent value for the first iteration. The others it has always a zero value. I didn't understand anything. Then, some collegue suggested me to change the place of the global statement (as in test()), and then it worked correctly, as it was expected. I repeat. The above example works fine. But when this same structure, but with my big problem, very main memory intensive, test2() didn't work correctly. Thank you for your attention. Regards, Jordi -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1707255&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1707497 ] generation errors in PDF-A4 tags for lib.pdf
Bugs item #1707497, was opened at 2007-04-25 17:20
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1707497&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Documentation
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Antoine LECA (antoinel)
Assigned to: Nobody/Anonymous (nobody)
Summary: generation errors in PDF-A4 tags for lib.pdf
Initial Comment:
I just downloaded 2.5.1, get the "books" from
http://www.python.org/ftp/python/doc/2.5.1/pdf-a4-2.5.1.tar.bz2> and start
reading (using Acrobat 5.01 17/09/2002 Spanish _and_ Foxit Reader 1.3 build
0930 if it matters) and I noticed in lib.pdf some bookmarks (right-hand column,
"Marcadores" in my localized interface) incorrectly generated, with traces from
the LaTeX sources still apparent:
4.8.5 encodings.utf_8_sig — UTF-8 codec with BOM signature
13.3 copy_reg — Register pickle support functions
15.4 dummy_thread — Drop-in replacement for the thread module
15.5 dummy_threading — Drop-in replacement for the threading
module
18.4.3 wsgiref.simple_server – a simple WSGI HTTP server
19.4.1 AU read Objects
19.4.2 AU write Objects
19.5.1 Wave read Objects
19.5.2 Wave write Objects
23.5 test.test_support — Utility functions for tests
26.2 __builtin__ — Built-in objects
26.3 __main__ — Top-level script environment
26.8 __future__ — Future statement definitions
30.8 py_compile — Compile Python source files
36.3 _winreg – Windows registry access
The actual text is correct (the above is a direct copy-and-paste), only the
summary bookmarks are wrong; and unfortunately, I cannot copy-and-paste them...
The last one shows something like
36.3 unhbox [EMAIL PROTECTED] penalty @M hskip [EMAIL PROTECTED] unhbox [EMAIL
PROTECTED] .06emvbox {hrule width.3em}discretionary {-}{}{}penalty @M hskip
[EMAIL PROTECTED] winreg -- Windows registry access
(at first sight I thought it was semi-crypted, anti-Windows or similar thing
:-))
HTH
Antoine
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1707497&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1633941 ] for line in sys.stdin: doesn't notice EOF the first time
Bugs item #1633941, was opened at 2007-01-12 05:34 Message generated for change (Comment added) made by draghuram You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1633941&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: for line in sys.stdin: doesn't notice EOF the first time Initial Comment: [forwarded from http://bugs.debian.org/315888] for line in sys.stdin: doesn't notice EOF the first time when reading from tty. The test program: import sys for line in sys.stdin: print line, print "eof" A sample session: [EMAIL PROTECTED] python foo.py foo <--- I pressed Enter and then Ctrl-D foo <--- then this appeared, but not more eof <--- this only came when I pressed Ctrl-D a second time [EMAIL PROTECTED] Seems to me that there is some buffering issue where Python needs to read end-of-file twice to notice it on all levels. Once should be enough. -- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-04-25 14:04 Message: Logged In: YES user_id=984087 Originator: NO BTW, I opened bug 1643712 for doc change. -- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-01-24 12:20 Message: Logged In: YES user_id=984087 Originator: NO I tested two kinds of inputs with iter and noiter verisons. I posted "noter" code and OP's code is the iter version. 1) For input without newline at all (line1) behaves same with both versions. 2) The noiter version prints "eof" with "line1\n" while the iter version requires an additional CTRL-D. This is because iter version uses read ahead which is implemented using fread() . A simple C program using fread() behaves exactly same way. I tested on Linux but am sure windows behaviour (as posted by gagenellina) will have same reasons. Since the issue is with platform's stdio library, I don't think python should fix anything here. However, it may be worthwhile to mention something about this in documentation. I will open a bug for this purpose. -- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-01-22 12:45 Message: Logged In: YES user_id=984087 Originator: NO Ok. This may sound stupid but I couldn't find a way to attach a file to this bug report. So I am copying the code here: import sys line = sys.stdin.readline() while (line): print line, line = sys.stdin.readline() print "eof" * -- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-01-22 12:37 Message: Logged In: YES user_id=984087 Originator: NO Sorry for my duplicate comment. It was a mistake. On closer examination, the OP's description does seem to indicate some issue. Please look at (attached) stdin_noiter.py which uses readline() directly and it does not have the problem described here. It properly detects EOF on first CTRL-D. This points to some problem with the iterator function fileobject.c:file_iternext(). I think that the first CTRL-D might be getting lost somewhere in the read ahead code (which only comes into picture with iterator). -- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-01-22 11:34 Message: Logged In: YES user_id=984087 Originator: NO I am not entirely sure that this is a bug. $ cat testfile line1 line2 $ python foo.py < testfile This command behaves as expected. Only when the input is from tty, the above described behaviour happens. That could be because of the terminal settings where characters may be buffered until a newline is entered. -- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-01-22 11:34 Message: Logged In: YES user_id=984087 Originator: NO I am not entirely sure that this is a bug. $ cat testfile line1 line2 $ python foo.py < testfile This command behaves as expected. Only when the input is from tty, the above described behaviour happens. That could be because of the terminal settings where characters may be buffered until a newline is entered. -- Comment By: Gabriel Genellina (gagenellina) Date: 2007-01-13 23:20 Message: Logged In: YES user_id=479790 Originator: NO Same thing occurs on Windows. Even worse, if the line does not end with CR, Ctrl-Z (EOF in Windows, equivalent to Ct
[ python-Bugs-1707607 ] raw text can't end with backslash
Bugs item #1707607, was opened at 2007-04-25 18:04 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1707607&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: lomm (korka) Assigned to: Nobody/Anonymous (nobody) Summary: raw text can't end with backslash Initial Comment: somehow the interpreter thinks it's an escape for the last quote print r'abc\' File "", line 1 print 'abc\' ^ SyntaxError: EOL while scanning single-quoted string -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1707607&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1707607 ] raw text can't end with backslash
Bugs item #1707607, was opened at 2007-04-25 18:04 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1707607&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 >Status: Closed >Resolution: Wont Fix Priority: 5 Private: No Submitted By: lomm (korka) Assigned to: Nobody/Anonymous (nobody) Summary: raw text can't end with backslash Initial Comment: somehow the interpreter thinks it's an escape for the last quote print r'abc\' File "", line 1 print 'abc\' ^ SyntaxError: EOL while scanning single-quoted string -- >Comment By: Georg Brandl (gbrandl) Date: 2007-04-25 19:36 Message: Logged In: YES user_id=849994 Originator: NO This is a tokenizer restriction and not considered a bug. Closing as "won't fix". -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1707607&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1707693 ] Please add .bz2 in encodings_map (in the module mimetypes)
Feature Requests item #1707693, was opened at 2007-04-25 22:46
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1707693&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: elghinn (elghinn)
Assigned to: Nobody/Anonymous (nobody)
Summary: Please add .bz2 in encodings_map (in the module mimetypes)
Initial Comment:
In the module mimetypes, can you add .bz2 in
encodings_map = {
'.gz': 'gzip',
'.Z': 'compress',
}
please ?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1707693&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1707768 ] os.path.normpath changes path (chops of trailing slash)
Bugs item #1707768, was opened at 2007-04-26 01:44
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1707768&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Robert Siemer (siemer)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.path.normpath changes path (chops of trailing slash)
Initial Comment:
Hello everybody!
>>> os.path.normpath('/etc/passwd')
'/etc/passwd'
I don't know any environment at all where
a) '/etc/passwd/'
b) '/etc/passwd'
are treated the same. It clearly does not apply for the path part of http urls
(this is left as an exercise for the reader).
But it also does not apply for (e.g.) Linux either:
an open() on path a) return ENOTDIR while it succeeds with b).
(assuming /etc/passwd is a file)
This is definitively not a documentation bug, as "normpath" should normalize a
path and not fuck it up.
Robert
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1707768&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1707768 ] os.path.normpath changes path (chops of trailing slash)
Bugs item #1707768, was opened at 2007-04-26 01:44
Message generated for change (Comment added) made by siemer
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1707768&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Robert Siemer (siemer)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.path.normpath changes path (chops of trailing slash)
Initial Comment:
Hello everybody!
>>> os.path.normpath('/etc/passwd')
'/etc/passwd'
I don't know any environment at all where
a) '/etc/passwd/'
b) '/etc/passwd'
are treated the same. It clearly does not apply for the path part of http urls
(this is left as an exercise for the reader).
But it also does not apply for (e.g.) Linux either:
an open() on path a) return ENOTDIR while it succeeds with b).
(assuming /etc/passwd is a file)
This is definitively not a documentation bug, as "normpath" should normalize a
path and not fuck it up.
Robert
--
>Comment By: Robert Siemer (siemer)
Date: 2007-04-26 01:47
Message:
Logged In: YES
user_id=150699
Originator: YES
A bugreport bug:
The example should read os.path.normpath('/etc/passwd/')...
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1707768&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1672853 ] Error reading files larger than 4GB
Bugs item #1672853, was opened at 2007-03-03 03:01 Message generated for change (Comment added) made by joearmbruster You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1672853&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Case Van Horsen (casevh) Assigned to: Nobody/Anonymous (nobody) Summary: Error reading files larger than 4GB Initial Comment: When reading test files larger than 4GB, sometimes two lines are merged into a single line. The problem is reproducible on Windows 2K SP4 with both Python 2.4 and 2.5. It does not appear to occur on Linux. I have attached a test case that creates the problem. -- Comment By: Joseph Armbruster (joearmbruster) Date: 2007-04-25 21:40 Message: Logged In: YES user_id=1643128 Originator: NO URL: http://svn.python.org/projects/python/trunk Revision: 54922 Note: Reproduced Error using test application on the following system OS Name:Microsoft Windows XP Professional OS Version: 5.1.2600 Service Pack 2 Build 2600 Try modifying line 13: fh = open(fname, 'r') to: fh = open(fname, 'rb') and notice the behavior. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1672853&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1672853 ] Error reading files larger than 4GB
Bugs item #1672853, was opened at 2007-03-03 03:01 Message generated for change (Comment added) made by joearmbruster You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1672853&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Case Van Horsen (casevh) Assigned to: Nobody/Anonymous (nobody) Summary: Error reading files larger than 4GB Initial Comment: When reading test files larger than 4GB, sometimes two lines are merged into a single line. The problem is reproducible on Windows 2K SP4 with both Python 2.4 and 2.5. It does not appear to occur on Linux. I have attached a test case that creates the problem. -- Comment By: Joseph Armbruster (joearmbruster) Date: 2007-04-25 22:11 Message: Logged In: YES user_id=1643128 Originator: NO josepharmbruster on #python or #python-dev in freenode -- Comment By: Joseph Armbruster (joearmbruster) Date: 2007-04-25 21:40 Message: Logged In: YES user_id=1643128 Originator: NO URL: http://svn.python.org/projects/python/trunk Revision: 54922 Note: Reproduced Error using test application on the following system OS Name:Microsoft Windows XP Professional OS Version: 5.1.2600 Service Pack 2 Build 2600 Try modifying line 13: fh = open(fname, 'r') to: fh = open(fname, 'rb') and notice the behavior. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1672853&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1706256 ] Give Partial the ability to skip positionals
Feature Requests item #1706256, was opened at 2007-04-23 20:18
Message generated for change (Comment added) made by belopolsky
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1706256&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Calvin Spealman (ironfroggy)
Assigned to: Nobody/Anonymous (nobody)
Summary: Give Partial the ability to skip positionals
Initial Comment:
There are some situations where you want to skip positional arguments in a use
of a partial function. In other words, you want to create a partial that
applies positional arguments out of order or without applying values to one or
more lower positional arguments. In some cases keyword arguments can be used
instead, but this has two obvious drawbacks. Firstly, it causes the caller to
rely on the name of a positional in a callee, which breaks encapsulation.
Secondly, on the case of the function being applied to being a builtin, it
fails completely, as they will not take positional arguments by name at all. I
propose a class attribute to the partial type, 'skip', which will be a
singleton to pass to a partial object signifying this skipping of positionals.
The following example demonstrates.
from functools import partial
def add(a, b):
return a + b
append_abc = partial(add, partial.skip, "abc")
assert append_abc("xyz") == "xyzabc"
Obviously this example would break if used as partial(add, b="abc") and the
maintainer of add changed the positional names to 'first' and 'second' or 'pre'
and 'post', which is perfectly reasonable. We do not need to expect the names
of our positional arguments are depended upon. It would also break when someone
gets smart and replaces the add function with operator.add, of course.
--
Comment By: Alexander Belopolsky (belopolsky)
Date: 2007-04-25 22:31
Message:
Logged In: YES
user_id=835142
Originator: NO
Names I've seen used for this purpose elsewhere: slot, arg, missing.
--
Comment By: Martin v. Löwis (loewis)
Date: 2007-04-24 01:41
Message:
Logged In: YES
user_id=21627
Originator: NO
I would not call it partial.skip, but partial.unbound (or find yet a
better name that indicates that the argument is not skipped, but instead
will be an argument of the resulting partial function).
--
Comment By: Calvin Spealman (ironfroggy)
Date: 2007-04-23 23:45
Message:
Logged In: YES
user_id=112166
Originator: YES
File Added: partial_skip.patch
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1706256&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1706256 ] Give Partial the ability to skip positionals
Feature Requests item #1706256, was opened at 2007-04-23 20:18
Message generated for change (Comment added) made by ironfroggy
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1706256&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Calvin Spealman (ironfroggy)
Assigned to: Nobody/Anonymous (nobody)
Summary: Give Partial the ability to skip positionals
Initial Comment:
There are some situations where you want to skip positional arguments in a use
of a partial function. In other words, you want to create a partial that
applies positional arguments out of order or without applying values to one or
more lower positional arguments. In some cases keyword arguments can be used
instead, but this has two obvious drawbacks. Firstly, it causes the caller to
rely on the name of a positional in a callee, which breaks encapsulation.
Secondly, on the case of the function being applied to being a builtin, it
fails completely, as they will not take positional arguments by name at all. I
propose a class attribute to the partial type, 'skip', which will be a
singleton to pass to a partial object signifying this skipping of positionals.
The following example demonstrates.
from functools import partial
def add(a, b):
return a + b
append_abc = partial(add, partial.skip, "abc")
assert append_abc("xyz") == "xyzabc"
Obviously this example would break if used as partial(add, b="abc") and the
maintainer of add changed the positional names to 'first' and 'second' or 'pre'
and 'post', which is perfectly reasonable. We do not need to expect the names
of our positional arguments are depended upon. It would also break when someone
gets smart and replaces the add function with operator.add, of course.
--
>Comment By: Calvin Spealman (ironfroggy)
Date: 2007-04-25 22:58
Message:
Logged In: YES
user_id=112166
Originator: YES
If anyone has a serious argument against the partial.skip name, I would
take partial.unbound as my second choice, but I definitely prefer
partial.skip to it. Third would be partial.latebound. I still can't figure
out how my code broke subclassing of partial, so if anyone can take a look,
I'd appreciate it hugely.
--
Comment By: Alexander Belopolsky (belopolsky)
Date: 2007-04-25 22:31
Message:
Logged In: YES
user_id=835142
Originator: NO
Names I've seen used for this purpose elsewhere: slot, arg, missing.
--
Comment By: Martin v. Löwis (loewis)
Date: 2007-04-24 01:41
Message:
Logged In: YES
user_id=21627
Originator: NO
I would not call it partial.skip, but partial.unbound (or find yet a
better name that indicates that the argument is not skipped, but instead
will be an argument of the resulting partial function).
--
Comment By: Calvin Spealman (ironfroggy)
Date: 2007-04-23 23:45
Message:
Logged In: YES
user_id=112166
Originator: YES
File Added: partial_skip.patch
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1706256&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1706256 ] Give Partial the ability to skip positionals
Feature Requests item #1706256, was opened at 2007-04-23 20:18
Message generated for change (Comment added) made by belopolsky
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1706256&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Calvin Spealman (ironfroggy)
Assigned to: Nobody/Anonymous (nobody)
Summary: Give Partial the ability to skip positionals
Initial Comment:
There are some situations where you want to skip positional arguments in a use
of a partial function. In other words, you want to create a partial that
applies positional arguments out of order or without applying values to one or
more lower positional arguments. In some cases keyword arguments can be used
instead, but this has two obvious drawbacks. Firstly, it causes the caller to
rely on the name of a positional in a callee, which breaks encapsulation.
Secondly, on the case of the function being applied to being a builtin, it
fails completely, as they will not take positional arguments by name at all. I
propose a class attribute to the partial type, 'skip', which will be a
singleton to pass to a partial object signifying this skipping of positionals.
The following example demonstrates.
from functools import partial
def add(a, b):
return a + b
append_abc = partial(add, partial.skip, "abc")
assert append_abc("xyz") == "xyzabc"
Obviously this example would break if used as partial(add, b="abc") and the
maintainer of add changed the positional names to 'first' and 'second' or 'pre'
and 'post', which is perfectly reasonable. We do not need to expect the names
of our positional arguments are depended upon. It would also break when someone
gets smart and replaces the add function with operator.add, of course.
--
Comment By: Alexander Belopolsky (belopolsky)
Date: 2007-04-25 23:21
Message:
Logged In: YES
user_id=835142
Originator: NO
The current patch does not compile:
Modules/_functoolsmodule.c: In function 'init_functools':
Modules/_functoolsmodule.c:306: error: too many arguments to function
'PyObject_CallObject'
Once I removed the extra NULL argument, it seems to work fine. What
exactly is broken? Can you add unit tests for the new functionality?
--
Comment By: Calvin Spealman (ironfroggy)
Date: 2007-04-25 22:58
Message:
Logged In: YES
user_id=112166
Originator: YES
If anyone has a serious argument against the partial.skip name, I would
take partial.unbound as my second choice, but I definitely prefer
partial.skip to it. Third would be partial.latebound. I still can't figure
out how my code broke subclassing of partial, so if anyone can take a look,
I'd appreciate it hugely.
--
Comment By: Alexander Belopolsky (belopolsky)
Date: 2007-04-25 22:31
Message:
Logged In: YES
user_id=835142
Originator: NO
Names I've seen used for this purpose elsewhere: slot, arg, missing.
--
Comment By: Martin v. Löwis (loewis)
Date: 2007-04-24 01:41
Message:
Logged In: YES
user_id=21627
Originator: NO
I would not call it partial.skip, but partial.unbound (or find yet a
better name that indicates that the argument is not skipped, but instead
will be an argument of the resulting partial function).
--
Comment By: Calvin Spealman (ironfroggy)
Date: 2007-04-23 23:45
Message:
Logged In: YES
user_id=112166
Originator: YES
File Added: partial_skip.patch
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1706256&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1706256 ] Give Partial the ability to skip positionals
Feature Requests item #1706256, was opened at 2007-04-23 20:18
Message generated for change (Comment added) made by belopolsky
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1706256&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Calvin Spealman (ironfroggy)
Assigned to: Nobody/Anonymous (nobody)
Summary: Give Partial the ability to skip positionals
Initial Comment:
There are some situations where you want to skip positional arguments in a use
of a partial function. In other words, you want to create a partial that
applies positional arguments out of order or without applying values to one or
more lower positional arguments. In some cases keyword arguments can be used
instead, but this has two obvious drawbacks. Firstly, it causes the caller to
rely on the name of a positional in a callee, which breaks encapsulation.
Secondly, on the case of the function being applied to being a builtin, it
fails completely, as they will not take positional arguments by name at all. I
propose a class attribute to the partial type, 'skip', which will be a
singleton to pass to a partial object signifying this skipping of positionals.
The following example demonstrates.
from functools import partial
def add(a, b):
return a + b
append_abc = partial(add, partial.skip, "abc")
assert append_abc("xyz") == "xyzabc"
Obviously this example would break if used as partial(add, b="abc") and the
maintainer of add changed the positional names to 'first' and 'second' or 'pre'
and 'post', which is perfectly reasonable. We do not need to expect the names
of our positional arguments are depended upon. It would also break when someone
gets smart and replaces the add function with operator.add, of course.
--
Comment By: Alexander Belopolsky (belopolsky)
Date: 2007-04-25 23:34
Message:
Logged In: YES
user_id=835142
Originator: NO
OK, I've got it. Your patch breaks test_functools. This is because you
have blown up partial_type.tp_dict .
--
Comment By: Alexander Belopolsky (belopolsky)
Date: 2007-04-25 23:21
Message:
Logged In: YES
user_id=835142
Originator: NO
The current patch does not compile:
Modules/_functoolsmodule.c: In function 'init_functools':
Modules/_functoolsmodule.c:306: error: too many arguments to function
'PyObject_CallObject'
Once I removed the extra NULL argument, it seems to work fine. What
exactly is broken? Can you add unit tests for the new functionality?
--
Comment By: Calvin Spealman (ironfroggy)
Date: 2007-04-25 22:58
Message:
Logged In: YES
user_id=112166
Originator: YES
If anyone has a serious argument against the partial.skip name, I would
take partial.unbound as my second choice, but I definitely prefer
partial.skip to it. Third would be partial.latebound. I still can't figure
out how my code broke subclassing of partial, so if anyone can take a look,
I'd appreciate it hugely.
--
Comment By: Alexander Belopolsky (belopolsky)
Date: 2007-04-25 22:31
Message:
Logged In: YES
user_id=835142
Originator: NO
Names I've seen used for this purpose elsewhere: slot, arg, missing.
--
Comment By: Martin v. Löwis (loewis)
Date: 2007-04-24 01:41
Message:
Logged In: YES
user_id=21627
Originator: NO
I would not call it partial.skip, but partial.unbound (or find yet a
better name that indicates that the argument is not skipped, but instead
will be an argument of the resulting partial function).
--
Comment By: Calvin Spealman (ironfroggy)
Date: 2007-04-23 23:45
Message:
Logged In: YES
user_id=112166
Originator: YES
File Added: partial_skip.patch
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1706256&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1706256 ] Give Partial the ability to skip positionals
Feature Requests item #1706256, was opened at 2007-04-23 20:18
Message generated for change (Comment added) made by ironfroggy
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1706256&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Calvin Spealman (ironfroggy)
Assigned to: Nobody/Anonymous (nobody)
Summary: Give Partial the ability to skip positionals
Initial Comment:
There are some situations where you want to skip positional arguments in a use
of a partial function. In other words, you want to create a partial that
applies positional arguments out of order or without applying values to one or
more lower positional arguments. In some cases keyword arguments can be used
instead, but this has two obvious drawbacks. Firstly, it causes the caller to
rely on the name of a positional in a callee, which breaks encapsulation.
Secondly, on the case of the function being applied to being a builtin, it
fails completely, as they will not take positional arguments by name at all. I
propose a class attribute to the partial type, 'skip', which will be a
singleton to pass to a partial object signifying this skipping of positionals.
The following example demonstrates.
from functools import partial
def add(a, b):
return a + b
append_abc = partial(add, partial.skip, "abc")
assert append_abc("xyz") == "xyzabc"
Obviously this example would break if used as partial(add, b="abc") and the
maintainer of add changed the positional names to 'first' and 'second' or 'pre'
and 'post', which is perfectly reasonable. We do not need to expect the names
of our positional arguments are depended upon. It would also break when someone
gets smart and replaces the add function with operator.add, of course.
--
>Comment By: Calvin Spealman (ironfroggy)
Date: 2007-04-26 00:10
Message:
Logged In: YES
user_id=112166
Originator: YES
Hmm, I didn't get such an error here on VC with the extra argument. I'll
change that here, too.
I figured the breaking of the subclassing of partial was related to what I
do with tp_dict, but I don't understand how. How did I blow it up? And,
yes, I will write tests for the new functionality, of course.
--
Comment By: Alexander Belopolsky (belopolsky)
Date: 2007-04-25 23:34
Message:
Logged In: YES
user_id=835142
Originator: NO
OK, I've got it. Your patch breaks test_functools. This is because you
have blown up partial_type.tp_dict .
--
Comment By: Alexander Belopolsky (belopolsky)
Date: 2007-04-25 23:21
Message:
Logged In: YES
user_id=835142
Originator: NO
The current patch does not compile:
Modules/_functoolsmodule.c: In function 'init_functools':
Modules/_functoolsmodule.c:306: error: too many arguments to function
'PyObject_CallObject'
Once I removed the extra NULL argument, it seems to work fine. What
exactly is broken? Can you add unit tests for the new functionality?
--
Comment By: Calvin Spealman (ironfroggy)
Date: 2007-04-25 22:58
Message:
Logged In: YES
user_id=112166
Originator: YES
If anyone has a serious argument against the partial.skip name, I would
take partial.unbound as my second choice, but I definitely prefer
partial.skip to it. Third would be partial.latebound. I still can't figure
out how my code broke subclassing of partial, so if anyone can take a look,
I'd appreciate it hugely.
--
Comment By: Alexander Belopolsky (belopolsky)
Date: 2007-04-25 22:31
Message:
Logged In: YES
user_id=835142
Originator: NO
Names I've seen used for this purpose elsewhere: slot, arg, missing.
--
Comment By: Martin v. Löwis (loewis)
Date: 2007-04-24 01:41
Message:
Logged In: YES
user_id=21627
Originator: NO
I would not call it partial.skip, but partial.unbound (or find yet a
better name that indicates that the argument is not skipped, but instead
will be an argument of the resulting partial function).
--
Comment By: Calvin Spealman (ironfroggy)
Date: 2007-04-23 23:45
Message:
Logged In: YES
user_id=112166
Originator: YES
File Added: partial_skip.patch
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1706256&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
ht
[ python-Feature Requests-1706256 ] Give Partial the ability to skip positionals
Feature Requests item #1706256, was opened at 2007-04-23 20:18
Message generated for change (Comment added) made by belopolsky
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1706256&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Calvin Spealman (ironfroggy)
Assigned to: Nobody/Anonymous (nobody)
Summary: Give Partial the ability to skip positionals
Initial Comment:
There are some situations where you want to skip positional arguments in a use
of a partial function. In other words, you want to create a partial that
applies positional arguments out of order or without applying values to one or
more lower positional arguments. In some cases keyword arguments can be used
instead, but this has two obvious drawbacks. Firstly, it causes the caller to
rely on the name of a positional in a callee, which breaks encapsulation.
Secondly, on the case of the function being applied to being a builtin, it
fails completely, as they will not take positional arguments by name at all. I
propose a class attribute to the partial type, 'skip', which will be a
singleton to pass to a partial object signifying this skipping of positionals.
The following example demonstrates.
from functools import partial
def add(a, b):
return a + b
append_abc = partial(add, partial.skip, "abc")
assert append_abc("xyz") == "xyzabc"
Obviously this example would break if used as partial(add, b="abc") and the
maintainer of add changed the positional names to 'first' and 'second' or 'pre'
and 'post', which is perfectly reasonable. We do not need to expect the names
of our positional arguments are depended upon. It would also break when someone
gets smart and replaces the add function with operator.add, of course.
--
Comment By: Alexander Belopolsky (belopolsky)
Date: 2007-04-26 00:14
Message:
Logged In: YES
user_id=835142
Originator: NO
If you remove partial_type.tp_dict = PyDict_New(); at line 309, the patch
will pass test_functools.
A few comments:
Design:
1. partial.skip should be an instance of a singleton class (look at
NoneType implementation in object.c)
2. repr(partial.skip) should be 'functools.partial.skip' (easy to
implement once #1 is done)
Implementation:
1. In the loop over pto->args you know that i < npargs, so you can use
PyTuple_GET_ITEM and there is no need to check for arg==NULL
2. You should check PyTuple_GetItem(args, pull_index) for null and return
with error if too few arguments is supplied. Better yet, find number of
supplied args outside the loop and raise your own error if pool_index grows
to that number.
3. It looks like you are leaking references. I don't see where you decref
ptoargscopy and arg after concatenation.
--
Comment By: Calvin Spealman (ironfroggy)
Date: 2007-04-26 00:10
Message:
Logged In: YES
user_id=112166
Originator: YES
Hmm, I didn't get such an error here on VC with the extra argument. I'll
change that here, too.
I figured the breaking of the subclassing of partial was related to what I
do with tp_dict, but I don't understand how. How did I blow it up? And,
yes, I will write tests for the new functionality, of course.
--
Comment By: Alexander Belopolsky (belopolsky)
Date: 2007-04-25 23:34
Message:
Logged In: YES
user_id=835142
Originator: NO
OK, I've got it. Your patch breaks test_functools. This is because you
have blown up partial_type.tp_dict .
--
Comment By: Alexander Belopolsky (belopolsky)
Date: 2007-04-25 23:21
Message:
Logged In: YES
user_id=835142
Originator: NO
The current patch does not compile:
Modules/_functoolsmodule.c: In function 'init_functools':
Modules/_functoolsmodule.c:306: error: too many arguments to function
'PyObject_CallObject'
Once I removed the extra NULL argument, it seems to work fine. What
exactly is broken? Can you add unit tests for the new functionality?
--
Comment By: Calvin Spealman (ironfroggy)
Date: 2007-04-25 22:58
Message:
Logged In: YES
user_id=112166
Originator: YES
If anyone has a serious argument against the partial.skip name, I would
take partial.unbound as my second choice, but I definitely prefer
partial.skip to it. Third would be partial.latebound. I still can't figure
out how my code broke subclassing of partial, so if anyone can take a look,
I'd appreciate it hugely.
--
Comment By: Alexander Belopolsky (belopolsky)
Date: 2007-04-25
[ python-Feature Requests-1706256 ] Give Partial the ability to skip positionals
Feature Requests item #1706256, was opened at 2007-04-23 19:18
Message generated for change (Comment added) made by rhettinger
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1706256&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Calvin Spealman (ironfroggy)
Assigned to: Nobody/Anonymous (nobody)
Summary: Give Partial the ability to skip positionals
Initial Comment:
There are some situations where you want to skip positional arguments in a use
of a partial function. In other words, you want to create a partial that
applies positional arguments out of order or without applying values to one or
more lower positional arguments. In some cases keyword arguments can be used
instead, but this has two obvious drawbacks. Firstly, it causes the caller to
rely on the name of a positional in a callee, which breaks encapsulation.
Secondly, on the case of the function being applied to being a builtin, it
fails completely, as they will not take positional arguments by name at all. I
propose a class attribute to the partial type, 'skip', which will be a
singleton to pass to a partial object signifying this skipping of positionals.
The following example demonstrates.
from functools import partial
def add(a, b):
return a + b
append_abc = partial(add, partial.skip, "abc")
assert append_abc("xyz") == "xyzabc"
Obviously this example would break if used as partial(add, b="abc") and the
maintainer of add changed the positional names to 'first' and 'second' or 'pre'
and 'post', which is perfectly reasonable. We do not need to expect the names
of our positional arguments are depended upon. It would also break when someone
gets smart and replaces the add function with operator.add, of course.
--
>Comment By: Raymond Hettinger (rhettinger)
Date: 2007-04-26 01:15
Message:
Logged In: YES
user_id=80475
Originator: NO
-1 on the concept for this patch. We're working too hard to avoid simple
uses of lambda or def. The additonal complexity and impact on readability
isn't work it.
--
Comment By: Alexander Belopolsky (belopolsky)
Date: 2007-04-25 23:14
Message:
Logged In: YES
user_id=835142
Originator: NO
If you remove partial_type.tp_dict = PyDict_New(); at line 309, the patch
will pass test_functools.
A few comments:
Design:
1. partial.skip should be an instance of a singleton class (look at
NoneType implementation in object.c)
2. repr(partial.skip) should be 'functools.partial.skip' (easy to
implement once #1 is done)
Implementation:
1. In the loop over pto->args you know that i < npargs, so you can use
PyTuple_GET_ITEM and there is no need to check for arg==NULL
2. You should check PyTuple_GetItem(args, pull_index) for null and return
with error if too few arguments is supplied. Better yet, find number of
supplied args outside the loop and raise your own error if pool_index grows
to that number.
3. It looks like you are leaking references. I don't see where you decref
ptoargscopy and arg after concatenation.
--
Comment By: Calvin Spealman (ironfroggy)
Date: 2007-04-25 23:10
Message:
Logged In: YES
user_id=112166
Originator: YES
Hmm, I didn't get such an error here on VC with the extra argument. I'll
change that here, too.
I figured the breaking of the subclassing of partial was related to what I
do with tp_dict, but I don't understand how. How did I blow it up? And,
yes, I will write tests for the new functionality, of course.
--
Comment By: Alexander Belopolsky (belopolsky)
Date: 2007-04-25 22:34
Message:
Logged In: YES
user_id=835142
Originator: NO
OK, I've got it. Your patch breaks test_functools. This is because you
have blown up partial_type.tp_dict .
--
Comment By: Alexander Belopolsky (belopolsky)
Date: 2007-04-25 22:21
Message:
Logged In: YES
user_id=835142
Originator: NO
The current patch does not compile:
Modules/_functoolsmodule.c: In function 'init_functools':
Modules/_functoolsmodule.c:306: error: too many arguments to function
'PyObject_CallObject'
Once I removed the extra NULL argument, it seems to work fine. What
exactly is broken? Can you add unit tests for the new functionality?
--
Comment By: Calvin Spealman (ironfroggy)
Date: 2007-04-25 21:58
Message:
Logged In: YES
user_id=112166
Originator: YES
If anyone has a serious argument against the partial.skip name, I would
take partial.unbou
[ python-Feature Requests-1705520 ] pyunit should allow __unittest in locals to trim stackframes
Feature Requests item #1705520, was opened at 2007-04-22 22:56
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1705520&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.6
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Robert Collins (rbcollins)
>Assigned to: Steve Purcell (purcell)
Summary: pyunit should allow __unittest in locals to trim stackframes
Initial Comment:
pyunit looks for __unittest = 1 in the globals of functions in an assertion
stacktrace. This is used to trim the trace so that unittest implementation
methods do not show up.
It would be great if it looked in the locals of the frame as well, as this
would allow subclasses of TestCase that add new assertFOO methods to have them
filtered in the same manner.
e.g. (bad example :))
def assertComplexState(self, inputs):
__unittest = 1
self.assertEqual('42', inputs[0], 'the input %s is not the right answer' %
inputs)
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1705520&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1706256 ] Give Partial the ability to skip positionals
Feature Requests item #1706256, was opened at 2007-04-23 20:18
Message generated for change (Comment added) made by belopolsky
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1706256&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Calvin Spealman (ironfroggy)
Assigned to: Nobody/Anonymous (nobody)
Summary: Give Partial the ability to skip positionals
Initial Comment:
There are some situations where you want to skip positional arguments in a use
of a partial function. In other words, you want to create a partial that
applies positional arguments out of order or without applying values to one or
more lower positional arguments. In some cases keyword arguments can be used
instead, but this has two obvious drawbacks. Firstly, it causes the caller to
rely on the name of a positional in a callee, which breaks encapsulation.
Secondly, on the case of the function being applied to being a builtin, it
fails completely, as they will not take positional arguments by name at all. I
propose a class attribute to the partial type, 'skip', which will be a
singleton to pass to a partial object signifying this skipping of positionals.
The following example demonstrates.
from functools import partial
def add(a, b):
return a + b
append_abc = partial(add, partial.skip, "abc")
assert append_abc("xyz") == "xyzabc"
Obviously this example would break if used as partial(add, b="abc") and the
maintainer of add changed the positional names to 'first' and 'second' or 'pre'
and 'post', which is perfectly reasonable. We do not need to expect the names
of our positional arguments are depended upon. It would also break when someone
gets smart and replaces the add function with operator.add, of course.
--
Comment By: Alexander Belopolsky (belopolsky)
Date: 2007-04-26 02:32
Message:
Logged In: YES
user_id=835142
Originator: NO
I am actually -1 on the concept as well. If you go to the trouble of
having a skip singleton in the language, then partial application syntax
should just be call syntax as in add(skip, 2). However this will not be
python anymore. Other languages that have partial application support use
special syntax such as add(,2) or add(:,2). Since adding syntax is out of
the question, it is hard to argue that partial(add, partial.skip, 2) is so
much better than lambda x: add(x,2).
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2007-04-26 02:15
Message:
Logged In: YES
user_id=80475
Originator: NO
-1 on the concept for this patch. We're working too hard to avoid simple
uses of lambda or def. The additonal complexity and impact on readability
isn't work it.
--
Comment By: Alexander Belopolsky (belopolsky)
Date: 2007-04-26 00:14
Message:
Logged In: YES
user_id=835142
Originator: NO
If you remove partial_type.tp_dict = PyDict_New(); at line 309, the patch
will pass test_functools.
A few comments:
Design:
1. partial.skip should be an instance of a singleton class (look at
NoneType implementation in object.c)
2. repr(partial.skip) should be 'functools.partial.skip' (easy to
implement once #1 is done)
Implementation:
1. In the loop over pto->args you know that i < npargs, so you can use
PyTuple_GET_ITEM and there is no need to check for arg==NULL
2. You should check PyTuple_GetItem(args, pull_index) for null and return
with error if too few arguments is supplied. Better yet, find number of
supplied args outside the loop and raise your own error if pool_index grows
to that number.
3. It looks like you are leaking references. I don't see where you decref
ptoargscopy and arg after concatenation.
--
Comment By: Calvin Spealman (ironfroggy)
Date: 2007-04-26 00:10
Message:
Logged In: YES
user_id=112166
Originator: YES
Hmm, I didn't get such an error here on VC with the extra argument. I'll
change that here, too.
I figured the breaking of the subclassing of partial was related to what I
do with tp_dict, but I don't understand how. How did I blow it up? And,
yes, I will write tests for the new functionality, of course.
--
Comment By: Alexander Belopolsky (belopolsky)
Date: 2007-04-25 23:34
Message:
Logged In: YES
user_id=835142
Originator: NO
OK, I've got it. Your patch breaks test_functools. This is because you
have blown up partial_type.tp_dict .
--
Comment By: Alexander Belopolsky (belopolsky)
Date: 2007-04-25
