python3 embedded in LibreOffice documents

2020-02-11 Thread ..
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 usen

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

2020-02-11 Thread 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 > >>> ref

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

2020-02-11 Thread 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 >>> i

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

2020-02-11 Thread 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."

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

2020-02-11 Thread 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

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

2020-02-11 Thread 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 syntacti

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

2020-02-11 Thread 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

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

2020-02-11 Thread 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 examp

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

2020-02-11 Thread 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 p

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

2020-02-11 Thread 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 bel

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

2020-02-11 Thread 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 y

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

2020-02-11 Thread 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. >

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

2020-02-11 Thread 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 eff

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

2020-02-11 Thread 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

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

2020-02-11 Thread 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

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

2020-02-11 Thread 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

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

2020-02-11 Thread 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

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

2020-02-11 Thread 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

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

2020-02-11 Thread 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

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

2020-02-11 Thread 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. > > > > > > > Eve

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

2020-02-11 Thread 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

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

2020-02-11 Thread 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 > su

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

2020-02-11 Thread 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

Re: Documentation of __hash__

2020-02-11 Thread 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 has

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

2020-02-11 Thread 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

[RELEASE] Python 3.8.2rc1 is now available for testing

2020-02-11 Thread Ɓ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

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

2020-02-11 Thread 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 suppor

Re: braket an matrix in python

2020-02-11 Thread 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

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

2020-02-11 Thread 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

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

2020-02-11 Thread 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

Re: Documentation of __hash__

2020-02-11 Thread 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. > > > >