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] 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
