Re: [Python-Dev] What's New text on future maintenance

[Martin v. Löwis]

> * It's very likely the 2.7 release will have a longer period of
>   maintenance compared to earlier 2.x versions.  Python 2.7 will
>   continue to be maintained while the transition to 3.x is in
>   progress, and that transition will itself be lengthy.  Most 2.x
>   versions are maintained for about 4 years, from the first to the
>   last bugfix release; patchlevel releases for Python 2.7 will
>   probably be made for at least 6 years.

I agree with Terry: how did you arrive at the 4 years for 2.x releases?
Bug fixes releases stopped after the next feature release being made,
which gave (counting between initial release and last bug fix release):
- 2.0 9 months
- 2.1 12 months
- 2.2 17 months
- 2.3 19 months
- 2.4 22 months
- 2.5 27 months
- 2.6 < 22 months (assuming the final 2.6 release is made before August)

In addition, since 2.3, we were offering security fixes for a period of
_five_ years.

So for 2.7, the question really is how long we create bug fix releases
and Windows binaries, rather than accepting only security fixes, and
producing source-only releases.

I'd personally expect that "longer" might mean 3 years (i.e. one more
release cycle), and definitely less than 6.

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] What's New text on future maintenance

[Nick Coghlan]

Terry Reedy wrote:
> Then the warnings stuff
>>
>> * Because 2.7 will be running production applications, a policy
> 
> Every major version (xcept 3.0) has run production application, and 3.1
> may be and 3.2 certainly will be. So this reasoning is not clear to me.
> 
>>decision was made to silence warnings only of interest to developers
>>by default.
> 
> I believe this is meant to say "Warnings aimed only at those porting
> code to 3.x are silenced by default."

Actually, the decision was indeed to make all Deprecation Warnings
silent by default. The rationale was a bit different from what AMK
currently has though (otherwise we wouldn't have made the same change in
3.x). I'll take a stab at a more accurate rationale:

"""For previous releases, it has been the policy of the CPython core
developers that :exc:`DeprecationWarning` should be enabled by default.
This provides Python developers with a clear indication when their code
has a substantial risk of breaking in the next major version of Python.
However, the nature of Python usage has changed over the years, such
that there are now a significantly larger number of Python application
users that are not directly involved in the development of those
applications. This has lead to a situation where users may be receiving
irrelevant warnings from an application that is actually working
correctly, creating unnecessary concern for affected end users and
additional overhead for the developers of these applications in
responding to these concerns.

Accordingly, starting with Python 2.7, this policy has been revised and
the CPython interpreter has been updated to silence all occurrences of
:exc:`DeprecationWarning` by default. Developers wishing to see if their
application is at significant risk of breaking on the next major Python
release can re-enable display of :exc:`DeprecationWarning` messages by
running Python with the :option:`-Wdefault` (short form: :option:`-Wd`)
switch, or you can add ``warnings.simplefilter('default')`` to your
code. (Note that the 'default' in these settings refers to the default
warning behaviour of displaying warnings once for each location where
they are encountered rather than to the overall default warning settings
used by the interpreter)"""

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

[Python-Dev] Issue #8610: Set default file system encoding to ascii on error?

[Victor Stinner]

Python 3.0 introduced PyUnicode_DecodeFSDefault() and 
PyUnicode_DecodeFSDefaultAndSize() functions. These functions fallback to 
UTF-8 if getting the file system encoding failed or the encoding is unknown 
(there is not nl_langinfo(CODESET) function).

UTF-8 is not a good choice for the fallback because it's incompatible with 
other encodings like Latin1. I would like to fallback to ASCII on error which 
is compatible with all encodings (thanks to surrogateescape).

I would like to ensure that sys.getfilesystemencoding() result cannot be None, 
because Python 3.2 uses it on Unix to decode os.environb and to encode 
filenames in subprocess. I can implement a fallback for os.environb and 
subprocess (and other functions calling sys.getfilesystemencoding()), but I 
prefer to have a reliable sys.getfilesystemencoding() function.

This change doesn't concern Windows and Mac OS X because the encoding is 
hardcoded (mbcs, utf-8). On Unix, I don't know in which case nl_langinfo() can 
fail. Empty environment is not an error: nl_langinfo(CODESET) returns "ascii". 
I think that few (or no) user would notice this change.

-- 
Victor Stinner
http://www.haypocalc.com/
___
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] Issue #8610: Set default file system encoding to ascii on error?

[Antoine Pitrou]

Le Fri, 07 May 2010 13:05:52 +0200, Victor Stinner a écrit :
> 
> UTF-8 is not a good choice for the fallback because it's incompatible
> with other encodings like Latin1. I would like to fallback to ASCII on
> error which is compatible with all encodings (thanks to
> surrogateescape).

What do you mean with "compatible with all encodings thanks to 
surrogateescape"?

>>> "àéè".encode("ascii", "surrogateescape")
Traceback (most recent call last):
  File "", line 1, in 
UnicodeEncodeError: 'ascii' codec can't encode characters in position 
0-2: ordinal not in range(128)

> I would like to ensure that sys.getfilesystemencoding() result cannot be
> None, because Python 3.2 uses it on Unix to decode os.environb and to
> encode filenames in subprocess. I can implement a fallback for
> os.environb and subprocess (and other functions calling
> sys.getfilesystemencoding()), but I prefer to have a reliable
> sys.getfilesystemencoding() function.

Having a reliable sys.getfilesystemencoding() would be a good thing 
indeed.

> This change doesn't concern Windows and Mac OS X because the encoding is
> hardcoded (mbcs, utf-8). On Unix, I don't know in which case
> nl_langinfo() can fail. Empty environment is not an error:
> nl_langinfo(CODESET) returns "ascii". I think that few (or no) user
> would notice this change.

Ok, it sounds like a good compromise.

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] Issue #8610: Set default file system e ncoding to ascii on error?

[Victor Stinner]

Le vendredi 07 mai 2010 13:24:18, Antoine Pitrou a écrit :
> > UTF-8 is not a good choice for the fallback because it's incompatible
> > with other encodings like Latin1. I would like to fallback to ASCII on
> > error which is compatible with all encodings (thanks to
> > surrogateescape).
> 
> What do you mean with "compatible with all encodings thanks to
> surrogateescape"?
> 
> >>> "àéè".encode("ascii", "surrogateescape")
> ...
> UnicodeEncodeError: 'ascii' codec can't encode characters ...

ascii+surrogatescape can *decode* anything:

>>> b"a\xc3\xff".decode('ascii', 'surrogateescape')
'a\udcc3\udcff'

Encode with ascii+surrogatescape raise an UnicodeEncodeError for non-ASCII 
(except for surrogates). I think it's better to raise an error than creating 
utf8 filenames on a latin1 file system.

--

I forgot to mention Marc Lemburg propositing of creating a PYTHONFSENCODING 
environment variable: #8622.

-- 
Victor Stinner
http://www.haypocalc.com/
___
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] Issue #8610: Set default file system encoding to ascii on error?

[M.-A. Lemburg]

Victor Stinner wrote:
> Python 3.0 introduced PyUnicode_DecodeFSDefault() and 
> PyUnicode_DecodeFSDefaultAndSize() functions. These functions fallback to 
> UTF-8 if getting the file system encoding failed or the encoding is unknown 
> (there is not nl_langinfo(CODESET) function).
> 
> UTF-8 is not a good choice for the fallback because it's incompatible with 
> other encodings like Latin1. I would like to fallback to ASCII on error which 
> is compatible with all encodings (thanks to surrogateescape).
> 
> I would like to ensure that sys.getfilesystemencoding() result cannot be 
> None, 
> because Python 3.2 uses it on Unix to decode os.environb and to encode 
> filenames in subprocess. I can implement a fallback for os.environb and 
> subprocess (and other functions calling sys.getfilesystemencoding()), but I 
> prefer to have a reliable sys.getfilesystemencoding() function.
> 
> This change doesn't concern Windows and Mac OS X because the encoding is 
> hardcoded (mbcs, utf-8). On Unix, I don't know in which case nl_langinfo() 
> can 
> fail. Empty environment is not an error: nl_langinfo(CODESET) returns 
> "ascii". 
> I think that few (or no) user would notice this change.

+1 on that change.

The UTF-8 fallback has these major problems:

 * it hides errors by always having the Unicode-bytes conversion
   succeed

 * it can cause applications to write files and create
   directories with wrongly encoded names (e.g. use UTF-8 on
   a Latin-1 file system)

Together with [issue8622] Add PYTHONFSENCODING environment variable:

http://bugs.python.org/issue8622

which reduces the Python3 reliance on encoding guess work,
the change would make Python3 more user friendly and reduce the
number of bummers user run into when waking up in the all-new
Unicode world of Python3.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, May 07 2010)
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/

2010-04-23: Released mxODBC.Zope.DA 2.0.1http://zope.egenix.com/

::: Try our new mxODBC.Connect Python Database Interface for free ! 


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
___
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] Possible patch for functools partial - Interested?

[VanL]

Howdy all -

I have an app where I am using functools.partial to bundle up jobs to
do, where a job is defined as a callable + args. In one case, I wanted
to keep track of whether I had previously seen a job, so I started
putting them into a set... only to find out that partials never test
equal to each other:

>>> import operator
>>> from functools import partial
>>> p1 = partial(operator.add)
>>> p2 = partial(operator.add)
>>> p1 == p2
False
>>> seen = set();seen.add(p1)
>>> p2 in seen
False

I created a subclass of functools.partial that provides appropriate
__eq__ and __hash__ methods, so that this works as expected. I called
the subclass a Job:
>>> j1 = Job(operator.add)
>>> j2 = Job(operator.add)
>>> j1 == j2
True
>>> seen = set();seen.add(j1)
>>> j2 in seen
True
>>> j1 is j2
False

While I was at it, I also added a nice repr. Would this group be
interested in a patch, or is this not interesting?

Thanks,

Van

___
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] Possible patch for functools partial - Interested?

[Michael Foord]

On 07/05/2010 16:37, VanL wrote:

Howdy all -

I have an app where I am using functools.partial to bundle up jobs to
do, where a job is defined as a callable + args. In one case, I wanted
to keep track of whether I had previously seen a job, so I started
putting them into a set... only to find out that partials never test
equal to each other:

   

import operator
from functools import partial
p1 = partial(operator.add)
p2 = partial(operator.add)
p1 == p2
 

False
   

seen = set();seen.add(p1)
p2 in seen
 

False

I created a subclass of functools.partial that provides appropriate
__eq__ and __hash__ methods, so that this works as expected. I called
the subclass a Job:
   

j1 = Job(operator.add)
j2 = Job(operator.add)
j1 == j2
 

True
   

seen = set();seen.add(j1)
j2 in seen
 

True
   

j1 is j2
 

False

While I was at it, I also added a nice repr. Would this group be
interested in a patch, or is this not interesting?

   
Sounds good to me. Could you post the patch to http://bugs.python.org 
please.


Michael Foord



Thanks,

Van

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk
   



--
http://www.ironpythoninaction.com/

___
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] Possible patch for functools partial - Interested?

[Antoine Pitrou]

VanL  gmail.com> writes:
> 
> I created a subclass of functools.partial that provides appropriate
> __eq__ and __hash__ methods, so that this works as expected. I called
> the subclass a Job:
[...]
> 
> While I was at it, I also added a nice repr. Would this group be
> interested in a patch, or is this not interesting?

It would be more useful to provide equality, hashing and repr to partial itself,
rather than a subclass. Feel free to propose a patch :)

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] What's New text on future maintenance

[A.M. Kuchling]

On Fri, May 07, 2010 at 09:30:00AM +0200, "Martin v. Löwis" wrote:
> I agree with Terry: how did you arrive at the 4 years for 2.x releases?
> Bug fixes releases stopped after the next feature release being made,
> which gave (counting between initial release and last bug fix release):

I used the initial release date of 2.4 and 2.5 and the dates of the
last patchlevel releases.  That may well be distorted by the recent
spasm of activity that led to 2.5.4.

--amk
___
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] Possible patch for functools partial - Interested?

[Rob Cliffe]

Sorry to grouse, but isn't this maybe being a bit too clever?
Using your example,
   p1 = partial(operator.add)
is creating a callable, p1, i.e. a sort of function.  Yes I know technically 
it's not a function, but it behaves very much like one.


Now, if I write

   def f1(x,y): return x+y
   def f2(x,y): return x+y

I don't expect  f1==f2 to be True, even though f1 and f2 behave in exactly 
the same way,

and indeed it is not.
If I wanted it to be true, I should have written

   def f1(x): return x+y
   f2=f1

I find this behaviour natural and expected, both in my example and yours 
(although maybe I've just got used to Python's behaviour).


Similarly, if you wanted p1==p2, why not write

   p1 = partial(operator.add)
   p2 = p1

Maybe I could be persuaded otherwise by a convincing use case, but I rather 
doubt it.

Rob Cliffe

- Original Message - 
From: "VanL" 

To: 
Sent: Friday, May 07, 2010 3:37 PM
Subject: [Python-Dev] Possible patch for functools partial - Interested?



Howdy all -

I have an app where I am using functools.partial to bundle up jobs to
do, where a job is defined as a callable + args. In one case, I wanted
to keep track of whether I had previously seen a job, so I started
putting them into a set... only to find out that partials never test
equal to each other:


import operator
from functools import partial
p1 = partial(operator.add)
p2 = partial(operator.add)
p1 == p2

False

seen = set();seen.add(p1)
p2 in seen

False

I created a subclass of functools.partial that provides appropriate
__eq__ and __hash__ methods, so that this works as expected. I called
the subclass a Job:

j1 = Job(operator.add)
j2 = Job(operator.add)
j1 == j2

True

seen = set();seen.add(j1)
j2 in seen

True

j1 is j2

False

While I was at it, I also added a nice repr. Would this group be
interested in a patch, or is this not interesting?

Thanks,

Van

___
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/rob.cliffe%40btinternet.com 


___
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] What's New text on future maintenance

[A.M. Kuchling]

On Fri, May 07, 2010 at 07:52:49PM +1000, Nick Coghlan wrote:
> 3.x). I'll take a stab at a more accurate rationale:

Thanks!  I've applied the scalpel and reduced it to:

* A policy decision was made to silence warnings only of interest to
  developers by default.  :exc:`DeprecationWarning` and its
  descendants are now ignored unless otherwise requested, preventing
  users from seeing warnings triggered by an application.  (Carried
  out in :issue:`7319`.)

  In previous releases, :exc:`DeprecationWarning` messages were
  enabled by default, providing Python developers with a clear
  indication of where their code may break in a future major version
  of Python.

  However, there are increasingly many users of Python-based
  applications who are not directly involved in the development of
  those applications.  :exc:`DeprecationWarning` messages are
  irrelevant to such users, making them worry about an application
  that's actually working correctly and burdening the developers of
  these applications with responding to these concerns.

  You can re-enable display of :exc:`DeprecationWarning` messages by
  running Python with the :option:`-Wdefault` (short form:
  :option:`-Wd`) switch, or you can add
  ``warnings.simplefilter('default')`` to your code.

Benjamin suggested being very definite about a 5-year maintenance
period, but I don't want to write any checks our butt can't cash, so
I've left the text as "Maintenance releases for Python 2.7 will
probably be made for 5 years."  An alternative formulation might say
it will be maintained for the next two 3.x releases, not the next one
as usual.

I thought about Ben Finney's suggestion to not give a timespan and
describe the conditions for 2.x maintenance continuing, but those
conditions are complicated to describe -- if 3.x doesn't catch on?  if
the 3.x transition is slow?  if there's a significant 2.x user base
that remains?  if someone starts a 2.x maintenance team? -- and might
be a confusing tangle of what-if statements.

--amk
___
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] Summary of Python tracker Issues

[Python tracker]

ACTIVITY SUMMARY (2010-04-30 - 2010-05-07)
Python tracker at http://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue 
number.  Do NOT respond to this message.


 2658 open (+44) / 17807 closed (+24) / 20465 total (+68)

Open issues with patches:  1081

Average duration of open issues: 724 days.
Median duration of open issues: 494 days.

Open Issues Breakdown
   open  2639 (+44)
languishing12 ( +0)
pending 6 ( +0)

Issues Created Or Reopened (71)
___

Bug in range() function for large values   2010-05-01
CLOSED http://bugs.python.org/issue1533reopened mark.dickinson  
 
   patch, 26backport   

configure: allow user-provided CFLAGS to override AC_PROG_CC d 2010-05-05
CLOSED http://bugs.python.org/issue8211reopened mark.dickinson  
 
   patch   

regrtest: use backslashreplace error handler for stdout2010-05-05
   http://bugs.python.org/issue8533reopened haypo   
 
   patch   

Add missing tests for FlushKey, LoadKey, and SaveKey in winreg 2010-04-30
   http://bugs.python.org/issue8579created  brian.curtin
 
   

Problem urllib2.URLError   2010-04-30
CLOSED http://bugs.python.org/issue8580created  m_enanos
 
   

Logging handlers do not handle double-closing very well2010-04-30
CLOSED http://bugs.python.org/issue8581created  Jason.Baker 
 
   patch   

urllib.urlretrieve fails with ValueError: Invalid format strin 2010-04-30
CLOSED http://bugs.python.org/issue8582created  Jason.Gross 
 
   patch   

Hardcoded namespace_separator in the cElementTree.XMLParser2010-04-30
   http://bugs.python.org/issue8583created  dmtr
 
   patch   

test_multiprocessing skips some tests  2010-04-30
   http://bugs.python.org/issue8584created  pitrou  
 
   

zipimporter.find_module is untested2010-05-01
   http://bugs.python.org/issue8585created  alex
 
   

test_imp.py test failures on Py3K Mac OS X 2010-05-01
CLOSED http://bugs.python.org/issue8586created  michael.foord   
 
   

test_import.py test failures on Py3K Mac OS X  2010-05-01
CLOSED http://bugs.python.org/issue8587created  michael.foord   
 
   

test_urllib2.py test failures on Py3K Mac OS X 2010-05-01
   http://bugs.python.org/issue8588created  michael.foord   
 
   

test_warnings.CEnvironmentVariableTests.test_nonascii fails un 2010-05-01
   http://bugs.python.org/issue8589created  michael.foord   
 
   

test_httpservers.CGIHTTPServerTestCase failure on 3.1-maint Ma 2010-05-01
   http://bugs.python.org/issue8590created  michael.foord   
 
   

update mkpkg to latest coding standards2010-05-01
   http://bugs.python.org/issue8591created  meatballhat 
 
   

'y' does not check for embedded NUL bytes  2010-05-01
   http://bugs.python.org/issue8592created  pitrou  
 
   

Improve c-api/arg.rst  2010-05-01
CLOSED http://bugs.python.org/issue8593created  pitrou  
 
   patch   

Add a "source_address" option

Re: [Python-Dev] Possible patch for functools partial - Interested?

[Alexander Belopolsky]

On Fri, May 7, 2010 at 11:02 AM, Antoine Pitrou  wrote:
> VanL  gmail.com> writes:
..
>> While I was at it, I also added a nice repr. Would this group be
>> interested in a patch, or is this not interesting?
>
> It would be more useful to provide equality, hashing and repr to partial 
> itself,
> rather than a subclass. Feel free to propose a patch :)

While you are at it, you might want to take a look at
http://bugs.python.org/issue7830, "Flatten nested functools.partial."
For your purposes you will need to decide whether partial(partial(f,
1), 2) and partial(f, 1, 2) compare equal or not.  Most likely with
the current implementation the answer will be "no,"  which may not be
ideal.
___
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] Possible patch for functools partial - Interested?

[Steven D'Aprano]

On Sat, 8 May 2010 02:07:55 am Rob Cliffe wrote:
> Sorry to grouse, but isn't this maybe being a bit too clever?
> Using your example,
> p1 = partial(operator.add)
> is creating a callable, p1, i.e. a sort of function.  Yes I know
> technically it's not a function, but it behaves very much like one.
>
> Now, if I write
>
> def f1(x,y): return x+y
> def f2(x,y): return x+y
>
> I don't expect  f1==f2 to be True, even though f1 and f2 behave in
> exactly the same way,
> and indeed it is not.

I do expect f1==f2, and I'm (mildly) disappointed that they're not.


[...]
> Similarly, if you wanted p1==p2, why not write
>
> p1 = partial(operator.add)
> p2 = p1

I thought the OP gave a use-case. He's generating "jobs" (partial 
applied to a callable and arguments), and wanted to avoid duplicated 
jobs.

I think it is reasonable to expect that partial(operator.add, 2) 
compares equal to partial(operator.add, 2). I don't think he's 
suggesting it should compare equal to partial(lambda x,y: x+y, 2).

+0.5 on comparing equal.
+1 on a nicer repr for partial objects.



-- 
Steven D'Aprano
___
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] Possible patch for functools partial - Interested?

[Steve Holden]

Steven D'Aprano wrote:
> On Sat, 8 May 2010 02:07:55 am Rob Cliffe wrote:
>> Sorry to grouse, but isn't this maybe being a bit too clever?
>> Using your example,
>> p1 = partial(operator.add)
>> is creating a callable, p1, i.e. a sort of function.  Yes I know
>> technically it's not a function, but it behaves very much like one.
>>
>> Now, if I write
>>
>> def f1(x,y): return x+y
>> def f2(x,y): return x+y
>>
>> I don't expect  f1==f2 to be True, even though f1 and f2 behave in
>> exactly the same way,
>> and indeed it is not.
> 
> I do expect f1==f2, and I'm (mildly) disappointed that they're not.
> 
How about

def f1(x, y): return x+y
def f2(x, y): return y+x

As you know, there are limits to everything. It seems to me that while
pure mathematics can (sometime) easily determine functional equivalence,
once you get to code it's a lot harder because there are semantic
constraints that don't apply in pure mathematics.

> 
> [...]
>> Similarly, if you wanted p1==p2, why not write
>>
>> p1 = partial(operator.add)
>> p2 = p1
> 
> I thought the OP gave a use-case. He's generating "jobs" (partial 
> applied to a callable and arguments), and wanted to avoid duplicated 
> jobs.
> 
> I think it is reasonable to expect that partial(operator.add, 2) 
> compares equal to partial(operator.add, 2). I don't think he's 
> suggesting it should compare equal to partial(lambda x,y: x+y, 2).
> 
Which absence, presumably, also mildly disappoints you?

regards
 Steve

> +0.5 on comparing equal.
> +1 on a nicer repr for partial objects.
> 
> 
> 


-- 
Steve Holden   +1 571 484 6266   +1 800 494 3119
See PyCon Talks from Atlanta 2010  http://pycon.blip.tv/
Holden Web LLC http://www.holdenweb.com/
UPCOMING EVENTS:http://holdenweb.eventbrite.com/

___
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] Possible patch for functools partial - Interested?

[Michael Foord]

On 07/05/2010 19:57, Steve Holden wrote:

Steven D'Aprano wrote:
   

On Sat, 8 May 2010 02:07:55 am Rob Cliffe wrote:
 

Sorry to grouse, but isn't this maybe being a bit too clever?
Using your example,
 p1 = partial(operator.add)
is creating a callable, p1, i.e. a sort of function.  Yes I know
technically it's not a function, but it behaves very much like one.

Now, if I write

 def f1(x,y): return x+y
 def f2(x,y): return x+y

I don't expect  f1==f2 to be True, even though f1 and f2 behave in
exactly the same way,
and indeed it is not.
   

I do expect f1==f2, and I'm (mildly) disappointed that they're not.

 

How about

def f1(x, y): return x+y
def f2(x, y): return y+x

As you know, there are limits to everything. It seems to me that while
pure mathematics can (sometime) easily determine functional equivalence,
once you get to code it's a lot harder because there are semantic
constraints that don't apply in pure mathematics.
   
Sure, but in CPython at least you *could* detect *identical* functions 
(but not functions that do the same thing in a different way). All the 
information is exposed - it would mean comparing bytecode though (plus 
signature etc) and is not likely to be portable to other implementations.


Partials that wrap the *same* function (based on identity) comparing 
equal seems useful enough to me.


Michael

--
http://www.ironpythoninaction.com/

___
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] What's New text on future maintenance

[Brett Cannon]

On Fri, May 7, 2010 at 09:09, A.M. Kuchling  wrote:

> On Fri, May 07, 2010 at 07:52:49PM +1000, Nick Coghlan wrote:
> > 3.x). I'll take a stab at a more accurate rationale:
>
> Thanks!  I've applied the scalpel and reduced it to:
>
> * A policy decision was made to silence warnings only of interest to
>  developers by default.  :exc:`DeprecationWarning` and its
>  descendants are now ignored unless otherwise requested, preventing
>   users from seeing warnings triggered by an application.  (Carried
>  out in :issue:`7319`.)
>
>   In previous releases, :exc:`DeprecationWarning` messages were
>  enabled by default, providing Python developers with a clear
>  indication of where their code may break in a future major version
>  of Python.
>
>  However, there are increasingly many users of Python-based
>  applications who are not directly involved in the development of
>  those applications.  :exc:`DeprecationWarning` messages are
>  irrelevant to such users, making them worry about an application
>  that's actually working correctly and burdening the developers of
>  these applications with responding to these concerns.
>
>  You can re-enable display of :exc:`DeprecationWarning` messages by
>   running Python with the :option:`-Wdefault` (short form:
>  :option:`-Wd`) switch, or you can add
>  ``warnings.simplefilter('default')`` to your code.
>
>
That sounds good to me.


> Benjamin suggested being very definite about a 5-year maintenance
> period, but I don't want to write any checks our butt can't cash, so
> I've left the text as "Maintenance releases for Python 2.7 will
> probably be made for 5 years."  An alternative formulation might say
> it will be maintained for the next two 3.x releases, not the next one
> as usual.
>
> I thought about Ben Finney's suggestion to not give a timespan and
> describe the conditions for 2.x maintenance continuing, but those
> conditions are complicated to describe -- if 3.x doesn't catch on?  if
> the 3.x transition is slow?  if there's a significant 2.x user base
> that remains?  if someone starts a 2.x maintenance team? -- and might
> be a confusing tangle of what-if statements.


Why can't we simply say that "we plan to support Python 2.7 beyond the
typical two years for bugfix releases"? It doesn't tie us to anything but
still lets people know our intentions. We don't have to worry about every
possible scenario now (e.g. 3.x gets no more traction or some other rare
event) and saying we plan on long term support but don't know for how long
is completely truthful; we have no timeline on how long we are willing to
keep 2.7 afloat beyond the fact that we plan to do it longer than normal.
___
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] Possible patch for functools partial - Interested?

[Steven D'Aprano]

On Sat, 8 May 2010 03:57:06 am Steve Holden wrote:
> Steven D'Aprano wrote:
> > On Sat, 8 May 2010 02:07:55 am Rob Cliffe wrote:
> >> Sorry to grouse, but isn't this maybe being a bit too clever?
> >> Using your example,
> >> p1 = partial(operator.add)
> >> is creating a callable, p1, i.e. a sort of function.  Yes I know
> >> technically it's not a function, but it behaves very much like
> >> one.
> >>
> >> Now, if I write
> >>
> >> def f1(x,y): return x+y
> >> def f2(x,y): return x+y
> >>
> >> I don't expect  f1==f2 to be True, even though f1 and f2 behave in
> >> exactly the same way,
> >> and indeed it is not.
> >
> > I do expect f1==f2, and I'm (mildly) disappointed that they're not.
>
> How about
>
> def f1(x, y): return x+y
> def f2(x, y): return y+x
>
> As you know, there are limits to everything. It seems to me that
> while pure mathematics can (sometime) easily determine functional
> equivalence, once you get to code it's a lot harder because there are
> semantic constraints that don't apply in pure mathematics.

This being Python, we can't assume x+y is always equal to y+x, so in 
your example I wouldn't expect them to be equal. And thus I avoid your 
trap :)

What you say is correct in general. I understand the arguments against 
making function equality more sophisticated than just identity testing: 
there aren't many use-cases for it, and it is potentially a lot of work 
depending on how clever you try to be. But if it came for free, it 
would be a sweet trick to impress your friends and scare your enemies.


[...]
> > I think it is reasonable to expect that partial(operator.add, 2)
> > compares equal to partial(operator.add, 2). I don't think he's
> > suggesting it should compare equal to partial(lambda x,y: x+y, 2).
>
> Which absence, presumably, also mildly disappoints you?

Only in the sense that in a perfect world where language features had 
benefits but no costs, I would expect nothing less.


-- 
Steven D'Aprano
___
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] What's New text on future maintenance

[Philip Jenvey]

On May 7, 2010, at 9:09 AM, A.M. Kuchling wrote:

>  You can re-enable display of :exc:`DeprecationWarning` messages by
>  running Python with the :option:`-Wdefault` (short form:
>  :option:`-Wd`) switch, or you can add
>  ``warnings.simplefilter('default')`` to your code.

The new PYTHONWARNINGS env var also needs mentioning here, how's about:

You can re-enable display of :exc:`DeprecationWarning` messages by
 either running Python with the :option:`-Wdefault` (short form:
 :option:`-Wd`) switch or by setting the :envvar:`PYTHONWARNINGS`
 environment variable to "default" (or "d") before running Python.
 Python code can also re-enable them by calling
 ``warnings.simplefilter('default')``.


--
Philip Jenvey
___
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] What's New text on future maintenance

[Martin v. Löwis]

A.M. Kuchling wrote:
> On Fri, May 07, 2010 at 09:30:00AM +0200, "Martin v. Löwis" wrote:
>> I agree with Terry: how did you arrive at the 4 years for 2.x releases?
>> Bug fixes releases stopped after the next feature release being made,
>> which gave (counting between initial release and last bug fix release):
> 
> I used the initial release date of 2.4 and 2.5 and the dates of the
> last patchlevel releases.  That may well be distorted by the recent
> spasm of activity that led to 2.5.4.

Ah. But the most recent 2.4 and 2.5 patchlevel releases are *not* bugfix
releases. They only provide security fixes, and I plan to provide them
for a period of five years (after the initial release).

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] Possible patch for functools partial - Interested?

[VanL]

On 5/7/2010 12:41 PM, Steven D'Aprano wrote:

>> Now, if I write
>>
>> def f1(x,y): return x+y
>> def f2(x,y): return x+y
>>
>> I don't expect  f1==f2 to be True, even though f1 and f2 behave in
>> exactly the same way, and indeed it is not.

This is not what I am getting after; these (IMO) should compare unequal.
I took a fairly conservative line, testing for identity of functions and
equality of arguments when converted to a normal form:

def __eq__(self, other):
try:
return ((self.func == other.func) and
(self.args == other.args) and
(self.keywords == other.keywords))
except AttributeError:
return False

def __hash__(self):
if self.keywords:
sorted_keys = sorted(self.keywords.keys())
values = [self.keywords[k] for k in sorted_keys]
kwhash = tuple(sorted_keys + values)
else:
kwhash = None
return hash(tuple((self.func, self.args, kwhash)))

It may be slightly controversial that I read out all the keys and values
and convert them to a normal form for the hash. This is both to get
around hashing issues (keywords is a dict, even though it is read-only)
and to allow for a dict-like object to be provided as an argument (which
happens in my application sometimes).

The repr is slightly long, too, but it was designed to support (weakly)
the idea that obj == exec(repr(obj)). Its not necessary, but I always
like it when that is true.

def __repr__(self):
if self.args: argstr = '*%s' % repr(tuple(self.args))
else: argstr = ''
if self.keywords: kwstr = '**%s' % self.keywords
else: kwstr = ''
if argstr and kwstr: argstr += ', '
classname = self.__class__.__name__
funcname = self.func.__name__
if argstr or kwstr: funcname += ', '
return '%s(%s%s%s)' % (classname, funcname, argstr, kwstr)

I make no effort to look for functional equality between two different
functions. too many side effects could go off trying to make that work,
and it would still be only inconsistently right. (IIRC, doing it
completely is NP-hard.)

Thanks,

Van

___
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] Possible patch for functools partial - Interested?

[Isaac Morland]

On Fri, 7 May 2010, VanL wrote:


I make no effort to look for functional equality between two different
functions. too many side effects could go off trying to make that work,
and it would still be only inconsistently right. (IIRC, doing it
completely is NP-hard.)


Actually, doing it completely is flat-out impossible.

Godel, Halting Problem, and all that.

So you don't need to apologize for not doing it ;-)

Isaac Morland   CSCF Web Guru
DC 2554C, x36650WWW Software Specialist
___
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] Possible patch for functools partial - Interested?

[Terry Reedy]

There is obviously interest in your proposal. I suggest you open an 
issue on the tracker. Make it a library feature request for 3.2. Upload 
the patch as a separate file. I would include the subclass form in the 
post to show the intneded effect, for discussion, and also so people can 
test and use with current installations without patching. When you have 
done so, post here in a followup with the link.


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] audience-instructors for Teach Me Python Bugfixing needed

[Vincent Davis]

On Thu, May 6, 2010 at 9:29 AM, Antoine Pitrou  wrote:

>
> Scanning through open issues will also give you a general idea of what
> kind of functionalities are looking for improvement, or need fixing.
>
> (you can create a new issue and start tackling it yourself, too)
>
> As a wanabe Dev I think the hardest thing is to find an open issue I can
actually fix and to have a mentor to help make sure I don't miss something I
did not know about.

Please record the "Teach Me" session if it happens. (audio and/or video)


>
>
  *Vincent Davis
720-301-3003 *
vinc...@vincentdavis.net
 my blog  |
LinkedIn
___
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] What's New text on future maintenance

[Nick Coghlan]

A.M. Kuchling wrote:
> On Fri, May 07, 2010 at 07:52:49PM +1000, Nick Coghlan wrote:
>> 3.x). I'll take a stab at a more accurate rationale:
> 
> Thanks!  I've applied the scalpel and reduced it to:

I saw this go by on the checkin list - looks good (although Philip is
right about mentioning PYTHONWARNINGS).

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] audience-instructors for Teach Me Python Bugfixing needed

[Nick Coghlan]

Vincent Davis wrote:
> As a wanabe Dev I think the hardest thing is to find an open issue I can
> actually fix and to have a mentor to help make sure I don't miss
> something I did not know about. 

Does the "easy" tag help with that at all? It's intended to mark issues
that aren't delving into deep dark corners of the interpreter or
standard library, but when you've been doing this for a long time one's
judgment of what's easy and what's difficult can get a little askew.

(e.g. I recently marked the task of fixing the enumerate docstring as
easy, but that does still require knowing how docstrings work for C code)

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

[Python-Dev] urlparse.urlunsplit should be smarter about +

[David Abrahams]

This is a bug report.  bugs.python.org seems to be down.

  >>> from urlparse import *
  >>> urlunsplit(urlsplit('git+file:///foo/bar/baz'))
  git+file:/foo/bar/baz

Note the dropped slashes after the colon.

-- 
Dave Abrahams   Meet me at BoostCon: http://www.boostcon.com
BoostPro Computing
http://www.boostpro.com

___
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] urlparse.urlunsplit should be smarter about +

[Senthil Kumaran]

On Sat, May 8, 2010 at 8:19 AM, David Abrahams  wrote:
>
> This is a bug report.  bugs.python.org seems to be down.

Tracked here: http://bugs.python.org/issue8656

>  >>> urlunsplit(urlsplit('git+file:///foo/bar/baz'))

Is 'git+file' a valid protocol? Or was it just your example?
I don't see any reason for it to be invalid but I don't find
authoritative references either.

-- 
Senthil
___
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] urlparse.urlunsplit should be smarter about +

[David Borowitz]

On Fri, May 7, 2010 at 21:04, Senthil Kumaran  wrote:

> On Sat, May 8, 2010 at 8:19 AM, David Abrahams  wrote:
> >
> > This is a bug report.  bugs.python.org seems to be down.
>
> Tracked here: http://bugs.python.org/issue8656
>
> >  >>> urlunsplit(urlsplit('git+file:///foo/bar/baz'))
>
> Is 'git+file' a valid protocol? Or was it just your example?
> I don't see any reason for it to be invalid but I don't find
> authoritative references either.
>

RFC 3986 is pretty clear on allowing '+' in scheme names, in principle if
not necessarily in practice:
http://tools.ietf.org/html/rfc3986#section-3.1


> --
> Senthil
> ___
> 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/ddborowitz%40gmail.com
>



-- 
It is better to be quotable than to be honest.
   -Tom Stoppard

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