[issue11352] Update cgi module doc
Glenn Linderman added the comment: First I would have to learn how GitHub works, and how PRs work. And I haven't found time for that, as yet. -- ___ Python tracker <https://bugs.python.org/issue11352> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11352] Update cgi module doc
Glenn Linderman added the comment: Seems like another example of the CGI module not getting much support. While I haven't looked at all the details of the patches, it seems that several people have contributed enhancements or clarifications. and it would be a shame to discard them rather than merge the submissions... but it seems no one with authority wants to support CGI. -- status: pending -> open ___ Python tracker <https://bugs.python.org/issue11352> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10483] http.server - what is executable on Windows
Glenn Linderman added the comment: On 11/18/2021 7:36 AM, STINNER Victor wrote: > STINNER Victor added the comment: > > I searched for open issues which contain "cgi" in their title. I found 43 > open issues. The oldest is 101 months ago. > > In 10 years, Lib/cgi.py got 43 commits. Only 13 commits in the last 5 years > (since 2016-01-01). > > It seems like the cgi module is not really maintained anymore. One option is > to do nothing: I guess that the most basic features continue to work. I got the definite feeling 10 years ago that CGI wasn't being maintained, at least for Windows use, and that's why I forked it for private use and enhancement. Nothing in the interim has made me change my mind, and your statistics support that. I got the impression that most core developers used Unix-variants for their development, and likely most CGI users as well, and that Windows use of CGI just wasn't a priority for anyone in the core team. But it has been useful for me, and if a little work were put into supporting it, I suspect it could be useful to others as well. But as a lowly non-core user unfamiliar with the ever-changing processes for submitting patches, I felt rather ignored (which apparently isn't an uncommon issue for users like me), but neither did I have the time to invest to learn the submission protocols, much less to advance to core development status, so I realized that it was partly my fault as well. > Another option is to start deprecating all code related to CGI in the stdlib. > > While CGI is not "commonly" used, it seems like it remains popular for > specific usages. So I don't think that it's time to deprecate it :-) Deprecation would certainly be a disservice to the community, as CGI is the only (as far as I know) universal service available on pretty much all web server implementations. There are probably better interfaces to user-supplied code on many web servers, but the ones I've heard about are not as universal, and not as simple for users to implement. -- ___ Python tracker <https://bugs.python.org/issue10483> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10483] http.server - what is executable on Windows
Glenn Linderman added the comment: Ethan, 3.7.2 at the moment. I doubt there'd be any issues moving it to 3.11, unless there have been significant changes to the main branch in that area, I just haven't bothered because it is working for me as is. I forget what version I started with, but I guess 3.6 was when I first reported it? I know I did have to tweak it a little when I upgraded Python once, and there had been changes to http.server in the meantime. -- ___ Python tracker <https://bugs.python.org/issue10483> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10483] http.server - what is executable on Windows
Glenn Linderman added the comment: As the original author of this report, getting significant pushback from the then maintainer of the code, I went ahead and implemented what I considered to be a useful set of features to make CGI work on Windows. I never proposed them as a patch, because they were bundled with a bunch of other things that certainly would have been considered feature requests, and I never figured out the process for submitting patches, which has changed a couple times since the bug was submitted, and I didn't have time to do all of (1) learn the churning patch mechanisms (2) separate my code changes into independent chunks (3) also get my projects completed The only reason that CGI support on Windows may not be relevant today is that it is so outdated, with no support or encouragement from the maintainers to encourage patches to make it useful, discouraging its use on Windows. With my private, forked implementation, I have a quite useful Windows testbed for implementing web server code that can run on Linux Apache servers. If only there were such support built-in! -- ___ Python tracker <https://bugs.python.org/issue10483> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43046] argparse: capturing actions
Glenn Linderman added the comment: Raymond Hettinger added the comment: >> Sounds like another wet blanket argpment > Please watch your tone. It borders on being abusive. I considered that as a canonical description of the type of negativity presented by your comment. It was not intended to be abusive, just a descriptive summary. > It is entirely appropriate to set limits on the scope of what a module is > trying to achieve. It is appropriate to consider module learnability. It is > appropriate to limit sprawl and feature creep. It is appropriate to consider > whether the pattern being encouraged and supported by the PR is > intellectually manageable by end users. I agree that all those considerations are worthwhile, but I see this as a small extension that adds significant power. No one is forced to use the new features, or the old features, or argparse at all. There are already features in argparse that I simply ignore, because I have no need for them. It doesn't make using the feature I do use more difficult. I just look for what I need, and use those features. > It is correct that argparse set out to handle more complex cases than > optparse. But even then, it was aiming to cases that commonly arose it the > wild (subparsers are not uncommon). It never aspired to be all things to all > users. And unfortunately, in so doing, it failed to support some cases that optparse could handle, although for the cases that argparse could handle, the user code to use it was far simpler. This was improved somewhat by the addition of parse_intermixed_args. Since argparse is provided in stdlib, it seems very reasonable to me to enhance it to support command line parsing paradigms used effectively since 1979, at least (ref: tar). -- ___ Python tracker <https://bugs.python.org/issue43046> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43046] argparse: capturing actions
Glenn Linderman added the comment: Raymond said: ISTM the scope of argparse was never intended to capture all possible patterns for command line argument parsing. Instead, it aimed at to address the common cases. I say: Sounds like another wet blanket argpment. Refer to the section "Why aren't getopt and optparse enough?" in the argparse PEP 389. It is clearn that argparse was intended to implement more complex cases than could be easily implemented with the prior getopt and optparse. The concepts of variable numbers of arguments for an option, and of subcommonds, introduced initially in argparse, are far more complex than the enhancements proposed here. -- ___ Python tracker <https://bugs.python.org/issue43046> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43046] argparse: capturing actions
Glenn Linderman added the comment: So the missing signature is why I didn't understand, probably. At least, it seems reasonable to blame that :) You didn't include [version] in the signature, but that isn't your fault: it isn't in the original and should be (see action "version"). So key is optional and defaults to dest... I saw that, but was already confused. This latest example clears up why you might want to overrride dest for use in different arguments... very similar to why dest is allowed to be specified instead of its default value. And dest could be used, it is sufficient, but allowing specification of key to override it is more flexible, and could save user code in some circumstances, with little cost to the implementation. Sounds good to me now. I was also surprised by introduction of a "capture" action by itself, and look forward to documentation for it, as things progress. I can guess about store_capture and append_capture from the definition of extend_capture. -- ___ Python tracker <https://bugs.python.org/issue43046> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42973] argparse: mixing optional and positional arguments... not again
Glenn Linderman added the comment: paul j3 said: Given how different this is from the normal argparse parsing (and the POSIX parsing argparse seeks to emulate), I question the wisdom of adding this, in part or whole, to the stock distribution. It could certainly be published as a pypi. That already has a number of parsers, some built on argparse, others stand alone. I say: This has been a deficiency of argparse from day one. Tadek's solution seems to enable addressing the deficiency in a backward-compatible manner. Do you, paul, find any test failures? Or any incompatibilities that may not be in the test cases? If not, then it certainly does seem like a wet-blanket comment. paul j3 forther said: I also wonder whether it would be simpler to do this kind of parsing directly from sys.argv. Just step through that list, consuming the values and flags in sequence. I say: The whole point of argparse, and of deprecation of the prior optparse was to make more functionality available in a more powerful API. Increasing the power of the API seems to be consistent with the purpose of argparse. It took me some time and use cases to discover the limitations of argparse, and although parse_intermixed_args solved the use cases I had, I was well aware that it didn't solve cases of every existing Unix utility. -- ___ Python tracker <https://bugs.python.org/issue42973> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43046] argparse: capturing actions
Glenn Linderman added the comment: I'm a little confused by the mention of the "key" keyword argument. I suspect that is an internal concept to argparse, possibly passed that way to internal methods, but on the add_argument interface, it doesn't exist... instead there is "name or flags" positional arguments, from which, together with the "dest" argument, the "key" keyword argument is derived. This is described under the explanation for the "dest" parameter. But in the user documentation, the use of "key" is a surprise (to me, maybe I missed something). Perhaps using "dest" rather than "key" in this documentation would be better? Or perhaps there is a precedent in the argparse documentation for what to call it? -- ___ Python tracker <https://bugs.python.org/issue43046> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42973] argparse: mixing optional and positional arguments... not again
Glenn Linderman added the comment: Yes I think this is a useful enabling step toward enhanced functionality, as is. But I think the learning curve to achieve the enhanced functionality is a bit high for most people, as it requires too much knowledge of argparse internals, so I really look forward to your followon work on 'capture' actions. which will be an enhancement that will not require internals knowledge, and will resolve a day-one deficiency in argparse in a nicely backward-compatible manner. -- ___ Python tracker <https://bugs.python.org/issue42973> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42973] argparse: mixing optional and positional arguments... not again
Glenn Linderman added the comment:
Paul said:
I haven't had a chance to study your longer posts, but it seems to me that the
AddFruitAction example could just as well be implemented with
parser.add_argument('--color', nargs='*', action='append')
with post parsing processing to create the 'fruits' dicts from the appended
lists.
That was also my first reaction, Paul, when I read Tadek's proposal. But I
quickly realized that particularly with the feature of "capture and reset to
default" that the number of instances of a particular optional and the number
of positionals do not always match, and there is no way to correlate them
later, even if they are all captured and saved.
--
___
Python tracker
<https://bugs.python.org/issue42973>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42973] argparse: mixing optional and positional arguments... not again
Glenn Linderman added the comment:
This sounds very good to me. Might also want action='store_capture' for a
single positional definition?
capture could be a string, or any iterable of strings (tuple comes to mind)
capture_once have similar value as capture, but I wonder if the naming would be
better as capture_reset to indicate the value is reset to default, rather than
just captured.
Tadek said:
There could be new predefined action, e.g. 'extend_with_capture' (or just
'extend_capture') which could be used like this:
parser.add_argument('fruits', nargs='*', action='extend_capture',
capture_once=['color'])
Where 'capture' would be one of: a list of parameters to capture (could be a
string instead of a list if it's just one parameter) or '*' to capture all
optional parameters and 'capture_once' would be similar list of parameters to
capture and reset to default.
--
___
Python tracker
<https://bugs.python.org/issue42973>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42973] argparse: mixing optional and positional arguments... not again
Glenn Linderman added the comment: for more helpful => far more helpful -- ___ Python tracker <https://bugs.python.org/issue42973> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42973] argparse: mixing optional and positional arguments... not again
Glenn Linderman added the comment: OK, I think I see what you are doing here. Thanks for your responses. And probably it is the bare-bones minimum feature that allows user-implementation of "as complex as desired" combinations of optionals and context-sensitive positionals. In the docs fruits example, though, I think the input and output are inconsistent: you have a brown banana reported as yellow? I guess I could think of enhancements to simplify common cases. For example, each positional might want to track/save values for some number of optionals. So one could write custom code to do that, like your fruit basket, or one could imagine a canned approach, where the list of optionals was passed as a parameter when defining the positionals. This could be built as a wrapper for add_argument, that would call a more general version of the AddFruit Action. Perhaps a special parameter could also indicate saving the values of all optionals at the point of parsing the positional, giving each positional a complete set of optionals that apply. Your feature of having the optional apply to only one positional would be a harder thing, especially if you wanted to have both kinds of optionals: that apply to the next positional, or that apply to all following positionals. But hmm. Maybe not much harder: just have two lists of optionals passed to the positional: a list of each kind. Does the namespace still contain the default value for an optional after it has been used? It looks like it might, so your fruit example could be reduced to not needing the DEFAULT_COLOR variable, but rather change references to it to use self._get_default_metavar_for_positional(action) ? That avoids using a global variable, and is for more helpful for the "list of optionals to be reset on each use" rather than re-creating the more complex data structure required to hold all the defaults. I'm not sure how that plays with optionals that use append or append_const storage methods, nor do I fully understand the comment in "def _copy_items(items):" I think if you could avoid the global variable, your implementation would be stronger. And if you provide, either as a sample subclass, or argparse new feature, the ability to do the things I mention here, it would be even stronger, as it would allow the user to deal with the more powerful capabilities without needing as much understanding of argparse internals. -- ___ Python tracker <https://bugs.python.org/issue42973> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42973] argparse: mixing optional and positional arguments... not again
Glenn Linderman added the comment: On 1/25/2021 12:43 PM, Tadek Kijkowski wrote: > Tadek Kijkowski added the comment: > > I added tests and docs to the PR. How does it look now? Could you send me the docs privately? I'm trying to understand what you are suggesting, without reading the code. I realize that you are trying to apply different values of optional parameters to positional parameters... how are you saving that context? Is it up to the special handler of the positional parameter to read and save the values of the optional parameters specified so far? What about the ones unspecified so far? Can one even read and save the default value? And where does it get stored? Is the value of the positional parameter turned into a dict or class containing its own value + the saved optional parameters? I do agree that the even though the parse_intermixed_args was sufficient for the use case I had at the time, and has been sufficient for me so far, that it not fully flexible, and I think I have seen Unix command line programs that had rich semantics similar to what you are proposing, where the sequence of repeated optional args could affect handling of later positionals but not earlier ones. So I applaud your efforts here, but simply reading the issue, and having forgotten most of the internal workings of argument parser since getting the compromise going, I think reading your docs would help clarify it for me. -- ___ Python tracker <https://bugs.python.org/issue42973> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42973] argparse: mixing optional and positional arguments... not again
Change by Glenn Linderman : -- nosy: +v+python ___ Python tracker <https://bugs.python.org/issue42973> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40284] Add mapping methods to types.SimpleNamespace
Glenn Linderman added the comment: Here's what I have. Maybe it would be better if parse and dump were under or dunder names, although I think parse was in the original implementation I found. Is this the derived from the same original as PyPI dotable? Not sure. -- Added file: https://bugs.python.org/file49061/Dotable.py ___ Python tracker <https://bugs.python.org/issue40284> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40284] Add mapping methods to types.SimpleNamespace
Glenn Linderman added the comment: Yes, I laud this effort. I don't care if it is called SimpleNamespace (which I didn't use because it was insufficient), or anything else, but it would be extremely handy to have this battery. I eventually found one called Dotable (or did I rename it to that?) which after a fair bit of study I finally understood, and then was able to add a few tweaks to make it work the way that was most convenient for me. While I agree with Guido that these are not standard Python semantics, they are, as pointed out by Raymond, far more convenient to use for nested structures. And as far as using CoffeeScript, I don't know of a CoffeeScript to Python conversion: the rest of the semantics of Python are more preferable than Javascript. I just wish Brendan Eich had consulted with Guido before inventing Javascript. -- nosy: +v+python ___ Python tracker <https://bugs.python.org/issue40284> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28029] Replace and empty strings
Glenn Linderman added the comment: Nope: I guess for x.replace( a, b, c ) the workaround would be x.replace( a, b, c ) if x else x.replace( a, b ) -- ___ Python tracker <https://bugs.python.org/issue28029> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28029] Replace and empty strings
Glenn Linderman added the comment: Thanks Stèphańe and Serhiy, I just discovered this strange behavior in 3.8, and wondered how my logic was wrong, until I pinpointed the inconsistent behaviour of str.replace with an empty first parameter and replace count of 1. Glad to see it is fixed in 3.9. I guess for x.replace( a, b, c ) the workaround would be x.replace( a, b, c ) if a else x.replace( a, b ) At least for recent versions of Python 3. -- nosy: +v+python ___ Python tracker <https://bugs.python.org/issue28029> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37816] f-string documentation not fully accurate
New submission from Glenn Linderman :
I noticed the following description for f-strings:
> Escape sequences are decoded like in ordinary string literals (except when a
> literal is also marked as a raw string). After decoding, the grammar for the
> contents of the string is:
followed by lots of stuff, followed by
> Backslashes are not allowed in format expressions and will raise an error:
> f"newline: {ord('\n')}" # raises SyntaxError
If f-strings are processed AS DESCRIBED, the \n would never seen by the format
expression... but in fact, it does produce an error.
PEP 498 has a more accurate description, that the {} parsing actually happens
before the escape processing. The string or raw-string escape processing is
done only to the literal string pieces.
So the string content is first parsed for format expressions enclosed in {}, on
the way, converting {{ and }} to { and } in the literal parts of the string,
and then the literal parts are treated exactly like independent string literals
(with regular or raw-string escaping performed), to be concatenated with the
evaluation of the format expressions, and subsequent literal parts.
The evaluation of the format expressions presently precludes the use of # and \
for comments and escapes, but otherwise tries to sort of by the same as a
python expression possibly followed by a format mini-language part. I am not
the expert here, just the messenger.
--
assignee: docs@python
components: Documentation
messages: 349370
nosy: docs@python, v+python
priority: normal
severity: normal
status: open
title: f-string documentation not fully accurate
versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issue37816>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37490] poor documentation for .startswith, .endswith
Glenn Linderman added the comment: Thanks for the explanations and suggestions. Now that I think I know what those parameters are used for... Sorry, my first example was tweaked on the fly, and doesn't make as much sense as it could because it wound up being a mix of pre-tweaked and tweaked text, as Steven points out at the beginning of msg347194. But the text he suggests in msg347195 would be an immense clarification to the existing text. The existing text is worded in such a way that it is not clear how the start and end parameters affect the search, except by analogy with other slicing operations in other parts of Python. Steven may be willing to draw such analogies to perceive that the current startswith documentation is clear, but if you go in with an open mind, uncluttered with the better-specified behavior of other Python operations, there are lots of possible interpretations. Describing the start/end parameters with defaults and explaining the whole operation as referring to the slice specified by those parameters makes it far less open to other interpretations. The text Aldwin suggests in msg347188 (from re) is better than the original for startswith/endswith, but is not as clear as Steven's wording. I would actually suggest that Steven's wording could be the basis for an improvement for the re docs as quoted. The second part, the "prefix can also be a tuple of prefixes to look for" could also be improved... neither prefix nor tuple of prefixes is defined as being a string. Further, if the parameter syntax is shown with the defaults, then the parethetical comments about (defaults to...) are not really necessary, simplifying the description to: The prefix parameter can be a single string, or a tuple of strings. Return True if the slice of string specified by [start:end] starts with any complete string supplied as part of the prefix parameter, otherwise return False. -- ___ Python tracker <https://bugs.python.org/issue37490> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37490] poor documentation for .startswith, .endswith
Glenn Linderman added the comment:
Or is
text.startswith(('day', 'month', 'year'), 8, 12)
the same as
text[8:12] in ('day', 'month', 'year')
What happens if the text doesn't have as many as 12 characters? What if it
doesn't have more than 8 characters?
--
___
Python tracker
<https://bugs.python.org/issue37490>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37490] poor documentation for .startswith, .endswith
New submission from Glenn Linderman :
The documentation is reasonably clear regarding the first parameter, which can
be a string or a tuple of strings to match at the start or end of a string.
However, the other two parameters are much less clear in their effect.
text = "Now the day is over"
text.startswith('the', 2, 8)
Does it produce True because 'w the' is at the beginning of the text[2:] ?
Maybe. Or because there is an ending position, must it fail because it doesn't
match all of text[2:8] ?
text.startswith('day', 8, 10)
Does this produce True because everything in day matches text[8:10] or must it
always produce false for any value of text because the match is never as long
as the prefix string?
text.startswith(('day', 'month', 'year'), 8, 12)
Can this ever match day or month, because it is comparing to text[8:12], or can
only year match because of the start and end?
Is there a difference between the following:
text.startswith(('day', 'month', 'year'), 8, 12)
text[8:12].startswith(('day', 'month', 'year'))
If no difference, why does startswith even need the extra two parameters? Maybe
only in performance?
If no difference, why doesn't the documentation describe it that way, so that
it could be far clearer?
If there is a difference, what is the difference?
Similar questions for endswith.
--
messages: 347179
nosy: v+python
priority: normal
severity: normal
status: open
title: poor documentation for .startswith, .endswith
___
Python tracker
<https://bugs.python.org/issue37490>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37018] put http.server on a diet
New submission from Glenn Linderman : The idea inspired by the email exchange below is basically in three parts: 1. investigate the various popular web server frameworks, to determine what parts of http.server they depend on. For example, bottle.py depends only on BaseHTTPRequestHandler and HTTPServer, which is less than half the code in http.server. Because of the deficiencies in the remaining parts, it seems unlikely that other frameworks use much more. 2. Trim http.server to those useful parts, removing the the rest from stdlib. Many of the "enhanced features" of http.server are such minimal enhancements that they are feature-poor and out-of-date with respect to current web server standards. The novice user is likely to be enticed into a swamp of missing capability when attempting to use them, as I was. It would take significant work to implement true CGI together with SSL on forking OSes; it took me significant work to implement true CGI together with SSL on Windows (non-forking). I gave up trying to do it on Linux, and switched to bottle. 3. Enhance what is left of http.server to support SSL and threading, so that the web frameworks that use http.server as a test server can at least offer those capabilities as well. It isn't too hard to add those things for bottle.py, but it would be nicer if users didn't have to google for the blog posts that show how, and reimplement it (most of the blog posts are somewhat dated). On 5/22/2019 4:09 AM, Christian Heimes wrote: > On 22/05/2019 01.11, Glenn Linderman wrote: >> On 5/21/2019 2:00 PM, Nathaniel Smith wrote: >>> On Tue, May 21, 2019 at 10:43 AM Glenn Linderman >>> wrote: >>>> After maintaining my own version of http.server to fix or workaround some >>>> of its deficiencies for some years, I discovered bottle.py. It has far >>>> more capability, is far better documented, and is just as quick to deploy. >>>> While I haven't yet converted all past projects to use bottle.py, it will >>>> likely happen in time, unless something even simpler to use is discovered, >>>> although I can hardly imagine that happening. >>> bottle.py uses http.server for its local development mode (the one you >>> see in their quickstart example at the top of their README). Same with >>> flask, django, and probably a bunch of other frameworks. It's *very* >>> widely used. >>> >>> -n >>> >> The source for bottle.py version 0.13-dev has an import for http.client, but >> not http.server. I hadn't tracked down every indirect dependency in the >> bottle.py source code, but it seems that if one uses the "default server" >> for bottle, that it is "wsgiref", imported from wsgiref.simple_server, and >> that in turn does import BaseHTTPRequestHandler and HTTPServer from >> http.server. >> >> It is the higher-level code in http.server that has significant deficiencies >> that have caused me problems over the years... a "SimpleHTTPRequestHandler" >> that is so simple it doesn't do POST, PUT or PASTE, a >> "CGIHTTPRequestHandler" that only implements part of the CGI protocol, only >> CGI support in POST, no support for PUT or PASTE, and no support for https, >> and not much bug fix activity in those areas. >> >> Maybe http.server should be split into the "basic parts" (used by bottle.py, >> and other frameworks), and the "higher-level parts", which could then be >> discarded by this PEP! At this point, though, I'd have to agree that the >> whole should not be discarded. Thanks for making me dig deeper. > > The idea has merrit. However I feel its out of scope for the PEP [594]. The > http.server module and socketserver module are still widely used for debug > and toy examples. > > Could you please open a bug to track your proposal? We may pursue it in a > couple of years from now. -- messages: 343275 nosy: v+python priority: normal severity: normal status: open title: put http.server on a diet ___ Python tracker <https://bugs.python.org/issue37018> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36863] argparse doesn't like options in the middle of arguments
Change by Glenn Linderman : -- nosy: +v+python ___ Python tracker <https://bugs.python.org/issue36863> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10486] http.server doesn't set all CGI environment variables
Glenn Linderman added the comment: That's interesting, Pierre, I hadn't really read the RFC carefully, to realize that many of the "missing" variables from Apache are HTTP headers, and that section 4.1.18 tell how to convert HTTP headers to meta variables. The code in server.py 3.6 (Sorry, I should check the master branch) picks specific HTTP_ headers to include, rather than including them all per the rules. Doing the latter would go a long way toward being more compatible with Apache. I don't know if Rémi got his NGINX list from source code (looks like it) and if maybe NGINX also defines meta variables from the HTTP_ headers, that are not listed in the header file he seems to be quoting. Unless the code has already been improved for Python 3.7, I think there is still some work to do to make server.py conform even to the RFC, if not be compatible with Apache. -- ___ Python tracker <https://bugs.python.org/issue10486> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10486] http.server doesn't set all CGI environment variables
Glenn Linderman added the comment: Rémi Lapeyre, glad to see your interest here, as this is an old and languishing bug. I would have hoped based on my input, that had there been anyone that was maintaining the Python web server code, that they might have done a more complete analysis than I did. I note the document you reference is from 2004 (and I referenced it too), and doesn't include mention of the HTTP_COOKIE header, yet that header is frequently used in practical web applications. Apache supports it (as noted). My point is that it is not clear that conforming to the RFC 3875 from 2004 is really sufficient to build a useful web server. While it is true that my references to Apache are to a particular implementation, it is a widespread implementation, which other implementations attempt to be compatible with, indicating that being reasonably compatible with Apache would seem to be a good thing for other web server implementations. A few more environment variables don't cost a lot, and seem to be useful. I don't know if some or all of the additional environment variables implemented by Apache are standardized by RFC or other standards, or whether they are common practice, or unique to Apache. Nor where such standards might be fonud, but I would hope a maintainer of the Python web server would be interested in sorting out such environment variables and making that determination, rather than relying on a 14 year old RFC as the definitive source, when web technologies have progressed significantly in the last 14 years. I would agree that variables that are unique to Apache might not want to be implemented, but on the other hand, with other implementations following Apache's lead, there may be few that are unique to Apache. -- ___ Python tracker <https://bugs.python.org/issue10486> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28044] Make the sidebar in the documentation follow the section automatically
Glenn Linderman added the comment: Uh, thanks, I guess, but it wasn't marked out of date or resolved or closed when I commented. I haven't used the GitHub issue tracker. Sigh. There should be a link here to the issue that was copied there, to make it easy and obvious? -- nosy: -Mariatta ___ Python tracker <https://bugs.python.org/issue28044> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28044] Make the sidebar in the documentation follow the section automatically
Glenn Linderman added the comment: Nice implementation of sticky sidebar. https://css-tricks.com/sticky-smooth-active-nav/#more-273952 I haven't looked at the patch, and don't know what R. David Murray doesn't like about how it works, but I find the Python sidebar extremely annoying because it scrolls off the top, and would rather it stayed around visible. -- nosy: +v+python ___ Python tracker <https://bugs.python.org/issue28044> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32983] UnicodeDecodeError 'ascii' codec can't decode byte in position - ordinal not in range(128)
Glenn Linderman <v+pyt...@g.nevcal.com> added the comment: The problem here is that the error message is trying to write to an output device using ASCII. If there is no error, there is no error message print attempt. The error message, when written to an ASCII device, needs to be escaped. You don't show the code, so it is hard to say more about the issue. -- nosy: +v+python ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32983> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32982] Parse out invisible Unicode characters?
Glenn Linderman <v+pyt...@g.nevcal.com> added the comment: Characters should not be stripped during compilation. But I can see where it might be helpful if the codepoint of the character, and the printed form just in case it is printable, could helpfully be included in the error message, as well as having the ^ pointer pointing to it. -- nosy: +v+python ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32982> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31639] http.server and SimpleHTTPServer hang after a few requests
Glenn Linderman <v+pyt...@g.nevcal.com> added the comment: I don't know how to look back at the previous version of the PR, I was barely able to find the "current version" each time. The following line is in the current version: daemon_threads = True Whether it was in the previous version, I don't know, but I didn't notice it, but maybe I overlooked it due to other changes in the same area, which are now gone. This line was not in the old suggestion that I had found and tried. When I added it, my test case started working. I have no idea what the line really does, but the HTTP server is a daemon, and we are adding threading, so it sounds appropriate. I do wonder if it should somehow be put in the definition of ThreadedHTTPServer instead of "pass". And the old solution I had found had called the HTTPServer.__init__ which yours does not, which was surprising, but I'll not argue with success. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31639> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31639] http.server and SimpleHTTPServer hang after a few requests
Glenn Linderman <v+pyt...@g.nevcal.com> added the comment: I tried the approach in the PR "externally" (when starting the server using a test program), and I couldn't get it to work. But my test case was probably different: I was using Chrome rather than Chromium, and while they both work for me for simple HTTP file access to localhost without threading, I had tried to set up a PWA with a service worker, and maybe that does something different, so I got the hang, applied the Threading.mixIn, and it still hung. I don't know how to tell for sure if it is the same sort of hang, or something different, in the Windows environment. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31639> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31639] http.server and SimpleHTTPServer hang after a few requests
Glenn Linderman <v+pyt...@g.nevcal.com> added the comment: This probably has been around for a while: this 2011 thread in a Chromium wontfix bug is enlightening, but the solution suggested, a ThreadingMixIn for the HTTPServer, didn't help me. https://bugs.chromium.org/p/chromium/issues/detail?id=195550 -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31639> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31639] http.server and SimpleHTTPServer hang after a few requests
Glenn Linderman <v+pyt...@g.nevcal.com> added the comment: Same behavior on Windows. -- components: +Windows nosy: +paul.moore, steve.dower, tim.golden, v+python, zach.ware ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31639> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32263] Template string docs refer to "normal %-based substitutions"
New submission from Glenn Linderman <v+pyt...@g.nevcal.com>:
At least as far back as Python 3.1, the description for Template strings
(section 6.1.5 in version 3.6.4rc1 docs) starts by differentiating what
Template strings do, as:
Instead of the normal %-based substitutions, Templates support $-based
substitutions, using the following rules:
Since this immediately follows a section describing the "Custom String
Formatting" and the "Format Specification Mini-Language", which does a type of
substitutions that is {} based, rather than % based, it is hard to grasp
exactly why %-based substitutions would be considered "normal". Of course, I
know why, due to the % operator, but for someone just reading through chapter
6, it is a reference that raises the mental question "Huh? What is normal
%-based substitution? Are Templates abnormal, if %-based substitutions are
normal? What did I miss? The previous section was about {}-based substitutions?
Are they abnormal, too? What are normal %-based substitutions, anyway?" rather
than helping to describe what Templates are and do.
--
assignee: docs@python
components: Documentation
messages: 307922
nosy: docs@python, v+python
priority: normal
severity: normal
status: open
title: Template string docs refer to "normal %-based substitutions"
versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32263>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14191] argparse doesn't allow optionals within positionals
Glenn Linderman added the comment: I would dearly love to discard my private copies of argparse subclasses to implement this that I have been using for the last 5 years. Please, some other committer, concur here! -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue14191> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30576] http.server should support HTTP compression (gzip)
Glenn Linderman added the comment: "veery" should be "veering" in above comment, sorry. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30576> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30576] http.server should support HTTP compression (gzip)
Glenn Linderman added the comment: Martin, I understood what you meant, but sadly, doing that least to confusion. Follow your link, it displays fine, and then save the file. At least in Firefox, the default name to save as is "nGzip — A File Compressor.html". This looks appropriate, but the saved file is actually the compressed .gz form, so attempting to display it later, from the default name, displays the compressed gibberish, because the name does not reflect the encoding. Perhaps this should be considered a Firefox bug? Chrome saves the uncompressed version with the same default name. I can't actually figure out how to save the file from Edge, so don't know what it might do. I'm surprised that Firefox, since it saves the compressed version, didn't offer the name "index.en.html.gz", and that Chrome, for the uncompressed version, didn't offer "index.en.html". Deriving the name from the title feels weird, but maybe only because I create web pages, and know what the real file names are. But this paragraph, other than the lack of ".gz" for Firefox naming, is veery off-topic. The point I'm trying to make, though, is that the URIs shouldn't contain file extensions that include the compression, because that is confusing. The compression should be an internally negotiated detail between the browser and the web server, and the URI should reflect the content to be displayed, not the form in which it was encoded for transfer (or storage). When .gz or .br is included in the URI, I would expect the browser to offer to save it to disk as a binary, compressed file, just like .zip. The variant behavior of Firefox and Chrome makes me wonder if there is even a standard that applies in this area... if there is, and if either one of them is following it, it is certainly not what I would expect. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30576> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30576] http.server should support HTTP compression (gzip)
Glenn Linderman added the comment: @martin sez: It may be reasonable to serve the Content-Encoding field based on the stored file though. If the client requests file “xyz”, there should be no encoding, but if the request was explicitly for “xyz.gz”, the server could add Content-Encoding. But I suspect this won’t help Pierre. I think this suggestion violates the mapping between file name and expected data type: if the request is for "xyz.gz" then the requester wants the compressed form of the file "xyz", but adding the Content-Encoding header would cause (most known) browsers to decode the file in the network stack, and the resulting file displayed or saved would be the uncompressed form, with the compressed name. While my implementation of the compression technique I outlined is, in fact, in a higher-level server which runs on top of either http.server or Apache, my perception of having to implement it at that level was that this is the sort of thing that the low-level server should be capable of, via configuration settings. I note that for Apache, both mod_deflate and mod_brotli support either on-the-fly or pre-compressed data files, so it would appear that the authors of those modules agree with my perception that this should be a low-level server configuration thing. Your example of a /tmp server, Martin, serves to point out the benefits of having pre-compressed files... much less storage is required. I haven't looked at the pull request in detail: I'm not particularly interested in on-the-fly compression, but I wasn't certain until Pierre responded exactly what he was proposing. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30576> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30576] http.server should support HTTP compression (gzip)
Glenn Linderman added the comment: I don't understand fully what you are planning here: to pre-compress the files, or to compress on the fly as mentioned by another commenter? I've implemented, in a CGI behind http.server, both .gz and .br (gzip and brotli) compression, following these rules: User requests file xyz If xyz doesn't exist, then look for xyz.gz or xyz.br. If one of them exists, then serve it. But if the browser doesn't support gzip or br (as appropriate) then decompress on the fly, otherwise set the appropriate Content-Encoding, and send the compressed file. This has worked out well. Of course, .br is only supported for https: transfers. Most browsers support it now, except Apple. -- nosy: +v+python ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30576> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5053] http.client.HTTPMessage.getallmatchingheaders() always returns []
Glenn Linderman added the comment: It is certainly true that getallmatchingheaders is broken... because the data it is looking at has changed format. Here is a replacement that is as compatible as can be, based on the changed format. name = name.lower() n = len(name) lst = [] for line, data in self.items(): if line.lower() == name: lst.append(line + ': ' + data) return lst The changed format has merged continuation lines, and separated keys and values into a list of duplet tuples. Iterators keys, values, and items exist, keys are not necessarily unique. -- nosy: +v+python ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue5053> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29654] SimpleHTTPRequestHandler should support browser cache
Changes by Glenn Linderman <v+pyt...@g.nevcal.com>: -- nosy: +v+python ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29654> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29059] Windows: Python not using ANSI compatible console
Glenn Linderman added the comment: Re: curses... maybe that becomes a DOCS issue, to mention the available packages. But it would be easier, no doubt to port curses to a known existing escape sequence control set, than to use a bunch arcane, foreign-to-the-Unix-porter-that-wants-curses obscure and seldom discussed Windows APIs. IIRC, ANSI is somewhat incompatible with sending random binary gibberish to the screen, as people accidentally do with TYPE sometimes :) But the random binary gibberish may contain ANSI control sequences... That's why I'm negative on making it a default. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29059> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29059] Windows: Python not using ANSI compatible console
Glenn Linderman added the comment: Nice idea, but not by default. An easy way to switch back and forth, and to be sure the original mode is restored on process exit would be a win. Most windows users want a real GUI, not curses, but compatibility with VT escape codes for cross-platform semi-GUI stuff could be useful... and could enable the stdlib curses to be included in Python for windows also? I'm not sure why it isn't, and "ANSI" a.k.a. VT escape codes have been available in Windows for a long time... but until Python 3.6.0 (thanks again Steve, and others), Windows console handling in Python has been extremely limited. Also note that UniCurses and Pygcurse exist and provide similar capabilities. -- nosy: +v+python ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29059> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14565] Allow multilevel subdirectories in cgi_directories
Glenn Linderman added the comment: Martin, thanks for the recent activity in this area. Sorry I've not yet learned how to submit patches. python_dev keeps busy changing the process and tools, and I keep busy with other projects, having patched a version of http-server well enough for my personal needs. Your analysis that this is a new feature because the code doesn't support it, and the documentation is vague has some merit. On the other hand, the reason I called it a behavior bug in the first place is comparison to other web servers that support multi-part paths to cgi scripts indicates it is clearly deficient by comparison... and the documentation isn't explicit enough to say so, so it can be considered a "deficient" if not "buggy" implementation. Certainly, any attempt to port a real web site that depends heavily on cgi scripts to http-server would be extremely likely to fail due to this deficiency, that is not documented as a limitation of the "generally expected" abilities of a web server. It'd sure be nice to fix it, whether it is called a bug or an enhancement, and the fix is in the comments above. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue14565> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1602] windows console doesn't print or input Unicode
Glenn Linderman added the comment: Just to note that another side effect of this bug is that stepping through code where the source contains non-ASCII characters results in pdb producing an error when trying to print the source lines. This makes stepping through such source code impossible. I mention it, because it hasn't been mentioned before, and debuggers are mysterious and low-level enough, that solutions that might work for normal code, may not solve working with the debugger... -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1602 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1602] windows console doesn't print or input Unicode
Glenn Linderman added the comment: Mark, the /U and /A switches to CMD only affect (as the help messages say) the output of internal CMD commands. So they would only affect interoperability between internal command output piped to a Python program. The biggest issue in this bug, however, is the output of Python programs not being properly displayed by the console window (often thought of or described as the CMD shell window). While my biggest concerns have been with output, I suppose input can be an issue also, and running the output of echo, or other internal commands, into Python could be an issue as well. I have pasted a variety of data into Python programs beyond ASCII, but I'm not sure I've gone beyond ANSI or beyond Unicode BMP. Obviously, once output is working properly, input should also be tested and fixed, although I think output is more critical. With the impetus of your question... I just took some text supplied in another context that has a bunch of characters from different repertoires, including non-BMP, and tried to paste it into the console window. Here is the text: こんにちは世界 - fine on Linux, all boxes on Windows (all boxes in Chrome on Linux too) مرحبا، العالم! - fine on Linux and Windows 안녕하세요, 세계! - fine on Linux, just boxes and punctuation on Windows (likewise in Chrome) Привет, мир! - fine on Linux and Windows Αυτή είναι μια δοκιμή - fine on both, but Google Translate has a problem with this! It returned Hello, world! as the Greek for Hello, world!... so I tried again with This is a test. 퓗퓮퓵퓵퓸, 픀퓸퓻퓵퓭! - not actually a language, but this is astral In the console window, which I have configured using the Consolas font, the glyphs for the non-ASCII characters in the first two and last lines were boxes... likely Consolas doesn't support those characters. I had written a Python equivalent of echo, including some workarounds originally posted in this issue, and got exactly the same output as input, with no errors produced. So it is a bit difficult to test characters outside the repertoire of whatever font is configured for the console window. Perhaps someone that has Chinese or Korean fonts configured for their console window could report on further testing of the above or similar strings. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1602 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1602] windows console doesn't print or input Unicode
Glenn Linderman added the comment: This bug deserves to stay open with its high priority (for whatever good that does these last seven years, although I appreciate all the efforts put forth, and have been making heavy use of the workarounds in the patches), because when working with Unicode data in programs, even exception messages are not properly displayed... instead, they cause a secondary exception of not being able to display the data of the original exception to the console. And writing Unicode data to the console as part of an interactive or command line program has to either be done with the hopes that the data only includes characters in the console, to avoid the failures, or with lots of special encoding calls and character substitutions for code points not in the console repertoire. Remember that the console is supposed to be human readable, not encoded numerically as ascii() would do. ascii() is sort of OK for for exception messages, but since that doesn't happen by default, the initial message to the console with Unicode data often doesn't appear, and an extra repetition after a failed message and a rework of the message parameters is required, which impedes productivity. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1602 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21666] Argparse exceptions should include which argument has a problem
Glenn Linderman added the comment: Yes, I hope someday the parse_intermixed_args patch can be released... but I know it is not relevant to this issue. I was aware of the %(substitution_variables) in the default help formatter, but I (1) goofed and entered % without escaping it (2) was surprised at how unhelpful the Traceback was at isolating the problem. Happily, my code had only a few instances of %) so I was able to isolate it fairly quickly, but the error report certainly shows up at quite a distance (execution-wise) from the location of the source bug. I haven't looked at the source for the HelpFormatter code: if it concatenates all the help text and then does substitutions en masse, then it would be difficult to isolate the error to a particular argument. If, on the other hand, it loops through the help text for each argument, doing the substitutions, and later formatting and concatenating, then surrounding the substitution attempt with a try: block so that the name of the argument with the faulty help text could be reported, that would be a big help to this situation, at little cost. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21666 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21666] Argparse exceptions should include which argument has a problem
New submission from Glenn Linderman: I coded up a new program, with a bunch of options, and got the following traceback when I tried to run it: Traceback (most recent call last): File D:\my\py\renmany.py, line 273, in module args = cmdl.parse_intermixed_args() File D:\my\py\glu\glu.py, line 1695, in parse_intermixed_args args, argv = self.parse_known_intermixed_args(args, namespace) File D:\my\py\glu\glu.py, line 1740, in parse_known_intermixed_args namespace, remaining_args = self.parse_known_args(args, namespace) File C:\Python33\lib\argparse.py, line 1737, in parse_known_args namespace, args = self._parse_known_args(args, namespace) File C:\Python33\lib\argparse.py, line 1943, in _parse_known_args start_index = consume_optional(start_index) File C:\Python33\lib\argparse.py, line 1883, in consume_optional take_action(action, args, option_string) File C:\Python33\lib\argparse.py, line 1811, in take_action action(self, namespace, argument_values, option_string) File C:\Python33\lib\argparse.py, line 1015, in __call__ parser.print_help() File C:\Python33\lib\argparse.py, line 2339, in print_help self._print_message(self.format_help(), file) File C:\Python33\lib\argparse.py, line 2323, in format_help return formatter.format_help() File C:\Python33\lib\argparse.py, line 276, in format_help help = self._root_section.format_help() File C:\Python33\lib\argparse.py, line 206, in format_help func(*args) File C:\Python33\lib\argparse.py, line 206, in format_help func(*args) File C:\Python33\lib\argparse.py, line 513, in _format_action help_text = self._expand_help(action) File C:\Python33\lib\argparse.py, line 600, in _expand_help return self._get_help_string(action) % params ValueError: unsupported format character ')' (0x29) at index 673 The only thing I can tell is that something went wrong in ArgParse. I had called a bunch of add_argument, and then a parse_known_args. I had passed parameters to the program to get a help message, so that is what I expect parse_known_args is trying to produce... and the call stack seems to confirm that. I didn't intentionally pass a format character ')' anywhere, but there are ')' characters in some of my help messages, so that is probably the source of the problem. No doubt I can reduce the problem space by judiciously commenting out things until I can isolate the particular help message that is causing the failure (it may be more than one as several are similar). But it seems like the exception should include the name of the argument for which the failure occurred. [OK, I isolated, and found a %) sequence in one of my messages that should have been %%). So this is not terribly urgent, just poor reporting.] -- messages: 219778 nosy: v+python priority: normal severity: normal status: open title: Argparse exceptions should include which argument has a problem ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21666 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21666] Argparse exceptions should include which argument has a problem
Changes by Glenn Linderman v+pyt...@g.nevcal.com: -- type: - enhancement ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21666 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1191964] asynchronous Subprocess
Changes by Glenn Linderman v+pyt...@g.nevcal.com: -- nosy: +v+python ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1191964 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1602] windows console doesn't print or input Unicode
Glenn Linderman added the comment: Hi Drekin. Thanks for your work in progressing this issue. There have been a variety of techniques proposed for this issue, but it sounds like yours has built on what the others learned, and is close to complete, together with issue 17620. Is this in a form that can be used with Python 3.3? or 3.4 alpha? Can it be loaded externally from a script, or must it be compiled into Python, or both? I've been using a variant of davidsarah's patch since 2 years now, but would like to take yours out for a spin. Is there a Complete Idiot's guide to using your patch? :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1602 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14191] argparse doesn't allow optionals within positionals
Glenn Linderman added the comment: So I read over your code again, and even read the documentation this time, and it all looks good, and I know it works good because I've been using the code. I tried to send a notice through Reitveld, and maybe did, but I don't know where it went, so I'll say this much here, too. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14191 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14191] argparse doesn't allow optionals within positionals
Glenn Linderman added the comment: Paul, is this ready to merge, or are you thinking of more refinements? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14191 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14191] argparse doesn't allow optionals within positionals
Glenn Linderman added the comment: These sound like good refinements. You've been thinking. By making the fallback happen externally, it simplifies the implementation of parse_intermixed_args, and forces the application to accept responsibility for calling it with a consistent set of arguments, or calling something else. I like that. I don't really see the fallback as a particularly useful feature, so pushing it outside the stdlib, yet still making it simple to implement for any that do find it to be useful, seems like a good tradeoff. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14191 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14191] argparse doesn't allow optionals within positionals
Glenn Linderman added the comment: OK, I've been running with the new code most the day, and it seems functional in my testing. I only sort of follow your discussion about the custom action class caveat, probably because I haven't used custom action classes... I tried once, but failed to achieve my goal, as it was more ambitious than they presently support. If the [] value is significantly problematical in some manner, could positional nargs be set to a sentinal value that would avoid the assignment of the [] value? I realize that would require code changes in some other function or functions, in addition to the added new functions, so that would make the patch a bit more intrusive. If _fallback helps some folks with understanding errors clearly, I won't object to it. I guess it would only be programmers that would be confused, because they would be the ones interpreting the errors... and with adequate testing, should fix the programming errors before the users get a chance to be confused. So maybe your next .patch will be ready to ship! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14191 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14191] argparse doesn't allow optionals within positionals
Glenn Linderman added the comment: paul j3: Regarding earlier versions of these files - I do not see a way of deleting them. Click on edit, then there is an option to unlink. I don't know if they ever actually get deleted, but it clears out the clutter when looking for the latest version. Will check out the newest code shortly. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14191 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14191] argparse doesn't allow optionals within positionals
Glenn Linderman added the comment: Paul, thanks for your continued work. I had reworked your prior patch into a subclass of Argument Parser, and tweaking the code to get parse_intermixed_args to adjust the behaviors I had reported. Now substituting exactly your more flexible new code into my subclass from your latest test_intermixed.py (you should delete your old patches), I can quickly confirm that it works with my applications that used to use my wrapper class, and expect and use intermixed functionality. I also read through all your code and comments and it looks good to me. Regarding parse_fallback_args, I do not see documentation for it. If that is intentional, you might want to add comments in the code regarding its use for testing only... and might want to rename it to _parse_fallback_args. I personally don't see a lot of value to the function, or the new parameter; tests for parse_intermixed_args and parse_known_intermixed_args should be (and have been, thanks) added to the tests for argparse, and should suffice for testing. In non-test code, I see no benefit: either the user uses features that are incompatible with parse_intermixed_args, and thus uses the other features of argparse, or the user, for compatibility reasons, needs to use parse_intermixed_args, and thus is prevented from successfully using the incompatible features. If I'm missing some benefit of parse_fallback_args, it should be explained in either the documentation or the comments. Regarding the terminology: both intermixed and interspersed would be correct English words to describe the use case. So would intermingled :) Because Stephen blessed intermixed, and because it is used by getopt documentation (getopt has not been deprecated, optparse has), it seems to be the best term to use. Should optparse someday be removed, along with its documentation, the use of the term interspersed would also disappear, leaving more consistency in terminology. Alternative: Because optparse uses interspersed in an API, we cannot fix it to use intermixed. However, we could fix the uses of intermixed to be interspersed prior to or at the time of accepting your patch to argparse... afterwards, it would be too late. Personally, I see no problem with the use of both terms in the documentation, and intermixed is the shortest, so I have a slight preference for that. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14191 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14191] argparse doesn't allow optionals within positionals
Glenn Linderman added the comment: Very nice, Paul. I tested that with some of my applications, and some of my test cases. All of them initially failed, because you have parse_intermixed_args returning parameters like parse_known_args instead of like parse_args. Now I can understand that might be a little confusing in msg166175, but note that the implementation is like a call to parse_known_args followed by a call to parse_args... strongly implying that the return should be like parse_args. After tweaking your implementation in that regard, then I was able to get all the same applications and test cases to pass, although I haven't tried all my applications and all my test cases, as yet. Your techniques for disabling particular parameters are pretty clever. I think the difficult cases should raise an error. Firstly, parse_intermixed_args is intended to be for functional compatibility with optparse functionality, which doesn't support the difficult cases, therefore use of the difficult cases would require additional restrictions on the allowed order of options on the command line, beyond what optparse supports... this would be an application interface change, and as part of that interface change, should such happen, the flexibility of intermixing optionals and positionals can be restricted. Secondly, if an understanding of how to define the use parse_intermixed_args with one or more of the difficult cases is reached, replacing an error case with a functional case is possible, but replacing one silent functionality with a different one is a backwards compatibility problem. Throwing an error avoids limiting a future definition of these cases. The freedom of mixing optionals and positionals that would available in the now deprecated optparse does seem to be restored by this patch. I look forward to seeing a revised patch, this is a very promising solution to this bug. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14191 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14191] argparse doesn't allow optionals within positionals
Glenn Linderman added the comment: Yes, a second function would give more flexibility. Due to the approval in msg166175 to use the name parse_intermixed_args for the functionality described there, it would probably be best to use that name for that functionality. So then we are left naming your current function something else. parse_known_intermixed_args certainly is descriptive, and fits the naming conventions of the other methods in the class. Quite long, unfortunately... but then I doubt it will get used much. I am using parse_intermixed_args regularly (via my wrapper class), and it is quite long enough. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14191 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14191] argparse doesn't allow optionals within positionals
Glenn Linderman added the comment: Paul, your comments are interesting, but your proposed patch doesn't actually solve the problem. So here I am typing away at my command prompt, and I type in a couple optional parameters I know I'll need and start on the sequence of positional ones, and half way through I remember oh, I need another optional paremeter so I type it in next before I forget, and then go on with the positional ones. No prior Unix-style argument parsing mechanism that I have ever seen or heard of would be confused by that, but argparse is. This bug is about providing a facility in argparse that supports intermixing optional parameters into strings of positional parameters, just like all prior Unix-style argument parsing mechanisms, so that an application can be ported to use argparse without breaking command lines that their users have stored in command files. Otherwise argparse is not an upgrade path for an application, yet optparse has been deprecated. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14191 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14191] argparse doesn't allow optionals within positionals
Glenn Linderman added the comment: I should clarify, before someone jumps in: some particular applications do implement restrictions on order of optional and positional arguments; I'm aware of that. getopt easily supported application defined order restrictions, because it processed arguments sequentially, and the processing loop was user code. optparse, as has been pointed out, parses the optionals, and leaves a single list of positionals, combined from between all the optionals, for the user code to process in any manner, but would actually make it harder for user code to implement order restrictions. argparse goes the other way, taking over all the user parsing (which is a good thing), but not providing sufficient features to implement flexible mixing of optional and positional arguments. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14191 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15427] Describe use of args parameter of argparse.ArgumentParser.parse_args
Glenn Linderman added the comment: These docs changes seem reasonable, from a side-by-side view (I didn't attempt to look at the formatted results of applying the patch), to better document the current behavior. -- nosy: +v+python ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15427 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14191] argparse doesn't allow optionals within positionals
Glenn Linderman added the comment: Docs look good as mentioned there, for the current behavior, although it would be good to improve the behavior. Note that I have supplied a wrapper (t18a.py) (if it hasn't bit-rotted for 3.4, I'm still using 3.3) that provides the needed functionality. The problem is, that I have no clue how to modify the internals of argparse to allow it to simply be a method of the current argparse class. One could achieve the goal by renaming the current argparse class to _argparse, and renaming my wrapper class to be the real argparse, and that would work, but would seem to be inefficient. It would be nice if someone could move the needed functionality, a new API called parse_intermixed_args, already approved by msg166175, that does the same thing as my wrapper does, but without the wrapper class. This would be a cure to the problem, and it could be tested against my wrapper class by comparison to ensure the needed functionality is provided. I'd be glad to help with testing and understanding the requirements, but don't have time to figure out the internals of argparse at present. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14191 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17083] can't specify newline string for readline for binary files
Glenn Linderman added the comment: I think Bryant's request is reasonable, for consistency in functionality. If line oriented operations are allowed on binary files, then a binary newline value should be permitted at the time of open. I think, for handling binary files, that it would also be interesting to have a version of readline that takes a binary newline file as a parameter to each readline call, because in binary files, the concept of newline can vary from section to section of the file... here, null-terminated records, there CR LF terminated encoded text records, elsewhere fixed-length records, and another place might have records delimited by some binary token of one or more bytes. Readline with a newline parameter could be useful in three of those cases, read in the fixed-length case. But this paragraph would be a new feature. However, simpler binary files, which may have only one type of terminated records, could effectively use the operations Bryant is suggesting, which seems quite reasonable to me, along with a mix of read calls for non-delimited data, fixed-length data, or data requiring complex logic to decode. -- nosy: +v+python ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17083 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16810] inconsistency in weekday
Glenn Linderman added the comment: Thanks for the response, Serhiy. I misreported, but there is still a bug in this area, it seems. Attached is some code. I was printing out (too) many values from datetime to learn how it worked. I got confused on which ones were printed in which order. The attached code reduces the number of values printed to just those that should be consistent, but according to the docs, aren't. However, now that I figured out which ones were printed by which code, I no longer find a discrepancy between code and documentation, just a confusing interface whereby weekday can be obtained in three different forms. -- Added file: http://bugs.python.org/file28485/t38.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16810 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16810] inconsistency in weekday
Changes by Glenn Linderman v+pyt...@g.nevcal.com: -- resolution: - invalid status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16810 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16810] inconsistency in weekday
New submission from Glenn Linderman: Docs say: date.timetuple() Return a time.struct_time such as returned by time.localtime(). The hours, minutes and seconds are 0, and the DST flag is -1. d.timetuple() is equivalent to time.struct_time((d.year, d.month, d.day, 0, 0, 0, d.weekday(), yday, -1)), where yday = d.toordinal() - date(d.year, 1, 1).toordinal() + 1 is the day number within the current year starting with 1 for January 1st. However, timetuple's 7th element has a range of 0-6 where 0 is Sunday, and d.weekday has a range of 0-6 where 0 is Monday. So the claim of equivalence is false. d.weekday() in the above could be replaced by ( d.weekday() + 1 ) % 7 I guess datetime consistently uses 0==Monday, and weeks starting on Monday, except for the timetuple (which probably has compatibility constraints which force it to return a different value, which I consider to be more correct). -- assignee: docs@python components: Documentation messages: 178477 nosy: docs@python, v+python priority: normal severity: normal status: open title: inconsistency in weekday versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16810 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16612] Integrate Argument Clinic specialized preprocessor into CPython trunk
Changes by Glenn Linderman v+pyt...@g.nevcal.com: -- nosy: +v+python ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16612 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16074] bad error in rename
New submission from Glenn Linderman: I've been using 3.3.0b1 for development, with mostly no problems, but today I was surprised and confused by an error message. It is an attempt to be an improvement over 3.2, giving the filename that os.rename cannot find... but instead, it gives the one it is renaming to. So I quickly upgraded to 3.3.0rc3, and it contains the same error. -- components: Windows files: test93.py messages: 171410 nosy: v+python priority: normal severity: normal status: open title: bad error in rename versions: Python 3.3 Added file: http://bugs.python.org/file27324/test93.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16074 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16074] bad error message in os.rename
Glenn Linderman added the comment: Terry, I thought the test case would demonstrate the error details. As far as Windows, I encountered it there, and it seemed like the sort of error that could be in a Windows-specific module. Serhiy, thanks for confirming, and analyzing. At this point in the release cycle, rolling back the enhanced message is probably better than trying to fix it. The 3.2 message was imprecise, but not confused with the sometimes-wrong file name. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16074 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15629] Run doctests in Doc/*.rst as part of regrtest
Glenn Linderman added the comment: Another idea would be to make a notation that looks exactly* like doctests for documentation purposes, but that doctest would not run. Then, non-runnable doctests could be skipped, and runnable ones could be run. This would help keep the runnable code in the documentation validated, but would be on a test-by-test basis, rather than file by file. -- nosy: +v+python ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15629 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15564] cgi.FieldStorage should not call read_multi on files
Glenn Linderman added the comment: I didn't call the current behaviour of browsers in assigning MIME types automatically based on file extension a bug; I would consider it more of a missing capability, an oversight due to the rareness of attempts to upload MHTML files. This is similar to the situation of email clients automatically choosing the Content-Disposition for attachments (which is just a recommendation) about whether to suggest they be displayed inline, or provided as attachments to be saved. Most automatically select a Content-Disposition based on their own capability to deal with an attachment of a particular MIME type, rather than the (unknown) capability of the email client of the ultimate recipient. I think in both cases, the default behavior works well enough for a large enough subset of cases, that there has been little demand for increased functionality, even though one can contrive reasonable sounding cases for that functionality. As a point of discussion, my perception is that MHTML files have two uses: to email an image of a web page (something typically done implicitly by bundled email/web-browser client software, and not generally explicit in the creation of a standalone MHTML file), and to archive a web page for local reference. Neither of these uses involves upload MHTML files to web sites, although saving a web page, and then attempting to email it to a friend as an attachment via a web mail client might encounter the same difficulty you are having. Another use I have heard discussed (but I've forgotten where, so have no references), is as a source for custom browsers to prepackage responses for particular WEB forms. In that case, I think it would be the custom browser's responsibility to supply the MHTML file content as a response to the form request, rather than to supply it as an uploaded file, expecting the server to dissect it... I think it is obvious that my personal, first reaction is that the parsing problem should be fixed... if the MIME type states it is multipart, it should dissected into its parts... and if that is not the desired behavior, then the MIME type should be different. Email standards, the source of MIME type specifications, certainly use and support nested multipart dissection, although various email software performs it in various manners and to various levels. Naturally, if the content syntax of the multipart file is incorrect, it should produce an exception, the same as if the multipart content a (buggy) browser produced from an HTML form were syntactically incorrect. Given a lack of capability of browser to allow specification of MIME type (this is .mht, but treat it as application/octet-stream rather than multipart/related), it does seem that web server toolkits such as cgi.FieldStorage might want to offer an option or hook to allow an application to disable the otherwise automatic parsing of multipart/* files. This is a rather murky area, indeed. Research into whether and how other web toolkits handle such a situation would be interesting in deciding how to proceed. While there is no need for Python to slavishly follow the lead of any other particular web toolkit, it would be interesting to know if any actually successfully parse such files, and it would be interesting to know if any ignore the MIME type for uploaded files, and it would be interesting to know if any support options for handling uploaded files with multipart/* MIME types. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15564 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15564] cgi.FieldStorage should not call read_multi on files
Glenn Linderman added the comment: I forgot to mention that the file you provided in your test doesn't look like a well-formed MHTML file, and so an exception would be expected in this case. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15564 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15564] cgi.FieldStorage should not call read_multi on files
Changes by Glenn Linderman v+pyt...@g.nevcal.com: -- nosy: +v+python ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15564 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15564] cgi.FieldStorage should not call read_multi on files
Glenn Linderman added the comment: So the issue you perceive is that a correctly MIME-typed .mht file has a MIME type of multipart/related -- but that for the purposes of uploading the file, you don't want to treat it as that MIME type, but rather as an opaque data file. Just give it a different MIME type at the time of upload, like application/octet-stream. That is appropriate, if your application wants to treat the data as an opaque data stream. But, you say, none of the browsers support user-specified or user-selectable MIME types, but rather they infer the MIME type from the file extension. So that sounds like a bug in the browsers... but also gives an out... change the name of the file before uploading it. The only bug I see here is your comment that the parsing fails. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15564 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14565] is_cgi doesn't function as documented for cgi_directories
Glenn Linderman added the comment: Thanks for the patch, Oscar, I've not had more time to follow up on this issue, and haven't yet learned how to generate the patches. While you dropped the return False line, which surprised me, the implicit return None is sufficiently false, that there no real concern with the correctness of the code in the patch. Hopefully, with your contribution, this issue can progress to completion. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14565 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14191] argparse doesn't allow optionals within positionals
Glenn Linderman v+pyt...@g.nevcal.com added the comment: So my t18a.py wraps Argparse, because the externals are documented and I could understand that. Given enough time, I might be able to understand the internals too... it is just Python... Seems like the internals separate positionals and optionals into two subparsers, the logic needed is to save the positionals, temporarily replace them with an empty group, and call parse_known_args, then restore the positionals, and call parse_known_args again. What I haven't figured out, is how that would affect the help message building, and how to make the empty group of positionals without affecting the help message. It's also not clear that it is possible, with current internals, to substitute an empty group... the only features for creating a group seem to always add it to a list of _action_groups. So that muddies the water, just like the help message... everything seems intertwined internally. A little guidance here, would let me code... I could probably whack and slash, and keep extra lists of arguments and sort of make it work like my wrapper does, but I doubt that would be an acceptable patch. So I would be happy, with guidance, to try to create the code, and I can do a diff, but beyond that, I'm sort of at a loss. So I'd be happy to work with someone to create the patch, but I've also never created a patch, nor test cases, for Python (or any other open source project). Theoretically, it is straightforward, and documented; as a practical matter, it isn't likely that I'll find time to figure out all that methodology and actually create a patch, in the near future (although it is on my list of things to learn, in the fullness of time, and after the first one, I'm sure subsequent ones would be easier). Or if someone else wants to code it, I'd be happy to look it over, test it with my environment and applications that I'm currently using with my wrapper. Given this guidance, I've tweaked my wrapper to have parse_intermixed_args rather than changing the behavior of parse_args as I have been, and will tweak the apps correspondingly, so I'll be in a position to test any code created for this issue. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14191 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15258] argparse documentation: Improve optparse section regarding allow_interspersed_args
Glenn Linderman v+pyt...@g.nevcal.com added the comment: See also issue 14191, which describes the problems of trying to make argparse achieve the goal of the default optparse handling of allow_interspersed_args ! The documentation for that branch of the feature is also seriously incomplete, and the workaround is more than a single line. -- nosy: +v+python ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15258 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14191] argparse: nargs='*' doesn't get out-of-order positional parameters
Glenn Linderman v+pyt...@g.nevcal.com added the comment: See also issue 15258 which points out issues with the converse case. Further testing and development also discovered that in certain error cases, the help message produced by t18-equivalent code was incorrect. t18a.py is an update/rewrite (same concepts, though) that produces a correct help message when errors occur. -- Added file: http://bugs.python.org/file26273/t18a.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14191 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1602] windows console doesn't print or input Unicode
Glenn Linderman v+pyt...@g.nevcal.com added the comment: My fix for this errors error, might be similar to what is needed for issue 12967, although I don't know if my fix is really correct... just that it gets past the error, and 'strict' is the default for TextIOWrapper. I'm not at all sure why there is now (since 3.2) an interaction between input on stdin and the particulars of the output class for stdout. But I'm not at all an expert in Python internals or Python IO. I'm not sure whether or not you applied the patch to your b0, if not, that is what I'm running, too... but using the win_console.patch as supporting code. The original test script didn't use the supporting code. If you did patch your b0 bwith unicode3.py, then you shouldn't need to do a chcp to write any Unicode characters; someone reported that doing a chcp caused problems, but I don't know how to apply the patch or build a Python with it, so can't really test all the cases. Victor did add a cp65001 codec using a different issue, not sure how that is relevant here, other than for the tests he wrote. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1602 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1602] windows console doesn't print or input Unicode
Glenn Linderman v+pyt...@g.nevcal.com added the comment: Terry said: Is unicode3.py something to run once or import in each app that wants unicode output? I say: The latter... import it. Terry said: Either way, if it is possible to fix the console, why is it not distribute it with the fix? I say: Not sure what you are asking here. Yes it is possible to fix the console, but this fix depends on the version-specific internals of the Python IO system... so unicode3.py works with Python 3.1, but not Python 3.2 or 3.3. I haven't tested to see if my patched unicode3.py still works on Python 3.1 (I imagine it would, due to the nature of the fix just adding something that Python 3.1 probably would ignore. So my opinion is the fix is better done inside Python than inside the application. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1602 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12967] IDLE RPC Proxy for standard IO streams lacks 'errors' attribute
Glenn Linderman v+pyt...@g.nevcal.com added the comment: So this looks like it might be a simple fix... in issue 1602, there was a patch for Windows console for 3.1... sadly not applied then, or 3.2, or 3.3 (yet). But in 3.2, the fix sprouted a failure just like this one: the console output class would get reported to not have an errors attribute when doing an input. A fix there was to add an attribute errors='strict' to the console output class. Here it seems the same symptom sprouted in the same time frame, for a similar situation where the output class has been replaced by one that doesn't have an errors attribute... so it should grow one... -- nosy: +v+python ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12967 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1602] windows console doesn't print or input Unicode
Glenn Linderman v+pyt...@g.nevcal.com added the comment: For the win_console.patch, it seems like adding the line self.errors='strict' inside UnicodeOutput.__init__ resolves the problem with input causing exceptions. Not sure if the sys_write_stdout.patch has the same sort of problem. Sure home this issue makes it into 3.3. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1602 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15226] max( str ) should be fast with PEP 393
New submission from Glenn Linderman v+pyt...@g.nevcal.com: This is stupid code, but it should be faster with PEP 393 than before, should it not? str = ' ' * 500 + this is really a string examplewow!!!; for ix in range( 9000 ): z = max(str) print(Max character: + max(str)) While the new C API seems to support quickly finding the max character in a string, Python code does not benefit. -- components: Interpreter Core messages: 164351 nosy: v+python priority: normal severity: normal status: open title: max( str ) should be fast with PEP 393 versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15226 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15226] max( str ) should be fast with PEP 393
Glenn Linderman v+pyt...@g.nevcal.com added the comment: Ah, so then it would require a new API to make the Python code as smart as the C code, max is too general. Issue 15016 is an example of Python code that could benefit from knowing in constant time if the string contained only characters 128, or if the string contained only characters 256... a three way decision. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15226 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15226] max( str ) should be fast with PEP 393
Changes by Glenn Linderman v+pyt...@g.nevcal.com: -- type: - enhancement ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15226 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15016] Add special case for latin messages in email.mime.text
Glenn Linderman v+pyt...@g.nevcal.com added the comment: Patch is interesting, using an encoder to detect validity. However, it suffers from some performance problems for long text that has large ASCII prefixes. This seems to be an enhancement sort of request rather than a bug... so I wonder why Python 3.2 is listed? And in Python 3.3 with PEP 393 strings the C API to strings provides a quick way to determine the maximum character in the string... although I see nothing in the PEP about how to access that information from Python. If it is available, it could provide a much quicker precheck rather than multiple attempts to encode strings with large ASCII prefixes only to discover that the next to last character is in (128,255) and the last character is 255 (which would be about the worst case scenario for the algorithm in the patch). -- nosy: +v+python ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15016 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14943] winreg OpenKey doesn't work as documented
New submission from Glenn Linderman v+pyt...@g.nevcal.com: My first time to use winreg and I am sure that some of this report is documentation, but depending on behavior in other versions, maybe it is a regression in code as well, but I doubt it. I'm reading the 3.3 documentation, but using 3.2.3 for testing. The documentation doesn't indicate any change execpt the exception thrown, between 3.2 and 3.3. The documentation for OpenKey indicates it has 4 parameters, calling the 3rd reserverd and the 4th access. These are given default values of 0 and KEY_ALL_ACCESS, respectively, according to the function definition. The text of the documentation does not further explain these parameters, rather it explains res and sam which may appear to correspond... (that is problem #1) Assuming a correspondence, and a name change for those parameters somewhere along the line (perhaps between 3.1 and 3.2 when named parameters became supported, per the doc. note), then sam is defined to have a default value of KEY_READ. That conflicts with the default value shown in the function definition (this is problem #2). The behavior of OpenKey in 3.2.2 seems to be that the access parameter actually defaults to KEY_READ, rather than KEY_ALL_ACCESS. Since the documentation is inconsistent in this area, I'm not sure if there was intended to be a code change, nor what the prior behavior might have been, nor what the future behavior is intended to be. If a change in default was intended, either it was implemented wrong, or documented wrong, and there is no indication in the documentation that a change was made, or should have been made (this is problem #3). I suspect the changes should all be to the documentation, changing the function definition to read KEY_READ instead of KEY_ALL_ACCESS, and changing the parameters in the text to be called reserved and access instead of res and sam, and if so, then problem #3 is fictitious, just a result of the other inconsistencies, and speculation. -- assignee: docs@python components: Documentation messages: 161822 nosy: docs@python, v+python priority: normal severity: normal status: open title: winreg OpenKey doesn't work as documented type: behavior versions: Python 3.2, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14943 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1602] windows console doesn't print or input Unicode
Glenn Linderman v+pyt...@g.nevcal.com added the comment: A little more empirical info: the missing errors attribute doesn't show up except for input. print works fine. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1602 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1602] windows console doesn't print or input Unicode
Glenn Linderman v+pyt...@g.nevcal.com added the comment: I actually had to go back to 3.1.2 to get it to run, I guess I had never run with Unicode output after installing 3.2. So it isn't an incompatibility between 3.2.2 and 3.2.3, but more likely a change between 3.1 and 3.2 that invalidates this patch and workaround. At least it is easier to keep 3.1.x and 3.2.x on the same system! Terry, applications for non-programmers that want to emit Unicode on the console... so the IDLE shell isn't appropriate. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1602 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1602] windows console doesn't print or input Unicode
Glenn Linderman v+pyt...@g.nevcal.com added the comment: Has something incompatible changed between 3.2.2 and 3.2.3 with respect to this bug? I have a program that had an earlier version of the workaround (Michael's original, I think), and it worked fine, then I upgraded from 3.2.2 to 3.2.3 due to testing for issue 14811 and then the old workaround started complaining about no attribute 'errors'. So I grabbed unicode3.py, but it does the same thing: AttributeError: 'UnicodeConsole' object has no attribute 'errors' I have no clue how to fix this, other than going back to Python 3.2.2... -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1602 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1602] windows console doesn't print or input Unicode
Glenn Linderman v+pyt...@g.nevcal.com added the comment: Oh, and is this issues going to be fixed for 3.3, so we don't have to use the workaround in the future? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1602 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14811] compile fails - UTF-8 character decoding
Glenn Linderman v+pyt...@g.nevcal.com added the comment: Forgot to mention that I was running on Windows, 64-bit. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14811 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14811] compile fails - UTF-8 character decoding
Glenn Linderman v+pyt...@g.nevcal.com added the comment: There is no traceback. Here is the text of the Syntax error. d:\my\im\infilesc:\python32\python.exe d:\my\py\t33a.py -h File d:\my\py\t33a.py, line 2 SyntaxError: Non-UTF-8 code starting with '\xc3' in file d:\my\py\t33a.py on line 3, but no encoding declared; see http://python.org/dev/peps/pep-0263/ for details My understanding is Python 3 uses utf-8 as the default encoding for source files -- unless there is an encoding line; and I've set my emacs to save all .py files as utf-8-unix (meaning with no CR, if you aren't an emacs user). I verified with a hex dump that the encoding in the file is UTF-8, but you are welcome to also, that is the file I uploaded. So your testing would seem to indicate it is a platform specific bug. Try running it on Windows, then. Further, if it were the platform default encoding, adding a space wouldn't cure it... the encoding of the file would still be UTF-8, and the platform default encoding would still be the same whatever you think it might be (but I think it is UTF-8 for source text), so adding a space would not effect an encoding mismatch. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14811 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14811] Syntax error on long UTF-8 lines
Glenn Linderman v+pyt...@g.nevcal.com added the comment: Thanks, David, for the clarification. I had been mentally separating syntax errors from other errors. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14811 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
