[ python-Bugs-1117048 ] Dictionary Parsing Problem
Bugs item #1117048, was opened at 2005-02-05 17:50 Message generated for change (Settings changed) made by walterbrunswick You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1117048&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None >Priority: 2 Submitted By: WalterBrunswick (walterbrunswick) Assigned to: Nobody/Anonymous (nobody) >Summary: Dictionary Parsing Problem Initial Comment: Python Version: Python 2.4 OS Version: Microsoft Windows XP [Version 5.1.2600] There may or may not be (according to some people on #python on irc.freenode.net) a fault, if you will, in the way that Python evaluates dictionaries (in this case, globals()). apparently printing of dicts are optimized not to produce the entire output string before printing it This may be an advantage when it comes to processing speed and memory management, but when it comes to catching errors, this could very well be a problem. (I am waltz.) ... you think it should print a dict with an error in it? ha! caught ya there! well, if there's an error, it should break. and it did. It shouldn't print AT ALL. why not? Because of the ERROR! ... I'm saying it should raise an abstract exception (something like DictError) BEFORE printing, as to allow the programmer to handle the error. Some people don't agree with my argument, but I'll let you (the core developers) decide what's best. I just thought I should mention this issue, to help improve Python to the max! -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1117048&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1121201 ] Python24.dll crashes, EXAMPLE ATTACHED
Bugs item #1121201, was opened at 2005-02-12 03:59 Message generated for change (Comment added) made by complex You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121201&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Viktor Ferenczi (complex) Assigned to: Nobody/Anonymous (nobody) Summary: Python24.dll crashes, EXAMPLE ATTACHED Initial Comment: The attached small quantum physical modeller crashes python24.dll on Windows XP. I've a 3.0GHz Intel P4 processor, hyperthreading enabled. Requires latest numarray and visual python to run. The crash occours after 2-3 seconds of successful operation, so it can be a synchronization bug (visual python uses multithreading). Windows reports memory reference to 0x0001 or 0x (+1 or -1). The dissassembly shows many floating point operations around the current EIP. This may be a numarray problem, but I'm not sure. I installed only pre-built MSI and EXE installers downloaded from http://www.python.org, http://vpython.org and http://www.stsci.edu/resources/software_hardware/numarray. -- >Comment By: Viktor Ferenczi (complex) Date: 2005-02-12 04:30 Message: Logged In: YES user_id=142612 I've changed the main loop again to exlude most of the numarray computations: while 1: vi.rate(20) # Draw state #Display(WF*conjugate(WF)).real*scale) Display(identity(resolution[0])) # Time step #TimeStep() t+=step After 30 seconds the app crashed in cvisual.dll (visual python). The assembly code and the referenced address seems to be OK, but "the memory could not be read" according to the kernel paging tables. After narrowing down to visual python and excluding all of the numarray operations it still crashes. I pretty sure, that this is a synchronization problem with python 2.4 that causes corrupt values somewhere. I've to fallback to Python 2.3.5, since 2.4.0 is very unstable. I'll give a chance to python 2.4.1, when released. Please inform me if you need any assistance to narrow down this bug further. Note: I've not tried this on Linux or non-HT CPU, but I will do. Thanks for any help. -- Comment By: Viktor Ferenczi (complex) Date: 2005-02-12 04:19 Message: Logged In: YES user_id=142612 I've tried to narrow down the bug. The example app crashed at various points referencing various addresses. It seems to be an instability or data corruption in memory (stack?). I've changed the main loop of the attached example to: while 1: vi.rate(20) # Draw state #Display(WF*conjugate(WF)).real*scale) Display(identity(resolution[0])) # Time step TimeStep() t+=step After 10-20 seconds of operation the following appears (don't ask, my machine is stable): Visual 2005-01-08 Traceback (most recent call last): File "2D_Box.pyw", line 141, in ? Display(identity(resolution[0])) File "2D_Box.pyw", line 125, in Display seg[y][x+1].pos[3][2]=p TypeError: unsubscriptable object The delay varies. The exception is very odd, because it requires a data type change. This can be caused by data corruption. This could be an Intel P4 hyperthreading specific issue. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121201&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1121201 ] Python24.dll crashes, EXAMPLE ATTACHED
Bugs item #1121201, was opened at 2005-02-11 21:59 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121201&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Viktor Ferenczi (complex) Assigned to: Nobody/Anonymous (nobody) Summary: Python24.dll crashes, EXAMPLE ATTACHED Initial Comment: The attached small quantum physical modeller crashes python24.dll on Windows XP. I've a 3.0GHz Intel P4 processor, hyperthreading enabled. Requires latest numarray and visual python to run. The crash occours after 2-3 seconds of successful operation, so it can be a synchronization bug (visual python uses multithreading). Windows reports memory reference to 0x0001 or 0x (+1 or -1). The dissassembly shows many floating point operations around the current EIP. This may be a numarray problem, but I'm not sure. I installed only pre-built MSI and EXE installers downloaded from http://www.python.org, http://vpython.org and http://www.stsci.edu/resources/software_hardware/numarray. -- >Comment By: Tim Peters (tim_one) Date: 2005-02-11 22:46 Message: Logged In: YES user_id=31435 You should report this to the Visual Python developers; historically, invalid memory references are usually due to bugs in non-core C extension modules. This is especially true here since your last report is of a crash inside cvisual.dll -- it's unlikely that anyone working on core Python can help you with that. BTW, yours is the first claim I've heard that Python 2.4 is "very unstable", and no bugfixes in 2.4.1 yet are anything I'd consider to be major -- major bugs just haven't been reported. I use Python 2.4 myself on Windows, for hours every day, mostly as part of Zope/ZODB development. No problems there either. -- Comment By: Viktor Ferenczi (complex) Date: 2005-02-11 22:30 Message: Logged In: YES user_id=142612 I've changed the main loop again to exlude most of the numarray computations: while 1: vi.rate(20) # Draw state #Display(WF*conjugate(WF)).real*scale) Display(identity(resolution[0])) # Time step #TimeStep() t+=step After 30 seconds the app crashed in cvisual.dll (visual python). The assembly code and the referenced address seems to be OK, but "the memory could not be read" according to the kernel paging tables. After narrowing down to visual python and excluding all of the numarray operations it still crashes. I pretty sure, that this is a synchronization problem with python 2.4 that causes corrupt values somewhere. I've to fallback to Python 2.3.5, since 2.4.0 is very unstable. I'll give a chance to python 2.4.1, when released. Please inform me if you need any assistance to narrow down this bug further. Note: I've not tried this on Linux or non-HT CPU, but I will do. Thanks for any help. -- Comment By: Viktor Ferenczi (complex) Date: 2005-02-11 22:19 Message: Logged In: YES user_id=142612 I've tried to narrow down the bug. The example app crashed at various points referencing various addresses. It seems to be an instability or data corruption in memory (stack?). I've changed the main loop of the attached example to: while 1: vi.rate(20) # Draw state #Display(WF*conjugate(WF)).real*scale) Display(identity(resolution[0])) # Time step TimeStep() t+=step After 10-20 seconds of operation the following appears (don't ask, my machine is stable): Visual 2005-01-08 Traceback (most recent call last): File "2D_Box.pyw", line 141, in ? Display(identity(resolution[0])) File "2D_Box.pyw", line 125, in Display seg[y][x+1].pos[3][2]=p TypeError: unsubscriptable object The delay varies. The exception is very odd, because it requires a data type change. This can be caused by data corruption. This could be an Intel P4 hyperthreading specific issue. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121201&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1121201 ] Python24.dll crashes, EXAMPLE ATTACHED
Bugs item #1121201, was opened at 2005-02-12 03:59 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=1121201&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Viktor Ferenczi (complex) Assigned to: Nobody/Anonymous (nobody) Summary: Python24.dll crashes, EXAMPLE ATTACHED Initial Comment: The attached small quantum physical modeller crashes python24.dll on Windows XP. I've a 3.0GHz Intel P4 processor, hyperthreading enabled. Requires latest numarray and visual python to run. The crash occours after 2-3 seconds of successful operation, so it can be a synchronization bug (visual python uses multithreading). Windows reports memory reference to 0x0001 or 0x (+1 or -1). The dissassembly shows many floating point operations around the current EIP. This may be a numarray problem, but I'm not sure. I installed only pre-built MSI and EXE installers downloaded from http://www.python.org, http://vpython.org and http://www.stsci.edu/resources/software_hardware/numarray. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121201&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-1104021 ] wishlist: os.feed_urandom(input)
Feature Requests item #1104021, was opened at 2005-01-17 17:56 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1104021&group_id=5470 Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Zooko O'Whielacronx (zooko) Assigned to: Nobody/Anonymous (nobody) Summary: wishlist: os.feed_urandom(input) Initial Comment: Both unixy /dev/randoms and Microsoft's CryptGenRandom offer an API for userland to feed entropy into the system's pool. It would be nice if os.urandom() supported this feature. -- >Comment By: Martin v. Löwis (loewis) Date: 2005-02-12 01:52 Message: Logged In: YES user_id=21627 Would you like to work on a patch? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1104021&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1121201 ] Python24.dll crashes, EXAMPLE ATTACHED
Bugs item #1121201, was opened at 2005-02-12 03:59 Message generated for change (Comment added) made by complex You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121201&group_id=5470 Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Viktor Ferenczi (complex) Assigned to: Nobody/Anonymous (nobody) Summary: Python24.dll crashes, EXAMPLE ATTACHED Initial Comment: The attached small quantum physical modeller crashes python24.dll on Windows XP. I've a 3.0GHz Intel P4 processor, hyperthreading enabled. Requires latest numarray and visual python to run. The crash occours after 2-3 seconds of successful operation, so it can be a synchronization bug (visual python uses multithreading). Windows reports memory reference to 0x0001 or 0x (+1 or -1). The dissassembly shows many floating point operations around the current EIP. This may be a numarray problem, but I'm not sure. I installed only pre-built MSI and EXE installers downloaded from http://www.python.org, http://vpython.org and http://www.stsci.edu/resources/software_hardware/numarray. -- >Comment By: Viktor Ferenczi (complex) Date: 2005-02-12 04:19 Message: Logged In: YES user_id=142612 I've tried to narrow down the bug. The example app crashed at various points referencing various addresses. It seems to be an instability or data corruption in memory (stack?). I've changed the main loop of the attached example to: while 1: vi.rate(20) # Draw state #Display(WF*conjugate(WF)).real*scale) Display(identity(resolution[0])) # Time step TimeStep() t+=step After 10-20 seconds of operation the following appears (don't ask, my machine is stable): Visual 2005-01-08 Traceback (most recent call last): File "2D_Box.pyw", line 141, in ? Display(identity(resolution[0])) File "2D_Box.pyw", line 125, in Display seg[y][x+1].pos[3][2]=p TypeError: unsubscriptable object The delay varies. The exception is very odd, because it requires a data type change. This can be caused by data corruption. This could be an Intel P4 hyperthreading specific issue. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121201&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-1110010 ] 'attrmap' function, attrmap(x)['attname'] == x.attname
Feature Requests item #1110010, was opened at 2005-01-26 17:28
Message generated for change (Comment added) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1110010&group_id=5470
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Gregory Smith (gregsmith)
Assigned to: Nobody/Anonymous (nobody)
Summary: 'attrmap' function, attrmap(x)['attname'] == x.attname
Initial Comment:
One of the side effects of the new-style classes is that
objects don't necessarily have __dict__ attached to them.
It used to be possible to write things like
def __str__(self):
return "Node %(name)s, %(nlinks)d links,
active: %(active)s" % self.__dict__
... but this doesn't work if the class doesn't have a
__dict__. Even if does, I'm not sure it will always get
members from base classes.
There is a 'vars' function; you could put 'vars(self)'
in the above instead of self.__dict__, but it still
doesn't work if
the class doesn't have a __dict__.
I can see different solutions for this:
(1) change the 'string %' operator so that it allows
%(.name)s, leading to a getattr() on the right-side
argument
rather than a getitem.
return "Node %(.name)s, %(.nlinks)d links,
active: %(.active)s" % self
(2) Make a builtin like vars, but which works when the
object doesn't have a __dict__ I.e. attrmap(x) would
return a mapping which is bound to x, and reading
attrmap(x)['attname'] is the same as
getattr(x,'attname'). Thus
return "Node %(name)s, %(nlinks)d links,
active: %(active)s" % attrmap(self)
This attrmap() function can be implemented in pure
python, of course.
I originally thought (1) made a lot of sense, but (2) seems
to work just as well and doesn't require changing much.
Also, (1) allows cases like "%(name)s %(.name2)s",
which are not very useful, but are very likely to be
created by
accident; whereas in (2) you are deciding on the right
of the '%' whether you are naming attributes or
providing mapping keys.
I'm not sure it's a good idea change 'vars' to have
this behaviour, since vars(x).keys() currently works in
a predictable way when vars(x) works; whereas
attrmap(x).keys() may not be complete, or possible,
even when attrmap(x) is useful. I.e. when x has a
__getattr__ defined.
On the other hand, vars(x) doesn't currently do much at
all, so maybe it's possible to enhance it like this
without breaking anything.
The motivation for this came from the "%(name)s" issue,
but the attrmap() function would be useful in other
places e.g.
processdata( infile, outfile, **attrmap(options))
... where options might be obtained from optparse, e.g.
Or, an attrmap can be used with the new Templates:
string.Template('Node $name').substitute( attrmap(node))
Both of these examples will work with vars(), but only
when the object actually has __dict__. This is why
I'm thinking it may make sense to enhance vars: some
code may be broken by the change; but other code,
broken by new-style classes, may be unbroken by this
change.
The proxy could be writable, so that
attrmap(x)['a'] = y
is the same as
x.a = y
.. which could have more uses.
A possible useful (possibly weird) variation: attrmap
accepts 1 or more parameters, and the resulting
proxy is bound to all of them. when attrmap(x,y,z)['a']
is done, the proxy will try x.a, y.a, z.a until one of
them doesn't raise AttributeError. So it's equivalent
to merging dictionaries. This would be useful
in the %(name)s or Template cases, where you want
information from several objects.
--
>Comment By: Martin v. Löwis (loewis)
Date: 2005-02-12 01:51
Message:
Logged In: YES
user_id=21627
I think I would rather not to see this as a builtin, e.g.
putting it into UserDict.AttrMap instead.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1110010&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1121152 ] file seek error
Bugs item #1121152, was opened at 2005-02-11 19:36
Message generated for change (Settings changed) made by tim_one
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121152&group_id=5470
Category: Python Library
>Group: Not a Bug
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Richard Lawhorn (lawhorn999)
Assigned to: Nobody/Anonymous (nobody)
Summary: file seek error
Initial Comment:
When opening a file for overwrite ("rb+"), sucessive
read/writes fail to advance the pointer. The tell()
indicates that the pointer is advancing, but the
resulting file simply repeats an earlier record.
See attached file for an example.
--
>Comment By: Tim Peters (tim_one)
Date: 2005-02-11 20:54
Message:
Logged In: YES
user_id=31435
Sorry, write the code in C and you'll see the same behavior.
For a file opened for update, the effect of input followed by
output is undefined unless a file-positioning call is made
between the I/O calls; the effect of output followed by input
is also undefined, unless a file-positioning call or a call to flush
() is made between them. Your comment "This line should
NOT be needed" is simply incorrect: you are in fact trying to
do input immediately following output. If you want defined
behavior, then you must seek between them, and/or flush()
after the write().
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121152&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1121152 ] file seek error
Bugs item #1121152, was opened at 2005-02-11 17:36
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=1121152&group_id=5470
Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Lawhorn (lawhorn999)
Assigned to: Nobody/Anonymous (nobody)
Summary: file seek error
Initial Comment:
When opening a file for overwrite ("rb+"), sucessive
read/writes fail to advance the pointer. The tell()
indicates that the pointer is advancing, but the
resulting file simply repeats an earlier record.
See attached file for an example.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121152&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1120862 ] Problem in join function definition
Bugs item #1120862, was opened at 2005-02-11 16:43 Message generated for change (Comment added) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1120862&group_id=5470 Category: Documentation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: yseb (yseb) Assigned to: Nobody/Anonymous (nobody) Summary: Problem in join function definition Initial Comment: There is a problem in the last sentence of the join definition. == join( words[, sep]) Concatenate a list or tuple of words with intervening occurrences of sep. The default value for sep is a single space character. It is always true that "string.join (string.split(s, sep), sep)" equals s. == It is true that string.join(string.split(s, sep), sep)" is always equals to s. But string.join(string.split(s)) is not always equals to s especially for repeated sequence of spaces. -- >Comment By: Fredrik Lundh (effbot) Date: 2005-02-12 18:10 Message: Logged In: YES user_id=38376 And? If the documentation explains how something works, does it also have to list a couple of other things that doesn't work? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1120862&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1116571 ] Wrong match with regex, non-greedy problem
Bugs item #1116571, was opened at 2005-02-05 01:12 Message generated for change (Settings changed) made by effbot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1116571&group_id=5470 Category: Regular Expressions Group: Python 2.4 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: rengel (engel_re) Assigned to: Gustavo Niemeyer (niemeyer) Summary: Wrong match with regex, non-greedy problem Initial Comment: # This is executable. # My test string ist rather long: tst = "In this Buch, used to designate Dinge der Wirklichkeit rather than SW Ent." # I want to match the last part of the string: # SW Ent # So I define the following pattern an compile it: pat = r"(.*?) (.*?)" rex = re.compile(pat) # Then I search the string to get a match group : mat = rex.search(tst) # If found, print the group if mat: print mat.group() # Instead of # SW Ent # I get the whole string starting with # Buch... # up to the very last # Apparently the non-greedy operator doesn't work correctly. # What's wrong? -- Comment By: Fredrik Lundh (effbot) Date: 2005-02-08 09:27 Message: Logged In: YES user_id=38376 Search returns the first (left-most) location where the pattern matches, if any. The non-greedy operator only guarantees that you get the shortest possible match at that location. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1116571&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1121416 ] zip incorrectly and incompletely documented
Bugs item #1121416, was opened at 2005-02-12 12:18 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=1121416&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alan (aisaac0) Assigned to: Nobody/Anonymous (nobody) Summary: zip incorrectly and incompletely documented Initial Comment: See the zip documentation: http://www.python.org/dev/doc/devel/lib/built-in-funcs.html i. documentation refers to sequences not to iterables ii. The other problem is easier to explain by example. Let it=iter([1,2,3,4]). What is the result of zip(*[it]*2)? The current answer is: [(1,2),(3,4)], but it is impossible to determine this from the docs, which would allow [(1,3),(2,4)] instead (or indeed other possibilities). The example expresses the solution to an actual need, so the behavior should be documented or warned against, I believe. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121416&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1120862 ] Problem in join function definition
Bugs item #1120862, was opened at 2005-02-11 10:43 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1120862&group_id=5470 Category: Documentation Group: Python 2.5 >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: yseb (yseb) Assigned to: Nobody/Anonymous (nobody) Summary: Problem in join function definition Initial Comment: There is a problem in the last sentence of the join definition. == join( words[, sep]) Concatenate a list or tuple of words with intervening occurrences of sep. The default value for sep is a single space character. It is always true that "string.join (string.split(s, sep), sep)" equals s. == It is true that string.join(string.split(s, sep), sep)" is always equals to s. But string.join(string.split(s)) is not always equals to s especially for repeated sequence of spaces. -- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-12 14:22 Message: Logged In: YES user_id=80475 I concur. The sentence is correct: >>> s = ' the quickbrown \t\t fox jumped ' >>> sep = ' ' >>> s == string.join(string.split(s, sep), sep) True Possibly the docs could go on to talk about string.join(string.split(s)). However that would just be adding rambling verbiage that is unlikely to be helpful to anyone who has just read what string.split(s) actually does. -- Comment By: Fredrik Lundh (effbot) Date: 2005-02-12 12:10 Message: Logged In: YES user_id=38376 And? If the documentation explains how something works, does it also have to list a couple of other things that doesn't work? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1120862&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1121475 ] Decorated functions are unpickleable
Bugs item #1121475, was opened at 2005-02-12 11:48 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=1121475&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: S Joshua Swamidass (sswamida) Assigned to: Nobody/Anonymous (nobody) Summary: Decorated functions are unpickleable Initial Comment: The decorator feature renders functions impossible to pickle if you end up wrapping the function in either a trivial lambda or a callable class. This is a significant/artificial limitation of the decorator which should not exist and prevents decorators from being used for many of my purposes. == Examples: == >>> def dec(f): ... return lambda a: f(a) ... >>> @dec ... def func(a): ... return a ... >>> import pickle >>> pickle.dumps(func) Traceback (most recent call last): ... pickle.PicklingError: Can't pickle at 0x40160ae4>: it's not found as __main__. >>> class C: ... def __init__(self, f): ... self.f=f ... def __call__(self, a): ... return f(a) ... >>> def dec(f): ... return C(f) >>> @dec >>> def func(a): ...return a >>> import pickle >>> pickle.dumps(func) Traceback (most recent call last): . pickle.PicklingError: Can't pickle : it's not the same object as __main__.func == I've found a syntacically ugly ways of working around the class wrapper bug that don't use decorators. Perhaps this could be used to create a decorator patch: == >>> class C: ... def __init__(self, f): ... self.f=f ... def __call__(self, a): ... return f(a) ... >>> def _func(a): ...return a >>> func=C(_func) >>> >>> import pickle >>> pickle.dumps(func) (No error) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121475&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1121416 ] zip incorrectly and incompletely documented
Bugs item #1121416, was opened at 2005-02-12 12:18 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121416&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alan (aisaac0) >Assigned to: Raymond Hettinger (rhettinger) Summary: zip incorrectly and incompletely documented Initial Comment: See the zip documentation: http://www.python.org/dev/doc/devel/lib/built-in-funcs.html i. documentation refers to sequences not to iterables ii. The other problem is easier to explain by example. Let it=iter([1,2,3,4]). What is the result of zip(*[it]*2)? The current answer is: [(1,2),(3,4)], but it is impossible to determine this from the docs, which would allow [(1,3),(2,4)] instead (or indeed other possibilities). The example expresses the solution to an actual need, so the behavior should be documented or warned against, I believe. -- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-12 14:50 Message: Logged In: YES user_id=80475 The problem with your example does not lie with zip(). Instead, there is a misunderstanding of iter() and how iterators are consumed. Instead of iter(), the correct function is itertools.tee(): >>> zip(*tee([1,2,3,4])) [(1, 1), (2, 2), (3, 3), (4, 4)] Also, stylistically, the zip(*func) approach is too opaque. It is almost always better (at least for other readers and possibly for yourself) to write something more obvious in its intent and operation. List comprehensions and generator expressions are often more clear and easier to write correctly: >>> [(x,x) for x in [1,2,3,4]] [(1, 1), (2, 2), (3, 3), (4, 4)] I do agree that the word sequence should be dropped because it implies that non-sequence iterables are not acceptable as arguments. That's too bad because the word "sequence" seems to help people understand what zip is doing. You're correct that the zip docs do not describe its implementation in such detail as to be able to predict the [(1,2),(3,4)] result. However, that would be an over-specification. That particular result is an implementation specific detail that is subject to change. It probably won't change, but we don't want to encourage people to write code that relies on the specific order of operations within zip(). If someone wants to do something tricky, such as [(1,2),(3,4)], then they are better off writing an explicit loop so that the order of operation is clear both to themselves and to code reviewers. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121416&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1121475 ] Decorated functions are unpickleable
Bugs item #1121475, was opened at 2005-02-12 11:48 Message generated for change (Settings changed) made by sswamida You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121475&group_id=5470 Category: None Group: None Status: Open Resolution: None >Priority: 8 Submitted By: S Joshua Swamidass (sswamida) Assigned to: Nobody/Anonymous (nobody) Summary: Decorated functions are unpickleable Initial Comment: The decorator feature renders functions impossible to pickle if you end up wrapping the function in either a trivial lambda or a callable class. This is a significant/artificial limitation of the decorator which should not exist and prevents decorators from being used for many of my purposes. == Examples: == >>> def dec(f): ... return lambda a: f(a) ... >>> @dec ... def func(a): ... return a ... >>> import pickle >>> pickle.dumps(func) Traceback (most recent call last): ... pickle.PicklingError: Can't pickle at 0x40160ae4>: it's not found as __main__. >>> class C: ... def __init__(self, f): ... self.f=f ... def __call__(self, a): ... return f(a) ... >>> def dec(f): ... return C(f) >>> @dec >>> def func(a): ...return a >>> import pickle >>> pickle.dumps(func) Traceback (most recent call last): . pickle.PicklingError: Can't pickle : it's not the same object as __main__.func == I've found a syntacically ugly ways of working around the class wrapper bug that don't use decorators. Perhaps this could be used to create a decorator patch: == >>> class C: ... def __init__(self, f): ... self.f=f ... def __call__(self, a): ... return f(a) ... >>> def _func(a): ...return a >>> func=C(_func) >>> >>> import pickle >>> pickle.dumps(func) (No error) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121475&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1121475 ] Decorated functions are unpickleable
Bugs item #1121475, was opened at 2005-02-12 11:48 Message generated for change (Settings changed) made by sswamida You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121475&group_id=5470 Category: None >Group: Python 2.4 Status: Open Resolution: None Priority: 8 Submitted By: S Joshua Swamidass (sswamida) Assigned to: Nobody/Anonymous (nobody) Summary: Decorated functions are unpickleable Initial Comment: The decorator feature renders functions impossible to pickle if you end up wrapping the function in either a trivial lambda or a callable class. This is a significant/artificial limitation of the decorator which should not exist and prevents decorators from being used for many of my purposes. == Examples: == >>> def dec(f): ... return lambda a: f(a) ... >>> @dec ... def func(a): ... return a ... >>> import pickle >>> pickle.dumps(func) Traceback (most recent call last): ... pickle.PicklingError: Can't pickle at 0x40160ae4>: it's not found as __main__. >>> class C: ... def __init__(self, f): ... self.f=f ... def __call__(self, a): ... return f(a) ... >>> def dec(f): ... return C(f) >>> @dec >>> def func(a): ...return a >>> import pickle >>> pickle.dumps(func) Traceback (most recent call last): . pickle.PicklingError: Can't pickle : it's not the same object as __main__.func == I've found a syntacically ugly ways of working around the class wrapper bug that don't use decorators. Perhaps this could be used to create a decorator patch: == >>> class C: ... def __init__(self, f): ... self.f=f ... def __call__(self, a): ... return f(a) ... >>> def _func(a): ...return a >>> func=C(_func) >>> >>> import pickle >>> pickle.dumps(func) (No error) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121475&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1121494 ] distutils.dir_utils not unicode compatible
Bugs item #1121494, was opened at 2005-02-12 21:47 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=1121494&group_id=5470 Category: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Morten Lied Johansen (epcylon) Assigned to: Nobody/Anonymous (nobody) Summary: distutils.dir_utils not unicode compatible Initial Comment: When sourcefiles are passed in as unicodestrings, distutils.dir_utils. mkpath will throw a DistutilsInternalError, as shown in the example attached. Using: Python 2.4 (#1, Feb 12 2005, 20:12:07) 2.6.9-gentoo-r9 GNU/Linux -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121494&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1121579 ] subprocess example missing "stdout=PIPE"
Bugs item #1121579, was opened at 2005-02-12 16:27 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=1121579&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Monte Davidoff (mdavidoff) Assigned to: Nobody/Anonymous (nobody) Summary: subprocess example missing "stdout=PIPE" Initial Comment: In the Python Library Reference, section 6.8.3.2, the Popen for p2 is missing "stdout=PIPE". Correct line is: p2 = Popen(["grep", "hda"], stdin=p1.stdout, stdout=PIPE) This typo also occurs in subprocess.py line 232. The executable example on line 1118 is correct. Python 2.4, Red Hat Linux 9. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121579&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1121416 ] zip incorrectly and incompletely documented
Bugs item #1121416, was opened at 2005-02-13 03:18 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121416&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alan (aisaac0) Assigned to: Raymond Hettinger (rhettinger) Summary: zip incorrectly and incompletely documented Initial Comment: See the zip documentation: http://www.python.org/dev/doc/devel/lib/built-in-funcs.html i. documentation refers to sequences not to iterables ii. The other problem is easier to explain by example. Let it=iter([1,2,3,4]). What is the result of zip(*[it]*2)? The current answer is: [(1,2),(3,4)], but it is impossible to determine this from the docs, which would allow [(1,3),(2,4)] instead (or indeed other possibilities). The example expresses the solution to an actual need, so the behavior should be documented or warned against, I believe. -- Comment By: Nick Coghlan (ncoghlan) Date: 2005-02-13 11:30 Message: Logged In: YES user_id=1038590 Raymond's point about opaqueness is well-taken, since the given partitioning behaviour in the example was actually what was intended (I was part of the relevant c.l.p discussion). For future reference, the reliable approach is to use a generator function instead: from itertools import islice def partition(iterable, part_len): itr = iter(iterable) while 1: yield tuple(islice(itr, part_len)) -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-13 05:50 Message: Logged In: YES user_id=80475 The problem with your example does not lie with zip(). Instead, there is a misunderstanding of iter() and how iterators are consumed. Instead of iter(), the correct function is itertools.tee(): >>> zip(*tee([1,2,3,4])) [(1, 1), (2, 2), (3, 3), (4, 4)] Also, stylistically, the zip(*func) approach is too opaque. It is almost always better (at least for other readers and possibly for yourself) to write something more obvious in its intent and operation. List comprehensions and generator expressions are often more clear and easier to write correctly: >>> [(x,x) for x in [1,2,3,4]] [(1, 1), (2, 2), (3, 3), (4, 4)] I do agree that the word sequence should be dropped because it implies that non-sequence iterables are not acceptable as arguments. That's too bad because the word "sequence" seems to help people understand what zip is doing. You're correct that the zip docs do not describe its implementation in such detail as to be able to predict the [(1,2),(3,4)] result. However, that would be an over-specification. That particular result is an implementation specific detail that is subject to change. It probably won't change, but we don't want to encourage people to write code that relies on the specific order of operations within zip(). If someone wants to do something tricky, such as [(1,2),(3,4)], then they are better off writing an explicit loop so that the order of operation is clear both to themselves and to code reviewers. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121416&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1121416 ] zip incorrectly and incompletely documented
Bugs item #1121416, was opened at 2005-02-13 03:18 Message generated for change (Comment added) made by ncoghlan You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121416&group_id=5470 Category: Documentation Group: None Status: Open Resolution: None Priority: 5 Submitted By: Alan (aisaac0) Assigned to: Raymond Hettinger (rhettinger) Summary: zip incorrectly and incompletely documented Initial Comment: See the zip documentation: http://www.python.org/dev/doc/devel/lib/built-in-funcs.html i. documentation refers to sequences not to iterables ii. The other problem is easier to explain by example. Let it=iter([1,2,3,4]). What is the result of zip(*[it]*2)? The current answer is: [(1,2),(3,4)], but it is impossible to determine this from the docs, which would allow [(1,3),(2,4)] instead (or indeed other possibilities). The example expresses the solution to an actual need, so the behavior should be documented or warned against, I believe. -- Comment By: Nick Coghlan (ncoghlan) Date: 2005-02-13 12:25 Message: Logged In: YES user_id=1038590 The generator in the previous comment was incorrect (tuple swallows the StopIteration, so it never terminates). Try this instead: def partition(iterable, part_len): itr = iter(iterable) while 1: item = tuple(islice(itr, part_len)) if len(item) < part_len: raise StopIteration yield item -- Comment By: Nick Coghlan (ncoghlan) Date: 2005-02-13 11:30 Message: Logged In: YES user_id=1038590 Raymond's point about opaqueness is well-taken, since the given partitioning behaviour in the example was actually what was intended (I was part of the relevant c.l.p discussion). For future reference, the reliable approach is to use a generator function instead: from itertools import islice def partition(iterable, part_len): itr = iter(iterable) while 1: yield tuple(islice(itr, part_len)) -- Comment By: Raymond Hettinger (rhettinger) Date: 2005-02-13 05:50 Message: Logged In: YES user_id=80475 The problem with your example does not lie with zip(). Instead, there is a misunderstanding of iter() and how iterators are consumed. Instead of iter(), the correct function is itertools.tee(): >>> zip(*tee([1,2,3,4])) [(1, 1), (2, 2), (3, 3), (4, 4)] Also, stylistically, the zip(*func) approach is too opaque. It is almost always better (at least for other readers and possibly for yourself) to write something more obvious in its intent and operation. List comprehensions and generator expressions are often more clear and easier to write correctly: >>> [(x,x) for x in [1,2,3,4]] [(1, 1), (2, 2), (3, 3), (4, 4)] I do agree that the word sequence should be dropped because it implies that non-sequence iterables are not acceptable as arguments. That's too bad because the word "sequence" seems to help people understand what zip is doing. You're correct that the zip docs do not describe its implementation in such detail as to be able to predict the [(1,2),(3,4)] result. However, that would be an over-specification. That particular result is an implementation specific detail that is subject to change. It probably won't change, but we don't want to encourage people to write code that relies on the specific order of operations within zip(). If someone wants to do something tricky, such as [(1,2),(3,4)], then they are better off writing an explicit loop so that the order of operation is clear both to themselves and to code reviewers. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121416&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
