Re: [Python-Dev] Fwd: Download Page - AMD64
On 13/01/2010 06:11, "Martin v. Löwis" wrote: How about: * Python 2.6.4 Windows X86-64 installer (Windows AMD64 / Intel 64 / X86-64 binary -- does not include source) instead of: * Python 2.6.4 Windows AMD64 installer (Windows AMD64 binary -- does not include source) -1. AMD doesn't want us to use the term x86-64 anymore, but wants us to use AMD64 instead. I think we should comply - they invented the architecture, so they have the right to give it a name. Neither Microsoft nor Intel have such a right. I think we should use whatever is most informative and least confusing to our users - we owe our allegiance to them and not to a processor vendor. Michael Regards, Martin -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [RELEASED] Python 2.7 alpha 2
Michael Foord wrote: > I agree with Martin that the *perception* is that to use Python 2.6 to > help you port to Python 3 you have to be willing to drop support for > earlier versions of Python. Note that increased 3.x compatibility in the most recent 2.x release will always help in two scenarios: 1. New projects that want to use 2.x only libraries but want to be ready for the Py3k transition in their own code (e.g. new 2.7 features like set literals, dict and set comprehensions and the view* dict methods can be translated far more cleanly by 2to3 than the closest comparable 2.6 code). 2. Similarly new projects that use a 3.x trunk can be more readily translated to a 2.7 version with 3to2, whereas some constructs may be difficult to recreate in earlier Python versions. I would expect this to be significantly less common then the first scenario though. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Download Page - AMD64
Antoine Pitrou wrote: > Christian Heimes cheimes.de> writes: >> How about: >> >> * Python 2.6.4 Windows X86-64 installer (Windows AMD64 / Intel 64 / >> X86-64 binary -- does not include source) > > +1. I don't care about trademarks or official names, we should call it > whatever > is obvious for our users. Until this discussion, I didn't even know the architecture had any name other than x86-64. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [RELEASED] Python 2.7 alpha 2
Tres Seaver wrote: > There is an obnoxious deprecation warning out of the distutils: > > DeprecationWarning: 'compiler' specifies the compiler type in > build_ext. If you want to get the compiler object itself, use > 'compiler_obj' > > which is likely a simple one-line fix, if I only knew what the hell it > was whining about. ;) The warning is extra obnoxious because it doesn't > tell me what in *my* code triggers the warning (it (needs a 'stacklevel' > argument). Could you kick a tracker issues in Tarek's direction for that one? Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] topics I plan to discuss at the language summit
Brett Cannon python.org> writes: > If there is something missing from the stdlib discussion that you think should be brought up at the summit let me know. And if there is something here you want to discuss before the summit let me know and I can start a separate thread on it. I'm sorry I won't be able to come to the language summit, but I would like if possible to expedite a pronouncement on PEP 391 (configuring logging using dictionaries). I believe I addressed all the comments made on the discussion threads mentioned in the PEP and so I'm not sure what more I need to do to get a pronouncement. I guess the stdlib slot gives an opportunity for people to air their views and so I'd be grateful if you added it to the agenda. Thanks & regards, Vinay Sajip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Download Page - AMD64
On Wed, Jan 13, 2010 at 00:11, "Martin v. Löwis" wrote: > -1. AMD doesn't want us to use the term x86-64 anymore, but wants us > to use AMD64 instead. I think we should comply - they invented the > architecture, so they have the right to give it a name. Neither > Microsoft nor Intel have such a right. I see and agree with the motivation behind your point, but it's just as reasonable to mimic the name Microsoft uses: the release is for Windows rather than the processor. On MSDN Microsoft uses parentheticals x86, ia64 and x64; this would suggest a name like Python 2.6.4 installer for Windows (x64). Unfortunately this usage doesn't seem to be reflected in consumer-oriented product pages, so I'm uncertain how clear it is for those downloading Python. -- Michael Urman ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Download Page - AMD64
Michael Urman wrote: > On Wed, Jan 13, 2010 at 00:11, "Martin v. Löwis" wrote: >> -1. AMD doesn't want us to use the term x86-64 anymore, but wants us >> to use AMD64 instead. I think we should comply - they invented the >> architecture, so they have the right to give it a name. Neither >> Microsoft nor Intel have such a right. > > I see and agree with the motivation behind your point, but it's just > as reasonable to mimic the name Microsoft uses: the release is for > Windows rather than the processor. On MSDN Microsoft uses > parentheticals x86, ia64 and x64; this would suggest a name like > Python 2.6.4 installer for Windows (x64). Unfortunately this usage > doesn't seem to be reflected in consumer-oriented product pages, so > I'm uncertain how clear it is for those downloading Python. As Windows doesn't run on non-x86 architectures, their naming is generally just Windows (32 bit) and Windows (64 bit). Linux, on the other hand, can run on multiple 64 bit architectures, so being more specific and using the official AMD64 nomenclature makes sense. In this case, making it clear that the 64-bit Windows binaries work for both Intel and AMD chips is more important than using only the official architecture name. Cheers, Nick. P.S. This discussion made me realise that out of habit I had dropped the 32-bit version of Python on my new 64-bit Windows box... -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [RELEASED] Python 2.7 alpha 2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Nick Coghlan wrote: > Tres Seaver wrote: >> There is an obnoxious deprecation warning out of the distutils: >> >> DeprecationWarning: 'compiler' specifies the compiler type in >> build_ext. If you want to get the compiler object itself, use >> 'compiler_obj' >> >> which is likely a simple one-line fix, if I only knew what the hell it >> was whining about. ;) The warning is extra obnoxious because it doesn't >> tell me what in *my* code triggers the warning (it (needs a 'stacklevel' >> argument). > > Could you kick a tracker issues in Tarek's direction for that one? Done: http://bugs.python.org/issue7694 Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAktN+bMACgkQ+gerLs4ltQ6s4gCdENhtVQWzoH449BCDz8SNx/4s DEoAn19LMcMs3b6ctdNF8K2hYd6d+BSZ =TWit -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PYTHON3PATH
Please review issue 2375 [1], which is an enhancement request to add a PYTHON3PATH environment variable. Because we have elected to have both a python and a python3 command, I think this is an issue worth thinking about carefully to make sure we are serving the Python user community and easing the transition to python3. It could be that "use virtualenv" is the best answer, but I feel we should think about it carefully to make sure that is really true. [1] http://bugs.python.org/issue2375 -- R. David Murray www.bitdance.com Business Process Automation - Network/Server Management - Routers/Firewalls ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PYTHON3PATH
Somehow the bug site doesn't load for me right now, but I'm -1 on this. There are maybe a dozen PYTHON... variables -- we really shouldn't try to add PYTHON3 variants for all of them. Specifically for PYTHONPATH, I feel that its use is always a short-time or localized hack, not something you set in your .profile nd forget about it (forgetting about it inparticular often leads to unnecessary debugging pain later). The better approaches are based on site-packages, wrapper scripts, virtualenv, etc. --Guido On Wed, Jan 13, 2010 at 9:24 AM, R. David Murray wrote: > Please review issue 2375 [1], which is an enhancement request to add a > PYTHON3PATH environment variable. Because we have elected to have both > a python and a python3 command, I think this is an issue worth thinking > about carefully to make sure we are serving the Python user community > and easing the transition to python3. It could be that "use virtualenv" > is the best answer, but I feel we should think about it carefully to > make sure that is really true. > > [1] http://bugs.python.org/issue2375 > > -- > R. David Murray www.bitdance.com > Business Process Automation - Network/Server Management - Routers/Firewalls > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [RELEASED] Python 2.7 alpha 2
On Sat, Jan 9, 2010 at 18:29, Benjamin Peterson wrote: > Please consider trying Python 2.7 with your code and reporting any bugs you > may I ran the Mercurial test suite on current trunk, and it worked alright. There was a small issue with the fact that mimetypes got fooled by the lack of ImportError from _winreg (which I solved by blacklisting _winreg in demandimport), and one test fails likely because of a change in MIME handling. Will look into that. So the state of trunk looks rather solid from where I sit. Cheers, Dirkjan ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PYTHON3PATH
"R. David Murray" writes: > Please review issue 2375 [1], which is an enhancement request to add a > PYTHON3PATH environment variable. Because we have elected to have both > a python and a python3 command, I think this is an issue worth thinking > about carefully to make sure we are serving the Python user community > and easing the transition to python3. It could be that "use virtualenv" > is the best answer, but I feel we should think about it carefully to > make sure that is really true. > > [1] http://bugs.python.org/issue2375 The first thing I got while trying to run a python3 prompt few days ago, was an error. python3 tried to read my $PYTHONSTARTUP file, which used print statements. people will have to run both python 2 and python 3 code at the same time. Using different environment variables will make this easier. - Ralf ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PYTHON3PATH
Guido van Rossum writes: > Somehow the bug site doesn't load for me right now, but I'm -1 on > this. There are maybe a dozen PYTHON... variables -- we really > shouldn't try to add PYTHON3 variants for all of them. > > Specifically for PYTHONPATH, I feel that its use is always a > short-time or localized hack, not something you set in your .profile > nd forget about it (forgetting about it inparticular often leads to > unnecessary debugging pain later). The better approaches are based on > site-packages, wrapper scripts, virtualenv, etc. then at least remove them completely from python3, so one can use them for his python 2 installation. Otherwise it will stump on some innocent python 3 program (and cause unnecessary debugging pain). ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PYTHON3PATH
On Wed, Jan 13, 2010 at 9:40 AM, Ralf Schmitt wrote: > "R. David Murray" writes: > >> Please review issue 2375 [1], which is an enhancement request to add a >> PYTHON3PATH environment variable. Because we have elected to have both >> a python and a python3 command, I think this is an issue worth thinking >> about carefully to make sure we are serving the Python user community >> and easing the transition to python3. It could be that "use virtualenv" >> is the best answer, but I feel we should think about it carefully to >> make sure that is really true. >> >> [1] http://bugs.python.org/issue2375 > > The first thing I got while trying to run a python3 prompt few days ago, > was an error. python3 tried to read my $PYTHONSTARTUP file, which used > print statements. people will have to run both python 2 and python 3 > code at the same time. Using different environment variables will make > this easier. How complicated is your PYTHONSTARTUP file? My suspicion is that you could easily write it to work for both Python 2.X and 3.X. Steve -- Where did you get that preposterous hypothesis? Did Steve tell you that? --- The Hiphopopotamus ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PYTHON3PATH
On Jan 13, 2010, at 12:40 PM, Ralf Schmitt wrote: > "R. David Murray" writes: > >> Please review issue 2375 [1], which is an enhancement request to add a >> PYTHON3PATH environment variable. Because we have elected to have both >> a python and a python3 command, I think this is an issue worth thinking >> about carefully to make sure we are serving the Python user community >> and easing the transition to python3. It could be that "use virtualenv" >> is the best answer, but I feel we should think about it carefully to >> make sure that is really true. >> >> [1] http://bugs.python.org/issue2375 > > The first thing I got while trying to run a python3 prompt few days ago, > was an error. python3 tried to read my $PYTHONSTARTUP file, which used > print statements. people will have to run both python 2 and python 3 > code at the same time. Using different environment variables will make > this easier. Or, how about just removing the antiquated use of environment variables altogether from Python 3 and avoid the issue completely. Python 2 will continue to run as it has, and better solutions will emerge for Python 3 development. Beats the heck out of making a whole duplicate set for PYTHON3BLAHBLAH, yuck! S ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] regex module
Memories of days past... Python had several regular expression implementations before, one of which was called "regex". But I would rather not have a new module -- I would much rather have a flag specifying the new (backwards incompatible) syntax/semantics. The flag would have a long name (e.g. re.NEW_SYNTAX), a short name (e.g. re.N) and an inline syntax, "(?n)...". --Guido On Tue, Jan 12, 2010 at 7:58 PM, Brett Cannon wrote: > > > On Tue, Jan 12, 2010 at 14:10, MRAB wrote: >> >> Hi all, >> >> I'm back on the regex module after doing other things and I'd like your >> opinion on a number of matters: >> >> Firstly, the current re module has a bug whereby it doesn't split on >> zero-width matches. The BDFL has said that this behaviour should be >> retained by default in case any existing software depends on it. My >> question is: should my regex module still do this for Python 3? >> Speaking personally, I'd like it to behave correctly, and Python 3 is >> the version where backwards-compatibility is allowed to be broken. >> > > If it is a separate module under a different name it can do the proper > thing. People will just need to be aware of the difference when they import > the module. > >> >> Secondly, Python 2 is reaching the end of the line and Python 3 is the >> future. Should I still release a version that works with Python 2? I'm >> thinking that it could be confusing if new regex module did zero-width >> splits correctly in Python 3 but not in Python 2. And also, should I >> release it only for Python 3 as a 'carrot'? >> > > That's totally up to you. There is practically no chance of it getting into > the 2.x under the stdlib at this point since 2.7b1 is coming up and this > module has not been out in the wild for a year (to my knowledge). If you > want to support 2.x that's fine and I am sure users would appreciate it, but > it isn't necessary to get into the Python 3 stdlib. > >> >> Finally, the module allows some extra backslash escapes, eg \g, in >> the pattern. Should it treat ill-formed escapes, eg \g, as it would have >> treated them in the re module? >> > > If you want to minimize the differences then it should probably match. As I > said, since it is a different name to import under it can deviate where > reasonable, just make sure to clearly document the deviations. > -Brett > >> >> Thanks >> ___ >> Python-Dev mailing list >> Python-Dev@python.org >> http://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: >> http://mail.python.org/mailman/options/python-dev/brett%40python.org > > > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > > -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PYTHON3PATH
Steven Bethard writes: > > How complicated is your PYTHONSTARTUP file? My suspicion is that you > could easily write it to work for both Python 2.X and 3.X. sure. that's exactly what I did. My point is that sharing those environment variables will cause pain for some people. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PYTHON3PATH
On Wed, Jan 13, 2010 at 9:57 AM, sstein...@gmail.com > Or, how about just removing the antiquated use of environment variables altogether from Python 3 and avoid the issue completely. -1. They have their use, but more in controlled situations. If you have "global" env vars that you only want to use with Python 2.x, write a wrapper for Python 3 that invokes it with -E. -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Download Page - AMD64
On 1/13/2010 9:04 AM, Nick Coghlan wrote: > As Windows doesn't run on non-x86 architectures, their naming is > generally just Windows (32 bit) and Windows (64 bit). That is not correct. There are IA-64 versions of Window Server. >From [1]: "Backward compatibility is a key point differentiating Itanium from x86 and x64 architectures." So to echo what Michael said, the Microsoft nomenclature is "x64" regardless of yours and Martin's objections to that name. Nobody who uses Windows would be confused by "x64" since that is *the* Microsoft naming scheme. And, anyone using IA64 will expect to see "IA64" and not "x64", and furthermore anyone using IA64 is likely aware of what processor they are using (being as there are only Windows Server editions for IA64) and the difference between "IA64" and "x64". I don't think an end-user facing page is a great place for pedantic and wordy defenses of defying the Microsoft-blessed naming scheme. > Linux, on the other hand, can run on multiple 64 bit architectures, so > being more specific and using the official AMD64 nomenclature makes > sense. This has no relevance to the conversation since there are no Linux binaries being distributed. The conversation on the expectations of Windows end-users, who are the target of the download links. [1] http://www.microsoft.com/servers/64bit/itanium/overview.mspx -- Scott Dial sc...@scottdial.com scod...@cs.indiana.edu ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] topics I plan to discuss at the language summit
On Wed, Jan 13, 2010 at 4:24 AM, Vinay Sajip wrote: > Brett Cannon python.org> writes: > >> If there is something missing from the stdlib discussion that you think >> should > be brought up at the summit let me know. And if there is something here you > want > to discuss before the summit let me know and I can start a separate thread on > it. > > I'm sorry I won't be able to come to the language summit, but I would like if > possible to expedite a pronouncement on PEP 391 (configuring logging using > dictionaries). I believe I addressed all the comments made on the discussion > threads mentioned in the PEP and so I'm not sure what more I need to do to > get a > pronouncement. I guess the stdlib slot gives an opportunity for people to air > their views and so I'd be grateful if you added it to the agenda. Is the PEP in the stage of consensus yet? If so it may not even be necessary to discuss it at the summit (though I certainly won't stop people if they want to). -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PYTHON3PATH
On Wed, Jan 13, 2010 at 12:57:42PM -0500, sstein...@gmail.com wrote: > Or, how about just removing the antiquated use of environment variables "antiquated"? You are kidding, aren't you?! Oleg. -- Oleg Broytmanhttp://phd.pp.ru/p...@phd.pp.ru Programmers don't die, they just GOSUB without RETURN. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PyCon Keynote
Please mail me topics you'd like to hear me talk about in my keynote at PyCon this year. -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Download Page - AMD64
>>> * Python 2.6.4 Windows X86-64 installer (Windows AMD64 / Intel 64 / >>> X86-64 binary -- does not include source) >>> >>> instead of: >>> >>> * Python 2.6.4 Windows AMD64 installer (Windows AMD64 binary -- does >>> not include source) >>> >> -1. AMD doesn't want us to use the term x86-64 anymore, but wants us >> to use AMD64 instead. I think we should comply - they invented the >> architecture, so they have the right to give it a name. Neither >> Microsoft nor Intel have such a right. >> > > I think we should use whatever is most informative and least confusing > to our users - we owe our allegiance to them and not to a processor vendor. And why do you think this is x86-64? Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [RELEASED] Python 2.7 alpha 2
> Note that increased 3.x compatibility in the most recent 2.x release > will always help in two scenarios: > > 1. New projects that want to use 2.x only libraries but want to be ready > for the Py3k transition in their own code (e.g. new 2.7 features like > set literals, dict and set comprehensions and the view* dict methods can > be translated far more cleanly by 2to3 than the closest comparable 2.6 > code). Of these, I can only see this being the case of the view* methods. Why would set literals allow for code that more cleanly translates to 3.x? Suppose you write f = set((1,2,3)) in 2.6. That code will work *exactly* the same way in 3.1, no translation needed at all. Likewise for dict and set comprehensions: the code is as cleanly translated in the 2.7 form as it is in any prior form (ie. no modifications). As for view* methods: there is one important exception where the 2.6 equivalent is as cleanly translated as a view method: for key in D: action This is a more modern equivalent for iterating over D.keys(), so if your code still does the latter, just change it to the former (requires Python 2.2). I'd claim that this is the dominant case of traversing a dictionary (probably followed by iterating over .items()). So while it is true that only view* can be transformed correctly, I'd claim that this is an infrequent issue. > 2. Similarly new projects that use a 3.x trunk can be more readily > translated to a 2.7 version with 3to2, whereas some constructs may be > difficult to recreate in earlier Python versions. That may be true, but is besides the point here: the issue was whether a 2.8 release might help in migrating to 3.x. People who follow this approach already have 3.x code. Whether they would rather port to 2.8 only, and get that work with little effort, or whether they would port to 2.5 and later, and put in more work, I don't know - I guess we would have to ask these people. I would expect that they prefer if 2.x died rather sooner than later, because they can then stop supporting it. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Download Page - AMD64
On 1/13/2010 2:13 PM, "Martin v. Löwis" wrote: I think we should use whatever is most informative and least confusing to our users - we owe our allegiance to them and not to a processor vendor. And why do you think this is x86-64? I do not believe I have personally seen, or at least noticed, that specific term before. Something like "Release for 64-bit Windows (Win NT, 2000, XP, Vista, 7 correct list is>) on AMD64-type processors from AMD and Intel" should be clear enough. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Download Page - AMD64
> As Windows doesn't run on non-x86 architectures, their naming is > generally just Windows (32 bit) and Windows (64 bit). Windows actually does - it runs on IA-64 (which is a non-x86 architecture). However, end users are unlikely to use such hardware, so distinguishing between 32-bit and 64-bit is typically good enough. > In this case, making it clear that the 64-bit Windows binaries work for > both Intel and AMD chips is more important than using only the official > architecture name. Well, we did have Itanium binaries at one point, and the "64-bit Windows binaries" you are referring to most definitely don't run on Itanium, even though that's an Intel chip. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Download Page - AMD64
> So to echo what Michael said, the Microsoft nomenclature is "x64" > regardless of yours and Martin's objections to that name. Nobody who > uses Windows would be confused by "x64" since that is *the* Microsoft > naming scheme. That's actually not entirely true. There are several places in the APIs where Microsoft either allows or requires to call the architecture AMD64 (e.g. architecture indication in MSI files). Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PYTHON3PATH
On Wed, Jan 13, 2010 at 18:40, Ralf Schmitt wrote: > The first thing I got while trying to run a python3 prompt few days ago, > was an error. python3 tried to read my $PYTHONSTARTUP file, which used > print statements. people will have to run both python 2 and python 3 > code at the same time. Using different environment variables will make > this easier. What do you need to do in the PYTHONSTARTUP file? Ten years of Python programming, and I didn't even know it existed. :-) -- Lennart Regebro: http://regebro.wordpress.com/ Python 3 Porting: http://python-incompatibility.googlecode.com/ +33 661 58 14 64 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PYTHON3PATH
On Wed, Jan 13, 2010 at 08:50:59PM +0100, Lennart Regebro wrote: > What do you need to do in the PYTHONSTARTUP file? > Ten years of Python programming, and I didn't even know it existed. :-) See http://phd.pp.ru/Software/dotfiles/init.py.html for an example. Oleg. -- Oleg Broytmanhttp://phd.pp.ru/p...@phd.pp.ru Programmers don't die, they just GOSUB without RETURN. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Download Page - AMD64
On Wed, Jan 13, 2010 at 13:45, "Martin v. Löwis" wrote: >> So to echo what Michael said, the Microsoft nomenclature is "x64" >> regardless of yours and Martin's objections to that name. Nobody who >> uses Windows would be confused by "x64" since that is *the* Microsoft >> naming scheme. > > That's actually not entirely true. There are several places in the > APIs where Microsoft either allows or requires to call the architecture > AMD64 (e.g. architecture indication in MSI files). I should have clarified I was talking about the names shown on MSDN subscriptions for downloading installation media of Windows 7 and Windows Vista. It's pretty clear in that context Microsoft uses x64 to describe this platform of Windows. But again, it's far from clear that this is a term they use for non-developers. -- Michael Urman ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PYTHON3PATH
On Wed, Jan 13, 2010 at 21:08, Oleg Broytman wrote: > On Wed, Jan 13, 2010 at 08:50:59PM +0100, Lennart Regebro wrote: >> What do you need to do in the PYTHONSTARTUP file? >> Ten years of Python programming, and I didn't even know it existed. :-) > > See http://phd.pp.ru/Software/dotfiles/init.py.html for an example. Cheese and fries! :-) Anyway, I don't see how this could pose any problems, because any user advanced enough to do these things will be advanced enough to understand what the problem is and fix it so it works under Python 3 too. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PYTHON3PATH
Lennart Regebro writes:
> On Wed, Jan 13, 2010 at 18:40, Ralf Schmitt wrote:
>> The first thing I got while trying to run a python3 prompt few days ago,
>> was an error. python3 tried to read my $PYTHONSTARTUP file, which used
>> print statements. people will have to run both python 2 and python 3
>> code at the same time. Using different environment variables will make
>> this easier.
>
> What do you need to do in the PYTHONSTARTUP file?
> Ten years of Python programming, and I didn't even know it existed. :-)
hehe. tab completion:
# -*- mode: python -*-
# Last changed: 2009-12-23 22:25:15 by ralf
import sys
import os
def initreadline():
try:
import readline
except ImportError:
sys.stdout.write("Module readline not available.\n")
return
import rlcompleter
readline.parse_and_bind("tab: complete")
# Use tab for completions
readline.parse_and_bind('tab: complete')
# This forces readline to automatically print the above list when tab
# completion is set to 'complete'.
readline.parse_and_bind('set show-all-if-ambiguous on')
# Bindings for incremental searches in the history. These searches
# use the string typed so far on the command line and search
# anything in the previous input history containing them.
readline.parse_and_bind('"\C-r": reverse-search-history')
readline.parse_and_bind('"\C-s": forward-search-history')
history = os.path.expanduser("~/.pyhistory")
if os.path.exists(history):
readline.read_history_file(history)
import atexit
atexit.register(lambda: readline.write_history_file(history))
initreadline()
del initreadline
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PYTHON3PATH
Lennart Regebro wrote: > On Wed, Jan 13, 2010 at 18:40, Ralf Schmitt wrote: >> The first thing I got while trying to run a python3 prompt few days ago, >> was an error. python3 tried to read my $PYTHONSTARTUP file, which used >> print statements. people will have to run both python 2 and python 3 >> code at the same time. Using different environment variables will make >> this easier. > > What do you need to do in the PYTHONSTARTUP file? I personally set up readline: set tab completion, and load the history of commands from the previous session. Of course, I don't know what Ralf uses it for. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PYTHON3PATH
Guido van Rossum wrote: > On Wed, Jan 13, 2010 at 9:57 AM, sstein...@gmail.com > Or, how about > just removing the antiquated use of environment variables altogether > from Python 3 and avoid the issue completely. > > -1. They have their use, but more in controlled situations. If you > have "global" env vars that you only want to use with Python 2.x, > write a wrapper for Python 3 that invokes it with -E. Perhaps a case can be made for Python 3 to assume -E by default, with a -e option to enable reading of the environment variables? That way naive users could run Python3 without tripping over existing Python2 environment variables, while other tools could readily set up a different environment before launching Python3. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PYTHON3PATH
On Wed, Jan 13, 2010 at 1:43 PM, Nick Coghlan wrote: > Guido van Rossum wrote: >> On Wed, Jan 13, 2010 at 9:57 AM, sstein...@gmail.com > Or, how about >> just removing the antiquated use of environment variables altogether >> from Python 3 and avoid the issue completely. >> >> -1. They have their use, but more in controlled situations. If you >> have "global" env vars that you only want to use with Python 2.x, >> write a wrapper for Python 3 that invokes it with -E. > > Perhaps a case can be made for Python 3 to assume -E by default, with a > -e option to enable reading of the environment variables? > > That way naive users could run Python3 without tripping over existing > Python2 environment variables, while other tools could readily set up a > different environment before launching Python3. Naive users using environment variables? That's a recipe for disaster in any version! :-) -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PYTHON3PATH
On 13 Jan 2010, at 13:43, Nick Coghlan wrote: > Guido van Rossum wrote: >> On Wed, Jan 13, 2010 at 9:57 AM, sstein...@gmail.com > Or, how about >> just removing the antiquated use of environment variables altogether >> from Python 3 and avoid the issue completely. >> >> -1. They have their use, but more in controlled situations. If you >> have "global" env vars that you only want to use with Python 2.x, >> write a wrapper for Python 3 that invokes it with -E. > > Perhaps a case can be made for Python 3 to assume -E by default, with a > -e option to enable reading of the environment variables? > > That way naive users could run Python3 without tripping over existing > Python2 environment variables, while other tools could readily set up a > different environment before launching Python3. I raised a question about these PYTHON3* variables once before in a discussion about shebang lines: http://www.mailinglistarchive.com/python-dev@python.org/msg29500.html I'm not advocating them, but just wanted to make sure to bring up the shebang use case. Jared ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PYTHON3PATH
Lennart> What do you need to do in the PYTHONSTARTUP file?
Just reading off stuff from my own personal startup file... I use it for
stuff I want available during interactive sessions:
1. Enable true division.
2. Conditionally define "help" from back in the days when there was no
help builtin function.
3. Auto-save session (readline) history so I can easily recall commands
across sessions.
4. Add other fake builtins ("like") or override behavior of some (like
"dir") making them handier for interactive use.
5. autoload modules/symbols (pokes around in common modules from
sys.excepthook function).
Oh, and I've had no particular trouble keeping it working in Python 1, 2 or
3.
Skip
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Download Page - AMD64
On 13/01/2010 19:13, "Martin v. Löwis" wrote: * Python 2.6.4 Windows X86-64 installer (Windows AMD64 / Intel 64 / X86-64 binary -- does not include source) instead of: * Python 2.6.4 Windows AMD64 installer (Windows AMD64 binary -- does not include source) -1. AMD doesn't want us to use the term x86-64 anymore, but wants us to use AMD64 instead. I think we should comply - they invented the architecture, so they have the right to give it a name. Neither Microsoft nor Intel have such a right. I think we should use whatever is most informative and least confusing to our users - we owe our allegiance to them and not to a processor vendor. And why do you think this is x86-64? Well anecdotal everyone I have *every* talked to about 64bit processors has referred to having a 64bit processor (x86 is a given) and not an AMD64 architecture processor. Linus Torvalds addressed this specific issue for Linux and came down on the side of "x86-64": http://kerneltrap.org/node/2466 Look up AMD64 on Wikipedia and it redirects you to the X86-64 page. Information website setup by AMD and partners about the AMD64 architecture: http://www.x86-64.org/about.html In the AMD website they refer to "x86-64 Assembly": http://www.x86-64.org/documentation/assembly.html Microsoft seem to draw a distinction between x64 (which would also be acceptable) and Itanium based systems. Very rarely do they refer to AMD64: * http://www.microsoft.com/servers/64bit/compare.mspx * http://www.microsoft.com/servers/64bit/x64/overview.mspx * http://www.microsoft.com/servers/64bit/overview.mspx Using a vendor specific name automatically begs the question as to whether the installer works on processors from other vendors, as we saw in the specific enquiry from the user that triggered this debate. Referring to the AMD 64 build as x86-64, with a footnote explaining which architectures this specifically means is unlikely to confuse people. It is *definitely* better than just saying AMD64. All the best, Michael Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] static (Modules/Setup) builds?
Just out of curiosity, is the static build stuff (use the old Modules/Setup file to build modules) exercised at all any more? Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] static (Modules/Setup) builds?
2010/1/13 : > > Just out of curiosity, is the static build stuff (use the old Modules/Setup > file to build modules) exercised at all any more? Exercised as in used in the build process? Yes. -- Regards, Benjamin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
