Lorenz Quack added the comment:
sorry it took so long but my contributor agreement is now signed.
Do you want me to write a patch with the results sorted?
If so, should I also change the docs to reflect that the results are sorted?
This would then also affect other implementations because they
Lorenz Quack added the comment:
sorry it took so long but the contributor agreement is now signed.
--
___
Python tracker
<http://bugs.python.org/issue22
Lorenz Quack added the comment:
I couldn't find anything concerning order in the docs so I didn't see any
reason the have them sorted.
I'm not opposed to sorting them. I guess you could call me +0 on returning
sorted(set(matches))
--
___
New submission from Lorenz Quack:
the doc string of __itruediv__ and __ifloordiv__ represent the operator as x/y
and x//y respectively.
This is obviously false and should be x/=y and x//=y
patch attached
--
assignee: docs@python
components: Documentation
files: inplace_div_doc.patch
Lorenz Quack added the comment:
Thanks for reviewing!
test now use assertIn and assertIsNone as suggested
PS: My Contributors Agreement is in progress. Just emailed the PSF with some
question (but I intend to sign it)
--
Added file: http://bugs.python.org/file37074/rlcompleter_22143
Lorenz Quack added the comment:
Hi,
here finally the updated patch with test case.
It depends on and should be applied after the patch included in issue22141.
This patch does changes two things:
1) completions are now unique
2) completions are now in no specific order
I had to touch some
Changes by Lorenz Quack :
Added file: http://bugs.python.org/file37064/rlcompleter_22141.patch
___
Python tracker
<http://bugs.python.org/issue22141>
___
___
Python-bug
Changes by Lorenz Quack :
Removed file: http://bugs.python.org/file37063/rlcompleter_22141.patch
___
Python tracker
<http://bugs.python.org/issue22141>
___
___
Python-bug
Lorenz Quack added the comment:
sorry for the delay but here is a new patch with a test.
I changed the strategy for fixing the bug because the dealing with the opening
parenthesis became to complicated.
So, now I simply check whether the match actually startswith the search phrase
before
Lorenz Quack added the comment:
Oops!
tests sound like a good Idea.
I realized my "fix" doesn't work.
I had not noticed this before because in my application I had already
implemented a workaround :/
The problem with catching the trailing parenthesis is that the group then does
Lorenz Quack added the comment:
attached the mini patch changing the regular expression in the proposed way
--
keywords: +patch
Added file: http://bugs.python.org/file36269/rlcompleter.diff
___
Python tracker
<http://bugs.python.org/issue22
New submission from Lorenz Quack:
Example:
>>> import rlcompleter
>>> completer = rlcompleter.Completer()
>>> class A(object):
... foo = None
>>> class B(A):
... pass
>>> b = B()
>>> print([completer.complete("b.foo", i
New submission from Lorenz Quack:
Example:
>>> completer = rlcompleter.Completer()
>>> class A(object):
... def foo(): pass
... def foobar(): pass
>>> completer.complete("A.foo(", 0)
'A.foo('
>>> completer.complete("A.foo(
New submission from Lorenz Quack :
RV Plastics is your end to end partner for all your moulds and Injection
Moulding requirements.
Founded in 2003, RV Plastics dedicates itself to the plastic industry,
exporting
Plastic injection moulds and molded Components to customers spread over 20
Lorenz Quack added the comment:
Thanks for the fast replies.
I used to groups some Python calls together and check in the end if any of them
failed in one exception handling block. I will now check every call
individually.
I will open a new bug for documentation fixes where there is now
Lorenz Quack added the comment:
I thought that the CamelCase C-functions like PyUnicode_AsUnicode would check
for errors like this and if you don't want error checking you can use the
capitalized versions like PyUnicode_AS_UNICODE.
I just looked at the code for PyFloat_AsDouble and it c
New submission from Lorenz Quack :
The C-API function "PyUnicode_AsUnicode(PyObject *unicode)" does not check the
argument for NULL pointers.
It passes it directly to the macro "PyUnicode_Check(op)" which then crashes
when trying to access "Py_TYPE(op)".
I marke
Lorenz Quack added the comment:
When I wrote this bug report I was mainly thinking about the C-API
documentation which doesn't mention extended slicing at all.
Since the C-API isn't mentioned in the other bug I don't think it's a duplicate
but they could maybe be m
New submission from Lorenz Quack :
I find the documentation regarding extended slicing to be lacking.
To be honest I couldn't find any documentation about it.
The only - and quite good - source of information I found was [1].
Maybe I didn't search enough. If so I would appreciate a l
New submission from Lorenz Quack :
I'm not sure if this is a bug or some weird backward-compatible behaviour...
In "distutil.extension.read_setup_file" it checks for the "-C" switch
but then appends "word" instead of "value"
So if you pass &qu
Lorenz Quack added the comment:
Ok, here is my shot at a patch for at least some of the undocumented
functions. Namely the following functions are being documented in the patch:
PyUnicode_FromFormat
PyUnicode_FromFormatV
PyUnicode_FromString
PyUnicode_FromStringAndSize
Lorenz Quack added the comment:
In addition to the above mentioned functions I found these to be
undocumented:
PyUnicode_DecodeUTF7
PyUnicode_DecodeUTF7Stateful
PyUnicode_EncodeDecimal
PyUnicode_EncodeUTF7
PyUnicode_FromFormat
PyUnicode_FromString
PyUnicode_FromStringAndSize
New submission from Lorenz Quack :
http://docs.python.org/c-api/typeobj.html#PyNumberMethods lists the
slots in the PyNumberMethods struct used to implement the Number
Protocol for extension types.
The entry for "binaryfunc nb_inplace_divide;" is missing from this listing.
It belon
Lorenz Quack added the comment:
FWIW here is the patch.
It is against r70267 of the trunk
--
keywords: +patch
message_count: 3.0 -> 4.0
Added file: http://bugs.python.org/file13291/itertools.patch
___
Python tracker
<http://bugs.pyth
Lorenz Quack added the comment:
Thanks for fixing.
But I'm afraid you missed the second typo in this Bug.
It's the same thing one line beneath the one you fixed.
next time I'll attach a patch. I promise.
--
message_count: 2.0 -> 3.0
stat
New submission from Lorenz Quack :
In the docs:
"http://docs.python.org/library/itertools.html#module-itertools";
In the table: "Iterators terminating on the shortest input sequence:"
In row: "imap()" and "starmap()"
In the column: &qu
Lorenz Quack <[EMAIL PROTECTED]> added the comment:
>> The loop in escape should really use enumerate
>> instead of "for i in range(len(pattern))".
>
>It needs i to edit s[i].
enumerate(iterable) returns a tuple for each element in iterable
containing th
Changes by Lorenz Quack <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file10054/rlcompleter.rst.diff
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Lorenz Quack <[EMAIL PROTECTED]> added the comment:
In the last patch I used the wrong ticks. I hope it's fine like this.
Added file: http://bugs.python.org/file10055/rlcompleter.rst.diff
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.
Lorenz Quack <[EMAIL PROTECTED]> added the comment:
I attached a patch for the docs.
It now states that the rlcompleter.Completer will catch and silence all
exceptions raised by evaluating the expression passed to complete()
Added file: http://bugs.python.org/file10054/rlcompleter.rs
Lorenz Quack <[EMAIL PROTECTED]> added the comment:
I confirmed that the rlcompleter can raise a SyntaxError on bad input.
Upon further investigation I found that a ReferenceError could also be
raised. I didn't check on other Exceptions.
I attached a new version of the patch where
Lorenz Quack <[EMAIL PROTECTED]> added the comment:
I was thinking that the code in question could maybe also raise other
exceptions. too bad I´m on vacation and can´t try this out myself.
I believe the regular expression also matches something like
import rlcompleter
rlcompleter.Com
Lorenz Quack <[EMAIL PROTECTED]> added the comment:
I have no idea what or who NAS is but comments are always welcome :)
concerning the documentation:
I´ve never done it before but there is a first time for everything,
right? I´m currently on vacation so I won´t look into it for at
New submission from Lorenz Quack:
in line 130 rlcompleter calls eval on the first part (before the last
dot) of the input text.
if that part is not valid it will raise an exception which is likely to
crash a calling application.
example 1:
==
import rlcompleter
rlcompleter.Completer
Lorenz Quack added the comment:
Some more information:
the dot in the example causes complete() to call self.attr_matches(text)
which in turn performes the following call
re.match(r"(\w+(\.\w+)*)\.(\w*)", text)
and return None if there is no match.
the complete method unconditionall
New submission from Lorenz Quack:
The following code would raise a TypeError:
>>> rlcompleter.Completer().complete("print self.foo", 0)
with this fix it will just return None
--
components: Library (Lib)
files: rlcompleter.patch
keywords: patch
messages: 63208
nosy:
36 matches
Mail list logo
