Anders Kaseorg added the comment:
It could and does, as quoted in my original report.
Content-Type: text/plain; charset*=utf-8”''utf-8%E2%80%9D
That’s a U+201D right double quotation mark.
This is not a valid charset for the charset of course, but it seems like the
code was intended
Anders Kaseorg added the comment:
> While optparse that it isn't being developed further, therebut will not
> be taken away. IIRC the reason for this was that it too had become
> difficult to build out and that is what necessitated the creation of
> argparse -- there wasn't clea
Anders Kaseorg added the comment:
If argparse will not be developed further to fix this bug, then we should undo
the deprecation of optparse in the documentation
(https://bugs.python.org/issue37103), since the stated justification for that
deprecation was that optparse will not be developed
Anders Kaseorg added the comment:
> extra_states[o] = ExtraState(obj)
(Typo for extra_states[obj] = ExtraState(obj), obviously.)
--
___
Python tracker
<https://bugs.python.org/issu
New submission from Anders Kaseorg :
Because WeakKeyDictionary unconditionally maintains strong references to its
values, the garbage collector fails to collect a reference cycle from a
WeakKeyDictionary value to its key. For example, the following program
unexpectedly leaks memory:
from
New submission from Anders Kaseorg :
We ran into a UnicodeEncodeError exception using email.parser to parse this
email
<https://lists.cam.ac.uk/pipermail/cl-isabelle-users/2021-February/msg00135.html>,
with full headers available in the raw archive
<https://lists.cam.ac.uk/pip
New submission from Anders Kaseorg :
The optparse library is currently marked in the documentation as deprecated in
favor of argparse. However, argparse uses a nonstandard reinterpretation of
Unix command line grammars that makes certain arguments impossible to express,
and causes scripts
Anders Kaseorg added the comment:
porton: Please don’t steal someone else’s issue to report a different bug.
Open a new issue instead.
--
title: argparse: add a full fledged parser as a subparser -> argparse does not
accept options taking arguments beginning with dash (regress
New submission from Anders Kaseorg <ande...@mit.edu>:
PosixPathTest.test_expanduser fails in the NixOS build sandbox, where every
user has home directory /, so it falls off the end of the for pwdent in
pwd.getpwall() loop.
nixbld:x:30001:3:Nix build user:/:/noshell
nobody:x:65534
Anders Kaseorg added the comment:
Usui, this is a tutorial intended for beginners. Even if the change from
“most” to “built-in” were a relevant one (and I don’t see how it is), beginners
cannot possibly be expected to parse that level of meaning out of a single word.
The difference between
Changes by Anders Kaseorg ande...@mit.edu:
--
assignee: docs@python
components: Documentation
nosy: andersk, docs@python
priority: normal
severity: normal
status: open
title: types.NoneType missing
type: behavior
versions: Python 3.2
___
Python
New submission from Anders Kaseorg ande...@mit.edu:
http://docs.python.org/py3k/library/constants.html#None says that None is the
sole value type types.NoneType. However, NoneType was removed from the types
module with Python 3.
--
___
Python
Anders Kaseorg ande...@mit.edu added the comment:
James: That’s not related to this issue. This issue is about options taking
arguments beginning with dash (such as a2x --asciidoc-opts --safe, where --safe
is the argument to --asciidoc-opts), not positional arguments beginning with
dash
New submission from Anders Kaseorg ande...@mit.edu:
This feels like an arbitrary restriction (obvious sequences have been replaced
with ‘…’ to save space in this report):
zip([0], [1], [2], …, [1999])
File stdin, line 1
SyntaxError: more than 255 arguments
especially when this works:
zip
Anders Kaseorg ande...@mit.edu added the comment:
I guess the desugaring is slightly more complicated in the case where the
original function call already used *args or **kwargs:
f(arg0, …, arg999, *args, k0=v0, …, k999=v999, **kwargs)
becomes something like
f(*((arg0, …, arg999) + args
Anders Kaseorg ande...@mit.edu added the comment:
@andersk: Would the restriction to only having flags with a fixed
number of arguments be acceptable for your use case?
I think that’s fine. Anyone coming from optparse won’t need options with
optional arguments.
However, FWIW, GNU
Anders Kaseorg ande...@mit.edu added the comment:
There are some problems that ‘=’ can’t solve, such as options with nargs ≥ 2.
optparse has no trouble with this:
parser = optparse.OptionParser()
parser.add_option('-a', nargs=2)
parser.parse_args(['-a', '-first', '-second'])
(Values
Anders Kaseorg ande...@mit.edu added the comment:
That would be a good first step.
I continue to advocate making that mode the default, because it’s consistent
with how every other command line program works[1], and backwards compatible
with the current argparse behavior.
As far
Anders Kaseorg ande...@mit.edu added the comment:
(1) It's only deprecated in the documentation
Which is why I suggested un-deprecating it in the documentation. (I want to
avoid encouraging programmers to switch away from optparse until this bug is
fixed.)
# proposed behavior
parser
Anders Kaseorg ande...@mit.edu added the comment:
I still disagree. You're giving the parser ambiguous input. If a
parser sees --foo --bar, and --foo is a valid option, but --bar
is not, this is a legitimately ambiguous situation.
There is no ambiguity. According to the way that every
Anders Kaseorg ande...@mit.edu added the comment:
arguments = *(positional-argument / option) [-- *(positional-argument)]
positional-argument = string
option = foo-option / bar-option
foo-option = --foo string
bar-option = --bar
Er, obviously positional arguments before the first
Anders Kaseorg ande...@mit.edu added the comment:
Note that the negative number heuristic you're complaining about
doesn't actually affect your code below.
Yes it does:
import argparse
parser = argparse.ArgumentParser(prog='a2x')
parser.add_argument('--asciidoc-opts',
... action
Anders Kaseorg ande...@mit.edu added the comment:
I don’t think that small change is good enough, if it is still the case that
the only provided example is the dangerous one.
It would be easy to clarify the differences between the classes:
rl = test.ReverseList('spam')
[c for c in rl]
['m
Anders Kaseorg ande...@mit.edu added the comment:
Antoine: That’s true.
Amaury: See my original bug description (“This is reasonable advice for writing
an iterator class, but terrible advice for writing a container class…”), and my
other comments.
There is nothing wrong with explaining how
New submission from Anders Kaseorg ande...@mit.edu:
Porting the a2x program to argparse from the now-deprecated optparse subtly
breaks it when certain options are passed:
$ a2x --asciidoc-opts --safe gitcli.txt
$ ./a2x.argparse --asciidoc-opts --safe gitcli.txt
usage: a2x [-h] [--version
Anders Kaseorg ande...@mit.edu added the comment:
Though in general I find argparse's default behavior more useful.
I’m not sure I understand. Why is it useful for an option parsing library to
heuristically decide, by default, that I didn’t actually want to pass in the
valid option that I
New submission from Anders Kaseorg ande...@mit.edu:
The Python tutorial offers some dangerous advice about adding iterator behavior
to a class:
http://docs.python.org/tutorial/classes.html#iterators
“By now you have probably noticed that most container objects can be looped
over using
Anders Kaseorg ande...@mit.edu added the comment:
As an experienced Python programmer I am obviously aware that the tutorial is
trying to teach how to make an iterator class, not how to make a container
class.
But the tutorial doesn’t make that *clear*. It should be much more explicit
about
28 matches
Mail list logo
