Steven Bethard wrote:
> On Mon, Apr 13, 2009 at 1:14 PM, Mart Sõmermaa wrote:
>> A default behaviour should be found that works according to most
>> user's expectations so that they don't need to use the positional
>> arguments generally.
>
> I believe the usual Python approach here is to have tw
On Thu, Apr 16, 2009 at 08:18, Jess Austin wrote:
> hi,
>
> I'm new to python core development, and I've been advised to write to
> python-dev concerning a feature/patch I've placed at
> http://bugs.python.org/issue5434, with Rietveld at
> http://codereview.appspot.com/25079.
>
> This patch adds a
Some library files, such as pdb.py, begin with
#!/usr/bin/env python
In various discussions regarding some issues I submitted I was told
that the decision had been made to call Python 3.x release
executables python3. (One of the conflicts I ran into when I made
'python' a link to python
On Sat, Apr 18, 2009 at 3:41 PM, Nick Coghlan wrote:
> Yep - Guido has pointed out in a few different API design discussions
> that a boolean flag that is almost always set to a literal True or False
> is a good sign that there are two functions involved rather than just
> one. There are exception
2009/4/18 Mitchell L Model :
> Some library files, such as pdb.py, begin with
> #!/usr/bin/env python
> In various discussions regarding some issues I submitted I was told that the
> decision had been made to call Python 3.x release executables python3. (One
> of the conflicts I ran into whe
On Apr 18, 2009, at 1:08 PM, Mitchell L Model wrote:
Some library files, such as pdb.py, begin with
#!/usr/bin/env python
In various discussions regarding some issues I submitted I was told
that the decision had been made to call Python 3.x release
executables python3. (One of the co
Mart Sõmermaa wrote:
> On Sat, Apr 18, 2009 at 3:41 PM, Nick Coghlan wrote:
>> Yep - Guido has pointed out in a few different API design discussions
>> that a boolean flag that is almost always set to a literal True or False
>> is a good sign that there are two functions involved rather than just
Benjamin Peterson wrote:
> 2009/4/18 Mitchell L Model :
>> Some library files, such as pdb.py, begin with
>>#!/usr/bin/env python
>> In various discussions regarding some issues I submitted I was told that the
>> decision had been made to call Python 3.x release executables python3. (One
>>
2009/4/18 Nick Coghlan :
> Benjamin Peterson wrote:
>> 2009/4/18 Mitchell L Model :
>>> Some library files, such as pdb.py, begin with
>>> #!/usr/bin/env python
>>> In various discussions regarding some issues I submitted I was told that the
>>> decision had been made to call Python 3.x rele
Benjamin Peterson wrote:
> 2009/4/18 Nick Coghlan :
>> I see a few options:
>> 1. Abandon the "python" name for the 3.x series and commit to calling it
>> "python3" now and forever (i.e. actually make the decision that Mitchell
>> refers to).
>
> I believe this was decided on sometime (the sprints
On Sat, Apr 18, 2009 at 8:14 PM, Benjamin Peterson wrote:
> 2009/4/18 Nick Coghlan :
>> I see a few options:
>> 1. Abandon the "python" name for the 3.x series and commit to calling it
>> "python3" now and forever (i.e. actually make the decision that Mitchell
>> refers to).
>
> I believe this was
At 20:51 -0700 04/18/2009, Steven Bethard wrote:
>On Sat, Apr 18, 2009 at 8:14 PM, Benjamin Peterson
>wrote:
>> 2009/4/18 Nick Coghlan :
>>> I see a few options:
>>> 1. Abandon the "python" name for the 3.x series and commit to calling it
>>> "python3" now and forever (i.e. actually make the decis
Steven Bethard wrote:
> On Sat, Apr 18, 2009 at 8:14 PM, Benjamin Peterson
> wrote:
>> 2009/4/18 Nick Coghlan :
>>> I see a few options:
>>> 1. Abandon the "python" name for the 3.x series and commit to calling it
>>> "python3" now and forever (i.e. actually make the decision that Mitchell
>>> re
On Sat, Apr 18, 2009 at 9:37 PM, Nick Coghlan wrote:
> Steven Bethard wrote:
>> On Sat, Apr 18, 2009 at 8:14 PM, Benjamin Peterson
>> wrote:
>>> 2009/4/18 Nick Coghlan :
I see a few options:
1. Abandon the "python" name for the 3.x series and commit to calling it
"python3" now and
Steven Bethard wrote:
> On Sat, Apr 18, 2009 at 9:37 PM, Nick Coghlan wrote:
>> Note that such an approach would then require an altaltinstall command
>> in order to be able to install a specific version of python 3.x without
>> changing the python3 alias (e.g. installing 3.2 without overriding 3.
On Sat, Apr 18, 2009 at 10:04 PM, Nick Coghlan wrote:
> Steven Bethard wrote:
>> On Sat, Apr 18, 2009 at 9:37 PM, Nick Coghlan wrote:
>>> Note that such an approach would then require an altaltinstall command
>>> in order to be able to install a specific version of python 3.x without
>>> changing
Nick Coghlan wrote:
Steven Bethard wrote:
On Sat, Apr 18, 2009 at 9:37 PM, Nick Coghlan wrote:
Note that such an approach would then require an altaltinstall command
in order to be able to install a specific version of python 3.x without
changing the python3 alias (e.g. installing 3.2
Allan McRae wrote:
Nick Coghlan wrote:
Steven Bethard wrote:
On Sat, Apr 18, 2009 at 9:37 PM, Nick Coghlan
wrote:
Note that such an approach would then require an altaltinstall command
in order to be able to install a specific version of python 3.x
without
changing the python3 alias (e
On Sun, Apr 19, 2009 at 05:51, Steven Bethard wrote:
> That's an unfortunate decision. When the 2.X line stops being
> maintained (after 2.7 maybe?) we're going to be stuck with the "3"
> suffix forever for the "real" Python.
Yes, but that's the only decision that really works.
> Why doesn't it
Steven Bethard wrote:
That's an unfortunate decision. When the 2.X line stops being
maintained (after 2.7 maybe?) we're going to be stuck with the "3"
suffix forever for the "real" Python.
I don't see why we have to be stuck with it forever.
When 2.x has faded into the sunset, we can start
ali
Nick Coghlan wrote:
Note that such an approach would then require an altaltinstall command
in order to be able to install a specific version of python 3.x without
changing the python3 alias (e.g. installing 3.2 without overriding 3.1).
Seems like what we need is something in between altinstall
21 matches
Mail list logo
