Re: Documentation of __hash__

[klauck2]

On Friday, February 7, 2020 at 4:30:23 PM UTC+1, Random832 wrote:
> On Fri, Feb 7, 2020, at 10:14, Richard Damon wrote:
> > On 2/6/20 2:13 PM, klau...@gmail.com wrote:
> > > The default __eq__ method (object identity) is compatible with all 
> > > (reasonable) self-defined __hash__ method.
> > >
> > > Stefan
> > 
> > If __eq__ compares just the id, then the only hash you need is the 
> > default that is also the id. If you define a separate hash function, 
> > which uses some of the 'value' of the object, then presumably you intend 
> > for objects where that 'value' matches to be equal, which won't happen 
> > with the default __eq__.
> 
> I think Stefan's point is that, no matter how questionable the intent may 
> sound, any deterministic __hash__ doesn't technically violate the hash/eq 
> relationship with the default __eq__, because hash(x) will still be equal to 
> hash(x). Only defining __eq__ can create the problem where x == y but hash(x) 
> != hash(y).

Yes, this is my question.

> 
> The purpose of this rule is to save you from having to override the default 
> __hash__ with something that will only raise an exception when you do not 
> intend your class to be hashable.

If I do not intend my class to be hashable, I will set __hash__ to None 
(according to the documentation).


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: datetime seems to be broken WRT timezones (even when you add them)

[Jon Ribbens via Python-list]

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 what existing systems people need to support. The main
project I work on pre-dates the existence of Python's 'datetime'
module, let alone Python 3. It still generally uses 1 and 0 for True
and False because True and False didn't exist when we started.

This project will never move to Python 3. It was a happy and momentous
day, fairly recently, when we were able to move to Python 2.7 - albeit
we're basically stuck on Python 2.7.5 (plus random patches from RedHat
making it not-really-2.7.5).

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 supporting,
and often it'd take some pretty huge unavoidable requirement
to motivate a port to Python 3.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: datetime seems to be broken WRT timezones (even when you add them)

[Chris Angelico]

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:
> >
> > Isn't it time to stop going to great effort to support Python 2?
>
> That depends on what existing systems people need to support. The main
> project I work on pre-dates the existence of Python's 'datetime'
> module, let alone Python 3. It still generally uses 1 and 0 for True
> and False because True and False didn't exist when we started.
>
> This project will never move to Python 3. It was a happy and momentous
> day, fairly recently, when we were able to move to Python 2.7 - albeit
> we're basically stuck on Python 2.7.5 (plus random patches from RedHat
> making it not-really-2.7.5).
>
> 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 supporting,
> and often it'd take some pretty huge unavoidable requirement
> to motivate a port to Python 3.

Or just the recognition that, eventually, technical debt has to be
paid. I didn't say that everything has to stop supporting Py2
instantly now that it's 2020, but that it's time to stop going to
great lengths for it. Py2 is a legacy system and has been for a long
time now, and if it takes a lot of effort to keep maintaining it, then
it's time to consider porting to Py3. Just how much work are you going
to do, to avoid the work of porting?

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: braket an matrix in python

[Parisa Ch]

On Monday, February 3, 2020 at 9:46:43 PM UTC+3:30, Peter Otten wrote:
> Parisa Ch wrote:
> 
> > x=np.linspace(0,2*math.pi,n)
> > n=len(x)
> > r=int(math.ceil(f*n))
> > h=[np.sort(np.abs(x-x[i]))[r] for i in range(n)]
> > 
> > this is part of a python code. the last line is confusing? x is a matrix
> > and x[i] is a number. how  calculate x-x[i] for each i?
> >  why the put r in [] ?
> 

thank you so much 
> Brake it appart:
> 
> y = x - x[i]  # the numpy feature that makes that possible is called
>   # "broadcasting"
> 
> subtracts the value x[i] from every entry in the vector x
> 
> z = np.abs(y)
> 
> calculates the absolute value of every entry in y.
> 
> t = np.sort(z)
> 
> sorts the values in z and finally, assuming r is an integer,
> 
> u = t[r]  
> 
> looks up a single scalar in the vector.
> 
> The enclosing "list comprehension" [expr for item in iterable] builds a list 
> of n values calculated as sketched above.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: datetime seems to be broken WRT timezones (even when you add them)

[Jon Ribbens via Python-list]

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 supporting,
>> and often it'd take some pretty huge unavoidable requirement
>> to motivate a port to Python 3.
>
> Or just the recognition that, eventually, technical debt has to be
> paid. I didn't say that everything has to stop supporting Py2
> instantly now that it's 2020, but that it's time to stop going to
> great lengths for it. Py2 is a legacy system and has been for a long
> time now, and if it takes a lot of effort to keep maintaining it, then
> it's time to consider porting to Py3. Just how much work are you going
> to do, to avoid the work of porting?

Not doing something generally doesn't involve any work. Occasionally
there's a very small amount of work when something that would have
been trivial in Python 3 is slightly harder in Python 2 - this thread
for example, where it appears to involve one extra line of code.
-- 
https://mail.python.org/mailman/listinfo/python-list

[RELEASE] Python 3.8.2rc1 is now available for testing

[Łukasz Langa]

Python 3.8.2rc1 is the release candidate of the second maintenance release of 
Python 3.8. Go get it here:

https://www.python.org/downloads/release/python-382rc1/ 


Assuming no critical problems are found prior to 2020-02-17, the scheduled 
release date for 3.8.2 (as well as 3.9.0 alpha 4!), no code changes are planned 
between this release candidate and the final release.
That being said, please keep in mind that this is a pre-release of 3.8.2 and as 
such its main purpose is testing.

Maintenance releases for the 3.8 series will continue at regular bi-monthly 
intervals, with 3.8.3 planned for April 2020 (during sprints at PyCon US).

What’s new?

The Python 3.8 series is the newest feature release of the Python language, and 
it contains many new features and optimizations. See the “What’s New in Python 
3.8 ” document for more 
information about features included in the 3.8 series.

Detailed information about all changes made in version 3.8.2 specifically can 
be found in its change log 
.

We hope you enjoy Python 3.8!

Thanks to all of the many volunteers who help make Python Development and these 
releases possible! Please consider supporting our efforts by volunteering 
yourself or through organization contributions to the Python Software 
Foundation.

https://www.python.org/psf/ 


- Ł
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: datetime seems to be broken WRT timezones (even when you add them)

[Python]

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 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.


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Documentation of __hash__

[Ethan Furman]

On 02/11/2020 02:23 AM, klau...@gmail.com wrote:

On Friday, February 7, 2020 at 4:30:23 PM UTC+1, Random832 wrote:



The purpose of this rule is to save you from having to override the default 
__hash__ with something that will only raise an exception when you do not 
intend your class to be hashable.


If I do not intend my class to be hashable, I will set __hash__ to None 
(according to the documentation).


If you define your own __eq__ method, __hash__ is automatically set to None.

--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list

Re: datetime seems to be broken WRT timezones (even when you add them)

[Chris Angelico]

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 problem.  But thankfully Jon
> > > Ribbens has the save:
> >
> > 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
supporting an old and unsupported system. Are you telling me that
someone is enslaving you and forcing you to continue supporting Python
2, or are you actually saying that it's less effort to keep
maintaining old code than to port to Py3? As I said in the previous
email, I did NOT say that it's time to instantly drop Py2 like a hot
potato. (And if you do nothing, a hot potato just becomes a cold
potato. Thank you, Bernard.)

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: datetime seems to be broken WRT timezones (even when you add them)

[Python]

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
> supporting an old and unsupported system.

Mostly not...  In the real world you typically are beholden to
customers (be they internal or external), and you are beholden to your
bosses (be they the same or different people from the first group).
What you say is true only if you have no customers or bosses to whom
you have obligations, or have sufficient financial freedom or
influence to ignore them and are willing to accept the consequences.

-- 
https://mail.python.org/mailman/listinfo/python-list

Technical debt - was Re: datetime seems to be broken WRT timezones (even when you add them)

[Michael Torrie]

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, there's always real cost, and therefore
always technical debt. Moving to Python 3 incurs technical debt.
Staying with Python 2 incurs technical debt.  Thus I wonder if the term
is actually that useful.

I know what you mean, though.  The cost of staying with Python2 is
increasing rapidly compared to the cost of porting to Python3.  Unlike
the nebulous term, "technical debt," the cost of staying with Python2 vs
porting to Python3 can be quantified in real dollar amounts.  I've no
doubt that the calculus is in favor of Python2 a while longer for many
people.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: datetime seems to be broken WRT timezones (even when you add them)

[Chris Angelico]

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.
> > >
> >
> > Everyone gets to decide how much time and effort they put into
> > supporting an old and unsupported system.
>
> Mostly not...  In the real world you typically are beholden to
> customers (be they internal or external), and you are beholden to your
> bosses (be they the same or different people from the first group).
> What you say is true only if you have no customers or bosses to whom
> you have obligations, or have sufficient financial freedom or
> influence to ignore them and are willing to accept the consequences.
>

Is your boss/client smart enough to understand the concept of putting
in effort now to pay off significant dividends later?

Does your boss/client recognize that using software that isn't getting
security patches means you're vulnerable?

Actually, does your boss/client even care what your chosen language
is? Certainly in the case of clients or customers, it's extremely
common for them to have expectations in terms of "make it work", not
"keep it running on Python 2".

So long as it's fairly easy to keep it going on Py2, sure, keep it
going on Py2. But if it's going to be a lot of effort - and,
increasingly, it will - then you need to be willing to take the
non-lazy option and do the migration, rather than perpetually putting
it off and incurring more and more technical debt in the process.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Technical debt - was Re: datetime seems to be broken WRT timezones (even when you add them)

[Chris Angelico]

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 way of looking at things.  But
> it doesn't matter what you do, there's always real cost, and therefore
> always technical debt. Moving to Python 3 incurs technical debt.
> Staying with Python 2 incurs technical debt.  Thus I wonder if the term
> is actually that useful.
>
> I know what you mean, though.  The cost of staying with Python2 is
> increasing rapidly compared to the cost of porting to Python3.  Unlike
> the nebulous term, "technical debt," the cost of staying with Python2 vs
> porting to Python3 can be quantified in real dollar amounts.  I've no
> doubt that the calculus is in favor of Python2 a while longer for many
> people.

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 off that debt when you
sink time into something in order to make it easier to work on in the
future. The most common form of technical debt is legacy code, where
you often end up paying interest on the debt every time you dip your
toes into the code to make a small change, avoiding the work of
actually refactoring things and fixing the problems.

Porting to Python 3 should *improve* your codebase, so it should be a
way of shedding technical debt. (Unless you do it by running 2to3 on
your code and hoping for the best. But that's a bad idea for many
other reasons.)

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: datetime seems to be broken WRT timezones (even when you add them)

[Barry Scott]

> 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 timezone you care about.  In the general
> case, this is hard, but since the timezone my dates are in is always
> GMT, it's no problem:
> 
> class GMT(datetime.tzinfo):
>def utcoffset(self, dt):
>return datetime.timedelta(hours=0)
>def dst(self, dt):
>return datetime.timedelta(minutes=0)
>def tzname(self, dt):
>return "GMT"
> 
> 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:


 dt = datetime.datetime(2020, 1, 31, 1, 30, 45, 987654, GMT())
 dt
> datetime.datetime(2020, 1, 31, 1, 30, 45, 987654, tzinfo=<__main__.GMT object 
> at 0x7f9084e2add0>)
 print dt
> 2020-01-31 01:30:45.987654+00:00
> 
> Note the tzinfo object, and the +00:00 indicating this is indeed in
> GMT.  If you create a "naive" datetime object, you don't get that:
> 
 xy = datetime.datetime(2020, 1, 31, 1, 30, 45, 987654)
 xy
> datetime.datetime(2020, 1, 31, 1, 30, 45, 987654)
 print xy
> 2020-01-31 01:30:45.987654
> 
> 
> So far, so good.  However, when you go to use this object, the time it
> represents is in fact wrong.  For example:
> 
 print dt.strftime("%s")
> 1580452245
> 
> Using the date command, we can easily see that it is incorrect:
> 
> # Ask for UTC, gives the wrong time
> $ date -u -d "@1580452245"
> Fri Jan 31 06:30:45 UTC 2020
> 
> # Ask for local time, gives the time I specified... which should have
> # been in GMT, but is in my local timezone
> $ date -d "@1580452245"
> Fri Jan 31 01:30:45 EST 2020
> 
> And the correct value should have been:
> $ date -d "2020-01-31 1:30:45 GMT" +%s
> 1580434245
> 
> Same results under Python2.7 or Python3.
> 
> :( :( :(
> 
> I suspect this is because the underlying implementation uses
> strftime() which takes struct tm, which has no field to contain the
> timezone info, and does not do the necessary conversion before handing
> it off.  I'm not sure what the date command is doing differently, but
> it clearly is able to get the correct answer.
> 
> Does Python have an alternative way to do the above, with correct
> results?

I found that there are two useful PyPi packages to help with time zones.
pytz and tzlocal.

Here is a piece of code that I use to be timezone aware for UTC and the
local time zone. It works for Windows, macOS and unix thanks.

import datetime
import pytz
import tzlocal

def utcDatetime( timestamp ):
return pytz.utc.localize( datetime.datetime.utcfromtimestamp( timestamp ) )

def localDatetime( datetime_or_timestamp ):
if type(datetime_or_timestamp) in (int, float):
dt = utcDatetime( datetime_or_timestamp )
else:
dt = datetime_or_timestamp

local_timezone = tzlocal.get_localzone()
local_dt = dt.astimezone( local_timezone )
return local_dt

Barry



> 
> Thanks
> 
> -- 
> https://mail.python.org/mailman/listinfo/python-list
> 

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Technical debt - was Re: datetime seems to be broken WRT timezones (even when you add them)

[Barry Scott]

> 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 way of looking at things.  But
> it doesn't matter what you do, there's always real cost, and therefore
> always technical debt. Moving to Python 3 incurs technical debt.
> Staying with Python 2 incurs technical debt.  Thus I wonder if the term
> is actually that useful.


At Chris said moving to python3 will *reduce* your technical debt.
You are paying off the debt.


> 
> I know what you mean, though.  The cost of staying with Python2 is
> increasing rapidly compared to the cost of porting to Python3.  Unlike
> the nebulous term, "technical debt," the cost of staying with Python2 vs
> porting to Python3 can be quantified in real dollar amounts.  I've no
> doubt that the calculus is in favor of Python2 a while longer for many
> people.

Not to mention that its harder to hire people to work on tech-debt legacy code.

Given the choice between a legacy python2 job and a modern python3 job
what would you choose?

Barry


> -- 
> https://mail.python.org/mailman/listinfo/python-list
> 

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Technical debt - was Re: datetime seems to be broken WRT timezones (even when you add them)

[Michael Torrie]

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 a legacy python2 job and a modern python3 job
> what would you choose?

If this was an income job, it would entirely depend on what it paid.  In
this day and age of the so-called "gig economy" it really doesn't
matter. I likely wouldn't be around long enough to have to personally
deal with the long-term consequences (pay the debt as you say).

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Technical debt - was Re: datetime seems to be broken WRT timezones (even when you add them)

[Chris Angelico]

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, and will only happen if
you do the job sloppily.

Perhaps you're completely misunderstanding the meaning of the term?

https://en.wikipedia.org/wiki/Technical_debt
https://thedailywtf.com/articles/technical-debt

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Technical debt - was Re: datetime seems to be broken WRT timezones (even when you add them)

[Michael Torrie]

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 off that debt when you
> sink time into something in order to make it easier to work on in the
> future. The most common form of technical debt is legacy code, where
> you often end up paying interest on the debt every time you dip your
> toes into the code to make a small change, avoiding the work of
> actually refactoring things and fixing the problems.

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." This not only included the up front cost, but
the on-going (and potentially increasing) cost of maintenance, and often
even the future cost of migrating to a new solution.  So in the end it's
all the same: cost.  And it's never paid off.  Ever.  That's why I've
recently come to question the usefulness of the term "technical debt."

> Porting to Python 3 should *improve* your codebase, so it should be a
> way of shedding technical debt. (Unless you do it by running 2to3 on
> your code and hoping for the best. But that's a bad idea for many
> other reasons.)

But see, this is the thing.  There's brand new technical debt accrued
with the move to Python 3.  The cost of the debt is lower, but it's
still there.  Because maintenance is still going to cost.  Versions
still bump and require hopefully minor tweaks.  Eventually the bigger
jumps come. New ideas come along also. New frameworks, new paradigms.


I think it's a fallacy to think we can pay down technical debt.

I'm sure we probably disagree.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Technical debt - was Re: datetime seems to be broken WRT timezones (even when you add them)

[Chris Angelico]

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 effort now at the
> > expense of being worse in the future. You pay off that debt when you
> > sink time into something in order to make it easier to work on in the
> > future. The most common form of technical debt is legacy code, where
> > you often end up paying interest on the debt every time you dip your
> > toes into the code to make a small change, avoiding the work of
> > actually refactoring things and fixing the problems.
>
> 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." This not only included the up front cost, but
> the on-going (and potentially increasing) cost of maintenance, and often
> even the future cost of migrating to a new solution.  So in the end it's
> all the same: cost.  And it's never paid off.  Ever.  That's why I've
> recently come to question the usefulness of the term "technical debt."

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.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Technical debt - was Re: datetime seems to be broken WRT timezones (even when you add them)

[Michael Torrie]

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.
> 
> That's not an intrinsic part of the rewrite, and will only happen if
> you do the job sloppily.
> 
> Perhaps you're completely misunderstanding the meaning of the term?
> 
> https://en.wikipedia.org/wiki/Technical_debt
> https://thedailywtf.com/articles/technical-debt

Yes I understand the meaning.  Getting code out the door now, at the
expense of maintenance later.  But really all code is technical debt.
That's my main point.  No one writes good enough code to be completely
free of this technical debt.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Technical debt - was Re: datetime seems to be broken WRT timezones (even when you add them)

[Python]

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 you do, there's always real cost, and therefore
> > always technical debt. Moving to Python 3 incurs technical debt.
> > Staying with Python 2 incurs technical debt.  Thus I wonder if the term
> > is actually that useful.
[...]
> 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.

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 basically means
that any non-trivial work you do inevitably will become technical debt
IMMEDIATELY, because you will not be given the time to do the job
completely in the first place, there will inevitably be bugs which are
minor enough to ignore indefinitely, and most likely, in order to meet
arbitrary-but-nevertheless-real time constraints you will find
yourself obliged to take shortcuts.  So conceptually "costs" may be
different from "debt" but in practice, you never have one without the
other, and "debt" is really just "costs" you haven't paid yet.  

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."


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Technical debt - was Re: datetime seems to be broken WRT timezones (even when you add them)

[Michael Torrie]

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
believes technical debt can never be paid off.  Microsoft got fabulously
wealthy incurring vast amounts of technical debt.  We can argue that
Windows is the result (it is), but what's killing Windows isn't the
technical debt. It's the cloud and the web.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Technical debt - was Re: datetime seems to be broken WRT timezones (even when you add them)

[Chris Angelico]

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 paying off the debt.
> >>
> >> While at the same time incurring new debt.
> >
> > That's not an intrinsic part of the rewrite, and will only happen if
> > you do the job sloppily.
> >
> > Perhaps you're completely misunderstanding the meaning of the term?
> >
> > https://en.wikipedia.org/wiki/Technical_debt
> > https://thedailywtf.com/articles/technical-debt
>
> Yes I understand the meaning.  Getting code out the door now, at the
> expense of maintenance later.  But really all code is technical debt.
> That's my main point.  No one writes good enough code to be completely
> free of this technical debt.

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 syntactic features that didn't
exist, or simply because you didn't know about them when you first
wrote the code). Maybe you'll still have SOME debt, but that doesn't
mean it's never reduced.

Debt is not a binary state.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Technical debt - was Re: datetime seems to be broken WRT timezones (even when you add them)

[Terry Reedy]

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 example is sending code to production without automated tests.


You pay off that debt when you
sink time into something in order to make it easier to work on in the
future.


In May 2013, idlelib had no test suite, no test/test_idle.py, and a few 
non-unittest unit tests.  Coverage is now somewhere around 50% and 
tested modules are much easier to work with.



The most common form of technical debt is legacy code, where
you often end up paying interest on the debt every time you dip your
toes into the code to make a small change, avoiding the work of
actually refactoring things and fixing the problems.


Without automated tests, every little change required manual testing and 
carried a non-zero chance of a regression.


--
Terry Jan Reedy

--
https://mail.python.org/mailman/listinfo/python-list

Re: Technical debt - was Re: datetime seems to be broken WRT timezones (even when you add them)

[Chris Angelico]

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.
>
> We'll agree to disagree on the last bit. And I'm not the only one that
> believes technical debt can never be paid off.  Microsoft got fabulously
> wealthy incurring vast amounts of technical debt.  We can argue that
> Windows is the result (it is), but what's killing Windows isn't the
> technical debt. It's the cloud and the web.

So what you're showing is that, sometimes, technical debt isn't paid
off. It's a bit of a logical leap to go from there to "technical debt
CAN'T be paid off", don't you think?

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Technical debt - was Re: datetime seems to be broken WRT timezones (even when you add them)

[Michael Torrie]

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 syntactic features that didn't
> exist, or simply because you didn't know about them when you first
> wrote the code). Maybe you'll still have SOME debt, but that doesn't
> mean it's never reduced.
> 
> Debt is not a binary state.

I agree with that. But your reply to my other comment didn't say that.
it said "it CAN be paid off" which is a binary thing.  Debt is paid off
(no longer existing) or it's not.  Debt can be paid down and reduced of
course.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Technical debt - was Re: datetime seems to be broken WRT timezones (even when you add them)

[Chris Angelico]

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 trying to represent
> > (maybe because those idioms require syntactic features that didn't
> > exist, or simply because you didn't know about them when you first
> > wrote the code). Maybe you'll still have SOME debt, but that doesn't
> > mean it's never reduced.
> >
> > Debt is not a binary state.
>
> I agree with that. But your reply to my other comment didn't say that.
> it said "it CAN be paid off" which is a binary thing.  Debt is paid off
> (no longer existing) or it's not.  Debt can be paid down and reduced of
> course.

Ahh, that might be a regional difference then, because around here,
it's possible to pay off some of a debt. That would be why we were
talking past each other.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Technical debt - was Re: datetime seems to be broken WRT timezones (even when you add them)

[Michael Torrie]

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."

I would agree generally, except eventually Python2 will be unavailable
in your distro and may no longer be build-able on current OS's.  However
if the program is working as well as you state, then the cost of
converting to the current version of Python (whatever that will be) is
not going to increase significantly.  Whatever the case, technical debt
belongs to the entity that owns the code.

I know some folks still running an MS-DOS system for billing.  Thanks to
things like DosBox, this system will live on for a long time yet. It
works, and they don't have any real need for anything beyond it.  It's
never needed much updating or maintenance beyond maintenance they would
do anyway like backups.  Insane amounts of technical debt?  Maybe.  Or
maybe just the cost of buying a new off-the-shelf system, which would be
the same cost (or more likely a lot more with upgrades and service
plans) had they done this years ago.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Technical debt - was Re: datetime seems to be broken WRT timezones (even when you add them)

[Michael Torrie]

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
>>> idioms that better express the concepts you're trying to represent
>>> (maybe because those idioms require syntactic features that didn't
>>> exist, or simply because you didn't know about them when you first
>>> wrote the code). Maybe you'll still have SOME debt, but that doesn't
>>> mean it's never reduced.
>>>
>>> Debt is not a binary state.
>>
>> I agree with that. But your reply to my other comment didn't say that.
>> it said "it CAN be paid off" which is a binary thing.  Debt is paid off
>> (no longer existing) or it's not.  Debt can be paid down and reduced of
>> course.
> 
> Ahh, that might be a regional difference then, because around here,
> it's possible to pay off some of a debt. That would be why we were
> talking past each other.

Yup I just came to that conclusion while typing a reply to your other
post!  My apologies.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Technical debt - was Re: datetime seems to be broken WRT timezones (even when you add them)

[Chris Angelico]

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
> >>> 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 syntactic features that didn't
> >>> exist, or simply because you didn't know about them when you first
> >>> wrote the code). Maybe you'll still have SOME debt, but that doesn't
> >>> mean it's never reduced.
> >>>
> >>> Debt is not a binary state.
> >>
> >> I agree with that. But your reply to my other comment didn't say that.
> >> it said "it CAN be paid off" which is a binary thing.  Debt is paid off
> >> (no longer existing) or it's not.  Debt can be paid down and reduced of
> >> course.
> >
> > Ahh, that might be a regional difference then, because around here,
> > it's possible to pay off some of a debt. That would be why we were
> > talking past each other.
>
> Yup I just came to that conclusion while typing a reply to your other
> post!  My apologies.
>

My apologies also :) It was one of those weird situations where I was
all "oh come on, he doesn't SERIOUSLY think that you never get rid of
any tech debt?" and you were all "oh come on, he doesn't SERIOUSLY
think that you can get rid of all of it", and we just both had no idea
:)

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

python3 embedded in LibreOffice documents

[..]

Both Open- and LibreOffice use   APSO.oxt  to support py3 in Office .odt 
documents, such as HTML files et cetera.



So one can make a web page with python and BASIC code essentially and 
save it as a document, possibly throw in some EMOTET as well.



after  import NNTPlib
one can make a lil usenet client even!
--
https://mail.python.org/mailman/listinfo/python-list