[ python-Feature Requests-1548178 ] Add 'find' method to sequence types
Feature Requests item #1548178, was opened at 2006-08-28 20:47 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1548178&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: None Status: Open Resolution: None Priority: 4 Submitted By: kovan (kovan) Assigned to: Nobody/Anonymous (nobody) Summary: Add 'find' method to sequence types Initial Comment: In the benefit of Python's readability and simplicity, a 'find' method could be added to sequence types, that would return the first item in the list that matches some criteria. For example, it's a common practice to use lists of (key,value) pairs instead of dictionaries when the sequence must be ordered. To find an element maching a key in such cases, I frequently find myself writing (IMHO) too much code for such a straightforward operation. AFAIK currently there are two easy ways to do this (shouln't be one, and only one?): for item in items: if item.attribute == key: foundItem = item break else: foundItem = None OR foundItems = [item for item in items if item.key == value] if foundItems: foundItem = foundItem[0] IMO, in none of the cases the code is as clear and, specially, as short, as it should be. With the find method, the same code would be: item = items.find(lambda x: x.key == value) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1548178&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1548252 ] Recursion limit exceeded in the match function
Bugs item #1548252, was opened at 2006-08-29 00:05
Message generated for change (Settings changed) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1548252&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: Closed
>Resolution: Fixed
Priority: 5
Submitted By: wojtekwu (wojtekwu)
Assigned to: Nobody/Anonymous (nobody)
Summary: Recursion limit exceeded in the match function
Initial Comment:
Python 2.3.4 (#53, May 25 2004, 21:17:02) [MSC v.1200
32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for
more information.
>>> import re
>>> exp = re.compile("((a*)(b*))*")
>>> result = exp.match("a")
Traceback (most recent call last):
File "", line 1, in ?
RuntimeError: maximum recursion limit exceeded
>>>
--
Comment By: Andres Riancho (andresriancho)
Date: 2006-08-29 01:31
Message:
Logged In: YES
user_id=1284064
I tried this on:
Python 2.4.3 (#2, Apr 27 2006, 14:43:58)
seems to be fixed.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1548252&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1548371 ] filterwarnings('error') has no effect
Bugs item #1548371, was opened at 2006-08-29 02: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=1548371&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: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Roger Upole (rupole)
Assigned to: Nobody/Anonymous (nobody)
Summary: filterwarnings('error') has no effect
Initial Comment:
Once a warning has already been issued,
warnings.filterwarnings('error',...) will not cause an
error to be raised. When the attached script is run,
the warning is printed the first time thru the loop,
but no error is raised the 2nd time thru. Likewise,
warnings.filterwarnings('always',...) will not cause
the warning to be printed again.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1548371&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1545837 ] array.array borks on deepcopy
Bugs item #1545837, was opened at 2006-08-24 11:49
Message generated for change (Comment added) made by twouters
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545837&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: Later
Priority: 7
Submitted By: Václav Haisman (wilx)
Assigned to: Anthony Baxter (anthonybaxter)
Summary: array.array borks on deepcopy
Initial Comment:
Hi,
I think there is a bug arraymodule.c this line:
{"__deepcopy__",(PyCFunction)array_copy,METH_NOARGS,
copy_doc},
should probably have METH_O instead of METH_NOARGS
there, since according to docs and the prototype of the
array_copy() function there is one parameter.
--
>Comment By: Thomas Wouters (twouters)
Date: 2006-08-29 09:35
Message:
Logged In: YES
user_id=34209
Not unless you want another release candidate. copy.deepcopy
has never worked on array instances, so it's not a
release-preventing bug (but each bugfix may *add* a
release-preventing bug by accident :)
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2006-08-28 15:32
Message:
Logged In: YES
user_id=80475
Should this be fixed in the release candidate?
--
Comment By: Thomas Wouters (twouters)
Date: 2006-08-24 20:50
Message:
Logged In: YES
user_id=34209
Thanks! Fixed in the trunk (which is 2.6-to-be) revision
51565, and it will also be fixed for Python 2.4.4 and 2.5.1.
It's unfortunately just a bit too late for 2.5.0.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545837&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1546628 ] urlparse.urljoin odd behaviour
Bugs item #1546628, was opened at 2006-08-25 23:04
Message generated for change (Comment added) made by the_j10
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1546628&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.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Andres Riancho (andresriancho)
Assigned to: Nobody/Anonymous (nobody)
Summary: urlparse.urljoin odd behaviour
Initial Comment:
Hi !
I think i have found a bug on the urljoin function
of the urlparse
module. I'm using Python 2.4.3 (#2, Apr 27 2006,
14:43:58), [GCC 4.0.3
(Ubuntu 4.0.3-1ubuntu5)] on linux2 . Here is a demo of
the bug :
>>> import urlparse
>>>urlparse.urljoin('http://www.f00.com/','//a')
'http://a'
>>>
urlparse.urljoin('http://www.f00.com/','https:///somethingIsWrong')
'https:///somethingIsWrong'
>>>
urlparse.urljoin('http://www.f00.com/','https:///somethingIsWrong')
'https:///somethingIsWrong'
>>>
urlparse.urljoin('http://www.f00.com/','file:///etc/passwd')
'file:///etc/passwd'
The result for the first call to urljoin should be
either
'http://www.f00.com/a' or 'http://www.f00.com//a'. The
result to the
second and third call to urljoin should be
'http://www.f00.com/', or maybe an
exception ?
Please correct me if i'm wrong and this is some kind
of feature or
the bug was already reported. This bug can result in a
security vuln,
take this code as an example:
// viewImage.py //
import htmlTools
# Some fake
module, just for the example
import urlparse
# module
with bug.
htmlTools.startHtml()
# print
params = htmlTools.getParams()# get the
query string
parameters
htmlTools.printToHtml( 'http://myWebsite/' , params['image'] ) + '>' )
htmlTools.endHtml()
# print
// viewImage.py //
The code should generate an html that shows an image
from the site
http://myWebsite/, but with the urljoin bug, the image
source can be
manipulated and result in a completely different html.
Cheers,
Andres Riancho
--
Comment By: Andrew Jones (the_j10)
Date: 2006-08-29 21:29
Message:
Logged In: YES
user_id=332575
The second argument in the urljoin method can be either an
absolute url or a relative url as specified by rfc1808. So
your 1st example: '//a' gives a relative position w.r.t the
base resulting in: 'http://a'. This is similar to how `cd
/boot` takes you to a path relative to the filesystem's root
'/'.
In the rest of your examples you have the scheme name
'https'in the url as the 2nd argument. urljoin follows the
rfc1808 and accepts the second argument if it has a scheme
name as the absolute url and returns it.
This behavior is not very intuitive. Perhaps the urlparse
could be extended to have a urlappend method, which has the
behavior you expected. Hmmm...
-- Andrew
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1546628&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1548687 ] C modules reloaded on certain failed imports
Bugs item #1548687, was opened at 2006-08-29 09:09 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=1548687&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.3 Status: Open Resolution: None Priority: 5 Submitted By: Josiah Carlson (josiahcarlson) Assigned to: Nobody/Anonymous (nobody) Summary: C modules reloaded on certain failed imports Initial Comment: Running z.py in the attached archive should produce an attribute error on printing, as we have set sys.stdout to None. On 2.3.5 and 2.4.3, output is printed and any imported C modules in x/y.py are reloaded, builtin or 3rd party. On 2.5, we get a traceback on import: "SystemError: Parent module 'x' not loaded". Changing the name on the import from 'x.y' to 'y' works-around the error, and we get the expected AttributeError in 2.3, 2.4. 2.5 gives us the same SystemError. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1548687&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1528802 ] Turkish Character
Bugs item #1528802, was opened at 2006-07-26 09:05
Message generated for change (Comment added) made by lemburg
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1528802&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: Unicode
Group: Python 2.5
Status: Open
Resolution: None
Priority: 6
Submitted By: Ahmet Bişkinler (ahmetbiskinler)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Turkish Character
Initial Comment:
>>> print "Mayıs".upper()
>>> MAYıS
>>> import locale
>>> locale.setlocale(locale.LC_ALL,'Turkish_Turkey.1254')
>>> print "Mayıs".upper()
>>> MAYıS
>>> print "ğüşiöçı".upper()
>>> ğüşIöçı
MAYıS should be MAYIS
ğüşIöçı should be ĞÜŞİÖÇI
but
>>> "Mayıs".upper()
>>> "MAYIS"
is right
--
>Comment By: M.-A. Lemburg (lemburg)
Date: 2006-08-29 19:43
Message:
Logged In: YES
user_id=38388
Could you test this with Unicode strings, ie. u"...".upper() ?
It would also help if you'd provide the repr()-version of
the strings - makes testing on non-Turkish systems easier.
Thanks.
--
Comment By: Ahmet Bişkinler (ahmetbiskinler)
Date: 2006-08-28 15:57
Message:
Logged In: YES
user_id=1481281
As you saw in the picture the IDLE does its work. Its is the
one who is working right.
The python interpreter(C:\Python25\Python.exe) has the
problem with it. Does the interpreter generate bug reports
if there is no crashing or else... And I don't know how to
file an IDLE bug report from the
interpreter(C:\Python25\Python.exe).
--
Comment By: M.-A. Lemburg (lemburg)
Date: 2006-08-21 12:01
Message:
Logged In: YES
user_id=38388
Could we please get some things straight first:
1. if you're working with IDLE and it doesn't do what you
expect it to, please file an IDLE bug report, not a Python
one; the same it true for any other Python IDE you are using
2. string's .lower() and .upper() method rely 100% on the
platform's C lib implementation of these functions; there's
nothing Python can do about bugs in these implementations
3. if you want reproducable behavior across platforms,
please always use Unicode, *not* 8-bit strings, for text data.
I see that #1 has already been done, so the IDLE specific
discussion should continue there.
#2 is the cause of the problem, then all we can do is point
you to #3.
If #3 fails for some reason, then we should investigate
this. However, be aware that the Unicode database has a
fixed set of case mappings and we currently don't support
extended case mapping which is locale and context sensitive.
Again, patches are welcome.
Please provide your examples using the repr() of the string
or Unicode objects in question. This makes it a lot easier
to test your examples on other platforms.
Thanks.
--
Comment By: Ahmet Bişkinler (ahmetbiskinler)
Date: 2006-08-21 09:55
Message:
Logged In: YES
user_id=1481281
There are still some problems with it. As in the image.
http://img205.imageshack.us/img205/3998/turkishcharpythonyu5.jpg
The upper() works fine(except ı and i uppercase) with IDLE
since upper() doesn't even work.
Another problem is with the ı(dotless) and i(dotted) 's upper.
ı(dotless) should be I (dotless)
i(dotted) should be İ (dotted)
ı = I
i = İ
For more information:
http://www.i18nguy.com/unicode/turkish-i18n.html
--
Comment By: Santiago Gala (sgala)
Date: 2006-08-18 16:37
Message:
Logged In: YES
user_id=178886
Done: Bug #1542677
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-08-17 21:08
Message:
Logged In: YES
user_id=849994
Please submit that as a separate IDLE bug.
--
Comment By: Santiago Gala (sgala)
Date: 2006-08-17 20:58
Message:
Logged In: YES
user_id=178886
Idle from 2.5rc1 (svn today) produces a different result
than console (with my default, utf-8, encoding):
IDLE 1.2c1
>>> print "á"
á
>>> print len("á")
2
>>> print "á".upper()
á
>>> str("á")
'\xc3\xa1'
>>> print u"á"
á
>>> print len(u"á")
2
>>> print u"á".upper()
á
>>> str(u"á")
Traceback (most recent call last):
File "", line 1, in
str(u"á")
UnicodeEncodeError: 'ascii' codec can't encode characters in
position 0-1: ordinal not in range(128)
Again, IDLE 1.1.3 (python 2.4.3) produces a different result:
IDLE 1.1.3
>>> print "á"
á
>>> print len("á")
2
>>> print "á".upper()
á
>>> str("á")
'\xc3\xa1'
>>> print u"á"
á
>>> print len(u"á")
2
>>> print u"á".upper()
á
>>> str(u"á")
'\xc3\x83\xc2\xa1'
>>>
I'd say id
[ python-Bugs-1548891 ] shlex (or perhaps cStringIO) and unicode strings
Bugs item #1548891, was opened at 2006-08-29 21:16 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=1548891&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 Submitted By: Erwin S. Andreasen (drylock) Assigned to: Nobody/Anonymous (nobody) Summary: shlex (or perhaps cStringIO) and unicode strings Initial Comment: Python 2.5c1 (r25c1:51305, Aug 19 2006, 18:23:29) [GCC 4.1.2 20060814 (prerelease) (Debian 4.1.1-11)] on linux2 (Also seen in 2.4) shlex.split do not like unicode strings: >>> shlex.split(u"foo") ['f\x00\x00\x00o\x00\x00\x00o\x00\x00\x00'] The shlex code IMO suggests that it should accept unicode (as it checks for argument being an instance of basestring). Digging slightly into this, this seems to be a difference between StringIO and cStringIO. While cStringIO claims it accepts unicode as long as it encode too ASCII it gives invalid results: >>> sys.getdefaultencoding() 'ascii' >>> cStringIO.StringIO(u'foo').getvalue() 'f\x00\x00\x00o\x00\x00\x00o\x00\x00\x00' Perhaps cStringIO should .encode to ASCII encoding before consuming the input, as I can't imagine anyone cares about the above result (which I guess are the UCS-2 or UCS-4 characters). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1548891&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1545696 ] structmember T_LONG won't accept a python long
Bugs item #1545696, was opened at 2006-08-24 00:07
Message generated for change (Comment added) made by rupole
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545696&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: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Roger Upole (rupole)
Assigned to: Nobody/Anonymous (nobody)
Summary: structmember T_LONG won't accept a python long
Initial Comment:
An attribute defined as T_LONG throws a vague error
when set to a python long, even when the value is
within the range of a LONG.
TypeError: bad argument type for built-in operation
--
>Comment By: Roger Upole (rupole)
Date: 2006-08-30 00:06
Message:
Logged In: YES
user_id=771074
Submitted patch 1549049.
--
Comment By: Roger Upole (rupole)
Date: 2006-08-27 21:23
Message:
Logged In: YES
user_id=771074
In the process of creating a patch for this, I came across
some more 'ugh'-liness. T_UINT's are returned via
PyInt_FromLong, so you actually get back a negative value
for large numbers. Changing it to use
PyLong_FromUnsignedLong will break backward compatibility,
but this is so wrong I can't possibly see keeping it. Your
call. (plus it makes it impossible to test T_UINT with
values larger than INT_MAX)
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2006-08-24 19:52
Message:
Logged In: YES
user_id=33168
Ugh. This code is lax in checking/conversion. Do you think
you could provide a patch?
All of the int cases should call PyInt_AsLong() if this call
fails (returns -1), then that should be returned from
PyMember_SetOne. If it succeeds, there should be a range
check that ensures the value is valid. If that fails a
warning should be produced. We need to issue a warning
rather than an error for backwards compatability (at least
for 2.6).
The float/double cases can be simplified some by calling
PyFloat_AsDouble and doing similar checks as in the int cases.
--
Comment By: Roger Upole (rupole)
Date: 2006-08-24 14:56
Message:
Logged In: YES
user_id=771074
The DEVMODE object from pywintypes has attributes defined
as T_LONG via the structmember API.
>>> import pywintypes
>>> dm=pywintypes.DEVMODEType()
>>> dm.Position_x=3
>>> dm.Position_x
3
>>> dm.Position_x=long(3)
Traceback (most recent call last):
File "", line 1, in ?
TypeError: bad argument type for built-in operation
>>>
Here's the relevant code from structmember.c
that throws the error:
case T_LONG:
if (!PyInt_Check(v)) {
PyErr_BadArgument();
return -1;
}
*(long*)addr = PyInt_AsLong(v);
break;
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2006-08-24 13:30
Message:
Logged In: YES
user_id=33168
Can you provide example code that demonstrates what you mean?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1545696&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
