Re: Load python from different plugin dlls
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)
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)
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)
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)
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)
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)
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
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)
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
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)
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
