[Python-Dev] Re: why is not 64-bit installer the default download link for Windows?
On Tue, Jun 18, 2019 at 9:37 PM Steve Dower wrote: > On 18Jun2019 1025, Stephen J. Turnbull wrote: > > Oleg Broytman writes: > > > On Tue, Jun 18, 2019 at 10:09:59AM -, smartmanoj42...@gmail.com > wrote: > > > > > > Why don't we check the architecture using js and provide the > > > > appropriate version? > > > > > >Because the downloading computer is not necessary the installation > > > target. > > > > Sure, but (a) it's a good bet, and (b) somebody downloading to install > > on a different machine is more likely to know what they're doing and > > be conscious of issues of platform. > > Equally, someone more conscious of the issues will know to go and get > the 64-bit version if they explicitly want it. But for practically > everyone the 32-bit version will be just fine. > > There's no definitive answer to this, which means regardless of which > decision we make we will have to continue to explain it over and over > again. Right now, status quo and the lack of a volunteer to update the > web site means that sticking with the 32-bit link is easier to explain > than having to figure out why a particular machine was offered a > particular download when it is not correct. > I just posted a webmaster reply about just such an inquiry. As one of the people who get to do the explaining, it would be nice if we (not the devs) could figure out some way of getting people to the download they want. The lack of volunteers to update the web site content is disappointing, but a fact of open source life. Personally I'd have thought that the PSF was now spending enough on infrastructure that it might be able to afford someone to maintain the content - especially those areas that most impact the dev team. I imagine some assistance for release managers would also be helpful. Is it worth trying to make this happen? regards Steve ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/I6ZRZKA6HOP4GYR5KQIYXM7A5L3ADCEC/
[Python-Dev] Re: why is not 64-bit installer the default download link for Windows?
On 19Jun2019 0124, Steve Holden wrote: I just posted a webmaster reply about just such an inquiry. As one of the people who get to do the explaining, it would be nice if we (not the devs) could figure out some way of getting people to the download they want. Probably the easiest thing to do is to add a static link below the big download button that goes to the current release page and is labelled "64-bit and other downloads". Right now, the only alternative is to go to the full list of releases. Cheers, Steve ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/JRCHXPKBRW66MZQG7KB7TLDNRRTUTE7I/
[Python-Dev] Re: why is not 64-bit installer the default download link for Windows?
On Tue, 18 Jun 2019 13:36:33 -0700 Steve Dower wrote: > On 18Jun2019 1025, Stephen J. Turnbull wrote: > > Oleg Broytman writes: > > > On Tue, Jun 18, 2019 at 10:09:59AM -, smartmanoj42...@gmail.com > > wrote: > > > > > > Why don't we check the architecture using js and provide the > > > > appropriate version? > > > > > >Because the downloading computer is not necessary the installation > > > target. > > > > Sure, but (a) it's a good bet, and (b) somebody downloading to install > > on a different machine is more likely to know what they're doing and > > be conscious of issues of platform. > > Equally, someone more conscious of the issues will know to go and get > the 64-bit version if they explicitly want it. The main download button doesn't say anything about being 32-bit. So unless you *know* that you're going to be given the 32-bit version, you'll blindly download and install it. When coming from a non-Windows OS it is weird and unexpected to be given a 32-bit version by default. (this just happened to me, incidentally) Regards Antoine. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/UFZWIWAAHN4TPD56VWNHMWTMWXMGBOUQ/
[Python-Dev] bug(?) - unexpected frames being skipped in extract_stack with closures
all,
I'm writing a function meant to print out the context of a given
function call when executed - for example:
1. def main():
2.
3. _st = stack_trace_closure("/path/to/log")
4. _st()
5. _st()
would print out
/path/to/file.py:4
/path/to/file.py:5
for each line when executed. Basic idea is to create a closure and
associate that closure with a filename, then run that closure to print
to the log without needing to give the filename over and over again.
So far so good. But when I write this function, the frames given by
getframeinfo or extract_stack skip the actual calling point of the
function, instead giving back the *point where the closure was
defined*. (in the above example, it would print /path/to/file.py:3,
/path/to/file.py:3 instead of incrementing to show 4 and 5).
However, when I insert a pdb statement, it gives me the expected
calling frame where _st is actually called.
What's going on here? It looks an awful lot like a bug to me, like an
extra frame is being optimized out of of the closure's stack
prematurely.
I've tried this in python2.7 and python3.3, both show this.
thanks much for any info,
Ed
code follows:
---
def stack_trace_closure(message, file_name=None, frame=3):
fh = open(file_name, "w+")
def _helper():
return stack_trace(message, frame, fh)
return _helper
def stack_trace(message _frame, fh):
_bt = traceback.extract_stack()
fh.write( "%s:%s - %s" % (_bt[_frame][0], _bt[_frame][1], _message))
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/4MKHPCRNAJACKIBMLILMQMUPTEVFD3HW/
