Re: [Python-Dev] New PEP
On Thu, Mar 22, 2012 at 00:39, Huan Do wrote: > Tell me what you guys think. I don't really want to add more things to the language, so I hate to say this: It makes sense to me. However, the syntax is very close to the syntax for function annotations. But that's when defining, and this is when calling, so it might work anyway, I don't have the knowledge necessary to know. So put it up on python-ideas. I'm not on that list, but people who know more about this are, so they can tell you if this is feasible or not and if it is a good idea or not. //Lennart ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] dictproxy for other mapping types than dict
Hi, I created the following issue to expose the dictproxy as a builtin type. http://bugs.python.org/issue14386 I would be interesting to accept any mapping type, not only dict. dictproxy implementation supports any mapping, even list or tuple, but I don't want to support sequences because a missing key would raise an IndexError instead of a KeyError. My problem is to check the type in C. issubclass(collections.ChainMap, collections.abc.Sequence) is False which is the expected result, so I need to implement this check in C. "The "PyMapping_Check(dict) && !PyMapping_Check(dict)" fails on ChainMap: type.__new__(ChainMap) fills tp_as_sequence->sq_item slot is defined because ChainMap has a __getitem__ method. Do you have an idea how to implement such test? Victor ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: Issue #7652: Integrate the decimal floating point libmpdec library to speed
Victor Stinner wrote: > >> Issue #7652: Integrate the decimal floating point libmpdec library to > >> speed > >> up the decimal module. Performance gains of the new C implementation are > >> between 12x and 80x, depending on the application. > > Congrats Stefan! And thanks for the huge chunk of code. Thanks, much appreciated. I'll take the opportunity to thank you in return for the gigantic amount of work you've done on Python in the past year! Stefan Krah ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: Issue #7652: Integrate the decimal floating point libmpdec library to speed
On Wed, Mar 21, 2012 at 23:22, Victor Stinner wrote: >>> http://hg.python.org/cpython/rev/730d5357 >>> changeset: 75850:730d5357 >>> user: Stefan Krah >>> date: Wed Mar 21 18:25:23 2012 +0100 >>> summary: >>> Issue #7652: Integrate the decimal floating point libmpdec library to speed >>> up the decimal module. Performance gains of the new C implementation are >>> between 12x and 80x, depending on the application. As a Python user, this looks really cool, thanks! As a packager, is the libmpdec library used elsewhere? For Gentoo, we generally prefer to package libraries separately and have Python depend on them. From the site, it seems like you more or less wrote libmpdec for usage in Python, but if it's general-purpose and actually used in other software, it would be nice if Python grew a configure option to make it use the system libmpdec. Cheers, Dirkjan ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python install layout and the PATH on win32 (Rationale part 1: Regularizing the layout)
As this has been brought up a couple times in this subthread, I figured
that I would lay out the rationale here.
There are two proposals on the table: 1) Regularize the install layout,
and 2) move the python binary to the binaries directory. This email will
deal with the first, and a second email will deal with the second.
1) Regularizing the install layout:
One of Python's strengths is its cross-platform appeal. Carefully-
written Python programs are frequently portable between operating
systems and Python implementations with very few changes. Over the
years, substantial effort has been put into maintaining platform
parity and providing consistent interfaces to available functionality,
even when different underlying implementations are necessary (such
as with ntpath and posixpath).
One place where Python is unnecessarily different, however, is in
the layout and organization of the Python environment. This is most
visible in the name of the directory for binaries on the Windows
platform ("Scripts") versus the name of the directory for binaries on
every other platform ("bin"), but a full listing of the layouts shows
substantial differences in layout and capitalization across platforms.
Sometimes the include is capitalized ("Include"), and sometimes not; and
the python version may or may not be included in the path to the
standard library or not.
This may seem like a harmless inconsistency, and if that were all it
was, I wouldn't care. (That said, cross-platform consistency is its own
good). But it becomes a real pain when combined with tools like
virtualenv or the new pyvenv to create cross-platform development
environments.
In particular, I regularly do development on both Windows and a Mac, and
then deploy on Linux. I do this in virtualenvs, so that I have a
controlled and regular environment. I keep them in sync using source
control.
The problem comes when I have executable scripts that I want to include
in my dvcs - I can't have it in the obvious place - the binaries
directory - because *the name of the directory changes when you move
between platforms.* More concretely, I can't hg add "Scripts/runner.py?
on my windows environment (where it is put in the PATH by virtualenv)
and thendo a pull on Mac or Linux and have it end up properly in
"bin/runner.py" which is the correct PATH for those platforms.
This applies anytime there are executable scripts that you want to
manage using source control across platforms. Django projects regularly
have these, and I suspect we will be seeing more of this with the new
"project" support in virtualenvwrapper.
While a few people have wondered why I would want this -- hopefully
answered above -- I have not heard any opposition to this part of the
proposal.
This first proposal is just to make the names of the directories match
across platforms. There are six keys defined in the installer files
(sysconfig.cfg and distutils.command.install): 'stdlib', 'purelib',
'platlib', 'headers', 'scripts', and 'data'.
Currently on Windows, there are two different layouts defined:
'nt': {
'stdlib': '{base}/Lib',
'platstdlib': '{base}/Lib',
'purelib': '{base}/Lib/site-packages',
'platlib': '{base}/Lib/site-packages',
'include': '{base}/Include',
'platinclude': '{base}/Include',
'scripts': '{base}/Scripts',
'data' : '{base}',
},
'nt_user': {
'stdlib': '{userbase}/Python{py_version_nodot}',
'platstdlib': '{userbase}/Python{py_version_nodot}',
'purelib': '{userbase}/Python{py_version_nodot}/site-packages',
'platlib': '{userbase}/Python{py_version_nodot}/site-packages',
'include': '{userbase}/Python{py_version_nodot}/Include',
'scripts': '{userbase}/Scripts',
'data' : '{userbase}',
},
The proposal is to make all the layouts change to:
'nt': {
'stdlib': '{base}/lib',
'platstdlib': '{base}/lib',
'purelib': '{base}/lib/site-packages',
'platlib': '{base}/lib/site-packages',
'include': '{base}/include',
'platinclude': '{base}/include',
'scripts': '{base}/bin',
'data' : '{base}',
},
The change here is that 'Scripts' will change to 'bin' and the
capitalization will be removed. Also, "user installs" of Python will
have the same internal layout as "system installs" of Python. This will
also, not coincidentally, match the install layout for posix, at least
with regard to the 'bin', 'lib', and 'include' directories.
Again, I have not heard *anyone* objecting to this part of the proposal
as it is laid out here. (Paul had a concern with the lib directory
earlier, but he said he was ok with the above).
Please let me know if you have any problems or concerns with this part 1.
Thanks,
Van
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python install layout and the PATH on win32 (Rationale part 2: Moving the python.exe)
[PART 2: Moving the python binary] There are two proposals on the table: 1) Regularize the install layout, and 2) move the python binary to the binaries directory. This email deals with the second issue exclusively. This has been the more contentious issue. 2) Moving the Python exe: A regular complaint of those new to Python on windows (and new to programming generally) has been that one of the first things that they need to do is to edit the PATH to allow Python to be run. In particular, this is the difficult sequence: 1. Install python. 2. Open up a shell and run "python" 3. Use pip or easy_install to install regetron (a package that installs an executable file). 4. Run regetron. For step #2, the python exe needs to be on the PATH. For steps 3 and 4, the binaries directory needs to be on the PATH. Currently, neither of these are true, so the path needs to be edited to include both the python root (where python.exe is, for step 2) and the "Scripts" (hopefully soon "bin") directory where "pip" and "regetron" are (for steps 3 and 4). You can substitute "regetron" for "nose," "cython," or other packages as well. MvL asked why anyone would want to run python directly from a cmd shell instead of running it from the start menu. There are two immediate responses to that: 1) observed behavior is that people prefer to run "python" from the cmd shell when developing (as observed by various people teaching Python, including Brian Curtin in this thread), and 2) running python or python programs from the shell is sometimes the only way to get a proper traceback when developing, making it a better way to work. The proposal here is to move the python.exe into the binaries directory (whatever it is called) and add an option to the windows installer to add that one directory to the PATH on install (and clean up the PATH on uninstall). A new registry key would be added pointing to the location of the python binary (wherever it is). Brian Curtin suggested this part of the proposal and has implemented it in a branch. MvL suggested a gradual transition to this over a three-release period. Open Issues: The PEP 397 Installer: As pointed out by Paul Moore, it may not matter once PEP 397 lands if python.exe is in the PATH or not - and it may be better if it is not. As he put it: """If we do put python.exe on PATH (whether it's in bin or not), we have to debate how to handle people having multiple versions of python on their machine. In a post-PEP 397 world, no Python is "the machine default" - .py files are associated with py.exe, not python.exe, so we have to consider the following 3 commands being run from a shell prompt: 1. myprog.py 2. py myprog.py 3. python myprog.py 1 and 2 will always do the same thing. However, 3 could easily do something completely different, if the Python in the #! line differs from the one found on PATH. To me, this implies that it's better for (3) to need explicit user action (setting PATH) if it's to do anything other than give an error. But maybe that's just me. I've been hit too often by confusion caused by *not* remembering this fact.""" One possible response here is that the moving of the python.exe binary and the setting of the PATH would be tied to an unchecked-by-default installer option, making an explicit user choice needed to invoke the new functionality. Breakage of existing tools: Mark Hammond, Paul Moore, and Tim Golden have all expressed that they have existing tools that would break and would need to be adjusted to match the new location of the python.exe, because that location is assumed to be at the root of the python install. A related issue is that this portion of the proposal has met with some resistance, but not much support here on Python-dev. The reason for that is selection bias: Those who are on Python-dev are much more likely to have tools that do advanced things with Python, such as introspect on the location of the binary, and are also much more likely to be comfortable with things like editing the PATH on windows. In contrast, the people that have trouble with this issue are those that are newest to Python and programming generally - those for whom editing the PATH is a challenge and whom are likely to be confused by the distinction between python.exe and a python program - and why, even after they add python to the path, the python program is not directly executable. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python-Dev Digest, Vol 104, Issue 79
> > On 03/21/2012 07:39 PM, Huan Do wrote: > > *Hi, > > > > I am a graduating Berkeley student that loves python and would like to > > propose an enhancement to python. My proposal introduces a concept of > > slicing generator. For instance, if one does x[:] it returns a list > > which is a copy of x. Sometimes programmers would want to iterate over a > > slice of x, but they do not like the overhead of constructing another > > list. Instead we can create a similar operator that returns a generator. > > My proposed syntax is x(:). The programmers are of course able to set > lower, upper, and step size like the following. -1 on the syntax And have you looked at itertools.islice ? ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Playing with a new theme for the docs
On Mar 21, 2012, at 6:28 PM, Greg Ewing wrote: > Ned Batchelder wrote: >> Any of the tweaks people are suggesting could be applied individually using >> this technique. We could just as easily choose to make the site >> left-justified, and let the full-justification fans use custom stylesheets >> to get it. > > Is it really necessary for the site to specify the justification > at all? Why not leave it to the browser and whatever customisation > the user chooses to make? It's design. It's complicated. Maybe yes, if you look at research related to default usage patterns, and saccade distance, reading speed and retention latency. Maybe no, if you look at research related to fixation/focus time, eye strain, and non-linear access patterns. Maybe maybe, if you look at the subjective aesthetic of the page according to various criteria, like "does it look like a newspaper" and "do I have to resize my browser every time I visit a new site to get a decent width for reading". As has been said previously in this thread several times, it's best to leave this up to a design czar who will at least make some decisions who will make some people happy. I'm fairly certain it's not possible to create a design that's optimal for all readers in all cases. -glyph ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Playing with a new theme for the docs
Fred Drake wrote: On Wed, Mar 21, 2012 at 3:13 PM, Ned Batchelder wrote: There are bad designers, or more to the point, designers who favor the overall look of the page at the expense of the utility of the page. That doesn't mean all designers are bad, or that "design" is bad. Don't throw out the baby with the bathwater. I get that. I'm not bad-mouthing actual design, and there are definitely good designers out there. It's unfortunate they're so seriously outnumbered. As they say, the 99% who are lousy designers give the rest a bad name. *wink* My first impression of this page: http://www.python.org/~gbrandl/build/html/index.html was that the grey side-bar gives the page a somber, perhaps even dreary, look. First impressions count, and I'm afraid that first look didn't work for me. But clicking through onto other pages with more text improved my feelings. A big +1 on the pale green shading of code blocks. The basic design seems good to me. I'd prefer a serif font for blocks of text, while keeping sans serif for the headings, but that's a mild preference. Looking forward to seeing the next iteration. -- Steven ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python install layout and the PATH on win32 (Rationale part 1: Regularizing the layout)
On 22 March 2012 14:17, VanL wrote:
> As this has been brought up a couple times in this subthread, I figured that
> I would lay out the rationale here.
I'm repeating myself here after I promised not to. My apologies, but I
don't think this posting captures the debate completely. One reason I
suggested a PEP is to better ensure that the arguments both pro and
con were captured, as that is a key part of the PEP process.
> One place where Python is unnecessarily different, however, is in
> the layout and organization of the Python environment. This is most
> visible in the name of the directory for binaries on the Windows platform
> ("Scripts") versus the name of the directory for binaries on every other
> platform ("bin"),
First of all, this difference is almost entirely *invisible*. Apart
from possibly setting PATH (once!) users should not be digging around
in the Python installation directory. Certainly on Windows, it is a
very unusual application that expects users to even care how the
application is laid out internally. And I suspect that is also true on
Unix and Mac.
Secondly, the layouts are not as similar as you claim here, if I
understand things correctly. on Unix Python is installed in
/usr/local/bin so there isn't even a "Python installation directory"
there. And Macs use some sort of Mac-specific bundle technology as I
understand it. To be honest, I don't think that there's a lot of
similarity even with your proposed changes.
> but a full listing of the layouts shows
> substantial differences in layout and capitalization across platforms.
That's true, but largely incidental. And given that (a) Windows is
case insensitive and (b) the capitalisation, although inconsistent,
follows platform standards (Unix all lowercase, Windows capitalised)
it makes little practical difference.
> Sometimes the include is capitalized ("Include"), and sometimes not; and
> the python version may or may not be included in the path to the
> standard library or not.
Given that on Windows the Python library is usually in something like
C:\Python32\Lib whereas on Unix it's in /usr/lib/python3.2 (I think),
the difference is reasonable because the Python *base* location
(C:\Python32 on Windows vs /usr on Unix) is version specific in one
case but not the other. To keep the correspondence complete, you
should be suggesting installing in /python32 on Unix (which I doubt
would gain much support :-))
> This may seem like a harmless inconsistency, and if that were all it was, I
> wouldn't care. (That said, cross-platform consistency is its own good). But
> it becomes a real pain when combined with tools like virtualenv or the new
> pyvenv to create cross-platform development environments.
The issue with virtualenv and pyvenv may be more significant. But
you're only mentioning those incidentally. As a straw-man suggestion,
why can virtualenv not be changed to maintain a platform-neutral
layout in spite of what core Python does? This is a straw-man because
I know the answer, but can we get the point out in the open - it's
related to how distutils installs code, and that in turn hits you
straight up against the distutils freeze. If distutils' behaviour is
the issue here, then argue for more flexibility in packaging, and use
that extra flexibility to argue for changes to virtualenv and pyvenv
to maintain a standard cross-platform layout. Breaking the Python
installation layout isn't the only option here, and I'd like to see a
clear analysis of the tradeoffs. (I also get a sense of undue haste -
"we can change the Python layout for 3.3, but changing packaging and
virtualenv is a much longer process"...)
> In particular, I regularly do development on both Windows and a Mac, and
> then deploy on Linux. I do this in virtualenvs, so that I have a controlled
> and regular environment. I keep them in sync using source control.
>
> The problem comes when I have executable scripts that I want to include in
> my dvcs - I can't have it in the obvious place - the binaries directory -
> because *the name of the directory changes when you move between platforms.*
> More concretely, I can't hg add "Scripts/runner.py? on my windows
> environment (where it is put in the PATH by virtualenv) and thendo a pull on
> Mac or Linux and have it end up properly in "bin/runner.py" which is the
> correct PATH for those platforms.
This presupposes that your development workflow - developing in place
in the virtualenv itself - is "the obvious approach". From what I've
seen of tools like virtualenvwrapper, you're not alone in this. And
I'm pretty new to using virtualenv so I wouldn't like to claim to be
any expert. But can I respectfully suggest that other ways of working
wouldn't hit these issues? WhatI do is develop my project in a project
specific directory, just as I would if I were using the system Python.
And I have an activated virtualenv *located somewhere else* that I
install required 3rd party modules in, etc. I then do standard "pip
install"
Re: [Python-Dev] Playing with a new theme for the docs
In article <[email protected]>, Steven D'Aprano wrote: >... > My first impression of this page: > > http://www.python.org/~gbrandl/build/html/index.html > > was that the grey side-bar gives the page a somber, perhaps even dreary, > look. > First impressions count, and I'm afraid that first look didn't work for me. > > But clicking through onto other pages with more text improved my feelings. A > big +1 on the pale green shading of code blocks. > > The basic design seems good to me. I'd prefer a serif font for blocks of > text, > while keeping sans serif for the headings, but that's a mild preference. > > Looking forward to seeing the next iteration. I like the overall design, but one thing seems to be missing is an overview of what Python is (hence what the page is about). Naturally we don't need that, but a one-line overview with a link to more information would be helpful. -- Russell ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python install layout and the PATH on win32 (Rationale part 1: Regularizing the layout)
Hi Paul, To start with, I appreciate your comments, and it is worth having both sides expressed. On 3/22/2012 12:59 PM, Paul Moore wrote: I'm repeating myself here after I promised not to. My apologies, but I don't think this posting captures the debate completely. One reason I suggested a PEP is to better ensure that the arguments both pro and con were captured, as that is a key part of the PEP process. I would be happy to write up a PEP. First of all, this difference is almost entirely *invisible*. Apart from possibly setting PATH (once!) users should not be digging around in the Python installation directory. Certainly on Windows, it is a very unusual application that expects users to even care how the application is laid out internally. And I suspect that is also true on Unix and Mac. This is a good point; it is mostly visible in the virtualenvs. If it only changed in virtualenvs, I would be happy. The policy, though, is that the virtualenv follows the platform policy. Secondly, the layouts are not as similar as you claim here, if I understand things correctly. on Unix Python is installed in /usr/local/bin so there isn't even a "Python installation directory" there. And Macs use some sort of Mac-specific bundle technology as I understand it. To be honest, I don't think that there's a lot of similarity even with your proposed changes. I was summarizing here because, frankly, there are hardly any OS/2 users, so it would be mostly Windows users affected by this change. Also as noted, I suggest that all platforms standardize on bin, lib, and include, just as I laid out. That said, while I think that the above is a good idea, my personal ambitions are more modest: If the names of the top-level directories only were changed to 'bin', 'lib', and 'include' - never mind differences under 'lib' - I would be happy. In fact, even the one change of 'Scripts' to 'bin' everywhere would get 90% of my uses. The issue with virtualenv and pyvenv may be more significant. But you're only mentioning those incidentally. I am approaching it from the platform level because of the policy that virtualenvs match the platform install layout. If instead virtualenv layouts were standardized, that would end up making me just as happy. (I also get a sense of undue haste - "we can change the Python layout for 3.3, but changing packaging and virtualenv is a much longer process"...) Honestly, I didn't expect that much resistance. None of the people I talked to in person even cared, or if they did, they thought that consistency was a benefit. But now that virtualenvs are going in in 3.3, I see this as the last good chance to change this. This presupposes that your development workflow - developing in place in the virtualenv itself - is "the obvious approach". From what I've seen of tools like virtualenvwrapper, you're not alone in this. [...] But can you acknowledge (and document) that "change your way of working" is another alternative to "change Python". Acknowledged. What you say is true - but people wanted to know what the benefit would be. I laid out my concrete use-case as a rationale. And as you note, I am not alone in this type of development. Sure, I care here because it affects my style of development, and there are other styles that have other benefits (and tradeoffs). I don't see that this part of the proposal would negatively affect those styles. While a few people have wondered why I would want this -- hopefully answered above -- I have not heard any opposition to this part of the proposal. See above. There has been opposition from a number of people. It's relatively mild, simply because it's a niche area and doesn't cause huge pain, but it's there. And you seem (based on the above analysis) to be overstating the benefits, so the summary here is weighted heavily in favour of change. If I have misrepresented anyone, I am sorry - but to the best of my understanding, no one had (prior to you, right now) objected to *this part* of the proposal. Mark, at least, specified that his concern was with the moving of the python binary and that he didn't care about this part. I believe Tim indicated that too, but perhaps I have on my rose-colored glasses and misunderstood him. Also, you have made no attempt that I've seen to address the question of why this is important enough to break backward compatibility. Maybe it is - but why? Backward compatibility is a very strong rule, and should be broken only with good justification. Consistency, and "it makes my way of working easier" really shouldn't be sufficient. In general, yes, I agree with you. However, the break with backwards compatibility is, as you point out, minor, and there is a benefit to consistency - especially given virtualenv-centric development. Has anyone checked whether this will affect people like Enthought and ActiveState who distribute their own versions of Python? Is ActiveState's PPM tool
Re: [Python-Dev] Playing with a new theme for the docs
In article , "Russell E. Owen" wrote: > In article <[email protected]>, > Steven D'Aprano wrote: > > >... > > My first impression of this page: > > > > http://www.python.org/~gbrandl/build/html/index.html > > > > was that the grey side-bar gives the page a somber, perhaps even dreary, > > look. > > First impressions count, and I'm afraid that first look didn't work for me. > > > > But clicking through onto other pages with more text improved my feelings. > > A > > big +1 on the pale green shading of code blocks. > > > > The basic design seems good to me. I'd prefer a serif font for blocks of > > text, > > while keeping sans serif for the headings, but that's a mild preference. > > > > Looking forward to seeing the next iteration. > > I like the overall design, but one thing seems to be missing is an > overview of what Python is (hence what the page is about). Naturally we > don't need that, but a one-line overview with a link to more information > would be helpful. > > -- Russell I'm afraid my last sentence was incoherent. I meant to say: Naturally we, as Python users, don't need that; but a one-line overview with a link to more information would be helpful to others who are not familiar with the language. -- Russell ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue 13524: subprocess on Windows
On Mar 21, 2012, at 4:38 PM, Brad Allen wrote: > I tripped over this one trying to make one of our Python at work > Windows compatible. We had no idea that a magic 'SystemRoot' > environment variable would be required, and it was causing issues for > pyzmq. > > It might be nice to reflect the findings of this email thread on the > subprocess documentation page: > > http://docs.python.org/library/subprocess.html > > Currently the docs mention this: > > "Note If specified, env must provide any variables required for the > program to execute. On Windows, in order to run a side-by-side > assembly the specified env must include a valid SystemRoot." > > How about rewording that to: > > "Note If specified, env must provide any variables required for the > program to execute. On Windows, a valid SystemRoot environment > variable is required for some Python libraries such as the 'random' > module. Also, in order to run a side-by-side assembly the specified > env must include a valid SystemRoot." Also, in order to execute in any installation environment where libraries are found in non-default locations, you will need to set LD_LIBRARY_PATH. Oh, and you will also need to set $PATH on UNIX so that libraries can find their helper programs and %PATH% on Windows so that any compiled dynamically-loadable modules and/or DLLs can be loaded. And by the way you will also need to relay DYLD_LIBRARY_PATH if you did a UNIX-style build on OS X, not LD_LIBRARY_PATH. Don't forget that you probably also need PYTHONPATH to make sure any subprocess environments can import the same modules as their parent. Not to mention SSH_AUTH_SOCK if your application requires access to _remote_ process spawning, rather than just local. Oh and DISPLAY in case your subprocesses need GUI support from an X11 program (which sometimes you need just to initialize certain libraries which don't actually do anything with a GUI). Oh and __CF_USER_TEXT_ENCODING is important sometimes too, don't forget that. And if your subprocess is in Perl or Ruby or Java you may need a couple dozen other variables which your deployment environment has set for you too. Did I mention CFLAGS or LC_ALL yet? Let me tell you a story about this one HP/UX machine... Ahem. Bottom line: it seems like screwing with the process spawning environment to make it minimal is a good idea for simplicity, for security, and for modularity. But take it from me, it isn't. I guarantee you that you don't actually know what is in your operating system's environment, and initializing it is a complicated many-step dance which some vendor or sysadmin or product integrator figured out how to do much better than your hapless Python program can. %SystemRoot% is just the tip of a very big, very nasty iceberg. Better not to keep refining why exactly it's required, or someone will eventually be adding a new variable (starting with %APPDATA% and %HOMEPATH%) that can magically cause your subprocess not to spawn properly to this page every six months for eternity. If you're spawning processes as a regular user, you should just take the environment you're given, perhaps with a few specific light additions whose meaning you understand. If you're spawning a process as an administrator or root, you should probably initialize the environment for the user you want to spawn that process as using an OS-specific mechanism like login(1). (Sorry that I don't know the Windows equivalent.) -glyph ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Playing with a new theme for the docs
On 22.03.2012 20:05, Russell E. Owen wrote: >> I like the overall design, but one thing seems to be missing is an >> overview of what Python is (hence what the page is about). Naturally we >> don't need that, but a one-line overview with a link to more information >> would be helpful. >> >> -- Russell > > > I'm afraid my last sentence was incoherent. I meant to say: > > Naturally we, as Python users, don't need that; but a one-line overview > with a link to more information would be helpful to others who are not > familiar with the language. Hi Russell, note that the page is not supposed to replace python.org, but is just a new styling of the Python documentation, docs.python.org, where it is kind of assumed that you know what Python is... Georg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: Issue #7652: Integrate the decimal floating point libmpdec library to speed
On 21.03.2012 23:22, Victor Stinner wrote: >>> http://hg.python.org/cpython/rev/730d5357 >>> changeset: 75850:730d5357 >>> user:Stefan Krah >>> date:Wed Mar 21 18:25:23 2012 +0100 >>> summary: >>> Issue #7652: Integrate the decimal floating point libmpdec library to speed >>> up the decimal module. Performance gains of the new C implementation are >>> between 12x and 80x, depending on the application. > > Congrats Stefan! And thanks for the huge chunk of code. Seconded. This is the kind of stuff that will make 3.3 the most awesomest 3.x release ever (and hopefully convince people that it does make sense to port)... cheers, Georg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Playing with a new theme for the docs
On 3/22/2012 10:02 AM, Steven D'Aprano wrote: As they say, the 99% who are lousy designers give the rest a bad name. *wink* :) My first impression of this page: http://www.python.org/~gbrandl/build/html/index.html was that the grey side-bar gives the page a somber, perhaps even dreary, look. First impressions count, and I'm afraid that first look didn't work for me. The dark sidebar continued down the whole page, and made it clearer why that space was being wasted at the bottom of long pages... I had never noticed, until doing the side-by-side comparison, that it was possible to collapse the TOC sidebar, but this seems to be true only in the old layout. After looking at both a while, my suggestions would be: 1. Preserve the collapsability of the TOC, but possible enhance its recognizability with an X in the upper right of the TOC sidebar, as well as the << in the middle. 2. Make the header fixed, so that the bread crumb trail at the top is available even after scrolling way down a long page. 3. Make the sidebar separately scrollable, so that it stays visible when scrolling down in the text. This would make it much easier to jump from section to section, if the TOC didn't get lost in the process. I have no particular preferences for colors or background colors, as long as they are reasonably legible. I do have a preference for serif fonts, especially if the font gets small. Can anyone point me to any legibility studies that show any font being more legible, more easily readable, than Times Roman? (And yes, I know a lot of people that dislike Times Roman, and none of them ever have.) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Playing with a new theme for the docs
On Fri, Mar 23, 2012 at 6:50 AM, Glenn Linderman wrote: > 3. Make the sidebar separately scrollable, so that it stays visible when > scrolling down in the text. This would make it much easier to jump from > section to section, if the TOC didn't get lost in the process. -1. The downside of separate scrolling is that you lose the ability to scroll-wheel the main docs if your mouse is over the TOC. I'd rather it stay as a single page, so it doesn't matter where my pointer is when I scroll. But I realise I'm bikeshedding this a bit. Bottom line: I'll use Python, and docs.python.org, regardless of the design and layout... so I'll let the expert(s) decide this one. ChrisA ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PendingDeprecationWarning
My impression is that the original reason for PendingDeprecationWarning versus DeprecationWarning was to be off by default until the last release before removal. But having DeprecationWarnings on by default was found to be too obnoxious and it too is off by default. So do we still need PendingDeprecationWarnings? My impression is that it is mostly not used, as it is a nuisance to remember to change from one to the other. The deprecation message can always indicate the planned removal time. I searched the Developer's Guide for both deprecation and DeprecationWarning and found nothing. -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Playing with a new theme for the docs
Georg, please start a new thread when you have a new design for review. I'm muting this one... -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Playing with a new theme for the docs
On Fri, 23 Mar 2012 07:57:18 +1100, Chris Angelico wrote: > On Fri, Mar 23, 2012 at 6:50 AM, Glenn Linderman > wrote: > > 3. Make the sidebar separately scrollable, so that it stays visible when > > scrolling down in the text. This would make it much easier to jump from > > section to section, if the TOC didn't get lost in the process. > > -1. The downside of separate scrolling is that you lose the ability to > scroll-wheel the main docs if your mouse is over the TOC. I'd rather > it stay as a single page, so it doesn't matter where my pointer is > when I scroll. I agree, and I don't use a mousewheel much. I use pentadactyl, and in that case sometimes the keyboard focus ends up in the TOC and then the scrolling keys scroll the wrong thing (or appear to do nothing, since such things are generally shorter than my screen...) and I can never remember the key sequence to change the focus, because *most* sites I don't have that problem with. For whatever that's worth :) --David ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Playing with a new theme for the docs
Glenn Linderman wrote: After looking at both a while, my suggestions would be: 1. Preserve the collapsability of the TOC, but possible enhance its recognizability with an X in the upper right of the TOC sidebar, as well as the << in the middle. 2. Make the header fixed, so that the bread crumb trail at the top is available even after scrolling way down a long page. 3. Make the sidebar separately scrollable, so that it stays visible when scrolling down in the text. This would make it much easier to jump from section to section, if the TOC didn't get lost in the process. +1 +1 and, of course, +1 Having to go clear back to the top is a pain, and I never knew `til now that the sidebar was collapsible. ~Ethan~ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: Issue #7652: Integrate the decimal floating point libmpdec library to speed
2012/3/22 Georg Brandl : >> Congrats Stefan! And thanks for the huge chunk of code. > > Seconded. This is the kind of stuff that will make 3.3 the most awesomest > 3.x release ever (and hopefully convince people that it does make sense to > port)... On the other hand, porting PyPy to 3.3 will be more work ;-) Fortunately the libmpdec directory should be reusable as is. Nice work! -- Amaury Forgeot d'Arc ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PendingDeprecationWarning
Wiadomość napisana przez Terry Reedy w dniu 22 mar 2012, o godz. 22:13: > My impression is that the original reason for PendingDeprecationWarning > versus DeprecationWarning was to be off by default until the last release > before removal. But having DeprecationWarnings on by default was found to be > too obnoxious and it too is off by default. So do we still need > PendingDeprecationWarnings? It is also my understanding that DeprecationWarnings have been effectively made to behave like PendingDeprecationWarnings. This makes the latter redundant. Should we raise DeprecationWarnings upon usage of PendingDeprecationWarnings? ;) -- Best regards, Łukasz Langa Senior Systems Architecture Engineer IT Infrastructure Department Grupa Allegro Sp. z o.o. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Playing with a new theme for the docs
Wiadomość napisana przez Ethan Furman w dniu 22 mar 2012, o godz. 22:18: > Glenn Linderman wrote: >> After looking at both a while, my suggestions would be: >> 1. Preserve the collapsability of the TOC, but possible enhance its >> recognizability with an X in the upper right of the TOC sidebar, as well as >> the << in the middle. >> 2. Make the header fixed, so that the bread crumb trail at the top is >> available even after scrolling way down a long page. >> 3. Make the sidebar separately scrollable, so that it stays visible when >> scrolling down in the text. This would make it much easier to jump from >> section to section, if the TOC didn't get lost in the process. > > +1 > +1 > and, of course, > +1 Something like that: http://packages.python.org/lck.django/lck.django.tags.models.html ? (breadcrumbs are at the bottom) -- Best regards, Łukasz Langa Senior Systems Architecture Engineer IT Infrastructure Department Grupa Allegro Sp. z o.o. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Playing with a new theme for the docs
Can we please get rid of the sidebar, or at least provide a way of turning it off? I don't think it's anywhere near useful enough to be worth the space it takes up. You can only use it when you're scrolled to the top of the page, otherwise it's just a useless empty space. Also, I often want to put the documentation side by side with the code I'm working on, and having about a quarter to a third of the horizontal space taken up with junk makes that much more awkward than it needs to be. A table of contents as a separate page is a lot more usable for me. I can keep it open in a browser tab and switch to it when I want to look at it. Most of the time I don't want to look at it and don't want it taking up space on the page. Also I agree about the grey text being suboptimal. Deliberately throwing away contrast, especially for the main body text, is insane. -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python install layout and the PATH on win32 (Rationale part 2: Moving the python.exe)
I'm responding to both of Van's recent messages in one: On 23/03/2012 1:47 AM, VanL wrote: [PART 2: Moving the python binary] ... A regular complaint of those new to Python on windows (and new to programming generally) has been that one of the first things that they need to do is to edit the PATH to allow Python to be run. In particular, this is the difficult sequence: 1. Install python. 2. Open up a shell and run "python" 3. Use pip or easy_install to install regetron (a package that installs an executable file). 4. Run regetron. ... One possible response here is that the moving of the python.exe binary and the setting of the PATH would be tied to an unchecked-by-default installer option, making an explicit user choice needed to invoke the new functionality. Given an off-by-default setting, I fail to see how it fixes your "difficult sequence" above. What would the instructions above now say? That the user should re-install Python ensuring to set that checkbox? Cover both cases, including how the user can tell if it is on the PATH and how to fix it otherwise? Something else? Breakage of existing tools: Mark Hammond, Paul Moore, and Tim Golden have all expressed that they have existing tools that would break and would need to be adjusted to match the new location of the python.exe, because that location is assumed to be at the root of the python install. A related issue is that this portion of the proposal has met with some resistance, but not much support here on Python-dev. The reason for that is selection bias: Those who are on Python-dev are much more likely to have tools that do advanced things with Python, such as introspect on the location of the binary, and are also much more likely to be comfortable with things like editing the PATH on windows. In contrast, the people that have trouble with this issue are those that are newest to Python and programming generally - those for whom editing the PATH is a challenge and whom are likely to be confused by the distinction between python.exe and a python program - and why, even after they add python to the path, the python program is not directly executable. Here you are referring to the PATH, but that isn't really where the objections are. I would claim a selection bias on Python-dev, where subscribers are less likely to use Windows regularly for development and therefore less likely to have developed or use tools for finding and launching Python. IMO, the lack of objections on Python-dev to renaming the binary directory is the same reason you aren't seeing overwhelming *support* for the change either. Without the perspective of being regular Windows users, people are happy to agree "consistent is better". All other things being equal, I'd agree too. Really, we have just one anecdote from you about your process and as Paul says, no attempt to outline other alternatives. For example, couldn't your "activate.bat" add both Scripts *and* bin to the PATH whereas your "activate.sh" adds just "bin"? I have been running like this for several years across multiple Python versions, so I have experience with the "breakage" from this part of the proposal. I have found four packages that would need to be updated: Pip, virtualenv, PyPM, and Egginst would need 1-2 line patches. With all due respect, I find this disingenuous. Your lack of experience with the tools that are out there doesn't mean they don't exist and I've already offered a couple of examples. I certainly can't claim to know what most of them are; I expect that I am underestimating them. IMO, your list is a fraction of the tools impacted. I have these patches, I would/could provide them. Generally these tools have something like: if platform == 'win32': bin_dir = 'Scripts' else: bin_dir = 'bin' The patches just remove the special casing - bin_dir just gets set to 'bin'. So none of those tools need to work with previous Python versions? But even if what you say is strictly true, I don't think a reasonable response to "but what about backwards compatibility and tool breakage" is "the breakage is simple and the fix is trivial" - the bar has never been that low for changes to the language itself. I don't see why tooling around the language shouldn't be held to any less account. So my summary of the situation is: * There has been *exactly one* concrete case listed that would benefit from this, and I believe that one case can be mitigated by you having 2 directories on the PATH in Windows and one on other platforms. * You yourself listed 4 tools that would need to change to support this. I've listed a further 2, and Paul and Tim both indicated they would be impacted. ActiveState and Enthought haven't been canvassed. I suspect this is the tip of the iceberg - although I concede it is probably a relatively small iceberg :) Like Tim, I wont sulk if you can convince people to make this change anyway, but IMO it is completely clear the costs outwe
Re: [Python-Dev] Python install layout and the PATH on win32 (Rationale part 2: Moving the python.exe)
Another use case was just pointed out to me: making things consistent with buildout. Given a similar use case (create repeatable cross platform environments), they create and use a 'bin' directory for executable files. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python install layout and the PATH on win32 (Rationale part 1: Regularizing the layout)
(resending, only sent to Van the first time) FWIW, I avoid the directory naming problems Van describes entirely by including my "scripts" in the source package and running them with the "-m" switch. So "python -m pulpdist.manage_site", for example, is PulpDist's Django administration client wrapper. I do it that way mainly to get sys.path right automatically, but it avoids several other installed vs checked out differences too. -- Sent from my phone, thus the relative brevity :) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python install layout and the PATH on win32 (Rationale part 2: Moving the python.exe)
Given the cost of the change, and the advent of the PEP-397 Launcher, I also vote -1. ~Ethan~ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Playing with a new theme for the docs
On Thu, Mar 22, 2012 at 11:56 PM, Greg Ewing wrote: > Can we please get rid of the sidebar, or at least provide > a way of turning it off? I don't think it's anywhere > near useful enough to be worth the space it takes up. +1. It seems to mostly duplicate the headline next/previous buttons already duplicated in the footer, it doesn't give you the whole TOC, and the whole TOC already present in many nodes. The "Search bar" is a standard feature of most headers (and sometimes footers), and I like the "Report a Bug" link because it confirms to the reader that Python developers actually care what they (readers) think. I guess there is enough room for both of those in the header even after subtractiing the horizontal space for the sidebar. > A table of contents as a separate page is a lot more > usable for me. I agree, but with emphasis on the *for me* part. I suspect this is a personal preference. > Also I agree about the grey text being suboptimal. +1 for black text or a perceptibly darker grey. > Deliberately throwing away contrast, especially for > the main body text, is insane. It does *look* nice, though. Overall, very nice job, Georg! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python install layout and the PATH on win32 (Rationale part 1: Regularizing the layout)
On Thu, Mar 22, 2012 at 12:59, Paul Moore wrote: > Note - that is not "Regularizing the layout". You have not made any > changes to OS/2 (which matches Windows at the moment). I think that would be a wasted effort with OS/2 entering "unsupported" mode in 3.3, and OS/2 specific code being removed in 3.4. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python install layout and the PATH on win32 (Rationale part 1: Regularizing the layout)
On Thu, Mar 22, 2012 at 13:57, VanL wrote: > Honestly, I didn't expect that much resistance. None of the people I talked > to in person even cared, or if they did, they thought that consistency was a > benefit. But now that virtualenvs are going in in 3.3, I see this as the > last good chance to change this. I was one of these people, first finding out just about the Scripts/bin change, and my thought was JFDI. The rest of it seems fine to me - I say let's go for it. >> Personally, my main concerns are around procedure and policy. The more the >> discussion goes on, the more I feel that there should be a PEP to capture >> the details of the debate clearly. Too much is getting lost in the noise. >> And I think you should provide a clear statement of why this issue is >> important enough to justify violating the backward compatibility policies. >> As Mark said (I think it was Mark...) if this had been proposed for 3.0, it >> would have been fine. Now we're at 3.2 with 3.3 close to release, and it >> just seems too late to be worth the risk. One plus point about your posting >> this separately. It's made me think through the issue in a bit more detail, >> and I'm now a solid -1 on the proposal. > > > I have been trying at various PyCons and in various conversations to move > this for years. No one cares. The current urgency is driven by pyvenv - > changes now will be much, much easier than changes later. > > Again, I am happy to write a PEP. If I were to summarize (on this issue > only): > > 1. The current backwards compatibility hit is minimal; I would be happy to > contact and provide patches to the four packages I have found (and anyone > else who wants one). Backwards compatibility in the future will probably be > harder to deal with. > 2. There are advantages to cross-platform consistency and to > virtualenv-based development. I believe that these will grow in the future. > 3. Most people won't care. To the extent that people notice, I think they > will appreciate the consistency. The virtualenv point, to me, is a strong one. I think we have an opportunity right now to make an adjustment, otherwise we're locked in again. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python install layout and the PATH on win32 (Rationale part 2: Moving the python.exe)
2012/3/22 VanL : > Open Issues: > > """If we do put python.exe on PATH (whether it's in bin or not), we have > to debate how to handle people having multiple versions of python on > their machine. In a post-PEP 397 world, no Python is "the machine > default" - .py files are associated with py.exe, not python.exe, so we > have to consider the following 3 commands being run from a shell > prompt: > > 1. myprog.py > 2. py myprog.py > 3. python myprog.py > > 1 and 2 will always do the same thing. However, 3 could easily do > something completely different, if the Python in the #! line differs > from the one found on PATH. To me, this implies that it's better for > (3) to need explicit user action (setting PATH) if it's to do anything > other than give an error. But maybe that's just me. I've been hit too > often by confusion caused by *not* remembering this fact.""" I'm not sure how widely used #1 is. I can't remember coming across any bug reports or posts around the web where the example command line just uses the Python chosen by the file association. I would suspect it's especially rare in the current time when many people are running a lot of versions of Python. Right now I have 2.6, 2.7, 3.1, 3.2, and 3.3, all installed in some different order, and I couldn't tell you which of those I installed the latest bugfix release for. That last one wins the race when it comes to file associations, and I've never paid attention to the installer option. #3 *will* require explicit user action - the Path setting is off by default. For as much as it's an advanced feature, it's really helpful to beginners. If you just want to type in "python" and have it work, the Path option is great. That's not to say the launcher isn't *also* a good thing. If you're a first timer and install Python 3.3 and want to run a tutorial - add Python to the path, type "python", and you're on your way. If you're an advanced user and you want to write and run code on Python 3.3, do the same. If you're even more advanced and are doing multi-version work, the launcher is a helpful alternative. > One possible response here is that the moving of the python.exe binary and > the setting of the PATH would be tied to an unchecked-by-default installer > option, making an explicit user choice needed to invoke the new > functionality. I ended up typing out the above while missing this paragraph...but, bingo. > Breakage of existing tools: Mark Hammond, Paul Moore, and Tim Golden have > all expressed that they have existing tools that would break and would need > to be adjusted to match the new location of the python.exe, because that > location is assumed to be at the root of the python install. Isn't the proposed "BinaryDir" registry key helpful here? It's not like we're telling people to fend for themselves -- we'll tell you where it's at. > A related issue is that this portion of the proposal has met with some > resistance, but not much support here on Python-dev. The reason for that is > selection bias: Those who are on Python-dev are much more likely to have > tools that do advanced things with Python, such as introspect on the > location of the binary, and are also much more likely to be comfortable with > things like editing the PATH on windows. In contrast, the people that have > trouble with this issue are those that are newest to Python and programming > generally - those for whom editing the PATH is a challenge and whom are > likely to be confused by the distinction between python.exe and a python > program - and why, even after they add python to the path, the python > program is not directly executable. I still don't really get how this portion of the proposal, the python.exe move to bin, is holding people up. If you're using the launcher, the change is invisible. If you're using a setup where bin is on the Path, the change is invisible. File associations? Invisible. If you're typing out the full path, you have to type "bin" in the middle -- this kind of sucks but I think we'll live. I get that tools could be affected. I had two IDE makers at PyCon immediately throw up red flags to this change. I think one of them was about to charge the stage during my talk. When it was mentioned that we could point them to the proper location, they breathed a sigh of relief and said "cool, do it". If a registry key pointing you to python.exe (rather, the directory) right now in Python < 3.3 works, why doesn't another one pointing you to python.exe in Python >= 3.3 work? ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python install layout and the PATH on win32 (Rationale part 2: Moving the python.exe)
On Thu, Mar 22, 2012 at 18:26, Ethan Furman wrote: > Given the cost of the change, and the advent of the PEP-397 Launcher, I also > vote -1. Can you provide some justification other than a number? It's a pretty cheap change and the launcher solves somewhat of a different problem. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python install layout and the PATH on win32 (Rationale part 2: Moving the python.exe)
[snipped some CCs] On 23/03/2012 2:20 PM, Brian Curtin wrote: ... I get that tools could be affected. I had two IDE makers at PyCon immediately throw up red flags to this change. I think one of them was about to charge the stage during my talk. When it was mentioned that we could point them to the proper location, they breathed a sigh of relief and said "cool, do it". If a registry key pointing you to python.exe (rather, the directory) right now in Python< 3.3 works, why doesn't another one pointing you to python.exe in Python>= 3.3 work? It will work. The fact MvL is proposing the conservative approach of landing this in 3.5+ and have 3.3+ include the *new* registry key means I'm willing to reluctantly accept it rather than aggressively oppose it. Tools then have a chance to adapt to the new key. If the proposal moved any faster, existing tools which only use the old key would break without warning. The fact they need to change at all is unfortunate, but the timescale proposed means we can at least say we warned them. Mark ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Setting up a RHEL6 buildbot
I'm looking into getting a RHEL6 system set up to add to the buildbot fleet. The info already on the wiki [1] is pretty helpful, but does anyone have any suggestions on appropriate CPU/memory/disk allocations? Cheers, Nick. [1] http://wiki.python.org/moin/BuildBot -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Setting up a RHEL6 buildbot
The 24 core machine at my last workplace could configure and make the tip in 45 seconds from a clean checkout. Lots of cores? :) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Python install layout and the PATH on win32 (Rationale part 1: Regularizing the layout)
In http://mail.python.org/pipermail/python-dev/2012-March/117953.html VanL wrote: > Paul Moore wrote: >> First of all, this difference is almost entirely *invisible*. Apart >> from possibly setting PATH (once!) users should not be digging around >> in the Python installation directory. Certainly on Windows, it is a >> very unusual application that expects users to even care how the >> application is laid out internally. And I suspect that is also true on >> Unix and Mac. >> Secondly, the layouts are not as similar as you claim here, In fact, of the 8 builtin layout schemes, the only two that are consistent are nt (which you propose to change) and os2. Of the 64 possible values, there are 26 unique values. So I suspect the right answer is just to make it easier for a user to set those 8 values at installation time; in your case, you can tell users what values to use when setting up their virtual environment. (And if you can't do that, then you can add files to your own directories, and if you can't do that, then you can add a post-install hook that renames your directories or moves your files according to the installed values.) > In fact, even the one change > of 'Scripts' to 'bin' everywhere would get 90% of my uses. So is this something that you can control in your recommended virtual environment? Or at least something that you can do with the same script that checks everything out of source control and adds *something* to the path? -jJ -- If there are still threading problems with my replies, please email me with details, so that I can try to resolve them. -jJ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
