Change by paul j3 :
--
nosy: +paul.j3
___
Python tracker
<https://bugs.python.org/issue39076>
___
___
Python-bugs-list mailing list
Unsubscribe:
paul j3 added the comment:
This patch changes the super class, _AttributeHolder. ArgumentParser and
Actions also inherit from this, though they have their own _get_kwargs methods,
and so aren't affected by the sort and its removal.
I just had occasion on stackoverflow to discuss the
Paul Ganssle added the comment:
This is a duplicate of issue 13305.
Right now we have some shims around `strftime` to improve consistency in some
situations and for other reasons, but mostly we just call the libc version.
There is an open issue from 2008 (#3173) to ship our own
Change by Paul Ganssle :
--
versions: +Python 3.7, Python 3.8, Python 3.9 -Python 3.6
___
Python tracker
<https://bugs.python.org/issue13305>
___
___
Python-bug
Change by Paul Sokolovsky :
--
nosy: +pfalcon
title: LOAD_NAME and LOAD_GLOBAL handle dict subclasses for globals()
differently -> LOAD_NAME and LOAD_GLOBAL, STORE_GLOBAL handle dict subclasses
for globals() differently
___
Python tracker
<
Paul Sokolovsky added the comment:
> I wanted to write a sandbox for Python.
Sandbox indeed, it is.
class NS(dict):
def __setitem__(self, k, v):
if not isinstance(v, type(lambda: 0)):
raise RuntimeError("Global variables considered harmful")
globals
paul j3 added the comment:
Despite the name, the 'type' parameter specifies a function, not a Python
class.
The only string that produces False is the empty one: bool(''). So 'type=bool'
is valid Python, even if it isn't useful.
With `nargs='+
paul j3 added the comment:
The rejected boolean type proposal:
https://bugs.python.org/issue37564
--
___
Python tracker
<https://bugs.python.org/issue39
Paul Sokolovsky added the comment:
Some smart maintainer closed https://bugs.python.org/issue36220 as a duplicate
of this one. That ticket might have more details of the underlying issues.
--
nosy: +pfalcon
___
Python tracker
<ht
Paul Sokolovsky added the comment:
> The doc for exec says globals "must be a dictionary (and not a subclass of
> dictionary)"
Docs are full of mistakes and outdated information.
Fixing STORE_GLOBAL case from https://bugs.python.org/issue36220#msg359046
would be triv
Paul Sokolovsky added the comment:
> I agree with Terry, the moment you pass a dict subclass to exec you are out
> of contract. If any, we may need to sanitize the input to exec, although I
> don't think is worth paying the performance price for that.
exec() params are already
Paul Ganssle added the comment:
> Oh, also, if y'all are fine with binding to Rust (through a C ABI) I'd love
> to help y'all use unicode-segmentation, which is much less work that pulling
> in ICU. Otherwise if y'all have implementation questions I can answe
Paul Moore added the comment:
Agreed it's not a bug, but I will say it took me a while to work out *why* it's
not a bug (namely, that even though the OP is using shared memory values, the
code relies on fork semantics to share the two Value objects that *reference*
the shared me
Paul Moore added the comment:
For me, I headed straight for "Sharing state between processes" and the "Shared
memory" object. That's probably because I was reviewing someone else's code,
rather than writing my own, but nevertheless when coding I do tend to dive
Paul Ganssle added the comment:
I don't love the inconsistency, but can you elaborate on the actual *danger*
posed by this? What security vulnerabilities involve parsing a datetime using a
non-ascii digit?
The reason that `fromisoformat` doesn't accept non-ASCII digits is actuall
Paul Ganssle added the comment:
> Yes, but not within the same format. If someone were to choose the format
> '2014-04-10T24:00:00', they would have a reasonable expectation that there is
> only one unique string that corresponds with that datetime
That's a particula
Paul Ollis added the comment:
I think it is worth pointing out that the semantics of
f = ``open(fd, closefd=True)``
are broken (IMHO) because an exception can result in an unreferenced file
object that has taken over reponsibility for closing the fd, but it can
also fail without
Paul Ollis added the comment:
> I thought that if this raises a (normal) exception, it always means that it
> did not have overtaken the `fd`, i.e. never results in an unreferenced file
> object which has taken ownership of `fd`.
The current CPython implementation does not guard aga
Paul Sokolovsky added the comment:
> Later, I closed my pysandbox beause it was "broken by design":
https://lwn.net/Articles/574215/
Thanks for the link, insightful. Still unclear, by design of what it's broken
;-).
> Paul Sokolovsky wrote in bpo-36220 than his idea i
Paul Sokolovsky added the comment:
s/only our own usecase/only your own usecase/ (missing "y" typo)
--
___
Python tracker
<https://bugs.python.o
Change by Paul Sokolovsky :
--
pull_requests: +17429
pull_request: https://github.com/python/cpython/pull/18033
___
Python tracker
<https://bugs.python.org/issue36
Paul Sokolovsky added the comment:
Ok, so the patch for my usecase (STORE_GLOBAL) is vividly trivial, so to go
thru the full circle, I posted it: https://github.com/python/cpython/pull/18033
.
--
___
Python tracker
<https://bugs.python.
Paul Sokolovsky added the comment:
> you ask to modify Python so you can pass dict subclasses as namespaces and
> expect CPython to respect the mapping protocol
But no, per your own account, you made noticeable, though not complete, code
changes in that direction. The only thing I
Paul Sokolovsky added the comment:
> Paul: you're are in front of 3 core developers who are rejecting your feature
> request.
But no, it's not my feature request. There were 2 tickets by at least 2 people.
I just saw my case to be similar to cases of those people, so inst
Paul Sokolovsky added the comment:
> Namespace performances are really critical for overall Python performances.
Yeah, that's why I'd like for myself and other people to make it easy to
explore the behavior of namespace lookups, to see how to optimize them.
> You're fr
Paul Sokolovsky added the comment:
> exec() function is currently quite clear
A recent case: https://bugs.python.org/issue38316, co_stacksize was quite clear
what it is. Turned out, a bug in the documentation (likely, just someone forgot
to update it to the actual code). That's
Paul Sokolovsky added the comment:
Absolutely should be able to optimize namespace access. The fact that namespace
is a dict is an implementation detail, it's still inefficient even with all
those version counters and inline caches. Ironically, to let people prototype
better, more effi
Paul Sokolovsky added the comment:
> We may be possible to replace bytecode from `STORE_GLOBAL _cnt; LOAD_GLOBAL
> _cnt` into `DUP_TOP; STORE_GLOBAL _cnt`.
Sounds good, and that's why I personally care about the "STORE" case, and the
patch I submit touches only it, wh
paul j3 added the comment:
This is a complicated issue that needs a lot of thought and testing before we
make any changes.
While all Actions have the 'required' attribute, the programmer can only set it
for optionals. _get_positional_kwargs() will raise an error if the programmer
paul j3 added the comment:
The issue of testing a script that uses argparse has come up on StackOverFlow a
number of times.
As noted the unittesting framework(s) often use their own parsers (not
necessarily argparse). That means they are looking at the sys.argv
commandline. It is
paul j3 added the comment:
A mutually_exclusive_group is not an argument_group. It affects parsing and
the usage, but does nothing in the help lines.
A mutually_exclusive_group may be nested in an argument_group if you want
another group title.
g1 = parser.add_argument_group(
paul j3 added the comment:
I don't think the SO question is relevant. It's about changing the order of
Actions in the Help and/or usage.
Here it's a question of whether to sort the `argparse.Namespace` display. I
think it's been adequately discussed in the recen
paul j3 added the comment:
https://bugs.python.org/issue9694
is the original issue about the titles of the base argument groups.
--
resolution: -> duplicate
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bug
Paul Ganssle added the comment:
Per my reasoning in the discourse thread, I disagree with this move. I think
that this should be handled in setuptools, which is where we tend to handle
breaking changes or even enhancements to distutils.
If we do this in setuptools, we'll get a backpo
Paul Ganssle added the comment:
Serhiy: I think at least a test for this particular corner case should be
added, so that no implementations of `isinstance` that use the CPython test
suite hit an infinite recursion in that event, I guess?
Though I think it's maybe an open question as to
Paul Moore added the comment:
> In short -- I understand that this is a complex issue, but making an absolute
> path is a pretty common use case, and we've had os.path.abspath() for
> decades, so there should be one obvious way to do it, and it should be easily
> discover
New submission from Paul Ganssle :
The entire public interface documented for the datetime C API is various C
macros (see: https://docs.python.org/3/c-api/datetime.html) which are wrappers
around function calls to the PyDateTimeAPI / PyDatetime_CAPI struct, but the
struct itself is
Paul Ganssle added the comment:
So this bug is asking for two things:
1. An official accessor for the `tzinfo` component of an existing datetime,
which I think is very reasonable in light of the fact that there are official
accessors for all the other components of a datetime.
2. An
Paul Moore added the comment:
You've provided links to your branches, but not to the specific text you're
proposing to add. Can you link to a diff or something that shows what you've
added more precisely?
--
___
Python
New submission from Paul Marquess :
Consider this code (based on code from an issue on StackOverflow)
import zipfile
import os
allFilesToZip = ["/tmp/tom"]
with zipfile.ZipFile(allZipPath, 'w') as allZip:
for f in allFilesToZip:
allZip.write(f, compress_type=
New submission from Paul Ganssle :
>From a report on the dateutil tracker today, I found that `time.timezone` and
>`time.altzone` are not accurate in Ireland (at least on Linux, not tested on
>other platforms): https://github.com/dateutil/dateutil/issues/1009
Europe/Dublin in the m
Change by Paul Ganssle :
--
nosy: -p-ganssle
___
Python tracker
<https://bugs.python.org/issue39763>
___
___
Python-bugs-list mailing list
Unsubscribe:
paul j3 added the comment:
https://bugs.python.org/issue13041
is (I think) the latest issue/patch to deal with the help width.
I don't like the idea of adding more parameters to the `ArgumentParser` class.
It's too complicated already.
There are a couple of ways that a user c
Paul Ganssle added the comment:
I don't think adding a default_year parameter is the right solution here.
The actual problem is that `time.strptime`, and by extension
`datetime.strptime` has a strange and confusing interface. What should happen
is either that `year` is set to None or
paul j3 added the comment:
But you can replace the simple 'lambda' with a function that takes the max with
'columns'. In other words, include:
width = _shutil.get_terminal_size().columns
width -= 2
width = min(max_text_width, wi
paul j3 added the comment:
Could you show the sys.argv (for both the linux and windows cases)?
print(args) (without your correction) might also help, just to see the 'raw'
Namespace.
(I'd have to restart my computer to explore the Windows
paul j3 added the comment:
Then this isn't an argparse issue. Probably not even a Python one. The
windows shell (which one? cmd.exe? power? some batch) is making the
substitution.
I see lots of discussion about Windows use of backslash, both as directory
separator and escape.
Change by paul j3 :
--
nosy: +paul.j3
___
Python tracker
<https://bugs.python.org/issue39955>
___
___
Python-bugs-list mailing list
Unsubscribe:
Paul Ganssle added the comment:
This is the intended behavior of these functions, and there is actually now a
warning on both the utcnow and utcfromtimestamp functionsto reflect this:
https://docs.python.org/3/library/datetime.html#datetime.datetime.utcnow
I would say that the correct
Paul Ganssle added the comment:
@Yi Luan
I think you may misunderstand what the `.timestamp()` function does - it
returns an epoch time, which is the amount of time (in seconds) elapsed since
the Unix epoch: https://en.wikipedia.org/wiki/Unix_time
The number is not different depending on
paul j3 added the comment:
You are right, this part of the same issue.
_get_value() tests '==SUPPRESS==' both for type and choices.
--
___
Python tracker
<https://bugs.python.o
paul j3 added the comment:
I think it can be closed.
--
___
Python tracker
<https://bugs.python.org/issue19462>
___
___
Python-bugs-list mailing list
Unsub
Paul Ganssle added the comment:
This isn't exactly "working as intended", but I believe it's a known problem
with either `import_fresh_module` or `datetime`, as you can see from these
comments:
https://github.com/python/cpython/blob/302e5a8f79514fd84bafbc44b7c97
Paul Ganssle added the comment:
> isoformat function does not conform to the ISO 8601 and drops microseconds
> part if its value is 00.
I'm not sure why you think that this does not conform to ISO 8601 - ISO 8601 is
a sprawling beast of a spec and allows some crazy fo
Paul Ganssle added the comment:
New changeset 975ac326ffe265e63a103014fd27e9d098fe7548 by Zackery Spytz in
branch 'master':
bpo-33262: Deprecate passing None for `s` to shlex.split() (GH-6514)
https://github.com/python/cpython/commit/975ac326ffe265e63a103014fd27e9d098fe7548
-
Paul Ganssle added the comment:
That is a specific problem with the third-party library `pytz`, not a standard
feature of the datetime module. Using `datetime.replace` is the intended way to
set a time zone, see:
https://blog.ganssle.io/articles/2018/03/pytz-fastest-footgun.html
As of
Paul Moore added the comment:
This works fine for me in Windows terminal, but I see the behaviour described
when using the conventional "Command prompt" window.
Enabling ANSI codes is handled via SetConsoleMode (see here:
https://docs.microsoft.com/en-us/windows/console/setconsole
New submission from Paul Ganssle :
It seems that test.support.import_fresh_module gets tripped up with its module
blocking when you attempt to get a fresh copy of a submodule of a module where
you are also importing the module that you are trying to block (bit of a doozy
of a sentence there
Paul Ganssle added the comment:
I can reproduce this on Linux with Python 3.8.2.
I think this may be a bug, but it may also just be platform-specific weirdness.
Either way it's very curious behavior:
>>> datetime.strptime("2023-0-0", "%Y-%W-%w")
Paul Ganssle added the comment:
Likely relevant is bpo-23136, where they dealt with similar issues in the past.
I don't see any explicit test for this behavior, but it seems that the solution
is to try to be consistent and to not raise a ValueError.
Looking at this issue, I think i
paul j3 added the comment:
'type=bool' doesn't get any special treatment. 'bool' is a builtin Python
function.
test with
def mybool(astr):
print("mybool:", astr, len(astr), bool(astr))
return bool(astr)
The trick to getting a False
Change by Paul Ganssle :
--
stage: -> needs patch
___
Python tracker
<https://bugs.python.org/issue40236>
___
___
Python-bugs-list mailing list
Unsubscrib
New submission from Paul Stoner :
I found this issue when running an ansible playbook. In the playbook we go out
to Azure Artifacts to download a customer jar to be deploy with a web
application.
After some digging, I found the error comes from the request class in the
urllib library
Paul Stoner added the comment:
--4/22/2020 09:36
I disconnected from my corporate vpn and ran the script over my private network
with the same result
--
___
Python tracker
<https://bugs.python.org/issue40
paul j3 added the comment:
This is a consequence of Python's own definition of append vs extend
In [730]: alist = []
In [731]: alist.append(
paul rubin added the comment:
I just saw this. Interesting. Sometimes I use ast.literal_eval to read big,
deeply nested data objects. I can probably convert to JSON if necessary but
it's another thing to watch out for. I might try to benchmark some of these.
--
nosy:
New submission from paul rubin :
It would be nice to have frozen Counters analogous to frozensets, so they are
usable as dictionary keys. One can of course create frozenset(counter.items())
but that means the set items are tuples rather than the original set elements,
so it's no l
Change by paul rubin :
--
nosy: -phr
___
Python tracker
<https://bugs.python.org/issue40334>
___
___
Python-bugs-list mailing list
Unsubscribe:
paul rubin added the comment:
Note, nowadays this is implement as itertools.chain.from_iterable .
--
___
Python tracker
<https://bugs.python.org/issue1726
paul rubin added the comment:
Yes, the idea was for them to be hashable, to be used as dict keys. E.g. if
you use frozensets to model graphs, you'd use frozen multisets for hypergraphs.
My immediate use case involved word puzzles, e.g. treating words as bags of
scrabble tiles with le
paul rubin added the comment:
Kyle, thanks, I saw your comment after posting my own, and I looked at
Raymond's mailing list post that you linked. I do think that "completing the
grid" is a good thing in the cases where it's obvious how to do it (if there's
one
paul rubin added the comment:
Oops I meant "*without* 100s of third party modules" in the case of ruby gems
or npm. There are just a few pip modules that I really use all the time, most
notably bs4. I continue to use urllib/urllib2 instead of requests because I'm
used to t
paul rubin added the comment:
Yeah I think the basic answer to this ticket is "Python doesn't really have
multisets and a proposal to add them should go somewhere else". Fair enough--
consider the request withdrawn from here.
Regarding minimalism vs completeness, regarding
paul rubin added the comment:
Totally tangential: Veky, your ordinal example would work ok in Haskell and
you'd have omega work the same way as epsilon0. Take a look at Herman Ruge
Jervell's book "Proof Theory" for a really nice tree-based ordinal notation
that g
paul j3 added the comment:
The display of the choices has been discussed in previous issues. When the
choices is long there isn't a clean way of handling the display.
I'd suggest using a 'metavar' to show a short value, and then enumerate the
choices in the help text.
New submission from Paul Martin :
According to the docs:
"
There are several ways to enable asyncio debug mode.
Setting the PYTHONASYNCIODEBUG environment variable to 1.
Using the -X dev Python command line option.
Passing debug=True to asyncio.run().
Calling loop.set_debug().
New submission from Paul Ganssle :
This is an issue to track the implementation of PEP 615:
https://www.python.org/dev/peps/pep-0615/
It should mostly involve migrating from the reference implementation:
https://github.com/pganssle/zoneinfo/
--
assignee: p-ganssle
components
Change by Paul Ganssle :
--
keywords: +patch
pull_requests: +19224
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/19909
___
Python tracker
<https://bugs.python.org/issu
Change by paul j3 :
--
nosy: +paul.j3
___
Python tracker
<https://bugs.python.org/issue40509>
___
___
Python-bugs-list mailing list
Unsubscribe:
paul j3 added the comment:
Handling the positional with '?' and '*' in a mutually_exclusive_group is
tricky enough!
I believe your user can use the '--' to get the same effect.
--
___
Python tracker
<h
paul j3 added the comment:
Related topic re. long usage with choices : https://bugs.python.org/issue16418
--
___
Python tracker
<https://bugs.python.org/issue40
paul j3 added the comment:
A flagged argument with REMAINDER works just fine in a mutually exclusive group.
group.add_argument('-g', nargs='...')
positionals in such a group can only have ? or *. If you check the code, and
past issues you'll see that those requ
New submission from Paul Ganssle :
One thing that I sort of overlooked in PEP 615 that I think will be a common
feature request for zoneinfo is the ability to get a list of time zones
available on the current TZPATH.
This is more complicated to implement than it sounds like, but luckily I
Paul Monson added the comment:
Yes I think this can be closed. Thank you!
--
status: pending -> open
___
Python tracker
<https://bugs.python.org/issu
Change by Paul Ganssle :
--
pull_requests: +19318
pull_request: https://github.com/python/cpython/pull/20006
___
Python tracker
<https://bugs.python.org/issue40
Paul Ganssle added the comment:
I've separated this into two separate PRs, one for docs and one for
tests/implementation.
I have not yet implemented the logic for the ability to configure the TZPATH at
compile time because I'm not quite sure how to start on that. How are other
co
Paul Ganssle added the comment:
I have an initial implementation against the reference implementation here:
https://github.com/pganssle/zoneinfo/pull/60
Once GH-19909 is merged, I will turn that into a PR against CPython.
For the first pass I went with:
1. free-standing function
2
Change by Paul Ganssle :
--
pull_requests: +19343
pull_request: https://github.com/python/cpython/pull/20034
___
Python tracker
<https://bugs.python.org/issue40
Paul Ganssle added the comment:
Thanks Thomas, that was super helpful. I've created GH-20034 to add in the
compile-time arguments on POSIX systems at least, do you mind having a look?
For the moment I have made it non-configurable on Windows, but I think the
right thing to do is to a
Change by Paul Ganssle :
--
keywords: +patch
pull_requests: +19344
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/19909
___
Python tracker
<https://bugs.python.org/issu
Change by Paul Ganssle :
--
pull_requests: -19344
___
Python tracker
<https://bugs.python.org/issue40536>
___
___
Python-bugs-list mailing list
Unsubscribe:
Paul Ganssle added the comment:
I mean, theoretically we don't "need" it, but it's much, much faster, and
without it nearly every operation that needs time zone offsets will be slower
than pytz (which has a mechanism for caching).
Also, I've already written it, s
Paul Ganssle added the comment:
Here are some benchmarks run using the latest implementation. The pure Python
code is pretty optimized, but the C code is still ~4-5x faster.
Running from_utc in zone Europe/Paris
c_zoneinfo: mean: 494.82 ns ± 3.80 ns; min: 489.23 ns (k=5, N=50)
py_zoneinfo
Paul Ganssle added the comment:
>From some discussion on the reference implementation PR, it seems that this
>may be a more complicated feature than I had bargained for:
>https://github.com/pganssle/zoneinfo/pull/60
The issue is that the current implementation picks up the posix/
Paul Ganssle added the comment:
Talked to Steve Dower in a sidebar about the issue with compile-time
configuration, he is convinced that compile-time configuration is not something
that would be useful or worth doing on Windows. I am indifferent on the matter,
so I am fine with calling the
paul rubin added the comment:
I'm the one always asking for more stuff in the stdlib, but above some
simplistic approaches this seems out of scope. Doing it usefully above say
2**32 requires fancy algorithms. Better to use some external package that
implements that stuff.
--
paul rubin added the comment:
https://bugs.python.org/issue457066 The old is new again ;-).
--
nosy: +phr
___
Python tracker
<https://bugs.python.org/issue36
New submission from paul rubin :
This is a well-explored issue in other contexts:
https://en.wikipedia.org/wiki/JSON_streaming
There is also a patch for it in json.tool, for release in 3.9:
https://bugs.python.org/issue31553
Basically it's often convenient to have a file containing a
Change by paul rubin :
Added file: https://bugs.python.org/file49154/jsonstream.py
___
Python tracker
<https://bugs.python.org/issue40623>
___
___
Python-bugs-list mailin
paul rubin added the comment:
Note: the function in my attached file wants no separation at all between the
json docs (rather than a newline between them), but that was ok for the
application I wrote it for some time back. I forgot about that when first
writing this rfe so thought I better
601 - 700 of 3008 matches
Mail list logo