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/issue11
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
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/cg
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
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
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
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 &quo
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"
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
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 &quo
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
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
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
Glenn Linderman added the comment:
for more helpful => far more helpful
--
___
Python tracker
<https://bugs.python.org/issue42973>
___
___
Python-bugs-lis
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.
I
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
Change by Glenn Linderman :
--
nosy: +v+python
___
Python tracker
<https://bugs.python.org/issue42973>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
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
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/issue28
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
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:
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
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
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
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
Change by Glenn Linderman :
--
nosy: +v+python
___
Python tracker
<https://bugs.python.org/issue36863>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
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
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
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
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
e
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 m
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 pre
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 whil
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/
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://
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 s
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 <
Glenn Linderman added the comment:
"veery" should be "veering" in above comment, sorry.
--
___
Python tracker <rep...@bugs.python.org>
<http
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 a
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
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
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
Changes by Glenn Linderman <v+pyt...@g.nevcal.com>:
--
nosy: +v+python
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29654>
___
_
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
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
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
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
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
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
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
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
Changes by Glenn Linderman v+pyt...@g.nevcal.com:
--
type: - enhancement
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21666
___
___
Python-bugs
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Changes by Glenn Linderman v+pyt...@g.nevcal.com:
--
type: - enhancement
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15226
___
___
Python-bugs
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
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
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
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
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
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
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
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
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
1 - 100 of 248 matches
Mail list logo
