Re: [Python-Dev] [Python-ideas] Proposed addtion to urllib.parse in 3.1 (and urlparse in 2.7)

[Nick Coghlan]

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 two variants of
> the function, add_query_params and add_query_params_no_dups (or
> whatever you want to name them). That way the flag parameter is
> "named" right in the function name.

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 exceptions to that guideline (e.g. the reverse argument
for sorted and list.sort), but they aren't common, and even when they do
crop up, making them keyword-only arguments is strongly recommended.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
---
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Issue5434: datetime.monthdelta

[Lennart Regebro]

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 "monthdelta" class and a "monthmod" function to the
> datetime module.  The monthdelta class is much like the existing
> timedelta class, except that it represents months offset from a date,
> rather than an exact period offset from a date.  This allows us to
> easily say, e.g. "3 months from now" without worrying about the number
> of days in the intervening months.
>
>    >>> date(2008, 1, 30) + monthdelta(1)
>    datetime.date(2008, 2, 29)
>    >>> date(2008, 1, 30) + monthdelta(2)
>    datetime.date(2008, 3, 30)
>
> The monthmod function, named in (imperfect) analogy to divmod, allows
> us to round-trip by returning the interim between two dates
> represented as a (monthdelta, timedelta) tuple:
>
>    >>> monthmod(date(2008, 1, 14), date(2009, 4, 2))
>    (datetime.monthdelta(14), datetime.timedelta(19))
>
> Invariant: dt + monthmod(dt, dt+td)[0] + monthmod(dt, dt+td)[1] == dt + td
>
> These also work with datetimes!  There are more details in the
> documentation included in the patch.  In addition to the C module
> file, I've updated the datetime CAPI, the documentation, and tests.
>
> I feel this would be a good addition to core python.  In my work, I've
> often ended up writing annoying one-off "add-a-month" or similar
> functions.  I think since months work differently than most other time
> periods, a new object is justified rather than trying to shoe-horn
> something like this into timedelta.  I also think that the round-trip
> functionality provided by monthmod is important to ensure that
> monthdeltas are "first-class" objects.
>
> Please let me know what you think of the idea and/or its execution.

There are so many meanings of "one month from now" so I'd rather see a
bunch of methods for monthly manipulations than a monthdelta class.

Obvious:
Tuesday February 3rd 2009 + 1 month = Tuesday March 3rd 2009

Not obvious:
Tuesday March 3rd 2009 + 1 month = Tuesday April 7th 2009 (5 weeks)
Tuesday April 7th 2009 + 1 months = Tuesday May 5th 2009 (4 weeks)

Problematic:
Tuesday March 31st 2009 + 1 month = what? Thursday April 30th 2009? Error?

Just supporting the obvious case is just not enough to be worth the work. Doing
  month = month + 1
  if month > 12:
 month = 1
 year = year +1
  lastday = calendar.monthrange(year, month)[1]
  if day > lastday:
day = lastday

Isn't really enough work to warrant it's own class IMO, even though
it's a method I also end up doing all the time in every bloody
calendar implementation I've done. :)

And then comes the same question when talking about years.
One year after the 20th of March 2011 may be the 20th of March 2012.
But it could also be 19th of March, as 2012 is a leap year. And a year
later still would then be the 20th of Match 2013 again... Code that
doesn't support ALL the weird-ass variants is really not worth putting
into the standard library, IMO.

I'd recommend you to look at the dateutil.rrule code, maybe there is
something you can use there. Perhaps there is something there that can
be used straight off. Or at least maybe it can be extracted to it's
own extended timedelta library that supports more advanced timedeltas,
including "second to last wednesday" and "first sunday after easter".

-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] #!/usr/bin/env python --> python3 where applicable

[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 when I made 
'python' a link to python3.1 was that some tools used in making the 
HTML documentation haven't been upgraded to run with 3.)


Shouldn't all library files that begin with the above line be changed 
so that they read 'python3' instead of python? Perhaps I should have 
just filed this as an issue, but I'm not confident of the state of 
the plan to move to python3 as the official executable name.

___
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] [Python-ideas] Proposed addtion to urllib.parse in 3.1 (and urlparse in 2.7)

[Mart Sõmermaa]

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 exceptions to that guideline (e.g. the reverse argument
> for sorted and list.sort), but they aren't common, and even when they do
> crop up, making them keyword-only arguments is strongly recommended.

As you yourself previously noted -- "it is often
better to use *args for the two positional arguments - it avoids
accidental name conflicts between the positional arguments and arbitrary
keyword arguments" -- kwargs may cause name conflicts.

But I also agree, that the current proliferation of positional args is ugly.

add_query_params_no_dups() would be suboptimal though, as there are
currently three different ways to handle the duplicates:
* allow duplicates everywhere (True),
* remove duplicate *values* for the same key (False),
* behave like dict.update -- remove duplicate *keys*, unless
explicitly passed a list (None).

(See the documentation at
http://github.com/mrts/qparams/blob/bf1b29ad46f9d848d5609de6de0bfac1200da310/qparams.py
).

Additionally, as proposed by Antoine Pitrou, removing keys could be implemented.

It feels awkward to start a PEP for such a marginal feature, but
clearly a couple of enlightened design decisions are required.
___
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] #!/usr/bin/env python --> python3 where applicable

[Benjamin Peterson]

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 when I made 'python' a link to python3.1 was
> that some tools used in making the HTML documentation haven't been upgraded
> to run with 3.)
>
> Shouldn't all library files that begin with the above line be changed so
> that they read 'python3' instead of python? Perhaps I should have just filed
> this as an issue, but I'm not confident of the state of the plan to move to
> python3 as the official executable name.

That sounds correct. Please file a bug report.



-- 
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] #!/usr/bin/env python --> python3 where applicable

[Kevin Teague]

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 conflicts I ran into when I made  
'python' a link to python3.1 was that some tools used in making the  
HTML documentation haven't been upgraded to run with 3.)


Shouldn't all library files that begin with the above line be  
changed so that they read 'python3' instead of python? Perhaps I  
should have just filed this as an issue, but I'm not confident of  
the state of the plan to move to python3 as the official executable  
name.


Hrmm ...

On installing from source, one either gets:

./bin/python3.0

Or is using 'make fullinstall':

./bin/python

So the default and the tutorial (http://docs.python.org/3.0/tutorial/interpreter.html 
) refer to 'python3.0'. But I've done all my Python installs with  
'make fullinstall' and then just manage my environment such that  
'python' points to a 2.x or 3.x release depending upon what the source  
code I'm working on requires. If using something such as the Mac OS X  
Installer you'll get both a 'python' and 'python3.0'.


Are there some Python installers that provide './bin/python3'?

But if there sometimes just 'python', 'python3.0' or 'python3' then  
it's not possible for the shebang to work with both all known install  
methods ...


One could argue that executable files part of the python standard  
library should have their interpreter hard-coded to the python  
interpreter to which they are installed with, e.g.:


#!/Users/kteague/shared/python-3.0.1/bin/python

Of course, this would remove the ability for a Python installation to  
be re-located ... if you wanted to move the install, you'd need to re- 
install it in order to maintain the proper shebangs. But it would mean  
that these scripts would also use the correct interpreter regardless  
of a user's current environemnt.


Or, if the standard library was packaged such that all of it's scripts  
were advertised as console_scripts in the entry_points, it'd be easier  
for different install approaches to decide how to write out the  
shebang or to instead provide wrapper scripts for accessing those  
entry points (since it might be nice to have a ./bin/pdb). But that's  
a bit pie-in-the-sky since entry_points isn't even yet a part of the  
Distutils Metadata.


___
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] [Python-ideas] Proposed addtion to urllib.parse in 3.1 (and urlparse in 2.7)

[Nick Coghlan]

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
>> one. There are exceptions to that guideline (e.g. the reverse argument
>> for sorted and list.sort), but they aren't common, and even when they do
>> crop up, making them keyword-only arguments is strongly recommended.
> 
> As you yourself previously noted -- "it is often
> better to use *args for the two positional arguments - it avoids
> accidental name conflicts between the positional arguments and arbitrary
> keyword arguments" -- kwargs may cause name conflicts.

Despite what I said earlier, it is probably OK to use named parameters
on the function in this case, especially since you have 3 optional
arguments that someone may want to specify independently of each other.
If someone really wants to add a query parameter to their URL that
conflicts with one of the function parameter names then they can pass
them in the same way they would pass in parameters that don't meet the
rules for a Python identifier (i.e. using the explicit params dictionary).

Something that can be done to even further reduce the chance of
conflicts is to prefix the function parameter names with underscores:

  def add_query_params(_url, _dups, _params, _sep, **kwargs)

That said, I'm starting to wonder if an even better option may be to
just drop the kwargs support from the function and require people to
always supply a parameters dictionary. That would simplify the signature
to the quite straightforward:

  def add_query_params(url, params, allow_dups=True, sep='&')

The "keyword arguments as query parameters" style would still be
supported via dict's own constructor:

>>> add_query_params('foo', dict(bar='baz'))
'foo?bar=baz'

>>> add_query_params('http://example.com/a/b/c?a=b', dict(b='d'))
'http://example.com/a/b/c?a=b&b=d'

>>> add_query_params('http://example.com/a/b/c?a=b&c=q',
... dict(a='b', b='d', c='q'))
'http://example.com/a/b/c?a=b&c=q&a=b&c=q&b=d'

>>> add_query_params('http://example.com/a/b/c?a=b', dict(a='c', b='d'))
'http://example.com/a/b/c?a=b&a=c&b=d'

This also makes the transition to a different container type (such as
OrderedDict) cleaner, since you will already be constructing a separate
object to hold the new parameters.

> But I also agree, that the current proliferation of positional args is ugly.
> 
> add_query_params_no_dups() would be suboptimal though, as there are
> currently three different ways to handle the duplicates:
> * allow duplicates everywhere (True),
> * remove duplicate *values* for the same key (False),
> * behave like dict.update -- remove duplicate *keys*, unless
> explicitly passed a list (None).

So if we went the multiple functions route, we would have at least:

add_query_params_allow_duplicates()
add_query_params_ignore_duplicate_items()
add_query_params_ignore_duplicate_keys()

I agree that isn't a good option, but mapping True/False/None to those
specific behaviours also seems rather arbitrary (specifically, it is
difficult to remember which of "allow_dups=False" and "allow_dups=None"
means to ignore any duplicate keys and which means to ignore only
duplicate items). It also doesn't provide a clear mechanism for
extension (e.g. what if someone wanted duplicate params to trigger an
exception?)

Perhaps the extra argument should just be a key/value pair filtering
function, and we provide functions for the three existing behaviours
(i.e. allow_duplicates(), ignore_duplicate_keys(),
ignore_duplicate_items()) in the urllib.parse module.

> (See the documentation at
> http://github.com/mrts/qparams/blob/bf1b29ad46f9d848d5609de6de0bfac1200da310/qparams.py
> ).

Note that your implementation and docstring currently conflict with each
other - the docstring says "pass them via a dictionary in second
argument:" but the dictionary is currently the third argument (the
docstring also later refers to passing OrderedDictionary as the second
argument).

Phrases like "second optional argument" and "fourth optional argument"
are also ambiguous - do they refer to "the second argument, which
happens to be optional" or to "the second of the optional arguments".
The fact that changing the function signature to disallow keyword
argument would make the optional parameters easier to refer to is a big
win in my book.

> Additionally, as proposed by Antoine Pitrou, removing keys could be 
> implemented.
> 
> It feels awkward to start a PEP for such a marginal feature, but
> clearly a couple of enlightened design decisions are required.

Probably not a PEP - just a couple of documented design decisions on a
tracker item pointing to discussion on this list for the rationale.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia

Re: [Python-Dev] #!/usr/bin/env python --> python3 where applicable

[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 release executables python3. (One
>> of the conflicts I ran into when I made 'python' a link to python3.1 was
>> that some tools used in making the HTML documentation haven't been upgraded
>> to run with 3.)
>>
>> Shouldn't all library files that begin with the above line be changed so
>> that they read 'python3' instead of python? Perhaps I should have just filed
>> this as an issue, but I'm not confident of the state of the plan to move to
>> python3 as the official executable name.
> 
> That sounds correct. Please file a bug report.

As Kevin pointed out, while this is a problem, changing the affected
scripts to say "python3" instead isn't the right answer.

All that happened with the Python 3 installers is that they do
'altinstall' rather than 'fullinstall' by default, thus leaving the
'python' alias alone. There is no "python3" alias unless a user creates
it for themselves (or a distro packager does it for them).

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).
2. Remove the offending shebang lines from the affected files and tell
people to use "python -m " instead.
3. Change the shebang lines in Python standard library scripts to be
version specific and update release.py to fix them all when bumping the
version number in the source tree.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
---
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] #!/usr/bin/env python --> python3 where applicable

[Benjamin Peterson]

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 release executables python3. (One
>>> of the conflicts I ran into when I made 'python' a link to python3.1 was
>>> that some tools used in making the HTML documentation haven't been upgraded
>>> to run with 3.)
>>>
>>> Shouldn't all library files that begin with the above line be changed so
>>> that they read 'python3' instead of python? Perhaps I should have just filed
>>> this as an issue, but I'm not confident of the state of the plan to move to
>>> python3 as the official executable name.
>>
>> That sounds correct. Please file a bug report.
>
> As Kevin pointed out, while this is a problem, changing the affected
> scripts to say "python3" instead isn't the right answer.
>
> All that happened with the Python 3 installers is that they do
> 'altinstall' rather than 'fullinstall' by default, thus leaving the
> 'python' alias alone. There is no "python3" alias unless a user creates
> it for themselves (or a distro packager does it for them).

I've actually implemented a python3 alias for 3.1.

>
> 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?).



-- 
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] #!/usr/bin/env python --> python3 where applicable

[Nick Coghlan]

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?).

If that decision has already been made, then sure, changing the shebang
lines to use the new name is the right thing to do.

It certainly wouldn't be the first time something was discussed at Pycon
or the sprints and those involved forgot to mention the outcome on the
list :)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
---
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] #!/usr/bin/env python --> python3 where applicable

[Steven Bethard]

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 decided on sometime (the sprints?).

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.

Why doesn't it make more sense to just use "python3" only for
"altinstall" and "python" for "fullinstall"?

Steve
-- 
I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a
tiny blip on the distant coast of sanity.
--- Bucky Katt, Get Fuzzy
___
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] #!/usr/bin/env python --> python3 where applicable

[Tony Nelson]

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 decision that Mitchell
>>> refers to).
>>
>> I believe this was decided on sometime (the sprints?).
>
>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.
>
>Why doesn't it make more sense to just use "python3" only for
>"altinstall" and "python" for "fullinstall"?

Just use python3 in the shebang lines all the time (where applicable ;), as
it is made by both altinstall and fullinstall.  fullinstall also make plain
"python", but that is not important.
-- 

TonyN.:'   
  '  
___
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] #!/usr/bin/env python --> python3 where applicable

[Nick Coghlan]

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
>>> refers to).
>> I believe this was decided on sometime (the sprints?).
> 
> 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.
> 
> Why doesn't it make more sense to just use "python3" only for
> "altinstall" and "python" for "fullinstall"?

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).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
---
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] #!/usr/bin/env python --> python3 where applicable

[Steven Bethard]

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 forever (i.e. actually make the decision that Mitchell
 refers to).
>>> I believe this was decided on sometime (the sprints?).
>>
>> 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.
>>
>> Why doesn't it make more sense to just use "python3" only for
>> "altinstall" and "python" for "fullinstall"?
>
> 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).

I wasn't suggesting that there shouldn't be a "python3.1",
"python3.2", etc. I'm more concerned about "fullinstall" creating
"python3" instead of regular "python".

Steve
-- 
I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a
tiny blip on the distant coast of sanity.
--- Bucky Katt, Get Fuzzy
___
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] #!/usr/bin/env python --> python3 where applicable

[Nick Coghlan]

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.1).
> 
> I wasn't suggesting that there shouldn't be a "python3.1",
> "python3.2", etc. I'm more concerned about "fullinstall" creating
> "python3" instead of regular "python".

If I understand Tony's summary correctly, the situation after Benjamin's
latest checkin is as follows:

2.x altinstall:
  - installs python2.x executable

2.x fullinstall (default for "make install"):
  - installs python2.x executable
  - adjusts (or creates) python symlink to new executable

3.x altinstall (default for "make install"):
  - installs python3.x executable
  - adjusts (or creates) python3 symlink to new executable

3.x fullinstall:
  - installs python3.x executable
  - adjusts (or creates) python3 symlink to new executable
  - adjusts (or creates) python symlink to new executable

With that setup, I'm sure we're going to get people complaining that
'altinstall' of 3.2 broke their python3 symlink from 3.1. If there are
going to be 3 levels of executable naming (python3.x, python3, python),
there needs to be 3 levels of installation rather than the traditional 2.

For example, add a new target "py3install" and make that the default for
3.1:

3.x altinstall:
  - installs python3.x executable

3.x py3install (default for "make install"):
  - installs python3.x executable
  - adjusts (or creates) python3 symlink to new executable

3.x fullinstall:
  - installs python3.x executable
  - adjusts (or creates) python3 symlink to new executable
  - adjusts (or creates) python symlink to new executable

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
---
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] #!/usr/bin/env python --> python3 where applicable

[Steven Bethard]

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 the python3 alias (e.g. installing 3.2 without overriding 3.1).
>>
>> I wasn't suggesting that there shouldn't be a "python3.1",
>> "python3.2", etc. I'm more concerned about "fullinstall" creating
>> "python3" instead of regular "python".
>
> If I understand Tony's summary correctly, the situation after Benjamin's
> latest checkin is as follows:
>
> 2.x altinstall:
>  - installs python2.x executable
>
> 2.x fullinstall (default for "make install"):
>  - installs python2.x executable
>  - adjusts (or creates) python symlink to new executable
>
> 3.x altinstall (default for "make install"):
>  - installs python3.x executable
>  - adjusts (or creates) python3 symlink to new executable
>
> 3.x fullinstall:
>  - installs python3.x executable
>  - adjusts (or creates) python3 symlink to new executable
>  - adjusts (or creates) python symlink to new executable

Thanks for the clear explanation. The fact that "python" still appears
with "fullinstall" covers my concern.

> With that setup, I'm sure we're going to get people complaining that
> 'altinstall' of 3.2 broke their python3 symlink from 3.1. If there are
> going to be 3 levels of executable naming (python3.x, python3, python),
> there needs to be 3 levels of installation rather than the traditional 2.
>
> For example, add a new target "py3install" and make that the default for
> 3.1:
>
> 3.x altinstall:
>  - installs python3.x executable
>
> 3.x py3install (default for "make install"):
>  - installs python3.x executable
>  - adjusts (or creates) python3 symlink to new executable
>
> 3.x fullinstall:
>  - installs python3.x executable
>  - adjusts (or creates) python3 symlink to new executable
>  - adjusts (or creates) python symlink to new executable

Yep, I agree this is what needs done to sensibly support a "python3".

Steve
-- 
I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a
tiny blip on the distant coast of sanity.
--- Bucky Katt, Get Fuzzy
___
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] #!/usr/bin/env python --> python3 where applicable

[Allan McRae]

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 without overriding 3.1).
  

I wasn't suggesting that there shouldn't be a "python3.1",
"python3.2", etc. I'm more concerned about "fullinstall" creating
"python3" instead of regular "python".



If I understand Tony's summary correctly, the situation after Benjamin's
latest checkin is as follows:

2.x altinstall:
  - installs python2.x executable

2.x fullinstall (default for "make install"):
  - installs python2.x executable
  - adjusts (or creates) python symlink to new executable

3.x altinstall (default for "make install"):
  - installs python3.x executable
  - adjusts (or creates) python3 symlink to new executable

3.x fullinstall:
  - installs python3.x executable
  - adjusts (or creates) python3 symlink to new executable
  - adjusts (or creates) python symlink to new executable

With that setup, I'm sure we're going to get people complaining that
'altinstall' of 3.2 broke their python3 symlink from 3.1. If there are
going to be 3 levels of executable naming (python3.x, python3, python),
there needs to be 3 levels of installation rather than the traditional 2.

For example, add a new target "py3install" and make that the default for
3.1:

3.x altinstall:
  - installs python3.x executable

3.x py3install (default for "make install"):
  - installs python3.x executable
  - adjusts (or creates) python3 symlink to new executable

3.x fullinstall:
  - installs python3.x executable
  - adjusts (or creates) python3 symlink to new executable
  - adjusts (or creates) python symlink to new executable
  



Adjusting the python2 installs to do something similar with symlinks to 
python2 would also be useful when python3 becomes the standard python 
and python2 is used for legacy.


I.e.

2.x altinstall:
- installs python2.x executable

2.x py2install (default for "make install"):
- installs python2.x executable
- adjusts (or creates) python2 symlink to new executable


2.x fullinstall (default for "make install"):
- installs python2.x executable
- adjusts (or creates) python2 symlink to new executable
- adjusts (or creates) python symlink to new executable

Allan





___
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] #!/usr/bin/env python --> python3 where applicable

[Allan McRae]

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.g. installing 3.2 without overriding 
3.1).
  

I wasn't suggesting that there shouldn't be a "python3.1",
"python3.2", etc. I'm more concerned about "fullinstall" creating
"python3" instead of regular "python".



If I understand Tony's summary correctly, the situation after Benjamin's
latest checkin is as follows:

2.x altinstall:
  - installs python2.x executable

2.x fullinstall (default for "make install"):
  - installs python2.x executable
  - adjusts (or creates) python symlink to new executable

3.x altinstall (default for "make install"):
  - installs python3.x executable
  - adjusts (or creates) python3 symlink to new executable

3.x fullinstall:
  - installs python3.x executable
  - adjusts (or creates) python3 symlink to new executable
  - adjusts (or creates) python symlink to new executable

With that setup, I'm sure we're going to get people complaining that
'altinstall' of 3.2 broke their python3 symlink from 3.1. If there are
going to be 3 levels of executable naming (python3.x, python3, python),
there needs to be 3 levels of installation rather than the 
traditional 2.


For example, add a new target "py3install" and make that the default for
3.1:

3.x altinstall:
  - installs python3.x executable

3.x py3install (default for "make install"):
  - installs python3.x executable
  - adjusts (or creates) python3 symlink to new executable

3.x fullinstall:
  - installs python3.x executable
  - adjusts (or creates) python3 symlink to new executable
  - adjusts (or creates) python symlink to new executable
  



Adjusting the python2 installs to do something similar with symlinks 
to python2 would also be useful when python3 becomes the standard 
python and python2 is used for legacy.


I.e.

2.x altinstall:
- installs python2.x executable

2.x py2install (default for "make install"):

And of course that was supposed to say "future default"...

- installs python2.x executable
- adjusts (or creates) python2 symlink to new executable


2.x fullinstall (default for "make install"):
- installs python2.x executable
- adjusts (or creates) python2 symlink to new executable
- adjusts (or creates) python symlink to new executable




___
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] #!/usr/bin/env python --> python3 where applicable

[Lennart Regebro]

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 make more sense to just use "python3" only for
> "altinstall" and "python" for "fullinstall"?

Because you will then get Python 3 trying to run all shebangs that
should be run with python 2. Making Python 3 default doesn't make it
compatible. ;-) And yes, that means we are stuck with it forever, and
I don't like that either, but nobody could come up with an
alternative.

The recommendation to use python3 could change back to use python once
2.7 falls out of support, which is gonna be many years still. And
until then we kinda need different shebang lines. Not much you can do
to get around that.

-- 
Lennart Regebro: Python, Zope, Plone, Grok
http://regebro.wordpress.com/
+33 661 58 14 64
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] #!/usr/bin/env python --> python3 where applicable

[Greg Ewing]

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
aliasing 'python' to 'python3' if we want, can't we?

--
Greg
___
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] #!/usr/bin/env python --> python3 where applicable

[Greg Ewing]

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
and fullinstall that aliases 'python3' but not 'python',
and make that the default. Maybe call it 'install3'.

--
Greg
___
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