Paul Ganssle added the comment:
What is an example of another Python implementation that has this property? Is
there a concrete issue open somewhere that this is solving?
I am not unsympathetic to the idea of accommodating other implementations of
Python, but this is very abstract and I
Paul Ganssle added the comment:
I am not seeing any compelling reasons to avoid supporting negative indexes
*or* slices here.
If I had to guess about the confusing semantics of negative indices, I would
guess it's the fact that the index in the -1 position for a non-empty Path will
a
Paul Ganssle added the comment:
One question I would have about this is that `.parents` is a lazily-calculated
sequence, not a list or a tuple, so it's not immediately obvious what the
return type of a slice would be. I don't think it makes sense to return, e.g. a
`_PathParents` o
Paul Ganssle added the comment:
New changeset 452058448335b39c784af9a047f9c4a1767c0b00 by Joshua Cannon in
branch 'master':
bpo-35498: Added slice support to PathLib parents attribute. (GH-11165)
https://github.com/python/cpython/commit/452058448335b39c784af9a047f9c4
Change by Paul Ganssle :
--
dependencies: -pathlib.PurePath.parents rejects negative indexes
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Paul Ganssle added the comment:
I think you may have confused my thoughts as to why this might be considered
ambiguous with an actual suggestion for what the semantics should be.
I think that we should stick with `p.parents[x] == tuple(p.parents)[x]` for any
valid value of `x`, which means
New submission from Paul Ganssle :
Currently, it seems that the pathlib module uses `.. data::` to annotate the
properties of the PurePath type (e.g. .parts, .drive, .root, etc). See:
https://github.com/python/cpython/blob/ff420f0e08a2443339da0df7ace95e14177bac53/Doc/library/pathlib.rst
Paul Ganssle added the comment:
New changeset 79d2e62c008446fbbc6f264bb8a30e2d38b6ff58 by Yaroslav Pankovych in
branch 'master':
Added support for negative indexes to PurePath.parents (GH-21799)
https://github.com/python/cpython/commit/79d2e62c008446fbbc6f264bb8a30e
Paul Ganssle added the comment:
New changeset 79d2e62c008446fbbc6f264bb8a30e2d38b6ff58 by Yaroslav Pankovych in
branch 'master':
Added support for negative indexes to PurePath.parents (GH-21799)
https://github.com/python/cpython/commit/79d2e62c008446fbbc6f264bb8a30e
Paul Ganssle added the comment:
Responding to a comment on the PR:
> Now, that said you might want to consider the fact that in
> _fold_mime_parameters I deal with this issue by bumping maxlen to 78 rather
> than raising an error. I'm not sure that was the right choice, but
New submission from Paul Ganssle :
In PR 5640 (https://github.com/python/cpython/pull/5460), a warning was added
that importing ABCs from collections directly is deprecated and will be removed
in Python 3.8, but they have not yet been removed and the warning is still
active.
If they are
Paul Ganssle added the comment:
@gphelmsley Can you clarify what you mean by this?
Do you have a minimal reproducing example that shows what's happening and what
you are expecting?
--
___
Python tracker
<https://bugs.python.org/is
Paul Ganssle added the comment:
Hm, I was a bit confused by your wording here, because I am able to trigger all
the errors just fine even before this PR, but I do think that even though this
isn't necessarily fixing inaccurate error messages (all the error messages
*are* accurate), y
Change by Paul Ganssle :
--
nosy: +p-ganssle
___
Python tracker
<https://bugs.python.org/issue30802>
___
___
Python-bugs-list mailing list
Unsubscribe:
Paul Ganssle added the comment:
> I respectfully disagree with logic, "the language now permits this, so we
> should change all the docs to display it everywhere". That moves it from
> optional knowledge to mandatory knowledge, from a day ten lesson to a day one
> l
Paul Ganssle added the comment:
I think the reason for the difference here is in the `no_error` function you
never actually create the coroutine `true()`, so there's nothing to warn about.
One thing that's confusing things about this example is that the `false()`
evaluates to Tru
Paul Ganssle added the comment:
New changeset 6b9c204ee77a0de87d6f51a3d4547a18604cef9e by Paul Ganssle (Mike
Gleen) in branch 'master':
bpo-34903: Document that some strptime formats only require 1 digit (GH-14149)
https://github.com/python/cpyt
Paul Ganssle added the comment:
Thanks for the PR, Mike! This is now merged and backported to Python 3.7, so I
believe we can close this issue.
--
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.p
Change by Paul Ganssle :
--
resolution: -> fixed
___
Python tracker
<https://bugs.python.org/issue34903>
___
___
Python-bugs-list mailing list
Unsubscrib
Paul Ganssle added the comment:
> why the code is executed?
> I could do a library or a package and include evil code instead of a
> print...
The code is executed because the decorator syntax
@decorator
def f():
...
Is equivalent to
def f():
...
f =
Change by Paul Ganssle :
--
nosy: -p-ganssle
___
Python tracker
<https://bugs.python.org/issue37418>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Paul Ganssle :
Between Python 2 and Python 3, the meaning of a naive datetime underwent a
subtle change. Previously a naive datetime was mostly treated as an abstract
datetime in the same way a unitless number is treated as an abstract quantity
(this is reflected in the
New submission from Paul Ganssle :
Currently, `test_pycfunction` picks a few built-in functions with various
calling conventions to exercise all the relevant code paths:
for py_name, py_args, c_name, expected_frame_number in (
('gmtime', '
Paul Ganssle added the comment:
> CPython has acted the current way for about 15 years (since 2.4 was
> released), and this is the first time anyone has raised an objection.
This is the expected result of fixing a bug that has been open since 2008 (11
years), which itself was n
Paul Ganssle added the comment:
@Lanteri If you'd like you can make a pull request against the French
documentation here: https://github.com/python/python-docs-fr
The relevant file is library/datetime.po
It also seems like the French documentation has its own issue tracker, here:
Paul Ganssle added the comment:
New changeset e6b46aafad3427463d6264a68824df4797e682f1 by Paul Ganssle (Xtreak)
in branch 'master':
bpo-37579: Improve equality behavior for pure Python datetime and time
(GH-14726)
https://github.com/python/cpyt
Change by Paul Ganssle :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Paul Ganssle added the comment:
Maybe I am missing something, but while it is true that DjangoModel is doing
the wrong thing by returning False instead of NotImplemented, the `ANY`
sentinel is supposed to match *anything*, not just things that compare equal to
it, right? I would expect this
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
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:
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:
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:
@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:
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
Change by Paul Ganssle :
--
pull_requests: +14950
pull_request: https://github.com/python/cpython/pull/15226
___
Python tracker
<https://bugs.python.org/issue37
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 :
--
nosy: +p-ganssle
___
Python tracker
<https://bugs.python.org/issue35317>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Paul Ganssle :
It seems that if you call skipTest *anywhere* in a test function, even in a
subTest, the *entire* function gets marked as "skipped", even if only one
sub-test is skipped.
Example:
import unittest
class SomeTest(unittest.TestCase):
Paul Ganssle added the comment:
As "prior art" the way that pytest does this is to have parametrized tests show
up as separate tests:
import pytest
@pytest.mark.parametrize("i", range(1, 3))
def test_something(i):
if i > 1:
pyt
Paul Ganssle added the comment:
@Rémi Interesting. Your suggested output does look clearer than the existing
one, but it still doesn't indicate that anything *passed*. I think I like the
way pytest does it the best, but if we can't expose the subtests as separate
tests, I'd p
Change by Paul Ganssle :
--
nosy: +p-ganssle
___
Python tracker
<https://bugs.python.org/issue35385>
___
___
Python-bugs-list mailing list
Unsubscribe:
Paul Ganssle added the comment:
Might it be worth moving `nextmonth` and `prevmonth` to `calendar._nextmonth`
and `calendar._prevmonth` to make it more clear that these are private methods?
Due to Hyrum's Law, people will be using them anyway, but it could have a short
deprecation p
Paul Ganssle added the comment:
This is another manifestation of issue 32417.
The biggest complication, to me, is that adding a `timedelta` to a datetime
always returns a `datetime.datetime` rather than the subclass that it was added
to.
I *think* most if not all people would consider this
Paul Ganssle added the comment:
> This is not easy problem, ant it doesn't have right solution. Different
> decisions were made for the result type of alternate constructors and
> operators for different classes.
It's certainly true that it occasionally makes sense to do
Paul Ganssle added the comment:
This issue was fixed in Python 3.7, and it turns out issue 31222 was a
duplicate of it. It can be closed now.
--
nosy: +p-ganssle
___
Python tracker
<https://bugs.python.org/issue20
Paul Ganssle added the comment:
Another thing to note: I'm pretty sure this was a mistake in the first place.
There are many examples of places where the datetime module was just not
designed with inheritance in mind, for example:
- issue 32404 / issue 32403 - fromtimestamp not ca
Change by Paul Ganssle :
--
keywords: +patch
pull_requests: +10142
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue32417>
___
___
Py
Change by Paul Ganssle :
--
keywords: +patch
pull_requests: +10143
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue35364>
___
___
Py
Paul Ganssle added the comment:
I'm not sure I agree with how this was resolved. We're adding complexity to the
datetime unpickler to support unpickling pickles created in Python 2 in Python
3? I also don't really understand the encoding parts of it, but it smells very
fishy
Paul Ganssle added the comment:
@Serhiy Any chance we can roll these back before the release so that they can
have some time for discussion? I have serious concerns about having to support
some Python 2/3 compatibility hack in datetime for the next 6 years. If this is
worth doing at all, I
Paul Ganssle added the comment:
I do not care enough about this to fight about it.
The issue has been open long enough that I do not think it justified the
urgency of rushing through a patch just before the release and merging without
review, but now that it is in the release of multiple
Change by Paul Ganssle :
--
nosy: -p-ganssle
___
Python tracker
<https://bugs.python.org/issue22005>
___
___
Python-bugs-list mailing list
Unsubscribe:
Paul Ganssle added the comment:
I am somewhat uneasy about backporting this to Python 2.7 because changing the
return type of `SomeDateTime + timedelta` could be seen as a breaking change. I
have sent a message to the datetime-SIG mailing list about this for more
visibility.
If it is
Paul Ganssle added the comment:
Ah, that's my mistake. I have always been under the impression that "Versions"
meant "versions affected", not "versions that this needs to be fixed for". I
usually just selected the ones where I had verified that it's a
Paul Ganssle added the comment:
> What's the use case for subclassing DateTime? These classes were not designed
> with subclassing as a use case in mind.
There are several reasons for doing it, of various levels of legitimacy. The
overall theme is that people want different beh
Paul Ganssle added the comment:
I don't really know what Python was doing in version 2.3, and I don't have
immediate access to a Python 2.3 interpreter, but at least for %U and %W,
datetime is calling the platform's `strftime` under the hood, so presumably if
this is a bu
Paul Ganssle added the comment:
I agree with Victor on this. In the future, I'd really like to see us do our
best to add cross-platform uniformity to Python's strftime and strptime
support. If there really is a platform out there that doesn't support a
trailing `%`, I l
New submission from Paul Ganssle :
When examining the performance characteristics of pytz, I realized that pytz's
eager calculation of tzname, offset and DST gives it an implicit cache that
makes it much faster for repeated queries to .utcoffset(), .dst() and/or
.tzname() though the
Change by Paul Ganssle :
--
keywords: +patch
pull_requests: +11122
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue35723>
___
___
Py
Paul Ganssle added the comment:
One other thing I might mention here is that I did explore the idea of storing
this cache on the tzinfo implementation itself, but it is problematic for a
number of reasons:
1. It would either need to use some sort of expiring cache (lru, ttl) or
require a
Paul Ganssle added the comment:
> I dislike adding a public API for an optimization. Would it be possible to
> make it private? Would it make sense? tzidx => _tzidx.
This also would have been my preference, but it is unfortunately not possible
because of the way tzinfo works. tzi
Paul Ganssle added the comment:
You can see the discussion in bpo-15873 for the full rationale of why "Z" was
omitted - to quote from https://bugs.python.org/issue15873#msg307607 :
> We can have further discussion later about what exactly should be supported
> in Python 3.
Paul Ganssle added the comment:
> I can see your point in not causing confusion about what this method is
> meant to be used for.
In this case, making it easy to explain what it does is less important than
making the scope and contract of the function clear so that we don't hav
Paul Ganssle added the comment:
> It seems a little odd to need to pull in a third-party library for this; it
> seems far more tempting for me to just do
> "datetime.fromisoformat(str.replace('Z', '+00:00'))" instead since I know my
> dates are pr
Paul Ganssle added the comment:
Possibly related to 35535.
--
nosy: +p-ganssle
___
Python tracker
<https://bugs.python.org/issue35841>
___
___
Python-bugs-list m
Paul Ganssle added the comment:
I think this is not a bug. bpo-35535 is probably also intended behavior, but
that is less certain.
The misunderstanding here is that %W does not give you the ISO week number,
from the documentation:
%W: Week number of the year (Monday as the first day of
Change by Paul Ganssle :
--
nosy: +p-ganssle
___
Python tracker
<https://bugs.python.org/issue35893>
___
___
Python-bugs-list mailing list
Unsubscribe:
Paul Ganssle added the comment:
@Ronald The module you've linked to seems to be using flit and doesn't have any
C extensions. Did you change over the build process, or am I missing something?
--
___
Python tracker
<https://bu
Paul Ganssle added the comment:
@Ronald Ah, interesting, I missed that.
In my experience, distutils is pretty static and it's not particularly common
to merge changes into it. Whether or not this is in scope for distutils, it's
definitely in scope for setuptools - do you mind
Paul Ganssle added the comment:
Well, there's some tentative plan for `setuptools` to completely adopt
distutils, so in some sense all distutils bugs are setuptools bugs as well.
That said, the reason to report it in setuptools as well is that setuptools
still supports Python 2.7, 3.
Change by Paul Ganssle :
--
pull_requests: +11790
___
Python tracker
<https://bugs.python.org/issue32417>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Paul Ganssle :
--
pull_requests: +11794
___
Python tracker
<https://bugs.python.org/issue35364>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Paul Ganssle :
--
pull_requests: +11790, 11791, 11792
___
Python tracker
<https://bugs.python.org/issue32417>
___
___
Python-bugs-list mailin
Change by Paul Ganssle :
--
pull_requests: +11790, 11791
___
Python tracker
<https://bugs.python.org/issue32417>
___
___
Python-bugs-list mailing list
Unsub
Change by Paul Ganssle :
--
pull_requests: +11794, 11795
___
Python tracker
<https://bugs.python.org/issue35364>
___
___
Python-bugs-list mailing list
Unsub
Change by Paul Ganssle :
--
pull_requests: +11790, 11791, 11792, 11793
___
Python tracker
<https://bugs.python.org/issue32417>
___
___
Python-bugs-list mailin
Paul Ganssle added the comment:
Hm, when I made the "What's new" issue, it added the same PR to the "Pull
requests" 4 times instead of once, and in the history it seems like it *tried*
to actually add PR 11790, 11791, 11792 and 11793 (only the first one exists at
Paul Ganssle added the comment:
Ah, sorry for the noise, this is a known issue:
https://github.com/python/bugs.python.org/issues/12
--
___
Python tracker
<https://bugs.python.org/issue32
Change by Paul Ganssle :
--
nosy: +p-ganssle
___
Python tracker
<https://bugs.python.org/issue35943>
___
___
Python-bugs-list mailing list
Unsubscribe:
Paul Ganssle added the comment:
This issue and bpo-32417 can be closed now, as they are fixed on master.
--
versions: +Python 3.8 -Python 3.6, Python 3.7
___
Python tracker
<https://bugs.python.org/issue35
New submission from Paul Ganssle :
Just noticed this (tested on Python 3.7 and 3.8):
mkdir /tmp/demo
cd /tmp/demo
cat << EOF > abc.py
raise Exception("Hi")
EOF
PYTHONPATH=: python -c ""
This will crash the interpreter with:
Fatal P
Paul Ganssle added the comment:
Tested with 3.6 and 2.7 - core dump on 3.6, no core dump on 2.7. The crash on
2.7 goes through a different path, it goes site.py > os.py >= UserDict.py >
_abcoll.py > abc.py. That may account for why it's not crashing the in
Paul Ganssle added the comment:
@Karthikeyan I would certainly consider this a duplicate of the encodings
bug/behavior that you demonstrate. I don't see an existing bug on the tracker
for it, though.
I think it's pretty clear that the interpreter needs to fail, but it seems
Paul Ganssle added the comment:
> One enhancement of this new API is that it now reports the name of the C
> function which causes the error. The initial bug report says "Fatal Python
> error: init_sys_streams: can't initialize sys standard
streams": init_sys_strea
Paul Ganssle added the comment:
> @Guido, I recall a while back you explained the value of adding CWD to
> sys.path. Would you mind providing some insight here
I think bpo-35971 or bpo-13475 are better places to discuss that, because this
issue doesn't require CWD to be in th
Change by Paul Ganssle :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
Change by Paul Ganssle :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
New submission from Paul Ganssle :
Datetime has many methods that "serializes" an instance to some other format -
toordinal, timestamp, isoformat, etc. Most methods that "serialize" a datetime
have a corresponding method that "deserializes" that method,
Change by Paul Ganssle :
--
keywords: +patch
pull_requests: +11918
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue36004>
___
___
Py
Paul Ganssle added the comment:
I have a first-pass PR, a few questions to address:
1. Should it take three arguments or a single 3-tuple? (I've gone with 3
arguments)
2. Since all three arguments are required, should we make them positional-only?
3. Should we allow time components i
Paul Ganssle added the comment:
The attached PR is more or less fully ready, I think the correct answers to 1,
3 and 4 are that we should go with 3 separate arguments and we should not allow
either time components or tz components, at least in this version.
In the future, I don't thi
New submission from Paul Ganssle :
The PyO3 test suite has been breaking since the alpha release of Python 3.8
because PyDateTimeAPI->Date_FromTimeStamp has had a breaking change in its API:
https://github.com/PyO3/pyo3/issues/352
I believe this happened when `datetime.date.fromtimest
Change by Paul Ganssle :
--
keywords: +patch
pull_requests: +11947
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue36025>
___
___
Py
Paul Ganssle added the comment:
I've put *a* fix in there by introducing a new wrapper function. Ideally we
would just point the C API at the argument clinic-generated function, but
because it takes a single positional argument the argument clinic outputs a
METH_O function inste
Change by Paul Ganssle :
--
resolution: -> fixed
___
Python tracker
<https://bugs.python.org/issue35186>
___
___
Python-bugs-list mailing list
Unsubscrib
Change by Paul Ganssle :
--
versions: -Python 3.6, Python 3.7
___
Python tracker
<https://bugs.python.org/issue35186>
___
___
Python-bugs-list mailing list
Unsub
Change by Paul Ganssle :
--
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue35186>
___
___
Pyth
Paul Ganssle added the comment:
I think I'm -1 on a general project or policy to replace all for-append loops
with list comprehensions, but I'm generally positive about individual
improvements to the code base, on a case-by-case basis.
I can't speak for anyone but myself, but
Change by Paul Ganssle :
--
nosy: +p-ganssle
___
Python tracker
<https://bugs.python.org/issue24643>
___
___
Python-bugs-list mailing list
Unsubscribe:
Paul Ganssle added the comment:
Because what's being printed is a tuple, I think it's not exactly the same as
issue35417, because in fact this is the correct behavior for 2to3, note that in
Python 2:
Python 2.7.15 (default, Jul 21 2018, 11:13:03)
>>> print 1, 2
1 2
&g
201 - 300 of 482 matches
Mail list logo
