On 13/02/20 9:17 AM, Michael Torrie wrote:
On 2/12/20 7:44 AM, Ethan Furman wrote:
On 02/11/2020 04:38 PM, Michael Torrie wrote:
...
True. Costs can be calculated and planned for. But Technical debt is
often impossible to quantify in a real, meaningful, business sense,
other than the that
On 2/12/20 7:44 AM, Ethan Furman wrote:
> On 02/11/2020 04:38 PM, Michael Torrie wrote:
>
>> It's all just different ways of accounting for the same things. In
>> the olden days before the term "technical debt" was invented, we
>> called this "total cost of ownership."
>
> TCO is not a fixed
On 12/02/2020 17:46, Python wrote:
On Wed, Feb 12, 2020 at 01:16:03PM +, Rhodri James wrote:
On 12/02/2020 00:53, Python wrote:
In pretty much every job I've ever worked at, funding work (e.g. with
humans to do it) with exactly and precisely the resources required is
basically impossible,
On Wed, Feb 12, 2020 at 01:16:03PM +, Rhodri James wrote:
> On 12/02/2020 00:53, Python wrote:
> > In pretty much every job I've ever worked at, funding work (e.g. with
> > humans to do it) with exactly and precisely the resources required is
> > basically impossible, and management prefers to
: Technical debt - was Re: datetime seems to be broken WRT
timezones (even when you add them)
On 12/02/2020 00:53, Python wrote:
> In pretty much every job I've ever worked at, funding work (e.g. with
> humans to do it) with exactly and precisely the resources required is
> basically i
On 02/11/2020 04:38 PM, Michael Torrie wrote:
It's all just different ways of accounting for the same things. In the
olden days before the term "technical debt" was invented, we called this
"total cost of ownership."
TCO is not a fixed number. For example, if a loan is taken to help fund a
On 12/02/2020 00:53, Python wrote:
In pretty much every job I've ever worked at, funding work (e.g. with
humans to do it) with exactly and precisely the resources required is
basically impossible, and management prefers to underfund the work
than to overfund it, for cost-savings reasons. This
On 2020-02-12, Chris Angelico wrote:
> But you CAN rewrite code such that it reduces technical debt. You can
> refactor code to make it more logical.
... but if doing so costs more than the debt, you shouldn't do it.
--
https://mail.python.org/mailman/listinfo/python-list
On Wed, Feb 12, 2020 at 12:32 PM Michael Torrie wrote:
>
> On 2/11/20 6:15 PM, Chris Angelico wrote:
> > On Wed, Feb 12, 2020 at 12:13 PM Michael Torrie wrote:
> >>
> >> On 2/11/20 5:55 PM, Chris Angelico wrote:
> >>> But you CAN rewrite code such that it reduces technical debt. You can
> >>>
On 2/11/20 6:15 PM, Chris Angelico wrote:
> On Wed, Feb 12, 2020 at 12:13 PM Michael Torrie wrote:
>>
>> On 2/11/20 5:55 PM, Chris Angelico wrote:
>>> But you CAN rewrite code such that it reduces technical debt. You can
>>> refactor code to make it more logical. You can update things to use
>>>
On 2/11/20 5:53 PM, Python wrote:
> If your hypothetical project was implemented perfectly from the
> beginning, in Python2.x, it may never need updating, and therefore
> there may well never be any reason to port it to python3. So doing so
> would be neither "debt" nor "cost" but rather "waste."
On Wed, Feb 12, 2020 at 12:13 PM Michael Torrie wrote:
>
> On 2/11/20 5:55 PM, Chris Angelico wrote:
> > But you CAN rewrite code such that it reduces technical debt. You can
> > refactor code to make it more logical. You can update things to use
> > idioms that better express the concepts you're
On 2/11/20 5:55 PM, Chris Angelico wrote:
> But you CAN rewrite code such that it reduces technical debt. You can
> refactor code to make it more logical. You can update things to use
> idioms that better express the concepts you're trying to represent
> (maybe because those idioms require
On Wed, Feb 12, 2020 at 12:00 PM Michael Torrie wrote:
>
> On 2/11/20 5:42 PM, Chris Angelico wrote:
> > Yes, if you consider the term to be synonymous with TCO, then
> > naturally you'll see it as useless. But it isn't. Technical debt is a
> > very specific thing and it CAN be paid off.
>
>
On 2/11/2020 3:09 PM, Chris Angelico wrote:
What you're talking about is costs in general, but "debt" is a very
specific term. You accrue technical debt whenever you "borrow" time
from the future - doing something that's less effort now at the
expense of being worse in the future.
A prime
On Wed, Feb 12, 2020 at 11:48 AM Michael Torrie wrote:
>
> On 2/11/20 5:37 PM, Chris Angelico wrote:
> > On Wed, Feb 12, 2020 at 11:32 AM Michael Torrie wrote:
> >>
> >> On 2/11/20 2:25 PM, Barry Scott wrote:
> >>> At Chris said moving to python3 will *reduce* your technical debt.
> >>> You are
On 2/11/20 5:42 PM, Chris Angelico wrote:
> Yes, if you consider the term to be synonymous with TCO, then
> naturally you'll see it as useless. But it isn't. Technical debt is a
> very specific thing and it CAN be paid off.
We'll agree to disagree on the last bit. And I'm not the only one that
On Wed, Feb 12, 2020 at 07:09:12AM +1100, Chris Angelico wrote:
> On Wed, Feb 12, 2020 at 7:03 AM Michael Torrie wrote:
> > Speaking about technical debt is certainly fashionable these days. As
> > if we've somehow discovered a brand new way of looking at things. But
> > it doesn't matter what
On 2/11/20 5:37 PM, Chris Angelico wrote:
> On Wed, Feb 12, 2020 at 11:32 AM Michael Torrie wrote:
>>
>> On 2/11/20 2:25 PM, Barry Scott wrote:
>>> At Chris said moving to python3 will *reduce* your technical debt.
>>> You are paying off the debt.
>>
>> While at the same time incurring new debt.
On Wed, Feb 12, 2020 at 11:39 AM Michael Torrie wrote:
>
> On 2/11/20 1:09 PM, Chris Angelico wrote:
> > What you're talking about is costs in general, but "debt" is a very
> > specific term. You accrue technical debt whenever you "borrow" time
> > from the future - doing something that's less
On 2/11/20 1:09 PM, Chris Angelico wrote:
> What you're talking about is costs in general, but "debt" is a very
> specific term. You accrue technical debt whenever you "borrow" time
> from the future - doing something that's less effort now at the
> expense of being worse in the future. You pay
On Wed, Feb 12, 2020 at 11:32 AM Michael Torrie wrote:
>
> On 2/11/20 2:25 PM, Barry Scott wrote:
> > At Chris said moving to python3 will *reduce* your technical debt.
> > You are paying off the debt.
>
> While at the same time incurring new debt.
That's not an intrinsic part of the rewrite,
On 2/11/20 2:25 PM, Barry Scott wrote:
> At Chris said moving to python3 will *reduce* your technical debt.
> You are paying off the debt.
While at the same time incurring new debt.
> Not to mention that its harder to hire people to work on tech-debt legacy
> code.
>
> Given the choice between
> On 11 Feb 2020, at 20:01, Michael Torrie wrote:
>
> On 2/11/20 4:05 AM, Chris Angelico wrote:
>> Or just the recognition that, eventually, technical debt has to be
>> paid.
>
> Speaking about technical debt is certainly fashionable these days. As
> if we've somehow discovered a brand new
> On 10 Feb 2020, at 23:01, Python wrote:
>
> As best I can tell, Python has no means to make use of the system's
> timezone info. In order to make datetime "timezone aware", you need
> to manually create a subclass of datetime.tzinfo, whose methods return
> the correct values for the
On Wed, Feb 12, 2020 at 7:03 AM Michael Torrie wrote:
>
> On 2/11/20 4:05 AM, Chris Angelico wrote:
> > Or just the recognition that, eventually, technical debt has to be
> > paid.
>
> Speaking about technical debt is certainly fashionable these days. As
> if we've somehow discovered a brand new
On Wed, Feb 12, 2020 at 6:45 AM Python wrote:
>
> On Wed, Feb 12, 2020 at 05:38:38AM +1100, Chris Angelico wrote:
> > > > Isn't it time to stop going to great effort to support Python
> > >
> > > If you live in a world where you get to decide that, sure. Not
> > > everyone does.
> > >
> >
> >
On 2/11/20 4:05 AM, Chris Angelico wrote:
> Or just the recognition that, eventually, technical debt has to be
> paid.
Speaking about technical debt is certainly fashionable these days. As
if we've somehow discovered a brand new way of looking at things. But
it doesn't matter what you do,
On Wed, Feb 12, 2020 at 05:38:38AM +1100, Chris Angelico wrote:
> > > Isn't it time to stop going to great effort to support Python
> >
> > If you live in a world where you get to decide that, sure. Not
> > everyone does.
> >
>
> Everyone gets to decide how much time and effort they put into
>
On Wed, Feb 12, 2020 at 3:57 AM Python wrote:
>
> On Tue, Feb 11, 2020 at 12:42:26PM +1100, Chris Angelico wrote:
> > > > I've been using the timestamp() method:
> > >
> > > That's the key piece of info. This does appear to work, though still
> > > not on python2. That, as you say, is my
On Tue, Feb 11, 2020 at 12:42:26PM +1100, Chris Angelico wrote:
> > > I've been using the timestamp() method:
> >
> > That's the key piece of info. This does appear to work, though still
> > not on python2. That, as you say, is my problem. But thankfully Jon
> > Ribbens has the save:
>
> Isn't
On 2020-02-11, Chris Angelico wrote:
> On Tue, Feb 11, 2020 at 10:01 PM Jon Ribbens via Python-list
> wrote:
>> So while it's been about 6 years since anyone should have been
>> starting any new projects using Python 2, there are plenty of
>> projects that are older than that and still need
On Tue, Feb 11, 2020 at 10:01 PM Jon Ribbens via Python-list
wrote:
>
> On 2020-02-11, Chris Angelico wrote:
> >> That's the key piece of info. This does appear to work, though still
> >> not on python2. That, as you say, is my problem. But thankfully Jon
> >> Ribbens has the save:
> >
> >
On 2020-02-11, Chris Angelico wrote:
>> That's the key piece of info. This does appear to work, though still
>> not on python2. That, as you say, is my problem. But thankfully Jon
>> Ribbens has the save:
>
> Isn't it time to stop going to great effort to support Python 2?
That depends on
On Tue, Feb 11, 2020 at 12:31 PM Python wrote:
>
> On Tue, Feb 11, 2020 at 11:33:54AM +1100, Chris Angelico wrote:
> > [...] instead of using the undocumented and unsupported strftime %s
> > format code
>
> I'm not sure this characterization is accurate... the docs (for both
> Python 2 and 3)
On Tue, Feb 11, 2020 at 11:33:54AM +1100, Chris Angelico wrote:
> [...] instead of using the undocumented and unsupported strftime %s
> format code
I'm not sure this characterization is accurate... the docs (for both
Python 2 and 3) say:
The full set of format codes supported varies across
On 2020-02-10, Python wrote:
> So far, so good. However, when you go to use this object, the time it
> represents is in fact wrong.
Unsurprisingly for a language feature that's been around for nearly
17 years, no it isn't.
> For example:
>
print dt.strftime("%s")
> 1580452245
That's
On Tue, Feb 11, 2020 at 11:17 AM Python wrote:
>
> On Tue, Feb 11, 2020 at 11:04:28AM +1100, Chris Angelico wrote:
> > On Tue, Feb 11, 2020 at 10:42 AM Python wrote:
> > > Now, you can instantiate a datetime.datetime object with the times you
> > > want, and pass an instance of this class as the
On Tue, Feb 11, 2020 at 11:04:28AM +1100, Chris Angelico wrote:
> On Tue, Feb 11, 2020 at 10:42 AM Python wrote:
> > Now, you can instantiate a datetime.datetime object with the times you
> > want, and pass an instance of this class as the tzinfo argument to the
> > constructor. Also no problem:
On Tue, Feb 11, 2020 at 10:42 AM Python wrote:
>
> As best I can tell, Python has no means to make use of the system's
> timezone info. In order to make datetime "timezone aware", you need
> to manually create a subclass of datetime.tzinfo, whose methods return
> the correct values for the
On Mon, Feb 10, 2020 at 05:52:59PM -0600, Skip Montanaro wrote:
> > As best I can tell, Python has no means to make use of the system's
> > timezone info. In order to make datetime "timezone aware", you need
> > to manually create a subclass of datetime.tzinfo, whose methods return
> > the
> As best I can tell, Python has no means to make use of the system's
> timezone info. In order to make datetime "timezone aware", you need
> to manually create a subclass of datetime.tzinfo, whose methods return
> the correct values for the timezone you care about.
>
...
> Does Python have an
42 matches
Mail list logo
