[issue32683] isinstance is calling ob.__getattribute__ as a fallback instead of object.__class__.__get__
Steven D'Aprano added the comment: I agree that the rules regarding type and `__class__` and isinstance are not clear or well documented. We have: https://docs.python.org/3/library/stdtypes.html#instance.__class__ https://docs.python.org/3/library/functions.html#isinstance but neither discuss the interaction between a class' "real" type and it's "fake" type. To be honest, I'm not even sure I fully understand the interaction myself, or how they combine with virtual subclasses. A lot of my information comes from this Stackoverflow post: https://stackoverflow.com/questions/1060499/difference-between-typeobj-and-obj-class and in particular this comment: "Some code does this deliberately to lie about the type of objects, such as weakref.proxy. Some people think obj.__class__ should be preferred, because it believes the lie, while some people think type(obj) should be preferred because it ignores the lie. isinstance will return true if an object's real class or its lie class is an instance of the second argument." So I think that the behaviour here is correct, but it is not documented well and we should fix that. What I think happens: * type(obj) always and only returns the actual internal (C-level) type of the object, guaranteed to be a type object. * isinstance(obj, classinfo) returns True if any of the following hold: - the type() of object is a subclass of any of the classes in the classinfo object (a class, a Union of classes, or a tuple of classes); - obj.__class__ is a subclass of any of the classes in classinfo; - or obj is registered as a virtual subclass of any of the classes in classinfo, by calling type(ob).__subclasshook__; * obj.__class__ is determined using the normal attribute lookup mechanism, which means it does not have to be a static attribute but can be dynamically generated using properties, __getattr__, __getattribute__ or any other similar mechanism. And for the avoidance of doubt, a class is always considered a subclass of itself. I'm really not sure about the interaction with virtual subclasses, I probably have that bit wrong. And it is not clear to me what happens if __class__ is a non-type object. It seems to be permitted. Improving the documentation would be excellent. -- ___ Python tracker <https://bugs.python.org/issue32683> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32683] isinstance is calling ob.__getattribute__ as a fallback instead of object.__class__.__get__
Steven D'Aprano added the comment: On Fri, Dec 10, 2021 at 12:03:15AM +, Gabriele N Tornetta wrote: > class Side(object): > def __getattribute__(self, name): > ValueError(name) You forgot to actually *raise* the exception. That will just instantiate the ValueError instance, and then immediately garbage collect it. In any case, type() and isinstance() do not work the same way. type() does not inspect the `__class__` attribute. -- ___ Python tracker <https://bugs.python.org/issue32683> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32683] isinstance is calling ob.__getattribute__ as a fallback instead of object.__class__.__get__
Steven D'Aprano added the comment:
The plot thickens.
I was wrong to say that type() always and only looks at the "real" underlying
type of the instance. type() does look at __class__ as well. But only sometimes.
>>> class A:
... __class__ = int
...
>>> type(A())
>>> a = A()
>>> a.__class__ = int
>>> type(a)
So from A, we might think that type() ignores __class__
>>> class B:
... pass
...
>>> type(B()) # no __class__ to inspect
>>> b = B()
>>> b.__class__ = int
Traceback (most recent call last):
File "", line 1, in
TypeError: __class__ assignment only supported for mutable types or ModuleType
subclasses
How very odd. But okay, let's try something else:
>>> b.__class__ = A # lie that this is an A not a B
>>> type(b)
So now type() *does* inspect __class__, and believes it.
If we generate the __class__ attribute dynamically with __getattr__, the method
doesn't even get called. But if we use __getattribute__:
>>> class C:
... def __getattribute__(self, name):
... print('C getattribute:', name)
... if name == '__class__':
... return int
... raise AttributeError
...
>>> C().__class__
C getattribute: __class__
>>> type(C())
type() ignores the dynamically generated __class__. But isinstance does not:
>>> isinstance(C(), int)
C getattribute: __class__
True
The same applies if we use property:
>>> class D:
... @property
... def __class__(self):
... return int
...
>>> type(D())
>>> isinstance(D(), int)
True
So the rules appear to be:
- you can set __class__, but only sometimes;
- type() will believe __class__, but only sometimes;
- you can generate __class__ dynamically, but not with __getattr__;
- isinstance() will believe __class__ (always?);
- and there is no indication of how much of this is deliberate language feature
and how much is an accident of implementation.
--
___
Python tracker
<https://bugs.python.org/issue32683>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23522] Misleading note in Statistics module documentation
Steven D'Aprano added the comment: Prompted by Guido's reopening of the ticket, I have given it some more thought, and have softened my views. Jake if you're still around, perhaps there is more to what you said than I initially thought, and I just needed fresh eyes to see it. Sorry for being so slow to come around. People may be less likely to wrongly imagine there is a single centre location of data if we use the term "central tendency" instead of location. I think we should also drop the reference to mode(), since it only works with discrete data and is not suitable for continuous data. "The mean is strongly affected by outliers and is not necessarily a typical example of the data points. For a more robust, although less efficient, measure of central tendency, see median()" How do we feel about linking to Wikipedia? I'd like to link both outliers and central tendency to the appropriate Wikipedia entries. -- stage: resolved -> versions: +Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9 -Python 3.4 ___ Python tracker <https://bugs.python.org/issue23522> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46112] PEP 8 code format
Steven D'Aprano added the comment: > not complied with the PEP-8 formatting. PEP 8 says: "Some other good reasons to ignore a particular guideline: 3. Because the code in question predates the introduction of the guideline and there is no other reason to be modifying that code." So PEP 8 itself tells us that legacy code that ignores the style guidelines is already compliant with PEP 8. -- nosy: +steven.daprano ___ Python tracker <https://bugs.python.org/issue46112> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46153] function fails in exec when locals is given
Steven D'Aprano added the comment:
The function you use in exec is not a closure. The function:
def f():
return a
does not capture the top-level variable "a", it does a normal name lookup for
a. You can check this yourself by looking at f.__closure__ which you will see
is None. Or you can use the dis module to look at the disassembled bytecode.
To be a closure, you have to insert both the "a" and the `def f()` inside
another function, and then run that:
code = """
def outer():
a = 1
def f():
return a
return f
f = outer()
print(f())
"""
exec(code, {}, {})
prints 1 as expected.
--
components: +Interpreter Core
nosy: +steven.daprano
title: closure fails in exec when locals is given -> function fails in exec
when locals is given
type: crash -> behavior
___
Python tracker
<https://bugs.python.org/issue46153>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46153] function fails in exec when locals is given
Steven D'Aprano added the comment:
Here is the key phrase in the docs:
"If exec gets two separate objects as globals and locals, the code will be
executed as if it were embedded in a class definition."
https://docs.python.org/3/library/functions.html#exec
And sure enough:
>>> class C:
... a = 1
... def f():
... return a # This looks for global a, not C.a
... print(f())
...
Traceback (most recent call last):
File "", line 1, in
File "", line 5, in C
File "", line 4, in f
NameError: name 'a' is not defined
which is intentional behaviour. Functions defined inside a class do not have
direct access to the variables inside the class. I thought there was a FAQ
about this but I can't find it now.
So there is no bug here. By passing two distinct dicts as the globals and
locals to exec, the interpreter treats the code as if it were being executed
inside the body of a class statement. Both the a and the f get created in the
locals dict, not the globals dict:
>>> g = {'__builtins__': None}
>>> l = {}
>>> exec("""a = 1
... def f():
... return a
... """, g, l)
>>> g
{'__builtins__': None}
>>> l
{'a': 1, 'f': }
But when you call f(), it is looking for a in the globals dict.
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue46153>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46153] function fails in exec when locals is given
Steven D'Aprano added the comment:
> I now want to define a closure with exec. I might want to do something like:
> exec("def f(): return a", globals(), locals())
That doesn't create a closure.
> I would expect f() to look for a in the locals().
I'm sorry, but your expectation that f() will look for a in the locals dict is
not correct. That's not how name resolution in Python works. a is looked up as
a global. You can't turn it into a local variable just by providing locals.
The names of the parameters are unfortunately confusing. The globals parameter
is always the global namespace. But locals is *never* the function's local
namespace. Nor is it a surrounding scope (nested functions), but it may be
treated as a surrounding *class* scope.
I agree that the behaviour is surprising and complex, but if you work through
the documentation carefully, it is behaving as designed.
What we need to realise is that locals describes the namespace where the *def
statement* runs, not the namespace used by the body of the function. The
function body's locals is always created when the function is called, it is
inaccessible from outside the function, and it most certainly does not use the
so-called "locals" parameter given to exec().
--
___
Python tracker
<https://bugs.python.org/issue46153>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46153] function fails in exec when locals is given
Steven D'Aprano added the comment: "Expected" is a strong word. It took me a lot of careful reading of the documentation and experimentation to decide that, yes, I expect the second case to fail when the first case succeeds. Which reminds me of a common anecdote from mathematics: https://hsm.stackexchange.com/questions/7247/in-a-popular-anecdote-who-took-20-minutes-to-decide-that-a-thing-was-obvious -- ___ Python tracker <https://bugs.python.org/issue46153> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46153] function fails in exec when locals is given
Steven D'Aprano added the comment: On Thu, Dec 23, 2021 at 12:15:29AM +, Eryk Sun wrote: > > Eryk Sun added the comment: > > > If exec gets two separate objects as globals and locals, > > the code will be executed as if it were embedded in a > > class definition. > > That's a misleading comparison That's taken straight out of the documentation. I don't think it is misleading, it is the opposite of misleading. Until I understood that exec with two different mapping objects as globals and locals behaves as if the code where embedded inside a class, I found the reported behaviour totally perplexing. If you think it is wrong, how would you explain the observed behaviour, and how would you word the documentation? > because a class definition intentionally supports nonlocal closures, I don't know what you mean by that. Classes are never closures. Only functions can be closures. (*Be* closures? *Have* a closure? The terminology is ambiguous.) >>> def f(): ... a = 1 ... class C: ... nonlocal a ... a = 999 ... print(a) ... return C ... >>> C = f() 999 >>> C.__closure__ Traceback (most recent call last): File "", line 1, in AttributeError: type object 'C' has no attribute '__closure__'. Did you mean: '__module__'? I don't know what terminology is appropriate here, but "closure" is surely not it. > which exec() doesn't support and shouldn't support. For example: [snip examples] Neither of those cases are relevant to the example here. > exec() executes as module code. Using separate globals and locals > mappings doesn't magically change how the code is compiled and > executed to make it equivalent to a class definition. Neither I nor the documentation said it was equivalent to a class definition. It is equivalent to code executed inside a class scope. > To understand > the case of separate globals and locals, just remember that assigning > to a variable by default makes it a local variable, unless it's > declared as a global. Also, class and function definitions are > implicitly an assignment, which by default will be local. Neither of those facts explain why the example code """a = 1 def f(): return a print(f()) """ behaves differently when given two distinct dicts as the globals and locals parameters, versus all the other cases (no arguments provided, or one argument, or the same dict repeated twice). Only the case where the provided globals and locals dicts are distinct behaves differently, and it behaves exactly the same as if you embedded that chunk of code inside a class definition and then executed it. -- ___ Python tracker <https://bugs.python.org/issue46153> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46153] function fails in exec when locals is given
Steven D'Aprano added the comment:
On Thu, Dec 23, 2021 at 05:47:33AM +, Eryk Sun wrote:
>
> Eryk Sun added the comment:
>
> > That's taken straight out of the documentation.
>
> Yes, but it's still a misleading comparison.
I asked how you would re-word the docs, but you haven't responded.
The description given in the docs exactly explains the observed
behaviour. Without recognising that, the observed behaviour is
perplexing to the point that it suggested to at least one person that it
was a bug in the language.
If you're not prepared to suggest an improvement to the documentation,
then I don't think that this conversation is going anywhere and maybe
we should just let the discussion die.
But for the record, in case you, or anyone else, does want to continue
the discussion in the hope of reaching additional insight to the
problem, my further comments are below.
[...]
> Saying that code will be "executed as if it were embedded in a class
> definition" is correct only so far as the fact that globals and locals
> are different in this case.
So it's correct in all the ways that matter:
- different globals and locals;
- and the behaviour is different.
and incorrect in no ways at all (see below). I don't think that supports
a charge of "misleading".
The bottom line here is that the description in the docs that you call
"misleading" did not mislead me, but lead me directly to the solution of
why the code behaved as it did, and why that was the intentional
behaviour rather than a bug.
So un-misleading, if you will.
> But it's also misleading because the code
> gets compiled as module-level code, not as class code.
Obviously there is no actual "class code" involved. That is why the
description says that it is executed *as if* it were embedded inside a
class statement, rather than by having an actual class statement added
to your source string.
I don't understand your comment about "compiled as module-level ... not
as class code". What's class code? (Aside from the actual class
statement itself, which is a red herring.)
If you look at the disassembly of the following two snippets:
dis.dis("""
a = 1
def f():
return a
print(f())
""")
and
dis.dis("""
class C:
a = 1
def f():
return a
print(f())
""")
the generated bytecode for the lines `a = 1` etc is the same, putting
aside the code for the actual class statement part. You get the same
code for `a = 1`
LOAD_CONST(1)
STORE_NAME(a)
the same code for both the body of the function:
LOAD_GLOBAL (a)
RETURN_VALUE
and the `def f()` statement:
LOAD_CONST()
LOAD_CONST('f')
MAKE_FUNCTION
STORE_NAME
and the same code for the call to print:
LOAD_NAME(print)
LOAD_NAME(f)
CALL_FUNCTION
CALL_FUNCTION
POP_TOP
LOAD_CONST (None)
RETURN_VALUE
Obviously the offsets and locations of constants will be different, but
aside from those incidental details, the code generated for the block is
the same whether it is inside a class statement or not.
So I don't understand what you consider to be the difference between
code compiled at module-level and code compiled at class-level. They
seem to me to be identical (aside from the incidentals).
The visible difference in behaviour relates to the *execution* of the
code, not to whether (quote):
"the code gets compiled as module-level code [or] as class code".
There is no distinct "class code". The difference in behaviour is in the
execution, not to the compilation.
> It should be pretty obvious why the following fails:
>
> exec("a = 1\ndef f(): return a\nprint(f())", {}, {})
Yes, it is obvious why it fails, in the same sense as the maths joke
about the professor who stares at the equations on the blackboard for
twenty minutes before exclaiming "Yes, it is obvious!".
It takes a sophisticated understanding of Python's scoping rules to
understand why that fails when the other cases succeed.
> Assignment is local by default, unless otherwise declared. Function
> f() has no access to the local scope where `a` is defined
With the same dict used for globals and locals, execution runs the
statements `a = 1`, the `def f` and the print in the same scope, which
is *both* global and local. This is what happens when you run code at
the module level: locals is globals.
Consequently, the statement `a = 1` assigns a to the local namespace,
which is the global namespace. And the call to f() retrieves a from the
global namespace, which is the local
[issue46164] New `both()` operator for matching multiple variables to one
Steven D'Aprano added the comment: Just use if a == b == 1: Comparisons can be chained arbitrarily. https://docs.python.org/3/reference/expressions.html#comparisons -- nosy: +steven.daprano resolution: -> rejected stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46164> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46173] float(x) with large x not raise OverflowError
Steven D'Aprano added the comment: float(x) performs rounding. Only if the value after rounding is out of range is OverflowError raised. M + 1, when correctly rounded to the nearest even float, gives sys.float_info.max. Likewise for M+2, M+3 etc all the way to M+K where K equals 2**960 before the correctly rounded result of float(M+K) overflows. Anything less than K=2**960 is too small to be distinguished from M when added to it. So there's no bug here, the behaviour is correct for IEEE-754, although perhaps the documentation is misleading. Mark, is my explanation right? -- nosy: +mark.dickinson, steven.daprano ___ Python tracker <https://bugs.python.org/issue46173> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46183] float function errors on negative number string with comma seperator ex: '-1, 234.0'
Steven D'Aprano added the comment:
The behaviour is correct and not a bug. Commas are not supported when
converting strings to float.
The allowed format for floats as strings is described in the docs:
https://docs.python.org/3/library/functions.html#float
By the way, the negative sign is irrelevant. Commas are not supported
regardless of whether there is a negative sign or not.
The difficulty with commas is that it is ambiguous whether float('1,234')
should interpret the comma as British/American digit grouping separator, and
return 1234.0, or as the European decimal point, and return 1.234. For good or
bad, Python has a bias towards English (like most programming languages) and so
it chooses to only recognise the decimal point as a dot in the British/American
style, and reject the comma.
If you want to support European-style commas as the decimal point, the easiest
way is to call float('1,234'.replace(',', '.'))
--
nosy: +steven.daprano
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue46183>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46183] float function errors on negative number string with comma seperator ex: '-1, 234.0'
Steven D'Aprano added the comment:
Aside: for what it is worth, the British style with a middle dot is also not
supported: float('1·234') also raises ValueError.
--
___
Python tracker
<https://bugs.python.org/issue46183>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46188] dictionary creation error
Steven D'Aprano added the comment:
> I still can not figure out why the first two elements are inconsistent
from the rest of the dictionary, and why they appear in the first place.
Hi Tobias,
This is a bug tracker for reporting bugs in Python, not a help desk to ask for
explanations. The behaviour you see is correct. Except for the last line, which
is a copy-and-paste error on your part: the actual last line is
>>> dictionary
{0: None, None: None, 2: 2, 4: 4, 6: 6, 8: 8}
So there is no error here, everything is working as expected.
If you need help understanding why the code is correct, please take the
discussion to the Python Discuss forum where you will be sure to get answers.
--
nosy: +steven.daprano
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue46188>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46199] Calculation influenced by print
Steven D'Aprano added the comment: Please try to provide a minimal reproducible example: https://stackoverflow.com/help/minimal-reproducible-example http://sscce.org/ At the very least, you need to provide three pieces of information: 1. What you tried. 2. What you expected to happen (and why, if it isn't obvious). 3. What actually happened instead. Ideally you should be able to get your example down to using one or two values, not three lists with 30 values each (90 values). -- nosy: +steven.daprano ___ Python tracker <https://bugs.python.org/issue46199> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46213] webbrowser.open doesn't work in Termux
Steven D'Aprano added the comment: I think the existence of sys.getandroidapilevel is evidence that Android is somewhat supported, even if it is not supported to the same degree that Linux and Windows are. https://docs.python.org/3/library/sys.html#sys.getandroidapilevel See also: https://mail.python.org/pipermail/python-dev/2017-December/151171.html for a longer discussion. There's an Android build factory https://github.com/python/buildmaster-config/pull/26 but I cannot see an official Android buildbot running. https://buildbot.python.org/all/#/ The PR seems straightforward and simple to me, but I'm not an expert on the webbrowser module nor do I have an Android where I can test it to see if it works. DonaldDuck1313, your NEWS entry needs to be re-written to use ReST (Restructured Text) rather than Markdown: Change: [Termux](https://termux.com/) to `Termux <https://termux.com/>`_ -- nosy: +steven.daprano, xdegaye type: -> enhancement ___ Python tracker <https://bugs.python.org/issue46213> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46282] print() docs do not indicate its return value
New submission from Steven D'Aprano : Do the print docs need to mention something so obvious? Functions and methods which operate by side-effect typically don't mention that they return None, see for example the docs for various builtin methods: https://docs.python.org/3/library/stdtypes.html#mutable-sequence-types e.g. s.append, s.clear, s.extend, s.insert, s.remove, s.reverse and likewise for list.sort, set.add, dict.clear and many others. (However, dict.update is a rare exception, it does mention that it returns None.) We should not feel it necessary to add an explicit comment to every function or method that operates by side-effect stating that they return None. -- nosy: +steven.daprano ___ Python tracker <https://bugs.python.org/issue46282> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46282] print() docs do not indicate its return value
Steven D'Aprano added the comment:
Sure, there will always be some users who will find certain things not
obvious. Sometimes I'm that user myself.
What did this user think print() returned? What precisely was their
question? Perhaps if I saw the conversation in context, I would be more
sympathetic to this.
I can see a difference between (for example) the questions:
"I see that print('Hello world') returns None, but is it safe to assume
that print will *always* return None? It is not documented anywhere as
far as I can see."
and
"What does x = print('Hello world') do?"
--
___
Python tracker
<https://bugs.python.org/issue46282>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46293] Typo in specifying escape sequence
Steven D'Aprano added the comment: Serhiy is correct. The table is correct, \n can be found further down the table, the first entry is backslash newline, as it says. -- nosy: +steven.daprano resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46293> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46302] IndexError inside list comprehension + workaround
Steven D'Aprano added the comment: > it returns IndexError (instead of "u") if used in a list comprehension Works as expected inside a list comprehension: >>> var = "u2" >>> [var.strip()[0] for i in range(2)] ['u', 'u'] >>> ["ok" for i in range(2) if var.strip()[0] == "u"] ['ok', 'ok'] I am 99.99% certain that you have a bug in your code, but your code is so complicated that it is not obvious at a glance where the bug is. I am strongly tempted to just close this as "Works for me" and tell you to come back and re-open the bug report when you have isolated the issue to a simpler case, but I will resist the temptation for now. -- nosy: +steven.daprano ___ Python tracker <https://bugs.python.org/issue46302> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46302] IndexError inside list comprehension + workaround
Steven D'Aprano added the comment:
Your functions test1 and test2 are irrelevant to the bug report. The driver
code using eval() to pick which function to call is unneeded. The business of
simulating a file is complexity for no purpose.
Those ignore, count, unique functions are also irrelevant.
Removing all the irrelevant and extraneous complexity that obfuscates the
problem, we get to two lines of simplified code sufficient to demonstrate the
issue:
each = "name = "
[code.strip()[0] for func, code in [each.split('=')]]
which sure enough raises IndexError.
The hint was looking at your fix() function, which made it clear that you are
getting an IndexError because the string is an empty string. Well of course you
do, that is expected behaviour.
Why do you get an empty string? Because you split the line "name = " on the
equals sign, giving
func = "name "
code = " "
then you strip the whitespace from code giving:
code = ""
then you try to extract the first character of code using code[0], which raises
IndexError, because that's what it is supposed to do.
So there is no bug here, Python is working correctly.
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue46302>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46324] 'import traceback' Causes a Crash
Steven D'Aprano added the comment: Your module token.py "shadowed" the stdlib token.py, and prevented it from being seen until you changed the name. -- nosy: +steven.daprano resolution: -> not a bug stage: -> resolved status: open -> closed type: crash -> behavior ___ Python tracker <https://bugs.python.org/issue46324> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46349] inspect.getdoc() should append parent class method docs when encountering a local one line docstring
Steven D'Aprano added the comment: Many docstrings are only 1 line without being "See base class." And many docstrings are multiple lines while also referring the reader to see the parent class for further details. So this DWIM heuristic to guess whether or not to display a parent class docstring will have a lot of both false positives and false negatives. The false negatives just revert to the status quo, but the false positives will be annoying. I am leery of DWIM code. The reader should be capable of recognising that sort of message and calling up help for that class, so I think the benefit here is minimal and the failures common. But if we do go ahead with this, I have a style issue. At the moment, getdoc shadows `object`, for no good purpose. (I'm fine with shadowing builtins if there is a good reason.) This is a minor issue that is not worth fixing on its own, but if you do end up touching getdoc to implement this, could you please remove the unnecessary shadowing? If we can call the function "get *doc*" we can call the parameter *obj* :-) -- nosy: +steven.daprano ___ Python tracker <https://bugs.python.org/issue46349> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46350] re.sub, re.Match.expand, etc doesn't allow x, u, U, or N escapes in the template
Steven D'Aprano added the comment:
It is better to raise each issue in its own ticket.
You seem to have three distinct issues here:
- The issue listed in the title, which I don't understand. A demonstration of
the issue would be helpful.
- The unrelated(?) issue of bad \N{} escapes, which appears to have nothing to
do with regexes, but maybe I'm wrong? In any case, whether this is regular
expressions or plain old strings, it seems reasonable to me to limit \N{} to
ASCII-only (Unicode guarantees that code point names are ASCII) and some
reasonable length. I can't imagine the Unicode consortium ever deciding on a
name > 255 characters, it wouldn't be practical.
- The difference in normalisation between group names and identifiers.
--
nosy: +steven.daprano
___
Python tracker
<https://bugs.python.org/issue46350>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46354] AttributeError: module 'collections' has no attribute 'Mapping'
Steven D'Aprano added the comment: Hi mareklachbc, What makes you think that this is a bug? Since at least version 3.7, you will have seen this warning: >>> import collections >>> collections.Mapping __main__:1: DeprecationWarning: Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated since Python 3.3,and in 3.9 it will stop working So this is not a bug. -- nosy: +steven.daprano stage: -> resolved status: pending -> closed ___ Python tracker <https://bugs.python.org/issue46354> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46365] _ curses module is not installed
Steven D'Aprano added the comment: Did you look in setup.py in detect_modules() for the module's name to see what was missing? How do you know the curses dependencies have been installed? What dependencies did you install? -- nosy: +steven.daprano ___ Python tracker <https://bugs.python.org/issue46365> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46385] Remove parenthetical symbols for readability and nlp
Steven D'Aprano added the comment: Dennis beat me to it in saying that tuples cannot be replaced by lists. But I also wanted to say that it is *not true* that removing bracket symbols would increase readability. Natural language allows parenthetical phrases -- which can be bracketed using dashes (or with parentheses [commonly called round brackets in the British commonwealth]) or even commas -- so even in natural language they are used. Even programming languages which are much, much closer to natural language than Python, like Hypertalk and Inform-7, use parentheses and delimiters for various purposes, for example: http://inform7.com/book/WI_21_3.html Ultimately, we simply can't remove brackets (square, round or curly) from the language. It would make it impossible to tell whether func(1, 2, 3, 4, 5) was a call to func() with 5 integer arguments, or a single 5-element list argument, or two 2-element lists and an integer, or three integers and a 2-element list, etc. So don't waste your time taking this proposal to Python-Ideas. -- nosy: +steven.daprano ___ Python tracker <https://bugs.python.org/issue46385> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46385] Remove parenthetical symbols for readability and nlp
Steven D'Aprano added the comment: Please don't reopen this issue. If you really want to take it to the Python-Ideas mailing list, you can: https://mail.python.org/mailman3/lists/python-ideas.python.org/ or to Discuss: https://discuss.python.org/c/ideas/6 -- status: open -> closed ___ Python tracker <https://bugs.python.org/issue46385> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46393] Generate frozenset constants when explicitly appropriate
Steven D'Aprano added the comment:
The difficulty is that frozenset may have been shadowed, or builtins
monkey-patched, so we cannot know what frozenset({1, 2, 3}) will return until
runtime.
Should we re-consider a frozenset display literal?
f{1, 2, 3}
works for me.
--
nosy: +steven.daprano
___
Python tracker
<https://bugs.python.org/issue46393>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46393] Generate frozenset constants when explicitly appropriate
Steven D'Aprano added the comment: Proposed on Python-Ideas. https://mail.python.org/archives/list/python-id...@python.org/message/GRMNMWUQXG67PXXNZ4W7W27AQTCB6UQQ/ -- ___ Python tracker <https://bugs.python.org/issue46393> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46393] Generate frozenset constants when explicitly appropriate
Steven D'Aprano added the comment:
That's not always the case though.
>>> def f():
... return frozenset({1, 2, 3})
...
>>> a = f.__code__.co_consts[1]
>>> a
frozenset({1, 2, 3})
>>> b = f()
>>> assert a == b
>>> a is b
False
Also see the disassembly I posted on Python-Ideas.
--
___
Python tracker
<https://bugs.python.org/issue46393>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46466] help function reads comments
Steven D'Aprano added the comment: That's not a bug. https://docs.python.org/3/library/pydoc.html "If there is no docstring, pydoc tries to obtain a description from the block of comment lines just above the definition of the class, function or method in the source file, or at the top of the module (see inspect.getcomments())." -- nosy: +dam1784, steven.daprano resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46466> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46467] Rounding 5, 50, 500 behaves differently depending on preceding value
Steven D'Aprano added the comment: As documented, this is not a bug. "if two multiples are equally close, rounding is done toward the even choice" https://docs.python.org/3/library/functions.html#round This is also called "Banker's Rounding" or "Round half to even" and for rounding many values, it minimizes the expected total rounding error. https://en.wikipedia.org/wiki/Rounding#Round_half_to_even -- nosy: +steven.daprano resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46467> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46612] Unclear behavior of += operator
Steven D'Aprano added the comment: You say: "The documentation says ..." but don't tell us which documentation. This documentation: https://docs.python.org/3/reference/simple_stmts.html#augmented-assignment-statements tells us that augmented assignment is assignment: "An augmented assignment evaluates the target (which, unlike normal assignment statements, cannot be an unpacking) and the expression list, performs the binary operation specific to the type of assignment on the two operands, and assigns the result to the original target." And also: "the assignment done by augmented assignment statements is handled the same way as normal assignments." -- nosy: +steven.daprano ___ Python tracker <https://bugs.python.org/issue46612> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46639] Ceil division with math.ceildiv
Steven D'Aprano added the comment: I don't understand why math.ceildiv couldn't ducktype. There's no rule that says it *must* convert arguments to float first, that's just a convention, and we've broken it before. >>> math.prod([Fraction(1, 3), 7]) Fraction(7, 3) Couldn't math.ceildiv(x, y) be implemented as -(-x//y) in a type-agnostic fashion? Perhaps it is too late in the night for me, but I have no idea what ceilrem(x, y) would do or why anyone might want it. I agree with Vladimir that the import thing is not an issue. If we can require an import for much more important functions as sin, cos, tan, log, etc, then requiring an import is not excessive for a function of secondary importance. Feature-bloat: its taken 30 years for somebody to request ceildiv. At that rate, it will take another 500 years for us to catch up to mpz in terms of features/bloat. I'm not losing sleep over that :-) -- nosy: +steven.daprano ___ Python tracker <https://bugs.python.org/issue46639> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46639] Ceil division with math.ceildiv
Steven D'Aprano added the comment: Decimal is a good question. Why does floor division not do floor division on Decimal? The documentation says The integer division operator // behaves analogously, returning the integer part of the true quotient (truncating towards zero) rather than its floor, so as to preserve the usual identity x == (x // y) * y + x % y but it's not clear why that identity is more important than floor division returning the floor. I guess we could just document the difference and maybe add a Decimal ceildiv method, although that makes me sad :-( Could we "fix" Decimal? -- ___ Python tracker <https://bugs.python.org/issue46639> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39805] Copying functions doesn't actually copy them
Steven D'Aprano added the comment: If we can't change the default behaviour of copying functions, can we add a specialised copy_function() function, for when we really need to make a genuine copy? -- ___ Python tracker <https://bugs.python.org/issue39805> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46766] Add a class for file operations so a syntax such as open("file.img", File.Write | File.Binary | File.Disk) is possible.
Steven D'Aprano added the comment:
I'm sorry, I don't see why you think this will improve code readability. I also
expect it will be harder to teach than the current code.
open("file.img", "wb") just needs the user to learn about reading and writing
files, and the difference between binary and text files. It works the same way
in probably dozens of different languages.
open("file.img", File.Write | File.Binary | File.Disk) needs the beginner to
learn the same details, *plus* they have to learn about this mystery File
object, classes, dot notation, `|` the bitwise-or operator, and how to import
File from the io module.
My guess is that File.Write etc are just enums equivalent to strings 'w' and
'b', but what's File.Disk?
What else does this File object do?
--
nosy: +steven.daprano
___
Python tracker
<https://bugs.python.org/issue46766>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46766] Add a class for file operations so a syntax such as open("file.img", File.Write | File.Binary | File.Disk) is possible.
Steven D'Aprano added the comment: True, but you did say it would be with the io module in your original suggestion. -- ___ Python tracker <https://bugs.python.org/issue46766> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46776] RecursionError when using property() inside classes
Steven D'Aprano added the comment: This is not a bug, Python is working correctly here. The interpreter is doing exactly what you told it to do, and then raising a RecursionError before you can crash the system. You have a property instance.bar which returns instance.bar, which returns instance.bar, which returns instance.bar... forever, or until RecursionError is triggered. Your class is the same as: class Foo: @property def bar(self): return self.bar So when you call instance.bar, it looks up bar, which is the property, which looks up bar, which is the property, which looks up bar, and so on. What did you expect to happen? -- nosy: +steven.daprano resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46776> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46776] RecursionError when using property() inside classes
Steven D'Aprano added the comment: Maybe you expected to do this: class C: def __init__(self): self._value = 999 @property def bar(self): return self._value obj = C() obj.bar # returns 999 -- ___ Python tracker <https://bugs.python.org/issue46776> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46803] Item not shown when using mouse wheel to scroll for Listbox/Combobox
Steven D'Aprano added the comment: Replicated on Linux, Python 3.10. It looks like mousewheel scrolling jumps by the wrong amount as it pages down (or up), and consequently some lines never appear in the view area. I ran a slightly modified version of the code that had 16 entries instead of just seven. By default, just three entries are visible at a time. If we number the lines 1-16, and start with lines 1-3 visible, then we get: * Initial view: lines 1, 2, 3 visible, 4-16 below the view area. * Scrollwheel down. * Lines 6-8 visible, 1-5 above the view area, 9-16 below. * Scrollwheel down. * Lines 11-13 visible, 1-10 above the view area, 14-16 below. * Scrollwheel down. * Lines 14-16 visible, 1-13 above the view area. So the scrollwheel scrolls down by: 5 lines, 5 lines, 3 lines. Going back the otherway, the scrollwheel scrolls up by 5, 5, 3. Why five lines? My guess is that it might have something to do with 16//3 = 5. I don't know if this is something we can fix, or we're stuck with whatever tk/tcl does. I don't know if this is related, or should be a separate issue, but I see that the keyboard PageUp and PageDown keys don't scroll up or down by a page, but by a single line -- and they don't correctly highlight the selected line either. Paging should scroll up or down by N-1 lines, where N is the number of visible lines in the view area. Likewise for clicking in the scrollbar's PageUp/PageDown region, which also scrolls by a single line. -- nosy: +steven.daprano ___ Python tracker <https://bugs.python.org/issue46803> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46803] Item not shown when using mouse wheel to scroll for Listbox/Combobox
Change by Steven D'Aprano : -- Removed message: https://bugs.python.org/msg413566 ___ Python tracker <https://bugs.python.org/issue46803> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46803] Item not shown when using mouse wheel to scroll for Listbox/Combobox
Change by Steven D'Aprano : -- Removed message: https://bugs.python.org/msg413567 ___ Python tracker <https://bugs.python.org/issue46803> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46803] Item not shown when using mouse wheel to scroll for Listbox/Combobox
Change by Steven D'Aprano : -- Removed message: https://bugs.python.org/msg413568 ___ Python tracker <https://bugs.python.org/issue46803> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46803] Item not shown when using mouse wheel to scroll for Listbox/Combobox
Change by Steven D'Aprano : -- nosy: -xiaox55066 ___ Python tracker <https://bugs.python.org/issue46803> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46803] Item not shown when using mouse wheel to scroll for Listbox/Combobox
Change by Steven D'Aprano : Removed file: https://bugs.python.org/file50635/6.jpeg ___ Python tracker <https://bugs.python.org/issue46803> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46871] BaseManager.register no longer supports lambda callable 3.8.12+
Steven D'Aprano added the comment:
Works for me in Python 3.10.0 on Linux.
After running your code, I get shared_dict is a DictProxy:
>>> shared_dict
>>> list(shared_dict.items())
[('number', 0), ('text', 'Hello World')]
and shared_lock an AcquirerProxy object.
Please double-check that the code you posted is the actual code that is
failing, and copy and paste the full traceback you receive, not just a one-line
summary.
Even if the error is reproducible, I doubt that the cause is what you state in
the title of this issue:
BaseManager.register no longer supports lambda callable
Lambdas are just functions, they aren't a different type of callable. So the
register method cannot distinguish between a lambda argument written directly
in place, and a named def defined earlier then passed by name. So whatever
error might be happening on your system, I doubt it has anything to do with the
use of lambda syntax
--
nosy: +steven.daprano
___
Python tracker
<https://bugs.python.org/issue46871>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46882] Clarify argument type of platform.platform(aliased, terse) to boolean
Steven D'Aprano added the comment: > Both arguments `aliased` and `terse` should be boolean instead of integer. Why should they be strictly True/False booleans? I disagree strongly that they should be. Any object that duck-types as a true or false value is sufficient. Treated as a documentation change, your PR is wrong because it implies that *only* the singletons `True` and `False` are acceptable, when in fact any true and false (note the lowercase) values are acceptable. Personally, I prefer the terms "truthy" and "falsey", or "a true value" and "a false value" over a bare true/false, but some people do not, and it is a long-standing tradition in Python circles to understand lowercase true/false as the duck-typed values as opposed to the `True` and `False` bool singletons. -- nosy: +steven.daprano ___ Python tracker <https://bugs.python.org/issue46882> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46883] Add glossary entries to clarify the true/True and false/False distinction
New submission from Steven D'Aprano : There is a long-standing tradition, going back to Python 1.x days before we had dedicated True and False values, to use the lowercase "true" and "false" to mean *any value that duck-types as True* and *any value that duck-types as False* in a boolean context. Other terms for this same concept include "truthy/falsey" and using true/false as adjectives rather than nouns, e.g. "a true value". But I am not sure whether this is actually written down anywhere in the documentation. It would be useful for those who are not aware of the convention (e.g. beginners and people coming from other languages) if the Glossary had entries for lowercase "true" and "false" that explained the usage and referred back to PEP 285. See for example #46882 where this came up. I suggest something like the following: boolean context Code such as ``if condition:`` and ``while condition:`` which causes the expression ``condition`` to be evaluated as if it were a :class:`bool`. false Any object which evaluates to the :class:`bool` singleton ``False`` in a :term:`boolean context`. Informally known as "falsey". See :term:`true` and :pep:`285`. Among the builtins , false values include ``None``, empty containers and strings, and zero numbers. true Any object which evaluates to the :class:`bool` singleton ``True`` in a :term:`boolean context`. Informally known as "truthy". See :term:`false` and :pep:`285`. Among the builtins , true values include non-empty containers and strings, non-zero numbers (including NANs), and all other objects by default. -- assignee: docs@python components: Documentation messages: 414204 nosy: docs@python, steven.daprano priority: normal severity: normal status: open title: Add glossary entries to clarify the true/True and false/False distinction type: enhancement versions: Python 3.10, Python 3.11, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue46883> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46882] Clarify argument type of platform.platform(aliased, terse) to boolean
Steven D'Aprano added the comment: See #46883 -- ___ Python tracker <https://bugs.python.org/issue46882> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46883] Add glossary entries to clarify the true/True and false/False distinction
Steven D'Aprano added the comment: Note also that this is mentioned here: https://docs.python.org/3/library/stdtypes.html#boolean-values "[True and False] are used to represent truth values (although other values can also be considered false or true)." although it is perhaps not as clear as I would prefer. Also relevant is this: https://docs.python.org/3/library/stdtypes.html#truth-value-testing -- ___ Python tracker <https://bugs.python.org/issue46883> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46871] Lambda can't be pickled with "spawn" and only "fork"
Steven D'Aprano added the comment: > The "spawn" method requires pickling the data and callable passed to > the child proces, and that's not supported for lambda's. Ah, today I learned something. Kyle, looks like you were right about it being due to the lambdas. -- status: pending -> open ___ Python tracker <https://bugs.python.org/issue46871> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46871] Lambda can't be pickled with "spawn" and only "fork"
Steven D'Aprano added the comment: Oops, replying by email reopens the ticket. Back to pending you go! -- status: open -> pending ___ Python tracker <https://bugs.python.org/issue46871> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46923] Implement stack overflow protection for supported platforms
Steven D'Aprano added the comment: > Personally I'd prefer a new exception `StackOverflow` to `MemoryError` +1 on a new exception (presumably a subclass of MemoryError). How about using OverflowedStack instead? The situation is not quite as bad as you suggest. Googling for "stack overflow" alone (with a space and no other qualifications): * on Bing, scroll halfway down the first page of results to find the "People also ask..." How do you get a stack overflow? How to prevent a stack overflow error? * also on Bing at the bottom of the first page of results is a question on stackoverflow.com asking what causes memory stack overflows; * on DuckDuckGo, the first page of search results fails to suggest anything useful; * on Google itself, on the first page is the People Also Ask What causes stack overflows? * as well as a link to Wikipedia's page on stack overflows. I expect that going forward, "python stack overflow exception" will be sufficient to hit the Python docs somewhere on the first page. Besides, presumably this OverflowedStack exception is likely to be rare, so I expect that few people will need to google it. -- nosy: +steven.daprano ___ Python tracker <https://bugs.python.org/issue46923> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12790] doctest.testmod does not run tests in functools.partial functions
New submission from Steven D'Aprano : Functions with docstrings which were created with partial are not run by doctest.testmod(). See the test script, which prints: Expected 1 failure from 2 tests, but got 0 from 0. -- files: partial_doctest.py messages: 142512 nosy: stevenjd priority: normal severity: normal status: open title: doctest.testmod does not run tests in functools.partial functions type: feature request versions: Python 3.3 Added file: http://bugs.python.org/file22953/partial_doctest.py ___ Python tracker <http://bugs.python.org/issue12790> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2636] Regexp 2.7 (modifications to current re 2.2.2)
Steven D'Aprano added the comment: I'm not sure if this belongs here, or on the Google code project page, so I'll add it in both places :) Feature request: please change the NEW flag to something else. In five or six years (give or take), the re module will be long forgotten, compatibility with it will not be needed, so-called "new" features will no longer be new, and the NEW flag will just be silly. If you care about future compatibility, some sort of version specification would be better, e.g. "VERSION=0" (current re module), "VERSION=1" (this regex module), "VERSION=2" (next generation). You could then default to VERSION=0 for the first few releases, and potentially change to VERSION=1 some time in the future. Otherwise, I suggest swapping the sense of the flag: instead of "re behaviour unless NEW flag is given", I'd say "re behaviour only if OLD flag is given". (Old semantics will, of course, remain old even when the new semantics are no longer new.) -- nosy: +stevenjd ___ Python tracker <http://bugs.python.org/issue2636> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2636] Adding a new regex module (compatible with re)
Steven D'Aprano added the comment: Matthew Barnett wrote: > Matthew Barnett added the comment: > > I think I need a show of hands. > > Should the default be old behaviour (like re) or new behaviour? (It might be > old now, new later.) > > Should there be a NEW flag (as at present), or an OLD flag, or a VERSION > parameter (0=old, 1=new, 2=?)? I prefer Antoine's suggested spelling, COMPAT, rather than OLD. How would you write the various options? After the transition is easy: # Get backwards-compatible behaviour: compile(string, COMPAT) compile(string, VERSION0) # Get regex non-compatible behaviour: compile(string) # will be the default in the future compile(string, VERSION1) But what about during the transition, when backwards-compatible behaviour is the default? There needs to be a way to turn compatibility mode off, not just turn it on. # Get backwards-compatible behaviour: compile(string) # will be the default for a release or two compile(string, COMPAT) compile(string, VERSION0) # Get regex non-compatible behaviour: compile(string, VERSION1) So I guess my preference is VERSION0 and VERSION1 flags, even if there is never going to be a VERSION2. -- ___ Python tracker <http://bugs.python.org/issue2636> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2636] Adding a new regex module (compatible with re)
Steven D'Aprano added the comment: Ezio Melotti wrote: > Ezio Melotti added the comment: > > Also note that some behaviors are not "old" or "compatible", but just > different. For example why inline flags should be the old (or new) behavior? > Or e.g. the behavior of version 2 but not 0 and 1? > Also what if I want zero-width splits but not nested sets and sets > operations? Or if I want inline flags but not zero-width splits? I think this is adding excessive complexity. Please consider poor Matthew's sanity (or whoever ends up maintaining the module long term), not to mention that of the users of the module. I think it is reasonable to pick a *set* of features as a whole: "I want the regex module to behave exactly the same as the re module" or "I don't care about the re module, give me all the goodies offered by the regex module" but I don't think it is reasonable to expect to pick and choose individual features: "I want zero-width splits but not nested sets or inline flags, and I want the locale flag to act like the re module, and ASCII characters to be treated just like in Perl, but non-ASCII characters to be treated just like grep, and a half double decaff half-caf soy mocha with a twist of lemon with a dash of half-fat unsweetened whipped cream on the side." If you don't want a feature, don't use it. "Feature flags" leads to a combinational explosion that makes comprehensive testing all but impossible. If you have four features A...D, then for *each* feature you need sixteen tests: A with flags A with flags 0001 A with flags 0010 A with flags 0011 [...] A with flags to ensure that there are no side-effects from turning features off. The alternative is hard to track down bugs: "this regular expression returns the wrong result, but only if you have flags A, B and G turned on and C and F turned off." -- ___ Python tracker <http://bugs.python.org/issue2636> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2636] Adding a new regex module (compatible with re)
Steven D'Aprano added the comment: Matthew Barnett wrote: > So, VERSION0 and VERSION1, with "(?V0)" and "(?V1)" in the pattern? Seems reasonable to me. +1 -- ___ Python tracker <http://bugs.python.org/issue2636> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6210] Exception Chaining missing method for suppressing context
Steven D'Aprano added the comment:
It seems to me that an explicit raise inside an except block should *not* chain
exceptions by default. The rationale for chaining exceptions is to detect bugs
in the exception handler:
try:
something
except SomeError:
y = 1/x # oops, what happens when x == 0?
but an explicit raise isn't a bug. If you want it to chain for some reason,
it's easy to do:
try:
something
except SomeError as exp:
raise MyException from exp
or otherwise set __content__, but there's no simple way to avoid chaining
except via boilerplate code.
I frequently use the EAFP idiom to detect error conditions, and chained
exceptions exposes details to the caller that are irrelevant implementation
details. Here's a common example:
def process(iterable):
try:
x = next(iterable)
except StopIteration:
raise ValueError("can't process empty iterable")
continue_processing()
The fact that ValueError was raised in response to a StopIteration is an
irrelevant implementation detail that shouldn't be, and wasn't in 2.x, exposed.
Another practical example is avoiding isinstance checks:
def func(x):
try:
x + 0
except (ValueError, TypeError):
raise MyException('x is not a number')
do_something_with(x)
I note that PEP 3134 explicitly listed the issue of *not* chaining exceptions
as an open issue. Now that chained exceptions are being seen in the wild, it
seems that the inability to easily suppress chaining *is* a real issue for some
users:
http://mail.python.org/pipermail/python-list/2010-October/1258583.html
http://mail.python.org/pipermail/python-list/2010-December/1261738.html
--
nosy: +stevenjd
___
Python tracker
<http://bugs.python.org/issue6210>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7821] Command line option -U not documented
New submission from Steven D'Aprano : There is a command line switch -U (uppercase U) which is mentioned in PEP 3147 http://www.python.org/dev/peps/pep-3147/ but doesn't appear to be documented anywhere. It is listed here, but not described: http://docs.python.org/using/cmdline.html Nor does it appear in the output of pythonX --help for X in 2.5, 2.6 and 3.1. -- assignee: georg.brandl components: Documentation messages: 98607 nosy: georg.brandl, stevenjd severity: normal status: open title: Command line option -U not documented versions: Python 2.5, Python 2.6, Python 3.1 ___ Python tracker <http://bugs.python.org/issue7821> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7821] Command line option -U not documented
Steven D'Aprano added the comment: If the switch is intentionally not documented, perhaps it should be removed from here: http://docs.python.org/using/cmdline.html#command-line where it is listed but not explained anywhere. As it stands now, the *existence* of the switch is documented, but not the purpose. -- ___ Python tracker <http://bugs.python.org/issue7821> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4037] doctest.py should include method descriptors when looking inside a class __dict__
Steven D'Aprano added the comment: The patch you suggest is *not* sufficient, at least not by my testing. However, the attached patch does work, according to my tests. -- nosy: +stevenjd Added file: http://bugs.python.org/file16158/patch ___ Python tracker <http://bugs.python.org/issue4037> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4037] doctest.py should include method descriptors when looking inside a class __dict__
Steven D'Aprano added the comment: Attached is a simple test script for the patch I submitted. I have tested it with Python 2.6 both before and after applying the patch. Run it from the command line. With the unpatched doctest module, it prints: "Expected 2 doctests, but only found 1" After the patch, it finds and runs both doctests, and prints nothing. -- Added file: http://bugs.python.org/file16185/doctest_test.py ___ Python tracker <http://bugs.python.org/issue4037> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8128] String interpolation with unicode subclass fails to call __str__
New submission from Steven D'Aprano :
String interpolation % operates on unicode strings directly without calling the
__str__ method. In Python 2.5 and 2.6:
>>> class K(unicode):
... def __str__(self): return "Surprise!"
...
>>> u"%s" % K("some text")
u'some text'
but subclasses of str do call __str__:
>>> class K(str):
... def __str__(self): return "Surprise!"
...
>>> "%s" % K("some text")
'Surprise!'
In Python 3.1, the above example for subclassing str operates like the unicode
example, i.e. it fails to call __str__.
The documentation for string interpolation states that str() is called for all
Python objects.
http://docs.python.org/library/stdtypes.html#string-formatting-operations
If the behaviour for unicode (2.5/2.6, str in 3.1) is considered correct, then
the documentation should be updated to say that unicode is an exception to the
rule. Otherwise the behaviour is incorrect, and it should call __str__ the same
as everything else.
--
messages: 100984
nosy: stevenjd
severity: normal
status: open
title: String interpolation with unicode subclass fails to call __str__
versions: Python 2.5, Python 2.6, Python 3.1
___
Python tracker
<http://bugs.python.org/issue8128>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8128] String interpolation with unicode subclass fails to call __str__
Steven D'Aprano added the comment: I've assumed that the documentation is correct, and that "%s"%obj should call __str__ for unicode objects as well as everything else. Attached in a test file. -- Added file: http://bugs.python.org/file16595/test_interpolation.py ___ Python tracker <http://bugs.python.org/issue8128> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4037] doctest.py should include method descriptors when looking inside a class __dict__
Steven D'Aprano added the comment: I have fixed the issue with line length, and taken Brian's advice re valname. Updated patch for doctest and test.test_doctest2 is attached. -- Added file: http://bugs.python.org/file16599/doctest_patch ___ Python tracker <http://bugs.python.org/issue4037> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4255] timing module refers to non-existent documentation
New submission from Steven D'Aprano <[EMAIL PROTECTED]>: import timing help(timing) => MODULE DOCS http://www.python.org/doc/current/lib/module-timing.html but there doesn't appear to be any such page: the URL gives Error 404: File Not Found. Searching the reference library for "timing" doesn't find anything that looks relevant. -- assignee: georg.brandl components: Documentation messages: 75466 nosy: georg.brandl, stevenjd severity: normal status: open title: timing module refers to non-existent documentation versions: Python 2.5 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4255> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4457] __import__ documentation obsolete
New submission from Steven D'Aprano <[EMAIL PROTECTED]>: The documentation for __import__ says that it primarily exists "so that you can replace it with another function that has a compatible interface, in order to change the semantics of the import statement". http://docs.python.org/library/functions.html That is no longer the case. The recommended way to do that is with the new import hooks, and the docs should reflect that. A common use for __import__ is for when you don't know the module name until runtime. That too should be mentioned. -- assignee: georg.brandl components: Documentation messages: 76582 nosy: georg.brandl, stevenjd severity: normal status: open title: __import__ documentation obsolete ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4457> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4795] inspect.isgeneratorfunction inconsistent with other inspect functions
New submission from Steven D'Aprano : The inspect isSOMETHING() functions all return True or False, except for isgeneratorfunction(), which returns True or None. The body of the function is very brief: if (isfunction(object) or ismethod(object)) and \ object.func_code.co_flags & CO_GENERATOR: return True The behaviour can be made consistent with the other routines by either appending "else: return False", or changing the body to: return bool( (isfunction(object) or ismethod(object)) and object.func_code.co_flags & CO_GENERATOR) -- components: Library (Lib) messages: 78661 nosy: stevenjd severity: normal status: open title: inspect.isgeneratorfunction inconsistent with other inspect functions type: behavior versions: Python 2.6 ___ Python tracker <http://bugs.python.org/issue4795> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4796] Decimal to receive from_float method
New submission from Steven D'Aprano : In the PEP for Decimal, it was discussed that the class should have a from_float() method for converting from floats, but to leave it out of the Python 2.4 version: http://www.python.org/dev/peps/pep-0327/#from-float Following discussions with Mark Dickinson, I would like to request that this now be implemented. The suggested API is: Decimal.from_float(floatNumber, [decimal_places]) At the risk of derailing the request, I wonder whether it is better to give a context rather than a number of decimal places? Pro: better control over conversion, as you can specify rounding method as well as number of decimal places. Con: more difficult for newbies to understand. Semi-pro: float to decimal conversions are inherently tricky, perhaps we should be discouraging newbies from blindly calling from_float() and make the (hypothetical) context argument mandatory rather than optional? -- components: Library (Lib) messages: 78664 nosy: stevenjd severity: normal status: open title: Decimal to receive from_float method type: feature request ___ Python tracker <http://bugs.python.org/issue4796> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4796] Decimal to receive from_float method
Steven D'Aprano added the comment: Mark suggested the following strategy for Decimal.from_float: "always use the largest exponent possible". Just for the avoidance of all doubt, do you mean the largest exponent with the number normalised to one digit to the right of the decimal place? Because 1e1 = 0.1e2 = 0.01e3 = ... and there is no "largest exponent possible" if you allow unnormalised numbers. Seems obvious to me, but maybe I'm missing something. ___ Python tracker <http://bugs.python.org/issue4796> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4796] Decimal to receive from_float method
Steven D'Aprano added the comment:
Raymond:
> Accordingly, I recommend Decimal.from_float(f) with no
> qualifiers or optional arguments.
-0 on this one. It's going to confuse an awful lot of newbies when
they write Decimal.from_float(1.1) and get
Decimal('110008881784197001252...e-51').
Also, why not just extend the Decimal() constructor to accept a float
as the argument? Why have a separate from_float() method at all?
> To support the use case of wanting to round the input, I
> suggest a separate method modeled on Context.create_decimal().
+1 on this.
___
Python tracker
<http://bugs.python.org/issue4796>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4796] Decimal to receive from_float method
Steven D'Aprano added the comment:
Mark wrote:
>> Also, why not just extend the Decimal() constructor to accept
>> a float as the argument? Why have a separate from_float()
>> method at all?
>
> This was discussed extensively when the decimal module was
> being proposed; see the Decimal PEP for arguments against this.
I'm very aware of that. The Decimal PEP says the consensus was for
from_float() to take a second argument specifying the precision.
Decimal(1.1) => Decimal("1.1") was rejected for the reasons given in
the PEP by Paul Moore, and Decimal(1.1) =>
Decimal('110008881784197001252...e-51') was (presumably)
rejected because it would confuse newbies. Hence the decision to (1)
make an alternative constructor and (2) have it take a second
argument.
It looks like you and Raymond have rejected #2 but are keeping #1, and
I'm curious why. That's genuine curiosity, and a real question, not a
thinly-veiled scowl of disapproval disguised as a question :)
Anyway, I'm happy enough so long as Raymond's suggested
Context.create_decimal() exists, that's the actual functionality I'm
after, so maybe I should let you guys get on with it. Thanks.
___
Python tracker
<http://bugs.python.org/issue4796>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4947] sys.stdout fails to use default encoding as advertised
New submission from Steven D'Aprano :
Documentation for files states that when writing to a file, unicode
strings are converted to byte strings using the encoding specified by
file.encoding.
http://docs.python.org/library/stdtypes.html#file.encoding
sys.stdout is a file, but it does not behave as stated above:
>>> type(sys.stdout)
>>> sys.stdout.encoding
'UTF-8'
>>> u = u"\u554a"
>>> print u
啊
>>> sys.stdout.write(u)
Traceback (most recent call last):
File "", line 1, in
UnicodeEncodeError: 'ascii' codec can't encode character u'\u554a' in
position 0: ordinal not in range(128)
>>> sys.stdout.write(u.encode('utf-8'))
啊
--
messages: 79849
nosy: stevenjd
severity: normal
status: open
title: sys.stdout fails to use default encoding as advertised
versions: Python 2.5, Python 2.6
___
Python tracker
<http://bugs.python.org/issue4947>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2527] Pass a namespace to timeit
Changes by Steven D'Aprano : -- nosy: +stevenjd ___ Python tracker <http://bugs.python.org/issue2527> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5065] IDLE improve Subprocess Startup Error message
New submission from Steven D'Aprano : When launching IDLE, it reports: "IDLE's subprocess didn't make connection. Either IDLE can't start a subprocess or personal firewall software is blocking the connection." This should report what needs to be opened on the firewall to allow the connection, e.g. "Allow UDP/TCP connections to 127.0.0.1 on ports FOO and BAR and try again". -- components: IDLE messages: 80560 nosy: stevenjd severity: normal status: open title: IDLE improve Subprocess Startup Error message type: feature request ___ Python tracker <http://bugs.python.org/issue5065> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5066] IDLE documentation for Unix obsolete/incorrect
New submission from Steven D'Aprano : Documentation for IDLE states: Starting IDLE on UNIX On Unix, just type "idle" at a command prompt. This should bring up a Window similar to the one above. (If it doesn't, look for the "idle" script in the Tools/idle directory in the Python source distribution.) http://www.python.org/idle/doc/idlemain.html I believe that is obsolete, I cannot see a Tools/idle directory in either 2.5 or 2.6. Perhaps better instructions might be: (If it doesn't, run "python LOC/idlelib/idle.py" where LOC is the location of your Python source distribution, usually /usr/lib/python*.) or similar. -- assignee: georg.brandl components: Documentation, IDLE messages: 80562 nosy: georg.brandl, stevenjd severity: normal status: open title: IDLE documentation for Unix obsolete/incorrect ___ Python tracker <http://bugs.python.org/issue5066> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5067] Error msg from using wrong quotes in JSON is unhelpful
New submission from Steven D'Aprano :
Using the wrong sort of quotes in json gives unhelpful error messages:
>>> json.loads("{'test':'test'}")
Traceback (most recent call last):
...
ValueError: Expecting property name: line 1 column 1 (char 1)
Unless you know that strings in JSON must be delimited with
double-quotes and not single (a very surprising fact to those used to
Python) this error message is perplexing. I suggest something like:
Single-quoted strings are invalid property names: line 1 column 1
(char 1)
or
Parse error, invalid char: line 1, column 1 (char 1)
--
messages: 80564
nosy: stevenjd
severity: normal
status: open
title: Error msg from using wrong quotes in JSON is unhelpful
versions: Python 2.6
___
Python tracker
<http://bugs.python.org/issue5067>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5067] Error msg from using wrong quotes in JSON is unhelpful
Changes by Steven D'Aprano : -- components: +Library (Lib) type: -> behavior ___ Python tracker <http://bugs.python.org/issue5067> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1108] Problem with doctest and decorated functions
Steven D'Aprano added the comment: For what it's worth, this bug appears to go back to at least Python 2.4, and it affects functions using decorators even if they are defined in the same module as the decorated function. I've applied the patch to my 2.4 installation, and it doesn't fix the issue. I'd like to request this be reopened, because I don't believe the patch works as advertised. I've attached a simple script which should demonstrate the issue. Run it with "python doctestfail.py [-v]", and if it passes with no failures, the bug still exists. I've tested it on 2.4 before and after the patch. (Apologies for not having anything more recent at the moment.) -- nosy: +stevenjd Added file: http://bugs.python.org/file13078/doctestfail.py ___ Python tracker <http://bugs.python.org/issue1108> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1108] Problem with doctest and decorated functions
Steven D'Aprano added the comment: Earlier I wrote: "I've applied the patch to my 2.4 installation, and it doesn't fix the issue. I'd like to request this be reopened, because I don't believe the patch works as advertised." Nevermind, I withdraw the request. I believe I was mislead due to the decorated function not having it's docstring automatically copied from the original without the use of functools.wraps(). ___ Python tracker <http://bugs.python.org/issue1108> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46947] unicodedata.name gives ValueError for control characters
Steven D'Aprano added the comment:
The behaviour is technically correct, but confusing and unfortunate, and I
don't think we can fix it.
Unicode does not define names for the ASCII control characters. But it does
define aliases for them, based on the C0 control char standard.
unicodedata.lookup() looks for aliases as well as names (since version 3.3).
https://www.unicode.org/Public/UNIDATA/UnicodeData.txt
https://www.unicode.org/Public/UNIDATA/NameAliases.txt
It is unfortunate that we have only a single function for looking up a unicode
code point by name, alias, alias-abbreviation, and named-sequence. That keeps
the API simple, but in corner cases like this it leads to confusion.
The obvious "fix" is to make name() return the alias if there is no official
name to return, but that is a change in behaviour. I have code that assumes
that C0 and C1 control characters have no name, and relies on name() raising an
exception for them.
Even if we changed the behaviour to return the alias, which alias should be
returned, the full alias or the abbreviation?
This doesn't fix the problem that name() and lookup() aren't inverses of each
other:
lookup('NUL') -> '\0 # using the abbreviated alias
name('\0') -> 'NULL' # returns the full alias (or vice versa)
It gets worse with named sequences:
>>> c = lookup('LATIN CAPITAL LETTER A WITH MACRON AND GRAVE')
>>> name(c)
Traceback (most recent call last):
File "", line 1, in
TypeError: name() argument 1 must be a unicode character, not str
>>> len(c)
2
So we cannot possibly make name() and lookup() inverses of each other.
What we really should have had is separate functions for name and alias
lookups, or better still, to expose the raw unicode tables as mappings and let
people create their own higher-level interfaces.
--
nosy: +steven.daprano
___
Python tracker
<https://bugs.python.org/issue46947>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46961] Caching/interning of small ints sometimes fails
New submission from Steven D'Aprano : I'm reluctant to call this a bug, as small int interning/caching is an implementation detail and there are no hard guarantees made. But on the other hand, it seems that the intention is that small ints such as 0, 1 and 2 should be cached. Here are some examples where they are not. Intentional or a bug? >>> x = 1 >>> y = pow(2, 31, 2**31-1) >>> y == x True >>> y is x False >>> x = 2 >>> y = pow(2, 31, 2**31-2) >>> y == x True >>> y is x False It also affects values which are presumably constant-folded at compile time: >>> x = 1 >>> y = 2**31 % (2**31 - 1) >>> z = 2**31 % (2**31 - 1) >>> x == y == z True >>> x is y False >>> y is z False >>> x is z False But if you run the code in exec, the value is interned: >>> code = """ ... x = 1 ... y = 2**31 % (2**31-1) ... """ >>> dis(code) 2 0 LOAD_CONST 0 (1) 2 STORE_NAME 0 (x) 3 4 LOAD_CONST 0 (1) 6 STORE_NAME 1 (y) 8 LOAD_CONST 1 (None) 10 RETURN_VALUE >>> exec(code) >>> x is y True Also affects zero: >>> x = 0 >>> y = 2**29 % (2**29) >>> x is y True >>> y = 2**30 % (2**30) >>> x is y False First noted here: https://discuss.python.org/t/cached-integer-id-on-high-calculations/14128/1 >>> sys.version '3.10.0 (default, Oct 28 2021, 20:43:43) [GCC 8.3.1 20190223 (Red Hat 8.3.1-2)]' -- components: Interpreter Core messages: 414762 nosy: steven.daprano priority: normal severity: normal status: open title: Caching/interning of small ints sometimes fails type: behavior versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue46961> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46967] Type union for except
Change by Steven D'Aprano : -- nosy: +steven.daprano ___ Python tracker <https://bugs.python.org/issue46967> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47018] ImportError: cannot import name '_simple_enum' from 'enum'
Steven D'Aprano added the comment: What makes you think you are supposed to be able to import _simple_enum? It is a name with a leading underscore, so even if it exists, it is private and you shouldn't touch it. Unless _simple_enum is documented as something you can use, this is not a bug and there is nothing to fix. I don't see "_simple_enum" listed anywhere in the enum documentation, so why do you think you should be able to import it? https://docs.python.org/3/library/enum.html By the way, "reinstall Python" is almost never the solution to problems. Why do you think you need to "fix the install"? -- nosy: +steven.daprano resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue47018> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47031] math.nan should note that NANs do not compare equal to anything
New submission from Steven D'Aprano :
The IEEE-754 requirement that NANs are never equal to anything, even to
themselves, is a common stumbling block for those new to the consequences of
IEEE-754. See for example #47020.
The documentation for math.nan would be a good place to add a note like
"Due to the requirements of the `IEEE-754 standard
<https://en.wikipedia.org/wiki/IEEE_754>`_, math.nan and float('nan') are never
equal to any other value, including themselves. Use math.isnan to test for
NANs."
https://docs.python.org/3.8/library/math.html#math.nan
--
assignee: docs@python
components: Documentation
keywords: easy
messages: 415302
nosy: docs@python, steven.daprano
priority: normal
severity: normal
status: open
title: math.nan should note that NANs do not compare equal to anything
type: enhancement
versions: Python 3.10, Python 3.11, Python 3.7, Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issue47031>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45297] Improve the IDLE shell save command
Steven D'Aprano added the comment: Here is another example of a newbie caught by this: https://discuss.python.org/t/syntax-error-in-python-3-10-when-running-on-terminal/14462 -- ___ Python tracker <https://bugs.python.org/issue45297> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47031] math.nan should note that NANs do not compare equal to anything
Steven D'Aprano added the comment: > We cannot guarantee that NAN never equal to anything, because we can > create an object equal to it. For example mock.ANY Sure. I don't expect that mock.ANY or other weird objects should obey the IEEE-754 rules. But we're talking numeric comparisons here, not arbitrary objects which may do arbitrary things in their `__eq__` method. The documentation for the math module assumes we're talking about sensible, standard numeric values that don't play strange tricks on the caller. Look at the first function documented: math.ceil(x) Return the ceiling of x, the smallest integer greater than or equal to x. If x is not a float, delegates to x.__ceil__(), which should return an Integral value. class MyWeirdFloat(float): def __ceil__(self): return -1 math.ceil(MyWeirdFloat(25.9)) # Returns -1 instead of the ceiling. Does the documentation really need to cover every imaginable weird class? I don't think so. Let's keep it simple. NANs compared unequal with all numeric values which directly or indirectly obey IEEE-754, which includes floats. -- ___ Python tracker <https://bugs.python.org/issue47031> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47134] Document the meaning of the number in OverflowError
New submission from Steven D'Aprano : OverflowError sometimes (but not always) includes some sort of numeric code: >>> 1e+300 ** 2 Traceback (most recent call last): File "", line 1, in OverflowError: (34, 'Numerical result out of range') but the meaning of the 34 is not documented: https://docs.python.org/3/library/exceptions.html#OverflowError help(OverflowError) is no more insightful, saying only: __init__(self, /, *args, **kwargs) Initialize self. See help(type(self)) for accurate signature. Other OverflowError exceptions do not include the numeric code: >>> math.exp(1) Traceback (most recent call last): File "", line 1, in OverflowError: math range error Is it an error code from C? Something to do with the number of digits of precision? An easter-egg to do with The Count Of Monte Cristo? -- assignee: docs@python components: Documentation messages: 416093 nosy: docs@python, steven.daprano priority: normal severity: normal status: open title: Document the meaning of the number in OverflowError type: enhancement versions: Python 3.10, Python 3.11, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue47134> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47133] enhance unittest to show test name and docstring on one line
Steven D'Aprano added the comment: I don't think this change of behaviour should be accepted without discussion, and I'm not sure why you think Python-Dev is the right place, rather than here. Messing around with unittest and docstrings has already caused issues in the past: https://docs.python.org/3/library/unittest.html#unittest.TestCase.shortDescription so perhaps we shouldn't break what's not broken? And frankly, I don't see why the current behaviour is a problem, although maybe that's because the way I use unittest is different from the way you use it. Grepping the output for errors? Why run verbose mode if you aren't going to read the whole output? Seems very odd. Ethan says: "the test name is easily missed by anyone who isn't aware of that" Surely the solution to that is education, not changing unittest? Now you are aware of it, and the test name is no longer "easily missed". If it ever was. To me, it is plain as day. Here is some typical output: [steve ~]$ python3.10 -m unittest -v mathlib/testing/test_utils.py test_broken_doc (mathlib.testing.test_utils.TestMinmax) This is a docstring ... ERROR test_broken_nodoc (mathlib.testing.test_utils.TestMinmax) ... ERROR test_empty_iterable (mathlib.testing.test_utils.TestMinmax) ... ok [additional passing tests ommitted for brevity] == ERROR: test_broken_doc (mathlib.testing.test_utils.TestMinmax) This is a docstring -- Traceback (most recent call last): File "/home/steve/Desktop/mathlib/testing/test_utils.py", line 20, in test_broken_doc self.assertEqual(1, x) NameError: name 'x' is not defined == ERROR: test_broken_nodoc (mathlib.testing.test_utils.TestMinmax) -- Traceback (most recent call last): File "/home/steve/Desktop/mathlib/testing/test_utils.py", line 24, in test_broken_nodoc self.assertEqual(1, x) NameError: name 'x' is not defined -- Ran 10 tests in 0.004s FAILED (errors=2) Errors are listed twice, once in the summary, and the second time in the details section showing the traceback. Note that if you just grep for ERROR you get the result you want: [steve ~]$ python3.10 -m unittest -v mathlib/testing/test_utils.py |& grep ERROR This is a docstring ... ERROR test_broken_nodoc (mathlib.testing.test_utils.TestMinmax) ... ERROR ERROR: test_broken_doc (mathlib.testing.test_utils.TestMinmax) ERROR: test_broken_nodoc (mathlib.testing.test_utils.TestMinmax) So I am having trouble seeing what the problem here is. -- nosy: +steven.daprano ___ Python tracker <https://bugs.python.org/issue47133> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47133] enhance unittest to show test name and docstring on one line
Steven D'Aprano added the comment: I have no problem with pinging Python-Dev, or any other forum, asking for interested parties. I just don't think we should be intentionally spliting the discussion more than it's going to get split organically. (If this is interesting to people, they will discuss it on other forums no matter what we say or do.) Aside from the conservative position "If it ain't broke, don't break it", also known as "Chesterton's Fence": https://matt-rickard.com/chestertons-fence/ I'm not specifically opposed to this change. Nor am I in favour. Why do we print the first line of the doctests in the output of failing tests? If we understood the rationale for why we do that, it might give some insight into the consequences of removing it. If we don't know why it was shown in the first place, maybe we shouldn't remove it until we have some idea. I am -1 on another option flag unless there is no other choice. Each boolean flag option doubles the number of tests of unitttest itself needed for full coverage. Another option might be to leave the docstring line alone, and just *add* the 'ERROR' to the method name line: # current output test_broken_doc (mathlib.testing.test_utils.TestMinmax) This is a docstring ... ERROR # enhancement test_broken_doc (mathlib.testing.test_utils.TestMinmax) ERROR This is a docstring ... ERROR That seems to me to be less risky than trying to cram them all on one line. test_broken_doc (mathlib.testing.test_utils.TestMinmax) This is a docstring ... ERROR By the way, I presume we do the same thing for FAIL lines, which have the same behaviour as ERROR lines: test_fail_doc (mathlib.testing.test_utils.TestMinmax) This is a docstring ... FAIL test_fail_nodoc (mathlib.testing.test_utils.TestMinmax) ... FAIL -- ___ Python tracker <https://bugs.python.org/issue47133> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47135] Allow decimal.localcontext to accept keyword arguments to set context attributes
New submission from Steven D'Aprano : Whenever I use decimal and need to change the context temporarily, without fail I try to write with decimal.localcontext(prec=10): ... or similar. Then I get surprised that it fails, and re-write it as with decimal.localcontext() as ctx: ctx.prec = 10 ... Let's make the first version work. localcontext should accept keyword arguments corresponding to the same arguments accepted by Context, and set them on the context given. A proof-of-concept wrapper function: def localcontext(ctx=None, **kwargs): if ctx is None: ctx = decimal.getcontext().copy() for key, value in kwargs.items(): setattr(ctx, key, value) return decimal.localcontext(ctx) I think this would be a valuable, and useful, improvement to the decimal API. -- components: Library (Lib) messages: 416114 nosy: steven.daprano priority: normal severity: normal status: open title: Allow decimal.localcontext to accept keyword arguments to set context attributes versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue47135> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47136] Wrong value assigned automatically to the variable __module__ in the class body.
Steven D'Aprano added the comment: > the programmer may use the variable __name__ for some other purposes Dunder names like `__name__` are reserved for the use of the interpreter. If the programmer uses them for "other purposes", the programmer is responsible for any failures. You wouldn't write: class MyList(list): __len__ = "Hello world!" and then be surprised that MyList is broken. You shouldn't be surprised if setting `__name__` to an invalid value breaks things either. -- nosy: +steven.daprano ___ Python tracker <https://bugs.python.org/issue47136> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47133] enhance unittest to show test name and docstring on one line
Steven D'Aprano added the comment: Rather than an option for this, it would be cleaner to deprecate the current output in 3.11, and fix it in 3.12 or 3.13. Otherwise we have to maintain the old (bad?) output and the new output both forever. -- ___ Python tracker <https://bugs.python.org/issue47133> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40469] TimedRotatingFileHandler rotating on use not time
Steven D'Aprano added the comment: See this thread on Discuss: https://discuss.python.org/t/logging-timedrotatingfilehandler-never-rotates-in-certain-cases/14747/1 -- nosy: +steven.daprano ___ Python tracker <https://bugs.python.org/issue40469> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47135] Allow decimal.localcontext to accept keyword arguments to set context attributes
Steven D'Aprano added the comment: I'm not sure what the implementation uses to enforce this, but decimal contexts already seem to reject arbitrary attributes. So a naive implementation that just setattr()'s the keyword arguments will automatically fail: >>> from decimal import getcontext >>> ctx = getcontext() >>> setattr(ctx, 'precision', 10) Traceback (most recent call last): File "", line 1, in AttributeError: 'decimal.Context' object has no attribute 'precision' But you are absolutely correct that however we enforce it, we should avoid allowing typos to silently fail. -- ___ Python tracker <https://bugs.python.org/issue47135> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
