Paul Ganssle added the comment:
> 2to3 is designed as a tool to convert a Python 2 code base to Python 3 at
> once. I understand that once the code base is converted, you may want to
> revert some unwanted "useless" changes.
While this problem is likely to show up beca
New submission from Paul Ganssle :
In a recent python-dev thread, there was some confusion about how to get
something like `timedelta.total_microseconds()`. There is already an existing,
supported idiom for this, which is that `timedelta` implements division:
td = timedelta(hours=1
Change by Paul Ganssle :
--
nosy: +p-ganssle
___
Python tracker
<https://bugs.python.org/issue22194>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Paul Ganssle :
--
nosy: +p-ganssle
___
Python tracker
<https://bugs.python.org/issue15237>
___
___
Python-bugs-list mailing list
Unsubscribe:
Paul Ganssle added the comment:
I'm not sure if either of these patches got merged, but at some point this was
fixed:
Python 3.7.2 (default, Feb 9 2019, 13:18:43)
[GCC 8.2.1 20181127] on linux
Type "help", "copyright", "credits" or "lic
Paul Ganssle added the comment:
Oh actually that's my mistake. I can't reproduce the failure in the constructor
in the Python version of the module, and also it seems to be fixed in the pure
Python version as of at least 3.6:
Python 3.6.7 (default, Oct 25 2018, 16:11:17)
Change by Paul Ganssle :
--
nosy: +p-ganssle
___
Python tracker
<https://bugs.python.org/issue36145>
___
___
Python-bugs-list mailing list
Unsubscribe:
Paul Ganssle added the comment:
I also think it would be ideal to avoid getting into too much detail about the
definitions of UTC and GMT in a general sense. Instead, we should probably
refer to some better source on the matter and maybe focus on how UTC and GMT
are used *in this document
Paul Ganssle added the comment:
It does seem like the values CLOCKS_PER_SEC, _PyTime_MAX and SEC_TO_NS are all
defined at compile-time, so presumably this can be a compile-time error.
As currently defined, though, it seems very unlikely that this would ever be
false, since _PyTime_MAX is
Paul Ganssle added the comment:
Sorry, I should say unlikely that it should ever be *true*. It seems unlikely
that there is a platform or piece of hardware on which this error would be
raised.
--
___
Python tracker
<https://bugs.python.
Paul Ganssle added the comment:
I think the proposed change to the test will work, or we can mark the test as
an expected failure on Android (on the theory that the test *should* work
because we want the behavior normalized, but we are not living up to that).
In either case, I think a
Paul Ganssle added the comment:
> No please, don't do that :-(
Interesting, I don't feel terribly strongly about it, but I would have thought
that you'd be more in favor of that solution, maybe we have a different
definition of "expected failure"?
Usually in m
Paul Ganssle added the comment:
>From the documentation (
>https://docs.python.org/3/library/datetime.html#datetime.datetime.fromtimestamp
> ):
> fromtimestamp() may raise OverflowError, if the timestamp is out of the range
> of values supported by the platform C localt
Paul Ganssle added the comment:
Can we change the title of this to something like, "Add example of
platform-specific support for negative timestamps to the time documentation"?
That might be a bit wordy, but as it is now, this looks like it's reporting a
bug in dateutil, which
Paul Ganssle added the comment:
@tin utcnow is a semi-deprecated way to get a naive datetime that represents
the time in UTC. The preferred replacement is to do this:
from datetime import datetime, timezone
datetime.now(tz=timezone.utc)
Note that you can replace "timezone.utc&
Paul Ganssle added the comment:
I would say that the natural output of mktime is indeed an integer, but I can't
say off the top of my head what "compatibility" refers to here, so per the
principle of Chesterton's fence, without more research or historical context
I'
Change by Paul Ganssle :
--
nosy: +p-ganssle
___
Python tracker
<https://bugs.python.org/issue33632>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Paul Ganssle :
When reviewing PR 12020 fixing an infinite loop in the e-mail module, I noticed
that a *different* infinite loop is documented with a "# XXX" comment on line
2724:
https://github.com/python/cpython/blob/58721a903074d28151d008d8990c98fc31d1e798
Change by Paul Ganssle :
--
keywords: +patch
pull_requests: +12655
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue36564>
___
___
Py
Paul Ganssle added the comment:
@Alex LordThorsen: It will accept EST if EST is one of your "local" time zones,
so whatever's in `time.tzname`.
In the short term, I think the right thing to do would be to update the
documentation to remove the reference to "EST", an
Paul Ganssle added the comment:
To clarify, as far as I know, this note *does* apply to both strftime and
strptime, as CPython doesn't have its own implementation of either. I'm not
sure if any guarantees are made that the supported formatting codes will be the
same betwe
Change by Paul Ganssle :
--
nosy: +p-ganssle
___
Python tracker
<https://bugs.python.org/issue22454>
___
___
Python-bugs-list mailing list
Unsubscribe:
Paul Ganssle added the comment:
> Is the behaviour you're proposing any different from using Path.rglob('*')?
I believe `rglob("*")` is eager, while `iterdir` is lazy.
@Epic_Wink:
> This would be trivial to implement as 'iterdir' can simply yield from
Paul Ganssle added the comment:
> rglob and glob also return a generator.
My mistake, I didn't notice the `sorted` in the `rglob` documentation and
thought it was emitting a list.
> By that logic, we should remove `Path.iterdir()` in favour of
> `Path.glob('*')`.
Paul Ganssle added the comment:
I am pretty neutral on this. I don't think it will be terribly difficult to
implement or maintain this, and while there are a few possible behaviors, if
you think about it for a bit, addition with overflow behavior *does* seem like
the natural w
Paul Ganssle added the comment:
> I don't spend enough time dealing with symlinks to have strong opinions
> there, but given we have ways to resolve symlinks but not to get back to the
> original name (and I *have* had to deal with issues where I've needed to find
>
Paul Ganssle added the comment:
> In short, a+b can overflow, but a-b cannot?
I think it's more that by always checking the elapsed time against `now() -
starttime`, you never need to represent the time at which the timeout should
happen - which may be so far in the future that it
Paul Ganssle added the comment:
I have edited the title to be a bit more and give more context. Donald, if you
feel I have misrepresented your issue, please feel free to tweak it further.
--
nosy: +p-ganssle
title: Minor inconsistancy with types. -> Reversing large ranges results
Paul Ganssle added the comment:
I believe the relevant code is here:
https://github.com/python/cpython/blob/bb86bf4c4eaa30b1f5192dab9f389ce0bb61114d/Objects/rangeobject.c#L1038
It looks like it's a performance enhancement and that for ranges where the
beginning and end can fit in a C
Change by Paul Ganssle :
--
pull_requests: +12905
___
Python tracker
<https://bugs.python.org/issue36722>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Paul Ganssle :
A decent fraction of the datetime C API has no tests. If we had tests, we could
have prevented bpo #36025, which was a regression in the FromTimestamp method.
I would like to open this issue to suggest the addition of tests for the full
interface, to
New submission from Paul Ganssle :
In Python 3.6, Time_FromTimeAndFold and PyDateTime_FromDateAndTimeAndFold were
added as part of the PEP 495 implementation, but no documentation was added for
the C API portions of this change:
https://docs.python.org/3.7/c-api/datetime.html
The functions
Change by Paul Ganssle :
--
nosy: +Mariatta, cheryl.sabella
___
Python tracker
<https://bugs.python.org/issue36783>
___
___
Python-bugs-list mailing list
Unsub
Paul Ganssle added the comment:
This ticket should be reserved for the mentored sprint.
--
assignee: -> Mariatta
nosy: +Mariatta
___
Python tracker
<https://bugs.python.org/issu
Paul Ganssle added the comment:
This ticket should be reserved for the mentored sprint.
--
assignee: docs@python -> Mariatta
___
Python tracker
<https://bugs.python.org/issu
Change by Paul Ganssle :
--
nosy: +p-ganssle
___
Python tracker
<https://bugs.python.org/issue36797>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Paul Ganssle :
This is a child issue for bpo 36782, specifically for testing the macro-only
datetime C API functions
Untested macros with no corresponding API module:
- PyDateTime_GET_YEAR
- PyDateTime_GET_MONTH
- PyDateTime_GET_DAY
- PyDateTime_DATE_GET_HOUR
Change by Paul Ganssle :
--
nosy: +fdrake
___
Python tracker
<https://bugs.python.org/issue35723>
___
___
Python-bugs-list mailing list
Unsubscribe:
Paul Ganssle added the comment:
> This sounds like a bug. Whether a tzinfo is a constant from a predefined set
> or something with a smart comparison semantic is none of datetime's business.
I'm not sure what you mean, but it was not a "bug" in the sense that it
Paul Ganssle added the comment:
@Stéphane The reason this issue was closed before PR 13204 was merged is that
PR 13147 was merged a bit prematurely due to a miscommunication, which is why
Cheryl closed the issue. I was going to re-open it after we realized what
happened, but since we were at
Change by Paul Ganssle :
--
nosy: +maxking, msapiro
___
Python tracker
<https://bugs.python.org/issue36564>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Paul Ganssle :
--
pull_requests: +5163
stage: resolved -> patch review
___
Python tracker
<https://bugs.python.org/issue10381>
___
___
Python-bugs-lis
Change by Paul Ganssle :
--
pull_requests: +5164
___
Python tracker
<https://bugs.python.org/issue10381>
___
___
Python-bugs-list mailing list
Unsubscribe:
Paul Ganssle added the comment:
I'm not sure if this warrants a separate issue, but I also notice this in the
documentation:
> If the package cannot be located or loaded, or it uses a loader which does
> not support get_data, then None is returned. In particular, the loader for
Change by Paul Ganssle :
--
pull_requests: +5380, 5381
___
Python tracker
<https://bugs.python.org/issue15873>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Paul Ganssle :
--
pull_requests: +5380
___
Python tracker
<https://bugs.python.org/issue15873>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Paul Ganssle :
--
pull_requests: +5589
___
Python tracker
<https://bugs.python.org/issue32403>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Paul Ganssle :
--
pull_requests: +5588
___
Python tracker
<https://bugs.python.org/issue10381>
___
___
Python-bugs-list mailing list
Unsubscribe:
Paul Ganssle added the comment:
adamwill: I think datetime's strftime is a wrapper around the system strftime,
so it varies between platforms. Might be useful to specify which platform you
are seeing this behavior on.
--
nosy: +p-ga
Paul Ganssle added the comment:
It seems that %s is not supported and the fact that it works at all is
incidental. See issue 12750 and this SO thread:
https://stackoverflow.com/questions/11743019/convert-python-datetime-to-epoch-with-strftime
Paul Ganssle added the comment:
I suspect discussion should be centralized in issue 12750, but if it were up to
me %s would either work as expected or throw an error. Silently giving the
wrong answer is a terrible compromise.
--
___
Python tracker
New submission from Paul Ganssle :
This is basically the same as issue 962772, as there seems to have been a
regression. The current version of distutils discards author= metadata if
maintainer= is present, even though PEP 345 has added the Maintainer: and
Maintainer-Email: metadata fields
New submission from Paul Ganssle :
I've been asked to post this by @brainwave (who is having some trouble getting
an account on bpo due to technical difficulties).
Per twine's github issue 311 ( https://github.com/pypa/twine/issues/311 ), it
seems that distutil's docs Update
Change by Paul Ganssle :
--
keywords: +patch
pull_requests: +5869
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue33069>
___
___
Py
Paul Ganssle added the comment:
@ncoghlan Yes, setuptools is affected. I've reported it there as well:
https://github.com/pypa/setuptools/issues/1288
I have patches for both distutils and setuptools prepared. The distutils patch
is more controversial because this is apparently the docum
Paul Ganssle added the comment:
One thing that's unclear to me is whether PKG-INFO metadata spec should be
considered exhaustive or whether you can add additional fields and still be
considered compliant with the spec. If the latter is true, I think there's some
case to b
Paul Ganssle added the comment:
I've fixed this in setuptools ( PR here:
https://github.com/pypa/setuptools/pull/1294 ).
Should we leave this open to track distutils upgrading to support all of PEP
345, or close this with "distutils will never support > 1.1". If the l
Paul Ganssle added the comment:
> Donald made an interesting suggestion over on
> https://github.com/pypa/packaging-problems/issues/127#issuecomment-374401331,
> which was to have distutils stop overwriting the Author metadata with the
> Maintainer metadata when both are s
Change by Paul Ganssle :
--
versions: +Python 3.8
___
Python tracker
<https://bugs.python.org/issue28602>
___
___
Python-bugs-list mailing list
Unsubscribe:
Paul Ganssle added the comment:
ISO 8601 does not require an offset (in fact, most portions of the ISO 8601
date and time are optional - ISO 8601 is more complicated than most people
think). Without an offset a datetime is assumed to be local time.
The T delimiter is required, but can be
Paul Ganssle added the comment:
I don't really agree with these changes to the documentation.
The format that paulc identifies is actually an RFC 3339 datetime, which is a
subset of ISO 8601, to the extent that you consider the fact that "we're using
RFC 3339" is
Change by Paul Ganssle :
--
keywords: +patch
pull_requests: +4145
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue31222>
___
___
Py
Paul Ganssle added the comment:
Some time ago this was fixed in pypy3:
https://bitbucket.org/pypy/pypy/issues/2635/datetimereplace-always-returns
I made a PR fixing this for `datetime`, `date` and `time`.
--
___
Python tracker
<ht
New submission from Paul Ganssle :
The TestCase.assertRaises and TestCase.subTest macros apparently don't interact
with each other well. To demonstrate, consider the following code:
from unittest import TestCase
class SubTestRaisesTest(TestCase):
def test_assert_outer
Paul Ganssle added the comment:
@r.david.murray So it is, my mistake. I think I was conflating issues when this
first came up, and then I didn't notice that the order the test cases printed
in was different than I expected.
--
stage: -> resolved
status: open -
Change by Paul Ganssle :
--
pull_requests: +4611
___
Python tracker
<https://bugs.python.org/issue15873>
___
___
Python-bugs-list mailing list
Unsubscribe:
Paul Ganssle added the comment:
> The better is the enemy of the good here. Given the history of this issue, I
> would rather accept a well documented restrictive parser than wait for a more
> general code to be written. Note that we can always relax the parsing rules
> i
Paul Ganssle added the comment:
> The other difference is Mattieu guarantees ValueError for invalid input
> strings, which I think is good.
I forgot to address this - but I don't think this is a difference in
approaches. If you pass `None` or an int or something, the problem
Change by Paul Ganssle :
--
pull_requests: +4721
___
Python tracker
<https://bugs.python.org/issue5288>
___
___
Python-bugs-list mailing list
Unsubscribe:
Paul Ganssle added the comment:
@martin.panter I don't see the problem here? Wouldn't 23:59.995 round up to
00:00?
--
___
Python tracker
<https://bugs.python.o
Paul Ganssle added the comment:
> Not if the time is associated with a particular day. Imagine implementing
> datetime.fromisoformat by separately calling date.fromisoformat and
> time.fromisoformat. The date will be off by one day if you naively rounded
> 2017-12-18 23:59 “up” t
New submission from Paul Ganssle :
In the addition of the `fromisoformat()` alternate constructor (bpo-15873:
https://github.com/python/cpython/pull/4699), I noted that I was able to get
some significant speedup by special-casing the `datetime` baseclass in the C
code so that it bypasses the
New submission from Paul Ganssle :
In writing some tests for the alternate date constructors as part of my PR for
issue 32403 (https://bugs.python.org/issue32403), I noticed that for
`datetime`, the `fromtimestamp` bypasses the `__new__` call on the subclass:
from datetime import datetime
New submission from Paul Ganssle :
When preparing some tests for how subclasses of date and datetime react as part
of a fix for issue 32403, I noticed a fairly big example of where subclass is
not preserved - `tzinfo.fromutc`:
from datetime import datetime, timezone
class
Paul Ganssle added the comment:
I've noticed that there's another complicating factor here, which is that
addition of `timedelta` does not respect subclasses either, which means that
third party libraries implementing fromutc (as was recommended in issue 28602),
who will likely m
Change by Paul Ganssle :
--
keywords: +patch
pull_requests: +4881
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue32403>
___
___
Py
Change by Paul Ganssle :
--
keywords: +patch
pull_requests: +4882
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue32404>
___
___
Py
Change by Paul Ganssle :
--
nosy: +p-ganssle
___
Python tracker
<https://bugs.python.org/issue10381>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Paul Ganssle :
--
keywords: +patch
pull_requests: +4919
stage: needs patch -> patch review
___
Python tracker
<https://bugs.python.org/issu
Paul Ganssle added the comment:
> I mean dropping `.copy()` breaks not only compatibility between pure python
> versions but also between pypy releases and pypy/CPython code.
That's why I suggest to keep `.copy()` as an alias for `__copy__()`.
If the main issue is that pypy user
Paul Ganssle added the comment:
@Andrew Are you suggesting that a `copy` method be *added* to the C
implementation, as an alias to __copy__? Because it makes no sense to keep the
pure Python and C implementations out of sync just so that it's easier for
projects forking the pure P
Paul Ganssle added the comment:
> There is no "fork" involved in other projects using it, from our point of
> view.
I did not mean "fork" in some judgmental sense, I'm mostly just familiar with
pypy, but I was under the impression that other projects were *l
Paul Ganssle added the comment:
@Nick
I'm certainly fine with re-configuring my PR to center around a new capsule
module with deprecation of the old C API (though if you have any examples of
what you have in mind that would be helpful to me). Certainly the "C global
needs to be
Paul Ganssle added the comment:
This is essentially what the `tzinfos` argument to `dateutil.parser.parse`
does. I do think something *like* this is the only reasonable way to handle
%Z->tzinfo mappings.
In `dateutil`
(https://dateutil.readthedocs.io/en/latest/parser.h
Paul Ganssle added the comment:
By the way, one possibly significant problem with this interface is that it
would tend to encourage the use of static timezone offsets rather than rule
sets as intended by `tzinfo`. The main problem is that a simple mapping between
tzname and tzinfo (whether
Paul Ganssle added the comment:
Sorry, forgot to include the link to the dateutil implementation of the
fold-resolution code: https://github.com/dateutil/dateutil/pull/517/files
--
___
Python tracker
<https://bugs.python.org/issue32
Change by Paul Ganssle :
--
pull_requests: +4974
___
Python tracker
<https://bugs.python.org/issue30541>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Paul Ganssle :
One thing I think that is fairly common is the desire to get the current
datetime only up to a current precision, so you see a lot of things in, say,
`dateutil` like this:
dt = datetime.now().replace(hours=0, minutes=0, seconds=0, microseconds=0)
Or
Paul Ganssle added the comment:
An alternate possibility here might be to implement either `__round__` or a
`round` function in `datetime` (which would basically automatically add this
precision functionality to *all* the constructors, not just now). An example
implementation:
from datetime
Paul Ganssle added the comment:
@Victor: With regards to getting a "date as datetime", that is another way to
do it that I have also done in the past (and in fact it's how the new
dateutil.utils.today() function is implemented:
https://github.com/dateutil/dateutil/blob/
Change by Paul Ganssle :
--
type: -> enhancement
___
Python tracker
<https://bugs.python.org/issue32522>
___
___
Python-bugs-list mailing list
Unsubscrib
Paul Ganssle added the comment:
@Barry I don't think it's a good idea to duplicate the `replace` functionality
in `datetime` like that. I think the main problem isn't the `.replace`, it's
the fact that you have to specify exactly which components you want to set to
Paul Ganssle added the comment:
I think if we're going to use `timedelta` then `__mod__` is the more
appropriate option here, since it would be hard to interpret what `round(dt,
timedelta(hours=2, microseconds=31))` would do.
Either __mod__ or __round__ with `timedelta` is a bit of a st
Paul Ganssle added the comment:
One thing to note, the "example implementation" of __round__ above is an actual
working prototype*:
>>> round(Datetime.now(), 'second')
Datetime(2018, 1, 9, 11, 59, 35)
>>> round(Datetime.now(), 'day')
Da
Paul Ganssle added the comment:
> In my experience, when dealing with temporal data truncation (rounding
> towards -infinity) is more useful than any other form of rounding. See also
> issue 19475.
Ah, I agree - if you see that's how my __round__ implementation works. I guess
Paul Ganssle added the comment:
> Looking at the dateutil, I don't see a truncate to rrule function. Maybe a
> good starting point would be to implement that in dateutil and if some
> simpler pattern emerges that can be proposed for stdlib, we can discuss it
> then
Paul Ganssle added the comment:
> This can be accomplished rather efficiently by truncating a time tuple:
This will not preserve tzinfo, and (though this is not a concern unless
nanosecond precision is added), I don't believe it preserves microseconds
either.
That said, it's
Paul Ganssle added the comment:
> Still, this feature is not appealing enough to try to squeeze into 3.7
> release schedule. I think this should go through a round of discussion
> either on datetime-sig or python-ideas.
Agreed. I will put together some summary in the next week
Paul Ganssle added the comment:
I think this is more a matter of misunderstanding the fact that ISO 8601 is a
larger and more complicated spec than people think. You'll note that the
original complaint also seems to think that a timezone is required (it is not).
You can find a copy o
Paul Ganssle added the comment:
Ah, actually, my mistake, RFC 3339 most assuredly *does* require a UTC offset:
4.4. Unqualified Local Time
A number of devices currently connected to the Internet run their
internal clocks in local time and are unaware of UTC. While the
Internet
301 - 400 of 482 matches
Mail list logo
