Re: [Python-Dev] test_uuid.py on HP NonStop Python-2.7.5 fails (test case: testIssue8621)
Hi, On Thu, Nov 28, 2013 at 7:14 AM, V S, Nagendra (Nonstop Filesystems Team) > on NonStop "uuid.py" falls throw to random.range() call to generate the > random number And indeed, the random module gets identical results in both parent and child after a fork(). This seems to mean that the random module is not safe to use in uuid without taking special care of this fact (e.g. feeding back os.getpid() into the seed). A bientôt, Armin. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] test_uuid.py on HP NonStop Python-2.7.5 fails (test case: testIssue8621)
Am 28.11.2013 10:53, schrieb Armin Rigo: > Hi, > > On Thu, Nov 28, 2013 at 7:14 AM, V S, Nagendra (Nonstop Filesystems Team) >> on NonStop "uuid.py" falls throw to random.range() call to generate the >> random number > > And indeed, the random module gets identical results in both parent > and child after a fork(). This seems to mean that the random module > is not safe to use in uuid without taking special care of this fact > (e.g. feeding back os.getpid() into the seed). Yes, there is an issue with the fallback to random, see my 17 months old bug report: http://bugs.python.org/issue15206 The uuid module needs a fork() aware random instance like the tempfile module. Christian ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] test_uuid.py on HP NonStop Python-2.7.5 fails (test case: testIssue8621)
> > Hi, > > > > On Thu, Nov 28, 2013 at 7:14 AM, V S, Nagendra (Nonstop Filesystems > > Team) > >> on NonStop "uuid.py" falls throw to random.range() call to generate > >> the random number > > > > And indeed, the random module gets identical results in both parent > > and child after a fork(). This seems to mean that the random module > > is not safe to use in uuid without taking special care of this fact > > (e.g. feeding back os.getpid() into the seed). > > Yes, there is an issue with the fallback to random, see my 17 months old bug > report: http://bugs.python.org/issue15206 The uuid module needs a > fork() aware random instance like the tempfile module. > > Christian Thanks all for your responses. I tried to something similar to what Armin was suggesting. Here is what I have done def myuuid(): random.seed(time()) # or just could be random.seed() <-New addition bytes = [chr(random.randrange(256)) for i in range(16)] val = uuid.UUID(bytes=bytes, version=4) return val With this I was able to get a unique sequences in both parent & child after fork().I have tested this function by calling it a million times & every time there has been a unique sequence both in parent & child. Do you this can be fair enough work around for this problem. Thanks & Regards Nagendra.V.S ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] buildbot's are needlessly compiling -O0
Am 24.11.2013 08:13, schrieb Gregory P. Smith: > our buildbots are setup to configure --with-pydebug which also > unfortunately causes them to compile with -O0... this results in a python > binary that is excruciatingly slow and makes the entire test suite run take > a long time. > > given that nobody is ever going to run a gdb or another debugger on the > buildbot generated transient binaries themselves how about we speed all of > the buildbot's up by adding CFLAGS=-O2 to the configure command line? > > Sure, the compile step will take a bit longer but that is dwarfed by the > test time as it is: > > http://buildbot.python.org/all/builders/AMD64%20Ubuntu%20LTS%203.x/builds/3224 > http://buildbot.python.org/all/builders/ARMv7%203.x/builds/7 > http://buildbot.python.org/all/builders/AMD64%20Snow%20Leop%203.x/builds/639 > > It should dramatically decrease the turnaround latency for buildbot results. maybe check if the compiler understands -Og (GCC 4.8), and use that? Otoh, it would be good to check with -O2 or -O3 too, common values used when building python for production use. Matthias ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP process entry point and ill fated initiatives
I wanted to help people who are trying to find out more about PEP submission process by providing relevant info (or a pointer) in README.rst that is located at the root of PEPs repository. You can see it here. https://bitbucket.org/rirror/peps I filled this issue with b.p.o http://bugs.python.org/issue19822 However, as you may see, I met some resistance, which said me to discuss the matter here. So, I'd like to discuss two things: 1. is my README.rst enhancement request is wrong? 2. what makes people close tickets without providing arguments, but using stuff like "should"? It is not the first stuff that I personally find discouraging, which may be attributed to my reputation, but what's the point in doing this? The only logical explanation I find for resistance in this particular case is that people in core Python development don't take usability and user experience matters seriously. Most of core development is about systems, not about people, so everybody is scratching own itches. I wish that usability and UX was given at least some coverage in Python development regulations. -- anatoly t. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP process entry point and ill fated initiatives
Anatoly, the Python community is a lot more diverse than you think. "Pull requests" (whatever that means) are not the way to start a PEP. You should start by focusing on the contents, and the mechanics of editing it and getting it formatted properly are secondary. The process is explained in PEP one. Your bug report would have gotten a much better response if you had simply asked "what is the process, I can't figure it out from the repo's README" rather that (again) complaining that the core developers don't care. Offending people is not the way to get them to help you. On Thu, Nov 28, 2013 at 9:45 AM, anatoly techtonik wrote: > I wanted to help people who are trying to find out more > about PEP submission process by providing relevant > info (or a pointer) in README.rst that is located at the > root of PEPs repository. You can see it here. > > https://bitbucket.org/rirror/peps > > I filled this issue with b.p.o > > http://bugs.python.org/issue19822 > > However, as you may see, I met some resistance, > which said me to discuss the matter here. So, I'd like > to discuss two things: > > 1. is my README.rst enhancement request is wrong? > 2. what makes people close tickets without providing > arguments, but using stuff like "should"? > > It is not the first stuff that I personally find discouraging, > which may be attributed to my reputation, but what's the > point in doing this? > > The only logical explanation I find for resistance in this > particular case is that people in core Python > development don't take usability and user experience > matters seriously. Most of core development is about > systems, not about people, so everybody is scratching > own itches. I wish that usability and UX was given at > least some coverage in Python development regulations. > -- > anatoly t. > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] py.ini documentation improvement
I was just getting Jython working with py.exe, and I think the documentation can be made a bit more friendly. In particular think we can make it easier for people to determine the correct folder by changing the line in 3.4.4.1 Customization via INI files: Two .ini files will be searched by the launcher - py.ini in the current user’s "application data" directory (i.e. the directory returned by calling the Windows function SHGetFolderPath with CSIDL_LOCAL_APPDATA) and py.ini in the same directory as the launcher. to Two .ini files will be searched by the launcher - py.ini in the current user’s "application data" directory (i.e. the directory returned by executing `echo %LOCALAPPDATA%` in a command window) and py.ini in the same directory as the launcher. %LOCALAPPDATA% should always contain the same value as would be returned from SHGetFolderPath with CSIDL_LOCAL_APPDATA. Tim Delaney ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] py.ini documentation improvement
On 11/28/2013 1:04 PM, Tim Delaney wrote: %LOCALAPPDATA% should always contain the same value as would be returned from SHGetFolderPath with CSIDL_LOCAL_APPDATA. Except when it gets changed. Documentation should reflect the actual use in the code. If it uses the SHGetFolderPath, that is what should be documented; if it uses the environment variable, that is what should get documented. Users can easily change the environment variable (which might be a reason to use it, instead of SHGetFolderPath). ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] py.ini documentation improvement
On 29 November 2013 08:34, Glenn Linderman wrote: > On 11/28/2013 1:04 PM, Tim Delaney wrote: > > > %LOCALAPPDATA% should always contain the same value as would be returned > from SHGetFolderPath with CSIDL_LOCAL_APPDATA. > > Except when it gets changed. Documentation should reflect the actual use > in the code. If it uses the SHGetFolderPath, that is what should be > documented; if it uses the environment variable, that is what should get > documented. Users can easily change the environment variable (which might > be a reason to use it, instead of SHGetFolderPath). > Didn't think of that - good point. Tim Delaney ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] py.ini documentation improvement
On 11/28/2013 4:04 PM, Tim Delaney wrote: I was just getting Jython working with py.exe, and I think the documentation can be made a bit more friendly. In particular think we can make it easier for people to determine the correct folder by changing the line in 3.4.4.1 Customization via INI files: Two .ini files will be searched by the launcher - py.ini in the current user’s "application data" directory (i.e. the directory returned by calling the Windows function SHGetFolderPath with CSIDL_LOCAL_APPDATA) and py.ini in the same directory as the launcher. to Two .ini files will be searched by the launcher - py.ini in the current user’s "application data" directory (i.e. the directory returned by executing `echo %LOCALAPPDATA%` in a command window) and py.ini in the same directory as the launcher. 'Two .ini files will be searched by the launcher' sort of implies to me that the files exist. On my Win7 machine, echo %LOCALAPPDATA% returns C:\Users\Terry\AppData\Local. If I go to Users/Terry with Explorer, there is no AppData. (Same with admin user.) C:\Windows contains py(w).exe, but no py.ini. Clearer would be The launcher will search for py.ini in two possible places -- first in the same directory as the launcher; second in the current user's "application data" directory . I am pretty sure that order is important and that my version, not the current version, is correct. -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] py.ini documentation improvement
Quoting Terry Reedy : 'Two .ini files will be searched by the launcher' sort of implies to me that the files exist. On my Win7 machine, echo %LOCALAPPDATA% returns C:\Users\Terry\AppData\Local. If I go to Users/Terry with Explorer, there is no AppData. (Same with admin user.) Are you sure about this? What happens if you type "%LOCALAPPDATA%" (without quotes) into the explorer's address bar? Regards, Martin ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] py.ini documentation improvement
On 11/28/2013 5:35 PM, [email protected] wrote: Quoting Terry Reedy : 'Two .ini files will be searched by the launcher' sort of implies to me that the files exist. On my Win7 machine, echo %LOCALAPPDATA% returns C:\Users\Terry\AppData\Local. If I go to Users/Terry with Explorer, there is no AppData. (Same with admin user.) I initially intended to write "there is no AppData *visible*". Then I switched to my win7 admin account and there was still no AppData visible, for any user. This is unlike with XP where things not visible to 'users' become visible as admin. What happens if you type "%LOCALAPPDATA%" (without quotes) into the explorer's address bar? It displays C:\Users\Terry\AppData\Local on the bar and the contents in the box below. The py.ini doc might mention this as a way to get there. Thanks. -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] py.ini documentation improvement
On 29 November 2013 10:59, Terry Reedy wrote: > On 11/28/2013 5:35 PM, [email protected] wrote: > >> >> Quoting Terry Reedy : >> >> 'Two .ini files will be searched by the launcher' sort of implies to >>> me that the files exist. On my Win7 machine, echo %LOCALAPPDATA% >>> returns C:\Users\Terry\AppData\Local. If I go to Users/Terry with >>> Explorer, there is no AppData. (Same with admin user.) >>> >> > I initially intended to write "there is no AppData *visible*". Then I > switched to my win7 admin account and there was still no AppData visible, > for any user. This is unlike with XP where things not visible to 'users' > become visible as admin. By default in Win7 AppData is a hidden folder - you need to go to Tools | Folder Options | View | Show hidden files, folders and drives to see it in Explorer (no matter what user you're logged in as). If the py.ini location does become defined in terms of %LOCALAPPDATA% then suggesting to use that value in the Explorer address bar would probably be the easiest way for people to get to the correct directory. Tim Delaney ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] py.ini documentation improvement
On 11/28/2013 7:06 PM, Tim Delaney wrote: By default in Win7 AppData is a hidden folder - you need to go to Tools On my system, that is Control Panel, not Tools. | Folder Options | View | Show hidden files, folders and drives to see it in Explorer (no matter what user you're logged in as). Thanks, done (and another desired change made also). If the py.ini location does become defined in terms of %LOCALAPPDATA% then suggesting to use that value in the Explorer address bar would probably be the easiest way for people to get to the correct directory. -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] py.ini documentation improvement
On 29 November 2013 13:17, Terry Reedy wrote: > On 11/28/2013 7:06 PM, Tim Delaney wrote: > > By default in Win7 AppData is a hidden folder - you need to go to Tools >> > > On my system, that is Control Panel, not Tools. Sorry - was referring to the Explorer "Tools" menu, which is likewise hidden by default ... so many things that I change from the defaults when setting up a Windows machine - it's become so automatic that I forget what is hidden from most users. Tim Delaney ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] py.ini documentation improvement
On 29 November 2013 12:27, Tim Delaney wrote: > On 29 November 2013 13:17, Terry Reedy wrote: >> >> On 11/28/2013 7:06 PM, Tim Delaney wrote: >> >>> By default in Win7 AppData is a hidden folder - you need to go to Tools >> >> >> On my system, that is Control Panel, not Tools. > > > Sorry - was referring to the Explorer "Tools" menu, which is likewise hidden > by default ... so many things that I change from the defaults when setting > up a Windows machine - it's become so automatic that I forget what is hidden > from most users. Turning my Windows gaming machine back to the default settings and trying to bootstrap pip was one of the key things that got me motivated to work on PEP 453. It still astounds me that one company can both create Visual Studio, *and* make it difficult to configure a machine to be suitable for software development, but I guess that's enterprise companies for you :) Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] py.ini documentation improvement
Nick Coghlan writes: > Turning my Windows gaming machine back to the default settings and > trying to bootstrap pip was one of the key things that got me > motivated to work on PEP 453. It still astounds me that one company > can both create Visual Studio, *and* make it difficult to configure a > machine to be suitable for software development, but I guess that's > enterprise companies for you :) Those of us who study management for a living are definitely not surprised. I recommend Robert Townsend's "Call Yourself Up" from _Up the Organization_: he advises CEOs to ring up the company's toll-free number and find out what the customers deal with. Urk! This is the "same s---, different dept", that's all. And it's a lot harder to avoid than most folks think. Kudos to Nick for "calling himself up", to python-dev for creating a language and development ecology with so few unnecessary barriers, and to Guido for setting the tone! ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
