[issue18078] threading.Condition to allow notify on a specific waiter
João Bernardo added the comment: Don't keep your hopes up. People here don't like implementing features they don't understand about even if they could verify elsewhere it works well. My solution at the time was to create a decent "Condition" class based on the original one (subclassing this one is not safe). Feel free to use my patch above. -- ___ Python tracker <https://bugs.python.org/issue18078> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13290] get vars for object with __slots__
João Bernardo added the comment: Being the OP, at that time I felt it was important to have a vars() function that worked on __slots__ to ease something I was developing. The truth for me is: __slots__ is not really relevant anymore. The benefits it brings are not enough to make the feature usable because of these incompatibilities with normal classes. Also, it does not bring real benefits even for most people who think they need this. If you believe having vars() working on __slots__ is bad because people may want to update it, why would locals() exist at all? Also, your argument that having vars() working on __slots__ classes may mask the wrong use of the attribute, why would someone use vars() on __slots__ if it doesn't work right now? If it is not useful for identifying this problem now, then I am ok with it not being useful in the future as well. On any case, feel free to mark this as "rejected" or "wont fix" because if in 6 years no one cared enough to have it working means that either it is not important and/or __slots__ classes are also not relevant for others as well. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue13290> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18159] ConfigParser getters not available on SectionProxy
João Bernardo added the comment: ping? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18159 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19933] Round default argument for ndigits
João Bernardo added the comment: I don't understand. There's already a way to make round return an integer: don't pass a second argument. If this function were to be written in Python, it would be something like: def round(number, ndigits=0): ... or def round(number, ndigits=None): ... But in C you can forge the signature to whatever you want and parse the arguments accordingly. In Python there's always a way to get the default behavior by passing the default argument, but in C it may not exist (in this case `PyObject *o_ndigits = NULL;`) So, I propose the default value being `None`, so this behavior can be achieved using a second argument. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19933 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19933] Round default argument for ndigits
João Bernardo added the comment: Anyway, why not round(1.2) - 1.0 in the first place? Just curious. It was the behavior on Python 2.x, but somehow when they changed the rounding method to nearest even number this happened... I think it's too late to change back the return type. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19933 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19933] Round default argument for ndigits
João Bernardo added the comment: Not really. Just consistency: For the same reason ' foo '.strip(None) works... To avoid special casing the function call when you already have a variable to hold the argument. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19933 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19933] Round default argument for ndigits
New submission from João Bernardo: From the docs for built-in function round: If ndigits is omitted, it defaults to zero (http://docs.python.org/3/library/functions.html#round) But, the only way to get an integer from `round` is by not having the second argument (ndigits): round(3.5) 4 round(3.5, 1) 3.5 round(3.5, 0) 4.0 round(3.5, -1) 0.0 round(3.5, None) Traceback (most recent call last): File pyshell#6, line 1, in module round(3.5, None) TypeError: 'NoneType' object cannot be interpreted as an integer Either the docs are wrong or the behavior is wrong. I think it's easier to fix the former... But also there should be a way to make round return an integer (e.g. passing `None` as 2nd argument) -- assignee: docs@python components: Documentation, Interpreter Core messages: 205647 nosy: JBernardo, docs@python priority: normal severity: normal status: open title: Round default argument for ndigits versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19933 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18078] threading.Condition to allow notify on a specific waiter
João Bernardo added the comment: Seems like just because I never used I don't support. Boost C++ libraries has a wait_for_any functionality to synchronize futures. C# has a WaitAny in the WaitHandle class (like our Condition). Another problem is: the Condition class cannot be easily subclassed because all the important bits are _protected... Can you add an interface for the _waiters list and _lock objects?? If you do that I'll be happy subclassing it. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18078 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18078] threading.Condition to allow notify on a specific waiter
João Bernardo added the comment: I've been thinking about returning a list on wait_for_any, but that way you will not be able to implement wait_for using it! wait_for will return False on timeouts while wait_for_any will return a list with some conditions(evaluates to True). Also, wait_for will show the result of the predicate when there's no timeout. It may clash with the boolean value of the list in some cases. Suggestions? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18078 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18078] threading.Condition to allow notify on a specific waiter
João Bernardo added the comment: ping. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18078 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18078] threading.Condition to allow notify on a specific waiter
João Bernardo added the comment: Charles-François's point about the algorithmic complexity is legitimate, so I think he was actually waiting for you to amend your patch ;) This doesn't seems to be the actual issue as it would require a big change for something that wasn't proven important... The old behavior is still O(1) in the new implementation. I might change that, but can someone give me an actual idea to implement that? Also, this can be done on another patch. ** The real problem ** I pointed out one issue about which conditions should be considered when waking up and there was no answer: http://bugs.python.org/msg190556 Also, Richard Oudkerk wrote he was expecting wait_for_any() return a list: http://bugs.python.org/msg190597 I need to get feedback about the first one to change the second one. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18078 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18078] threading.Condition to allow notify on a specific waiter
João Bernardo added the comment:
1) It should check all predicates.
OK. Maybe later there could be an option for customization?
2) It should return a list of ready conditions.
OK.
3) It should *not* accept a list of conditions.
The list option would be to simplify the wait method... Avoiding things like:
{cond: (lambda: True)}
4) from_condition() should be removed.
OK. Could the Lock object be made part of the api, then? like self.lock
instead of self._lock
I'm OK with the rest of your post. Will make new patch
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18078
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18159] ConfigParser getters not available on SectionProxy
João Bernardo added the comment: Was the patch accepted yet? Looks good to me -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18159 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18078] threading.Condition to allow notify on a specific waiter
João Bernardo added the comment: (ping) It would be nice to have the feature on 3.4. What changes should I do to the patch? Is anyone else working on that? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18078 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18159] ConfigParser getters not available on SectionProxy
João Bernardo added the comment: Overriding __getattr__ doesn't look like the best solution Another idea would be to allow the proxy class to be selectable, but this would require the user to do much more coding for this simple thing... I believe a proxy should be dynamic enough to avoid having to duplicate every function definition. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18159 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18159] ConfigParser getters not available on SectionProxy
New submission from João Bernardo:
The configparser.RawConfigParser class implements some `get` methods:
get, getint, getfloat, getboolean
but if any of these get overridden on a subclass(with other arguments) or new
ones are added (e.g. getlist), there's no way a SectionProxy instance will be
able to use them.
class DemoParser(ConfigParser):
def getlist(self, section, option):
return self.get(section, option).split()
parser = DemoParser()
parser.read(some_file)
# These 2 lines should be equivalent, like getint, but the
# second doesn't work because of the SectionProxy instance
parser.getlist('some_section', 'foo')
parser['some_section'].getlist('foo')
Reading the code, for SectionProxy, it redefines all the get* methods from
RawConfigParser, and that looks pretty bad...
A more elegant approach would be to fetch the function on the parser instance
and bound to the section name with `lambda` or `functools.partial`... Something
like:
class SectionProxy(...):
...
def __getattr__(self, attr):
if not attr.startswith('get'):
raise AttributeError(attr)
fn = getattr(self._parser, attr)
return lambda *args, **kw: fn(self._name, *args, **kw)
--
components: Library (Lib)
messages: 190767
nosy: JBernardo
priority: normal
severity: normal
status: open
title: ConfigParser getters not available on SectionProxy
type: behavior
versions: Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18159
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18078] threading.Condition to allow notify on a specific waiter
João Bernardo added the comment: I'm not convinced it's really useful. It doesn't seem a lot useful until you *really* need it. I've got 2 highly parallel programs that took advantage of this pattern. the wait is O(C) (appending to C wait queues) and wakeup is O(CT) (C removal from a T-length deque). That's another thing that I wanted to address, but I didn't want to change the data structure in this patch. The complexity for `notify` and `notify_all` is the same as before. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18078 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18078] threading.Condition to allow notify on a specific waiter
João Bernardo added the comment: BTW, I think it would be better to have wait_for_any() return a list of ready conditions rather than a boolean. That was the original idea until I realized `wait` and `wait_for` were just specializations of `wait_for_any`. This can probably be done with another helper function. (BTW: There are 2 commented lines in the patch that can be used to see the ready Conditions). Any suggestions? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18078 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18078] threading.Condition to allow notify on a specific waiter
João Bernardo added the comment: Here, removing a thread from a wait queue other than the one from which it was signalled is O(waiting threads). To be fair, You will probably never have more than a few hundred/thousand threads on a process. Usually you'll work under a few dozen threads. To reduce the complexity on average, you could use a set, but `notify` no longer will be able to follow insertion order. I was hoping it could be done later... -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18078 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18078] threading.Condition to allow notify on a specific waiter
João Bernardo added the comment: Hi, This code is working quite well on my system, but I'm still not sure if the behavior of multiple predicates is the one other people want. So, for the thread start running again: - Should it test only the predicates from the awakened Conditions an accept if one of them is true? - Or any of the predicates must be true (current implementation)? - Or all of them must be true (less likely, but possible)? Another option is that we allow the behavior to be configurable. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18078 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18078] threading.Condition to allow notify on a specific waiter
João Bernardo added the comment:
I did what @Richard Oudkerk said and created the wait_for_any classmethod for
the Condition class.
Other Changes:
- I had to refactor wait and wait_for to be specializations of
wait_for_any.
- try...except on notify because the inner lock might have been released by
other condition.
- Added two helper functions _remove_waiter and _wait (the part of the old
wait function to re-acquire the inner lock)
Bonus:
To simplify the use, I added a from_condition constructor to create a new
condition using the same lock as an existing one.
That way, you don't need to record the lock someplace else before creating a
new Condition for the same lock.
* The current tests pass.
* Missing: new tests and docs.
Sample:
lock = Lock()
cond1 = Condition(lock)
cond2 = Condition(lock)
cond3 = Condition.from_condition(cond1)
with lock:
Condition.wait_for_any({cond1: foo, cond2: bar})
Condition.wait_for_any([cond1, cond2, cond3]) # no predicates
# used on wait
with cond2: # same thing
Condition.wait_for_any({cond3: foo})
---
PS: the patch text is messy because of refactoring and some lines were moved.
It is easy to read when applied.
--
keywords: +patch
Added file: http://bugs.python.org/file30413/wait_for_any.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18078
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18078] threading.Condition to allow notify on a specific waiter
João Bernardo added the comment: I usually have hundreds of threads waiting on a single Condition object and I wake them with .notify_all() Sometimes, I want a specific thread to wake from this condition and finish their job apart from the others. The problem is that I have 2 conditions to wait for. I can't just add another Condition object and ask for it to wait for the first (unless there is some sort of `select` mechanism). BTW, I find .notify(N) not much useful, because the docs say it may wake more threads on a different implementation and also I can't never know whom am I waking. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18078 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18078] threading.Condition to allow notify on a specific waiter
João Bernardo added the comment: But it might be nice to be able to wait on multiple conditions at once, assuming they are associated with the same lock. Maybe we could have a static method This could solve the waiting problem for the thread, but also may keep the other Condition objs waiting -- and that may not be problem because I'm already using .notify_all() Probably this function have more use cases than my original idea, but is it simple to wait on several locks? It could be in the form: Condition.wait_for_any(cond_to_pred: dict|list, timeout=None) - condition For cases when there's no need for a predicate function. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18078 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18078] threading.Condition to allow notify on a specific waiter
João Bernardo added the comment:
It would be for waiting for several conditions associated with the
same lock, not for waiting for several locks.
A Condition uses a 2 lock mechanism:
- outer lock: one for all the waiters to access the Condition object
- inner lock: one for each waiter to wait on.
You cannot associate several conditions to the *inner lock*, because you don't
have access to them (otherwise I wouldn't open this issue).
You said you want to have several conditions on the lock passed by the user:
lock = Lock()
cond1 = Condition(lock)
cond2 = Condition(lock)
Condition.wait_for_any({cond1: foo, cond2: bar})
but because this lock object is not the one the thread is waiting on, it
won't work.
There is always a need for a predicate function.
You may not need to test for a predicate when using .wait() . Only when you're
using .wait_for()
This is what I'm most interested in mimicking.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18078
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18078] threading.Condition to allow notify on a specific waiter
João Bernardo added the comment: Condition.wait_for_any() would create a single inner lock and add it to the _waiters list for each of the condition variables Now I see your point! Could it also have one (optional) argument so I can provide this lock myself? while expr: cond.wait() This allows the woken thread to check whether it is really supposed to continue -- Yes, I use that, but sometimes I have the thread just waiting for cleanup time and there's no need to check a condition. This is one my use cases though... You may want it to be more generic. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18078 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18078] threading.Condition to allow notify on a specific waiter
New submission from João Bernardo: If users could provide an inner lock for `threading.Condition` acquire when making a thread wait, it would allow for notifying a specific waiter. Because of race conditions, using: cond.notify(1) may not wake the thread I want. Also, I may not want to wake the first waiter at all. So my proposal is something along the lines: class Condition: ... def wait(self, timeout=None, lock=None): ... waiter = _allocate_lock() if lock is None else lock ... def notify_one(self, lock): # Maybe could notify a list of locks? try: self._waiters.remove(lock) except ValueError: pass # Maybe RuntimeError(Lock not waiting in this Condition) else: lock.release() -- components: Library (Lib) messages: 190173 nosy: JBernardo priority: normal severity: normal status: open title: threading.Condition to allow notify on a specific waiter type: enhancement versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18078 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16872] Metaclass conflict proposition
New submission from João Bernardo: This is actually a proposition for a behavior change caused by a bugfix. I have a project dealing with a metaclass factory and the next thing in the TODO list was to add multiple inheritance support. For my surprise, I tried and there was no metaclass conflict on Python 2.7... I've been developing on Py3.2 and now on Py3.3 an it couldn't obviously choose one of the metaclass to use. I found this(http://hg.python.org/cpython/rev/c2a89b509be4) commit saying the metaclass calculation was fixed on some special cases (I think it is because of the __new__ method on the metaclass). Py3.1 and inferior are not affected. The thing is: My metaclasses are smart enough to produce the right behavior so the bug doesn't bother me as long as this bugfix never gets backported. For Python 3.2+, the solution requires some more code/knowledge for the user: If I have this class diagram for Obj, A and B: Obj[type=M]M /\ - / \ A[type=MA] B[type=MB] MA MB then, I want to create C: class C(A, B, metaclass=something): pass Where something cannot be neither MA, MB or M because of metaclass conflict. but if something = lambda *args: M(*args) I can call finally call my smart metaclass to solve the problem. Now the proposition: It is possible for the metaclass to have some special attribute (e.g. __call_me_maybe__ = True) so Python knows it can deal with these special cases and avoid the user to explicitly use the `metaclass` parameter? So class C(A, B): pass Would call MA because of the special attribute inherited from M and it would know how to deal with the B class. If it can't do it with some X class, just return NotImplemented or other thing so the `TypeError: metaclass conflict...` will finally be shown. -- components: Interpreter Core messages: 179140 nosy: JBernardo priority: normal severity: normal status: open title: Metaclass conflict proposition type: behavior versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16872 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15245] ast.literal_eval fails on some literals
João Bernardo jbv...@gmail.com added the comment:
Of course `nan` and `inf` are part of the syntax! The `ast.parse` function
recognize them as `Name`.
So that works:
ast.dump(ast.parse('True'))
Module(body=[Expr(value=Name(id='True', ctx=Load()))])
ast.dump(ast.parse('inf'))
Module(body=[Expr(value=Name(id='inf', ctx=Load()))])
inf = float('inf')
eval('inf')
inf
I've run into some literals with `Ellipsis` and `inf` and couldn't load them
with literal_eval. That's why I'm proposing that.
The thing about `nan` and `inf` is because they are the *only* representations
of float numbers produced by the interpreter that cannot be loaded.
Something like that could solve the problem keeping `literal_eval` safe and
allowing other names:
ast.literal_eval('[1.0, 2.0, inf]', {'inf': float('inf')})
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15245
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15245] ast.literal_eval fails on some literals
Changes by João Bernardo jbv...@gmail.com: -- keywords: +patch Added file: http://bugs.python.org/file26262/ast.py.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15245 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15245] ast.literal_eval fails on some literals
João Bernardo jbv...@gmail.com added the comment: Ellipsis in this context is `_ast.Ellipsis`, not the original one... There's no TypeError there as `_ast.Ellipsis` is a class. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15245 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15245] ast.literal_eval fails on some literals
Changes by João Bernardo jbv...@gmail.com: Added file: http://bugs.python.org/file26264/ast.py_with_tests.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15245 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15245] ast.literal_eval fails on some literals
João Bernardo jbv...@gmail.com added the comment: Just to be sure: What's a doc update? The `.rst` files are updated automatically with the doc strings? The adding another argument should require a: Changed in version 3.x: Accepts a second argument ... ? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15245 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15245] ast.literal_eval fails on some literals
Changes by João Bernardo jbv...@gmail.com: Added file: http://bugs.python.org/file26266/ast.py_tests_doc.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15245 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15245] ast.literal_eval fails on some literals
João Bernardo jbv...@gmail.com added the comment: That's what I said by `nan` and `inf` are not literals, but their representations look like they should be. One solution could be to add another argument to allow some extra names. Maybe a mapping, as `eval`. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15245 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15245] ast.literal_eval on some literals
New submission from João Bernardo jbv...@gmail.com:
`ast.literal_eval` is very strict on names, so it seems to lack some literals
that may be result of `repr` on built-in objects.
- Obvious cases:
ast.literal_eval('...')
ast.literal_eval('Ellipsis')
both result on ValueError.
- Not so obvious:
nan_name = repr(float('nan'))
ast.literal_eval(nan_name) # ValueError
inf_name = repr(float('inf'))
ast.literal_eval(inf_name) # ValueError
ast.literal_eval(2e308) # == inf
`nan` and `inf` are not literals (at least inf should be, but that's another
problem), but their representations are not possible to be evaluated unlike any
other float numbers with maybe precision loss.
I think `literal_eval` should include these 3 names the same way it accepts
True, False and None.
Another case, that I personally don't care, but seems plausible would be
`NotImplemented`.
--
components: Library (Lib)
messages: 164621
nosy: JBernardo
priority: normal
severity: normal
status: open
title: ast.literal_eval on some literals
type: enhancement
versions: Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15245
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13667] __contains__ method behavior
New submission from João Bernardo jbv...@gmail.com: Hi, I'm working on a class which implements the __contains__ method but the way I would like it to work is by generating an object that will be evaluated later. It'll return a custom object instead of True/False class C: def __contains__(self, x): return I will evaluate this thing later... Don't bother now but when I do: 1 in C() True It seems to evaluate the answer with bool! Reading the docs (http://docs.python.org/py3k/reference/expressions.html#membership-test-details) It says: `x in y` is true if and only if `y.__contains__(x)` is true. It looks like the docs doesn't match the code and the code is trying to mimic the behavior of lists/tuples where x in y is the same as any(x is e or x == e for e in y) and always yield True or False. There is a reason why it is that way? Thanks! -- assignee: docs@python components: Documentation, Interpreter Core messages: 150283 nosy: JBernardo, docs@python priority: normal severity: normal status: open title: __contains__ method behavior type: behavior versions: Python 3.2, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13667 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13667] __contains__ method behavior
João Bernardo jbv...@gmail.com added the comment: @Georg Brandl Oh sorry, now I see... true != True But still, why is that the default behavior? Shouldn't it use whatever the method returns? -- type: enhancement - behavior versions: +Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13667 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13667] __contains__ method behavior
Changes by João Bernardo jbv...@gmail.com: -- type: behavior - enhancement ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13667 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13667] __contains__ method behavior
João Bernardo jbv...@gmail.com added the comment: I see that every other comparison operator (, , =, =, ==, !=) except for `is` work the way I expect and is able to return anything. e.g. numpy.arange(5) 3 array([ True, True, True, False, False], dtype=bool) I didn't checked the code (and probably I'm talking nonsense), but seems like the `in` operator has an extra call to `PyObject_IsTrue` that maybe could be dropped? Of course it can break code relying on `x in y` being True/False but it would only happen on customized classes. Another option that won't break code is to add a different method to handle these cases. Something like __contains_non_bool__, but that'd be a big api change. -- components: -Documentation ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13667 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13667] __contains__ method behavior
João Bernardo jbv...@gmail.com added the comment:
Using my poor grep abilities I found that on Objects/typeobject.c
(I replaced some declarations/error checking from the code with ...)
static int
slot_sq_contains(PyObject *self, PyObject *value) {
...
func = lookup_maybe(self, __contains__, contains_str);
if (func != NULL) {
...
res = PyObject_Call(func, args, NULL);
...
if (res != NULL) {
result = PyObject_IsTrue(res);
Py_DECREF(res);
}
}
else if (! PyErr_Occurred()) {
/* Possible results: -1 and 1 */
result = (int)_PySequence_IterSearch(self, value,
PY_ITERSEARCH_CONTAINS);
}
}
I don't know if I'm in the right place, but the function returns `int` and
evaluates the result to 1 or 0 if __contains__ is found.
I also don't know what SQSLOT means, but unlike the other operators (which are
defined as TPSLOT), `slot_sq_contains` is a function returning int while
`slot_tp_richcompare` returns PyObject *.
Why is that defined that way?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13667
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13667] __contains__ method behavior
João Bernardo jbv...@gmail.com added the comment: The problem with `not in` is because it must evaluate the result. It's not just another operator like == and !=. Looks like we're suffering from premature optimization and now it would break a lot of code to make it good. For my application, I created a different method to generate the object (Not as good as I wanted, but there's no option right now): `MyClass().has(1)` instead of `1 in MyClass()` So, if no one comes up with a better idea, this issue should be closed. Thanks -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13667 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13290] get vars for object with __slots__
João Bernardo jbv...@gmail.com added the comment:
Oh, sorry for the full file. Yes, I only changed after
d = PyObject_GetAttrString(v, __dict__);
if (d == NULL) {
I was searching for uses of slots other than __slots__ = (a, b) and I saw a guy
saying that dicts may have special meaning the future. So, something like
__slots__ = {'my_var': int}
could be an annotation (or hint for IDE's). In the present implementation, the
value of each key is just ignored.
If slots is just a_single_string it should not be treated as an iterable, so
I used PyUnicode_Check because I didn't knew a better method.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13290
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13290] get vars for object with __slots__
New submission from João Bernardo jbv...@gmail.com:
I just realized the builtin function `vars` can't handle custom objects without
the __dict__ attribute.
It would be nice if it worked with objects that have __slots__ to make them
look more like normal objects and to make debugging easier.
I changed the source of Python/bltinmodule.c to accept this new case, but, as
I'm fairly new to the C API, it may not be much good.
I'm attaching the whole file to this Issue and the `builtin_vars` function was
modified (lines 1859 to 1921) to work with:
__slots__ = ('a', 'b', 'c')
__slots__ = 'single_name'
__slots__ = {'some': 'mapping'}
The output is a dict (just like in the __dict__ case).
#Example
class C:
__slots__ = ['x', 'y']
c = C()
c.x = 123
vars(c)
{'x': 123}
--
components: Interpreter Core
files: bltinmodule.c
messages: 146598
nosy: JBernardo
priority: normal
severity: normal
status: open
title: get vars for object with __slots__
type: feature request
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file23546/bltinmodule.c
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13290
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13153] IDLE crash with unicode bigger than 0xFFFF
João Bernardo jbv...@gmail.com added the comment: Just for comparison, on Python 2.7.1 (x32 on Windows 7) it's possible to paste the char (but can't use it) and a nice error is given. u'Ң' Unsupported characters in input So the problem was partially solved but something might have happened with the 3.x port... Searching on both source codes, I can see the following block was commented on Python3.2 but not on Python2.7 (Maybe someone removed someone else's bug fix?) and an `assert` was added. #--- Lines 605 to 613 of PyShell.py assert isinstance(source, str) # v-- on Python2.7 it is types.UnicodeType instead #if isinstance(source, str): #from idlelib import IOBinding #try: #source = source.encode(IOBinding.encoding) #except UnicodeError: #self.tkconsole.resetoutput() #self.write(Unsupported characters in input\n) #return I uncommented those lines, removed the `assert` and deleted __pycache__ for fresh bytecode but the error keeps happening. This function `runsource()` is only called after the return key is pressed so the bug was introduced on another part of the program. I'll search further but it's hard to do that without traceback of the error. (Maybe `runit()` is the problem because it seems to build the line and call `runsource(line)`) -- PS: @Terry Reedy That looks nice to have different lengths for chars but what will be the impact on performance? Indexing will still be in constant time? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13153 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13153] IDLE crash with unicode bigger than 0xFFFF
João Bernardo jbv...@gmail.com added the comment: Just to complete my monologue: Here's the traceback from running IDLE in cmd line. C:\Python32\Lib\idlelibpython -i idle.py Traceback (most recent call last): File idle.py, line 11, in module idlelib.PyShell.main() File C:\Python32\Lib\idlelib\PyShell.py, line 1429, in main root.mainloop() File C:\Python32\Lib\tkinter\__init__.py, line 1009, in mainloop self.tk.mainloop(n) UnicodeDecodeError: 'utf8' codec can't decode bytes in position 1-2: invalid continuation byte Not much meaningful but is better than nothing... Looks like some traceback is missing, and this one points to tkinter. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13153 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13153] IDLE crash with unicode bigger than 0xFFFF
New submission from João Bernardo jbv...@gmail.com: I was playing with some unicode chars on Python 3.2 (x64 on Windows 7), but when pasted a char bigger than 0x, IDLE crashes without any error message. Example (works fine): '\U000104a2' 'Ң' But, if I try to paste the above char, the window will instantly close. The interpreter uses 2-bytes per char (UTF-16) and I don't know if that's causing the problem (as side note, why don't the default Windows build uses 4-bytes char?). I can't check now with my Ubuntu install (UTF-32) if the problem persists. -- components: IDLE, Unicode, Windows messages: 145363 nosy: JBernardo priority: normal severity: normal status: open title: IDLE crash with unicode bigger than 0x versions: Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13153 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13153] IDLE crash with unicode bigger than 0xFFFF
João Bernardo jbv...@gmail.com added the comment: @Ned That looks like a bit different case. IDLE *can* print the char after you entered the '\U' version of it. It doesn't accept you to paste those caracters... -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13153 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12745] Python2 or Python3 page
New submission from João Bernardo jbv...@gmail.com: Since 2008 (as far as can remember) the Python Download page has a link to that web page: http://wiki.python.org/moin/Python2orPython3 I know it's been updated but it keeps saying the same thing since Python 3.0 was launched. Basically it says that Python 3 is awesome but please don't use it because not everything became compatible. (That's how a newcomer reads it). I've been using Python 3 as replacement of Python 2 since the launch of 3.1... And now I can't even write a Python 2 code without feeling a little sick. I pretty much think it's time to tell people to skip learning all that junk the dev team had to remove and start with something much nicer. Think about it. You'll not have to worry if list comprehensions/generator expressions are available, the conditional operator, the boolean type (and True and False as keywords), decorators, the ability of having `non local` variables, extended tuple unpacking etc etc etc. If nobody uses the next generation of the language, the developers won't port their code. If they don't port the code, no one can use it... tl;dr So I vote for a new page saying something like Python 3 is the way you should go and, if you can't run something, try asking the developer to port it or choose another tool BTW, Those PyPI modules that haven't made any effort to port should be marked as `deprecated`, but that doesn't have anything to do with the change of the aforementioned web page. --- Sorry if that doesn't belong to a bug report and erase it if you want. -- assignee: docs@python components: Documentation messages: 142004 nosy: JBernardo, docs@python priority: normal severity: normal status: open title: Python2 or Python3 page versions: Python 3.2, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12745 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12538] Extending int class
New submission from João Bernardo jbv...@gmail.com: I'm having trouble subclassing the int type and I think this behavior is a bug... (Python 3.2) class One(int): def __init__(self): super().__init__(1) one = One() one + 2 2 one == 0 True I know `int` objects are immutable but my `One` class should be mutable... and why it doesn't raise an error? That gives the same result on Python 2.7 using super properly. Also, if that's not a bug, how it should be done to achieve one + 2 == 3 without creating another attribute. Things I also tried: self.real = 1 #readonly attribute error int.__init__(self, 1) #same behavior I Couldn't find any related issues... sorry if it's repeated. -- components: Interpreter Core messages: 140161 nosy: JBernardo priority: normal severity: normal status: open title: Extending int class type: behavior versions: Python 2.7, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12538 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12438] IDLE problem displaying warning message
João Bernardo jbv...@gmail.com added the comment: @orsenthil My system is Ubuntu 11.04 x64. To run idle, i press the Super (windows button) then write idle. If I open the terminal and type idle, the problem don't appear but I have to type the password on the terminal rather than on idle GUI. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12438 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12438] getpass error on idle
New submission from João Bernardo jbv...@gmail.com: The getpass function is raising an error when first used on idle (Python 3.2 and 2.7.1) The next time it'll work as expected (it echoes the data, but idle is just for testing purposes so no problems here) from getpass import getpass p = getpass() Traceback (most recent call last): File pyshell#1, line 1, in module p = getpass() File /usr/lib/python3.2/getpass.py, line 55, in unix_getpass passwd = fallback_getpass(prompt, stream) File /usr/lib/python3.2/getpass.py, line 114, in fallback_getpass stacklevel=2) File /usr/lib/python3.2/idlelib/PyShell.py, line 62, in idle_showwarning lineno, file=file, line=line)) TypeError: idle_formatwarning() got an unexpected keyword argument 'file' p = getpass() Warning: Password input may be echoed. Password: ok p 'ok' Looking at the /usr/lib/python3.2/idlelib/PyShell.py file the idle_formatwarning function don't have the file argument so it should be revomed from the function call at line 61: file.write(warnings.formatwarning(message, category, filename, lineno, file=file, line=line)) -- components: IDLE messages: 139385 nosy: JBernardo priority: normal severity: normal status: open title: getpass error on idle type: crash versions: Python 2.7, Python 3.1, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12438 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11658] complex sqrt error
New submission from João Bernardo jbv...@gmail.com: With Python 3, the ** operator is supposed to do math with complex numbers, but look what is happening: Python 3.2 (r32:88445, Feb 20 2011, 21:30:00) [MSC v.1500 64 bit (AMD64)] on win32 Type copyright, credits or license() for more information. (-1)**.5 (6.123233995736766e-17+1j) import cmath cmath.sqrt(-1) 1j pow(-1, .5) (6.123233995736766e-17+1j) (-4)**.5 (1.2246467991473532e-16+2j) I also tried with Python 3.1.2 in my 32-bit Ubuntu 10.10 installation and got the same results. The error seems to be in the floating point (double) representation limit of 16 decimal places. -- components: None messages: 131951 nosy: JBernardo priority: normal severity: normal status: open title: complex sqrt error type: behavior versions: Python 3.1, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11658 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
