Changes by Daniel Urban :
--
nosy: +durban
___
Python tracker
<http://bugs.python.org/issue13062>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Daniel Urban :
--
nosy: +durban
___
Python tracker
<http://bugs.python.org/issue13264>
___
___
Python-bugs-list mailing list
Unsubscribe:
Daniel Urban added the comment:
> class Meta(ABCMeta):
> def __instancecheck__(cls, instance):
> # monkeypatching class method
> cls.__subclasscheck__ = super(Meta, cls).__subclasscheck__
This line is approximately the same as:
cls.__dict__['
Changes by Daniel Urban :
--
nosy: +durban
___
Python tracker
<http://bugs.python.org/issue13266>
___
___
Python-bugs-list mailing list
Unsubscribe:
Daniel Urban added the comment:
> It seems to me this is not a bug.
+1
--
___
Python tracker
<http://bugs.python.org/issue13264>
___
___
Python-bugs-list mai
Daniel Urban added the comment:
It doesn't work with staticmethod:
>>> import abc
>>>
>>> class C(metaclass=abc.ABCMeta):
... @staticmethod
... @abc.abstractmethod
... def foo(x):
... raise NotImplementedError()
...
>>> clas
Daniel Urban added the comment:
I've posted some comments on Rietveld.
--
___
Python tracker
<http://bugs.python.org/issue11610>
___
___
Python-bugs-list m
Changes by Daniel Urban :
--
nosy: +durban
___
Python tracker
<http://bugs.python.org/issue12374>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Daniel Urban :
--
nosy: +durban
___
Python tracker
<http://bugs.python.org/issue12459>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Daniel Urban :
--
nosy: +durban
___
Python tracker
<http://bugs.python.org/issue12457>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Daniel Urban :
--
nosy: +durban
___
Python tracker
<http://bugs.python.org/issue8639>
___
___
Python-bugs-list mailing list
Unsubscribe:
Daniel Urban added the comment:
Here is a patch. If the code changes are acceptable I can also make a
documentation patch.
(I'm surprised to see 3.2 in "Versions". I thought 3.2 only gets bugfixes...)
--
keywords: +patch
nosy: +durban
Added file: http://bugs.pytho
Daniel Urban added the comment:
> If we go this way, the "errors" and "newline" argument should be added
> as well.
Yeah, I thought about that. I can make a new patch, that implement this, if
needed. Though it seems there is a real problem, the one that Amaury F
Changes by Daniel Urban :
--
nosy: +durban
___
Python tracker
<http://bugs.python.org/issue12575>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Daniel Urban :
--
nosy: +durban
___
Python tracker
<http://bugs.python.org/issue12608>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Daniel Urban :
--
nosy: +durban
___
Python tracker
<http://bugs.python.org/issue12599>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Daniel Urban :
--
nosy: +durban
___
Python tracker
<http://bugs.python.org/issue12617>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Daniel Urban :
--
nosy: +durban
___
Python tracker
<http://bugs.python.org/issue12647>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Daniel Urban :
--
nosy: +durban
___
Python tracker
<http://bugs.python.org/issue12657>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Daniel Urban :
--
nosy: +durban
___
Python tracker
<http://bugs.python.org/issue12691>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Daniel Urban :
--
nosy: +durban
___
Python tracker
<http://bugs.python.org/issue12675>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Daniel Urban :
--
nosy: +durban
___
Python tracker
<http://bugs.python.org/issue12735>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Daniel Urban :
--
nosy: +durban
___
Python tracker
<http://bugs.python.org/issue12732>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Daniel Urban :
--
nosy: +durban
versions: +Python 3.3 -Python 2.7
___
Python tracker
<http://bugs.python.org/issue12772>
___
___
Python-bugs-list mailin
Changes by Daniel Urban :
--
nosy: +durban
___
Python tracker
<http://bugs.python.org/issue12775>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Daniel Urban :
--
nosy: +durban
___
Python tracker
<http://bugs.python.org/issue12857>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Daniel Urban :
--
nosy: +durban
___
Python tracker
<http://bugs.python.org/issue12850>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Daniel Urban :
--
nosy: +durban
___
Python tracker
<http://bugs.python.org/issue12915>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Daniel Urban :
--
nosy: +durban
___
Python tracker
<http://bugs.python.org/issue5867>
___
___
Python-bugs-list mailing list
Unsubscribe:
Daniel Urban added the comment:
I think, that the reason is that, object.__new__ checks, if the class is
instantiable (object_new in Objects/typeobject.c ). dict.__new__ (and
tuple.__new__, and I guess the __new__ method of other built-in types) doesn't
call object.__new__, but user de
Daniel Urban added the comment:
@abstractmethod
@classmethod
def ...
doesn't work because classmethod objects doesn't have a __dict__, so setting
arbitrary attributes don't work, and abstractmethod tries to set the
__isabstractmethod__ atribute to True.
The other orde
Daniel Urban added the comment:
Here is a patch, which adds a descriptor to classmethod and staticmethod.
Pseudocode:
__get__(self, inst, owner):
if getattr(inst.callable, '__isabstractmethod__', False):
return True
return False
__set__(self, inst, value):
ins
Daniel Urban added the comment:
If I understand correctly, some tests are needed for the instantiation of
classes with abstract static/classmethods. I added them in issue5867a.diff.
--
Added file: http://bugs.python.org/file18512/issue5867a.diff
Daniel Urban added the comment:
I'm attaching a new patch adding the abc.abstractclassmethod and
abc.abstractstaticmethod decorators.
--
Added file: http://bugs.python.org/file18519/abstractclassstaticmethod.diff
___
Python tracker
Daniel Urban added the comment:
I'm attaching a new patch containing also some documentation for the two new
decorators. The doc is rather terse, and english is not my first language, so
please let me know if some corrections are needed.
--
Added file: http://bugs.pytho
Changes by Daniel Urban :
--
nosy: +durban
___
Python tracker
<http://bugs.python.org/issue1615>
___
___
Python-bugs-list mailing list
Unsubscribe:
Daniel Urban added the comment:
Thanks for the corrections. I'm attaching the new patch as issue9212b.diff.
I'm using PyAnySet_Check to determine if the other argument is really a set,
but I'm not entirely sure, that this is correct. Please let me know if other
correct
Changes by Daniel Urban :
--
nosy: +durban
___
Python tracker
<http://bugs.python.org/issue9731>
___
___
Python-bugs-list mailing list
Unsubscribe:
Daniel Urban added the comment:
> Attached is a greatly revised patch, with two significant changes:
> - Adds support for !PyLong_CheckExact (using _PySequence_IterSearch)
Thanks, indeed, we should support that.
> Any strong feelings on whether range.index should support the start a
Daniel Urban added the comment:
Is there anybody, who is interested in this?
There are some substantial problems with it (hashing a dict), so I suggest that
this should be closed, unless somebody is interested.
--
status: open -> pending
___
Pyt
Changes by Daniel Urban :
--
nosy: +durban
___
Python tracker
<http://bugs.python.org/issue4761>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Daniel Urban :
--
nosy: +durban
___
Python tracker
<http://bugs.python.org/issue9746>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Daniel Urban :
--
nosy: +durban
___
Python tracker
<http://bugs.python.org/issue9756>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Daniel Urban :
The attached patch adds the start, stop and step members to range objects,
corresponding the contructor arguments. The patch also include tests and
documentation changes.
--
components: Interpreter Core
files: range_attrs.diff
keywords: patch
Daniel Urban added the comment:
> What is the use case for this?
The basic idea was, that in Python almost everything is introspectable, so why
range objects aren't. It was pretty straightforward to implement it, so I've
done it (actually when I was working on rangeobject.c, I
Changes by Daniel Urban :
--
nosy: +durban
___
Python tracker
<http://bugs.python.org/issue9971>
___
___
Python-bugs-list mailing list
Unsubscribe:
Daniel Urban added the comment:
If we create a new class, which is a metaclass, and also inherits an ABC, we
create a new instance of ABCMeta.
When ABCMeta.__new__ creates the __abstractmethods__ attribute of the new
class, it iterates over the __abstractmethods__ attribute of every base
Changes by Daniel Urban :
--
nosy: +durban
___
Python tracker
<http://bugs.python.org/issue10006>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Daniel Urban :
--
nosy: +durban
___
Python tracker
<http://bugs.python.org/issue10049>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Daniel Urban :
--
nosy: +durban
___
Python tracker
<http://bugs.python.org/issue10224>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Daniel Urban :
--
nosy: +durban
___
Python tracker
<http://bugs.python.org/issue11297>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Daniel Urban :
Currently instances of classes which inherit an ABC in collections.abc will
have a __dict__. This can be a problem for example a tree-like data structure.
It would make sense to inherit for example MutableMapping, but that would
possibly mean, that every
Daniel Urban added the comment:
> In what use-cases would you want to call MyABC.register() when defining
> a class instead of inheriting from MyABC?
For example if you don't want to inherit a __dict__ for a tree-like data
structure (see also
Daniel Urban added the comment:
Updated patch with extra tests.
--
Added file: http://bugs.python.org/file20911/issue11256_2.diff
___
Python tracker
<http://bugs.python.org/issue11
Daniel Urban added the comment:
I found another case, when this is a problem: if there are no **kwargs, but
there are some keyword-only arguments:
>>> def f(*, a, b): pass
...
>>> f(a=1, b=2)
>>>
>>> getcallargs(f, a=1, b=2)
Traceback (most recent call la
Changes by Daniel Urban :
--
nosy: +durban
___
Python tracker
<http://bugs.python.org/issue11339>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Daniel Urban :
--
nosy: +durban
___
Python tracker
<http://bugs.python.org/issue9276>
___
___
Python-bugs-list mailing list
Unsubscribe:
Daniel Urban added the comment:
It does exactly what is documented: "If any component is an absolute path, all
previous components (on Windows, including the previous drive letter, if there
was one) are thrown away, and joining continues."
(http://docs.python.org/dev/py3k/libra
Changes by Daniel Urban :
--
nosy: +durban
___
Python tracker
<http://bugs.python.org/issue11388>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Daniel Urban :
--
nosy: +durban
___
Python tracker
<http://bugs.python.org/issue4806>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Daniel Urban :
--
nosy: +durban
___
Python tracker
<http://bugs.python.org/issue7689>
___
___
Python-bugs-list mailing list
Unsubscribe:
Daniel Urban added the comment:
I think the patch isn't entirely correct. It uses PyIter_Check for detecting
the case when an *iterable* raises TypeError, but that function actually checks
for an *iterator*. The check on the tp_iter member mentioned by Amaury Forgeot
d'Arc prob
Daniel Urban added the comment:
I'm attaching an updated patch. Instead !PyIter_Check() this patch checks for
tp_iter == NULL && !PySequence_Check. If this condition is false,
PyObject_GetIter has a chance to succeed (and if it fails, we shouldn't mask
the exception).
Daniel Urban added the comment:
Apparently ast_error_finish calls PyTuple_GetItem with a value that is not a
tuple, but a SyntaxError instance (in Python/ast.c line 112). It seems that
ast_error_finish expects that PyErr_Fetch will return the exception value as a
tuple, and in some cases
Daniel Urban added the comment:
Here is a patch. I wasn't sure, where to put the test, so I put it in test_ast.
--
keywords: +patch
Added file: http://bugs.python.org/file21054/issue11441.patch
___
Python tracker
<http://bugs.python.org/is
Daniel Urban added the comment:
Okay, here is a new patch with the test in the correct place (I hope).
--
Added file: http://bugs.python.org/file21055/issue11441_2.patch
___
Python tracker
<http://bugs.python.org/issue11
Daniel Urban added the comment:
> Why is the exception normalized at the end? I suppose it's because
> when value is an exception instance, it's replaced by a tuple, but the
> original value has to be recreated at the end. So in some cases, the
> SyntaxError object is c
Daniel Urban added the comment:
> You could also call PyErr_NormalizeException at the beginning, and
> update the fields directly in the PySyntaxErrorObject structure. No
> need to deal with any tuple.
Sorry, but I don't really understand. If I call PyErr_NormalizeException at
Daniel Urban added the comment:
So, I see four possible solutions:
1. If we get a tuple, create the new tuple, normalize the exception, and store
it. If we get a SyntaxError instance, use its args, create the new tuple,
normalize, and store. (In this case a SyntaxError instance will be
Daniel Urban added the comment:
Err... sorry, I don't understand again:
If we get a tuple, create a new, store it without normalization. That's okay, I
understand.
If we get a SyntaxError instance, then take its args field, create the new
tuple. Then call PyErr_NormalizeException(
Daniel Urban added the comment:
> Can somebody propose a patch?
Yes, here it is. (I'm not sure if the test is in the correct file.)
--
keywords: +patch
nosy: +durban
Added file: http://bugs.python.org/file21072/issue11455.patch
___
Python
Changes by Daniel Urban :
--
nosy: +durban
___
Python tracker
<http://bugs.python.org/issue11470>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Daniel Urban :
--
nosy: +durban
___
Python tracker
<http://bugs.python.org/issue11477>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Daniel Urban :
copy.copy cannot copy a class which have a metaclass other than type:
>>> import abc
>>> import copy
>>>
>>> class C(metaclass=abc.ABCMeta):
... pass
...
>>> copy.copy(C)
Traceback (most recent call last)
New submission from Daniel Urban :
In the copyreg documentation there is this sentence: "The copy module is likely
to use this in the future as well."
(http://docs.python.org/dev/py3k/library/copyreg) But the copy module already
uses the copyreg module.
--
assignee: d
Daniel Urban added the comment:
Attaching an updated patch for py3k.
> Not an expert, but the Python parts of your patch look good to me.
Me neither, but the C parts also look good to me. The tests fail without the
patch, succeed with it.
Note, that it is possible, that the copy module a
Changes by Daniel Urban :
--
nosy: +durban
___
Python tracker
<http://bugs.python.org/issue11549>
___
___
Python-bugs-list mailing list
Unsubscribe:
Daniel Urban added the comment:
The new entry in Misc/NEWS says: "Patch by Daniel Urban." But it wasn't me, who
made the patch, I just opened the issue.
--
___
Python tracker
<http://bugs.pyt
Daniel Urban added the comment:
The reason of this behaviour is that x += 1 basically is the same as x =
x.__iadd__(1). In the tuple case: t[1] = t[1].__iadd__([6]). The __iadd__
call mutates the list, then the tuple item assignment raises the TypeError.
See these examples:
>>&g
Changes by Daniel Urban :
--
nosy: +durban
___
Python tracker
<http://bugs.python.org/issue11572>
___
___
Python-bugs-list mailing list
Unsubscribe:
Daniel Urban added the comment:
Updated the patch for mercurial.
--
Added file: http://bugs.python.org/file21281/issue11256_4.patch
___
Python tracker
<http://bugs.python.org/issue11
Changes by Daniel Urban :
--
nosy: +durban
___
Python tracker
<http://bugs.python.org/issue11610>
___
___
Python-bugs-list mailing list
Unsubscribe:
Daniel Urban added the comment:
I looked at the patch (I didn't test it yet), my comments are on Rietveld.
--
___
Python tracker
<http://bugs.python.org/is
Daniel Urban added the comment:
I tried to test your patch, but the build dies with this error:
Fatal Python error: Py_Initialize: can't initialize sys standard streams
Traceback (most recent call last):
File ".../cpython/Lib/io.py", line 60, in
Aborted
I don't know wh
Daniel Urban added the comment:
inspect.cleandoc (which is also used by inspect.getdoc and pydoc.getdoc) seems
to do a similar thing. Maybe that could be used for this?
--
nosy: +durban
___
Python tracker
<http://bugs.python.org/issue7
Daniel Urban added the comment:
Here is a patch for list. It modifies the following C API functions:
PyList_SetItem
PyList_Insert
PyList_Append
PyList_SetSlice
PyList_Sort
PyList_Reverse
_PyList_Extend
It also includes tests (with ctypes).
I plan to do next the same for dict, but first I&#
Daniel Urban added the comment:
> I would prefer an explicit PyExc_RuntimeWarning to not have to read the
> source of PyErr_WarnFormat() or its documentation.
The patch at issue11470 adds a new warning type, CompatibilityWarning. I think
probably that should be used he
Changes by Daniel Urban :
--
nosy: +durban
___
Python tracker
<http://bugs.python.org/issue11660>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Daniel Urban :
--
nosy: +durban
___
Python tracker
<http://bugs.python.org/issue11664>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Daniel Urban :
--
nosy: +durban
___
Python tracker
<http://bugs.python.org/issue11640>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Daniel Urban :
--
nosy: +durban
___
Python tracker
<http://bugs.python.org/issue5135>
___
___
Python-bugs-list mailing list
Unsubscribe:
Daniel Urban added the comment:
The problem seems to be that you're calling Decimal.from_float with a Decimal
instance, not a float. I'm not sure that should even work. The Decimal
constructor can create a decimal from an other decimal.
Your suggested solution probably would
Changes by Daniel Urban :
--
nosy: +durban
___
Python tracker
<http://bugs.python.org/issue887237>
___
___
Python-bugs-list mailing list
Unsubscribe:
Daniel Urban added the comment:
> not x == 2 can be theoretically optimized to x != 2, ...
I don't think it can:
>>> class X:
... def __eq__(self, other):
... return True
... def __ne__(self, other):
... return True
...
>>> x = X()
Changes by Daniel Urban :
--
nosy: +durban
___
Python tracker
<http://bugs.python.org/issue7796>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Daniel Urban :
--
nosy: +durban
___
Python tracker
<http://bugs.python.org/issue11707>
___
___
Python-bugs-list mailing list
Unsubscribe:
Daniel Urban added the comment:
The attached test case currently fails. I'll try to make a patch soon.
> Perhaps __build_class__ (which I have not read) should either call
> type_new or a new function with the winner calculation factored out of
> type_new.
Yeah, that'
Daniel Urban added the comment:
What about this:
>>> class MyTestCase(TestCase):
... def test_foo(self):
... with self.assertRaises(SyntaxError) as cm:
... compile('asdf jkl', 'file.py', 'eval')
..
Daniel Urban added the comment:
The attached patch seems to correct this issue. It contains the test attached
yesterday, and it passes now.
I factored out the winner calculation from type_new to a new
_PyType_CalculateWinner function, and type_new calls this. I've put the
declarati
Changes by Daniel Urban :
--
nosy: +durban
___
Python tracker
<http://bugs.python.org/issue11764>
___
___
Python-bugs-list mailing list
Unsubscribe:
1 - 100 of 271 matches
Mail list logo
