Greg Werbin added the comment:
> Users certainly don't need an API change to prevent that, should they wish
> to. The following simple call will suffice (using 'gnupg' just as an example):
>
> logging.getLogger('gnupg').setLevel(logging.CRITICAL + 1)
This selectively _disabl
Greg Werbin added the comment:
Hi, thanks for the comment.
> First of all, library developers should not be configuring loggers at all,
> other than adding a NullHandler to their top-level logger.
This is true, and I agree. I am not expecting people to start using
basicConfig()
Greg Kuhn added the comment:
I see, thank you all for the detailed investigation and explanation!!
Agreed Terry, anyone who reads the error should be able to parse it themselves
and see what the errors is. Pointing the user to the error site is the most
important piece
Greg Kuhn added the comment:
But doesn't the square bracket have no relevance here?
It's not within a curly bracketed string so shouldn't be treated specially.
I would have expected the error to be: SyntaxError: f-string: unmatched '}'.
Unless I need to go back and reread pep498
New submission from Greg Kuhn :
Hi All,
Is the below a bug? Shouldn't the interpreter be complaining about a curly
brace?
$ python
Python 3.8.5 (tags/v3.8.5:580fbb0, Jul 20 2020, 15:43:08) [MSC v.1926 32 bit
(Intel)] on win32
Type "help", "copyright", "credi
Change by Greg Werbin :
--
keywords: +patch
pull_requests: +26452
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/28010
___
Python tracker
<https://bugs.python.org/issu
New submission from Greg Werbin :
Hello all!
I am proposing to add a "logger=" kwarg to logging.basicConfig(), which would
cause the configuration to be applied to the specified logger. The value of
this parameter could be a string or a logging.Logger object. Omitting logger=
Greg Neagle added the comment:
While checking this issue hoping there might be updates, I realized that I
didn't share a link to the script I use to convert python.org's Python
framework into one that can be relocated.
It's here: https://github.com/gregneagle/relocatable-python
Change by Greg Stein :
--
nosy: +gstein
nosy_count: 3.0 -> 4.0
pull_requests: +24667
pull_request: https://github.com/python/cpython/pull/26015
___
Python tracker
<https://bugs.python.org/issu
Change by Greg Darke :
--
resolution: -> fixed
___
Python tracker
<https://bugs.python.org/issue43497>
___
___
Python-bugs-list mailing list
Unsubscrib
Greg Darke added the comment:
I would argue that there is none (especially if it is tuple/something that is
always true) -- thus why I would assume that Python would provide a warning.
This bug comes from a discussion I was having with someone earlier today where
they mentioned
Change by Greg Darke :
--
keywords: +patch
pull_requests: +23629
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/24867
___
Python tracker
<https://bugs.python.org/issu
New submission from Greg Darke :
The following block of code does not produce a SyntaxWarning in python 3.7 and
above (it does produce a warning in python 3.6 and below):
```
assert(False, 'msg')
```
If the tuple is not a constant (for example `(x, 'msg')`), then a warning is
still produced
Greg added the comment:
I tested out tk_scroll.py (and tk_scroll2.py, for kicks) and I couldn't get
that to scroll either. I tried both with and without the ttk line commented.
To my shame, it looks like that means you're spot on, and that it's an issue
between my machine and tcl/tk
Greg added the comment:
That wasn't the case with https://bugs.python.org/issue34047
Was it not clear that I'm having this issue in (and only in) IDLE? Given that
it's the interpreter bundled with python, it seems like it has *something* to
do
New submission from Greg :
Up/down scrolling is not possible with a two-finger swipe on a trackpad. I'm
using Lenovo's notably bad UltraNav drivers on Windows 7. Horizontal scrolling
works just fine. PgUp and PgDn both behave as normal, as does ctrl + arrow keys.
I'm having this issue
Greg Neagle added the comment:
A Python.app you could drop somewhere convenient would by definition need a
relocatable Python.framework within. :-)
--
___
Python tracker
<https://bugs.python.org/issue42
New submission from Greg Neagle :
The current Python.framework installed by the macOS packages is hard-coded to
/Library/Frameworks/Python.framework and breaks if renamed or moved.
A relocatable framework would allow users/admins/developers to install a
specific framework to an alternate
Greg Lindahl added the comment:
I just tripped on the bug that the maxrss field is kilobytes on Linux and bytes
on Darwin.
I don't think referring to the C manpages is sufficient to prevent confusion. I
don't actually use my package on a Mac, I just use Travis-CI to test
Greg Price added the comment:
For the record because this issue is mentioned in a comment in
logging/handlers.py and people are sometimes confused by it today:
> This happens because in that particular locale,
> "INFO".lower() != "info"
Since Python 3, this no
Change by Greg Lindahl :
--
nosy: +wumpus
___
Python tracker
<https://bugs.python.org/issue38227>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Greg Whiteley :
Issue:
Running ModuleFinder.run_script() on numpy versions 1.16.1 to 1.18.3 (maybe
more) fails with backtrace. See steps to reproduce below.
I do not see this problem on earlier versions of python than 3.8 (tested 3.4,
3.5, 3.6 on ubuntu LTSs
Greg added the comment:
while waiting for a fix, would it be possible to document in the argparse
documentation that the 'dest' parameter is required (at least temporarily) for
add_subparsers()? (somewhere near
file:///usr/share/doc/python/html/library/argparse.html#sub-commands
Greg Price added the comment:
> labeling long-stable code as "evil".
Let me apologize about this bit -- I was thinking of the term in quotes
(referring to the earlier comment), but I didn't write it clearly that way. I
don't think any of this code is evil, past or present,
Greg Price added the comment:
I've gone and implemented a version of this that's integrated into
Tools/unicode/makeunicodedata.py , and into the unicodedata module. Patch
attached. Demo:
>>> import unicodedata, pprint
>>> pprint.pprint(unicodedata.property_value_aliase
Greg Price added the comment:
I hesitate to come back to this thread, because as Raymond says it's consumed a
lot of time already. But I think this point is of broader interest than the
specific few lines we've been discussing:
> When small integer are disabled at compilation t
Greg Price added the comment:
Thanks Benjamin for reviewing and merging this series!
--
___
Python tracker
<https://bugs.python.org/issue37760>
___
___
Pytho
Change by Greg Price :
--
keywords: +patch
pull_requests: +15849
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/16254
___
Python tracker
<https://bugs.python.org/issu
Greg Price added the comment:
> We're wasted a lot of dev time on something that never promised much value in
> the first place. So, I'll revert and close this tracker issue
OK, so be it. I'll certainly agree that this series of threads consumed a lot
more time than I anticipated or
Greg Price added the comment:
See followup at https://bugs.python.org/issue38205 and
https://bugs.python.org/issue37812#msg352670 .
The patch in GH-15710 had a side effect of introducing a call to
`Py_UNREACHABLE` inside a comma-expression. A subsequent commit 3ab61473b
changed
Greg Price added the comment:
> if using a static inline function is causing issues
Separately from whether there was or wasn't such an issue here, I think it's
interesting to note that the build failure bpo-38205 is an example of exactly
the opposite! It was caused by a combinat
Greg Price added the comment:
Thanks Victor for linking that issue back here.
> A first change converted a macro to a static inline function. The second
> change converted the static inline fnuction to a macro
Not quite. The first change converted a macro `CHECK_SMALL_INT` to an
equi
Change by Greg Lindahl :
--
nosy: +wumpus
___
Python tracker
<https://bugs.python.org/issue27970>
___
___
Python-bugs-list mailing list
Unsubscribe:
Greg Price added the comment:
Thanks @zach.ware for the review and merge of GH-15451!
That was the "minimal" fix, fixing rules that apply to files we have in the
repo now. So `rg` will no longer ignore `PC/pyconfig.h`. :-)
I've just sent GH-15823 with the "more thoro
Change by Greg Price :
--
pull_requests: +15472
pull_request: https://github.com/python/cpython/pull/15823
___
Python tracker
<https://bugs.python.org/issue37
Greg Price added the comment:
(The tracker just linked GH-14838 to this issue because I mentioned it in a
comment there, but it's not for this issue -- it's that recent fix for an
11-year-old bug in a callsite's overflow check.)
--
___
Python
New submission from Greg Price :
Currently `_PyObject_VAR_SIZE` effectively has a precondition that it must not
be passed arguments which would overflow in its arithmetic. If that's violated,
it overflows... which is undefined behavior already, and in fact the likely
next thing that happens
Greg Price added the comment:
(Just to help keep discussions together: some earlier discussion was on
GH-15216 .)
Because is_small_int / IS_SMALL_INT is so small, there's not much cost in the
source code to making it a macro (as GH-15710 did).
But I think it'd be a mistake to go a lot
Change by Greg Price :
--
pull_requests: +15368
pull_request: https://github.com/python/cpython/pull/15558
___
Python tracker
<https://bugs.python.org/issue38
Change by Greg Price :
--
pull_requests: +15367
pull_request: https://github.com/python/cpython/pull/15712
___
Python tracker
<https://bugs.python.org/issue38
Change by Greg Price :
--
keywords: +patch
pull_requests: +15366
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/15711
___
Python tracker
<https://bugs.python.org/issu
New submission from Greg Price :
Benjamin noticed in reviewing GH-15558 (for #37966) several points where the
existing code around Unicode normalization can be improved:
* on the `QuickcheckResult` enum:
> Maybe `makeunicodedata.py` should output this enum (with better name
namespac
Greg Price added the comment:
Ah OK, that makes sense of it then :)
> But the most important thing is that using PyLong_FromUnsignedLong() instead
> of _PyLong_FromUnsignedChar() on top of GH-15192 is producing the same
> results: striter_next() uses small_ints[] directly. Howev
Change by Greg Price :
--
nosy: +Greg Price
___
Python tracker
<https://bugs.python.org/issue6331>
___
___
Python-bugs-list mailing list
Unsubscribe:
Greg Price added the comment:
Fix posted, as GH-15558.
Adding cc's for the folks in the thread on #32285, where this function was
originally added.
--
components: +Unicode
nosy: +Maxime Belanger, benjamin.peterson, ezio.melotti, steven.daprano,
vstinner
title: is_normalized is much
Change by Greg Price :
--
keywords: +patch
pull_requests: +15231
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/15558
___
Python tracker
<https://bugs.python.org/issu
New submission from Greg Price :
In 3.8 we add a new function `unicodedata.is_normalized`. The result is
equivalent to `str == unicodedata.normalize(form, str)`, but the implementation
uses a version of the "quick check" algorithm from UAX #15 as an optimization
to try to av
Greg Price added the comment:
> I have a minimal fix which takes care of all the files above. I'll post that
> shortly, and I may also write up a more thorough fix that tries to make it
> easy not to fall into the same Git pitfall again.
Both now done.
* GH-15451 is that minimal fi
Change by Greg Price :
--
pull_requests: +15219
pull_request: https://github.com/python/cpython/pull/15542
___
Python tracker
<https://bugs.python.org/issue37
Greg Price added the comment:
Very interesting, thanks!
It looks like with LTO enabled, this optimization has no effect at all.
This change adds significant complexity, and it seems like the hoped-for payoff
is entirely in terms of performance on rather narrowly-focused microbenchmarks
Greg Price added the comment:
> I've gone and made a patch for this change
Update:
* The preparatory changes in #37760 are now almost all merged; GH-15265 is the
one piece remaining, and I'd be grateful for a review.
It's a generally straightforward and boring change that converts the m
Greg Price added the comment:
> Is there a particular reason to specifically call PyLong_FromSize_t? Seems
> like PyLong_FromLong is the natural default (and what we default to in the
> rest of the code), and it's what this ends up calling anyway.
Ah I see, the patch is meant to
Greg Price added the comment:
Oh also:
* What compiler, and what compilation flags, are you using in your
benchmarking? That seems relevant :)
--
___
Python tracker
<https://bugs.python.org/issue37
Greg Price added the comment:
Hmm, I'm a bit confused because:
* Your patch at GH-15251 replaces a number of calls to PyLong_FromLong with
calls to the new _PyLong_FromUnsignedChar.
* That function, in turn, just calls PyLong_FromSize_t.
* And that function begins:
PyObject
Greg Price added the comment:
> May I suggest directing your efforts towards fixing known bugs or
> implementing requested features.
Well, I would certainly be grateful for a review on my fix to #18236. ;-)
There's also a small docs bug at GH-15301.
I do think there's significant
Change by Greg Price :
--
keywords: +patch
pull_requests: +15143
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/15451
___
Python tracker
<https://bugs.python.org/issu
New submission from Greg Price :
There are a number of files that we track in the repo, but are nevertheless
covered by `.gitignore`.
This *mostly* doesn't change anything, because Git itself only cares what
`.gitignore` has to say about files that aren't already tracked. But:
* It affects
Greg Price added the comment:
Thanks, Raymond, for the review on GH-15216!
Shortly after posting this issue, I noticed a very similar story in
CHECK_BINOP. I've just posted GH-15448 to similarly make returns explicit
there. It basically consists of a number of repetitions
Change by Greg Price :
--
pull_requests: +15140
pull_request: https://github.com/python/cpython/pull/15448
___
Python tracker
<https://bugs.python.org/issue37
Change by Greg Price :
--
nosy: +Greg Price
___
Python tracker
<https://bugs.python.org/issue36375>
___
___
Python-bugs-list mailing list
Unsubscribe:
Greg Price added the comment:
(A bit easy to miss in the way this thread gets displayed, so to highlight in a
comment: GH-15265 is up, following the 5 other patches which have now all been
merged. That's the one that replaces the length-18 tuples with a dataclass
Greg Price added the comment:
I ran across this test when looking at especially slow files in the test suite:
it turns out that not only is this service currently down, but the
snakebite.net domain still exists, and as a result the test can end up waiting
20-30s before learning
Change by Greg Price :
--
keywords: +patch
pull_requests: +15063
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/15349
___
Python tracker
<https://bugs.python.org/issu
Greg Price added the comment:
Thanks Victor for the reviews and merges!
(Unmarking 2.7, because https://docs.python.org/2/library/stdtypes.html seems
to not have this issue.)
--
versions: -Python 2.7
___
Python tracker
<https://bugs.python.
Change by Greg Price :
--
components: +Interpreter Core
___
Python tracker
<https://bugs.python.org/issue37872>
___
___
Python-bugs-list mailing list
Unsub
Change by Greg Price :
--
title: Move statics in Python/import.c to top of the file -> Move
_Py_IDENTIFIER statics in Python/import.c to top of the file
___
Python tracker
<https://bugs.python.org/issu
Change by Greg Price :
--
nosy: +Greg Price
___
Python tracker
<https://bugs.python.org/issue37872>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Greg Price :
--
pull_requests: +15027
pull_request: https://github.com/python/cpython/pull/15302
___
Python tracker
<https://bugs.python.org/issue37
Change by Greg Price :
--
pull_requests: +15026
pull_request: https://github.com/python/cpython/pull/15301
___
Python tracker
<https://bugs.python.org/issue36
Change by Greg Price :
--
keywords: +patch
pull_requests: +15025
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/15300
___
Python tracker
<https://bugs.python.org/issu
New submission from Greg Price :
While working on #36502 and then #18236 about the definition and docs of
str.isspace(), I looked closely also at its neighbor str.isprintable().
It turned out that we have the definition of what makes a character "printable"
documented in three plac
Change by Greg Price :
--
nosy: +vstinner
___
Python tracker
<https://bugs.python.org/issue37758>
___
___
Python-bugs-list mailing list
Unsubscribe:
Greg Price added the comment:
> About the RSS memory, I'm not sure how Linux accounts the Unicode databases
> before they are accessed. Is it like read-only memory loaded on demand when
> accessed?
It stands for "resident set size", as in "resident in memory&quo
Change by Greg Price :
--
pull_requests: +15019
pull_request: https://github.com/python/cpython/pull/15296
___
Python tracker
<https://bugs.python.org/issue36
Greg Price added the comment:
(I should add that it was only after doing the reading that produced the OP
that I had a clear idea what I thought the priority of the issue was -- before
doing that work I didn't have a clear sense of the scope of what it affects.
Based
Greg Price added the comment:
> Maintaining Python is already expensive [...] There are already enough bugs
> waiting for you to be fixed ;-)
BTW I basically agree with this. I think this is not a high-priority issue, and
I have my eye on some of those bugs. :-)
I think the fact tha
Greg Price added the comment:
> I believe that all locale specific things should be in the locale module, not
> in the str class.
The locale module is all about doing things with the current process-global
Unix locale. I don't think that'd be an appropriate interface for this -- if
Greg Price added the comment:
OK, I forked off the discussion of case-mapping as #37848. I think it's
probably good to first sort out what we want, before returning to how to
implement it (if it's agreed that changes are desired.)
Are there other areas of functionality that would be good
Greg Price added the comment:
Another previous discussion is #4610.
--
___
Python tracker
<https://bugs.python.org/issue37848>
___
___
Python-bugs-list mailin
New submission from Greg Price :
Splitting this out from #32771 for more specific discussion. Benjamin writes
there that it would be good to:
> implement the locale-specific case mappings of
> https://www.unicode.org/Public/UCD/latest/ucd/SpecialCasing.txt and ยง3.13 of
> the U
Change by Greg Price :
--
pull_requests: +14985
pull_request: https://github.com/python/cpython/pull/15265
___
Python tracker
<https://bugs.python.org/issue37
Greg Price added the comment:
> From my perspective, the main problem with using type annotations is that
> there's nothing checking them in CI.
Yeah, fair concern. In fact I think I'm on video (from PyCon 2018) warning
everyone not to do that in their codebases, because what you
Greg Price added the comment:
Speaking of improving functionality:
> Having unicodedata readily accessible to the str type would also permit
> higher a fidelity unicode implementation. For example, implementing
> language-tailored str.lower() requires having canonical combin
Greg Price added the comment:
> Loading it dynamically reduces the memory footprint.
Ah, this is a good question to ask!
First, FWIW on my Debian buster desktop I get a smaller figure for `import
unicodedata`: only 64 kiB.
$ python
Python 3.7.3 (default, Apr 3 2019, 05:39:12)
[GCC 8.
Greg Price added the comment:
> This is good. But the title mentioned dataclasses, and they are 3.7+.
Ahh, sorry, I think now I understand you. :-)
Indeed, when I switch to the branch with that change
(https://github.com/gnprice/cpython/commit/2b4aec4dd -- it comes after the
patch tha
Greg Price added the comment:
> What is the minimal Python version for developing CPython? The system Python
> 3 on current Ubuntu LTS (18.04) is 3.6, so I think it should not be larger.
Ah, I think my previous message had an ambiguous parse: the earliest that
*uses* of the typing
Greg Price added the comment:
> BTW: Since when do we use type annotations in Python's stdlib ?
Hmm, interesting question!
At a quick grep, it's in a handful of places in the stdlib: asyncio, functools,
importlib. The earliest it appeared was in 3.7.0a4.
It's in more places in the t
Greg Price added the comment:
> I like to run pyflakes time to time on the Python code base. Please avoid
> "import *" since it prevents pyflakes (and other code analyzers) to find bugs.
Ah fair enough, thanks!
Pushed that change to the next/curr
Change by Greg Price :
--
nosy: +Greg Price
___
Python tracker
<https://bugs.python.org/issue32771>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Greg Price :
--
pull_requests: +14969
pull_request: https://github.com/python/cpython/pull/15248
___
Python tracker
<https://bugs.python.org/issue37
Greg Price added the comment:
> On the other hand, if it is tricky and requires something more than minor
> surgery, that would be a hint that it isn't worth it. There is some value in
> code that is stable and known to be working just fine.
Definitely true!
I think this change t
Change by Greg Price :
--
pull_requests: +14944
pull_request: https://github.com/python/cpython/pull/15216
___
Python tracker
<https://bugs.python.org/issue37
Greg Price added the comment:
> Sometimes for testing we turn it off in order to identify identity test
bugs.
Interesting! Well, if the option is useful for testing, that's certainly a
good reason to keep it.
> Also, eveonline was controlling this to save memory.
Also interesting.
Change by Greg Price :
--
nosy: +Greg Price
___
Python tracker
<https://bugs.python.org/issue37802>
___
___
Python-bugs-list mailing list
Unsubscribe:
Greg Price added the comment:
I've just sent GH-15203 which is the first of two patches for this. It's quite
small.
The second patch, which completes the change, is also small:
https://github.com/gnprice/cpython/commit/c6b905104
It depends on the first one, so I think the easiest is for me
Change by Greg Price :
--
keywords: +patch
pull_requests: +14932
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/15203
___
Python tracker
<https://bugs.python.org/issu
New submission from Greg Price :
In longobject.c we have the following usage a few times:
PyObject *
PyLong_FromLong(long ival)
{
PyLongObject *v;
// ... more locals ...
CHECK_SMALL_INT(ival);
if (ival < 0) {
/* negate: can't write this as abs_ival = -ival si
Greg Price added the comment:
Good question! With the patch:
>>> import re
>>> re.match(r'\s', '\x1e')
>>>
In other words, the definition of the regexp r'\s' follows along. Good to know.
--
___
Python tracke
Change by Greg Price :
--
pull_requests: +14903
pull_request: https://github.com/python/cpython/pull/15171
___
Python tracker
<https://bugs.python.org/issue37
Greg Price added the comment:
I've gone and made a patch for this change:
https://github.com/gnprice/cpython/commit/7dab9d879
Most of the work happens in the script Tools/unicode/makeunicode.py , and along
the way I made several changes there that I found made it somewhat nicer to
work
1 - 100 of 335 matches
Mail list logo
