Re: [Python-Dev] draft PEP: virtual environments
> Not a zip file specifically - just a binary stream which organises scripts to
> be
> installed. If each class in a hierarchy has access to a binary stream, then
> subclasses have access to the streams for base classes as well as their own
> stream, and can install selectively from base class streams and their own
> stream.
>
> class Base:
> scripts = ... # zip stream containing scripts A, B
>
> def install_scripts(self, stream):
> # ...
>
> def setup_scripts(self):
> self.install_scripts(self.scripts)
>
> class Derived:
> scripts = ... # zip stream containing modified script B, new script C
>
> def setup_scripts(self):
> self.install_scripts(Base.scripts) # adds A, B
> self.install_scripts(self.scripts) # adds C, overwrites B
I'm not sure how many scripts you are talking about, and how long they
are. Assuming there are free, and assuming they are short, I'd not make
them separate source files again, but put them into string literals instead:
scripts = {
'start':'''\
#!/bin/sh
echo start
''',
'stop':'''\
#!/bin/sh
echo stop
'''
}}}
Then, your install_scripts would take a dictionary filename:script
contents. That's just as easily extensible.
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] cpython (3.2): adjust braces a bit
On Fri, Oct 21, 2011 at 8:17 PM, Benjamin Peterson wrote: > 2011/10/21 Tres Seaver : >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> On 10/21/2011 12:31 PM, Benjamin Peterson wrote: >>> 2011/10/21 Eric V. Smith : What's the logic for adding some braces, but removing others? >>> >>> No braces if everything is a one-liner, otherwise braces >>> everywhere. >> >> Hmm, PEP 7 doesn't show any example of the one-liner exception. Given >> that it tends to promote errors, particularly among >> indentation-conditioned Python programmers (adding another statement >> at the same indentation level), why not just have braces everywhere? > > Because we're not writing Python? Right. Only CPython here. Where can I find The True Python? =) BTW, some of this stuff may find its way into PEP-7 http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml?showone=Conditionals#Conditionals -- anatoly t. ___ 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] draft PEP: virtual environments
Martin v. Löwis v.loewis.de> writes:
> I'm not sure how many scripts you are talking about, and how long they
> are. Assuming there are free, and assuming they are short, I'd not make
> them separate source files again, but put them into string literals instead:
>
> scripts = {
> 'start':'''\
> #!/bin/sh
> echo start
> ''',
> 'stop':'''\
> #!/bin/sh
> echo stop
> '''
> }}}
>
> Then, your install_scripts would take a dictionary filename:script
> contents. That's just as easily extensible.
True, but while the default scripts are not *too* long, third party scripts
might be not amenable to this treatment. Plus, there can be binary executables
in there too: at the moment, the pysetup3 script on Windows is shipped as a stub
executable pysetup3.exe and a script pysetup3-script.py (since we can't rely on
the PEP 397 launcher being available, this is the only way of being sure that
the correct Python gets to run the script).
I've changed the implementation now to use a directory tree, and the API takes
the absolute pathname of the directory containing the scripts.
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
[Python-Dev] PEP 397 and idle
python-dev I am being forced to support multiple versions of python on Windows platforms. I have been using PEP 397 and the execution of *.py files works great. Thank you!! My problem is idle. The various versions of idle have the same problem as the various versions of python. We were using an editor that allowed python selection, however, they stopped supporting python and we are back using idle. Any suggestions on switching versions of idle would be appreciated. Thanks Dave Bailey ___ 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] PEP 397 and idle
Hi, 2011/11/1 David Bailey > python-dev > > I am being forced to support multiple versions of python on Windows > platforms. I have been using PEP 397 and the execution of *.py files works > great. Thank you!! > My problem is idle. The various versions of idle have the same problem as > the various versions of python. We were using an editor that allowed python > selection, however, they stopped supporting python and we are back using > idle. Any suggestions on switching versions of idle would be appreciated. > The python-dev mailing list is for the development *of* python. For development *with* python, please ask your question on the python-list mailing list, or the comp.lang.python newsgroup. There are many friendly people there ready to answer your questions. Thank you! -- Amaury Forgeot d'Arc ___ 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] PEP 397 and idle
On Tue, 1 Nov 2011 14:25:28 +0100 "Amaury Forgeot d'Arc" wrote: > Hi, > > 2011/11/1 David Bailey > > > python-dev > > > > I am being forced to support multiple versions of python on Windows > > platforms. I have been using PEP 397 and the execution of *.py files works > > great. Thank you!! > > My problem is idle. The various versions of idle have the same problem as > > the various versions of python. We were using an editor that allowed python > > selection, however, they stopped supporting python and we are back using > > idle. Any suggestions on switching versions of idle would be appreciated. > > > > The python-dev mailing list is for the development *of* python. > For development *with* python, please ask your question on the python-list > mailing list, or the comp.lang.python newsgroup. Given the question is about an in-progress PEP, it actually seems quite appropriate for python-dev. Also, until now, IDLE is supposed to be developed in the stdlib (although concretely it's not developed anymore). Regards Antoine. ___ 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] draft PEP: virtual environments
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/31/2011 09:57 PM, Stephen J. Turnbull wrote: > That's fine, but either make sure it works with a POSIX-conformant > /bin/sh, or make the shebang explicitly bash (bash is notoriously > buggy in respect of being POSIX-compatible when named "sh"). It has no shebang line, it must be sourced not run (its only purpose is to modify the current shell environment). Carl -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6wEJYACgkQ8W4rlRKtE2dNGQCguHy8iYMgWIJyaQqABObt5ecv esIAnjmuHYH+G8JBGBzcwZzj8sofPinc =MR6D -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
Re: [Python-Dev] draft PEP: virtual environments
On 31 October 2011 20:10, Carl Meyer wrote: >> For Windows, can you point me at the nt scripts? If they aren't too >> complex, I'd be willing to port to Powershell. > > Thanks! They are here: > https://bitbucket.org/vinay.sajip/pythonv/src/6d057cfaaf53/Lib/venv/scripts/nt The attached should work. Untested at the moment, I'm afraid, as I don't have access to a PC with the venv branch available. But they aren't complex, so they should be fine. Paul. Deactivate.ps1 Description: Binary data Activate.ps1 Description: Binary data ___ 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] draft PEP: virtual environments
On 1 November 2011 16:29, Paul Moore wrote: > On 31 October 2011 20:10, Carl Meyer wrote: >>> For Windows, can you point me at the nt scripts? If they aren't too >>> complex, I'd be willing to port to Powershell. >> >> Thanks! They are here: >> https://bitbucket.org/vinay.sajip/pythonv/src/6d057cfaaf53/Lib/venv/scripts/nt > > The attached should work. Untested at the moment, I'm afraid, as I > don't have access to a PC with the venv branch available. But they > aren't complex, so they should be fine. By the way, these do not need to be dot-sourced to activate/deactivate the venv, but they do need to be dot-sourced to enable the prompt change. As the prompt is more of a cosmetic thing, I'm not sure how crucial that is... Paul. ___ 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] draft PEP: virtual environments
On 1 November 2011 16:40, Paul Moore wrote: > On 1 November 2011 16:29, Paul Moore wrote: >> On 31 October 2011 20:10, Carl Meyer wrote: For Windows, can you point me at the nt scripts? If they aren't too complex, I'd be willing to port to Powershell. >>> >>> Thanks! They are here: >>> https://bitbucket.org/vinay.sajip/pythonv/src/6d057cfaaf53/Lib/venv/scripts/nt >> >> The attached should work. Untested at the moment, I'm afraid, as I >> don't have access to a PC with the venv branch available. But they >> aren't complex, so they should be fine. > > By the way, these do not need to be dot-sourced to activate/deactivate > the venv, but they do need to be dot-sourced to enable the prompt > change. As the prompt is more of a cosmetic thing, I'm not sure how > crucial that is... ... and of course, to prove that anything untested is wrong, here's a minor fix to deactivate.ps1 :-) Paul. Deactivate.ps1 Description: Binary data ___ 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] PEP 397 and idle
Amaury,
Maybe this belongs on some blog. I don't know. I was responding to PEP 397,
seems to me that idle was left out.
I am not being critical of what you guys are doing. I love python. As a
developer, I see a problem. You are correct, I have no technical issue. I
do believe it is still a development issue that is more of a marketing
issue than a technical issue. I am tired of ruby this and ruby on rails
that. I love python and want it to succeed. If you want to increase the
population of windows users of python, make idle easier to use or fix print
in 3.X or both. The point I was trying to make, is that to the world
outside of python-dev, idle is part of python, especially on a windows
platform. I am not trying to say that emacs should be part of gcc or
anything like that. I have taught python to a number of windows users and
the editor is the first big hurdle to using python. On linux, emacs vs vim
might be an issue but the editor is not an issue. My guess is that very few
python-dev developers use windows. I wouldn't. It is fascinating to watch
a new python user on windows. The typical scenario is that they download
both a version of 3.X and 2.6 or 2.7 because they are not sure which is
correct. I tell them to uninstall 3.X but there is a lot of push back
because they don't want the "old stuff".
I grew up using Unix, and it is very hard to watch someone trying to use
microsoft word to write a python 'hello world'. Every book they read says
type print "hello world" into hello.py. They will try any way they know
how. Then they double click on hello.py and if they are lucky and have a
slow machine they can see a syntax error flash on their screen from a
command window that pops up and then goes away. The people with fast
machines just throw their hands in the air. Some dig deeper, and migrate to
idle. Idle generates the same syntax error but with persistence. They try
all the different combinations of quotes, because that seems to be the
indicated syntax error. Then they start asking about Ruby.
So we install PEP 397 and change the hello.py to
#!/usr/bin/env python2
print "hello world"
raw_input('>')
and
#!/usr/bin/env python3
print ("hello world")
input('>')
It now executes correctly when they double click and the command window
stays open. Python works and everyone is happy, but idle is broken and
continues to generate a syntax error. At this point they don't have warm
fuzzy feelings about python. These people were thinking that they were
going to use python in their job, but now it is too scary. They don't
understand how python works but idle does not.
It is truly unfortunate that print breaks between versions of python. The
uninitiated do not expect that. So once I get to the point of saying " ok
now lets first create .bat files to start different versions of idle, their
eyes start to glaze over. An then when I say " OK now lets put copies of
these .bat files in all the python folders on the desktop" they start
looking out the real windows. What once took 5 min in a training now takes
the whole hour if someone has loaded two versions, and the whole class is
lost to VB or something worse.
Idle needs to be smart so it runs the correct version of python, or
generate a print deprecated message or something that gives a new user a
clue. This is more of a marketing issue than a technical issue. You can
develop the greatest new version of python but if a new python user can't
get past the first page of the python book they bought, they will not
bother to go to page two and the greatest new version that you guys develop
is lost all because of a single keyword print that has no technical issues.
Dave Bailey
On Tue, Nov 1, 2011 at 6:25 AM, Amaury Forgeot d'Arc wrote:
> Hi,
>
> 2011/11/1 David Bailey
>
>> python-dev
>>
>> I am being forced to support multiple versions of python on Windows
>> platforms. I have been using PEP 397 and the execution of *.py files works
>> great. Thank you!!
>> My problem is idle. The various versions of idle have the same problem as
>> the various versions of python. We were using an editor that allowed python
>> selection, however, they stopped supporting python and we are back using
>> idle. Any suggestions on switching versions of idle would be appreciated.
>>
>
> The python-dev mailing list is for the development *of* python.
> For development *with* python, please ask your question on the python-list
> mailing list, or the comp.lang.python newsgroup.
> There are many friendly people there ready to answer your questions.
> Thank you!
>
> --
> Amaury Forgeot d'Arc
>
___
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] Code cleanups in stable branches?
On Oct 31, 2011, at 06:23 PM, Éric Araujo wrote: >I thought that patches that clean up code but don’t fix actual bugs were >not done in stable branches. Has this changed? I hope not. Sure, if they fix actual bugs, that's fine, but as MvL often points out, even innocent looking changes can break code *somewhere*. We don't lose by being conservative with our stable branches. -Barry ___ 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] PEP 397 and idle
On 11/1/2011 2:20 PM, David Bailey wrote:
population of windows users of python, make idle easier to use or fix
print in 3.X or both.
print is fixed in 3.x. This is not the place to argue otherwise. If you
want to rant againt print as function, go to python-list.
If one looks up 'print' in the index, it is clearly and immediately
identified as a "built-in function" (at least in Window help version of
docs).
IDLE is as trivial to use as anything. A Start menu icon is installed.
If used often, it appears in the frequently used programs list. I
presume a shortcut can be copied to the desktop. I just have it pinned
to my taskbar. One click and it starts. Could not be easier.
Now, it would be better if the icons were labelled by version. I thought
that had been agreed on, and I intend to request it again.
is that very few python-dev developers use windows. I wouldn't.
I am an exception; I have used it for a decade and still do.
And I still plan to work on improving it.
fascinating to watch a new python user on windows. The typical scenario
is that they download both a version of 3.X and 2.6 or 2.7 because they
are not sure which is correct. I tell them to uninstall 3.X
WRONG, WRONG, WRONG. New users should install the most recent 3.x, learn
it, and only bother with 2.7 if they actually NEED it.
> but there is a lot of push back because they don't want the "old stuff".
They are correct about that. 3.x is easier to learn because of the
removal of obsolete junk.
microsoft word to write a python 'hello world'.
That works if, AND ONLY IF, they know to save as plain vanilla text
mode. Perhaps this needs to be emphasized better. Notepad works better.
IDLE is much, much better yet.
Every book they read says type print "hello world" into hello.py.
Only old 2.x books. Any 3.x book (like Mark Summerfield's) will say
'print("Hello world")'
Do the people you are talking about expect that everything in a Windows
XP book applies without change to Windows 7?
> They will try any way they know how.
Except look in the doc, with its index? Or type 'help(print)'?
Any decent beginner book or class should explain how to use both the
docs and help(). I hope our tutorial does.
Then they double click on hello.py
This and PEP 397 have nothing to do with IDLE. It is for interactive use
and editing.
It would be helpful if the right-click context menu for .py files had an
'Edit with IDLEx.y' for each version installed, instead of one 'Edit
with IDLE'. But there is no 'correct' version for editing. It depends on
what the user intends to do, and what version the user wants the file to
run with *after* editing.
IDLE could be enhanced to look at the first line of files that it is
opening and if there is a conflicting shebang line, ask if the use wants
to open it with a different version of Python and IDLE. This should NOT,
however, be automatic as the user might want to edit the file (including
the first line) to work with the Python version already running.
#!/usr/bin/env python3
print ("hello world")
input('>')
It now executes correctly when they double click and the command window
stays open. Python works and everyone is happy, but idle is broken and
continues to generate a syntax error.
IDLE 3.2 runs the above fine. I have no idea what you are talking about.
It is truly unfortunate that print breaks between versions of python.
The uninitiated do not expect that.
So they should start with 3.2 and never learn about the old version
unless they really, really have to.
" ok now lets first create .bat files to start different versions of
idle,
Why? The installers already create version-specific icons (which, as I
said, should be better labelled), and beginners should start with the
modern one.
> their eyes start to glaze over.
No wonder.
An then when I say " OK now lets
put copies of these .bat files in all the python folders on the desktop"
Why? This make no sense to me, an experience IDLE user.
they start looking out the real windows.
No wonder.
What once took 5 min in a
training now takes the whole hour if someone has loaded two versions,
So they should not do that, and you should not mess their heads with
talk about unneeded .bat files.
Idle needs to be smart so it runs the correct version of python,
IDLE does not run Python, it is run by Python, and the Python it is run
by runs *its* version of IDLE in *its* stdlib.
--
Terry Jan Reedy
___
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] PEP 397 and idle
On Wed, Nov 2, 2011 at 7:28 AM, Terry Reedy wrote: > Now, it would be better if the icons were labelled by version. I thought > that had been agreed on, and I intend to request it again. It has, it really just needs a patch put forward with specific installer changes in it. 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
