[issue21475] Support the Sitemap extension in robotparser
Steven Steven added the comment: Kindly add a test for this issue -- nosy: +stevensalbert ___ Python tracker <https://bugs.python.org/issue21475> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33288] Diethealth
New submission from Steven Steven : sue -- messages: 315363 nosy: stevensalbert priority: normal severity: normal status: open title: Diethealth ___ Python tracker <https://bugs.python.org/issue33288> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33288] Diethealth
Steven Steven added the comment: http://www.diethealthsupplements.com/ -- ___ Python tracker <https://bugs.python.org/issue33288> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45504] [argparse] Entering a partial config_parser flag works with subparsers
New submission from Steven :
I have a package with a module called `commands.py`. This file is basically
three sub parsers and an entry point.
Here is one of my subparsers. It shows the current path of a config file, and
lets you update the path if you want.
#config sub-command
config_parser = subparsers.add_parser('config')
config_parser.set_defaults(func=config_path)
config_parser.add_argument('--show', help='show current config file path -
takes no input', action='store_true')
config_parser.add_argument('--update', help='modify config file path',
dest='path')
If you look at the first config_parser which is `--show`. Notice how it doesn't
take an input. You just pass in --show and it prints the config path to the cli.
Here is the function that tells --show what to do.;
def config_path(args):
dotenv_file = dotenv.find_dotenv()
dotenv.load_dotenv(dotenv_file)
if args.show:
print(os.environ['FILE_PATH'])
elif args.path:
os.environ['FILE_PATH'] = args.path
dotenv.set_key(dotenv_file, 'FILE_PATH', os.environ['FILE_PATH'])
This is what my entrypoints in my setup.py looks like.
entry_points={
'console_scripts': [
#command = package.module:function
'conftool = conftool.commands:main',
],
}
)
All of the following work
conftool config --s
conftool config --sh
conftool config --sho
conftool config --show
I have another sub parser and function like the one above. The config_parser is
basically the same. It has an option that doesn't take an argument and store is
true. They behave the same way. The other function and subparser have an option
that is `--gettoken`. It works with --g, --ge, --get, --gett, --getto,
--gettok, gettoke.
Is this possibly a bug?
--
components: Parser
messages: 404153
nosy: lys.nikolaou, pablogsal, swills1
priority: normal
severity: normal
status: open
title: [argparse] Entering a partial config_parser flag works with subparsers
versions: Python 3.9
___
Python tracker
<https://bugs.python.org/issue45504>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28926] subprocess.Popen + Sqlalchemy doesn't wait for process
New submission from Steven:
Called subprocess.Popen("python_file.py", shell=True).wait(), which triggered a
call to `Base.metadata.create_all(engine)` inside `python_file.py`
This caused nothing after the `create_all(engine)` call to execute in
`python_file.py` But, if I changed `subprocess.Popen` to
`subprocess.check_call("python_file", shell=True).wait()`, the desired behavior
was achieved.
I was able to continue past `create_all(engine)` if there was an error in the
parent script after the subprocess call. In this case, then `python_file.py`
was able to execute fully as expected.
--
components: Library (Lib)
messages: 282804
nosy: s1113950
priority: normal
severity: normal
status: open
title: subprocess.Popen + Sqlalchemy doesn't wait for process
type: behavior
versions: Python 2.7
___
Python tracker
<http://bugs.python.org/issue28926>
___
___
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: 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
[issue46294] Integer overflow & Int values loaded into Bool detected via Libfuzzer & UndefinedBehaviorSanitizer
New submission from Steven Wirsz : Compiling source from github on January 6, 2022, detected via Libfuzzer & UndefinedBehaviorSanitizer: # ./fuzz_struct_unpack crash-a0d.txt Running: crash-a0d.txt /src/cpython3/Modules/_struct.c:509:28: runtime error: load of value 128, which is not a valid value for type '_Bool' Python/pyhash.c:396:9: runtime error: unsigned integer overflow: 1726337582519137 + 1455368869671451682 cannot be represented in type 'unsigned long' Python/pyhash.c:414:5: runtime error: unsigned integer overflow: 6843264283216330929 + 16329705011411640967 cannot be represented in type 'unsigned long' Python/pyhash.c:417:5: runtime error: unsigned integer overflow: 13747253807228978341 + 10396395245414858527 cannot be represented in type 'unsigned long' Python/pyhash.c:418:5: runtime error: unsigned integer overflow: 17173606624272818715 + 4069551840979798976 cannot be represented in type 'unsigned long' Python/pyhash.c:419:5: runtime error: unsigned integer overflow: 12388162105911730119 + 9634611433502982398 cannot be represented in type 'unsigned long' Objects/longobject.c:288:22: runtime error: unsigned integer overflow: 0 - 18446744073709550595 cannot be represented in type 'unsigned long' Objects/longobject.c:4872:31: runtime error: unsigned integer overflow: 18446744073709551615 + 1 cannot be represented in type 'unsigned long' Objects/longobject.c:3124:33: runtime error: unsigned integer overflow: 0 - 1 cannot be represented in type 'unsigned int' Objects/longobject.c:3130:33: runtime error: unsigned integer overflow: 0 - 1 cannot be represented in type 'unsigned int' Objects/tupleobject.c:426:21: runtime error: unsigned integer overflow: 219911203979059663 * 14029467366897019727 cannot be represented in type 'unsigned long' Objects/tupleobject.c:428:13: runtime error: unsigned integer overflow: 14367201699383568926 * 11400714785074694791 cannot be represented in type 'unsigned long' Objects/tupleobject.c:426:13: runtime error: unsigned integer overflow: 1835114336222707 + 1497884194698650478 cannot be represented in type 'unsigned long' Objects/tupleobject.c:432:9: runtime error: unsigned integer overflow: 18406138070188819878 + 2870177450013471924 cannot be represented in type 'unsigned long' Python/traceback.c:247:86: runtime error: unsigned integer overflow: 18446744073709551615 * 2 cannot be represented in type 'unsigned long' Objects/frameobject.c:51:72: runtime error: unsigned integer overflow: 18446744073709551615 * 2 cannot be represented in type 'unsigned long' -- files: crash-a0d.txt messages: 409973 nosy: swirsz priority: normal severity: normal status: open title: Integer overflow & Int values loaded into Bool detected via Libfuzzer & UndefinedBehaviorSanitizer type: crash versions: Python 3.11 Added file: https://bugs.python.org/file50547/crash-a0d.txt ___ Python tracker <https://bugs.python.org/issue46294> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46294] Integer overflow & Int values loaded into Bool detected via Libfuzzer & UndefinedBehaviorSanitizer
Steven Wirsz added the comment:
Closing this report. I investigated the remaining issue and it looks like a
perfectly valid call to PyBool_FromLong:
/src/cpython3/Modules/_struct.c:509:28: runtime error: load of value 128, which
is not a valid value for type '_Bool'
static PyObject *
nu_bool(_structmodulestate *state, const char *p, const formatdef *f)
{
_Bool x;
memcpy((char *)&x, p, sizeof x);
return PyBool_FromLong(x != 0);
}
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue46294>
___
___
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
[issue1233] bsddb.dbshelve.DbShelf.append doesn't work
New submission from Steven Vereecken: The check for DB_RECNO seems to do the opposite of what it's supposed to do: def append(self, value, txn=None): if self.get_type() != db.DB_RECNO: self.append = self.__append return self.append(value, txn=txn) raise db.DBError, "append() only supported when dbshelve opened with filetype=dbshelve.db.DB_RECNO" -- components: Library (Lib) messages: 56219 nosy: polaar severity: normal status: open title: bsddb.dbshelve.DbShelf.append doesn't work type: behavior versions: Python 2.5 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1233> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13540] Document the Action API in argparse
Steven Bethard added the comment: Sorry about being out of contact (I'm flying back and forth between the US and the EU every 4-5 weeks right now), and thanks Terry for bringing this to my attention. Essentially, the API is: * The argument to action= must be a callable that accepts at least a "dest" and "option_strings" keyword arguments, and returns some object. The keyword arguments passed to this callable will be dest, option_strings, and whatever other keyword arguments were passed to add_argument(). * The object returned by the action= callable should have attributes "dest", "option_strings", "default", "type", "required", "help", etc. defined in essentially the same way as the add_argument() documentation. * The object returned by the action= callable should itself be callable, and should accept the arguments (self, parser, namespace, values, option_string=None). This method can do whatever it wants, but as you note, the typical approach is to invoke setattr(namespace, self.dest, ...) Now, all that said, the easiest way of creating a callable that returns an callable where both have the right signatures and the right attributes is to subclass argparse.Action. In fact, doing it any other way is probably crazy. I'm against changing the name of __call__ to invoke because it removes the possibility of defining an action as a function returning another function (which is currently possible), but I'm all for making the documentation strongly recommend subclassing argparse.Action. I would just say something like: "You may also specify an arbitrary action by passing a subclass of :class:`argparse.Action`, or another callable object that implements the same interface." I wouldn't bother to go into more detail about "implements the same interface" - all sane people will just subclass Action. ;-) As to argparse.Action.__init__, hopefully the above bullet points make it clear that you must accept "dest" and "option_strings", but what other keyword arguments you want to accept are up to you. Be sure to call the superclass __init__ to set any attributes that you didn't accept to appropriate default values. A simple example of accepting an additional keyword argument is the _VersionAction, which accepts a "version" keyword argument that the other actions don't accept. The current "example of a custom action" should probably define __init__ to show how this works. -- ___ Python tracker <http://bugs.python.org/issue13540> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13584] argparse doesn't respect double quotes
Steven Bethard added the comment:
Can you submit some example code that shows this? I can't reproduce this with:
-- temp.py --
import argparse
parser = argparse.ArgumentParser()
parser.add_argument("--ng", action="store_true")
parser.add_argument("--INP")
print(parser.parse_args())
--
$ python temp.py --ng --INP="Demo IO"
Namespace(INP='Demo IO', ng=True)
--
___
Python tracker
<http://bugs.python.org/issue13584>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12776] argparse: type conversion function should be called only once
Steven Bethard added the comment: Could you add a test to verify that custom actions are still getting the converted values passed to their __call__? I suspect this may not be happening under the current patch - if that's the case, you may also need to add conversions in _get_values, where the lines look like "value = action.default". Also, "action.default == getattr(namespace, action.dest)" should probably use "is" instead of "==". Other than that, the patch looks okay. -- ___ Python tracker <http://bugs.python.org/issue12776> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10772] Several actions for argparse arguments missing from docs
Steven Bethard added the comment: Looks good to me too. -- ___ Python tracker <http://bugs.python.org/issue10772> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13249] argparse.ArgumentParser() lists arguments in the wrong order
Steven Bethard added the comment: The ArgumentParser constructor is definitely only intended to be called with keyword arguments, so it's definitely a documentation bug that it doesn't say this. I haven't actually applied the patch, but the basic approach and wording look fine to me. -- ___ Python tracker <http://bugs.python.org/issue13249> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13271] When -h is used with argparse, default values that fail should not matter
Steven Bethard added the comment: I think http://bugs.python.org/issue12776, which delays type conversions on defaults should solve this problem, right? If you agree, could you add your code here as a test case to that issue and mark this as duplicate? (And yes, I agree this is a bug.) -- ___ Python tracker <http://bugs.python.org/issue13271> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13041] argparse: terminal width is not detected properly
Steven Bethard added the comment: I'd feel more comfortable with the argparse fix if it were simply calling "os.get_terminal_size()". I recommend that you: * Create a new issue called, say "add os.get_terminal_size()" proposing just the single method. * Add that issue to the Dependencies of this issue. Once that is fixed, then the argparse fix should be simple. -- versions: +Python 2.7, Python 3.2 ___ Python tracker <http://bugs.python.org/issue13041> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12806] argparse: Hybrid help text formatter
Steven Bethard added the comment: As I understand it the current proposal is: * Wrap each paragraph separately * Don't wrap any lines indented by at least one additional space This sounds like a useful formatter. I would probably call it "PargraphWrappingFormatter" or something like that which is more descriptive than FlexiFormatter. Sadly, it can't be the default, since that would break backwards compatibility, but I'd certainly agree to an obvious note somewhere in the docs recommending the use of this formatter instead of the current default. -- ___ Python tracker <http://bugs.python.org/issue12806> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9253] argparse: optional subparsers
Steven Bethard added the comment: If you can make your patch relative to the cpython source tree, and add a couple tests, it will be easier to review. Thanks for working on this! -- ___ Python tracker <http://bugs.python.org/issue9253> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13023] argparse should allow displaying argument default values in addition to setting a formatter class
Steven Bethard added the comment: Your solution is actually the current recommended solution - mix together both classes that you want to combine and pass your subclass as the parameter. This should probably be documented somewhere (and tested more). -- ___ Python tracker <http://bugs.python.org/issue13023> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12713] argparse: allow abbreviation of sub commands by users
Steven Bethard added the comment: Modulo the comments already on the patch by others, this approach looks fine to me. -- ___ Python tracker <http://bugs.python.org/issue12713> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12686] argparse - document (and improve?) use of SUPPRESS with help=
Steven Bethard added the comment: Could you give some examples of bugs that you observed? Otherwise, this looks like a duplicate of issue 9349. The intention is that help=SUPPRESS should cause the given argument to not be displayed in the help message. If there are cases where that's not true, then it's definitely a bug. -- ___ Python tracker <http://bugs.python.org/issue12686> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11708] argparse: suggestion for formatting optional positional args
Steven Bethard added the comment: I agree that this is a bug in current argparse formatting. It might be a little difficult to fix though because the current option formatting handles arguments one at a time, and producing something like [arg1 [arg2]] requires some understanding of how arguments interact, which the formatter currently doesn't have. But patches are certainly welcome. -- ___ Python tracker <http://bugs.python.org/issue11708> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12284] argparse.ArgumentParser: usage example option
Steven Bethard added the comment: %(prog)s is available in epilog: -- temp.py -- import argparse epilog = """\ Example usage: %(prog)s option1 option2 """ parser = argparse.ArgumentParser( formatter_class=argparse.RawTextHelpFormatter, epilog=epilog) parser.parse_args() -- $ python temp.py -h usage: temp.py [-h] optional arguments: -h, --help show this help message and exit Example usage: temp.py option1 option2 -- Did you need more than that? -- ___ Python tracker <http://bugs.python.org/issue12284> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9938] Documentation for argparse interactive use
Steven Bethard added the comment: Looks good to me. -- ___ Python tracker <http://bugs.python.org/issue9938> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11839] argparse: unexpected behavior of default for FileType('w')
Steven Bethard added the comment: I think Issue 12776, which delays type conversions on defaults, should solve this problem, right? If you agree, could you add your code here as a test case to that issue and mark this as duplicate? -- ___ Python tracker <http://bugs.python.org/issue11839> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11874] argparse assertion failure with brackets in metavars
Steven Bethard added the comment: I agree this is a bug. The patch needs to add unit tests that make sure metavars with [] work as expected. -- ___ Python tracker <http://bugs.python.org/issue11874> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11807] Documentation of add_subparsers lacks information about parametres
Steven Bethard added the comment: Looks good. A few minor comments (click "review" by the patch). -- ___ Python tracker <http://bugs.python.org/issue11807> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13605] document argparse's nargs=REMAINDER
New submission from Steven Bethard : There is an undocumented value for add_argument's nargs parameter, REMAINDER, which can be used to consume all the remaining arguments. This is commonly useful for command line utilities that dispatch to other command line utilities. Though undocumented, it has been used successfully by at least a few different people: http://stackoverflow.com/questions/5826881/how-to-use-argparse-to-collect-arguments-for-a-separate-command-line-without http://code.google.com/p/argparse/issues/detail?id=52 And I just received an email from yet another user who used it successfully. So I think it's time to graduate this from a hidden feature to a real documented one. -- assignee: docs@python components: Documentation messages: 149552 nosy: bethard, docs@python priority: normal severity: normal stage: needs patch status: open title: document argparse's nargs=REMAINDER type: enhancement versions: Python 3.3 ___ Python tracker <http://bugs.python.org/issue13605> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13584] argparse doesn't respect double quotes
Steven Bethard added the comment: Closing then. Thanks for checking it again! -- assignee: -> bethard resolution: -> works for me stage: -> committed/rejected status: open -> closed ___ Python tracker <http://bugs.python.org/issue13584> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13685] argparse does not sanitize help strings for % signs
Steven Bethard added the comment: Eric's suggested doc fix looks good to me. -- ___ Python tracker <http://bugs.python.org/issue13685> ___ ___ Python-bugs-list mailing list Unsubscribe: http://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
[issue9571] argparse: Allow the use of -- to break out of nargs and into subparser
Steven Bethard added the comment: This is closely related to issue 9338. The parser should know that your command line requires at least the COMMAND argument, so it should stop parsing in time for that. However, in the case of subcommands, even if we solved issue 9338, you would still get the behavior that ./script.py --ignore one two COMMAND arg1 arg2 would get parsed as "arg2" being the command. So I guess there still ought to be a way to tell argparse to stop parsing nargs='+' optionals. Seems like there's also a bug in the current behavior - you should get an error saying that no command was given, not an error saying you issued the command "--". -- ___ Python tracker <http://bugs.python.org/issue9571> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9625] argparse: Problem with defaults for variable nargs
Changes by Steven Bethard : -- nosy: +bethard stage: -> needs patch versions: +Python 2.7, Python 3.2 -Python 2.6 ___ Python tracker <http://bugs.python.org/issue9625> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9653] New default argparse output to be added
Steven Bethard added the comment: A simpler approach might be to do this before your call to parse_args: if len(sys.argv[0]) == 1: parser.print_help() Does that solve your problem? -- ___ Python tracker <http://bugs.python.org/issue9653> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9653] New default argparse output to be added
Steven Bethard added the comment:
Sorry, typo. Should have been len(sys.argv) == 1. Full script:
import argparse
import sys
parser = argparse.ArgumentParser()
parser.add_argument('--foo')
if len(sys.argv) == 1:
parser.print_help()
else:
print(parser.parse_args())
With that script, I see:
$ ./python.exe temp.py
usage: temp.py [-h] [--foo FOO]
optional arguments:
-h, --help show this help message and exit
--foo FOO
--
___
Python tracker
<http://bugs.python.org/issue9653>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9653] New default argparse output to be added
Steven Bethard added the comment: I see. When there are no arguments you basically want to replace the standard argparse help entirely with your own message, with your own capitalization, etc. What you're doing now looks like a pretty good approach for this, so I guess I'm still not clear what you're asking for. Could you suggest a concrete API for argparse that would make it easier to do what you want to do? -- ___ Python tracker <http://bugs.python.org/issue9653> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9694] argparse: Default Help Message Lists Required Args As Optional
Steven Bethard added the comment: Yeah, I guess the optional vs. positional isn't the best terminology now that you can have required flag-based arguments. Did you have a word other than "optional" that you'd prefer? -- ___ Python tracker <http://bugs.python.org/issue9694> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9694] argparse: Default Help Message Lists Required Args As Optional
Steven Bethard added the comment: I guess one possibility might be "flag arguments". It's not great, but I guess it's more accurate. -- ___ Python tracker <http://bugs.python.org/issue9694> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9694] argparse: Default Help Message Lists Required Args As Optional
Steven Bethard added the comment:
And I guess the bigger issue to think about is how to add this in a backwards
compatible way. I guess we could just add methods like
"set_positionals_group_name(name)" and then fiddle with
"self._positionals.title" in there. Not sure that's a great solution though -
it seems like adding one method to change just this single attribute is
overkill and not very general.
In the meantime, here's a workaround:
>>> parser = argparse.ArgumentParser(prog='PROG')
>>> parser.add_argument('--foo', required=True)
>>> parser._optionals.title = "flag arguments"
>>> parser.print_help()
usage: PROG [-h] --foo FOO
flag arguments:
-h, --help show this help message and exit
--foo FOO
I can't promise this will continue to work, since it uses the undocumented
_optionals attribute, but at least it's a way of getting something like what
you want now.
--
___
Python tracker
<http://bugs.python.org/issue9694>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9652] Tidy argparse default output
Steven Bethard added the comment: Looks like "usage" is almost always lowercase in the programs I tried (ssh, svn, cat, etc.). So it probably wouldn't be a good idea to change the default. Seems like both this and issue 9694 need a better way to customize the text in argparse mesages. As a temporary workaround for the group names, you can try: parser._optionals.title = "Optional arguments" parser._positionals.title = "Positional arguments" I can't guarantee this will continue to work since it relies on internal details but at least it would work for the time being. -- ___ Python tracker <http://bugs.python.org/issue9652> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
