Paul Silisteanu added the comment:
Same issue on Window 10 and macOS Catalina with Python 3.8.0.
Here is the error I get on Windows 10:
C:\Users\x>py -3.8
Python 3.8.0 (tags/v3.8.0:fa919fd, Oct 14 2019, 19:37:50) [MSC v.1916 64 bit
(AMD64)] on win32
Type "help", "copyri
Change by Paul Martin :
--
keywords: +patch
pull_requests: +16341
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/16779
___
Python tracker
<https://bugs.python.org/issu
Change by Paul Martin :
--
versions: +Python 3.9
___
Python tracker
<https://bugs.python.org/issue38471>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Paul Martin :
Expected behaviour for DatagramTransport (from_SelectorDatagramTransport):
transport.close() called.
If there is data in the write buffer, don't call connection_lost.
When all data is written and the buffer is empty, check if connection has been
lost a
Paul Martin added the comment:
Should singledispatchmethod and cached_property be added?
--
nosy: +primal
___
Python tracker
<https://bugs.python.org/issue37
Paul added the comment:
> Problem is you follow it with:
>
> fo = os.fdopen(fd, 'rb+')
> which introduces a Python level of buffering around the kernel unbuffered
> file descriptor. You'd need to pass buffering=0 to make os.fdopen avoid
> returning a buffe
Paul added the comment:
> I agree with Josh. If you want to use O_DIRECT, use an unbuffered file object
> and be sure to issue reads of the right size.
I do not believe an unbuffered file uses O_DIRECT. This is why I use
os.open(fpath, os.O_DIRECT).
> Also I'm curious: why
Paul Moore added the comment:
Sigh. Never mind, this appears to be because virtualenv uses its own hacked
copy of site.py which is missing a lot of the venv support code.
I'll report this over on virtualenv.
--
resolution: -> third party
stage: -> resolved
status: ope
Paul Moore added the comment:
Further update - this appears to also happen on Ubuntu (at least the version
available through the Windows Linux subsystem), so it's not a Windows-specific
issue.
--
assignee: steve.dower ->
___
Python
Paul Moore added the comment:
This appears to be somehow caused by running Python 3.7.4 from an active
virtualenv (which I'd forgotten I had active when I did the test).
Regardless, I'd have expected that the command would either correctly create a
venv containing pip, or fail to
New submission from Paul Moore :
The venv module with Python 3.4 on Windows doesn't install pip - even though
the --without-pip flag is not specified. This appears to be a regression since
pip is installed when using 3.7:
>C:\Utils\PythonVersions\Python-3.7.3\python.exe -m venv ve-
Paul Ganssle added the comment:
>From what I can tell, this is a Python 2.7-only bug, and it's not a security
>issue, so I think we can close the issue as either "wontfix" (because we won't
>fix it in Python 2) or "fixed" (because it is already
paul rubin added the comment:
I don't think we're going to accomplish anything continuing the eternal
static-vs-dynamic debate, which in Python's case has already been resolved by
adding optional static typing. It's a done deal, and the issue here is just
how to docum
paul rubin added the comment:
At first glance, having a typeclass for each protocol (at least the widely used
ones) seems fine. It's inherent in Haskell and a lot of libraries are
organized around a common set of typeclasses--look up "Typeclassopedia" for
descriptions of t
paul rubin added the comment:
abs takes any value that understands the __abs__ method and returns something
of the same type. In fact there is already a type protocol for it:
https://mypy.readthedocs.io/en/stable/protocols.html#supportsabs-t
So abs's signature would be (x : Abs[T])
paul rubin added the comment:
Yes, the suggestion was just for the docs, and since those are intended for
human rather than machine consumption, it's fine if there are some blurry cases
where there is no signature. Ideally in those cases, the issue should be
explained in the doc tex
New submission from paul rubin :
It would be nice if the library reference manual had type signatures for all
the stdlib functions at some point. It might be possible to extract a lot of
them automatically from typeshed and semi-automatically paste them into the doc
files. It might also be
New submission from Paul Sokolovsky :
CPython's Data Model -> Internal types -> Code objects, direct link as of
version 3.7 is:
https://docs.python.org/3.7/reference/datamodel.html?highlight=co_stacksize#index-55
, states following:
* "co_nlocals is the number of local varia
Paul Martin added the comment:
run_in_executor doesn't necessarily create a new thread each time so
create_thread would be misleading. run_in_thread might be better.
--
nosy: +primal
___
Python tracker
<https://bugs.python.org/is
Paul Ganssle added the comment:
I checked and it appears that `attrs` handles this by creating *all* dicts
using the default dict_factory (similar to my original suggestion of just using
`dict` instead of the specific type), if I'm reading this right:
https://github.com/python-attrs/
Paul Ganssle added the comment:
Considering that `namedtuple` is special-cased, I think it's reasonable to
special-case `defaultdict` as well, though it may be worth considering more
general solutions that will also work for things other than the standard
library. One would be to solve
Change by Paul Ganssle :
--
pull_requests: +15935
pull_request: https://github.com/python/cpython/pull/16356
___
Python tracker
<https://bugs.python.org/issue35
Paul Ganssle added the comment:
Closing this as resolved. I don't think we should backport this, as it's more
of an enhancement than a bug fix (and since no one has ever complained about it
to my knowledge, I don't think there's any big rush to see this released).
Than
Paul Ganssle added the comment:
New changeset 96b1c59c71534db3f0f3799cd84e2006923a5098 by Paul Ganssle (t k) in
branch 'master':
bpo-38155: Add __all__ to datetime module (GH-16203)
https://github.com/python/cpython/commit/96b1c59c71534db3f0f3799cd84e20
paul j3 added the comment:
Which is more valuable to you, the string conversion, or the checking?
What's wrong with doing the 'type check' in post parsing code? (MarSoft's
answer in the SO link).
To make a better case for this, I'd suggest writing your own fix.
Paul Ganssle added the comment:
Is this issue only in Python 3.6? I believe Python 3.6 is only receiving
security fixes at the moment, so this could only be fixed in 3.7, 3.8 and 3.9.
--
nosy: +p-ganssle
___
Python tracker
<ht
Paul added the comment:
This is the platform that I'm working on as well as the failure. I have a
review out for a fix.
# uname -a
Linux init129-13 3.10.0-957.el7.x86_64 x86_64 x86_64 x86_64 GNU/Linux
# python3.7 directread.py
Traceback (most recent call last):
File "small.py&qu
Change by Paul :
--
pull_requests: +15742
pull_request: https://github.com/python/cpython/pull/16131
___
Python tracker
<https://bugs.python.org/issue38
Change by Paul :
--
keywords: +patch
pull_requests: +15741
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/16130
___
Python tracker
<https://bugs.python.org/issu
New submission from Paul :
The following Python3 script fails.
import mmap
import os
fd = os.open(path_to_file, os.O_DIRECT | os.O_RDWR)
fo = os.fdopen(fd, 'rb+')
m = mmap.mmap(-1, 4096)
fo.readinto(m)
But it worked for Python2. It also works for any other multiple of 4K. For
e
Paul Ganssle added the comment:
The current state of the PR doesn't hinge on the pure Python implementation, we
went with a very simple tuple subclass to keep the two more closely in sync and
because we don't need any of the additional functionality that namedtuple
brings, but
Paul added the comment:
I've dug into stracing this python program in 2.7 vs. 3.7.
directread.py
import mmap
import os
fd = os.open('/dev/dm-2', os.O_DIRECT | os.O_RDWR) # mapped block device
fo = os.fdopen(fd, 'rb+')
m = mmap.mmap(-1, 4096)
fo.readinto(m)
Pyt
Paul Ganssle added the comment:
New changeset d6a9d17d8b6c68073931dd8ffa213b4ac351a4ab by Paul Ganssle
(Elizabeth Uselton) in branch 'master':
bpo-37555: Update _CallList.__contains__ to respect ANY (#14700)
https://github.com/python/cpython/commit/d6a9d17d8b6c68073931dd8ffa213b
Paul Ganssle added the comment:
Actually, how about adding this simpler test into `Lib/test/datetimetester.py`,
right above test_name_cleanup
(https://github.com/python/cpython/blob/ff2e18286560e981f4e09afb0d2448ea994414d8/Lib/test/datetimetester.py#L65):
def test_all(self
Paul Ganssle added the comment:
Hi Tahia: Go ahead and make a PR, no need to worry about the test.
I mainly put in the bit about tests because I was hoping to nerd-snipe someone
into figuring out how to do it for me ;) It's not a particularly important
New submission from Paul Ganssle :
Currently the datetime module has no __all__, which means we only advertise
what is public and private based on leading underscores. Additionally, because
there are two implementations (Python and C), you actually get different things
when you do `from
Paul added the comment:
Michael,
I ran into the same issue as you. I got it to work by changing the mmap size
to 8K.
d = os.open(disk_file_path, os.O_RDWR | os.O_DIRECT | os.O_SYNC | os.O_DSYNC)
readbuf = mmap.mmap(-1, 8192)
os.lseek(d, 0, os.SEEK_SET)
fo = os.fdopen(d, 'rb')
f
Paul Ganssle added the comment:
Thanks Joannah!
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Paul Ganssle added the comment:
Hi Yixing, thank you for your bug report. This issue has already been reported,
and the discussion is in issue #22377.
In the short term I believe the solution will be to document the current
behavior. In the long term there are some solutions, though I
Change by Paul Ganssle :
--
stage: -> needs patch
versions: +Python 3.7, Python 3.8, Python 3.9 -Python 3.5, Python 3.6
___
Python tracker
<https://bugs.python.org/issu
Paul Ganssle added the comment:
We've merged the PR and I think it resolves this issue, so we can close this
issue now. Please let me know if it's not fully resolved and we can re-open.
Thanks Roger for reporting this and Harmandeep for making the PR and requeste
Paul Ganssle added the comment:
New changeset 2d32bf1ef23c9e468b2e8afab3c24e7a2047ac36 by Paul Ganssle
(Harmandeep Singh) in branch 'master':
bpo-13927: time.ctime and time.asctime return string explantion (GH-11303)
https://github.com/python/cpyt
Paul Ganssle added the comment:
Sorry guys, my mistake. I think I was a bit caught up in the workflow at the
sprint where I've been going through the review-cleanup-merge process a lot
faster than I usually do (partially since I have the time and partially since
the huge number o
Paul Ganssle added the comment:
New changeset 8ed6503eca4e3ea4949479d8d7fd9ffd54f81038 by Paul Ganssle (Jason
R. Coombs) in branch 'master':
bpo-38121: Sync importlib.metadata with 0.22 backport (GH-15993)
https://github.com/python/cpython/commit/8ed6503eca4e3ea4949479d8d7fd9f
Change by Paul Ganssle :
--
pull_requests: +15596
stage: backport needed -> patch review
pull_request: https://github.com/python/cpython/pull/15962
___
Python tracker
<https://bugs.python.org/issu
Change by Paul Ganssle :
--
pull_requests: +15595
status: pending -> open
pull_request: https://github.com/python/cpython/pull/15961
___
Python tracker
<https://bugs.python.org/issu
Change by Paul Ganssle :
--
resolution: -> fixed
stage: patch review -> backport needed
status: open -> pending
___
Python tracker
<https://bugs.python.or
Paul Ganssle added the comment:
New changeset 7117074410118086938044c7a4ef6846ec1662b2 by Paul Ganssle (Raymond
Hettinger) in branch 'master':
bpo-38096: Clean up the "struct sequence" / "named tuple" docs (GH-15895)
https://gi
Change by Paul Ganssle :
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
versions: +Python 3.9 -Python 3.8
___
Python tracker
<https://bugs.python.or
Paul Ganssle added the comment:
New changeset 3fb1363fe87a24cdb2ee1dd9746f1c49046af958 by Paul Ganssle (Brad)
in branch 'master':
Overhaul datetime documentation (GH-13410)
https://github.com/python/cpython/commit/3fb1363fe87a24cdb2ee1dd9746f1c
Paul Ganssle added the comment:
This is done, thanks Petr and Jeroen!
I don't see a need to backport this unless we also want to backport GH-14311 or
something else that depends on it.
--
resolution: -> fixed
stage: patch review -> resolved
status: ope
Paul Ganssle added the comment:
Hi Abhisek,
This is actually the expected / intended behavior, and it is documented under
"strptime() and strftime() behavior":
https://docs.python.org/3/library/datetime.html#strftime-strptime-behavior
(which is linked to by the time.strftime doc
New submission from Paul Ganssle :
The datetime module has a capsule API, which is very useful for other
languages' bindings, but the C API documentation for datetime only covers the C
macros: https://docs.python.org/3/c-api/datetime.html
The current extent of the documentation is
Paul Ganssle added the comment:
I have compiled both versions with optimizations on, looks like the gap gets a
bit smaller (percentage-wise) after that:
benchmark| master (ns) | PR 15633 (ns) | Δ
Paul Ganssle added the comment:
I haven't had time to try this with an optimized build, I have done a few more
benchmarks using a standard build, I'm seeing almost a 50% regression on
isocalendar() calls, but the picture is a little rosier if you consider the
fact that you need to
Paul Ganssle added the comment:
In an effort to get a sense of how useful this would actually be, I did a code
search for `.isoformat()` on github. I saw a few doctests that will break (if
they're even being run) if we make this change, but I also found that the
*vast* majority of us
Paul Ganssle added the comment:
> What IS unprecedented is having a C function bend over backwards to return an
> instance of collections.namedtuple().
Is this an issue that anyone is currently insisting upon? From what I can tell
the current implementation uses a structseq and none
Paul Ganssle added the comment:
> Dong-hee Na, if you want to make a fresh PR for this and bring it to
> fruition, I would be happy to review and apply it.
It seems premature to say that you will accept a PR for this when there's no
consensus for actually adding the feature, and
Paul Ganssle added the comment:
> But I'm wondering how the `fromisocalendar` API relates to this patch.
> Rather, wouldn't this patch contribute to improving the usability of the
> `fromisocalendar` API?
The `fromisocalendar` API relates to this patch only insofar as
Paul Ganssle added the comment:
Sorry for the late response after a patch, but I'm actually -1 on this patch. I
don't think it buys us very much in terms of the API considering it only has 3
parameters, and it adds some complexity to the code (in addition to the
performance issue)
Paul Ganssle added the comment:
This is only a semi-arbitrary restriction. Realistically, `datetime` is not a
particularly good way to represent times much older than the 17th or 18th
century (and if you're using time zones, it gets increasingly inaccurate as you
go further back from
Change by paul j3 :
--
nosy: +paul.j3
status: closed -> open
___
Python tracker
<https://bugs.python.org/issue27227>
___
___
Python-bugs-list mailing list
Un
Change by Paul Ganssle :
--
keywords: +patch
pull_requests: +15272
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/15596
___
Python tracker
<https://bugs.python.org/issu
New submission from Paul Ganssle :
Per Antoine's comment in the discourse thread (
https://discuss.python.org/t/parse-z-timezone-suffix-in-datetime/2220/6 ):
> ... the doc isn’t helpful, as it doesn’t give any alternative.
I think we can link to dateutil.parser.isoparse as an alt
Paul Ganssle added the comment:
> Defining isoformat() and fromisoformat() as functional inverses is misguided.
> Indeed, it's not even true:
`isoformat()` is not the inverse of `fromisoformat()`, that doesn't work
because there are multiple strings that isoformat() can
Paul Ganssle added the comment:
This is a duplicate of #35829.
The reason that 'Z' is not supported is that `fromisoformat()` is not a general
ISO 8601 parser, but rather is intended to be the inverse of `isoformat()`. See
the documentation here:
https://docs.python.org/d
paul j3 added the comment:
https://bugs.python.org/issue26510
https://bugs.python.org/issue33109
There was some flip/flop over whether required should be true by default or not
- the current behavior is False, (the 3.3.0)
The lasting change since this issue in 2012 is that `add_subparsers
Paul Ganssle added the comment:
> I would support this addition. The timedelta class already has accessors for
> days and seconds, why not for hours and minutes?
The `timedelta.days` and `timedelta.seconds` accessors do not do what is being
requested here. The component accessors jus
paul j3 added the comment:
That usage formatting is extremely brittle. It's not just "" metavar that can
mess it up. Other 'usual' characters can mess it in the same way.
The underlying problem is that it formats the whole usage, and if it is too
long tries to
paul j3 added the comment:
But see
https://bugs.python.org/issue37793
for a discussion of whether 'container' is as good a descriptor as 'iterable'.
--
___
Python tracker
<https://bug
paul j3 added the comment:
hai shi
Do you have a specific need for this, or do you want it just for the same of
completeness?
--
___
Python tracker
<https://bugs.python.org/issue9
Change by Paul Ganssle :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Paul Ganssle added the comment:
New changeset ed44b84961eb0e5b97e4866c1455ac4093d27549 by Paul Ganssle in
branch '3.7':
bpo-37642: Update acceptable offsets in timezone (GH-14878) (#15226)
https://github.com/python/cpython/commit/ed44b84961eb0e5b97e4866c1455ac
Paul Ganssle added the comment:
New changeset 27b38b99b3a154fa5c25cd67fe01fb4fc04604b0 by Paul Ganssle in
branch '3.8':
bpo-37642: Update acceptable offsets in timezone (GH-14878) (#15227)
https://github.com/python/cpython/commit/27b38b99b3a154fa5c25cd67fe01fb
Paul Moore added the comment:
This is normal behaviour of the Windows console command line editing. Python
simply inherits the standard console behaviour.
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Pytho
paul j3 added the comment:
I'm not set up to work with the current development distribution (via github).
All my proposed patches are diffs for earlier repos.
Paul
--
___
Python tracker
<https://bugs.python.org/is
Paul Moore added the comment:
To clarify, I think adding the label needs core dev (or maybe triager) rights
on github, so I don't think it's something you can do yourself.
--
___
Python tracker
<https://bugs.python.o
Paul Moore added the comment:
I added the label for you.
--
___
Python tracker
<https://bugs.python.org/issue25172>
___
___
Python-bugs-list mailing list
Unsub
paul j3 added the comment:
This patch lacks proper documentation, and is too English language specific.
For users who assume 'type' means a class rather than function (callable) this
change does not need documentation, since it accommodates that assumption. But
more experienced
Change by Paul Ganssle :
--
pull_requests: +14951
pull_request: https://github.com/python/cpython/pull/15227
___
Python tracker
<https://bugs.python.org/issue37
Change by Paul Ganssle :
--
pull_requests: +14950
pull_request: https://github.com/python/cpython/pull/15226
___
Python tracker
<https://bugs.python.org/issue37
New submission from Paul Martin :
I found these two methods in the windows_events code for asyncio. Is there a
reason why they don't seem to be documented, and are not included in
AbstractServer? They provide a good Windows alternative to create_unix_server &
create_unix_connection
Paul Ganssle added the comment:
New changeset 92c7e30adf5c81a54d6e5e555a6bdfaa60157a0d by Paul Ganssle (Ngalim
Siregar) in branch 'master':
bpo-37642: Update acceptable offsets in timezone (GH-14878)
https://github.com/python/cpython/commit/92c7e30adf5c81a54d6e5e555a6bdf
Paul Moore added the comment:
It shouldn't be hard to update the regex to accept either "... " followed by
other text or "..." on a line on its own, surely?
--
nosy: +paul.moore
___
Python tracker
<https:
Paul Moore added the comment:
That's where I decided it was too complex for now :-)
The whole test_crypt.py file is skipped if you can't import crypt, via the use
of the test.support.import_module() function. To be able to write a test for a
platform where the whole point is that
Paul Moore added the comment:
On reflection, adding a test for the Windows-specific behaviour looks like it
could be more complex than I'd anticipated, so I'm happy for this to go in
without an extra test. I'll look at adding a test in a follow-up PR (or if
someone else w
Paul Moore added the comment:
New changeset f4e725f224b864bf9bf405ff7f863cda46fca1cd by Paul Moore
(shireenrao) in branch 'master':
bpo-25172: Raise appropriate ImportError msg when crypt module used on Windows
(GH-15149)
https://github.com/python/cpyt
Change by Paul Monson :
--
pull_requests: +14913
pull_request: https://github.com/python/cpython/pull/15181
___
Python tracker
<https://bugs.python.org/issue36
Change by Paul Francis :
--
resolution: duplicate ->
status: closed -> open
___
Python tracker
<https://bugs.python.org/issue37786>
___
___
Python-bugs-
Paul Francis added the comment:
This is regarding the GUI uninstall program that is accessedd via Programs &
Features (formerly known as Add/Remove Programs) in Control Panel. Sorry I
didn't make this clear.
That "duplicate" report seems to be for a Command Line method o
New submission from Paul Francis :
Neither the 32bit nor the 64bit version of Python 3.7.4 will remove the PATH
variables from the System Environment Variables of the O/S even though the
uninstallation screen explicitly displays a message that infers it is doing so.
Windows 10 Pro x64 v1903
Paul Moore added the comment:
It might be worth adding a test (running only on Windows) to confirm that if
you try to import crypt you get an import error with a message that includes
the phrase "not supported". That will ensure that we don't get regressions here
in future,
Paul Moore added the comment:
The proposed wording seems good to me.
--
___
Python tracker
<https://bugs.python.org/issue25172>
___
___
Python-bugs-list mailin
Paul Monson added the comment:
If you try to create a datagram socket with the current AF_UNIX changes on
Windows the error is:
OSError: [WinError 10047] An address incompatible with the requested protocol
was used
All of the examples given will fail to load with AttributeError on Windows
paul j3 added the comment:
As discussed in https://bugs.python.org/issue23487, `action` works if the class
is compatible with argparse._SubParsersAction.
these commands all do the same thing:
parser.add_subparsers() # default
parser.add_subparsers(action='pa
Paul Ganssle added the comment:
@veky I can't be sure, but I think you may not understand what returning
`NotImplemented` does - this makes comparisons *more* versatile, not less.
The way it works is that when Python does, for example, x == y, it will first
call x.__eq__(y) and chec
Paul Ganssle added the comment:
I have been thinking about this more and I think the two issues (`min` and
`max` vs. the incompatibility between C and Python) should be considered two
separate issues.
My reasoning is that a change of the value of `timezone.min` and `timezone.max`
is not
Paul Ganssle added the comment:
I agree that the C and Python behavior should be the same, and both of them
should allow all offsets less than 24 hours. I'm actually quite surprised we
don't have a test for this in `datetimetester.py`.
--
stage: ->
Paul Ganssle added the comment:
> So is the proposed change, in a way. At some point, there will be a 4.0
> release, which may or may not break the code in question.
I don't think it's a foregone conclusion that there will be a 4.0 release. It
could be that we decide th
Paul Ganssle added the comment:
New changeset 9cd39b16e2655f748f7aa8d20bca4812da00ba70 by Paul Ganssle (Paul
Monson) in branch 'master':
bpo-37552: Skip failing tests in strptime/strftime with UCRT version 17763.615
(#14460)
https://github.com/python/cpyt
601 - 700 of 3213 matches
Mail list logo
