Re: [Python-Dev] an idea for improving struct.unpack api
On Fri, 7 Jan 2005 19:40:18 -0800 (PST), Ilya Sandler <[EMAIL PROTECTED]> wrote:
> Eg. I just looked at xdrlib.py code and it seems that almost every
> invocation of struct._unpack would shrink from 3 lines to 1 line of code
>
> (i = self.__pos
> self.__pos = j = i+4
> data = self.__buf[i:j]
> return struct.unpack('>l', data)[0]
>
> would become:
> return struct.unpack('>l', self.__buf, self.__pos)[0]
> )
FWIW, I could read and understand your original code without any
problems, whereas in the second version I would completely miss the
fact that self.__pos is updated, precisely because mutating arguments
are very rare in Python functions.
OTOH, Nick's idea of returning a tuple with the new offset might make
your example shorter without sacrificing readability:
result, newpos = struct.unpack('>l', self.__buf, self.__pos)
self.__pos = newpos # retained "newpos" for readability...
return result
A third possibility - rather than "magically" adding an additional
return value because you supply a position, you could have a "where am
I?" format symbol (say & by analogy with the C "address of" operator).
Then you'd say
result, newpos = struct.unpack('>l&', self.__buf, self.__pos)
Please be aware, I don't have a need myself for this feature - my
interest is as a potential reader of others' code...
Paul.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.3.5 schedule, and something I'd like to get in
On Saturday 08 January 2005 00:05, Jack Jansen wrote: > > This patch implements the proposed direct framework linking: > > http://python.org/sf/1097739 > > Looks good, I'll incorporate it. And as I haven't heard of any > showstoppers for the -undefined dynamic_lookup (and Anthony seems to be > offline this week) I'll put that in too. Sorry, I've been busy on other projects for the last couple of weeks, and email's backed up to an alarming degree. Currently I'm thinking of a 2.3.5 sometime around the 20th or so. I'll have a better idea next week, once I've been back at work for a couple of days and I've seen what stuff's backed up awaiting my time. At the moment I'm thinking of a 2.4.1 in maybe early March. The only really outstanding bugfix is the marshal one, afaik. Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] an idea for improving struct.unpack api
First, let me say two things:
(a) A higher-level API can and should be constructed which acts like a
(binary) stream but has additional methods for reading and writing
values using struct format codes (or, preferably, somewhat
higher-level type names, as suggested). Instances of this API should
be constructable from a stream or from a "buffer" (e.g. a string).
(b) -1 on Ilya's idea of having a special object that acts as an
input-output integer; it is too unpythonic (no matter your objection).
[Paul Moore]
> OTOH, Nick's idea of returning a tuple with the new offset might make
> your example shorter without sacrificing readability:
>
> result, newpos = struct.unpack('>l', self.__buf, self.__pos)
> self.__pos = newpos # retained "newpos" for readability...
> return result
This is okay, except I don't want to overload this on unpack() --
let's pick a different function name like unpack_at().
> A third possibility - rather than "magically" adding an additional
> return value because you supply a position, you could have a "where am
> I?" format symbol (say & by analogy with the C "address of" operator).
> Then you'd say
>
> result, newpos = struct.unpack('>l&', self.__buf, self.__pos)
>
> Please be aware, I don't have a need myself for this feature - my
> interest is as a potential reader of others' code...
I think that adding more magical format characters is probably not
doing the readers of this code a service.
I do like the idea of not introducing an extra level of tuple to
accommodate the position return value but instead make it the last
item in the tuple when using unpack_at().
Then the definition would be:
def unpack_at(fmt, buf, pos):
size = calcsize(fmt)
end = pos + size
data = buf[pos:end]
if len(data) < size:
raise struct.error("not enough data for format")
# if data is too long that would be a bug in buf[pos:size] and
cause an error below
ret = unpack(fmt, data)
ret = ret + (end,)
return ret
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Re: csv module TODO list
I'd love to see a 'split' and a 'join' function in the csv module to just convert between string and list without having to bother about files. Something like csv.split(aStr [, dialect='excel'[, fmtparam]]) -> list object and csv.join(aList, e[, dialect='excel'[, fmtparam]]) -> str object Feasible? mb - Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Weekly Python Patch/Bug Summary
Patch / Bug Summary
___
Patches : 267 open ( +6) / 2727 closed ( +9) / 2994 total (+15)
Bugs: 798 open ( -3) / 4748 closed (+15) / 5546 total (+12)
RFE : 165 open ( +0) / 140 closed ( +1) / 305 total ( +1)
New / Reopened Patches
__
Remove witty comment in pydoc.py (2005-01-01)
CLOSED http://python.org/sf/1094007 opened by Reinhold Birkenfeld
Docs for file() vs open() (2005-01-01)
CLOSED http://python.org/sf/1094011 opened by Reinhold Birkenfeld
Improvements for shutil.copytree() (2005-01-01)
CLOSED http://python.org/sf/1094015 opened by Reinhold Birkenfeld
xml.dom.minidom.Node.replaceChild(obj, x, x) removes child x (2005-01-01)
http://python.org/sf/1094164 opened by Felix Rabe
os.py: base class _Environ on dict instead of UserDict (2005-01-02)
http://python.org/sf/1094387 opened by Matthias Klose
add Bunch type to collections module (2005-01-02)
http://python.org/sf/1094542 opened by Steven Bethard
self.button.pack() in tkinter.tex example (2005-01-03)
http://python.org/sf/1094815 opened by [N/A]
fixes urllib2 digest to allow arbitrary methods (2005-01-03)
http://python.org/sf/1095362 opened by John Reese
Argument passing from /usr/bin/idle2.3 to idle.py (2003-11-30)
http://python.org/sf/851459 reopened by jafo
fix for trivial flatten bug in astgen (2005-01-04)
http://python.org/sf/1095541 opened by DSM
exclude CVS conflict files in sdist command (2005-01-04)
http://python.org/sf/1095784 opened by Wummel
Fix for wm_iconbitmap to allow .ico files under Windows. (2005-01-05)
http://python.org/sf/1096231 opened by John Fouhy
Info Associated with Merge to AST (2005-01-07)
http://python.org/sf/1097671 opened by Kurt B. Kaiser
Direct framework linking for MACOSX_DEPLOYMENT_TARGET < 10.3 (2005-01-07)
http://python.org/sf/1097739 opened by Bob Ippolito
Encoding for Code Page 273 used by EBCDIC Germany Austria (2005-01-07)
http://python.org/sf/1097797 opened by Michael Bierenfeld
Patches Closed
__
locale.getdefaultlocale does not return tuple in some OS (2004-10-21)
http://python.org/sf/1051395 closed by rhettinger
imghdr -- identify JPEGs in EXIF format (2003-06-08)
http://python.org/sf/751031 closed by rhettinger
Remove witty comment in pydoc.py (2005-01-01)
http://python.org/sf/1094007 closed by rhettinger
Docs for file() vs open() (2005-01-01)
http://python.org/sf/1094011 closed by rhettinger
Improvements for shutil.copytree() (2005-01-01)
http://python.org/sf/1094015 closed by jlgijsbers
a new subprocess.call which raises an error on non-zero rc (2004-11-23)
http://python.org/sf/1071764 closed by astrand
Argument passing from /usr/bin/idle2.3 to idle.py (2003-11-30)
http://python.org/sf/851459 closed by jafo
@decorators, including classes (2004-08-12)
http://python.org/sf/1007991 closed by jackdied
Convert glob.glob to generator-based DFS (2004-04-27)
http://python.org/sf/943206 closed by jlgijsbers
Make cgi.py use email instead of rfc822 or mimetools (2004-12-06)
http://python.org/sf/1079734 closed by jlgijsbers
New / Reopened Bugs
___
marshal.dumps('hello',0) "Access violation" (2005-01-03)
CLOSED http://python.org/sf/1094960 opened by Mark Brophy
General FAW - incorrect "most stable version" (2005-01-03)
http://python.org/sf/1095328 opened by Tim Delaney
Python FAQ: list.sort() out of date (2005-01-03)
CLOSED http://python.org/sf/1095342 opened by Tim Delaney
Bug In Python (2005-01-04)
CLOSED http://python.org/sf/1095789 opened by JastheAce
"Macintosh" references in the docs need to be checked. (2005-01-04)
http://python.org/sf/1095802 opened by Jack Jansen
The doc for DictProxy is missing (2005-01-04)
http://python.org/sf/1095821 opened by Colin J. Williams
Apple-installed Python fails to build extensions (2005-01-04)
http://python.org/sf/1095822 opened by Jack Jansen
time.tzset() not built on Solaris (2005-01-05)
http://python.org/sf/1096244 opened by Gregory Bond
sys.__stdout__ doco isn't discouraging enough (2005-01-05)
http://python.org/sf/1096310 opened by Just van Rossum
_DummyThread() objects not freed from threading._active map (2004-12-22)
http://python.org/sf/1089632 reopened by saravanand
Example needed in os.stat() (2005-01-06)
CLOSED http://python.org/sf/1097229 opened by Facundo Batista
SimpleHTTPServer sends wrong Content-Length header (2005-01-06)
http://python.org/sf/1097597 opened by David Schachter
urllib2 doesn't handle urls without a scheme (2005-01-07)
http://python.org/sf/1097834 opened by Jack Jansen
getsource and getsourcelines in the inspect module (2005-01-07)
CLOSED http://python.org/sf/1098134 opened by Björn Lindqvist
mailb
[Python-Dev] os.removedirs() vs. shutil.rmtree()
Is there a reason the standard library needs both os.removedirs and shutil.rmtree? They seem awful similar to me (I can see they aren't really identical). Ditto for os.renames and shutil.move. Presuming they are all really needed, is there some reason they don't all belong in the same module? Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] os.removedirs() vs. shutil.rmtree()
On Sat, Jan 08, 2005 at 02:45:25PM -0600, Skip Montanaro wrote: > Is there a reason the standard library needs both os.removedirs and > shutil.rmtree? They seem awful similar to me (I can see they aren't really > identical). Ditto for os.renames and shutil.move. Presuming they are all > really needed, is there some reason they don't all belong in the same > module? os.removedirs() only removes directories, it will fail to remove a non-empty directory, for example. It also doesn't have the ignore_errors/onerror arguments [1]. os.renames() is different from shutil.move() in that it also creates intermediate directories (and deletes any left empty). So they're not identical, but I do agree they should be consolidated and moved into one module. I'd say shutil, both because the os module is already awfully crowded, and because these functions are "high-level operations on files and collections of files" rather than "a more portable way of using operating system dependent functionality [...]". Johannes [1] That may actually be a good thing, though. It was a pain to keep those working backwards-compatibly when shutil.rmtree was recently rewritten. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Possible bug in codecs readline? It breaks lines apart.
Hello
using current cvs Python on Linux, I observe this weird
behavior of the readline() method on file-like objects
returned from the codecs module:
[EMAIL PROTECTED] ypage]$ cat testfile1.txt
xxx yyy
offending line: ladfj askldfj klasdj fskla dfzaskdj fasklfj laskd
fjasklfaa%whereisthis!!!
next line.
[EMAIL PROTECTED] ypage]$ cat testfile2.txt
stillokay:xx
brokenbadbad
againokay.
[EMAIL PROTECTED] ypage]$ cat bug.py
import codecs
for name in ("testfile1.txt","testfile2.txt"):
f=codecs.open(name,encoding="iso-8859-1") # precise encoding doesn't matter
print "",name,""
for line in f:
print "LINE:"+repr(line)
[EMAIL PROTECTED] ypage]$ python25 bug.py
testfile1.txt
LINE:u'xxx yyy\r\n'
LINE:u'offendi'
LINE:u'ng line: ladfj askldfj klasdj fskla dfzaskdj fasklfj laskd fjasklfaa'
LINE:u'%whereisthis!!!\r\n'
LINE:u'next line.\r\n'
testfile2.txt
LINE:u'\n'
LINE:u'\n'
LINE:u'stillokay:xx\n'
LINE:u'broke'
LINE:u'nbadbad\n'
LINE:u'againokay.\n'
[EMAIL PROTECTED] ypage]$
See how it breaks certain lines in half?
It only happens when a certain encoding is used, so regular
file objects behave as expected. Also, readlines() works fine.
Python 2.3.4 and Python 2.4 do not have this problem.
Am I missing something or is this a bug? Thanks!
--Irmen
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Possible bug in codecs readline? It breaks lines apart.
On 2005-01-09, at 04.11, Irmen de Jong wrote: Hello using current cvs Python on Linux, I observe this weird behavior of the readline() method on file-like objects returned from the codecs module: [...] See how it breaks certain lines in half? It only happens when a certain encoding is used, so regular file objects behave as expected. Also, readlines() works fine. Python 2.3.4 and Python 2.4 do not have this problem. Am I missing something or is this a bug? Thanks! It looks like the readline method broke at revision 1.36 of codecs.py, when it was modified, yes. //Simon ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
