Re: Resolution of the library-path mess

2017-10-06 Thread Daniele Nicolodi via devel
On 06/10/17 18:47, Gary E. Miller via devel wrote: >> Debian solves the problem of installing user components in the system >> path creating a dist-libraries along the site-libraries path in the >> python module folder. > > Uh, yeah. Pretty much universal. Except you left out the sort of > deta

Re: Resolution of the library-path mess

2017-10-06 Thread Gary E. Miller via devel
Yo Daniele! On Fri, 6 Oct 2017 18:37:53 -0600 Daniele Nicolodi via devel wrote: > The reason is that a python interpreter cannot assume that any other > path, outside the one in which it has been installed belongs to him. Uh, no. In fact, nothing outside of the base python 'belongs' to the ins

Re: Resolution of the library-path mess

2017-10-06 Thread Daniele Nicolodi via devel
On 06/10/17 17:43, Gary E. Miller via devel wrote: > Yo Daniele! > > On Fri, 6 Oct 2017 16:57:13 -0600 > Daniele Nicolodi wrote: > What if I want to have 2.7.1 and 2.7.2, for example? >>> >>> Gentoo can easily do that as well. Pretty common on gentoo. >> >> How? It is clearly not possi

Re: Resolution of the library-path mess

2017-10-06 Thread Gary E. Miller via devel
Yo Daniele! On Fri, 6 Oct 2017 16:57:13 -0600 Daniele Nicolodi wrote: > >> What if I want to have 2.7.1 and 2.7.2, for example? > > > > Gentoo can easily do that as well. Pretty common on gentoo. > > How? It is clearly not possible with the scheme you described before. Not gonna worry ab

Re: Resolution of the library-path mess

2017-10-06 Thread Daniele Nicolodi via devel
On 10/6/17 4:21 PM, Gary E. Miller wrote: > Yo Daniele! > > On Fri, 6 Oct 2017 15:59:05 -0600 > Daniele Nicolodi wrote: > >> On 10/6/17 1:46 PM, Gary E. Miller via devel wrote: >>> Yo Daniele! >>> >>> On Thu, 5 Oct 2017 23:39:51 -0600 >>> Daniele Nicolodi via devel wrote: >>> The reason

Re: Resolution of the library-path mess

2017-10-06 Thread Fred Wright via devel
On Thu, 5 Oct 2017, Hal Murray wrote: > >> Warnings are easily lost in the noise. So either create the > >> directory or treat it as an error and bail. > > > There are two issues with just "creating the directory": > > 1) There's no guarantee that Python will actually use it. > > 2) Creating the

Re: Library-path glitch, again

2017-10-06 Thread Fred Wright via devel
On Fri, 6 Oct 2017, Eric S. Raymond via devel wrote: > Fred Wright writes: > >Sorry for the lateness, but I realized that the current code still has a > >bug (as well as a couple of deficiencies of a more-or-less cosmetic > >nature). It's currently checking sys.path in the *running* Python, but i

Re: Resolution of the library-path mess

2017-10-06 Thread Gary E. Miller via devel
Yo Daniele! On Thu, 5 Oct 2017 23:39:51 -0600 Daniele Nicolodi via devel wrote: > The reason why Python does not > include /usr/local folders in his search path by default is: what if > you want to install an alternative Pythion _interpreter_ there? Uh, no. Each interpreter makes it's own pat

Re: Library-path glitch, again

2017-10-06 Thread Gary E. Miller via devel
Yo Eric! On Fri, 6 Oct 2017 09:32:06 -0400 (EDT) "Eric S. Raymond via devel" wrote: > Fred, your timing is awful and you shouldn't have submitted multiple > changes as a single MR. Three days ago I might have taken a single, > simple change that fixed the one bug. Now I can't justify doing th

Re: Testing float-valued functions

2017-10-06 Thread Ian Bruene via devel
On 10/06/2017 10:15 AM, Eric S. Raymond wrote: This is why the minimal-change alternative is worth considering at this point in our release cycle. It means you don't have to do that research project. Done, functions that can be simply changed to assertAlmostEqual have been, problematic one

Re: Library-path glitch, again

2017-10-06 Thread Daniele Nicolodi via devel
On 06/10/17 07:32, Eric S. Raymond via devel wrote: > Daniele, you weren't ignored. I read and processed what you said, > but it's way too late in the cycle to redo the build around a technique > (virtual environments) that the senior devs don't have experience with. I don't understand this state

Re: Testing float-valued functions

2017-10-06 Thread Eric S. Raymond via devel
Ian Bruene via devel : > I changed ntp_to_posix back to what it should be, and fixed what tests I can > fix immediately. Good. > >A question for you to ponder: should you replace all assertEqual calls > >or only those on which we have seen failures? If the latter, what > >else do you need to do?

Re: Testing float-valued functions

2017-10-06 Thread Ian Bruene via devel
On 10/06/2017 06:52 AM, Eric S. Raymond wrote: In fact, all this test code is subtly wrong, and it is just blind luck nothing went sproing sooner. Any of those assertions could have gone toes-up at any time. The tests in posixize() are wrong, too. The problem here is that float representation

Library-path glitch, again

2017-10-06 Thread Eric S. Raymond via devel
Fred Wright writes: >Sorry for the lateness, but I realized that the current code still has a >bug (as well as a couple of deficiencies of a more-or-less cosmetic >nature). It's currently checking sys.path in the *running* Python, but it >needs to be checking it in the *target* Python. Specifying

Testing float-valued functions

2017-10-06 Thread Eric S. Raymond via devel
This is a training assignment for Ian Bruene. I'm describing the background in public because this is an instance of a generic error other programmers are likely to run into, and all need to guard against it. As it presently exists, the pylib/packet.py function def ntp_to_posix(t) is incorrect.