RE: Pythonic Y2K

[David Raymond]

Which brings up the assumption that this whole A.D. thing is gonna stick around 
for more than a few millennia and isn't just a fad. Sloppy to just use positive 
for A.D. and negative for B.C. without a discrete unit for Age. What happens 
when Sauron is defeated and the Third Age is declared? Or if we go back to "in 
the 65th year of the reign of Elizabeth, second of her name"? Or if someone 
declares a new epoch and that this is really the year 49 A.U. (Anno Unixy)?


-Original Message-
From: Python-list 
[mailto:python-list-bounces+david.raymond=tomtom@python.org] On Behalf Of 
Avi Gross
Sent: Thursday, January 17, 2019 5:46 PM
To: python-list@python.org
Subject: RE: Pythonic Y2K

Ian,

You just scared me. It is 2019 which has four digits. In less than 8,000
years we will need to take the fifth to make numbers from 10,000 to 10,999.
90,000 years later we will need a sixth digit and so on.

Do you know how many potential Y2K-like anomalies we may have between now
and year 292,277,026,596 when it may all be over? Will people evert learn
and just set aside lots of room that dates can grow into or allow varying
lengths?

Makes me wonder though why anyone in the distant future would want numbers
that long to represent that date. I suspect that long before then, some
surviving members of whatever the human race becomes will do a reset to a
new calendar such as the date the first settlers arrived in the Gamma
Quadrant.

So whatever unit they store time in, though, may still need a way to reach
back to historic times just as we do by talking about what may have happened
in 2000 B.C.


-Original Message-
From: Python-list  On
Behalf Of Ian Kelly
Sent: Thursday, January 17, 2019 2:14 PM
To: Python 
Subject: Re: Pythonic Y2K

On Wed, Jan 16, 2019 at 9:57 PM Avi Gross  wrote:
>
> The forthcoming UNIX 2038 problem will, paradoxically happen on 
> January
19. I wonder what they will do long before then. Will they just add a byte
or four or 256 and then make a date measurable in picoseconds? Or will they
start using a number format that can easily deal with 1 Million B.C. and 5
Billion A.D. just in case we escape earth before it co-locates with the
expanding sun.

The obvious solution is to stop using 32-bit Unix timestamps and start using
64-bit Unix timestamps. This change has already been made in some OSes, and
the problem will not repeat until the year 292,277,026,596, by which time it
is highly unlikely that either Unix timestamps or humankind itself will
still exist. Even if they will, that moment in time is so far out from the
present that I can't really be bothered by the possibility.

We have 19 years to take care of the problem before it happens. Hopefully
this time around we won't be trying to fix it right up until the last
minute.
--
https://mail.python.org/mailman/listinfo/python-list

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

Re: python package management confusion

[dcs3spp via Python-list]

On Friday, 18 January 2019 07:39:00 UTC, dieter  wrote:
> dcs3spp via Python-list  writes:
> > ...
> > How do I configure setuptools to pull my own private dependency package 
> > using virtualenv + python setup.py develop
> 
> 
> You call "python setup.py develop" for your own package
> (which the "python" from the virtualenv).
> 
> This makes your package (more precisely, the one whose "setup.py"
> you have activated) available in the virtualenv.
> The "making available" happens in a way, that Python is actually
> using your package's source tree; thus, modifications in this
> source tree are seen by Python (either the next "run" or via
> "importlib.reload").

Thanks dieter I understand that is the case if I have one project and have 
tried it and that works fine.

My situation is similar to the following

Assume the following two privately developed projects that I have written, each 
with their own setup.py:
1. parent exists in folder $HOME/project/
2. child exists in folder $HOME/a_different_project/
*child could be also be used by other projects in the future

parent has a dependency requirement on child and so child is listed as an 
install dependency in parent setup.py

if I try python setup.py develop from parent project it fails to find child 
dependency on build. 

I have created a github project to illustrate the scenario @

https://github.com/dcs3spp/setuptools_dependency_example
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Pythonic Y2K

[Michael Torrie]

On 01/16/2019 12:02 PM, Avi Gross wrote:
> I recall the days before the year 2000 with the Y2K scare when people
> worried that legacy software might stop working or do horrible things once
> the clock turned. It may even have been scary enough for some companies to
> rewrite key applications and even switch from languages like COBOL.

Of course it wasn't just a scare.  The date rollover problem was very
real. It's interesting that now we call it the Y2K "scare" and since
most things came through that okay we often suppose that the people who
were warning about this impending problem were simply being alarmist and
prophets of doom.  We often deride them.  But the fact is, people did
take these prophets of doom seriously and there was a massive, even
heroic effort, to fix a lot of these critical backend systems so that
disaster was avoided (just barely).  I'm not talking about PCs rolling
over to 00.  I'm talking about banking software, mission critical
control software.  It certainly was scary enough for a lot of companies
to spend a lot of money rewriting key software.  The problem wasn't with
COBOL necessarily.

In the end disaster was averted (rather narrowly) thanks to the hard
work of a lot of people, and thanks to the few people who were vocal in
warning of the impending issue.

That said, I'm not sure Python 2.7's impending EOL is comparable to the
Y2K crisis.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Pythonic Y2K

[Larry Martell]

On Fri, Jan 18, 2019 at 10:43 AM Michael Torrie  wrote:
>
> On 01/16/2019 12:02 PM, Avi Gross wrote:
> > I recall the days before the year 2000 with the Y2K scare when people
> > worried that legacy software might stop working or do horrible things once
> > the clock turned. It may even have been scary enough for some companies to
> > rewrite key applications and even switch from languages like COBOL.
>
> Of course it wasn't just a scare.  The date rollover problem was very
> real. It's interesting that now we call it the Y2K "scare" and since
> most things came through that okay we often suppose that the people who
> were warning about this impending problem were simply being alarmist and
> prophets of doom.  We often deride them.  But the fact is, people did
> take these prophets of doom seriously and there was a massive, even
> heroic effort, to fix a lot of these critical backend systems so that
> disaster was avoided (just barely).  I'm not talking about PCs rolling
> over to 00.  I'm talking about banking software, mission critical
> control software.  It certainly was scary enough for a lot of companies
> to spend a lot of money rewriting key software.  The problem wasn't with
> COBOL necessarily.

I had one client, a hedge fund, that I fixed literally 1000's of Y2K
issues for. When Y2K came and there were no problems, the owner said
to me "You made such a big deal about the Y2K thing, and nothing
happened."
-- 
https://mail.python.org/mailman/listinfo/python-list

mocking for get method in requests

[Shakti Kumar]

Hello people,
I noticed something weird (weird as per my current knowledge, though I know
its subjective) today.

sample.py file

--

import requests
def random_testing():
out = requests.get('www.cisco.com')
a = out.json()
return a


testing.py file

--

@patch(*’*sample.requests')
def test_random_testing(self, mock_req):
mock_req.get('').return_value = 'Hello'
out = api.random_testing()


Patching the sample.requests in this way does not lead the output of
requests.get() function in sample.py file to be ‘Hello’ as indicated
in
mock_req.get('').return_value = 'Hello'
Instead, it creates a new field called return_value in ‘out', and
hence out.return_value is ‘Hello’ instead of just ‘out’.

But if I patch it as,

@patch(*’*sample.requests')
def test_random_testing(self, mock_req):
mock_req.get.return_value = 'Hello'
out = api.random_testing()

It does give the value of ‘out’ as ‘Hello’ in sample.py file.
I know I am missing something, which is where I need some help :)

Thanks.

-- 



UG, CSE,
RVCE, Bengaluru.
-- 
https://mail.python.org/mailman/listinfo/python-list

RE: Pythonic Y2K

[David Raymond]

Reminds me of a similar problem that didn't get noticed until it did actually 
hit: In 2007 the first time a group of F-22's crossed the international date 
line every computer system in the aircraft crashed, losing comms, navigation, 
avionics, and a host of other systems. Fortunately their engines, landing gear, 
and enough other systems still worked, so they were able to visually follow 
their refueling tankers back to Hawaii and land, where they had to sit for a 
couple days before Lockheed could patch their software.

If the circumstances had been a little different they could have lost a whole 
group of shiny new $150 million aircraft to a software bug and left a bunch a 
pilots floating in life rafts for a while in the middle of the Pacific.


-Original Message-
From: Python-list 
[mailto:python-list-bounces+david.raymond=tomtom@python.org] On Behalf Of 
Michael Torrie
Sent: Friday, January 18, 2019 10:36 AM
To: python-list@python.org
Subject: Re: Pythonic Y2K

On 01/16/2019 12:02 PM, Avi Gross wrote:
> I recall the days before the year 2000 with the Y2K scare when people
> worried that legacy software might stop working or do horrible things once
> the clock turned. It may even have been scary enough for some companies to
> rewrite key applications and even switch from languages like COBOL.

Of course it wasn't just a scare.  The date rollover problem was very
real. It's interesting that now we call it the Y2K "scare" and since
most things came through that okay we often suppose that the people who
were warning about this impending problem were simply being alarmist and
prophets of doom.  We often deride them.  But the fact is, people did
take these prophets of doom seriously and there was a massive, even
heroic effort, to fix a lot of these critical backend systems so that
disaster was avoided (just barely).  I'm not talking about PCs rolling
over to 00.  I'm talking about banking software, mission critical
control software.  It certainly was scary enough for a lot of companies
to spend a lot of money rewriting key software.  The problem wasn't with
COBOL necessarily.

In the end disaster was averted (rather narrowly) thanks to the hard
work of a lot of people, and thanks to the few people who were vocal in
warning of the impending issue.

That said, I'm not sure Python 2.7's impending EOL is comparable to the
Y2K crisis.
-- 
https://mail.python.org/mailman/listinfo/python-list
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Pythonic Y2K

[Grant Edwards]

On 2019-01-18, Dennis Lee Bieber  wrote:

>   Hey... I'm still waiting for a novelization of the TRS-DOS date "bug".
> TRS-DOS directory structure only allocated 3-bits for the year.

Three bits for the year?  they didn't expect those computers to last
long, eh?

[My current Thinkpad is over 10 years old.]

-- 
Grant Edwards   grant.b.edwardsYow! BARBARA STANWYCK makes
  at   me nervous!!
  gmail.com

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

Re: Pythonic Y2K

[mm0fmf]

On 17/01/2019 02:34, Avi Gross wrote:





 but all it took was to set the clock forward on a test system and
look for anomalies.


You're new to programming or you're not very  old and certainly haven't 
run much pre-Y2k software. ;-)


Issues that needed solving:

2 digits only for the date
use of 99 or 00 in the year for "magic" purposes
software that didn't know 2000 was a leap year

One machine I had to update (all in Z80 assembler) had the date in the 
format DD-MMM-199Y, i.e. only the units year could be changed. There was 
a comment in the date code saying


; marketing say this machine will stop being sold in 1993 so there
; is no need to support anything other than 1990-1999 in the year

It was still being sold in 2002!

The reason there were so few Y2K issues was that things were fixed in 
advance. And yes, there was also lots of stupidity and hysterics from 
people who didn't know. One major change, after people started fixing 
this in issue in earnest, dates started to always include the century 
digits.


Now get off my lawn! :-)


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

RE: Pythonic Y2K

[Avi Gross]

Michael,

I certainly agree with you on most of what you said. My internal humor makes
me see patterns that are not at all applicable. Such as the common "2" in
python 2.X and Y2K which influence my choice of phrases. And, perhaps even
more oddly, I see Y and K in both Y2K and the slightly odd spelling of
pYthoniK, and even 2/to. Just the way my mind works as it searches for
patterns knowing that most of them do not really exist and then trying to
winnow it down to those that do. Can't expect anyone to follow and would be
afraid of anyone that can.

As stated, nothing horrible happens immediately when python 2.X is
officially declared as no longer supported by the main python organizations.
I am sure they can go to NetFLIX or FOX and be revived as a series for a
while longer like Longmire and Last Man Standing after their original
networks abandoned them.

But it can take something noisy to get the attention of some people. For
Y2K, there was a very real threat even if it only impacted one program in a
hundred or even 10,000. That one could be quite serious if it was in a
mission critical component. What if it decided to delete lots of data or
declare people dead or send a missile the wrong way (as if there is a right
way!) The problem was not just the two digits used but that many languages
might allow longer items to write into other parts of memory leading to
further corruption. Or a program simply changed to handle wider data might
encounter old data and do odd things or now be too big to fit into memory or
even have some weird sporadic race condition now that it took a tad longer
to run and so on. And, fixing something quickly (or even slowly) might
introduce brand new errors.  There was plenty to be scared about. Change is
scary but sometimes what is even scarier is no change.

In the end not much happened BUT I wonder what could have happened if nobody
went through most of the code and often adjusted it. Some vaccines have
worked so well that people say we don't need them because hardly anyone gets
that infection any more. Really? Does that mean it was a waste to use it in
the first place or perhaps there is some cause/effect there.

I am often asked to proofread something before it is sent out. I find an
amazing number of things including many quite relevant and obvious. What is
scary is I keep seeing errors in things that get out there. Most are
harmless and are either not noticed at all, such as a repeated "of"  but in
a computer language, something like that can just break things. I was amused
recently at a book that seemed to use the word "score" when talking about a
python module that does statistical work (more like Machine Learning) and
noted it was a mistake that should have said "core = -1" because it was an
option allowing the algorithm to run in parallel on as many cores (i.e. CPU)
as the machine had available. Again, the spelling did matter but I suspect
few would notice. That is why Y2K often required teams of people with
different backgrounds to slog through code reviews so more problems would be
found than any one person might notice.

Anyone who has been involved in projects where you get errors reported and
recorded as modification requests may relate to this. The requests are often
routed around to be validated and see if they are duplicates  and then
assigned priorities and some make it into future versions. What bothered me
is we would see reports coming from unit testing and then more in system
tests and then from the field after deployment but they just kept coming.
Some problems will only be seen if you take some convoluted pathway.

Y2K was a problem they should have seen decades away and some did.

I don't make fun of COBOL. It was a tool largely designed for a purpose that
made some people who like Business stuff to be happy or be able to do more
than they used to. FORTRAN and LISP and other such tools made other such
groups happy. Yes, Modern Languages may make many early ones look like toys
NOW as we stand on the shoulders of Lilliputians.

But my view of the world sees marketing and politics and frankly radicals
using scare tactics as major drivers of events and they tend to overdo to
the point where everything becomes a crisis and therefore nothing can be
taken seriously even if it turns out to BE a crisis. The Software industry
is no different.

So I suggest a sober discussion on benefits that may occur. I note some
improvements are NOT. My machine keeps rebooting with other strange behavior
because it is trying to load an improvement/UPDATE that oddly was already
done last month. Turns out I am not alone and a fix involves uninstalling
the old one the hard way. Microsoft does things like this frequently when an
update messes things up and another update is needed to the point where many
simply decide to wait a while.

That brings me to the point. One horrible thing about some programs such as
C was that they could fail drastically at run time. Blue Screen of Death
ty

RE: Pythonic Y2K

[Avi Gross]

Larry,

I keep hearing similar things about the Flu Vaccine. It only works 40% of
the time or whatever. But most of the people that get the flu get a
different strain they were not vaccinated against!

There are hundreds of strains out there and by protecting the herd against
just a few, others will flourish. So was it worth it?

Your argument would be that your work found lots of things related to Y2000
that could have been a problem and therefore never got a chance to show. I
wonder if anyone did a case study and found an organization that refused to
budge and changed nothing, not even other products that were changed like
the OS? If such organizations had zero problems, that would be interesting.
If they had problems and rapidly had their software changed or fixed, that
would be another and we could ask if the relative cost and consequence made
such an approach cheaper.

But in reality, I suspect that many of the vendors supplying products made
the change for all their clients. I bet Oracle might have offered some
combination of new and improved products to replace old ones or tools that
could be used to say read in a database in one format and write it out again
with wider date fields. 

The vast difference some allude to is realistic. Y2K swept the globe in
about 24 hours. No easy way to avoid it for many applications. Someone
running python 2.X on their own machines may be able to continue living in
their bubble for quite a while. If you sell or share a product with python
frozen into an app, it makes no difference. But asking some clients to
maintain multiple copies of python set up so one app keeps running as all
others use the newer one, may not remain a great solution indefinitely. 

Has anyone considered something that may be at the edges. How well do
cooperating programs work together? I mean if program one processes and
saves some data structures using something like pickle, and program two is
supposed to read the pickle back in and continue processing, then you may
get anomalies of many kinds if they use different pythons. Similarly,
processes that start up other scripts and communicate with them, may need to
start newer programs that use the 3.X or beyond version as no back-ported
version exists. The bubble may enlarge and may eventually burst.

-Original Message-
From: Python-list  On
Behalf Of Larry Martell
Sent: Friday, January 18, 2019 10:47 AM
To: Python 
Subject: Re: Pythonic Y2K

On Fri, Jan 18, 2019 at 10:43 AM Michael Torrie  wrote:
>
> On 01/16/2019 12:02 PM, Avi Gross wrote:
> > I recall the days before the year 2000 with the Y2K scare when 
> > people worried that legacy software might stop working or do 
> > horrible things once the clock turned. It may even have been scary 
> > enough for some companies to rewrite key applications and even switch
from languages like COBOL.
>
> Of course it wasn't just a scare.  The date rollover problem was very 
> real. It's interesting that now we call it the Y2K "scare" and since 
> most things came through that okay we often suppose that the people 
> who were warning about this impending problem were simply being 
> alarmist and prophets of doom.  We often deride them.  But the fact 
> is, people did take these prophets of doom seriously and there was a 
> massive, even heroic effort, to fix a lot of these critical backend 
> systems so that disaster was avoided (just barely).  I'm not talking 
> about PCs rolling over to 00.  I'm talking about banking software, 
> mission critical control software.  It certainly was scary enough for 
> a lot of companies to spend a lot of money rewriting key software.  
> The problem wasn't with COBOL necessarily.

I had one client, a hedge fund, that I fixed literally 1000's of Y2K issues
for. When Y2K came and there were no problems, the owner said to me "You
made such a big deal about the Y2K thing, and nothing happened."
--
https://mail.python.org/mailman/listinfo/python-list

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

Re: Pythonic Y2K

[Larry Martell]

On Fri, Jan 18, 2019 at 4:56 PM Avi Gross  wrote:
>
> Larry,
>
> I keep hearing similar things about the Flu Vaccine. It only works 40% of
> the time or whatever. But most of the people that get the flu get a
> different strain they were not vaccinated against!

That seems like a complete non-sequitur. What does that have to do with Y2K?

But I will tell you something: I've never had a flu vaccine in my life
and I've never had the flu.

And I will tell you something else: I have proof that worrying works -
99% of the things I worry about never happen, so it must work.

And please stop top posting.

> There are hundreds of strains out there and by protecting the herd against
> just a few, others will flourish. So was it worth it?
>
> Your argument would be that your work found lots of things related to Y2000
> that could have been a problem and therefore never got a chance to show. I
> wonder if anyone did a case study and found an organization that refused to
> budge and changed nothing, not even other products that were changed like
> the OS? If such organizations had zero problems, that would be interesting.
> If they had problems and rapidly had their software changed or fixed, that
> would be another and we could ask if the relative cost and consequence made
> such an approach cheaper.
>
> But in reality, I suspect that many of the vendors supplying products made
> the change for all their clients. I bet Oracle might have offered some
> combination of new and improved products to replace old ones or tools that
> could be used to say read in a database in one format and write it out again
> with wider date fields.
>
> The vast difference some allude to is realistic. Y2K swept the globe in
> about 24 hours. No easy way to avoid it for many applications. Someone
> running python 2.X on their own machines may be able to continue living in
> their bubble for quite a while. If you sell or share a product with python
> frozen into an app, it makes no difference. But asking some clients to
> maintain multiple copies of python set up so one app keeps running as all
> others use the newer one, may not remain a great solution indefinitely.
>
> Has anyone considered something that may be at the edges. How well do
> cooperating programs work together? I mean if program one processes and
> saves some data structures using something like pickle, and program two is
> supposed to read the pickle back in and continue processing, then you may
> get anomalies of many kinds if they use different pythons. Similarly,
> processes that start up other scripts and communicate with them, may need to
> start newer programs that use the 3.X or beyond version as no back-ported
> version exists. The bubble may enlarge and may eventually burst.
>
> -Original Message-
> From: Python-list  On
> Behalf Of Larry Martell
> Sent: Friday, January 18, 2019 10:47 AM
> To: Python 
> Subject: Re: Pythonic Y2K
>
> On Fri, Jan 18, 2019 at 10:43 AM Michael Torrie  wrote:
> >
> > On 01/16/2019 12:02 PM, Avi Gross wrote:
> > > I recall the days before the year 2000 with the Y2K scare when
> > > people worried that legacy software might stop working or do
> > > horrible things once the clock turned. It may even have been scary
> > > enough for some companies to rewrite key applications and even switch
> from languages like COBOL.
> >
> > Of course it wasn't just a scare.  The date rollover problem was very
> > real. It's interesting that now we call it the Y2K "scare" and since
> > most things came through that okay we often suppose that the people
> > who were warning about this impending problem were simply being
> > alarmist and prophets of doom.  We often deride them.  But the fact
> > is, people did take these prophets of doom seriously and there was a
> > massive, even heroic effort, to fix a lot of these critical backend
> > systems so that disaster was avoided (just barely).  I'm not talking
> > about PCs rolling over to 00.  I'm talking about banking software,
> > mission critical control software.  It certainly was scary enough for
> > a lot of companies to spend a lot of money rewriting key software.
> > The problem wasn't with COBOL necessarily.
>
> I had one client, a hedge fund, that I fixed literally 1000's of Y2K issues
> for. When Y2K came and there were no problems, the owner said to me "You
> made such a big deal about the Y2K thing, and nothing happened."
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Pythonic Y2K

[Gene Heskett]

On Friday 18 January 2019 16:55:28 Avi Gross wrote:

> Larry,
>
> I keep hearing similar things about the Flu Vaccine. It only works 40%
> of the time or whatever. But most of the people that get the flu get a
> different strain they were not vaccinated against!
>
> There are hundreds of strains out there and by protecting the herd
> against just a few, others will flourish. So was it worth it?
>
> Your argument would be that your work found lots of things related to
> Y2000 that could have been a problem and therefore never got a chance
> to show. I wonder if anyone did a case study and found an organization
> that refused to budge and changed nothing, not even other products
> that were changed like the OS? If such organizations had zero
> problems, that would be interesting. If they had problems and rapidly
> had their software changed or fixed, that would be another and we
> could ask if the relative cost and consequence made such an approach
> cheaper.
>
> But in reality, I suspect that many of the vendors supplying products
> made the change for all their clients. I bet Oracle might have offered
> some combination of new and improved products to replace old ones or
> tools that could be used to say read in a database in one format and
> write it out again with wider date fields.
>
> The vast difference some allude to is realistic. Y2K swept the globe
> in about 24 hours. No easy way to avoid it for many applications.
> Someone running python 2.X on their own machines may be able to
> continue living in their bubble for quite a while. If you sell or
> share a product with python frozen into an app, it makes no
> difference. But asking some clients to maintain multiple copies of
> python set up so one app keeps running as all others use the newer
> one, may not remain a great solution indefinitely.
>
> Has anyone considered something that may be at the edges. How well do
> cooperating programs work together? I mean if program one processes
> and saves some data structures using something like pickle, and
> program two is supposed to read the pickle back in and continue
> processing, then you may get anomalies of many kinds if they use
> different pythons. Similarly, processes that start up other scripts
> and communicate with them, may need to start newer programs that use
> the 3.X or beyond version as no back-ported version exists. The bubble
> may enlarge and may eventually burst.
>
> -Original Message-
> From: Python-list
>  On Behalf Of
> Larry Martell
> Sent: Friday, January 18, 2019 10:47 AM
> To: Python 
> Subject: Re: Pythonic Y2K
>
> On Fri, Jan 18, 2019 at 10:43 AM Michael Torrie  
wrote:
> > On 01/16/2019 12:02 PM, Avi Gross wrote:
> > > I recall the days before the year 2000 with the Y2K scare when
> > > people worried that legacy software might stop working or do
> > > horrible things once the clock turned. It may even have been scary
> > > enough for some companies to rewrite key applications and even
> > > switch
>
> from languages like COBOL.
>
> > Of course it wasn't just a scare.  The date rollover problem was
> > very real. It's interesting that now we call it the Y2K "scare" and
> > since most things came through that okay we often suppose that the
> > people who were warning about this impending problem were simply
> > being alarmist and prophets of doom.  We often deride them.  But the
> > fact is, people did take these prophets of doom seriously and there
> > was a massive, even heroic effort, to fix a lot of these critical
> > backend systems so that disaster was avoided (just barely).  I'm not
> > talking about PCs rolling over to 00.  I'm talking about banking
> > software, mission critical control software.  It certainly was scary
> > enough for a lot of companies to spend a lot of money rewriting key
> > software. The problem wasn't with COBOL necessarily.
>
> I had one client, a hedge fund, that I fixed literally 1000's of Y2K
> issues for. When Y2K came and there were no problems, the owner said
> to me "You made such a big deal about the Y2K thing, and nothing
> happened." --

I would quite cheerfully have bought a ticket to watch and hear your 
reply, Larry.

Or better yet, silently reached into your briefcase and brought out an 
invoice, listing what and where you patched, and what you would normally 
charge to find and fix each one individually when the gun went off for 
real 36 hours back and his fund was losing 1% an hour.  Sometimes the 
truth shuts them up but theres usually some yelling involved.

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


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 

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

Re: Pythonic Y2K

[Rich Shepard]

On Fri, 18 Jan 2019, Gene Heskett wrote:


I had one client, a hedge fund, that I fixed literally 1000's of Y2K
issues for. When Y2K came and there were no problems, the owner said
to me "You made such a big deal about the Y2K thing, and nothing
happened." --



I would quite cheerfully have bought a ticket to watch and hear your
reply, Larry.


My response would have been, "That's because of all the time and effort I
devoted to fixing all the issues that would have put you out of business.
Perhaps a bonus is due me?"

This is a common situation for all consultants, including environmental
scientists such as I am. Clients don't know how to fix the problems they
face, nor have that capability in-house, so they need external assistance.
This lack of knowledge means they don't understand why the project took so
long nor recognize the effort put in by the consultant.

People tend to take for granted when things work smoothly but notice when
there are glitches. Ask any major conference or annual meeting director
about this. :-) A similar situation is faced by those of us who are expected
to "prove" a negative.

Carpe weekend, all,

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

Python Packages Survey

[Cameron Davidson-Pilon]

Hello! I invite you to participate in the Python Packages Survey - it takes
less than a minute to complete, and will help open source developers
understand their users' better. Thanks for participating!

https://python-packages-survey.com/

-- 

Cameron Davidson-Pilon
Data Origami 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: TKinter Newbie question

[TUA]

Thanks for your fresh pair of eyes!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: sampling from frequency distribution / histogram without replacement

[duncan smith]

On 14/01/2019 20:11, duncan smith wrote:
> Hello,
>   Just checking to see if anyone has attacked this problem before
> for cases where the population size is unfeasibly large. i.e. The number
> of categories is manageable, but the sum of the frequencies, N,
> precludes simple solutions such as creating a list, shuffling it and
> using the first n items to populate the sample (frequency distribution /
> histogram).
> 
> I note that numpy.random.hypergeometric will allow me to generate a
> sample when I only have two categories, and that I could probably
> implement some kind of iterative / partitioning approach calling this
> repeatedly. But before I do I thought I'd ask if anyone has tackled this
> before. Can't find much on the web. Cheers.
> 
> Duncan
> 

After much tinkering I came up with the following:


import numpy as np

def hypgeom_variate(freqs, n):
# recursive partitioning approach
sample = [0] * len(freqs)
cumsum = np.cumsum(list(chain([0], freqs)))
if n > cumsum[-1]:
raise ValueError('n cannot be greater than population size')
hypergeometric = np.random.hypergeometric
argslist = [(0, len(freqs), 0, cumsum[-1], n)]
for i, k, ci, ck, m in argslist:
if k == i + 1:
sample[i] = m
else:
j = (i + k) // 2
cj = cumsum[j]
x = hypergeometric(cj - ci, ck - cj, m, 1)[0]
y = m-x
if x:
argslist.append((i, j, ci, cj, x))
if y:
argslist.append((j, k, cj, ck, y))
return sample


Cheers.

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

Re: the python name

[Gregory Ewing]

DL Neil wrote:

(not that New Zealanders need to know much about snakes!)


Probably recommended when we visit Australia, though.

Also we seem to have imported some of their spiders in recent
years, so it's only a matter of time before their snakes
follow.

I wonder if we could get Australia to pay for a snake-proof
wall across the Tasman?

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

Re: python package management confusion

[dieter]

dcs3spp via Python-list  writes:
> On Friday, 18 January 2019 07:39:00 UTC, dieter  wrote:
> ...
> My situation is similar to the following
>
> Assume the following two privately developed projects that I have written, 
> each with their own setup.py:
> 1. parent exists in folder $HOME/project/
> 2. child exists in folder $HOME/a_different_project/
> *child could be also be used by other projects in the future
>
> parent has a dependency requirement on child and so child is listed as an 
> install dependency in parent setup.py
>
> if I try python setup.py develop from parent project it fails to find child 
> dependency on build. 

Do you tell me to have a cyclic dependency structure?

If not, first install "child" in your virtualenv (by whatever
means, maybe "python setup.py develop"), then "parent".

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