Re: Load python from different plugin dlls

2020-02-12 Thread R.Wieser
Eko,

> which needs also access to python3.dll but cannot load it itself as it has
> been already loaded by plugin1
>
> Is such a scenario actually possible?

Yes.

Normally a DLL can be loaded in as many processes (and threads thereof) as 
you like.

However, it is possible that the DLLs initialisation contains code to check 
if something it needs is available*, and if not directly exit.

*like if it can access certain I/O - if the first DLL instance "takes 
posession" the second DLL instance wil fail.  Than again, this can also 
happen when using two totally different plugin DLLs.

tl;dr:
Yes, but not likely.


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

2020-02-12 Thread DL Neil via Python-list

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 we "know" it's going to cost big time in the future.
  In some senses, it's theoretical future cost.  That's what I was having
a hard time with, and still do to a large degree.


I think an oft overlooked aspect of technical debt is the affect on
the programmers dealing with it:  frustration, burn-out, and
job-seeking.


Yeah for sure.  A programmer may not love dealing with technical debt,
and certainly he may want to chase greener fields.  But there are lots
of things about lots of jobs that are less pleasant than other things.
Personally I tend to get way caught up trying to get a perfect design
that avoids technical debt, but often get not much done (on my personal
projects). Whereas another guy just cranks out code that isn't always
the best but serves his needs at the time. Guess who is more productive
overall? Not me.


Applauding your professional attitude, but haven't you (only) defined 
"productive" as purely getting 'this job' out the door? cf any 
definition of "Total" cost?



I had an IT Manager moaning at me precisely because of one of those 
'other guys'. The job had been 'done'. The contract had mere 'words' to 
cover 'quality'. Accordingly, difficult to argue that 'the guy' hadn't 
done what was asked (my 'specialist' $advice on the matter). However, 
the code was 'ramshackle' and had obviously been 'dashed off' in the 
shortest amount of time possible. Maintenance costs were expected to be 
high; motivation of in-house staff to do so, expected to be v.low!


So, we're re-negotiating the contract-wording... More importantly, 
improving their acceptance testing, and adding more detail to their 
specs/requirements, etc. (the mistake there, was thinking that reqmts to 
external staff would be 'the same' as such to in-house employees)



However, the interesting question was to ask whether he (the manager) 
was 'taking advantage' of the "gig economy". (yes, that's what it's 
there for!) Thus, what relationship did he (or even, 'they' of the IT 
dept) have with the contractor? The home truth: 'using' the cheapest 
people creates a 'race to the bottom', and must, by definition, lead to 
'the cheapest job' being done. Why the surprise?
(He doesn't hire me as a programmer - and we're not even talking 
'Python', apologies!)


I asked him if he wanted a 'professional' to do the job, ie in a 
'professional manner'. Yes! So, why are you looking for the guy(?) 
who'll do it at the lowest-possible price/rate or imposing the delivery 
date on a short time-line? Ahh...


The above concerns contractors, but I managed to slide-in a few 
questions/comments that relationships with in-house staff require 
similar consideration and attention!




OK, so turning it around to people more like 'us': Professionalism? As a 
programmer/coder, would you rather work on decent code? So, is that what 
you turn-out? Alternatively, vice-versa.


That is a slightly unfair, or biased, question. I am in the fortunate 
position of being able to tell certain people that I won't undertake 
their work, that where they want me to work will push the price UP, that 
their tool-set is sub-standard, or that the existing platform is imbued 
with uncomfortably high 'risk'. I quite understand that someone who 
'needs the job' will see that as a 'luxury'. (apologies as necessary)


That said, would you build a team with a mixture of 'clock-watchers' and 
'professionals' or would/do you enjoy working within such a team?


Both 'sides' need to understand that there are two view-points to every 
relationship.



One thought that occurred to me lurking/reading this thread, is the 
likelihood that many of the differing views arise between those working 
in an 'Agile' environment, and those not (or a pseudo-/'we call 
it'-Agile environment)?


One of the (social) contracts in Scrum (for example) is that the 
professionals estimate the time needed to do the job, cf some (likely 
ignorant) 'manager' imposing a deadline. In my experience (YMMV) an 
established, professional 'Agile' team tends to follow practices which 
attempt to avoid adding to Technical Debt, and factor-in any need to 
correct sub-standard or sans-tests old-code. There is no doubt in my 
mind, that the participation of 'users' helps to create an understanding 
that (like anything else) software takes time (read also $), and that 
over-loading (?abusing) development staff is itself a 'Technical Debt' 
("Marginal Cost") for the organisation! (absences, turn-over, ... you've 
been-there, seen-that...). There again, would user-members of the team 
notice if 'we'd' padded our estimates so as to have plenty of time for 
'other things'?


It's by no means a cut-and-dried situation. What 'works

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

2020-02-12 Thread Michael Torrie
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 number.  For example, if a loan is taken to help
> fund a project, then the "interest debt" will be a portion of the
> TCO, but its amount will vary depending on the interest rate: 15%
> will be more interest debt than 4%.  Likewise, the technical debt for
> a project will be higher or lower depending on the quality of the
> code written.

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 we "know" it's going to cost big time in the future.
 In some senses, it's theoretical future cost.  That's what I was having
a hard time with, and still do to a large degree.

> I think an oft overlooked aspect of technical debt is the affect on
> the programmers dealing with it:  frustration, burn-out, and
> job-seeking.

Yeah for sure.  A programmer may not love dealing with technical debt,
and certainly he may want to chase greener fields.  But there are lots
of things about lots of jobs that are less pleasant than other things.
Personally I tend to get way caught up trying to get a perfect design
that avoids technical debt, but often get not much done (on my personal
projects). Whereas another guy just cranks out code that isn't always
the best but serves his needs at the time. Guess who is more productive
overall? Not me.

More on topic, I feel like the technical debt issue might be over used
to push folks to upgrade from Python 2, or to do promote certain
technologies.

Without knowing the details of how and why they used it, it's impossible
for me to say that it will cost them a lot in the future.  It very well
could cost nothing.  Or it might be expensive enough to sink an enterprise.

In the case of the original poster, it could well be that the
maintenance he's doing to the code is minor and of no real cost, nor any
maintenance burden in the future.  He might not need security patches or
any other on-going development of the Python 2 interpreter.  His app
might have no attack surface.  The script does its internal job and
that's that.  As long as a Python2 interpreter runs he's golden. I
suspect a lot of Python 2 use falls into that sort of category.  Sort of
like the company I know that still uses an MS-DOS billing system.
-- 
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)

2020-02-12 Thread Rhodri James

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



s/become/accrue/.  The work itself isn't the debt, but its sub-optimality
creates debt (or future headaches, if you prefer to think of it that way).



I think it's a purely semantic distinction without a practical
difference...which was the point I was trying to make.  The work is
the direct cause of the debt, and at the time it is performed the debt
is realized.  Without the work, that particular debt is not incurred.
You may have eliminated some old debt when the work is done, but your
new debt replaces your old debt.  Depending on the resources you can
devote, that debt may or MAY NOT be less than the other, and sometimes
the truth of this can not be discovered until you're already knee deep
in it.


Here's where the "purely semantic" distinction matters.  You are 
equating the work with the debt, but ignoring the benefit the work 
presumably brings (otherwise you wouldn't have done it at all).  Either 
you should be rolling it all together or separate both, surely.


--
Rhodri James *-* Kynesim Ltd
--
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)

2020-02-12 Thread Python
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 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
> 
> s/become/accrue/.  The work itself isn't the debt, but its sub-optimality
> creates debt (or future headaches, if you prefer to think of it that way).

I think it's a purely semantic distinction without a practical
difference...which was the point I was trying to make.  The work is
the direct cause of the debt, and at the time it is performed the debt
is realized.  Without the work, that particular debt is not incurred.
You may have eliminated some old debt when the work is done, but your
new debt replaces your old debt.  Depending on the resources you can
devote, that debt may or MAY NOT be less than the other, and sometimes
the truth of this can not be discovered until you're already knee deep
in it.

> > 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.
> 
> It's that last bit, "you haven't paid yet", that's the important part.
> Project managers and accountants alike are very much in favour of putting
> off paying for things if they can.  Sometimes they can be persuaded that the
> interest on the debt (the extra cost that the code structure imposes on
> fixing bugs) is too much, and then you get the opportunity to refactor and
> reduce the overall debt (at a cost, obviously) and the interest you will pay
> in the future.

Right.  Or... not.  More often than not, in my experience.  And
sometimes you can convince them you need to, but other priorities
continually surface that block it from ever happening anyway.
 
> Sometimes, and this is the bit that bean counters really like, you can get
> away without paying the debt by ditching the project entirely before the
> debt is paid off.  If you don't want to piss your customers off you need to
> pay the cost of a replacement project, which will accrue its own technical
> debt...

Or it may become obsolete due to changing circumstances.  Or (as in
many cases) it is sufficient to tell your customers, "don't do that,"
perhaps with admittedly annoying but not particularly costly
consequences if they don't listen. :) 

[It's not always feasible, but often if they complain, you can say
something like, "...but we're working on this other magic thingy that
will really help you, and spending time on fixing this thing you're
complaining about now will significantly delay the delivery of that."
It may or may not be true, but in the interim the customer learns to
stop doing that thing, and forgets they ever cared.]

Technical debt is just about inevitable, for most non-trivial software
(again, unless you've got a special case of a full solution for some
problem whose circumstances never change), and isn't necessarily a bad
thing.  It just depends entirely on the details of your situation.
And while I'm not particularly a fan of Agile in practice, the
philosophy behind it addresses this reasonably well...  But then
again, you don't *need* Agile to do that, either.  You just have to
pay attention to the problem.  Like everything else.

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

2020-02-12 Thread Avi Gross via Python-list
I have to wonder if this is a bit like what happens when something like
Windows offers you an upgrade if you pay for it. Some people have noticed
how after such things come out, a series of rapid bug fixes come along. So,
they wait. Some wait long enough until another entire version has come along
or even several such cycles. They then try to jump from say version 2.1 to
version 5.0 and skip paying for all the in-betweens. Others may wait till
something forces them to change like receiving documents their version of
EXCEL cannot handle properly or at all. And, when that happens, they may
simply jump to a different product entirely, like leaving Lotus for EXCEL.

And, as noted, some simply move on. All kinds of calendar programs and
contact list managers can become obsolete when it is all bundled into
something like Microsoft office Outlook. At some point, you toss the old or
use some tool to migrate your data, or start over.

With your own software a migration can be hairy and especially when the
original staff are long gone or promoted and the manager has no clue and no
budget for this. There seems to be substantial risk versus just leaving it
alone and hoping it works long enough for you to get your bonus or move on.
It is worse if the people maintaining it sort of made their own kludge
variations like reinventing new features on their own in ways not compatible
with the new. Do you port the kludge or switch over to the new way even if
it means restructuring other parts of the code.

A serious question. What has happened in other aspects of the field where a
big enough change bifurcates the community? I am wondering what happened
when PERL made incompatible changes. Are people still using both versions?
What about largely discontinued languages that stopped being developed in
any way and do not even have a compiler for newer machines?

I know Microsoft periodically declares no further support for much earlier
versions of Windows. I bet people who have old machines keep running without
an upgrade, especially when their machine does not support the new version
because it does not have enough memory or whatever. Why keep the old? I am
sure they have their reasons that boil down to it runs programs they know
well and that do what they need and do not add many bells and whistles that
they  don't think they need or that force them to change their ways. For
some touch typists, the earlier word processors that do not know about a
mouse and run in one big window, may be just right. But try sending one to
others without using some conversion method first.

But anyone teaching Python today who still uses version 2 exclusively may
have some explaining to do unless the goal is to maintain and migrate those
using it to version 3. Are there any serious new projects being built NOW
using version 2?

-Original Message-
From: Python-list  On
Behalf Of Rhodri James
Sent: Wednesday, February 12, 2020 8:16 AM
To: python-list@python.org
Subject: Re: 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 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

s/become/accrue/.  The work itself isn't the debt, but its sub-optimality
creates debt (or future headaches, if you prefer to think of it that way).

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

It's that last bit, "you haven't paid yet", that's the important part. 
Project managers and accountants alike are very much in favour of putting
off paying for things if they can.  Sometimes they can be persuaded that the
interest on the debt (the extra cost that the code structure imposes on
fixing bugs) is too much, and then you get the opportunity to refactor and
reduce the overall debt (at a cost,
obviously) and the interest you will pay in the future.

Sometimes, and this is the bit that bean counters really like, you can get
away without paying the debt by ditching the project entirely before the
debt is paid off.  If you don't want to piss your customers off you need to
pay the cost of a replacement project, which will accrue its own technical
debt...

-- 
Rhodri James *-* Kynesim Ltd
-- 
https://mail.python.org/mailman/listinfo/python-list

-- 
https://

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

2020-02-12 Thread Ethan Furman

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 project, then 
the "interest debt" will be a portion of the TCO, but its amount will vary 
depending on the interest rate: 15% will be more interest debt than 4%.  Likewise, the 
technical debt for a project will be higher or lower depending on the quality of the code 
written.

I think an oft overlooked aspect of technical debt is the affect on the 
programmers dealing with it:  frustration, burn-out, and job-seeking.

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


ghostscripts in python with watchdog

2020-02-12 Thread legaulph
I'm trying to use ghostscripts with python watchdog.

I want to duplicate the last page of a pdf to another directory using the
same name as the source pdf + page number.

So watchdog will monitor the directory for the pdf and ghostscript will copy
the last page to another directory.

I have this, and not able to figure out how to change the output name and
location.

 

import sys

import os

import time

import logging

from watchdog.observers import Observer

from watchdog.events import LoggingEventHandler

from watchdog.events import PatternMatchingEventHandler

 

if __name__ == "__main__":

patterns = "*"

ignore_patterns = ""

ignore_directories = False

case_sensitive = True

my_event_handler = PatternMatchingEventHandler(patterns,
ignore_patterns, ignore_directories, case_sensitive)

def on_created(event):

number_of_pages = 4

input_pdf = event.src_path

for i in range(4, number_of_pages +1):

os.system("gswin64c -q -dBATCH -dNOPAUSE
-sOutputFile=page{page:04d}.pdf"

" -dFirstPage={page} -dLastPage={page}"

" -sDEVICE=pdfwrite {input_pdf}"

.format(page=i, input_pdf=input_pdf))

 

my_event_handler.on_created = on_created

 

path = "."

go_recursively = True

my_observer = Observer()

my_observer.schedule(my_event_handler, path, recursive=go_recursively)

 

my_observer.start()

try:

while True:

time.sleep(1)

except KeyboardInterrupt:

my_observer.stop()

my_observer.join()

 

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

2020-02-12 Thread Rhodri James

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 basically means
that any non-trivial work you do inevitably will become technical debt


s/become/accrue/.  The work itself isn't the debt, but its 
sub-optimality creates debt (or future headaches, if you prefer to think 
of it that way).



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.


It's that last bit, "you haven't paid yet", that's the important part. 
Project managers and accountants alike are very much in favour of 
putting off paying for things if they can.  Sometimes they can be 
persuaded that the interest on the debt (the extra cost that the code 
structure imposes on fixing bugs) is too much, and then you get the 
opportunity to refactor and reduce the overall debt (at a cost, 
obviously) and the interest you will pay in the future.


Sometimes, and this is the bit that bean counters really like, you can 
get away without paying the debt by ditching the project entirely before 
the debt is paid off.  If you don't want to piss your customers off you 
need to pay the cost of a replacement project, which will accrue its own 
technical debt...


--
Rhodri James *-* Kynesim Ltd
--
https://mail.python.org/mailman/listinfo/python-list


Load python from different plugin dlls

2020-02-12 Thread Eko palypse
Assuming there is an CppApp which allows extending its functionality by adding 
plugins. Now let's assume there are plugin developer which use cython to create 
such a plugins.

How can one check if there has been already a plugin loaded which itself loaded 
a python interpreter?

And if this is possible, what needs to be done that a second plugin can be used 
with the python interpreter loaded from the first plugin?

To summarize:
CppApp loads pluign1 (which loads python3.dll) ok
CppApp loads pluign2 (which needs also access to python3.dll but cannot load it 
itself as it has been already loaded by plugin1)

Is such a scenario actually possible?

Thank you
Eren
-- 
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)

2020-02-12 Thread Jon Ribbens via Python-list
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